电网数字化标书（bid-technical-response）

运行环境与依赖

• Python 3.8+，四个脚本（build_spec_response.py、build_bid_docx.py、verify_spec_response.py、verify_bid_docx.py）均依赖 python-docx。
• 安装依赖：pip install -r requirements.txt（或 pip install python-docx）。
• 脚本缺失该依赖时会以 缺少依赖：python-docx 明确退出，不会静默产出错误文件。
• 脚本全部离线运行，不联网、不写技能目录之外的文件；仅读取传入的输入文件、输出到 --output 指定路径。
• 若本机无 python-docx，可改用 WorkBuddy 内置文档工具链（workbuddy-local-office-edit / workbuddy-docx）完成 docx 生成与核验，门禁判据不变。

〇、首要分支判定（Step 0，必做）

接到任务后第一件事是判定走哪一轨，二者格式与流程完全不同，⛔ 不得混用：

默认优先轨 A：只要用户提供的是"技术规范书"或"服务内容要求"类文件，走轨 A。

一、二十条最高原则

1. 【红线一】矩阵先行，正文后写：未建立完整应答矩阵前⛔ 禁止动笔。技术标失分主因是漏答与前后不一致，不是文笔。
2. 【红线二】不得编造：无用户书面依据时⛔ 严禁生成资质证书编号、业绩（项目名称/业主/金额/验收结论）、人员姓名职称证书、注册资本营收、检测报告编号。只写结构与占位符 【待提供：…】。
3. 【红线三】版式服从招标文件：招标文件规定的格式、字体、字号、装订、密封、份数绝对优先于内置版式；用内置版式前先查招标文件"投标文件格式"章。
4. 【红线四】交付前必过门禁：轨 A 跑 verify_spec_response.py，轨 B 跑 verify_bid_docx.py（双章项目加 --dual）；并走查 references/合规红线与废标项.md 的 10 项废标清单。有 FAIL 禁止交付。
5. 【红线五】指标零偏差：应答/方案中的指标数值、工作内容、工作周期、任务名称必须与招标原文一字不差。允许变换措辞、语序、句式；⛔ 不允许改动任何数值、标准号、等级、周期、任务名称。
6. 【红线六】格式镜像：编号形式随原文⭐（2026-10-12 用户指令新增）：应答文件的标题格式与编号体系必须与原技术规范书保持一致。原文某标题下用 （1）（2）（3） 列小项，应答就沿用 （1）（2）（3）；原文用 1. 2.，应答就用 1. 2.；原文用 1.1 1.2，应答就用 1.1 1.2。⛔ 严禁把 （1）（2）（3） 改写成"一是/二是/三是"——这是最常见的格式破坏；⛔ 严禁自造"（一）（二）"层级、⛔ 严禁改写标题措辞、⛔ 严禁把多级标题压平成连续段落。详见 references/技术规范书逐条应答格式规范.md 第三章之二、之四。
7. 【红线七】表格整块应答，不拆条⭐：技术规范书中的表格（设计开发任务清单、功能清单、参数表、进度表、交付物清单等）一律原样整表照录，⛔ 不得把表格行/列/单元格拆出来逐条应答、⛔ 不得为每行单独写"应答：理解并满足。"块、⛔ 不得把表格内容改写成"N 个自然段"逐段对应。表后只写一个总结式应答块。表格行不计入条数守恒。详见 references/技术规范书逐条应答格式规范.md 第四章。
8. 【红线八】适度扩充 20%~40%⭐（2026-10-12 用户指令新增）：应答展开只在其所应答的原条款内容基础上适度扩充 20%~40%，作用是点明"如何满足"，⛔ 不得大幅铺陈、⛔ 不得加演原文没有的技术细节/实现方案/工艺流程、⛔ 不得引入原文没有的新内容或新指标、⛔ 不得为凑篇幅重复原文。衡量口径：应答展开字数 ÷ 对应招标原文字数 ≈ 1.2~1.4。超出即视为过度编写，需精简。详见 references/技术规范书逐条应答格式规范.md 第三章之五。
9. 【红线九】评分表驱动大纲（轨 B）⭐：未完成"评分项 → 章节大纲 + 篇幅配额"映射前，⛔ 禁止写技术方案正文。技术方案的章节标题须与评分项名称一致或高度对应，篇幅按分值分配，深度对标评分标准的最优档次。详见 references/评分表驱动的方案大纲.md。
10. 【红线十】封面单位必须是投标人⭐⭐（2026-10-13 用户指令固化，废标级）：技术标首页的单位是投标人，⛔ 绝不是技术规范书里的项目单位/招标人/采购人/建设单位。投标人名称未知时一律用 XXXX公司 占位，⛔ 严禁照抄招标文件单位名称、⛔ 严禁留空。build_bid_docx.py 已内置校验，填入招标人名称会直接退出且不生成文件；门禁 G 组复核。详见 references/封面主体信息规范.md。
11. 【红线十一】设计开发方案与系统实施方案必须分章且有区分⭐⭐（2026-10-13 用户指令固化）：评分表同时含"设计开发方案"与"系统实施方案"时，⛔ 必须拆成两章（不得合并成"技术与实施方案"），并按方案名称归位内容——设计开发方案写总体设计四要件（系统架构、技术路线、非功能性要求〔设计侧〕、信息安全集成需求分析）+ 开发任务五段式；系统实施方案写九要件（差异分析及方案设计、数据收集及处理、系统部署及配置、系统集成、系统测试、上线准备及切换、上线试运行支持、系统建转运、非功能性要求〔实施侧〕）。两章要素并集必须覆盖打分表全部要求，⛔ 但内容不得雷同：非功能性要求在设计侧写"设计约束"、实施侧写"验证闭环"，⛔ 不得整段复制。门禁 H 组（--dual）核查要素齐全与章节错位。详见 references/设计开发方案与系统实施方案双章写法.md。
12. 【红线十二】需求分析必须分"政策 / 业务 / 管理"三个方面⭐⭐（2026-10-14 用户指令固化）：技术方案中的需求分析章节，⛔ 必须且只能设1. 政策需求、2. 业务需求、3. 管理需求 三个二级节，顺序一致，⛔ 不得合并、不得改名、不得插入自创小节。政策需求须同时覆盖国家政策要求（政策导向→行业含义→转化为本项目需求）与电网公司政策要求（五架构遵从、数据模型、开发平台与标准号、等保三级、自主可控适配），⛔ 不得只写国家政策或空写"符合公司要求"。业务需求与管理需求一律按「现状分析 → 面临问题 → 引出需求」三段递进写，问题成条、需求成条且一一对应；管理需求须含身份/消息/资产/组织四条主线。详见 references/现状分析与需求分析写法.md。
13. 【红线十三】系统开发类章节骨架照标准大纲⭐（2026-10-14 用户指令固化）：系统开发类投标技术文件在招标文件未另行规定章节结构时，⛔ 一律采用 references/系统开发类投标技术文件标准大纲.md 的 8 章骨架与三级标题编号体系：一、（章）→（一）（节）→1.（条）→1.1（目）→1.1.1（细目），全文统一、⛔ 不得混编编号体系、⛔ 不得用字号放大区分层级。第一章固定为「现状分析」（项目背景/需求分析/关键点与难点/项目目标），第二章固定为「设计开发方案」。
14. 【红线十四】应答展开首句禁用"明确"⭐⭐（2026-10-14 用户指令固化，逐字口径）：应答展开首句写我方理解并满足<条款名>要求，<内容>：时，⛔ "明确"二字一律不得出现。旧公式"我方理解并满足<条款名>要求，明确<要点>："已废止。收到"我方理解并满足"后，直接按技术规范书该条款的要求内容展开应答，不插入任何提示性动词。正确：我方理解并满足项目说明要求，理解当前……存在底层逻辑不统一等问题，我方将……；错误：我方理解并满足项目说明要求，明确项目说明……。门禁 C 组核查。
15. 【红线十五】技术方案正文禁用第一人称主语⭐⭐（2026-10-14 用户指令固化，仅适用轨 B）：技术方案按正常方案编制模式输出，⛔ 不用"我方/我司/本公司/本单位/笔者"作主语，⛔ 不强加主语，直接陈述方案内容与实施动作。正例：采用微服务架构，按等级保护三级设计数据加密机制。／上述要求全部前置为设计输入，在概要设计阶段同步输出五大架构视图与等保条款对照表。；反例：我方采用微服务架构，满足等保三级要求。／本公司承诺提供 7×24 小时服务。。⚠️ 轨 A 不受本条约束——轨 A 是"逐条应答"体裁，"我方理解并满足…"是范本实测格式（红线十四），照旧保留。门禁 K 组检出即 FAIL；build_bid_docx.py 生成时即打印告警。详见 references/投标技术标版式规格.md 第二节。
16. 【红线十六】表格文字统一宋体五号居中⭐⭐（2026-10-14 用户指令固化，轨 B）：技术方案中所有表格的表内文字（含表首行）一律 宋体五号 10.5pt + 水平居中；表首行额外加粗以示表头，表内容不加粗。⛔ 不再区分表首行与表内容的字号，⛔ 表内单元格一律不得左对齐或右对齐，⛔ 表内不得出现"我方/本公司"（责任方列写"投标人/招标人/第三方"等角色名）。build_bid_docx.py 已内置（SIZE_TABLE=10.5 + 居中），门禁 J 组逐单元格核验，不符报 FAIL。
17. 【红线十七】交付前必须过格式统一核验⭐⭐（2026-10-14 用户指令固化，轨 B）：⛔ 不得凭印象认为格式正确。交付前必跑 python scripts/verify_bid_docx.py 方案.docx --format-only（仅版式）或完整门禁，脚本报告末尾输出 L 组版式统一核验清单（14 项逐项 ✓/✗），任一 ✗ 即返工。清单覆盖：A4 尺寸 / 上下25.4 左右31.8mm / 无页眉 logo 与水印 / 正文与标题宋体小四 12pt / 表格宋体五号 10.5pt 居中 / 全文 1.5 倍行距 / 正文首行缩进 2 字符 / 禁斜体下划线 / 第一人称主语 0 处 / 目录页存在 / 编号体系统一不混编 / 封面主体为投标人 / 无章首概述段、无章末响应小结、无引述规范书铺垫（红线二十）。⚠️ 脚本通过 ≠ 格式合格，另须人工确认表题位置、图题与"阅读要点"、无单行独占一页、章节标题与评分项同名。
18. 【红线十八】技术方案必须生成目录⭐⭐（2026-10-15 用户指令新增，轨 B 强制）：技术方案 docx ⛔ 必须带目录页，位置为封面之后、正文之前，格式为「目　录」标题段（宋体加粗居中）+ Word TOC 域（TOC \o "1-3" \h \z \u，收录 一、/（一）/1. 三级标题，带页码）。build_bid_docx.py 默认生成目录，无需任何参数；⛔ 不得手工在 markdown 里写"目录"章节冒充，⛔ 不得用静态文字罗列章名（无法随页码更新）。各级标题已内置 w:outlineLvl 大纲级别，文档 settings.xml 写入 updateFields，Word 打开时提示更新域即自动补齐条目与页码。仅在招标文件明确要求不设目录时才用 --no-toc 关闭，并须记入交付报告。门禁 M 组核查（目录标题段 + TOC 域 + 大纲级别三者缺一即 FAIL），已并入 L 组清单。
19. 【红线十九】实施方案的关键点难点必须从实施角度写、与设计开发区分⭐⭐（2026-10-15 用户指令固化，实测《投标技术方案-系统实施.docx》）：系统实施方案（实施标段）第一章「（三）关键点与难点」⛔ 必须聚焦实施落地环节，难点条目从 I1~I9 实施要件中提炼（如：一、二级部署环境异构、实施数据源多口径校验、集成联调跨单位协同、上线切换窗口受限、系统建运平稳交接）；⛔ 严禁照抄或雷同设计开发方案的难点清单（多链底层逻辑统一、合约安全引擎构建、溯源性能与精度、标注防篡改留痕等 D 类设计开发难点属设计开发标段，不得出现在实施方案中），两份方案的难点条目不得重名。难点写法仍按"总述段＋难点汇总表＋逐点『现状与问题 → 解决思路：』两段式"（见 references/现状分析与需求分析写法.md 第四章）；总述段须点明"本标段承接设计开发标段既定设计成果、难点集中在实施落地环节"的定位；数量按用户指令执行（本例 5 个）。
20. 【红线二十】方案直陈本体：禁章首概述、禁章末响应小结、禁引述规范书作铺垫⭐⭐（2026-10-15 用户指令固化，仅适用轨 B）：技术方案就是方案，正文 ⛔ 直接写方案内容——采取什么措施、设计什么功能、怎么实现，开门见山。三项禁止：① 一级/二级标题后 ⛔ 不写引导性/总结性概述段（"本章围绕……""本节介绍……""本节是……"式）；② 每章末尾 ⛔ 不写"本章响应/本评分点响应小结/本章小结"式收尾段；③ 章节开头 ⛔ 不引用技术规范书/评分表原文作为要求基础再对应写方案（招标任务清单要求"……"。本方案按此要求……式首句已废止）。技术规范书要求已通过评分点—大纲映射整体覆盖，⛔ 不得把规范书要求单列复述后再逐一对应写方案。判据：直接承载方案实质内容（措施/功能/动作/数据/交付物）的段落保留，纯元话语（说明本章是什么、如何响应、复述招标要求）一律删；评分关键词命中靠章节标题与评分项同名及正文实质内容保证，不依赖响应小结段。门禁 N 组核查。⚠️ 轨 A（逐条应答）的"招标原文照录+应答"是范本实测格式（红线五/六/十四），不受本条约束。

