项目交付资料太多，Agent 怎样核对缺少哪份验收附件

项目资料核对 Agent 适合处理一项明确任务：对照被双方确认的交付清单，指出哪份附件缺少、哪份版本不匹配、哪项还需要人工复核。它不应该仅凭文件名里出现“验收”两个字，就宣布项目已经满足验收条件。

以下项目、文件与要求都是合成演示。本文只讨论工程资料整理，不能替代客户的正式验收决定。实际项目应以双方确认的范围和适用要求为依据，不由模型自行增加合同义务或删减必交项。

先把交付清单变成规则表

一行规则对应一个可以被核对的交付件，保存编号、名称、适用条件、版本要求、责任人、需要检查的内容和通过方式。例如“部署说明”不能只要求有一个PDF，还应确认其对应已交付版本、包含环境前置条件，并有重新部署的核对记录。

要分清必交与条件适用。项目没有接入外部身份系统时，不能把“单点登录联调报告”当成所有项目的缺件；一旦客户确认有这一范围，又不能因为目录里没找到就自动改成不适用。适用性由项目范围决定，文件存在性不能反过来定义范围。

把机器可以判断的条件与需要人工判断的内容分开。扩展名、版本号和签字状态通常可以形成明确检查项；方案是否充分、测试覆盖是否满足业务目标，则需要有职责的人员复核。报告应说明检查了什么，而不是输出一个无法解释的“合格分”。

为文件记录项目编号、相对路径、资料版本、文件大小或哈希、接收时间和来源人。文件改名后仍应能查到原来的记录；同名不同内容的两个版本不能被后一份无痕覆盖。

W3C的PROV来源信息概述解释了实体、活动与参与者的来源记录用途；工程资料台账可以采用较简单的字段实现追溯，不必为了做缺项核对引入复杂平台。

对于压缩包，先列出内部文件清单再核对。仅看到“项目全套资料.zip”并不能说明必交件齐全。加密文件、损坏文件或无法解析的扫描件，要标为暂无法检查，与没有文件区别处理。

“待人工复核”并不等于不合格，也不等于通过。报告可以同时显示已完成的机械检查、仍缺的依据和建议责任人。这样客户能知道下一步由谁处理，而不是得到一份只有红色警告的长表。

下载交付资料缺项样例。附件中部署说明、恢复记录和联调报告分别演示版本不符、文件缺失与条件适用。把自己的交付范围填好后，可以先由人工做一遍标准核对，再比较Agent生成的报告。

“测试报告最终版”可能没有运行记录，“已签字”可能只是文件名中的备注。内容核对需要查看真实页面或可解析正文。无法识别签章时，应写明需人工确认，不能推测电子签名有效或给出法律效力结论。

资料之间也需要一致。说明里写的端口、模型版本、部署方式应与交付配置对应。恢复记录引用的备份若属于旧项目，即使文件完整，也不支持当前系统能够恢复。跨文件的一致性比凑齐一组看起来正式的名称更有用。

如果需要读取客户代码和配置，先约定可访问范围；密钥和个人信息不进入公开报告。报告可以引用配置项名称或脱敏摘要，具体值由授权人员在项目系统内核对。附件链接失效时，标明不可达，不把“有链接”当作“文件已收到”。

先提交故意不完整的合成目录，核对系统是否准确区分缺失、版本不符和不适用。随后补交一份正确文件，检查报告是否只关闭对应问题，是否保留旧记录与复核时间。若每次重跑都生成全新报告却无法对比，团队仍然难以跟踪补件进度。

最终交付的报告应包括规则版本、检查文件集合、自动检查范围、未完成事项和人工确认记录。它是帮助验收的材料，不是替客户签字。只有业务方按约定流程确认后，系统才可以标记该阶段已完成。

同一个版本问题不应在每次重跑时变成新的待办。可以将规则编号与资料标识作为问题关联键，记录首次发现、补交、复核和关闭的过程。若资料范围变了，先更新规则版本，再解释哪些问题不再适用。这样客户看到的是一份可以跟进的补件清单，而不是每次运行都重新排列、无法对应责任的错误集合。

资料复杂时可先参考文档整理方法和文档处理场景。想定制缺项核对流程，可以在咨询页提供一份脱敏交付清单、示例目录和人工核对结果，先验证规则表与报告，再考虑接入项目管理系统。