为什么我们没有把 AI 标书只做成网页？

近期公开可见的 AI 标书产品，常见动线很相似：

上传招标文件，提取评分点，生成目录和章节，在网页里继续编辑，最后导出 Word。

这条路线没有错。对快速理解招标文件、搭建提纲、起草一章内容和多人协作来说，网页足够轻，也容易让用户立即上手。

但如果目标再往前一步——不是生成一份新的初稿，而是接管企业正在使用的技术标母版，保留其中的表格、图片、编号、页眉页脚和目录，把 AI 修改准确写回原位置，形成 Word 能识别的修订，并让负责人可以复核、撤销和签收——问题就变了。

它不再只是一个网页写作问题，而是一个本地生产文档问题。

这也是筑见合规为什么选择了一条明显更难的路：Web 负责项目和状态，本地工作台负责敏感文档生产，治理端负责规范、规则、模型和版本。我们为这条路线投入了大量工程精力，因为技术标交付的不是聊天记录，也不是网页里的富文本，而是一份必须继续在 Word 或 WPS 中工作的 DOCX。

AI 标书已经会写，为什么仍难接管生产文件

先把结论说得准确一些：不是因为用了 Web，模型就一定写不好；浏览器也并非天然不能处理复杂文档。

问题不在 Web 本身，而在产品把交付目标定到哪里。若目标主要是生成速度、篇幅、模板数量和一键导出，几个更难的问题就很容易留在链路之外。

第一，输入被压成了文本，上下文却不只是文本。

一份技术标的事实分散在招标文件、评分办法、工程量清单、图纸、企业资料和原有母版中。同一个工期、地点、设备型号或施工边界，可能在多份材料里以不同形式出现。如果系统只把内容切成文本片段交给模型，它很容易写出语言流畅、事实关系却不牢的段落。

第二，逐章生成很快，跨章一致性却更难。

章节并行生成可以缩短等待时间，也可能带来项目名称、工期、人员、机械、工艺口径和承诺程度不一致。解决它不能只靠“再润色一次”，需要先建立项目事实、来源位置、章节职责和跨文档关系。

第三，导出 Word 不等于回到原 Word。

从网页富文本生成一个新 DOCX，与在原母版中准确替换一段、保住复杂结构并产生原生修订，是两类任务。前者解决“把内容带走”，后者要对原文件的结构和修改责任负责。

第四，模型给出了答案，不等于负责人作出了决定。

标书里有大量承诺性内容。人员、工期、机械、工艺、规范和业绩依据不能因为两个模型意见一致就自动生效。AI 结果必须先成为候选，再由人采纳、拒绝、修改或继续核对。

第五，下载成功不等于交付完成。

目录能否更新、表格是否跨页错位、图片是否丢失、页眉页脚是否串节、接受全部修订后是否与普通版一致，仍然要经过自动结构检查、真实 Word/WPS 和独立使用者三层验证。

所以，AI 标书的质量瓶颈不只在模型。产品把标书当成“一篇长文章”，还是当成“带事实、证据、结构、版本和责任的生产文件”，往往更关键。

为什么是本地工作台，而不是把所有能力继续塞进 Web

筑见合规并没有放弃 Web。我们只是把不同任务放回更合适的边界。

Web 端适合承载项目列表、任务状态、风险摘要、规则版本、轻量问答，以及打开本地工作区的入口。规则和模型治理端适合维护规范、证据包、场景包、模型配置和发布记录。

客户原始 DOCX、招标文件、清单、图纸和完整附件，则默认留在本地工作台。可同步的是项目元数据、规则版本、风险数量、人工复核状态和文件 hash，而不是把客户全文默认上传到云端生产库。

这个选择不只是为了“文件存在本机”。本地生产工作台还要同时承担几件 Web 生成器通常不会全部承担的事：

• 长时间保存一个可恢复的工作区，而不是一次上传和下载；
• 直接处理原始 DOCX 包、附件和本机文件版本；
• 保存结构锚点、人工决定、审计记录和持久撤销；
• 生成普通版、原生修订版、预览版、风险清单和交付包；
• 调用本机能力完成安装诊断、升级、回滚、备份和恢复；
• 把最终文件交给实际安装的 Word 或 WPS 验证。