服务领域（主）：电力信息化/数字化系统类（调度自动化、配网自动化、数据中台、网络与信息安全等）；咨询/服务/运维类（方案咨询、运维外包、检测校验、项目管理评审）。其他类型（EPC、设备采购）可套用方法论，章节架构需改用相应专业骨架。

二-A、轨 A 工作流：技术规范书逐条逐项应答

A-Step 1 — 读取并拆解招标规范书

1. 读入招标文件（.wps 为 OLE2 二进制，用 open_file file_type=doc 或先转 .docx），逐段提取标题层级 + 原文段落 + 表格。
2. 建立条款清单（见 references/应答矩阵与条款解构.md），标出每个条款下的编号子项数量。
3. 提取全文指标数值清单（数值+单位+标准号+等级+周期），作为一致性比对基线。
4. 标记表格型条款⭐：凡以表格形式给出的内容（设计开发任务清单、功能清单、参数表、进度表、交付物清单等），在清单中标注 【表格】，该条款按 A-Step 2 表格规则处理，不拆行成条。

A-Step 2 — 逐条撰写（三段式，严格）

[条款标题]        宋体14加粗 ← 标题文字与编号形式 ⛔照录原文
[招标原文]        宋体12常规，首行缩进2字符 —— ⛔逐字照录
应答：理解并满足。  宋体12 黑色+加粗+单下划线 —— 独立成段
[应答展开]         宋体12 黑色+加粗+单下划线 —— 篇幅见 A-Step 2.3

