去年年底一个市政项目同事的技术标在符合性审查环节被评标专家当场圈了三处目录里三“后面直接跳”五“正文第四章的条款编号从4.2.3直接接到4.2.5”更扎眼的是一句详见第三章第 5 节评委翻遍第三章只有 4 节。项目没因此直接废掉但质询记录里那句文件编制不严谨最后在分数上真真切切兑了现。事后复盘三处全是多轮插拔章节、三个人接力改稿留下的疤。这是标书岗的通病文档越长编号系统越脆弱。Word 的自动编号经过几轮跨文档拷贝、不同模板互灌之后断档、重号、层级跳变几乎是必然事件。靠人工逐节核对四五百页的标书要耗掉整整两天还不敢保证捞得全——人眼对编号的敏感度下午三点以后直线下降。我现在把这类活交给察元AI文档助手一个跑在 WPS 文字里的开源加载项Apache-2.0 协议外加一个本机 MCP 文档智能体服务。它不是在聊天窗口里给你贴一段建议让你自己找位置而是真的能读文档、钉批注、动表格。都说 AI Agent 办公落地落到标书岗头上最实在的形态就是这种能直接进文档干活的。第一层内置助手扫序号体例装好之后 WPS 顶部多一个察元选项卡内置 29 个助手其中一个名字就很直白叫「检查段落序号格式」。选中要查的章节点一下问题以批注形式钉在对应段落上。注意是批注不是直接改正文——封版前的标书任何工具未经我确认就改我的正文我都不敢用。批注输出、人工定夺这是我的底线恰好也是这个工具的默认姿态写操作不带确认参数时只返回预览不写盘。体例问题扫出来之后再配合「文档审计助手」看一遍书签级的结构状况哪个章节层级明显不对劲基本一眼就能扫出来。第二层MCP 查交叉引用序号体例只是第一层更深的一层是交叉引用。“详见第 X 章第 Y 节”见附件 3见下表 5这类句子必须逐条验证目标真实存在而这类句子在一本标书里能埋几十处人工查起来最磨人。我的做法是用 Claude Code 直连察元在本机起的 MCP 服务claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62588/mcp服务只监听 127.0.0.1标书从头到尾不出本机。标书岗对文档上云天然敏感这个本机即信任边界的设计很合心意。连上之后 46 个文档工具可用。四五百页的标书直接全文读取会触发 DOCUMENT_TOO_LARGE正确姿势是先 document_meta 看字数和段数再用 document_chunks 分块过document_locate 负责定位详见见附件这类句式返回命中锚点然后让 Agent 逐条核对目标章节或附件存不存在。偶尔稿子改完之后锚点对不上工具会返回 LOCATE_MISMATCH 或 LOCATE_NOT_FOUND重新跑一遍就好不要硬来。提示词我常备两条可以直接抄检查标题/条款序号一、一、1.是否层级混乱批注指出把正文里所有详见第X章见附件X的引用列成清单逐条验证目标章节或附件存在对不上的用批注标在原句上批量写回同样有保护document_apply_ops 一次最多 200 条操作不带确认参数只给预览批注类操作必须显式确认才落盘全程不会出现AI 自己动了手的惊吓。改完再跑一遍确认清零批注清完、序号改完之后我固定再跑一轮确认清零。第一轮报告里经常混着误报——报价表、合同条款页的编号体系本来就是独立体例工具照实标出来第二轮要靠人分辨哪些是故意的独立编号哪些是真断档。这一步的判断没法外包给机器。这套检查现在是我们组交标前的固定动作工具十分钟跑完的事过去要一个人盯两天。边界也要说清楚编号检查只是形式自查的辅助招标文件对编号体例有专门约定的比如固定三级编号一律以招标文件和代理机构要求为准。投标专员、标书编写团队、商务支持岗——所有对形式审查四个字有阴影的人都值得把它排进交标前的工作流。形式分这东西丢起来最冤捞回来最便宜。