Bid Technical Proposal

投标技术方案 V2

本技能把技术标视为一项“可追溯的响应工程”，而不是通用方案文本的堆叠。最终目标是同时证明：

1. 招标要求、评分项和重要条款没有遗漏；
2. 每项能力、事实、数字和承诺都有来源或明确的待确认状态；
3. 章节结构帮助评委按评分表定位并判断，而不是靠篇幅制造完整感；
4. 草稿、正式投标正文和内部答辩材料的边界清楚；
5. Word 交付经过结构校验和逐页视觉检查。

一、任务边界与单一主控

先读取 references/boundaries-and-routing.md，判定任务模式和主控技能。

本技能主控

• 新编技术标、技术标大纲、技术评分章节；
• 技术参数、功能需求、★/▲/#/* 条款逐条响应；
• 需求理解、总体设计、实施迁移、测试验收、培训运维、售后技术方案；
• 技术偏离、证据缺口、承诺风险和满分条件核查；
• 现有技术标审查、单章节补写、评分更正后的增量修订；
• 仅技术册的 Word 交付。

本技能不主控

• 完整投标/响应文件：移交 bid-document-builder，本技能只产出技术章节与技术追踪矩阵；
• 资格、商务、合同、报价：分别由完整标书主控流程或报价技能处理；
• 非招投标解决方案：使用 presales-consultant-persona；
• 仅修改 Word 样式、目录、页眉页脚：使用 documents。
• 将技术标改编为答辩 PPT、演示稿或汇报材料：由 presentations 与 amber-pptx-style 主控， 本技能只提供响应一致性和承诺边界检查。

完整标书场景只移交一次，不允许两个技能各自生成一套完整文件。

二、按任务加载参考文件

只加载当前任务需要的参考文件，不为一次漏项检查加载全部章节写作指南。

三、不可绕过的质量红线

3.1 权威来源不能被有损摘要替代

招标文件、采购需求、评分标准、响应格式、答疑、澄清和更正公告是权威来源。必须登记文件版本、 优先级和定位方式，并保留关键条款原文。摘要只能导航，不能替代逐条响应的证据源。

处理 20 页以上的大文档时，先按工作环境规则生成 2000 字以内导航摘要并存入 summaries/； 在同一轮材料处理过程中，把评分项、否决项、技术要求、重要标记条款和格式要求原文提取到追踪矩阵。 后续基于“摘要 + 带定位的结构化摘录”工作；未经用户明确要求，不重复回读整份原文。

禁止对权威招标材料使用“只保留3—5条事实、之后不再核对原文”的压缩方式。历史标书、产品白皮书等 辅助材料可以摘要，但摘要内容不能自动升级为本项目的事实或承诺。

3.2 不得把推断写成既有能力

下列内容只有在招标文件、用户材料、有效证明或经责任人确认后才能写入正式响应：

• 产品功能、兼容适配、接口、性能、容量、准确率和并发指标；
• SLA、响应时限、到场时限、恢复时限、质保期和巡检频率；
• 客户名称、案例成效、合同金额、证书编号、资质等级和有效期；
• 项目团队、工期、资源投入、第三方能力、免费升级或永久承诺；
• “提升多少、缩短多少、达到百分之多少”等量化收益。

无法证实时，使用 【待产品确认】、【待商务确认】、【待交付确认】、【待证明材料】， 并进入承诺台账。不得默认写“完全响应”。

3.3 必须使用联合状态，不得压缩成一个“已响应”

技术追踪矩阵至少同时记录：

• 适用性：适用、不适用待确认、不适用已确认；
• 能力状态：已具备、条件具备、定制实现、第三方依赖、不支持、待核验；
• 证据状态：已核验可引用、已取得待核验、待补证、证据失配、无证据、不适用；
• 承诺状态：无需新增承诺、沿用采购要求、已审批、待审批、禁止承诺；
• 偏离状态：无偏离、正偏离、条件响应、负偏离、待澄清；
• 响应进度：未处理、已拆解、已起草、待证据/待确认、已复核、已锁定。

不适用是适用性判断，不是能力状态；只有 不适用已确认 + 证据状态=不适用 + 已定位确认依据 才能进入提交候选版。正文写“完全满足” 必须同时满足：适用、能力已具备、证据已核验可引用、无偏离、相关承诺已关闭。不得另建 covered/partial/pending 等单值状态掩盖证据、承诺或偏离缺口。

正偏离只能与已具备 + 已核验可引用组合，必须写明新增范围与边界，并双向关联一条已关闭的 COM-* 承诺；它不能被表述为普通“完全满足”。同一数字或同一审批记录不得覆盖否定改写、 对象变化、无条件扩张或其他未审批承诺。