这条路线更重。它意味着我们不仅要做 AI，还要面对 Windows 运行时、Electron 安全边界、本地密钥加密、OOXML、异常恢复、Office 兼容、安装包、代码签名、升级回滚和生产 UAT。

但真实用户的工作不会在模型返回最后一个 token 时结束。对标书来说，后半程恰恰是最容易出事故的部分。

本地只是边界，专业性还要靠可验证的审核内核

把软件装到本地，并不会自动让 AI 更懂技术标。

如果仍然只是把整份文档扔给一个通用模型，本地版同样可能写出空话、漏掉评分点、混入旧项目事实，或者给出无法核验的规范结论。

因此，我们最近补的并不只是桌面界面，而是一套能说明“AI 到底做了什么”的审核内核。

当前技术标正文审核按 8 个领域维度、16 个原子审核点组织，不只看段落文字，还覆盖标题、章节、表格和图片。语义分析模型与独立质疑模型要返回实际响应身份；工作台记录正文覆盖、图片是否真的以像素进入模型、使用了哪些规则、有没有取得规范证据、哪些意见由多路结果交叉印证，以及为什么仍需人工处理。

更重要的是，系统不能为了显得“技术很多”，默认把向量检索、重排和 GraphRAG 全部打开。最近一轮消融验证没有证明规范检索能带来稳定的增量价值，因此当前运行策略会关闭低相关条文的自动注入，保留确定性规则、双模型正文审核和人工复核。

少用一项看起来先进的能力，有时比把噪声送进模型更专业。

下面是六阶段工作台的脱敏回归画面。相较此前只有候选和采纳按钮的版本，它已经把“资料与事实”放在第一阶段，并加入 AI 分析与独立质疑异常台；事实尚未补齐时，内容不会进入后续章节 AI。图中的文档、模型名称和正文均为测试样本，不是客户项目。

这张界面之后的实现又补充了正文覆盖、图片像素输入、规范证据、检索门控和人工复核原因等回执。当前通用审核知识包仍是候选版本，尚不能据此自动宣称合规。

更难的一步：让一次修改可证明、可写回、可撤销

我们不是一开始就敢让 AI 原位修改整份 Word。

早期更稳妥的做法，是保留原 DOCX 母版，只在文末追加优化内容和复核清单。原因很具体：当时的编辑视图并不保留 Word 段落 run、表格单元格、节、页眉页脚和编号定义等锚点。若把编辑后的纯文本全量写回，版式破坏和正文重复都无法控制。

下一步才是给段落建立稳定身份，让用户采纳的建议能够插回目标位置；再往后，才逐步补上章节和表格动作、定位失败阻断、候选与人工决定、持久撤销、原生修订，以及 Word/WPS 验收。

这条演进路线看起来慢，却避免了一个更危险的假进度：界面已经能改字，系统却不知道它改的是 Word 里的什么对象。

安全写回的第一步，不是调用一个“替换文本”函数，而是先把 AI 结果和正式正文分开。

一条 AI 建议应当先作为候选存在。编制人员需要同时看到原文、建议稿、依据和可能的风险，再决定采纳、拒绝、人工修改，还是继续核对。高风险内容还可以交给第二个模型独立质疑，检查是否遗漏招标要求、引用了不足以支持结论的依据，或者把尚未确认的条件写成了承诺。

模型之间意见一致，也不等于内容自动生效。最终决定仍然属于负责这份标书的人。

一条可以进入工程流程的写回记录，至少要回答五组问题：

1. 问题与来源：这次修改来自哪条审查意见、哪项招标要求或哪个已确认项目事实？
2. 候选与质疑：AI 给出了什么建议，独立质疑发现了什么，哪些风险仍未关闭？
3. 人工决定：谁在什么时间采纳、拒绝或修改了候选，留下了什么说明？
4. 目标与动作：修改的是哪个章节、段落或表格单元格，执行替换、插入还是删除？
5. 结果与恢复：普通版和修订版怎样体现这次变化，保存重开后能否追溯，必要时怎样撤销？

