一份看起来完整的结果，可能少了半张清单
假设团队让AI逐项检查一批合同附件，输出结构化结果。返回内容可以正常解析，每条都有名称、结论和理由，界面也顺利展示，但其中几份附件根本没有被处理。没有报错不等于任务完成，这是假设场景，却指出了验收中很容易混淆的两个层次：格式与覆盖范围。
格式检查回答结果是不是系统能读的形状，完整性检查回答该做的事情是否都做了。一份数组即使只有一条，也可能完全符合字段结构。企业不能仅因为解析器没有异常，就把任务状态标记为成功，更不能让后续审批默认它已经审查了全部输入。
在调用之前，先保存一份预期清单
完整性不能只靠读结果猜。流程应先记录本次需要处理的对象及其稳定标识，例如附件编号、记录编号或明确的检查项。清单由业务输入或规则产生，而不是让模型完成后自行声明“这些就是全部”。没有事先定义的范围，系统很难判断结果究竟漏掉了什么。
如果任务要求从材料中发现未知项目，不能提前列出全部结果，也仍可以定义边界：覆盖哪些文件、哪些章节、哪些规则，哪些内容允许无法判断。不要为了方便检查而假装所有任务都有固定答案数量。完整性标准应适合任务性质，必要时把人工抽查纳入验收，而不是制造虚假的确定性。
输入清单还应带版本。用户在处理过程中追加了材料，旧任务完成时不应被当作已经包含新内容。保存本次输入快照的标识与范围，让结果能够对应到实际处理对象。这里不要求把所有敏感原文写入日志，关键是有足够的关联信息供授权人员核对。
结果回来后，检查集合关系而不仅是数量
先验证返回的每个标识是否来自本次输入，再检查有没有重复、缺失或无法识别的对象。只对比总条数不够：少一项、多一项，数量仍可能一致。对业务流程而言，处理错对象和漏掉对象都不能被当成通过，必须明确列出差异，供系统补做或人工处理。
每个对象还需要自己的完成条件。字段齐全但理由为空、结论写“无法判断”却被计为通过，都会让总体状态失真。可以区分已完成且可用、已处理但需人工判断、执行失败和未开始。状态名称可以按业务调整，但不要把不同含义都塞进一个成功布尔值。
对于生成型任务，完整性还包含必需章节和证据范围。一个总结有开头与结尾，并不证明它讨论了所有要求。可以让规则检查显式章节，再由抽样或人工审核检查内容是否真正回应问题。结构校验负责可自动确认的部分，不能冒充对语义质量的全面保证。
区分正常结束、输出截断和业务完成
具体接口可能提供终止原因或输出状态，接入时应按所用服务文档解释。不能假设所有平台字段一致，也不能仅凭网络请求成功就忽略生成状态。若出现长度限制、连接中断或未完成输出，应先按未完成处理，再判断是否能够补做，避免把最后一个完整段落当成整项任务的结束。
即使接口正常结束，业务也未必完成。模型可能主动省略它认为重复的项，也可能对要求理解不足。因此终止状态是一项必要线索，不是业务覆盖的替代证明。项目应把接口层、数据层和业务层检查串起来，每一层只作证据能够支持的判断。
流式显示时尤其要防止过早触发下游。页面已经显示了几段文字，用户会感觉任务正在完成，但后台不应据此启动正式写入或通知。将中间展示与最终确认分开，只有约定条件满足以后才解锁依赖完整结果的动作，能减少半成品被误用的机会。
补做缺项，不要让重跑覆盖已确认结果
发现缺项后，可以仅对缺失对象发起补做，但前提是任务允许独立处理，且能够保持输入版本一致。补做结果合并时仍要核对标识与重复，不要因为来源是第二次调用就默认可靠。对于相互依赖的分析，则需重新检查整体一致性，不能简单拼接文本结束。
已经人工确认的内容应有保护规则。整体重跑可能改变原先正确的结论，若系统静默覆盖，审核记录就失去了对应对象。可以保留结果版本，让使用者看到哪些项补充、哪些项改变、是否需要重新确认。这样修复漏项不会顺便制造一批难以发现的新变化。
若决定交付部分结果，应明确列出完成范围、未完成范围及不能据此作出的决定。比如只处理部分附件，就不能把页面顶部写成“全部审查完成”。用户有时可以接受暂缺，但需要知道缺在哪里，以及下一步谁负责。准确的未完成状态比一个看似漂亮的总成功提示更有价值。
用能骗过格式校验的样例验收
测试时可以准备格式完全正确但故意漏一项、重复一项、替换成未知标识的结果，确认流程会拦住它们。再加入空理由、无法判断、接口正常结束但覆盖不足等情况。这些测试不需要真实客户材料，用清晰可控的样例就能验证状态逻辑与差异提示。
还应检查补做后的合并、输入版本变化以及人工确认保护。业务人员参与验收时，不必阅读所有技术字段，可以直接看系统能否告诉他还剩什么、当前结果能否使用、再次运行会改变什么。若这些问题回答不清，说明完整性规则还停留在开发内部，没有进入实际工作流程。
把预期清单、结果差异、补做记录和最终确认放在一条可追溯路径上，AI输出才有机会成为可靠的业务输入。结构化只是方便系统接收，完整性验收才让团队知道这次工作究竟做到哪里。两者一起设计，才能避免“没有报错”被误当成“事情已经办完”。
要点总结
- 不保证。还应核对本次输入范围、必需项、重复项以及每项的业务完成条件。
- 不够。应按稳定标识检查集合差异，数量一致也可能同时存在漏项与重复。
- 取决于业务要求。允许时也应明确完成范围、缺项和使用限制，不能显示为全部完成。
参考来源说明
本文提出可供业务团队评估的方法，示例不代表真实客户项目。官方资料仅用于核对对应技术机制，站内服务页用于了解业务范围，不作为效果证明。