• 展开首句公式⭐（2026-10-14 用户指令修订）：我方理解并满足<条款名>要求，<按技术规范书该条款要求内容直接展开>：
• ⛔ 不得写"明确"二字。原公式 我方理解并满足<条款名>要求，明确<要点>： 已废止。
• 正确：我方理解并满足项目说明要求，理解当前星火链网节点以及能源碳链等服务与国网链存在……
• 错误：我方理解并满足项目说明要求，明确项目说明…… / ……，明确实现方案、完成……
• 短条款可省冒号直接句号收尾：我方理解并满足部署方式要求，本项目部署方式为一、二级部署。
• ⭐ 编号形式随原文（红线六）：应答展开的分项编号必须沿用招标原文的编号形式。原文 （1）（2）（3） → 应答写 （1）（2）（3）；原文 1. 2. → 应答写 1. 2.。⛔ 不得写成"一是/二是/三是"，⛔ 不得换成 （一）（二）、① ② ③ 或其它体系。
• ⭐ 扩充幅度 20%~40%（红线八）：展开字数控制在对应招标原文字数的 1.2~1.4 倍，见 A-Step 2.3。
• 指标零偏差：数值、周期、标准号、等级逐字继承。

⭐ A-Step 2.1 — 表格型条款的应答规则（红线七，优先于上面的通用规则）

