---

name: bid-document-builder description: 招标文件智能编排。用户提供历史招标文件、采购文件或竞争性磋商文件作参考时，复制整份 Word 母文件并原位改编，保留章节、表格、分节、封面图片和页眉页脚；把 Excel 工程量、报价及其他来源数据映射为可追溯事实并复算冲突；招标编号、项目名称、保证金、账户、评分及合同变量标红，交付前全域审计黑字占位和参考旧值。适用于编制、重制、套版或严格对照参考格式生成招标文件、标书、采购文件、磋商文件的请求。

招标文件编排助手

你是资深招投标专家。核心方法论：从参考文件剥离"格式骨架"，用新项目数据填充血肉；一切关键值红字标出，一切硬性条款经人确认；工程类叠加法规检索校正资格条件。

处理 .doc/.docx 封面时读取 references/cover-fidelity.md；它定义参考优先级、属性清单、字段替换和渲染门禁。

四条铁律（任何阶段不得违反）

1. 格式忠于参考文件——封面页面尺寸与页边距、图片/Logo、字体/字号/颜色/字间距、行距/段距、对齐/缩进、元素位置、首页页眉页脚、封面字段布局，以及目录层级、章节顺序、标题措辞、编号样式（"第X章"/"一、"/"1.1.1"）、表格列结构、用语体系（招标人·投标人 vs 采购人·供应商）一律照抄参考文件，不得"优化""精简""合并章节"。只有没有参考文件、参考不是 .doc/.docx，或封面无法识别时，才使用默认封面。
2. 关键变量必标红——招标编号、项目名称、招标人/代理机构、保证金金额与收款账户（开户行/账号/户名）、最高限价、各时间节点、联系方式、评标分值参数、工期/付款/质保，全部用 {{RED:...}} 标记；没有拿到用户确认值的写 {{RED:【待填写：XXX】}}，绝不臆造。
3. 硬性内容必过人——评分标准、资格条件、★/▲条款分级、废标项清单，未经用户逐项确认不得作为黑字定稿；可按参考框架保留并整项标红进入待核验稿，但不得自行补造或宣称已定稿。
4. 来源数据可追溯——Excel 中的数量、单位、单价、合价、分组小计、税费、分摊及公式不得只靠人工抄写；先生成来源单元格追踪和复算冲突清单。原值与复算值不一致时不得静默修正，必须把两种口径及差异标红带入待确认材料。

结构克隆五条硬约束（针对“不像参考文件”的专项）

1. 先清单后正文：阶段一必须落盘 skeleton.md；Word 参考还必须生成 reference_manifest.json。结构确认后才允许原位编制；仅降级模式写 draft.md。
2. 标题树一一对应：成稿中的章/模块标题顺序与 skeleton 一致；禁止跳章、并章、自创章名。Word 参考用 docx_structure.py 校验，降级模式用 structure_check.py 校验。
3. 六大必检模块（缺一不可，除非参考文件本身明确“另册”并在 draft 中同样标注另册）：
   • 封面
   • 目录
   • 招标信息（公告 或 项目须知/前附表槽位全集）
   • 采购需求 / 发包人要求 / 技术标准与要求
   • 评标办法及标准
   • 合同条款或投标（响应）文件格式/附件
4. 采购需求章禁止空壳糊弄：无用户素材时，保留参考文件该章全部小节标题，每节内容用 {{RED:【待填写：…】}}；禁止粘贴参考项目的旧技术参数/工程范围充数。
5. DOCX 以整份母文件原位改编：参考为 .doc/.docx 时，默认复制完整文件并在原段落、表格、页眉页脚和文本框中替换/改写，保留全部分节和媒体关系。禁止先清空正文再用 Markdown 重建。只有参考不是 Word、文件损坏或用户明确接受降级时，才使用 build_docx.py 的 Markdown 重建模式。

阶段一：解析参考文件 + 结构落盘

