# Bid Technical Proposal

> 招投标技术标、技术响应和评分技术项的内容主控。用于编写或修订技术章节、技术参数与功能逐条响应，以及检查评分覆盖、证据缺口、偏离、实施迁移、培训运维和售后技术承诺；负责独立采购需求基线、技术追踪矩阵和提交门禁。完整投标由 bid-document-builder 主控，非投标客户方案、独立报价、纯 Word 排版和答辩 PPT 不由本 Skill 主控。

- Skill: `wjjjjjjjjjjj/bid-technical-proposal` (Agent Skill, multi-file: 65 files)
- Install (CLI): `npx skillmds@latest add wjjjjjjjjjjj/bid-technical-proposal`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wjjjjjjjjjjj/bid-technical-proposal/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-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` 主控，
  本技能只提供响应一致性和承诺边界检查。

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

---

## 二、按任务加载参考文件

| 场景 | 必须读取 |
|---|---|
| 所有技术标任务 | `references/boundaries-and-routing.md`、`references/source-and-claims.md` |
| 新编技术标、逐条响应、评分规划 | `references/traceability-matrix.md`、`references/section-playbooks.md` |
| 审查、提交版检查、Word 交付 | `references/qa-gates.md` |
| 更正公告、澄清文件、旧稿增量修订 | `references/review-and-amendment.md` |
| 档案信息化项目 | `references/domains/archive-informatization.md` |

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

---

## 三、不可绕过的质量红线

### 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。

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

---

## 七、写作原则

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