# 面向领导的说明：把 zhctprompt 升级为售前招投标项目工作台

## 一句话

`zhctprompt` 现在不只管理研发、交付和知识库，也开始承接售前项目和招投标标书编制：把采购文件、客户需求、产品能力、证据材料和团队协作流程统一到一个可追踪的工作台。

## 为什么要升级

售前和投标工作最容易出现四个问题：

1. 资料分散：采购文件、历史方案、产品截图、证书、检测报告、客户案例分散在微盘、个人电脑和聊天记录里。
2. 响应不可追踪：标书写完后，很难反查每一句承诺来自哪个证据。
3. 经验不能复用：上一个项目写过的控标参数、技术章节、实施方案和补证动作，下一次又重新找。
4. 风险难提前暴露：证书有效期、厂家授权、硬件参数、AI/营养健康承诺、客户案例授权等问题，容易到临投标前才发现。

这次升级的目标，是把售前招投标从“临时写材料”变成“有输入、有矩阵、有证据、有审查、有回流”的项目机制。

## 现在项目里新增了什么

| 能力 | 说明 |
| --- | --- |
| 招投标模块入口 | `modules/presales-bidding/` 作为售前和投标工作的统一入口。 |
| 历史资料索引 | `modules/presales-bidding/indexes/source-material-index.csv` 汇总已有控标参数库、营养健康参数库、保康中学投标样例和售前 intake 模板。 |
| 新项目模板 | `modules/presales-bidding/templates/` 提供项目目录模板、要求响应矩阵模板和证据门禁检查表。 |
| 新项目落位区 | `modules/presales-bidding/customer-projects/` 用于后续招投标测试项目。 |
| 两份说明 | 领导版说明解释经营价值和风险边界；团队协作版说明具体怎么干。 |

## 工作方式

一次售前或投标项目按这个链路走：

```text
采购文件/客户需求
  -> 来源登记
  -> 要求响应矩阵
  -> 证据分级
  -> 技术章节/服务章节/安全章节
  -> 人审 HTML
  -> 正式标书排版
  -> 可复用资产回流
```

关键变化是：标书不是直接开始写正文，而是先拆要求、找证据、标风险。这样可以尽早知道哪些能写成硬承诺，哪些只能写成方案建议，哪些必须补证。

## 对领导有用的管理视角

| 管理问题 | 项目如何回答 |
| --- | --- |
| 当前能不能投？ | 看响应矩阵里 P0/P1 要求是否能响应，哪些要求缺证。 |
| 我们优势在哪里？ | 看控标参数库、产品差异化评分和历史项目证据。 |
| 风险在哪里？ | 看证据门禁：证书、检测报告、厂家授权、案例授权、硬件参数、AI/营养承诺。 |
| 团队谁该补什么？ | 看补证清单和 owner 字段。 |
| 下次如何复用？ | 项目完成后把章节、参数、证据和反模式回流到招投标模块索引。 |

## 风险边界

这个工作台能提高资料组织、响应速度和风险可见性，但不能替代人工审批：

- 商务报价、付款、合同、盖章必须由负责人确认。
- 企业资质、产品证书、检测报告和厂家授权必须核验真件、有效期和投标主体。
- AI、营养健康、安全等级、国产化和等保结论不能无证承诺。
- 客户案例、验收截图和现场照片外发前必须确认授权和脱敏。
- 正式标书仍需投标负责人做最终排版、格式、附件和递交审查。

## 下一步测试方式

把一个真实或模拟招投标项目放入：

```text
modules/presales-bidding/customer-projects/<project-slug>/
```

然后按模板完成三件事：

1. 登记采购文件和来源。
2. 建立要求响应矩阵。
3. 生成一版人审 HTML，让负责人看能不能用于真实投标流程。

测试结束后，再决定是否把该模块升级为正式售前投标 SOP。