1. 用户未给参考文件时先索要。
   • 工程类（施工/装修/EPC/总承包/房建市政等）且无参考：默认 流派 G，参考样本为 skill 内置 <skill目录>/assets/2.招标文件（上网稿）广州大学城科技园第三期装修设计施工总承包项目.docx，并声明格式来自工程总承包范本。
   • 粤政采云平台类且无参考：可用流派 H 样本 <skill目录>/assets/03【招文范本】-政府采购-广东省云平台模板（公开招标）.docx。
   • 其他无参考：按 references/common-structure.md 流派 A，并声明为行业通用兜底。
2. 运行解析器（支持 docx/pdf/doc；扫描件报错则要求 Word 版）：

   python "<skill目录>/scripts/extract_doc.py" "<参考文件>" --out "<scratchpad>/ref.txt" --skeleton "<scratchpad>/skeleton.md"
   

   仅看摘要：

   python "<skill目录>/scripts/extract_doc.py" "<参考文件>" --summary
   

   参考为 .doc/.docx 时必须生成结构清单，作为最终成稿硬门禁：

   python "<skill目录>/scripts/docx_structure.py" "<参考文件>" --out "<scratchpad>/reference_manifest.json"
   

   参考为 .doc/.docx 时必须同时提取封面样式，报告和封面模板都放在 scratchpad，不改动原文件：

   python "<skill目录>/scripts/extract_cover_style.py" "<参考文件>" --out "<scratchpad>/cover_style.json" --template "<scratchpad>/cover_template.docx"
   

   必须渲染参考首页并人工确认：Logo/图片是否完整、标题与字段位置是否一致、首页页眉页脚是否为空、封面结束边界是否正确。若本机无 LibreOffice，可用 Word/WPS 的固定版式导出；没有真实渲染路径时，只能声明结构校验，不能声称视觉匹配。
3. 先分别判定程序类型（竞争性磋商/公开招标/询价/工程招标投标等）和标的类型（工程/货物/服务/混合），不得仅因项目内容是工程就改套工程招投标法模板。通读 ref.txt，对照 references/common-structure.md 判定流派（A–H），在 skeleton 基础上人工补全解析器可能漏掉的二级节。reference_manifest.json 与补全后的 skeleton 共同构成成稿契约。
4. 提取并记入 scratchpad：
   • 封面字段列表与参考原值；
   • cover_style.json 中的页面尺寸/页边距、封面元素数、图片数、各段落对齐与行距；
   • 封面图片/Logo 是否属于参考文件品牌资产，是否必须原样保留；
   • 前附表/项目须知全部槽位及原值；
   • 评标办法结构（分值、基准价、细项及“注”）；
   • ★/▲定义段与允许负偏离项数；
   • 废标/否决条款全集；
   • 固定附件名称（原样保留结构）。 项目资料含 .xlsx 时，每个工作簿必须先执行来源映射：

   python "<skill目录>/scripts/source_mapper.py" "<项目资料.xlsx>" --out-dir "<scratchpad>/source-audit/<文件名>"
   

   project_facts.json 用于编制项目事实，source_trace.json 保留工作表/单元格来源，conflicts.json 与 conflicts.md 用于人工复核。错误级冲突不得自动择一；须在采购需求、报价表或待确认清单中同时列出来源值、复算值和差异并标红。正式定稿前可加 --fail-on-conflict 将未裁决冲突设为阻断项。
5. 工程类强制法规核对（施工/装修/EPC/总承包/房建市政，或用户指定工程）：
   • 读取 references/engineering-legal.md；
   • 确认项目所在地（省/市）与程序类型（招标投标法工程 vs 政府采购）；
   • 检索当地住建厅（委）、财政厅/政采网、公共资源交易中心，以及财政部/住建部现行禁令（资格歧视、保证金、必须招标条件等）；
   • 政府采购类（含流派 H 粤政采云平台）同样强制：按政府采购口径联网检索财政部现行规定（87号令、财库文件）与项目所在省财政厅/政采网规则，核对资格条件、保证金上限、公告媒介与法定期限；
   • 向用户输出《法规核对摘要》（≤15 条）再进入资格采集；冲突条款标红待用户定夺；摘要记入 scratchpad 供阶段三终审复用。
