先说一个让信息科同事哭笑不得的场景让 AI 从合同里抽字段甲方乙方、金额、签订日期AI 输出了一段文采飞扬的总结人看着舒服可 OA 表单要的是机器能解析的结构化数据。于是又回到人肉复制粘贴的老路AI 只贡献了个开头。AI Agent 办公落地的关键一环不只是人看懂 AI 的结果更是系统接得住 AI 的结果。这篇讲讲怎么用察元AI文档助手 建一个输出 JSON 的助手把结果直接交给 OA 和脚本。先看两个内置的样板。察元自带的表单智能提取助手就是干合同、公文抽字段输出 JSON 这件事的拼写与语法检查输出的也是结构化 JSON 问题列表。照着这两个的思路建自己的专属抽取助手方向就不会跑偏。第一步建助手定两项关键配置在自定义助手里新建两项配置是灵魂输出格式选 JSON写回动作选仅生成结果——结果不落盘谁调用谁拿走正好适合给下游程序消费。模型按场景选涉及合同、内部数据的建议配 Ollama、LM Studio 这类本机或内网端点数据不出域。第二步系统提示里锁死结构JSON 助手的命门在系统提示必须把结构写死、把废话禁掉。给一个可直接抄的模板从选中的合同内容中提取字段严格按此 JSON 结构输出{甲方:,乙方:,合同金额:,签订日期:,履约期限:}。找不到的字段填 null禁止输出 JSON 以外的任何文字包括解释和代码块标记。三个细节别省给全字段示例空字符串占位规定找不到怎么办填 null别让模型自己编禁止附加文字多一句以下是提取结果解析就可能挂。第三步输入来源圈定范围输入来源选仅选区。抽取这件事范围越明确越准——圈住合同首部抽签约信息圈住付款条款抽账期信息。全文输入反而引入噪声模型容易把不同章节的同名字段混着填。第四步试跑校验拿三份格式差异大的真实文档各跑一遍字段齐不齐、结构稳不稳、有没有偶发的多余文字。这一步别省上线后发现格式漂移再排查成本翻好几倍。第五步脚本接住带容错脚本侧解析 JSON 时做好两件事解析失败自动重试一次模型偶发格式漂移是常态重试通常就正了字段缺失时告警而不是静默吞掉宁可让人看一眼异常也别让空数据悄悄进了库。走 MCP 通道的脚本还有现成的机器可读接口校对工具默认 dryRun 只返回问题列表异步任务可以轮询查询状态整条链路都不需要解析人话。三种典型漂移见招拆招第一种多嘴输出 JSON 前后带解释文字。对策是解析端先做剥壳处理截取第一个左花括号到最后一个右花括号之间的内容再解析失败就带着错误信息重试一次通常就正了。第二种字段漂移把签订日期自作主张写成签约日期下游字段名对不上数据悄悄丢。对策是系统提示里字段名逐一列死试跑阶段专门核对字段名的稳定性。第三种硬编字段找不到时模型现编一个值填上这是最危险的一种。对策就是那句找不到的字段填 null加上线后的人工抽检——宁可空值被发现也别让编造值混进业务系统。再补一句部署层面的事实脚本和智能体走 MCP 对接时服务地址是本机的 http://127.0.0.1:62588/mcp健康检查访问 healthz 返回 online 即链路通畅服务只监听本机回环地址抽取过程的文档数据不出机器。在合同、公文这类敏感场景里这一点和 JSON 输出本身一样值钱。适用人群与边界这套玩法适合的单位画像很具体有 OA 或内部系统要接 AI 输出的信息科、做办公自动化脚本的 developer、要批量处理合同和公文表单的行政法务。边界也说实在话JSON 化解决的是接得住不解决抽得对——模型可能漏抽、错抽关键字段上线前必须人工抽检抽取结果进正式系统前留一道人工确认的闸门。结构化是让 AI 进入业务流程的门票但流程的责任主体始终是人。