适用范围：设计开发任务清单、功能需求清单、参数表、进度里程碑表、交付成果清单、报价/清单类表等一切表格型内容。
唯一例外：招标文件明确要求"对表格中每一项单独出具应答/承诺函/偏离说明"时，以招标文件要求为准（红线三）。

标准范例（开发功能清单类）：

[整表照录：一级业务需求｜二级业务需求｜一级功能｜二级功能｜状态｜功能描述 …]

应答：理解并满足。
我方对开发任务清单所列一级功能点（度电赋码、状态校核、反窃电证据链、全景可视化等）全部响应，
按项目要求完成全部功能开发工作，各项功能的具体实现方案详见技术方案相应章节。

⭐ A-Step 2.2 — 编号形式镜像规则（红线六，对应格式规范第三章之四）

三条硬要求：
1. 标题格式照录：应答文件的章节标题文字、层级、编号与原技术规范书一一对应，⛔ 不得改写标题措辞、⛔ 不得自造层级、⛔ 不得增删章节。
2. 编号体系一致：一份文件内只用招标原文那一种编号体系，⛔ 不得混用。
3. 原文无编号则不新增：原文是连续段落的，应答展开同样写成段落，⛔ 不得为了"看起来清晰"擅自拆成 （1）（2）（3）。

⚠️ 常见破坏（⛔ 必查）：原文 （1）系统应支持数据采集； 应答写成 一是系统应支持数据采集； —— 这已构成格式破坏，须改回 （1）。

⭐ A-Step 2.3 — 扩充幅度控制（红线八，对应格式规范第三章之五）

目标：应答展开字数 ÷ 对应招标原文字数 = 1.2 ~ 1.4。

自检：写完一段展开后估算字数比。> 1.5 倍即需精简，删掉原文没有的技术推演；< 1.1 倍视为应答过薄，须补足"如何满足"的落实要点。
⚠️ 表格型条款走 A-Step 2.1 的总结式应答，不适用本节字数比。

A-Step 3 — 生成 docx

python scripts/build_spec_response.py --input 应答.md --output 应答文件.docx \
  --org "XXXXX公司" --date "日期"

:: 文字 = 应答段（自动渲染为黑色加粗单下划线）；表格单元格内以 :: 开头的同样按 BU 格式渲染。

A-Step 4 — 交付前门禁（必跑）

python scripts/verify_spec_response.py 应答文件.docx
# 招标文件明确要求"表格逐项单独应答"时，追加豁免开关：
python scripts/verify_spec_response.py 应答文件.docx --allow-table-split

核验十组：A页面 / B字体 / C应答BU格式 / D条款闭合性 / E条数守恒（不含表格） / F指标一致性 / G内容风险 / H表格未拆条 / I编号形式镜像 / J扩充幅度。退出码 0=无高危，1=有 FAIL 必须修复。报告末尾列出"未应答条款"清单，并输出每张表的「数据行数 / 应答结论句数 / 连续应答段数」核查明细。

A-Step 5 — 交付四项报告

覆盖率（条款总数/已应答数/未应答清单，表格按 1 条款计）、指标核对（继承指标及逐项一致性）、待补清单（占位符及章节）、风险提示（可能触发否决的条款）。⛔ 不得省略表格型条款的应答方式说明。

二-B、轨 B 工作流：技术方案编写（⭐ 评分表驱动）

> 轨 B 的成败在写作之前的结构设计。顺序永远是：读评分表 → 定大纲 → 分篇幅 → 才写正文。
> ⛔ 跳过 B-Step 1~2 直接写正文，是技术标低分的头号原因。