3.4 工作稿、审查草稿与提交候选版分门

• 工作稿允许覆盖不完整和结构占位，但必须明确标注“未完成，不可提交”；
• 审查草稿要求现行需求、评分项和重要条款映射达到 100%，允许保留已登记且有责任人的待确认项；
• 提交候选版的否决项、强制项、评分项、证明材料、承诺和必填字段不得存在未关闭状态或占位。

脚本的 --mode draft 可用于工作稿和审查草稿，区别由覆盖率报告判断；--mode submission 只用于 提交候选版。如仍存在影响响应有效性或履约能力的缺口，停止生成“可直接提交”结论，明确列出阻断项。

3.5 审查任务不擅自改稿

用户要求审查、诊断或列问题时，只输出证据化问题清单，不重写原文件。增量修订必须保留原件， 生成新版本，不覆盖原文件。

四、标准中间成果

从 assets/templates/ 复制模板到项目工作目录，不直接修改技能内模板。

1. source_register.json：文件、A—E 层级、发布方、版本、接收时间、适用范围、优先级、哈希、定位方式和登记人；A/B/C 层来源必须填写 SHA-256；
2. source_requirements.csv：独立保存从现行权威来源提取的需求、标记、强制属性、评分原文与满分条件；不得从响应稿反推或回填；
3. technical_traceability.csv：把基线需求映射到章节、证据、承诺和响应状态；提交模式下其 requirement_id 集合必须与 source_requirements.csv 完全一致；
4. commitment_register.csv：分别保留 original_text 与 final_text；正文和扫描白名单只允许使用已关闭记录的 final_text；
5. bundle_qa_report.json 与 submission_scan_report.json：分别保存台账校验和正文污染扫描，避免两个脚本覆盖同一报告；
6. chapter_blueprint.md：按评分原文形成的章节蓝图；
7. cplus_review.md：决策者质询、修正说明和答辩准备记录。

字段定义、状态转换和示例见 references/traceability-matrix.md。

五、Phase 0—7 工作流

Phase 0：识别任务模式

识别是新编、矩阵、单章节、审查、增量修订还是 Word 交付；识别技术册/商务册是否分册、是否暗标、 是否有页数或文件大小限制。信息不完整时先按最可能模式产出初步结果，再只询问一个会实质改变结果的 关键问题。

Phase 1：锁定来源与版本

1. 登记招标文件、评分表、格式模板、附件、答疑、澄清和更正公告；
2. 明确最新文件对旧文件的覆盖关系，冲突项不得静默选择；
3. 提取段落、表格、页眉页脚、附件和扫描页；扫描件需要 OCR 时加载 PDF 技能；
4. 保留文件、页码/章节、表格行或其他稳定定位信息；
5. 缺少采购需求时只能给暂定大纲，不能声称已完成点对点响应。

A/B/C 层来源登记时计算并保存 SHA-256。缺少指纹的来源可进入工作稿，但不得支撑提交候选版。

Phase 2：原子化要求与否决项预检

把复合条款拆成单一可判断义务，分为：

veto、mandatory、scored、technical_requirement、function、deliverable、 format、evidence。

逐项记录 ★/▲/#/* 标记、是否强制、分值、满分条件、证明材料、验收口径和依赖条件。先处理可能导致 无效响应的分册、暗标、签章、格式、文件命名、容量和提交要求，再进入内容写作。

上述源要求先写入独立的 source_requirements.csv，再创建响应矩阵。不得通过删除 technical_traceability.csv 行来“提高覆盖率”，也不得在响应矩阵中改写基线原文、类型或标记。

Phase 3：建立评分策略与章节蓝图

1. 章节和子章节名称优先逐字采用评分项及评分子项原文；
2. 为每项记录满分条件、响应策略、证明材料、章节锚点、风险和责任人；
3. 内容预算按“分值 × 评分复杂度 × 风险程度”分配，同时服从页数限制；
4. 不使用“每分几页、每节几百字”等机械篇幅规则；
5. 无评分依据的补充内容放在计分项之后，不能挤占高分项表达空间。

Phase 4：完成能力、证据、承诺和偏离核验

逐项核验产品材料、案例、证书、团队、第三方依赖和交付资源。所有高风险主张进入承诺台账； 提交候选版正文中的承诺只允许 无需新增承诺、沿用采购要求 或 已审批，且只使用台账中的 final_text。强制项、否决项或 mandatory=是 的基线要求一旦为 不支持、条件响应 或 负偏离，脚本直接阻断提交；书面“知悉风险”不能替代能力、范围或采购要求的实质性关闭。

