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）建议：

{ 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）：

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。

八、协作 skill

九、产出物

• 单一完整 .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 占用且需留痕）。