Customer Problem
客户问题
企业制作标书时，真正造成投标风险的往往不是文字写得不好，而是：使用了错误版本的招标文件、招标补遗没有同步、评分项遗漏、同一家企业事实在不同章节不一致、AI 生成了企业不存在的案例或能力、正文写完以后才寻找证据导致「倒挂」、审核问题停留在 Excel/微信/邮件、修改一个事实以后无法知道影响哪些章节、最终提交时仍存在未关闭问题。
招标文件可能有多个版本和补遗，使用过期版本或遗漏补遗直接导致废标。
评分要求散落在数百页招标文件中，人工逐项核对容易遗漏关键得分点。
同一家企业事实（资质、案例、数据）在不同章节表述不一致，评审专家会质疑可信度。
传统流程中正文写完才找证据支撑，导致「先生成再找证据」——如果找不到证据，正文已经写好了但不可用。
审核问题分布在 Excel、微信、邮件中，无法追踪是否真正关闭。一处修改影响多少章节无法自动识别。
因此标书不是一个「长文本生成任务」，而是一个由来源控制、事实管理、要求覆盖、证据管理、内容生成、审校、变更控制和最终交付共同组成的复杂工作流。
What I Did
我做了什么
重新设计完整制标链路，围绕四个核心产品系统构建：
Source Registry（来源注册表）
管理所有输入文件的类型、版本、发布时间、优先级和有效性。招标文件补遗更新了版本？Registry 追踪变化并标记影响范围。过期版本自动失效但保留审计记录。没有来源治理，就没有可追溯的标书。
Evidence-first Generation
先确认企业证据（资质、案例、数据），再基于证据生成正文。正文中的每条主张都可以追溯到对应的 Enterprise Evidence，杜绝「先写正文再找依据」的倒挂问题。
Issue Lifecycle & Change Impact
审核问题状态流：Open → Assigned → In Progress → Resolved → Verified → Closed。当 Tender Fact 或 Evidence 修改后，系统自动识别受影响章节、评分项和引用。
Bid Gate（交付闸门）
导出前自动检查：必填项完整性、评分项覆盖率、证据完整性、未关闭 Issue、版本状态、全文一致性。任一检查未通过则阻止导出，降低交付风险。
Key Decisions
关键决策
Source Registry 是系统底层基础
为什么
如果招标文件版本、补遗和答疑没有被系统管理，后面的 RAG 和生成能力都可能建立在错误材料之上。来源错误 = 全文错误。
决策
将 Source Registry 设计为独立的产品对象，所有后续流程从 Registry 获取「当前有效版本」。
取舍
增加了前期的配置和维护工作，但这是标书可靠性的最底层保障。
AI 提取的事实不等于企业正式事实
为什么
模型从材料中提取的事实可能存在理解偏差、遗漏或过度推断。直接使用 AI 提取结果参与内容生成会产生连锁错误。
决策
Tender Fact 必须经历 Extracted → Reviewed → Confirmed 三阶段，才能参与正式内容生成。
取舍
流程增加了人工确认环节，但确保所有参与生成的事实都经过了验证。
Evidence-first，不是 Generation-first
为什么
先生成正文再找证据的流程（Generation-first）在产品逻辑上是倒置的。如果找不到证据，已经生成的正文就不可用。
决策
先匹配企业真实资质、案例和数据，确定可以写什么，再生成正文。
取舍
生成速度可能比直接吐文本慢，但生成的每一段内容都有对应的证据锚点。
Bid Gate 是强制闸门，不是可选建议
为什么
如果最终检查是可跳过的，它就不会被执行。投标容错率为零 —— 一次提交错误可能导致数月的努力白费。
决策
Bid Gate 检查：必填项、评分项覆盖、Evidence、未关闭 Issue、版本状态、全文一致性。重要问题未解决时不得进入最终导出。
取舍
极端情况下可能延迟提交，但对投标场景来说，未准备好的提交比不提交更糟糕。
Results
成果
完成从「AI 写标书」到「AI 制标与合规审校工作台」的产品定义：
Product
完成从长文本生成到制标合规审校工作台的产品定位转变。
System
建立 Source → Fact → Requirement → Evidence → Generation → Issue → Change → Gate 完整产品模型。
Prototype
展示来源管理、评分图谱、证据匹配、Issue 追踪和 Bid Gate 检查的完整交互流程。
Evaluation
形成评分项覆盖率、证据正确性、事实一致性、Issue 关闭率、修改影响识别准确性等验证指标。
当前为产品设计与交互原型阶段。生产级 Source Registry 服务、真实投标业务验证和企业资质与案例库系统属于 Future State。
Product System
产品系统设计
以 Source 和 Evidence 为基底的制标系统：
Evaluation
如何验证
围绕合规审校和交付质量建立评价体系 —— 目前为 Evaluation Framework：
评分项覆盖率
每个评分项是否有对应响应，是否存在遗漏。
证据正确性
引用的 Enterprise Evidence 是否真实有效，版本是否有效。
事实一致性
同一事实在不同章节是否表述一致，是否存在矛盾。
Issue 关闭率
审核问题从 Open 到 Closed 的比例，未关闭问题是否影响最终提交。
修改影响识别准确性
事实修改后是否正确识别了受影响范围。
工作流恢复能力
系统故障后任务是否能正确恢复，是否丢失进度。
Product Demo
产品展示
Bid Gate —— 最终交付前统一检查评分覆盖、证据、版本与未关闭问题，重要问题未解决时阻止导出。
Analysis Framework
产品分析框架
Future State
后续迭代
当前为产品设计与交互原型阶段。后续需要在真实投标业务中验证的方向：
- 生产级 Source Registry 服务
- 真实投标业务验证
- 企业资质与案例库系统
- 与 OA / CRM 系统集成