B-Step 0 — 类型判定与材料受理

判定项目类型（系统开发类 / 服务咨询类 / 运维类 / 其他）。系统开发类走 B-Step 2.5 任务清单轨。
收集：招标文件全套（⭐技术评分表/评标办法、技术规范书、技术需求、投标格式、答疑澄清与补遗）、投标人资质业绩人员素材。
材料不全不阻塞（用占位符），但缺评分表或技术规范书无法起步；两者皆缺时先向用户索取。

B-Step 1 — ⭐解析技术评分表（红线九第一步）

按 references/评分表驱动的方案大纲.md 第一节执行：
1. 定位评分表（评标办法/技术评分细则/详细评审表），⭐必查答疑澄清与补遗——分值与细目常在此被修改。
2. 逐条提取评分项号、名称、分值、评分标准原文（逐字照录）、得分档次描述、扣分项、关联招标条款号。⛔ 不得把多个评分项合并成一条。
3. 把评分标准中的措辞翻译成必写动作（如"方案完整科学合理"→ 须有架构图 + 选型论证）。
4. 校验：所有评分项分值之和 = 技术分总分。对不上说明漏了评分项或漏了补遗。

产出：填入 assets/评分点-大纲对照表模板.md 第一节。

B-Step 2 — ⭐评分项 → 章节大纲 + 篇幅配额（红线九第二步）

1. 一评分项一章节（或一章多节）：评分项名称直接作为章节标题，⛔ 不用与评分项无关的自创标题。
2. 顺序对齐：章节顺序优先服从招标文件规定；未规定时按评分表顺序排列，便于评委顺序勾读。
3. 篇幅配额：章节占比 ≈ 该章覆盖分值 ÷ 技术分总分 × 100%；档次要求"完整/全面"的章节上浮 20~30%。
4. 反向校验（全部打勾才准进入写作）：每个评分项有同名章节、每个必写要素有小节、分值合计一致、无自嗨章。

产出：assets/评分点-大纲对照表模板.md 第二节。未完成此表⛔ 禁止写正文。

B-Step 2.5 — ⭐系统开发类：解析开发任务清单（重点，见第三节之二）

系统开发/软件建设类项目必须执行，详见第三节之二：
1. 在招标文件中定位开发任务清单 / 设计开发任务清单 / 功能清单（无表时按技术规范书文字条款切分）。
2. 逐行登记任务台账：任务号、招标任务名称照录、交付物、工期、落点章节。⛔ 任务数、名称、顺序与招标清单逐行一致，不得增删改序。
3. 每项任务在方案中独占一节，小节标题 = 招标任务名，按五段式展开。
4. 章末出开发任务清单响应总表（任务号 → 章节 → 交付物 → 周期），作为全覆盖的直接证据。

⛔ 严禁自行设计功能、合并/拆分招标任务、改写任务名称——判定为未实质性响应将严重扣分甚至废标。

B-Step 2.6 — ⭐⭐双章判定：设计开发方案 vs 系统实施方案（红线十一，⭐必做）

评分表/技术规范书同时出现 "设计开发方案" 与 "系统实施方案" 两项时（系统开发类项目极常见），必须执行本步，详见 references/设计开发方案与系统实施方案双章写法.md：

1. 判定是否需要双章：逐条比对评分项名称，命中"设计开发/开发设计"与"系统实施/实施方案"两项各自独立存在 → 需双章。
2. 拆成两章：⛔ 不得合并为一章"技术与实施方案"。章标题须与评分项同名（评分项叫"设计开发方案"就写"设计开发方案"）。
3. 按方案名称归位内容（机械执行，不靠感觉）：

4. 对账打分表：双章要素并集须覆盖打分表全部评分点，每个评分点都要能落到某一章的具体小节。
5. 保证有区分：两章内容不得雷同。非功能性要求等交叉项，设计侧写"设计约束"、实施侧写"验证闭环"，⛔ 不得整段复制。
6. 产出：填入 assets/评分点-大纲对照表模板.md 第二节（含"归属方案"列）与双章对账表。

⚠️ 若评分表只含其中一项，则只写该章，⛔ 不硬造另一章；但该章要素必须齐全。

B-Step 2.7 — ⭐系统开发类：套用标准大纲（红线十三，⭐必做）

系统开发类项目在招标文件未另行规定章节结构时，⛔ 一律采用 references/系统开发类投标技术文件标准大纲.md：

1. 8 章骨架：现状分析 / 设计开发方案 / 项目管理 / 项目进度保障 / 软件能力成熟度模型 / 培训方案 / 售后服务方式与响应时间 / 风险防控与履约保障。
2. 第一章固定为「现状分析」，四个二级节：项目背景 / 需求分析 / 关键点与难点 / 项目目标。
3. 标题编号体系全文统一：一、（章）→（一）（节）→1.（条）→1.1（目）→1.1.1（细目）。⛔ 不得混编、不得用字号放大区分层级。
4. 逐章映射评分表：每章对应一个评分项，写入 assets/评分点-大纲对照表模板.md 第二节；未出现在评分表中的章（尤其"软件能力成熟度模型"）⛔ 整章删除。
5. 第二章内的开发任务编号：1. 一级任务名照录 → 1.1 二级功能名照录 → 1.1.1 实现 技术实现细项；实现点小节统一命名「×××实现」。

