项目总工期只有一个，一份技术标里却可能出现三个答案。
项目概况写 180 日历天，进度章节沿用了旧母版的 210 日历天，承诺书又写成“6 个月内完成”。每一句单独看都通顺，放在同一个投标文件里，就是三份彼此冲突的履约承诺。
这不是一个真实项目案例。它是编标工作中很常见的一类问题：同一项事实进入多个章节以后，开始各自生长。
我把它称为“事实漂移”。
标书里的事实，不会只出现一次
工期可能同时进入项目概况、施工部署、进度计划、资源投入、季节性施工、承诺书和横道图。质量目标、安全目标、项目名称、关键日期、人员数量和设备型号，也有同样的问题。
它们不是普通关键词。
同一个数字出现在不同章节，承担的责任不同。项目概况负责说明，进度计划负责展开，资源章节要证明配置能够支撑计划，承诺书则可能形成直接履约义务。
只做全文搜索，可以找到相同的字。它很难判断“180 日历天”“计划 6 个月”和一张从旧项目复制过来的 210 天横道图，是否指向同一项承诺。
更危险的是，这些冲突往往不会以错别字的样子出现。
它们语法正确，数字具体，甚至比原文更像一份成熟标书。
AI 会让事实漂移更隐蔽
大模型很擅长补足上下文。
当资料里同时存在招标文件的新工期、旧母版的历史工期和一个没有来源的通用模板数字时，模型可能选择其中一个，也可能把“180 日历天”改写成“约 6 个月”，再把旧进度计划润色成另一套看似合理的节点。
结果可能更流畅，却更难复核。
所以，长标书使用 AI 的第一步不应是“把整篇写得更好”，而是先回答三件事：
- 哪些信息属于当前项目事实；
- 每项事实来自哪里，现在是什么状态；
- 哪些章节有权使用它，事实变化后哪些结果必须失效。
先建立一份事实基线
事实基线不是把项目概况复制到表格里。
一项能够进入正文的事实，至少要有六个字段：
| 字段 | 要回答的问题 |
|---|---|
| 事实标识 | 这是工期、质量目标，还是某个关键节点？ |
| 当前值 | 正文允许使用的准确表达是什么？ |
| 来源 | 来自招标文件、清单、澄清文件还是责任人确认？ |
| 状态 | 已确认、待确认、冲突，还是不适用？ |
| 版本 | 这项事实在哪次澄清或确认后发生过变化？ |
| 使用范围 | 哪些章节可以引用，哪些章节需要专业负责人补证？ |
“已确认”和“看起来合理”必须分开。
如果招标文件与答疑文件给出不同工期，系统不能自行挑一个更像最终答案的数字。它应该把冲突暴露出来，交给投标负责人确认。
事实没有确认，AI 可以整理问题，不能替团队制造承诺。
响应矩阵要把要求、事实和章节绑在一起
事实基线解决“当前项目是什么”。响应矩阵解决“这一条要求在哪里被回答”。
一张可用的响应矩阵，不只列招标条款和章节号。它还应连接五类信息：
- 招标要求或评分点；
- 当前响应章节；
- 允许使用的项目事实；
- 仍然缺失的证据；
- 最终确认人。
这样做有两个直接收益。
第一，编写人员能看到某章缺的到底是文字，还是资料。缺人员资格证明时，继续生成一段“组织保障有力”没有意义。
第二，事实变化后可以找到受影响的章节。工期从 180 日历天调整为 195 日历天，不应只改项目概况；进度节点、资源峰值、季节性措施、承诺书和图表都需要重新打开。
事实变化后，旧结果必须失效
很多系统只记录“这章已经生成”或“这条问题已经处理”。
这种状态不够。
如果章节候选基于工期版本 3 生成，项目负责人后来确认了版本 4，这份候选就不能继续显示为“已完成”。它应进入待复核状态，并列出受影响的事实与段落。
更稳的流程是：
- 从招标文件、清单和澄清材料提取事实候选；
- 人工确认当前值、来源与责任状态；
- 用响应矩阵限定章节任务和可用证据；
- AI 只生成受约束的章节候选；
- 确定性规则检查旧项目残留、数字、日期、型号和跨章节冲突；
- 人工采纳后，以修订方式写回 DOCX，并在 Word 或 WPS 中完成最终验收。
这条链路看起来比“一键改完整本”多了几个步骤，却减少了最昂贵的返工：定稿前重新通读几百页，寻找那些已经被润色得很自然的错误。
为什么工作台比原计划走得更久
我们原先希望在 7 月底拿出一个更早的可试用版本。那一阶段的主线更接近传统工程软件：导入资料，提取要求和事实，生成候选，逐项复核，再把采纳结果写回 DOCX。
这些能力没有被推翻。事实基线、响应矩阵、确定性检查、人工确认和 Word / WPS 验收，仍然是今天的底座。
开发周期被拉长，是因为整本技术标并不是一次生成任务。它会跨章节、跨证据、跨多轮修改；任务中断以后要能够恢复，一项事实改变以后，依赖它的章节、图片和承诺也要重新进入复核。只在界面上增加几个按钮，承载不了这样的过程。
8 月以后，工作台开始引入受控的 Tender Agent 运行方式：把任务拆成有明确技能、权限和检查点的步骤，记录父子任务、证据回执与 Word 修订谱系。智能体可以持续执行，但不能绕过事实确认、人工审批和最终签收。
这条路线也显著增加了系统复杂度，原来的时间判断因此失效。当前能够确认的是，执行链、审计边界和中断恢复能力正在逐步闭合；它能否在陌生标书上稳定减少时间、降低遗漏、降低对熟练编制人员的依赖，还要由真人试验回答。我们不会把“已经接入智能体”写成“效果已经得到证明”。
这也是筑见合规当前在解决的问题
筑见合规 Windows 技术标本地工作台当前为 1.0.0，采用受控定向分发，公开下载仍关闭。
它已经把 DOCX 母版、招标文件、工程量清单和证据附件放进同一个本地工作区，并围绕已确认项目事实生成可审阅的章节候选。整标智能审查与确定性门禁分别处理语义遗漏和硬边界问题，修改以候选、差异和修订记录进入人工决定，再导出到 WPS 或 Microsoft Word 完成排版与责任复核。
这个工作台不会替投标负责人签字，也不会把候选规范、模型建议或自动检查包装成“已经合规”。
产品当前最重要的价值，是让要求、事实、正文、证据和责任人之间的关系更容易检查，而不是让标书在几分钟内多出几百页文字。
现在就能做的一次 15 分钟检查
不需要先安装任何软件。
从当前标书中任选 6 项高风险事实：项目名称、工期、质量目标、开竣工日期、项目负责人、关键设备。为每项事实填写一行：
| 当前值 | 来源位置 | 出现章节 | 是否存在别名表达 | 最终确认人 |
|---|---|---|---|---|
然后问三个问题：
- 同一事实是否出现了两个以上不同值？
- 图表、附件和承诺书是否仍保留旧项目表达？
- 事实变化后，团队能否列出必须重新复核的全部章节？
只要有一个问题答不上来，标书就还没有形成可靠的事实基线。
AI 可以帮助人快速发现矛盾、整理来源和生成候选。最终承诺仍应由有权负责的人确认，并保留可追溯的依据。
关注我们
欢迎搜索并关注 筑见实验室，获取更多建筑 AI、结构计算与工程数字化实践：
