# Bid Document Builder

> 完整投标、响应、陪标或磋商文件的唯一流程主控。用于用户提供采购或招标文件并要求编制包含资格、商务、报价、技术、附件和评分索引的整套提交材料；负责权威来源、否决项、目录结构、跨册一致性和最终合稿。只要求技术标时由 bid-technical-proposal 主控，独立功能级报价由 archive-quotation-builder 主控，Word 载体由 documents 完成。

- Skill: `wjjjjjjjjjjj/bid-document-builder` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add wjjjjjjjjjjj/bid-document-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wjjjjjjjjjjj/bid-document-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: wjjjjjjjjjjj (https://skillmd.com/u/wjjjjjjjjjjj)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/wjjjjjjjjjjj/bid-document-builder

---


# 投标/陪标文件全流程编写

> 本 skill 沉淀自档案信息化类政府采购（竞争性磋商）投标文件的完整编写实践，目标是：用户给出招标文件与参考资料后，形成一份结构完整、证据可追溯，并在通过提交门槛后可用于正式投标的响应文件 .docx。

---

## 零、V2 主控边界与规则优先级

完整投标/响应文件只由本 skill 主控一次。本 skill 负责材料总控、资格商务、报价、整本顺序、评分索引、
最终合稿与提交检查；技术部分调用 `bid-technical-proposal`，复用其 `source_register.json`、
`technical_traceability.csv`、`commitment_register.csv` 和 `qa_report.json`，不再另建一套技术要求清单。

若请求只涉及技术标、功能/参数响应、技术评分项、技术标审查或评分更正后的技术章节修订，则把主控权交给
`bid-technical-proposal`，本 skill 不继续生成资格、商务和报价章节。

正式投标/提交版发生格式冲突时按以下顺序执行：

`最新有效的招标文件/响应模板 > 用户的视觉偏好 > 本 skill 整本规范 > bid-technical-proposal 中性技术标默认规则`。

用户可以明确要求制作偏离模板的内部草稿或评审稿，但必须标注“非提交版”，不能同时标记为满足正式
提交格式。

技术内容的真实性、证据、承诺、偏离和提交门槛以 `bid-technical-proposal` 为准；整本文件的章节顺序、
分册、商务资格、报价和最终样式以本 skill 为准。

---

## 一、铁律（不可违反）

1. **不编造，主张必须可追溯。** 公司、人员、证书、案例、金额、产品能力、性能、SLA、工期、资源和量化收益均须有来源或批准记录。工作稿可保留结构占位；审查草稿只允许保留已登记、有责任人的待确认项；提交候选版所有必填字段、内部占位和待确认标记必须为 0。
2. **陪标/保护性信息约束。** 文件中不得出现任何与"我方实际公司"相关、可识别的名称、产品名、案例、人员信息（除非用户明确提供陪标方材料）。所有公司信息严格按用户提供填写，或留空。
3. **模板优先。** 有招标模板时完整继承其页面、字体、颜色、编号和表格规范；无模板时才使用黑色中性投标样式，不默认套企业品牌色。
4. **表格服从模板且只承载行列数据。** 无模板时使用单线边框、白底表头的中性样式；甘特图可用表格表达，复杂架构和流程不得用表格冒充图示。
5. **功能点点对点响应。** 采购需求功能清单的每个功能点逐条响应，不做总结性归纳；带多个子功能的，每个子功能单独描述。
6. **★/▲/#/* 等标记条款全覆盖。** 招标文件中所有带特殊标记的重要技术条款必须逐条响应、不遗漏，并标注需提供的证明材料；建议单列一张"重要条款（#项）专项响应表"。
7. **评分标准逐项响应。** 评审标准的每个评分项都要在文件中有对应内容并能被定位（见评分索引表）。
8. **日期统一。** 所有日期占位默认填"响应文件提交截止日"（向用户确认具体日期）。
9. **致函抬头用实际单位名。** "致：采购人或采购代理机构"等泛称，替换为招标文件中的采购人名称、采购代理机构名称。
10. **技术方案按得分条件配置内容。** 先服从页数和格式限制，再按“分值 × 满分条件复杂度 × 履约风险”分配篇幅；用项目化方法、证据、边界、责任和验收口径体现深度，不用固定字数或重复注水体现深度。
11. **方案标题与评分标准逐字对齐。** 编写技术方案、实施方案、售后服务方案等各评分章节时，章节标题必须与评分标准中对应评分项、评分子项的表述保持完全一致（用词、顺序均一致），不得自行改写、合并、增删或新造名称。例：评分项为"软件系统技术方案"、其评审内容列明"①系统总体技术架构与网络部署结构②数据架构方案③档案组件设计方案④系统的功能模块设计方案⑤系统集成与平台对接方案"，则方案须以"软件系统技术方案"为章节标题，并逐字采用上述五个子项作为子章节标题。目的：让评审专家能按评分表逐项对号入座、不漏评不误评，主观分尽可能拿满。

---

## 二、输入材料

- **必需**：招标文件 / 竞争性磋商文件（.docx/.pdf）。
- **必需**：评分标准（通常在招标文件第三章"评审方法和评审标准"）。
- **建议**：成品软件/第三方产品资料、产品功能清单、历史标书、格式模板。
- **需向用户确认**：报价总价及固定分项（如 CA、OFD 等成品软件单价）、交付形态、功能响应颗粒度、提交截止日期。

权威招标材料按 `bid-technical-proposal` 的来源登记和追踪矩阵规则处理：摘要只用于导航，评分项、否决项、
技术要求、重要条款和格式要求必须保留原文定位，不能被有损摘要替代。不得对权威采购材料调用会丢弃原文、
限制事实条数或禁止回查原件的压缩工作流。历史标书、产品白皮书等辅助材料可压缩摘要，但不能自动升级为
本项目事实或承诺。`doc-token-saver` 不得接管招标文件、澄清/更正、评分表、响应模板和合同条款；即使为控制
上下文建立导航摘要，也必须保留原件、版本、页码/条款定位和回读入口。读取与转换文件时加载对应 PDF/文档技能。

---

## 三、工作流程

### Phase 1　研读招标文件，建立整本评分总索引与技术追踪入口
1. 提取：项目名称/编号/包号、采购人、代理机构、预算、工期、资格要求、保证金、响应有效期、份数、提交截止时间。
2. 提取**评分标准表**：逐项记录"评分因素 / 分值 / 评分规则 / 需提供的证明材料"。
3. 在本阶段即加载 `bid-technical-proposal`，由其原子化采购需求功能清单、技术评分行和所有 ★/▲/#/* 技术条款，并生成 `technical_traceability.csv`；本 skill 不再建立第二套技术条款编号或状态。
4. 提取**第六章"响应文件格式"**的全部实质性格式文件清单与顺序。
5. 建立整本映射表：`评分项 → 文件章节 → 响应策略`。其中技术评分行引用技术追踪矩阵 ID，资格、商务、报价项由本 skill 维护。

### Phase 2　关键澄清
默认按招标文件推断交付形态、分册方式和逐条响应颗粒度并继续推进。只有报价、提交日期、暗标/分册或
其他答案会实质改变结果且无法从材料发现时，才先给最可能正确的假设，再询问一个关键确认项。

### Phase 3　商务·资格·报价
- **格式化章节**严格按招标文件规定的顺序与格式编写。合同、采购需求或技术偏离只有经过逐项核验后才能写“无偏离/完全响应”；无法确认的内容进入偏离与未决事项清单。工作稿可保留结构占位，审查草稿只保留已登记待确认项，提交候选版必须全部关闭。
- **报价总控**：本 skill 负责招标模板中的报价文件组成、税费/币种/单位口径、总价、固定分项、商务承诺和整本一致性；任何未知金额、税率、优惠或付款条件不得推断。
- **功能级报价子流程**：只有需要档案功能清单造价分配或独立 Excel 报价工作簿时，调用 `archive-quotation-builder`。向其传递已确认的总价、固定项、范围、单位和税口径；接收数值型报价表与对账结果后再合稿，不在两个 skill 中各算一套价格。
- **金额门**：程序校验每个系统、每个报价表和整本总价完全一致，固定项与分配项无重复，金额大写准确，尾差为 0。报价子流程未通过对账时不得生成“正式报价”结论。

### Phase 4　技术方案（复用 Phase 1 技术子流程成果）

> 编写前先把评分标准中每个主观评分项及其列明的评审子项（①②③…）原文摘出，作为本部分章节/子章节标题的唯一来源，标题逐字照搬，正文再充分扩写。

继续使用 Phase 1 已启动的 `bid-technical-proposal`，按其 Phase 0—7 工作流产出技术章节，不在本 skill 内重复生成另一份技术响应。
至少接收并复核：

1. 来源与版本登记；
2. 技术追踪矩阵及评分项、需求项、重要条款数量；
3. 能力、证据、承诺和偏离状态；
4. 按评分原文形成的章节蓝图与技术正文；
5. C+ 决策者质询及修正记录；
6. 技术部分 QA 报告。

只有同时满足“适用、能力已具备、证据已核验可引用、无偏离、相关承诺已关闭”的条目才能写
“完全响应”。量化指标、SLA、案例、证书和兼容性必须有来源或已批准承诺。技术章节的具体写法、
档案专业检查、增量修订和提交门槛均以技术技能 V2 为准。

### Phase 5　评分索引表
对照评分标准，做一张"评分索引表"放在**目录之后、正文之前**，列：序号 / 评分因素 / 分值 / 投标文件对应响应内容 / 对应页码。**"对应页码"列默认留空（不填充）**——评审定稿前页码常因增改图文反复变动，留空避免误导；"投标文件对应响应内容"写清对应章节名即可，专家凭目录与章节名即能定位。如用户明确要求填页码，再用第六节的页码定位脚本回填。

### Phase 6　生成 .docx 并自检
加载 `documents` 生成或合并 Word。按招标模板和本文件规则完成目录、编号、页眉页脚、表格、图示与
评分索引；渲染全部页面为 PNG 并逐页检查，不再只做抽查。提交候选版还必须通过技术技能的 submission
校验、整本占位符检查、旧项目污染扫描、暗标/元数据检查和报价一致性校验。

---

## 四、文档技术规范（documents 主控；以下为无模板任务规范）

Word 的运行时、生成方式与逐页渲染由 `documents` 决定。模板存在时，招标模板是唯一版式权威；
不得套用通用文档 preset 或企业 VI 覆盖模板。无模板时，本节的 A4、中性中文投标参数作为明确的任务
规范交给 `documents`，优先于其通用 US Letter/设计 preset 默认值。`assets/lib.js` 只提供无业务默认值的
底层组件；所有项目名称、编号、包号、日期和主体必须由项目配置显式传入，缺失时组件应失败而不是填示例。

- **页面**：A4（11906×16838 DXA），四边距 1440。
- **正文**：宋体（SimSun）、小四（size 24=12pt）、行距 360、首行缩进 480、两端对齐。
- **标题**：黑体（SimHei）、加粗、**黑色**、自动多级编号（绑定 numbering reference 到 Heading1–4，呈现 1 / 1.1 / 1.1.1 / 1.1.1.1）。功能点用**加粗段落**承载招标原编号（如"1.1 数据统计"），不占文档标题编号，避免与文档自动编号冲突。
- **页眉**：项目名称+包号，下加黑色细线。**页脚**：居中"第 X 页 共 Y 页"（PageNumber.CURRENT / TOTAL_PAGES）。
- **目录**：`TableOfContents` headingStyleRange "1-3"（功能组放 Heading4 即不进目录，保持目录干净）。
- **表格**：纯单线边框、表头加粗黑字白底、无底纹（`shading: undefined`）；宽度用 DXA，列宽之和 ≤ 内容宽（约 9000），始终 `WidthType.DXA`。
- **占位符**：虚线边框灰底框 + 灰色斜体说明文字（`placeholder()`）。
- **图示**：仅在能提高评审理解、定位或得分时绘制；架构、复杂流程和组织关系使用真正图示，表格只承载行列数据，甘特计划可用表格表达。方案示意图、原型图必须明确标注，不得冒充真实产品截图。
- **封面（非实质性格式）**：项目名称、编号/包号、供应商名称（加盖公章）占位、日期占位。

`assets/lib.js` 导出：`p, run, heading, plainTitle, placeholder, table, cell, headerRow, cover, makeHeader, makeFooter, numberingConfig, docStyles, bullet` 等。仅当 `documents` 选用 docx-js 时复用；不得修改技能目录内组件，不得依赖组件中的示例值。

**功能数据结构**（funcdata.js）建议：
```js
{ groups:[ { title:"一、xxx子系统", items:[
  { code:"1.1", name:"数据统计", hash:false,
    value:"本功能完全响应。<定位+业务价值+响应声明，富描述>",
    subs:[ ["子功能名","多句富描述：操作/场景/价值"], ... ] }
]}]}
```
渲染：组标题=Heading4；每个 item：加粗段落"code name(（#…）)" → value 段 → 各 sub "（n）名：描述"。

---

## 五、评分索引表页码（默认留空；如需填充的可选方法）

**默认：索引表"对应页码"列留空**（`pages.js` 各值设 "" 或 "—"），不做回填。理由：定稿前正文常因扩写、加图、改序导致页码漂移，留空更稳妥，专家凭章节名+目录即可定位。

**如用户明确要求填页码**，按"先占位、后回填"：
1. 索引表先用占位页码生成 docx → `soffice --headless --convert-to pdf` 转 PDF。
2. 用 `scripts/page_locator.py` 按**每个评分项对应章节的唯一锚点句**（取该节正文开头一句独有的长串，避免与目录重名）定位页码；脚本去除空白规避 pdftotext 在汉字间插空格。
3. 回填 `pages.js` 后**重新生成**；因索引表行数不变、分页一致，回填页码即为最终值（再次定位校验）。
4. 注意：任何会改变页数的修改（加图、扩写）后都需重跑回填，故除非临近定稿，否则保持留空。

> 锚点选"正文独有句"而非标题（标题会在目录里重复命中）。PDF 物理页号 = 页脚"第 X 页"。

---

## 六、自检清单（交付前逐项核对）

- [ ] 评分标准每一项都有对应内容；评分索引表对应内容齐全、章节名准确（**对应页码列默认留空**）。
- [ ] 功能点逐条点对点响应，子功能逐个有描述，描述富化。
- [ ] ★/▲/#/* 重要条款全部覆盖、数量与招标一致、注明证明材料。
- [ ] 实施/项目管理/进度/售后等章节满足评分满分条件，有项目化方法、责任、证据和验收口径，无重复注水。
- [ ] 资质、人员、业绩、证书编号、公司信息、产品能力、SLA 和量化承诺均可追溯；提交候选版所有必填字段和内部占位为 0。
- [ ] 无任何"我方实际公司"可识别信息（陪标约束）。
- [ ] 颜色与表格遵循招标模板；无模板时采用中性黑白样式。日期统一为提交截止日，致函使用实际单位名。
- [ ] 宋体小四正文、黑体标题自动编号、页眉、页脚页码、目录正确。
- [ ] 报价分项合计=总价（程序校验），大写金额正确。
- [ ] 全部页面已渲染并逐页检查，docx 可正常打开，无截断、重叠、缺字、错页或表格溢出。
- [ ] 各方案章节标题与评分标准评分项/子项表述逐字一致，评委可按评分表逐项定位。

---

## 七、图示自动生成（架构图与功能原型图）

只有图示能降低评审理解成本、帮助定位评分点或证明方案关系时，才按方案内容生成并嵌入；不得以“能配图”为理由批量插图。两类常用图：

**（1）总体技术架构图（按需生成，不是默认必做）。** 仅依据本项目已经确认的架构关系绘制。图层、组件、纵向体系、标题和图注必须来自项目配置文件；不得预置或推断信创、容器云、区块链、等保、密评、移动端等能力。提交版使用黑白灰并标注“方案示意”。运行 `scripts/make_arch.py --config <project.json> --output <project-workdir>/arch.png`；不得修改 skill 源文件来写入项目内容。

**（2）功能原型示意图（可选）。** 仅当评分规则重视界面、交互或场景说明，且没有可授权的真实截图时使用。标题、字段、节点、按钮、样例行和指标值必须来自已确认的项目配置；未提供数字时留空或使用“—”，不得随机生成或自行填充。所有模式永久显示“原型示意｜非真实产品截图”水印；正式提交版使用黑白灰，彩色模式只可用于用户明确要求的内部稿。运行 `scripts/make_proto.py --config <project.json> --output <project-workdir>/proto.png`。

**嵌入要点（docx-js）：**
```js
const { ImageRun } = require("docx"); const fs=require("fs");
new Paragraph({ alignment: AlignmentType.CENTER, children:[
  new ImageRun({ type:"png", data: fs.readFileSync(projectConfig.archImagePath),
    transformation:{ width:600, height:315 },           // 架构图≈600×315；原型图≈560×356
    altText:{ title:"…", description:"…", name:"…" } }) ] });
```
图片源用高分辨率，显示时按版心等比缩放。生成图保存到项目工作目录，不得写入 skill 的 `assets/`。脚本先使用显式 `--font-regular/--font-bold`，未提供时再从 Windows 与 Linux 常见 CJK 字体位置探测；找不到中文字体必须失败并说明原因，不能退回可能产生方框的字体。
两类生成器的配置字段和最小示例见 [`references/generator-configs.md`](references/generator-configs.md)。

---

## 八、协作 skill

| Skill | 协作方式 |
|------|----------|
| `presales-consultant-persona` | 整本需求与价值逻辑使用 A/C；技术子流程按技术技能使用 A/B/C/C+，其中 C+ 为初稿后的强制门 |
| `bid-technical-proposal` | 技术章节、技术追踪矩阵、证据/承诺/偏离闭环和技术提交门槛 |
| `documents` | Word 生成、模板继承、目录编号和全部页面渲染 QA |
| `archive-quotation-builder` | 仅作为档案功能级报价工作簿子流程；不得接管完整标书、税费/合同口径或整本总价 |

---

## 九、产出物

- 单一完整 `.docx`：封面 → 目录 → 评分索引表 → 资格商务文件 → 报价文件 → 技术方案。
- 工作稿允许结构占位；审查草稿要求需求、评分和重要条款映射 100%，只允许已登记待确认项；只有通过 submission 门槛的提交候选版才可标记为可填报盖章。
- 附：评分索引表（"对应页码"列默认留空，列清评分因素/分值/对应章节），便于专家评审定位。

---

## 十、配套陪标知识库（持续扩充）

本 skill 配套一个**陪标知识库**（随项目增多逐步丰富），编写新项目时优先从中复用、再按新项目改写：

- **方案知识库**：实施、项目管理、进度保障、售后服务、运维、测试与测评、验收、应急管理、数据迁移、信创适配、大数据支撑、培训、需求理解、服务理解等可复用方案文本（markdown）。
- **功能截图库**：只复用已授权截图的构图思路，不复用旧客户文字、字段、数据或界面主张；无真实截图时由 `make_proto.py` 读取本项目配置重新生成带水印原型。
- **架构图库**：只复用图形组织方式；由 `make_arch.py` 读取本项目确认的图层、组件和纵向体系重新生成，不复制旧项目能力标签。

用法：先检索知识库中是否已有同类方案/图，有则取来按新项目的招标需求、采购人名称、业务场景改写（切勿照抄留下旧项目痕迹）；无则新写。只有用户明确要求沉淀时才回写知识库。知识库位置由当前项目配置或工作区规则解析；找不到明确路径时继续项目工作并报告“未检索知识库”，不得猜测某个 `README.md` 的位置。
---

## 十一、评分标准变更后的增量修订流程

招标过程中评分标准常以"更正/澄清/补充/附件"形式变更（如本系列的"附件2 评审标准更正后"）。此时**增量修订**已有标书，不要推倒重来。流程如下：

本 skill 负责新版评分总表、资格商务变化、整本索引和最终合稿；凡涉及技术评分、技术要求、技术证明、
技术承诺或技术章节的变化，必须交给 `bid-technical-proposal` 按 `review-and-amendment.md` 形成差异包、
新版技术追踪矩阵和 QA 报告。本 skill 接收这些成果后再合稿，不直接越过技术主控改单。

### 11.1 先做新旧逐项对比，列"变更影响清单"
逐项比对新旧评分标准，识别四类变化并落到具体章节：
1. **分值变化**：某评分项分值升/降（例：服务理解 4→8、技术参数 28.8→34、进度 6→5）。分值升的项要补强内容、写满写细；分值降的项内容可不动。
2. **评分项增删**：新增项要补写对应章节；**删除项**（例：信创适配能力、大数据支撑能力被整项删除）要从评分索引表移除，正文对应章节可二选一处理——①直接删除使文档对齐评分表；②降级为"（附·补充技术能力）"保留内容并注明"本项不再单列计分"（适合内容优质、不愿浪费时，且置于计分项之后）。默认与用户确认。
3. **评分规则/口径变化**：如技术参数从"#条款13项每项扣2 + 普通56项每项扣0.05"改为"普通条款共68项每项扣0.5"——正文的条款口径表述要同步改（改条款总数、扣分规则；原#专项表可保留但重新定性为"需提供证明材料的重要条款"）。
4. **证明材料/资质要点变化**：如项目成员职称分值调整、删除某加分项（例：删除"档案局科技项目"加分）——商务部分团队表、资质表的说明要同步对齐新口径。

### 11.2 必改：评分索引表整表重做
按变更后的评分因素、分值、对应章节**整表重做**评分索引表（删除已取消的评分项行、更新分值、核对合计=100）。对应页码按默认留空。

### 11.3 内容修订与对齐
- 分值升高/规则细化的评分项：按新的满分条件、证明要求和履约风险补强，标题与新评分项/子项逐字对齐，不使用固定字数规则。
- 删除项：按 11.1 第2点处理；若降级保留，调整章节顺序使**计分项在前、补充项在后**（例：把"政策性加分"前移到售后之后，信创/大数据置于最末作附）。
- 若变更涉及成品软件/特定产品方案，且用户提供了厂商资料（如电子签章技术方案、版式套件白皮书），据此把对应方案扩写详实、专属（见知识库"通用方案模板/成品软件-*"）。

### 11.4 自检（变更修订专项）
- [ ] 新评分每一项都有对应内容与索引行；分值合计=100。
- [ ] 已删除评分项：索引无残留；正文已删除或已明确降级为"附·不计分"。
- [ ] 规则口径（条款数、扣分规则、资质分值）已与新标准逐字一致。
- [ ] 章节标题与新评分项/子项逐字对齐；计分项排在补充项之前。
- [ ] 因增删导致页码漂移——索引页码保持留空（除非临近定稿且用户要求回填）。
- [ ] 交付为新文件名（如"…-按新评分修订.docx"），不覆盖原件（原件可能被 Word 占用且需留痕）。