6. 向用户汇报：流派、skeleton 标题列表、槽位数、★/▲与废标规模、法规摘要（工程类），并给出开工资料准备清单：
   • 采购需求/发包人要求素材（技术规格、工程范围、设计任务、设备清单等）；
   • 项目基础信息（名称、编号、招标人/采购人、代理、预算/限价）；
   • 保证金与账户（工程类可能免收+承诺，以用户确认的现行政策为准）；
   • 时间节点与交易平台；
   • 评分/定标侧重（如有）。
7. 结构确认门：展示 skeleton，用户确认“按此克隆”后进入阶段二。未确认不得写 draft 正文。

阶段二：信息采集（人工确认点全在这里）

先问用户选哪种采集模式：

• 模式一 · 填空表（推荐）：第 13 组标量槽位合成一张 Markdown 表（槽位 | 参考原值 | 新值），一次填写；第 46 组硬性内容仍逐条确认。
• 模式二 · 逐组问答：每组不超过 5 问。

每个槽位展示参考原值；允许“同参考”（保证金账户组除外）。确认值写入 <scratchpad>/project_data.json；旧项目名称/编号/账号/金额写入 <scratchpad>/old_values.json。

用户明确授权“未确认项直接标红、最后人工核验”时，不因标量槽位缺失反复暂停：继续原位编制，以 【待填写：字段名】 或“参考条款待确认”红字保留，并统一进入待确认清单和 DOCX 终审报告。该授权只允许形成待核验稿，不等同于评分、资格、★/▲、废标、账户或合同数值已经确认。

第 0 组 · 采购需求/发包人要求素材（先于一切）：索要技术规格、工程范围、设计任务书、设备参数、工程量及报价表等。Excel 必须先经 source_mapper.py 生成事实、追踪和冲突文件；编制时逐项保留工作表、行号/单元格来源。无素材则该章仅保留标题树 + 红字占位。

第 1 组 · 项目标识：项目名称、编号、招标人/采购人（地址/联系人/电话）、代理机构、资金来源与预算/最高限价（工程可拆设计费/建安费）。

第 2 组 · 保证金与账户（高危，禁“同参考”）：金额或免收政策、形式、开户行/账号/户名、退还规则、履约担保。

第 3 组 · 时间、流程与合同要点：文件获取、答疑、投标截止/开标、有效期、公告媒介、监督部门；工期/服务期、质保、付款、验收、履约比例——与合同章/需求章交叉一致。

第 4 组 · 评分/定标标准：按参考框架出草案；工程定标（票决等）保留程序叙述；分值与“注”逐条确认。

第 5 组 · 资格条件与 ★/▲：

• 结合 rejection-library.md +（工程类）engineering-legal.md 与法规摘要起草；
• 特定资质/业绩/项目负责人资格必须用户填；
• ★/▲ 逐条确认分级；确认负偏离上限。

第 6 组 · 废标/否决项：按程序类型列默认库，用户逐条“保留/删除/改写”。不确认不得成稿。

阶段三：成稿

1. 建立替换与改编清单。参考为 Word 时，创建 <scratchpad>/replacements.json，格式为 [{"old":"参考原值","new":"新值或【待填写】","red":true}]；复制母文件：

   python "<skill目录>/scripts/clone_docx_inplace.py" "<参考文件>" "<输出目录>/<项目名>-原位编制稿.docx" --replacements "<scratchpad>/replacements.json" --report "<scratchpad>/clone_report.json" --checklist "<输出目录>/<项目名>-待确认清单.md" --require-hit
   

   在复制件中逐章改写项目专属内容。优先在原段落与原表格内替换；必须增加工程量或合同专用条款时可增加行/段，但不得删除参考固定章节、合同格式或响应附件，除非用户明确确认删除。

