办公 AI 的常见误差，往往从模型看到文档之前就开始了：表格中的列名丢了，批注混进正文了，脚注里的限制条件被截断了。等模型接到一段看似完整的文本，它可能已经失去了判断业务含义所需的关系。
因此，可靠的实现链路需要连续回答三个问题：原文的结构是否保留下来？生成结果是否符合数据与业务规则？结果是否具备进入下一步工作流的条件？任何一个环节缺位，都可能让“提取成功”与“任务完成”之间出现明显落差。
一、结构保真：让模型知道一句话属于哪里。文档的含义不仅来自文字，也来自位置、层级和关联关系。标题决定段落讨论的范围，表头决定数字的含义，列表层级表达条件与从属关系，引用块区分他人观点与正文陈述，批注则可能记录尚未确认的修改意见。
资料《办公软件开放AI接口：形态、实战与避坑指南》指出，办公文档包含标题、表格、列表、引用块和批注；接口传递上下文时如果将这些结构拍平成纯文本，会使模型难以理解表格与相邻段落之间的关系。该资料提出，可以通过 Markdown、JSON 或接口支持的结构化上下文参数保留文档元素。
这意味着，预处理阶段的目标应包括“保留关系”。例如，下面是一份用于说明结构问题的假设性表格：
| 部门 | 本期费用（万元） | 上期费用（万元） |
|---|---|---|
| 技术部 | 90 | 100 |
如果提取结果只剩下“技术部 90 100”，模型需要猜测两个数字分别代表什么；如果单位也被丢弃，后续报告还可能出现数量级错误。保留表头、单位及其归属，才能为计算和解释提供依据。
对于摘要、改写等以阅读为主的任务，Markdown 通常便于表达标题、列表和简单表格。对于字段提取、校验和工作流执行，可以设计 JSON 中间表示，显式记录元素类型、来源位置及关联对象。具体采用哪种形式，应取决于下游需要检查什么。
一个可供实现参考的文档元素结构如下，字段为设计示例：
{ "document_id": "doc-example", "version": "v1", "element_id": "table-01", "type": "table", "section_path": ["经营分析", "费用变化"], "source_location": { "page": 3 }, "unit": "万元", "columns": ["部门", "本期费用", "上期费用"], "rows": [ ["技术部", "90", "100"] ], "related_notes": ["note-01"] }其中，element_id用于定位原始元素，section_path保存章节归属，related_notes连接表格与说明。这些字段能够支持结果追溯，也方便程序在模型输出后重新读取对应数据进行校验。
二、异构文件：先统一表达，再处理业务含义。办公任务通常涉及多个来源：正文描述需求，邮件补充条件，PDF 提供合同依据，图片包含附件信息。不同文件的解析结果，需要进入一套可比较、可追溯的中间表示。
资料《【深度分析】ServiceNow：借力AI驱动工作流自动化，推动企业价值跃升》将读取、理解和提取文档、PDF、电子邮件、图片等多种格式的信息，列为 AI 代理所需的能力；该文还介绍，Now Assist 可以总结文档、支持工单和邮件，并生成智能回复。这说明，企业工作流的内容入口具有多种形态，但这些能力描述本身不能证明某个具体任务已经达到所需的准确性。
工程上可以为不同格式配置各自的解析入口，再统一输出文档、章节、段落、表格、批注、附件等元素。图片或扫描件如果需要识别文字，也应继续保留其文件来源和页面位置，方便复核。
统一过程中有几项关系尤其需要保存：
- 正文与批注的关系：批注可能是建议或疑问，需要明确标记其身份。
- 邮件与附件的关系：附件中的条件可能只适用于特定邮件或业务对象。
- 表格与脚注的关系：单位、统计范围和例外说明会影响数字解释。
- 不同版本的关系：应依据业务指定的版本选择规则确定有效内容，避免直接拼接后交给模型自行判断。
当一次请求无法容纳全部内容时，分块也应尽量以章节、完整表格或业务对象为边界。只按固定字符数切割，可能把表头与数据行分开，把条款与例外条件分开。跨块引用则需要携带必要的关联内容，否则结构虽然保存在系统中，模型实际收到的上下文仍然不完整。
三、字段校验：让输出成为可检查的数据。结构化输入之后，还需要结构化输出。直接让模型生成一份措辞流畅的分析报告，会把数据提取、计算和表述揉在一起，增加检查难度。
更容易落地的方案是先要求模型输出候选事实，再由程序校验，最后根据通过校验的事实组织文字。候选事实可以包含字段值、单位、来源元素、来源版本，以及“待确认”状态。
字段校验可以从三层展开：
- 格式层：日期能否解析，金额能否转换为数值，必填字段是否缺失。
- 取值层：币种、部门、工单状态等是否属于允许范围。
- 业务层：起止日期是否合理，审批条件是否满足，所引用的文档版本是否有效。
这些规则需要业务方明确给出。例如，“缺少付款期限时暂停处理”应成为可执行条件。仅在提示词中写“请仔细检查”，难以替代稳定的字段约束与流程控制。
遇到来源缺失或冲突时，输出协议也应允许模型返回“无法确定”，并附上冲突位置。强制所有字段都有值，容易让信息不足被掩盖在完整的输出格式之下。
四、数字交叉验证：把计算结果与文字结论一起检查。数字问题既可能来自读取，也可能来自计算或解释。模型即使复制了正确的数值，仍可能把下降写成增长，把环比写成同比。
《办公软件开放AI接口：形态、实战与避坑指南》建议，对涉及数字、日期、合同条款、法律法规的生成内容进行规则校验或人工复核，并提到数字交叉验证可以作为质量兜底手段。
沿用前面的假设数据，本期费用为 90 万元，上期为 100 万元。按以下公式计算：
变化率 =（本期值 - 上期值）/ 上期值 =（90 - 100）/ 100 = -10%程序可以独立计算变化率，再检查生成文本中的方向和数值是否一致。如果结果写成“费用增长 10%”，即使句子自然，也应进入修正流程。
计算之前，还要确认两个数值是否具有可比性：指标含义、统计周期、单位和统计范围是否一致。对于上期为零、数据缺失或口径不一致的情况，需要设置单独的处理规则。公式正确，只能保证特定输入下的运算正确，不能保证输入具有业务上的可比性。
五、人工复核：围绕证据检查关键结论。人工复核最有价值的对象，是规则难以充分覆盖、同时会影响业务决策的内容，例如合同条款解释、多个文件之间的冲突，以及例外条件是否适用。
复核界面应把生成结论与依据放在一起，至少展示原文位置、引用版本、提取字段、计算过程和未通过的规则。这样，审核者可以快速定位争议，而无需重新通读所有附件。
审批也需要绑定具体版本。可以将输入文档版本、生成结果版本和审核状态一并记录；当关键输入变化后，重新判断已有审批是否仍然有效。否则，已经审核的内容与实际执行的内容可能发生偏离。
六、工作流执行：让通过校验成为明确的前置条件。文档理解负责提供候选事实，规则与人工复核负责确认可用结果，工作流系统再根据确认后的状态执行动作。三者之间需要清晰的接口。
一种可采用的状态流转是：
已解析 → 已提取 → 校验通过 → 待审核 → 已批准 → 已执行校验失败应进入修正或补充材料流程，审核未通过应记录原因。对于创建工单、更新业务字段等动作，还应使用任务标识防止重复执行，并保留执行结果，便于追踪。
权限也属于这条链路。《办公软件开放AI接口：形态、实战与避坑指南》区分了服务账号调用与用户身份调用：前者使用应用自身的权限，后者继承调用用户的权限。实际接入时，需要将读取来源文档与执行业务动作所需的权限分别核对，并遵循最小权限原则。
七、适用范围与局限：按任务风险确定自动化深度。这套方法适合来源明确、字段相对稳定、业务规则能够表达的场景，例如周报数据汇总、工单分类、邮件待办提取，以及合同关键字段初筛。对于这些任务，结构化上下文能提供证据基础，程序规则能检查明确约束，人工审核能处理例外情况。
它仍有边界。复杂排版可能解析错误，扫描件可能缺字，多文件可能存在冲突，业务规则也可能尚未形成统一定义。Markdown 或 JSON 可以保留已经识别出的关系，但无法自动补回解析阶段遗漏的信息；字段格式全部通过，也不能证明法律解释或业务判断正确。
落地时，可以先选择一个范围有限的任务，例如“从指定版本的费用表提取数据，计算变化率并生成待审核说明”。围绕它建立来源定位、字段校验、独立计算和审核记录，再逐步扩大自动执行范围。每增加一种文件格式、一类业务规则或一个执行动作，都检查其输入依据与失败处理方式，才能让办公 AI 的能力边界保持清晰。
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。
- 办公软件开放AI接口：形态、实战与避坑指南
- 【深度分析】ServiceNow：借力AI驱动工作流自动化，推动企业价值跃升
