Skip to content

Latest commit

 

History

History
39 lines (23 loc) · 3.03 KB

File metadata and controls

39 lines (23 loc) · 3.03 KB

设计哲学

tender-writer 不是一个"让 AI 写标书"的工具,而是一个"让标书编制变成可审查的工程流程"的方案。以下是几个关键设计取舍和背后的理由。


为什么是 5 个阶段,不是更多或更少

标书编制的本质是"把招标文件的要求,逐项映射成可验证的应答"。拆成 5 个阶段,是因为每个阶段产出的中间产物有明确的检查标准:

  1. 招标解析 → tender_brief.md:能不能一眼看出预算、工期、资质门槛、废标条款?
  2. 评分矩阵 → scoring_matrix.csv:每一分是否都对应到了具体的应答章节?
  3. 提纲反推 → outline.md:章节结构是否完整覆盖了评分矩阵的所有行?
  4. 分章节撰写 → tender_response.docx:正文是否逐项应答,有没有漏答?
  5. 合规终审 → compliance_report.md:格式对不对,废标条款有没有踩?

少于 5 步会导致中间产物不可审查(比如把解析和矩阵合并,你就没法单独检查矩阵是否拆准了);多于 5 步则引入不必要的等待(比如把撰写再拆成"初稿→润色→定稿"三步,在实战中并没有明确的检查边界)。

为什么严禁一键生成

"一键生成整本标书"在演示时很惊艳,但在实战中是灾难。原因很简单:标书是一份法律文件,漏答一个评分项可能丢 5 分,踩到一条废标条款整本作废。如果 AI 一口气生成 80 页内容,你根本不知道它在第 37 页漏掉了什么。

分阶段推进的价值不在于"让 AI 更慢",而在于每一步都给你一个明确的检查点。你审过的 tender_brief 是后续所有工作的事实来源;你审过的 scoring_matrix 是撰写阶段的唯一参照。这条链路上任何一环出了错,都能在当步被捕获,而不是等到提交前 2 小时才发现。

为什么要区分 own / partner / reference

这不是一个技术分类,而是一条合规红线。在政府采购场景中:

  • own(我方)的素材可以直接引用
  • partner(合作方)的素材可以引用但必须标注来源
  • reference(竞品/标杆)的素材绝对不能出现在标书正文里——如果你把竞品的业绩写成了自己的,轻则废标,重则进黑名单

如果不在工具层面做隔离,靠人的自觉来防止这件事,迟早会翻车。所以 tender-writer 在 companies.yaml 中用 company_type 字段做强制分类,所有素材入库和引用时都必须校验类型,reference 类型的素材从物理路径上就被隔离在 references/knowledge_base/ 中,永远不会出现在 assets/ 里。

为什么素材库和知识库严格分离

assets/ 里的东西会被直接"抄进"标书;references/knowledge_base/ 里的东西只用来"学习风格"。这两个动作的法律后果完全不同。

如果混在一起,AI 在撰写时可能把一段只应该用来学习话术风格的竞品案例,当作可引用素材写进了正文——这就是一起合规事故。物理隔离(不同目录)+ 类型校验(company_type)+ 双重审查(review_status),三层防护确保这件事不会发生。