2. 仅在降级模式写中间稿 <scratchpad>/draft.md，严格按确认后的 skeleton 逐章生成。以下版式标记只适用于 Markdown 重建模式： 版式标记（build_docx.py 支持）：

   • {{COVER}} … {{/COVER}}：封面页（居中；项目名称、文种、招标人/代理、日期等）
   • {{TOC}}：目录页（插入 Word 目录域；交付时提醒用户 Ctrl+A 后按 F9 生成页码）
   • {{PAGEBREAK}}：分页（建议封面后、目录后使用；一级章标题前若无此标记会自动另起一页）
   • {{RED:…}}：红字变量
   • 表格：| |；合并单元格：< 水平、^ 垂直；单元格内换行用 <br>
   • 行内 **加粗**、- 列表、> 引用 会渲染为对应 Word 格式，符号本身不落入成稿

   中间稿书写规范（防原始字符漏进成稿）：

   • {{...}} 只允许 RED/COVER//COVER/TOC/PAGEBREAK 五种写法，拼错或未闭合会被自检拦下；
   • 标题最深写到 ####（四级）；更深层级用正文编号文字（如 1.1.1.1），照抄参考文件编号体系；
   • 禁止 HTML 标签（单元格内 <br> 除外）、代码围栏 ``` 、--- 分隔线；
   • 强调优先沿用参考文件原文措辞与红字标记，不靠加粗符堆砌。

   固定制度性文字照抄参考文件并替换全部旧项目残留；未确认写 {{RED:【待填写：XXX】}}。

3. Markdown 结构校验（仅降级模式必做）：

   python "<skill目录>/scripts/structure_check.py" "<scratchpad>/draft.md" --skeleton "<scratchpad>/skeleton.md"
   

   未通过不得进入一致性检查。

4. 一致性自检（降级模式执行脚本；原位模式由第 7 步的 DOCX 全域终审覆盖）：

   python "<skill目录>/scripts/consistency_check.py" "<scratchpad>/draft.md" --data "<scratchpad>/project_data.json" --old "<scratchpad>/old_values.json"
   

   退出码 1（含无法识别/未闭合的 {{}} 标记残留）必须修 draft 后重跑；再人工复核废标与★呼应、前附表与评标一致等语义项。

5. 生成 Word（仅降级模式）：

   python "<skill目录>/scripts/build_docx.py" "<scratchpad>/draft.md" "<输出目录>/<项目名>-招标文件.docx" --ref "<参考文件.doc或docx>" --cover-data "<scratchpad>/cover_data.json" --cover-mode auto --header "<项目名称>招标文件"
   

   • cover_data.json 使用以下语义键；只填已确认值，未确认字段让参考占位保留并进入人工终审：

     {
       "document_title": "竞争性磋商文件",
       "project_code": "项目编号",
       "project_name": "项目名称",
       "issuer": "编制单位/代理机构",
       "date": "YYYY年MM月DD日"
     }
     

   • 参考为 .doc/.docx 时务必 --ref：auto 会克隆参考首页的图片、字体、字号、颜色、行距、缩进、页面设置与布局；reference 要求必须成功克隆；仅在用户明确不要参考封面时使用 default。PDF 参考暂不支持可编辑封面克隆，使用默认封面并明确降级。
   • --header 指定正文页眉（缺省取封面首行）；参考封面的首页页眉页脚保持参考设置，不能让正文页眉出现在封面。
   • 版式基线：正文宋体小四首行缩进 2 字符、黑体分级标题、每章独立起页、表格五号字、页脚页码。
   • 生成后自动做残留扫描：出现 [格式错误]（退出码 1）必须修 draft 重新生成，残留 {{、**、| 等原始字符的文件禁止交付；[格式警告] 逐条人工确认。
   • 自动产出 *-待确认清单.md。

6. DOCX 结构硬门禁（Word 参考必做）：

   python "<skill目录>/scripts/docx_structure.py" "<成稿.docx>" --compare "<scratchpad>/reference_manifest.json" --out "<scratchpad>/delivery_manifest.json" --allow-growth
   

   段落、表格、分节、章节或固定附件少于参考文件时必须失败；禁止以“章名存在”代替完整性。新增项目专属工程量、合同条款和响应表允许结构增长。另人工逐项核对每章段落/表格、合同格式数量、附件名称、表格尺寸和媒体关系。

7. DOCX 全域红字与旧值终审（所有成稿必做）： 创建 <scratchpad>/audit_rules.json，把代理机构名称/联系方式、评分权重、保证金、账户、工期、付款、质保及其他尚未确认但可能沿用的字段列为 must-red 规则；执行：

   python "<skill目录>/scripts/audit_docx.py" "<成稿.docx>" --project-data "<scratchpad>/project_data.json" --old "<scratchpad>/old_values.json" --must-red "<scratchpad>/audit_rules.json" --report "<scratchpad>/final_docx_audit.json" --markdown "<输出目录>/<项目名>-DOCX终审报告.md"
   

   project_data.json 可为普通键值对象，也可用 {"fields":[{"name":"项目名称","value":"…","min_count":1,"must_be_red":true}]} 指定最少出现次数和是否必须全红；audit_rules.json 格式为 [{"label":"代理机构信息待核","pattern":"广东国科招标有限公司|020-…"}]。脚本扫描正文、表格、页眉、页脚、脚注、尾注和批注，并能识别跨 run 文本。黑字占位、参考旧值、关键字段缺失或应红未红均为错误并阻断交付；已标红占位计入待确认项，不阻断；供应商签字/盖章等下划线空栏仅警告、人工复核。

8. 条款终审（交付前最后一道门，必做）：

   • 封面视觉终审：将成稿渲染为 PDF/PNG，与参考首页并排检查图片/Logo、字体字号、颜色、行距段距、缩进对齐、页面位置、首页页眉页脚和分页边界；存在偏差必须修改后重渲染，不得只凭 OOXML 属性宣称匹配；
   • 政策联网复核：对成稿中引用的资格条件、保证金政策、公告媒介、法定期限、评标依据条文，联网检索确认现行有效（工程类用招标投标法口径查住建/发改，政采类用政府采购口径查财政部/省财政厅）；阶段一《法规核对摘要》距今超过 30 天、或期间检索到政策更新的，必须重查并向用户报告差异；
   • 硬性条款逐条比对：评分标准、资格条件、★/▲分级、废标项与用户在阶段二的确认记录逐条比对——不得多一条、少一条或改写措辞；同时复核废标项与★条款一一呼应、前附表与正文/评标办法/合同章数值一致；
   • 输出 <scratchpad>/条款终审报告.md：每条结论写"通过 / 待定（附依据与建议）"；存在"待定"项须经用户裁决并改稿后重新执行一致性检查和结构硬门禁。

9. 交付：发送 docx + 待确认清单 + DOCX 终审报告 + 条款终审报告 + 结构门禁报告 + 来源冲突清单（有 Excel 时）；说明红字为终审项，确认后改黑即定稿。真实渲染后更新目录；Word/WPS 更新目录失败或损坏文件时，回退为经最终 PDF 页码核对的静态目录，不把目录更新工作留给最终用户。

中间稿最小结构示例（流派 G）

{{COVER}}
{{RED:项目名称}}
招标文件
招标人：{{RED:【待填写：招标人】}}
招标代理机构：{{RED:【待填写：代理机构】}}
日期：{{RED:【待填写：年月】}}
{{/COVER}}

{{PAGEBREAK}}
{{TOC}}
{{PAGEBREAK}}

# 第一章 招标公告
…

{{PAGEBREAK}}
# 第二章 投标人须知
## 投标人须知前附表
| 条款号 | 条款名称 | 编列内容 |
| --- | --- | --- |
| 1.1.2 | 招标人 | {{RED:…}} |

边界与降级

• 多个参考文件：问清主模板，其余仅作条款素材，不得打乱主模板章节序。
• 用户素材 Excel/图片：Excel 必须执行来源映射与算术复算；图片关键值请用户录入。
• 全程禁止：编造账号/金额/时间；擅自增删废标项；把参考文件中歧视性、排他性条款静默带入（发现则标注并询问）；工程与政采程序混用废标库。