B-Step 2.8 — ⭐⭐需求分析三段式写作（红线十二，⭐必做）

第一章「（二）需求分析」按 references/现状分析与需求分析写法.md 执行，⛔ 不得跳项：

配套「（三）关键点与难点」写法：总述段 + 难点汇总表（难点名/维度/应对策略）+ 逐点"现状与问题 → 解决思路："两段式；⛔ 不得只列难点不给思路。⭐⭐ 系统实施方案（实施标段）的难点必须从实施角度写、与设计开发方案的难点区分（红线十九）：条目从 I1~I9 提炼（部署环境异构/数据源多口径校验/集成联调跨单位协同/上线切换窗口受限/建运平稳交接等），⛔ 严禁照抄设计开发方案的 D 类难点（多链底层逻辑统一、合约安全引擎、溯源性能精度、标注防篡改等），两份方案难点条目不得重名。

B-Step 3 — 技术规范书对齐（红线五）

方案引用的指标、性能要求、工作周期、任务名称必须与技术规范书一字不差。
模糊表述（"具备…能力""支持…扩展"）在本方案中必须给出明确技术定义，⛔ 不得把模糊留到验收变成风险点。

B-Step 4 — 逐章撰写正文

按大纲逐章写，每章结构：核心技术内容（分节展开）→ 可核查证据（表/图）。⭐⭐ 直陈方案本体（红线二十）：标题后第一段即方案实质内容——⛔ 不写"本章/本节介绍…"式概述段、⛔ 章末不写"本章响应小结"、⛔ 章节开头不引述技术规范书/评分表原文作铺垫；规范书要求由评分点—大纲映射整体覆盖，不单列复述再对应写方案。
- 章节骨架参考 references/信息化系统类技术标架构.md（系统类）或 references/咨询运维服务类技术标架构.md（服务类），但⭐评分表优先于骨架参考；系统开发类 ⭐优先套用 references/系统开发类投标技术文件标准大纲.md（红线十三）。
- ⭐第一章「现状分析」必须按 references/现状分析与需求分析写法.md 写，需求分析严格分政策/业务/管理三节（红线十二）。
- ⭐⭐全文禁用第一人称主语（红线十五）：⛔ 不用"我方/我司/本公司/本单位"作主语，⛔ 不强加主语，直接写方案内容与实施动作。写完后用 Ctrl+F 检索"我方""本公司"自检——技术方案正文应为 0 处（轨 A 应答体裁除外）。
- ⭐⭐表格一律宋体五号居中（红线十六）：由 build_bid_docx.py 自动实现，编写 markdown 时⛔ 不必也不应手工控制表内字号；表格内⛔ 不写"我方"，责任方列写"投标人/招标人/第三方"。
- 深度对标最优档次：写到"评委无需再问项目组即可确认满分"的程度。
- 偏离表由应答矩阵筛选派生，⛔ 不得另写。
- 以 assets/技术标应答骨架.md 为写作起点。

B-Step 5 — 生成 docx

# ⭐ --org 是【投标人】：用户未提供时一律写 XXXX公司 占位，⛔ 严禁填技术规范书里的项目单位
python scripts/build_bid_docx.py --input 技术方案.md --output 技术方案.docx \
    --title "××项目技术方案" --org "XXXX公司" --date "2026年10月"

⚠️ --org 填入招标人/采购人/建设单位名称时，脚本会打印错误并退出、不生成文件（红线十）。
⚠️ 脚本检测到正文含"我方/我司/本公司/本单位"时，会打印行号与片段告警（红线十五），须逐条改写为无主语陈述后再进入门禁。
⭐⭐ 目录默认生成（红线十八）：脚本在封面之后、正文之前自动插入「目　录」页（宋体加粗居中 + Word TOC 域，收录 一、/（一）/1. 三级标题），并写入 updateFields，Word 打开时提示更新域选「是」即补齐条目与页码。⛔ 不得在 markdown 里自行写"目录"章节。可选参数：--no-toc（关闭，仅限招标文件明确要求不设目录）、--toc-depth 5（收录到五级标题）。

B-Step 6 — 交付前门禁（必跑）

第一步：格式统一核验（红线十七，⛔ 不得跳过）

python scripts/verify_bid_docx.py 技术方案.docx --format-only

逐项核对报告末尾的 L 组 14 项清单，任一 ✗ 即返工。⚠️ 脚本通过 ≠ 格式合格，另须人工确认：目录页条目与页码已在 Word 中更新出来、每张表有表题且在表上方、每张图有图题与"阅读要点"段、无单行内容独占一页、章节标题与评分项名称一致、无章首概述段/章末响应小结/引述招标原文铺垫（红线二十）。

第二步：完整门禁