这五组信息把一次 AI 回答变成一项可审计的文档操作。

DOCX 不是装着文字的空盒子

人看到的是几十页或几百页标书，程序面对的却是一组彼此关联的结构。

正文可能被拆成多个文字片段，每个片段带着不同字体、字号、加粗和语言设置。标题依赖样式与大纲层级，列表编号由另一套定义控制。表格有合并单元格和跨页规则，图片通过关系文件引用，页眉页脚按节组织，目录和交叉引用则依赖字段。

这也是为什么“抽出正文—交给 AI 重写—重新生成一个 Word”经常会出问题。

内容也许还在，原文档多年积累的结构却很容易丢失：编号从中间重新开始；标题看起来一样，却已经不属于原来的标题体系；图片仍在文件包里，正文引用已经断开；表格内容正确，跨页后表头不再重复；目录还在，页码却没有刷新。

解决它，需要在导入时为章节、段落、表格和关键块建立稳定锚点。用户采纳候选后，写回动作携带目标锚点和操作类型，明确它要替换哪一段、插在什么位置、修改哪个单元格。

原文被后续编辑、锚点失效或目标不再唯一时，系统应该停止写回，让问题回到人工处理。

“找不到位置就追加到文末”不算降级成功。它会让一段看起来正确的内容脱离原章节、编号和上下文，还可能在交付前悄悄形成重复承诺。

安全的含义不是程序永远不失败，而是它不会在无法证明位置正确时假装成功。

原生修订不是把新文字标成红色

很多所谓“修订版”，只是把修改后的文字换一种颜色，或者另存两份文件让人肉眼比较。这样做能提示“这里可能变了”，却不能让 Word 把它识别为可接受、可拒绝的原生修订。

Word 的修订记录属于 DOCX 内部结构。插入与删除要以 WordprocessingML 修订节点保存，并带有作者、时间等信息。段落属性、表格行、单元格格式和页眉页脚中的修改，还可能使用不同的结构表达。

难点不只是生成 w:ins 和 w:del 两个标签。

一段人眼看到的连续文字，在文件内部可能被拆成多个 run。替换时既要形成正确的插入和删除，又不能误伤未修改的加粗、斜体、域、超链接、图片和段落属性。表格单元格里既可能有多段文字，也可能有图形；删除视觉内容和只替换普通文本，风险完全不同。

因此，修订版至少要通过两项比对：

• Word 能识别并逐项接受或拒绝修改；
• 接受全部修订后的内容，与普通版的目标结果一致。

前者服务人工复核，后者服务自动一致性检查。二者都不能由一份“红色文字版”替代。

一份改过的标书，为什么要形成四类产物

普通版 DOCX 用于继续编辑和形成交付稿。它应当保留修改后的完整内容，并尽量延续母版中的样式、编号、表格、图片和页眉页脚。

修订版 DOCX 用于负责人复核。新增、删除和替换应以 Word 能识别的原生修订呈现，接手人可以查看、接受或拒绝变化。

接受修订预览版 用于自动比对。它展示所有修订合并后的内容状态，帮助检查修订版与普通版是否一致，但不能替负责人作出接受决定。

风险清单 保存仍未关闭的问题：缺少项目依据、承诺性措辞、待核规范、未响应要求、位置不确定项，以及只能在 Word 或 WPS 中确认的版式问题。

真实工作台还会把“尚不能交付”直接显示出来。下面的脱敏画面中，项目名称仍缺少可用来源，阶段风险稿尚未生成；用户可以看到普通版和修订版入口，却不能把未关闭的事实缺口当成完成状态。

上面的工作台画面展示的是交付前的运行状态：事实缺口还在，系统就把风险暴露出来，不让“文件已经生成”掩盖“内容尚未闭环”。

等这些门禁逐项关闭，系统也不应该只吐出一个名字叫“最终版”的文件。为了让继续编辑、修改审批、一致性检查和遗留风险各自有明确载体，安全写回需要形成下面四类相互关联、又不能互相替代的产物。

