# 面向团队协作的说明：售前招投标项目怎么在 zhctprompt 里协作

## 适用场景

当团队要做以下工作时，默认进入 `modules/presales-bidding/`：

- 售前方案。
- 招标文件解读。
- 技术标书章节。
- 控标参数整理。
- 产品差异化响应。
- 企业资质、产品证书、检测报告和客户案例补证。
- 一个真实项目的投标材料复用和归档。

## 先看哪里

| 你要做什么 | 入口 |
| --- | --- |
| 了解整体规则 | `modules/presales-bidding/README.md` |
| 查已有控标/投标素材 | `modules/presales-bidding/indexes/source-material-index.csv` |
| 新建一个招投标项目 | `modules/presales-bidding/templates/project-folder-template.md` |
| 拆采购文件要求 | `modules/presales-bidding/templates/requirement-response-matrix-template.csv` |
| 判断证据能不能写进标书 | `modules/presales-bidding/templates/evidence-gate-checklist.md` |
| 看已有真实样例 | `product_kezuozhongqi-baokang-middle-school-smart-canteen/README.md` |

## 新项目目录

后续招投标测试项目默认放这里：

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

建议结构：

```text
<project-slug>/
  README.md
  ROUTING_NOTE.md
  source-docs/
    source-index.csv
    source-evidence.md
  response-matrix/
    requirement-response-matrix.csv
    evidence-gap-list.csv
  deliverables/
    01-technical-solution.md
    02-implementation-plan.md
    03-service-and-training.md
    04-security-and-compliance.md
  review/
    <project-slug>-bid-review.html
  archive/
```

不要把业务代码、客户服务器配置、密钥、手机号、未脱敏合同或大体积原始微盘文件复制进来。

## 角色分工

| 角色 | 主要输入 | 主要输出 |
| --- | --- | --- |
| 销售/项目负责人 | 客户背景、采购节奏、竞争对手、商务边界 | 项目基本信息、投标策略、报价和递交节奏确认 |
| 产品/售前 | 产品能力、方案结构、功能边界、差异化 | 要求响应矩阵、技术章节、补证清单 |
| 研发/测试 | 系统截图、接口、版本、性能、安全和可验证能力 | A/B 级技术证据、验证说明、风险提示 |
| 交付/实施 | 部署方式、实施计划、培训、售后、验收经验 | 实施服务章节、现场条件清单、交付风险 |
| 商务/法务/投标负责人 | 资质、授权、报价、合同、盖章、附件 | 最终人工确认和正式投标文件 |

## 执行步骤

1. 新建项目目录，复制 `templates/project-folder-template.md` 的结构。
2. 在 `source-docs/source-index.csv` 登记采购文件、客户资料、历史方案、微盘路径和产品证据。
3. 把采购文件拆成 `response-matrix/requirement-response-matrix.csv`。
4. 给每条要求标注：
   - `response_strategy`: 直接响应、替代响应、偏离说明、待补证、不响应。
   - `evidence_level`: A、B、C、D。
   - `evidence_path`: 对应截图、证书、文档、案例或历史材料。
   - `risk`: 写进标书前必须处理的问题。
5. 在 `deliverables/` 输出章节 Markdown。
6. 生成 `review/<project-slug>-bid-review.html` 给负责人审。
7. 审完后把可复用的控标参数、章节模板和反模式回流到 `modules/presales-bidding/indexes/` 或 `standards-stack/`。

## 证据规则

| 证据等级 | 可以怎么用 |
| --- | --- |
| A | 可写成硬性响应，但仍需确认有效期、授权和投标主体。 |
| B | 可写成方案能力或案例支撑，外发前补脱敏和授权。 |
| C | 只能用于内部结构、方法、竞品参考或方案建议。 |
| D | 只能作为假设和待确认项，不能写成承诺。 |

强承诺必须有证据路径。没有证据的内容不要写成“已实现、满足、具备、达到、保证”。

## 常见禁止项

- 不把内部演示或设计原型写成已上线功能。
- 不把客户兴趣写成采购承诺。
- 不把内部评分表写成行业权威排名。
- 不把未经授权客户案例写进公开标书。
- 不把 AI 准确率、健康效果、等保、国产化、硬件参数写成无证承诺。

## 测试一个招投标项目的验收口径

一个测试项目至少要产出：

1. `README.md`：项目目标、阶段、负责人和输出范围。
2. `source-docs/source-index.csv`：来源清单。
3. `response-matrix/requirement-response-matrix.csv`：要求响应矩阵。
4. `response-matrix/evidence-gap-list.csv`：补证清单。
5. `deliverables/`：至少 1-2 个章节草案。
6. `review/<project-slug>-bid-review.html`：人审页面。

只有人审页面能清楚展示“能响应什么、缺什么证据、哪些不能承诺”，才算通过测试。