python scripts/verify_bid_docx.py 技术方案.docx --scoremap 评分点-大纲对照表.md
# 双章项目（设计开发方案 + 系统实施方案）追加 --dual，启用 H 组要素齐全与章节错位核验：
python scripts/verify_bid_docx.py 技术方案.docx --scoremap 评分点-大纲对照表.md --dual

核验十四组：A 页面（A4/上下25.4/左右31.8mm）/ B 字体字号（⭐正文与标题均宋体小四 12pt，标题加粗、正文不加粗、禁斜体下划线）/ C 段落（⭐全文 1.5 倍行距、正文首行缩进 2 字符）/ D 结构 / E 内容合规 / F 评分点覆盖 / G 封面（⭐封面投标人单位合规，占位符报 WARN）/ H 双章（--dual：D1~D4、I1~I9 要素齐全与章节归属，错位或整段重复报 FAIL）/ I 需求分析（⭐红线十二：需求分析须分「政策需求/业务需求/管理需求」三节，缺项报 FAIL；出现自创小节报 WARN）/ J 表格格式（⭐红线十六：逐单元格核验宋体五号 10.5pt + 居中，表首行加粗、表内容不加粗）/ K 称谓（⭐红线十五：检出"我方/我司/本公司/本单位"报 FAIL）/ M 目录（⭐红线十八：须有「目　录」标题段 + Word TOC 域 + 标题大纲级别，缺一报 FAIL）/ N 直陈（⭐红线二十：检出"本章/本节介绍…"式章首概述段、"本章响应小结"式收尾段、章节开头引述技术规范书/评分表原文作铺垫即 FAIL）/ L 版式统一清单（报告末尾逐项输出 ✓/✗）。退出码 0 = 无 FAIL。有 FAIL 禁止交付；加 --strict 时 WARN 也视为不通过。

B-Step 7 — 交付四项报告

评分点覆盖度（逐项：分值/落点章节/篇幅偏差/档次判定，双章项目须标注归属方案）/ 规范书一致性（引用指标与原文核对结果）/ 待补清单（占位符及所属章节，须含 XXXX公司 投标人占位）/ 风险提示（可能掉档或废标的点）。⛔ 不得省略。

另须附「格式统一核验结论」：L 组 14 项逐项 ✓/✗ + 人工确认项（目录条目与页码已在 Word 中更新、表题、图题、阅读要点、单行独占页、章节标题对齐、无章首概述/章末响应小结/引述规范书铺垫）确认结果。⛔ 不得以"格式已按脚本生成"代替结论。

三、轨 A 版式（实测固化，⭐ 最高优先级）

完整规格见 references/技术规范书逐条应答格式规范.md（全部数值实测，勿擅改）。

页面  A4 210×297mm；上/下 25.4mm，左/右 31.8mm（默认 Word 页边距）；页眉页脚均空白
行距  全文 1.5 倍行距
缩进  招标原文段与应答段均首行缩进 2 字符

⭐ 核心：凡"应答"内容（结论句 + 展开正文 + 表格内投标人响应列），一律黑色 + 加粗 + 单下划线 + 宋体 12pt。 招标原文保持常规格式，绝不加粗加下划线——否则评委无法对读。

⭐ 格式镜像（红线六）：应答文件的章节标题与编号形式一律照录原技术规范书；原文用 （1）（2）（3） 的，应答沿用 （1）（2）（3），⛔ 不得写成"一是/二是/三是"。

⭐ 表格整块规则（红线七）：表格原样整表照录 + 表后一个总结式应答块，⛔ 不拆行拆列逐条应答、⛔ 不为每行单写"应答：理解并满足。"。详见 A-Step 2.1。

⭐ 扩充幅度（红线八）：应答展开控制在对应招标原文的 1.2~1.4 倍，⛔ 不加演原文没有的技术细节。

⚠️ 轨 A 与轨 B 页边距/行距虽同为默认值，但标题字号、应答段格式（加粗+下划线）、结构逻辑完全不同，⛔ 不得混用于同一文件。

四、轨 B 版式（⭐ 2026-10-12 用户指令固化，勿擅改）

完整规格见 references/投标技术标版式规格.md。

页面  A4 210×297mm；上/下 25.4mm，左/右 31.8mm
行距  ⭐全文 1.5 倍行距
缩进  ⭐正文首行缩进 2 字符
字号  ⭐正文与各级标题同为宋体小四 12pt

⭐⭐ 目录（红线十八，2026-10-15 用户指令固化）：技术方案 ⛔ 必须设目录页，位于封面之后、正文之前。
- 由 build_bid_docx.py 默认生成：「目　录」标题段（黑体 16pt 加粗居中）+ Word TOC 域 TOC \o "1-3" \h \z \u。
- 各级标题段落内置 w:outlineLvl（一、=0 /（一）=1 / 1.=2 /（1）=3 / 1.=4），这是 TOC 域识别层级的前提，⛔ 手工造标题会丢失该属性。
- 文档 settings.xml 写入 updateFields=true，Word 打开时提示"更新域"选是即自动生成条目与页码；⛔ 不得把未更新的空目录交付。
- 收录层级默认 3 级（一、/（一）/1.）；需 5 级用 --toc-depth 5；仅当招标文件明确要求不设目录时才用 --no-toc，并须在交付报告中说明。

