直接答案
AI 自动化 PoC，也就是概念验证，结束时应该留下能逐项查证的结果。为每个样本记录预期、实际输出、证据位置和审核意见，把失败及恢复过程接在同一条记录后面。业务负责人据此判断哪些流程已经验证，哪些条件仍然不满足，再签署本轮决定。
实解智能的服务方法把“双方约定的真实样本、预期与实际结果、异常和可追踪输出”列为验收依据。本文沿着这个要求给出一套记录方法。表格和填写方式属于操作建议，示意记录没有填入客户数据，也不代表任何项目已经通过验收。
适用边界
这篇文章写给已看过演示或试点结果、正在准备上线评审的业务负责人和项目负责人。开始填写前，双方需要约定业务范围、样本用途、审核人和放行条件。样本数量与通过标准应由项目风险和使用条件决定，这里不提供通用分数或固定上线阈值。
如果还在比较服务商与交付方式，可以先看企业 AI 自动化服务商选择与验收清单。本文集中处理检查完成后怎样留记录，以及记录如何支持下一步决定。
实施步骤
测试前，把预期写到样本旁边
先给本轮测试建立一个清楚的范围说明，写明要验证的业务动作、运行环境、系统版本，以及明确排除的动作。涉及外部发送、付款或公开发布时，列出批准这些动作的人和审批入口。演示环境没有执行真实发送，就只能记录演示范围内的结果。
样本要能定位，也要获准使用。记录样本编号、来源版本、允许的处理位置和审核人；敏感原件留在约定环境中，验收表只保存授权人员能够访问的位置。不要为了让表格看起来完整，把账号密钥、客户原件或公开下载链接放进去。
预期结果应在执行前写下。例如，一项外联流程可以要求草稿先进入人工审核，未获批准时不能继续发送。这是待验证条件。实际是否符合，要等执行和核对后填写，不能把预期复制到“实际结果”一栏。
一项结论要能找到对应的输入与输出
下面这些字段可以放在表格、工单或项目已有的验收系统中。已有工具能保存它们，就不必再维护一份内容相同的文档。
| 记录字段 | 填写内容 |
|---|---|
| 样本标识与场景类型 | 使用哪个样本，属于正常、异常、授权还是恢复场景 |
| 执行上下文 | 本次运行标识、时间、系统版本和测试环境 |
| 预期结果 | 测试前约定的输出、停止位置和人工参与条件 |
| 实际结果 | 本次观察到的输出与状态；未执行、无法确认也如实填写 |
| 证据位置 | 对应输入、输出、事件记录和必要截图的受控位置 |
| 人工复核 | 谁在何时检查了哪些证据，判断及理由是什么 |
| 失败原因 | 已查明的原因；尚未查明时保留“原因待查” |
| 恢复结果 | 从哪里恢复、谁授权、产生了什么结果，是否检查重复处理 |
| 未关闭事项 | 缺少的证据、剩余影响和处理条件 |
| 责任人 | 谁补证、谁修复或复测，最终由谁决定接受结果 |
运行标识尤其有用。同一个样本可能执行多次，只写样本编号，后来的人容易把第一次的输入和第二次的截图拼在一起。复测时保留原记录，追加新的执行标识，并说明这次改了什么。
证据也需要具体到判断依据所在的位置。知识库问答只保存一张答案截图，审核人无法核对引用来自哪份文档、哪个版本。建议同时记录问题、使用的知识库范围、原始回答及引用位置，再由业务审核人确认引用是否支持回答。
Hermes Notebook的公开说明区分了接入层身份与部门映射、检索前的知识库访问范围，以及业务负责人对引用的核对。验收记录也应分别保存这些观察，不能用“回答看起来正确”代替权限验证。
将正常、异常、授权和恢复分别呈现
正常路径说明约定输入能否产生可用输出。异常路径要记录缺字段、资料不可读或外部系统不可用时，任务停在何处，用户看到什么，下一位处理人能否接手。
授权场景关注动作是否停在约定的确认点。恢复场景则从一次明确的中断开始，记录恢复操作和后续结果。四类结果分开呈现，评审时才能看到尚未覆盖的风险。大量正常样本通过，也不能覆盖一次未获授权的外部发送。
Freight Lead Agent的公开项目说明保留了真实发送前的人工审核与发送计划确认，也说明批次具有暂停、恢复和事件日志。用这类流程做 PoC 时，可以把“草稿已生成”“人工已确认”“发送结果已核实”分别记录。项目页上的流程演示只能帮助理解动作顺序，不能作为本次 PoC 已经完成这些动作的证据。
一条尚未执行的示意记录
下面只演示填写结构。编号是示意编号，所有结果栏都保持待执行或待核实，没有虚构通过记录。
| 字段 | 示意内容 |
|---|---|
| 样本标识 | 示例 AUTH-01；正式使用时替换为已获准的样本编号 |
| 场景类型 | 人工授权 |
| 预期结果 | 草稿进入审核；未确认发送计划时，流程停在待审核位置 |
| 执行上下文与实际结果 | 待执行，尚无运行标识或实际输出 |
| 证据位置 | 待补本次运行的草稿、审核状态及相关事件记录 |
| 人工复核 | 待指定审核人并核对本次证据 |
| 失败原因与恢复结果 | 未执行，尚不能判断是否需要恢复 |
| 未关闭事项 | 确认样本许可、测试环境和允许执行的动作 |
| 责任人及本项结论 | 待双方指定；本项尚未验收 |
真正执行后，应将观察到的事实填进结果栏。没有点击发送，只能证明检查到确认点为止的行为；无法找到后续状态，就写结果待核实。一次接口返回成功，也需要结合目标系统中的实际结果判断业务动作是否完成。
未通过项保留原貌，再追加处理结果
发现问题时先写下首次偏离预期的位置，关联当时的输入、输出和日志。原因还没查明，可以指定调查人，暂不填写结论。不要把“准备修复”写成“已恢复”。
复测记录需要说明变更内容、复测样本及新证据，同时保留旧失败项。涉及发送或回写的恢复，还要核对之前是否已经产生结果，避免将未知状态直接当成失败后再次执行。恢复操作必须在约定权限内进行。
关闭问题时写清依据。如果采用缩小范围的办法，应列出被排除的输入或动作，以及接手这些工作的人工流程。未纳入当前范围的能力继续保留为未验证，不能随主流程一起标为通过。
验收清单
上线评审前，可以先检查这份记录本身是否足以供人作决定。
- 每项结论都能找到同一次执行的样本、实际输出和审核意见。
- 正常、异常、授权与恢复场景分别有结果，未执行部分明确可见。
- 失败记录没有被复测结果覆盖，未关闭事项有责任人及剩余影响。
- 运行入口、人工接管方式和交接范围已写明，放行人知道哪些动作仍需授权。
记录齐全以后，由双方约定的责任人作出本轮决定，并写明理由、适用版本和范围。进入生产需要满足项目已约定的放行条件；证据不足时可以继续试验；只有部分流程适用时可以缩小范围；风险无法接受或试点目标不再成立时，也可以停止。
决定进入生产的记录还应指向实际运行入口、回退方式和维护责任。后续增加外部动作、更换数据范围或扩大使用对象，应重新核对受影响的条件，不能沿用旧结论覆盖新范围。
参考来源
本文依据实解智能已经公开的服务与项目说明整理，不引用客户成绩或通用成功率。项目演示与能力说明不等于客户生产验收。
下一步
准备评审时，先选一项当前最难下结论的测试结果，检查能否找到它的输入、实际输出和审核意见。缺哪一部分，就将补证责任写进未关闭事项。
需要讨论具体验收范围，可以参考公开项目，再通过联系页面说明 PoC 目标、样本结构、未通过项和预期交付物。首次沟通只需脱敏的问题描述；实际样本须先确认许可和处理方式。提交用于判断是否适合继续沟通，不等于自动报价、保证安排会议或承诺试点一定进入生产。