现有系统已经拥有文档中心、招标解析、评分响应矩阵、目录设计、正文编写、审核与导出等完整页面。下一阶段不应该继续堆页面，而要把“来源、事实、评分、企业证据、审核问题、修改影响和交付闸门”变成真正的数据与工作流对象，使产品能够承接真实政府采购和企业投标流程。
主流程完整，用户不是直接面对一个聊天框；招标解析保留页码；评分响应矩阵成为制标中枢；目录和正文拆开处理；审核与导出独立存在；已有 DeepSeek、Prisma、TipTap、PDF/DOCX/XLSX 和 Electron 本地优先技术基础。
文件之间没有真正的版本优先级；AI 提取结果与业务事实没有分层；企业资料还是“文件”，不是可验证证据；评分覆盖更多是状态统计；正文可以先生成再找依据；审核发现问题但缺少关闭机制；修改一个事实以后很难知道哪些章节、评分和证据需要重算。
旧：AI 标书生成系统。
新：AI 制标与合规审校作业平台 —— 从招标原文和企业证据出发，控制整份标书的评分覆盖、真实性、全文一致性和最终交付风险。
企业系统不能把全部文件平等扔进 RAG。必须知道哪一份文件是当前有效版本，哪一份补遗覆盖了旧规则。例如 V1 为 12 个月、补遗改为 9 个月，最终事实必须使用 9 个月，同时保留历史来源。
把模型提取出来的文本重新标准化为项目名称、项目编号、预算、交付期、付款条件、资格、团队要求等正式业务事实。后续评分、目录、正文、审核全部引用同一 Fact，而不是各 Agent 各自理解招标文件。
资质、人员、案例、证书、产品参数必须变成带来源、有效期、Claim 与人工确认状态的 Evidence。生成逻辑由“先写再找资料”改成“先确认需要证明什么 → 找到有效 Evidence → 再允许写入正文”。
评分矩阵从单纯表格升级为 Score Item ↔ Section ↔ Evidence 三向关系图。系统不仅知道某评分项写在哪一章，还知道为什么认为它已经覆盖、缺哪份材料、当前最多能支撑到哪个得分档。
不预测“中标率”。只根据评分规则与企业现有材料判断：当前能支持到哪一个得分档、哪里值得优先补材料。例如 5 个案例得 8 分，但正文只计划引用 3 个，而企业库实际有 7 个有效案例，则建议补 2 个。
点击“AI 生成章节”前，先形成本章写作计划：需要回答哪些评分点、有哪些强制项、需要哪些企业证据、哪些事实仍待确认。缺证据时允许保留 【待企业确认】，禁止模型虚构。
审核中心不能只显示红点。每个问题都要有严重等级、来源、影响范围、责任人和状态：待处理 → 处理中 → 已解决 / 接受风险 / 驳回 AI。这样“审核”才真正成为业务流程。
修改项目经理、交付期、证书或企业证据以后，系统先计算受影响的章节、评分项、附件和审核问题，再只重生成受影响部分。锁定章节不应被无意覆盖。
允许带待确认和未关闭问题导出，但必须明显标识风险，适合内部协同和人工审稿。
必须通过废标风险、强制响应、资格要求、企业证据、全局事实、待确认项等硬闸门。强行越过必须留下审批人与审计日志。
长文档解析和章节生成不是一个 HTTP 请求。每一个 Map Batch、Reduce、评分规划、目录、章节、审核和修改任务都需要 Checkpoint。刷新页面、Electron 重启或单章失败后，只从失败节点继续，已通过章节不重复消费 Token。
| 维度 | 普通 AI 标书 Demo | 目标产品 |
|---|---|---|
| 输入 | 上传一份招标文件 | 招标资料包 + 版本覆盖 + 企业资料 |
| 事实 | 模型输出即结果 | Tender Fact + 人工确认 + 历史值 |
| 评分 | 关键词覆盖 | Score ↔ Section ↔ Evidence |
| 企业内容 | RAG 搜资料 | 结构化 Evidence + 有效性 + Claim |
| 生成 | 一键生成全文 | Section Plan + Evidence-first + Claim Trace |
| 审核 | 提示问题 | Issue Lifecycle + Assignee + Resolution |
| 修改 | 全文重生成 | Change Impact + Selective Regeneration |
| 导出 | 有文件就能导 | Internal Draft / Formal Bid + Bid Gate |
| 运行 | 一次性调用 | Workflow Checkpoint + Pause / Resume / Retry |
| 测试 | 通过标准 |
|---|---|
| 补遗覆盖 | 原文件 12 个月、补遗 9 个月，最终 Fact 必须为 9 个月并保留历史值 |
| 无企业证据 | 没有 ISO 证书时正文不得生成“已通过 ISO” |
| 评分高分档 | 企业有足够案例但章节未利用时，系统应识别得分档提升机会 |
| 全局事实 | 项目经理或交付期在不同章节出现不一致必须被发现 |
| 修改影响 | 修改项目经理只重新计算有关章节 / 评分 / Evidence |
| Bid Gate | Critical Issue 或 Mandatory 未关闭时正式投标版不可导出 |
| 工作流恢复 | 单章节失败或重启应用后从 Checkpoint 继续，不重跑全部章节 |
最终不要把项目讲成“DeepSeek 可以自动生成 100 页标书”。更准确的产品逻辑是：AI 负责把长招标文件、评分标准和企业资料加工成可计算的业务对象，人负责确认关键事实与业务判断，系统负责保证整份标书有证据、能得分、口径一致，并在交付前把风险关掉。