Phase 5：按响应类型编写

加载 presales-consultant-persona：

• 模块 A 用于把表象需求重构为业务问题；
• 模块 B 用于识别倾向性参数、履约风险和投入策略；
• 模块 C 用于形成价值优先的方案逻辑；
• 模块 C+ 在初稿后强制执行。

投标正文遵循“符合性优先、业务价值增强”的顺序。功能或参数响应通常包含：

1. 响应结论；
2. 实现机制或执行方法；
3. 本项目业务场景和价值；
4. 证明材料或来源定位；
5. 依赖条件、偏离或责任边界。

不同评分类型使用不同写法，不把所有内容强行套成“背景—痛点—架构—功能”。具体模式见 references/section-playbooks.md。

图示只在能提高理解、定位或得分时使用。生成的架构图和原型图必须标明“方案示意”或“原型示意”， 不得冒充真实产品截图；表格只承载真正的行列数据，不用作复杂架构图或装饰框。

Phase 6：压力测试与自动校验

1. 运行 scripts/validate_bid_bundle.py --bundle <目录> --mode submission --output bundle_qa_report.json，校验来源、独立需求/评分基线、追踪矩阵、承诺和提交状态；
2. 运行 scripts/scan_submission.py <正文> --mode submission --commitment-register commitment_register.csv --source-register source_register.json --output submission_scan_report.json，检查旧项目名称、禁用词、占位符和量化/绝对化/范围扩张承诺；如台账中有沿用采购要求，必须传入来源台账，使脚本核验其确实回链采购方权威来源；
3. 对照源材料核对需求、评分项和重要标记条款数量；
4. 执行 persona 模块 C+，提出具体指向承诺、资源、周期、责任和证据的尖锐问题；
5. 将真实缺口修回正文；质询清单单独保存为答辩/自检记录，未经要求不插入正式投标正文；
6. 答辩材料不得临场增加正式投标文件没有承诺的功能、数字或责任。

Phase 7：Word 生成、视觉验收与交付

只有用户要求 Word 时才加载 documents。正式投标/提交版的文档格式优先级分两种：

• 完整标书的技术子流程：最新有效的招标文件/响应模板 > 用户的视觉偏好 > bid-document-builder 整本规范 > 中性中文投标样式；
• 独立技术册：最新有效的招标文件/响应模板 > 用户的视觉偏好 > 本技能中性默认值。

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

不得在本技能内硬编码蓝橙品牌色、每章过渡页或固定 Word 引擎。Word 交付必须：

1. 继承招标模板的页面、标题、编号、页眉页脚和表格规则；
2. 更新并核查目录、交叉引用、图表标题和页码；
3. 对暗标版本清理供应商名称、品牌标识、作者和文档元数据；
4. 渲染全部页面为 PNG，在 100% 缩放下逐页检查截断、重叠、缺字、错页和表格溢出；
5. 修正后重新渲染，最后一次逐页检查通过才能交付；
6. 不覆盖原文件，只交付用户要求的正式成果，QA 中间图默认不外发。

六、交付门槛

审查草稿

• 所有要求均有唯一 ID 和来源定位；
• 评分项、技术需求和重要条款覆盖率为 100%；
• 待确认项已进入台账并有责任人；
• 没有把未核实能力写成“完全响应”；
• 同时交付未决事项和 C+ 自检记录。

提交候选版

除满足审查草稿外，还必须：

• 否决项和强制项不存在未解决状态；
• source_requirements.csv 与 technical_traceability.csv 的需求 ID 集合完全一致，基线原文、类型和标记无改写；
• A/B/C 层来源均有 64 位 SHA-256 文件指纹；
• 需证明项均有有效证据或经确认的处理结论；
• 所有正式承诺均已批准；
• 强制字段零占位，旧项目/旧客户污染为零；
• 暗标、分册、格式、命名和提交规则核验通过；
• Word 逐页渲染检查通过；
• validate_bid_bundle.py --mode submission 无 error。

只要任何提交门槛未通过，就不得声称文件“可直接提交”。

七、写作原则

• 先回答评分规则真正判断什么，再决定写什么；
• 先建立证据链，再扩写业务价值；
• 使用客户业务语言，但不把推测包装为事实；
• 用项目场景、方法、边界、责任和验收标准体现深度，不用重复与字数体现深度；
• 标题服务于评委定位，正文服务于可信判断；
• 外部研究只能补充背景，不能替代招标原文和投标人证明材料；引用时优先官方原始来源并记录日期。