四类产物并存，才能同时回答四个问题：现在可以继续编辑什么，具体改过什么，合并后是否一致，还有什么不能放过。

把它们混成一个“最终版”，会让内容交付、修改审批和风险收口相互遮蔽。

自动测试、Word/WPS 和真实使用者，谁也替代不了谁

DOCX 本质上是一个包含多份 Open XML 文件的压缩包。自动化检查可以拆开它，核对正文、样式、编号、关系文件、页眉页脚、标题和表格节点是否仍然存在；也可以验证锚点是否命中、有没有发生兜底追加、修订插入与删除是否形成，以及接受修订后的内容是否一致。

这些检查速度快、可重复，能挡住大量结构性回归。

但自动测试看到的是文件结构，不是 Word 最终渲染出来的每一页。

目录有没有更新，页码是否正确，复杂表格怎样跨页，图片怎样环绕，分页是否把标题和正文拆开，仍要在真实 Word 或 WPS 环境中打开后判断。验收记录还必须写明实际使用的软件，不能把兼容接口识别成另一个产品。

在一份脱敏的大体量验证样本中，我们记录了 99 页、70 张表、10 张内嵌图片和 181 个域，并完成了真实 Word 保存、关闭和重开核对。这个结果只能证明该样本和当次版本通过，不能外推成“所有标书模板都兼容”；WPS 的修订回归也属于另一轮证据，不能拼成一张“同版双 Office 全通过”的证书。

三层证据各自回答不同问题：

• 自动化结构检查证明文件和程序行为符合约定；
• Word 或 WPS 原生检查证明文件能够真实打开、更新和复核；
• 独立生产 UAT 证明投标人员能在没有研发代操作的情况下把工作做完。

研发人员用熟悉的样例成功导出，只能证明工程链路可运行。生产 UAT 还要验证普通用户能否独立完成资料导入、章节和表格修改、AI 候选处理、保存重开、异常恢复、普通版与修订版导出，以及 Word 或 WPS 的最终复核。

其中一层通过，不能替代另外两层。

这条路很难，但值得做

如果只追求“几分钟生成上百页”，做一个网页生成器会轻得多。

我们选择本地工作台，是因为真实标书的终点不是网页预览，而是原始资料不失控、项目事实不乱串、每次修改有人决定、复杂母版不被轻易破坏、交接人能看见修订、失败可以恢复，最后还能回到 Word 或 WPS 完成责任签收。

这要求产品把 AI、工程文档、桌面软件和交付治理接在一起。难度大、进展也不会像增加一个提示词按钮那样显眼，但它更接近投标团队愿意长期使用的工具。

截至 2026 年 7 月 31 日，Windows 技术标本地工作台候选版本仍为 0.9.0-pilot.1，发布判断仍是 HOLD。当前工程包尚未完成正式代码签名；陌生真实标书的人工验证和独立外部 UAT 也没有全部闭合。本文介绍的是已经形成的技术路线、当前实现和验收边界，不是生产发布公告。

我们也不承诺 Word 或 WPS 的最终版式零人工收尾。目录、页码、复杂表格、图片、承诺性表述和业务依据，仍需在交付前由人确认。

我们希望大家期待的，不是又一个能生成长文的页面。

而是一套愿意对原文件、修改过程和最终交付负责的本地工作台。

参考资料

以下资料均可按机构和标题检索：

1. Ecma International：ECMA-376 Office Open XML File Formats。
2. Microsoft Learn：Use Office Open XML (OOXML) in Word add-ins for rich content insertion。
3. Microsoft Support：Track changes in Word。
4. MDN Web Docs：File System API。
5. 筑见合规：产品端边界与本地工作台分层、Windows 技术标本地工作台当前产品真相、试点交付说明与生产 UAT 操作规程。

如果你的团队也在处理复杂 Word 标书

欢迎通过文末入口或平台私信，告诉我们最容易改坏的模板类型、常见结构问题，以及主要使用 Word 还是 WPS。无需发送客户正文，我们会先判断这类问题是否适合进入后续的脱敏验证。

关注我们

欢迎搜索并关注 筑见实验室，获取更多建筑 AI、数字化工具与工程工作流实践：