⭐⭐ 表格文字统一（红线十六，2026-10-14 用户指令固化）：表内所有单元格（含表首行）一律 宋体五号 10.5pt + 居中；表首行额外加粗，表内容不加粗。⛔ 不再区分表首行与表内容的字号/对齐。

⭐⭐ 正文称谓（红线十五，2026-10-14 用户指令固化）：技术方案正文按正常方案编制模式输出，⛔ 不用"我方/我司/本公司/本单位"作主语，⛔ 不强加主语。
- ✅ 采用微服务架构，按等级保护三级设计数据加密机制。
- ⛔ 我方采用微服务架构，满足等保三级要求。
- ✅ 上述要求全部前置为设计输入，在概要设计阶段同步输出五大架构视图。
- ⛔ 我方将上述要求全部前置为设计输入。
⚠️ 轨 A（逐条应答）的"我方理解并满足…"是范本实测格式（红线十四），不在本条约束范围。

⭐⭐ 交付前格式统一核验（红线十七）：交付前必跑

python scripts/verify_bid_docx.py 技术方案.docx --format-only

脚本报告末尾输出 L 组 13 项版式统一核验清单（A4/页边距/无页眉 logo/正文小四/表格五号居中/1.5倍行距/首行缩进2字符/禁斜体下划线/第一人称主语0处/目录页存在/封面主体），任一 ✗ 即返工。完整清单见 references/投标技术标版式规格.md 第五之二节。

⭐ 标题层级只靠加粗与编号区分，⛔ 不用字号放大；⛔ 正文不得加粗、禁斜体下划线。
招标文件另有版式规定时，一律服从招标文件（红线三），必要时用 --h1-size 覆盖一级标题字号。

⭐⭐ 封面主体铁律（红线十）：封面第二行固定为 投标人：XXXX公司。
- --org 必须是投标人/投标单位；⛔ 严禁填技术规范书里的项目单位、招标人、采购人、建设单位、业主。
- 投标人名称未知 → 一律写 XXXX公司 占位（⛔ 不留空、⛔ 不写 ××公司、⛔ 不照抄招标文件单位名）。
- 项目名称来自招标文件（照录），投标人名称来自用户——两者来源不同，⛔ 不得混填。
- 详见 references/封面主体信息规范.md；build_bid_docx.py 已内置拦截（填招标人直接退出不生成文件）。

⭐⭐ 双章结构（红线十一）：评分表同时含"设计开发方案"与"系统实施方案"时必须分两章，不得合并。设计开发方案 = 系统架构 + 技术路线 + 非功能性要求（设计侧）+ 信息安全集成需求分析 + 开发任务五段式；系统实施方案 = 差异分析及方案设计 + 数据收集及处理 + 系统部署及配置 + 系统集成 + 系统测试 + 上线准备及切换 + 上线试运行支持 + 系统建转运 + 非功能性要求（实施侧）。两章并集覆盖全部评分点，⛔ 内容不得雷同。详见 references/设计开发方案与系统实施方案双章写法.md。

五、系统开发类：开发内容写法（⭐ 轨 B 重点）

系统开发/软件建设/平台建设类项目必须执行，完整规则见 references/系统开发类方案-开发任务清单写法.md。

1. 开发内容必须围绕招标文件给出的开发任务清单（或功能清单）编写，⛔ 严禁自行设计功能、合并或拆分招标任务、改写任务名称。
2. 一任务一节，小节标题 = 招标任务名称照录，便于评委逐行核对。
3. 每项任务按五段式展开，⛔ 不得缺段：

1 功能定位  职责、解决什么问题、回指任务号
2 输入输出  ⭐表格化（字段/报文级），⛔ 禁止"接收数据""输出结果"式空话
3 技术实现  ⭐落到模块/接口/表/算法层面，说明为何适合本任务，⛔ 禁堆通用词
4 异常与边界  并发/超时/断链/数据缺失/重复提交的处理与补偿
5 交付与验收  交付物 + 量化验收判据 + 周期

4. 章末出开发任务清单响应总表（任务号 → 章节 → 交付物 → 周期），作为全覆盖的直接证据。
5. 篇幅最大的章节通常是"功能/模块设计"（常见占技术分 40%~60%），⛔ 不得把主要篇幅给架构图。

六、交付要求与资源索引

交付时必须显式包含：轨 A 报覆盖率/指标核对/待补清单/风险提示，并说明各表格型条款的应答方式为"整表照录 + 表后单一应答块"；轨 B 报评分点覆盖度（逐项分值/落点章节/篇幅偏差/档次判定）、规范书指标一致性、待补清单、风险提示。⛔ 不得省略。

常见触发语——轨 A："根据技术规范书逐条应答""服务内容逐条逐项应答""格式照这个范本"；轨 B："编制投标技术标""根据招标文件写技术方案""按评分表/评标办法组织大纲""按开发任务清单写开发内容""做技术偏离表"。

七、与既有技能的边界

⛔ 同一文件内严禁混用两套版式；投标文件绝不使用公文版式或行标母版。