会写，是标书 AI 最容易演示的能力。
但做标书的人更担心另一组问题：招标要求有没有漏，评分点有没有承接，旧项目内容有没有残留，工期和项目名称是不是前后矛盾，AI 改过的地方能不能放心采用，最后导出的 Word 会不会在交付前出问题。
如果这些问题没有解决，AI 写得越快，复核压力可能越大。
这也是我们研发筑见合规本地技术标工作台时，越来越明确的一条产品判断：标书 Agent 的价值，不应按生成字数计算，而应看它能不能减少遗漏、错误、返工和重复核对。会写是起点，可信交付才是标准。
标书不是一篇长文章
普通写作工具关心的是“这段话怎么写”。
技术标还要回答：这句话依据什么，回应了哪项要求，使用的是哪个项目事实，是否形成了企业承诺，修改后有没有影响其他章节，最终文件是否还是当前已经审核的那一版。
同一句“工期 300 日历天”，可能出现在封面、工程概况、进度计划、施工组织和承诺章节。只改一处不够，全文替换又可能误伤。AI 即使写出一段流畅的施工方案，也可能漏掉评分办法中的一个细项，或者沿用了旧项目的地名、人员和设备。
这说明标书 Agent 面对的不是一次写作任务，而是一套持续变化的约束。招标文件会换版，补遗会改变要求，项目事实会被重新确认，人工也会在 Word 或 WPS 中继续修改。任何一个环节变化，旧结论都可能失效。
我们认为，行业下一阶段的分水岭不会是谁一次生成得更长，而是谁能说明：当前文字回应了什么，依据来自哪里，谁确认过，最后交付的又是哪一版。
所以我们没有把 Agent 设计成一个接收提示词、返回长文的聊天框。它要进入一条受控的文档生产链：
这条链路里，模型负责理解、起草和发现线索；系统负责来源、版本、状态和交付约束；人确认项目事实、关键承诺并承担最终签收责任。
第一件事：先建立依据，再开始写
一份技术标通常同时依赖招标文件、补遗、评分办法、工程量清单、旧标书、企业资料和本次项目事实。
把这些文件一次性塞进模型上下文，并不能自动得到稳定的依据。资料会换版，补遗会改变要求，旧标书里的内容也不一定适用于新项目。
因此，工作台先整理三类对象：
- 招标要求和评分点：哪些必须响应，准备由哪些章节承接；
- 项目事实：项目名称、地点、范围、工期、质量目标等，哪些有来源，哪些存在冲突，哪些仍待确认；
- 企业资料：哪些内容可以复用，适用于什么范围，使用的是哪个版本。
Agent 后续生成章节时，使用的是这些已经登记的对象，而不是依赖一次对话里的临时记忆。来源或事实发生变化，已经完成的核对也会重新进入待确认状态。
这些复杂性应该由系统承担。编标人员不需要记住内部状态机，只需要知道依据是否仍然有效、当前还有哪些问题没有关闭。
第二件事：Agent 只能提交候选，不能悄悄覆盖正文
标书里的很多句子会形成责任。工期、资源投入、施工方法、质量安全目标和规范依据，都不适合让模型直接写进最终稿后假装已经确认。
筑见合规把 AI 输出作为候选处理。用户可以比较原文与建议，选择采用、拒绝或保留备选；锁定的章节、段落、表格和指定文字不会被批量改编覆盖。资料换版、项目事实变化或历史版本恢复以后，旧候选会失去对当前稿的写入资格，但仍保留审计记录。
这样做的目标不是让用户审批更多卡片。
用户最好只需要处理少数必须由人判断的事情：哪里有问题，依据在哪里，系统建议怎么处理，这次决定会影响哪些内容。哈希、版本、候选资格、来源授权和检查点不应该变成新的操作负担。
第三件事：始终只有一份“当前稿”
AI 文档工具有一个很隐蔽的风险：模型检查的是 A，用户后来修改成 B，导出时又拿到了 C。
页面上每个环节都显示成功，最后交付的却不是那份已经审核的文件。
为避免这种错位，工作台把当前稿、来源状态、Agent 终检、导出文件和负责人签收绑定在一起。历史版本恢复后，旧任务和待审候选不能继续冒充当前进度；最终交付包生成前，系统还会重新核对实际进入交付包的 DOCX 字节。文件在终检后被 Word、WPS 或其他流程覆盖，旧的通过状态就不能继续授权外发。
这类设计不会让生成演示更炫，但它直接决定了“审核过”和“交付出去”是不是同一个结果。
第四件事：不重造 Word，也不能把 Word 留到最后
技术标里有多级编号、复杂表格、图片、页眉页脚、目录、域、分节和企业模板。重新做一个完整的 Word，投入很大，也容易把产品拖进无止境的排版兼容。
我们的取舍是：工作台完成高频编辑、事实联动、章节编写、候选审改、版本管理和交付检查；复杂排版仍允许进入 Word 或 WPS 收尾，并支持外部修改后回到工作台继续审查和生成。
近期迭代继续收拢文档侧最容易在交付时出问题的部分：普通规则表的行列维护，生成表的跨页表头、列宽和安全合并拆分，图片缩放、裁剪、位置和图注，以及页眉页脚中的已确认项目事实。这些修改都要进入同一份当前稿，并继续生成普通稿和修订稿；Office 外改回流后，还要能够接着审查和编写。
对无法安全定位的复杂对象，系统选择明确受限，而不是让界面看起来能改、导出时再损坏。
“能导出 DOCX”只是入口。能在真实 Office 流程里继续工作，才接近编标人员需要的结果。
第五件事：把机器时间和人的时间分开计算
一项 Agent 任务 10 分钟跑完，不代表它节省了 10 分钟。
如果用户还要花两个小时重新核对要求、修复格式、判断无依据内容，这个产品并没有减轻压力。一个运行稍慢、但能把问题定位到来源和章节、只让人处理高风险分歧的系统，反而可能更省人。
因此，我们后续验证不会只记录模型耗时和 Token，还要记录编标人员的主动操作时间、人工判断次数、候选采用率、Office 收尾时间，以及最终遗漏的问题。
我们把这部分称为“人的注意力成本”。它比生成速度更接近产品是否有用。
我们想把产品做成什么样
我们希望筑见合规最终呈现的，不是一排需要用户分别对话的 Agent，也不是一个把整份标书交给模型后等待结果的黑箱。
更接近实际工作的路径应该是：导入本次项目资料，确认要求和事实，围绕当前章节生成候选；系统把变化、冲突和影响位置摆到人面前，人只在需要承担责任的地方作决定。被采用的结果进入唯一当前稿，再经过终检和 DOCX 交付回到 Word 或 WPS。
对个人，它要减少翻文件、找口径和重复核对。对团队，它要把评分响应、项目事实、企业资料和人工决定沉淀成有版本边界的工作记录，而不是散落在聊天记录和个人经验里。
这也是我们愿意在底层链路上花时间的原因。产品不应要求用户理解多少 Agent、哈希或任务回执；这些工程约束最后应该变成更少的返工、更清楚的责任和一份敢于交付的文件。
目前走到了哪里
筑见合规当前是一款 Windows 本地技术标工作台。1.0.0 已进入受控定向分发边界，公开下载仍然关闭。我们没有把 Web、商务标、施工方案和整个合规平台一并包装成当前产品。
近期研发的重心，也从“再加一个功能”转向几件不太适合做演示、却直接影响可信度的事：
- 招标来源换版后，旧的审核结论、候选和任务仍可回看，但不能继续占据当前工作流；
- 单章和整标写作先绑定已保存的当前稿，已经生成的候选可以在重开后继续处理；
- 独立质疑或后续步骤失败时保留已经完成的写作成果，不自动重复发起付费写作；
- 当前稿、终检结果、实际进入交付包的 DOCX 和负责人签收使用同一套身份约束；
- 表格、图片、页眉页脚和 Office 回流继续围绕同一当前稿收口，无法安全定位的对象明确失败关闭。
这些能力已经有代码和定向回归支撑，基础版本也完成过受控的 Word 交付验收。但 9 月 21 日以来的最新迭代，还不能据此宣称已经通过真实供应商模型、完整 Electron、客户长标和 Word/WPS 全链复验。工程进展、真实使用价值和规模化产品成熟度，是三件不同的事。
还有三件事必须用真实工作证明
第一，AI 到底写得对不对。
我们需要用模型没有见过的脱敏真实标书，建立人工金标准，测强制要求召回、评分点召回、硬事实准确率、无依据承诺和旧项目残留。自动化测试通过，不能代替这些业务指标。
第二，使用者到底省了多少时间。
需要把同一份标书在传统流程和工作台流程中的阅读、找评分点、建目录、改旧标、核事实、改 AI 内容和 Office 收尾时间放在一起比较。
第三，复杂文档能不能稳定往返。
客户长 DOCX、不同企业模板、复杂表格、图片、目录、修订、Word 与 WPS，都要进入代表性验收。一次合成样本通过，不能外推到所有标书。
这三类证据没有建立以前，我们不会把“功能在代码里存在”写成“已经成为成熟产品”。筑见合规当前仍在快速迭代，本文不代表公开试用或正式商用已经开放。
我们最终想减少的，是四种成本
少漏：招标要求和评分点不再主要依赖个人记忆。
少错：项目事实、旧项目残留和无依据承诺更早暴露。
少改：AI 候选围绕当前章节和当前依据生成，减少整篇返工。
少重复劳动：同一份事实、版本和审查结果可以继续进入编辑、复核和交付。
这四项不是宣传口号，而是我们判断产品是否值得继续扩张的尺子。如果它们没有明显改善，Agent 再复杂，也只是把技术复杂度搬给了用户。
我们期待的结果，是让有经验的人把时间留给方案取舍和高风险判断，也让经验较少的编标人员不必只靠记忆和反复翻页维持质量。AI 不替人承担投标责任，但可以把责任所依赖的依据、变化和决定整理得更清楚。
如果你参与技术标编写或审核，欢迎在评论区说说最消耗时间的是哪一步：读标、改旧标、核项目事实、处理 AI 内容，还是 Word/WPS 收尾。我们会继续用这些真实问题校准产品优先级。
关注我们
筑见实验室（ArchSight Labs）关注科学学习、建筑工程、软件架构与 AI 实践，持续用内容、开源和产品实验，把复杂问题转化为可理解、可验证、可复用的能力。
