Agent 说“完成了”之后，怎样验收结果

一份交付报告可以说明 Agent 做了什么，但最终验收还需要检查结果。测试通过、文件生成、网页上线，分别证明不同的事情，不能相互替代。

最实用的做法，是在任务开始时写出完成条件，结束时要求每一项都有证据。下面的检查表适合不想逐行读代码、但能够判断实际使用结果的人。

把完成条件和证据放在同一张表里

完成条件	检查动作	可以保留的证据
页面支持修改标题	改标题后保存并刷新	实际保存后的内容
导出文件可用	用目标软件打开导出文件	打开结果及缺失项
空输入不会产生错误记录	提交一条空输入	明确的错误提示和记录检查
修复没有破坏旧流程	重做一遍原来正常的操作	验证时间、环境和结果

示例是演示用检查表，并非某个产品的实测报告。实际任务要把每一行换成自己的要求。

至少检查三类输入

正常输入回答“主要流程能否完成”。边界输入检查空值、长文本、重复记录和顺序变化。失败输入检查取消、断网、权限不足等情况，具体选择取决于功能会遇到什么。

不要为了覆盖率把所有可能性列满。先问：如果这一项失败，会不会让使用者丢失数据、重复操作或误以为已经成功？这类场景应优先验证。

读懂检查的范围

构建成功说明代码可以完成构建流程，不能直接证明按钮保存了数据。本地成功不能证明公开地址部署了同一版本。自动测试只覆盖它实际检查的条件，测试名称也不等于测试内容。

可以要求交付者把结果分成“已检查”“未检查”“已知限制”。例如只在电脑上测试过，就明确记录手机流程尚未检查。避免用一句“全部通过”遮住范围。

给复核者原始证据

第二个 Agent 可以帮助找遗漏，但如果它只读第一个 Agent 的总结，错误前提很容易被保留下来。让它看验收条件、实际产物和必要的运行结果，再独立指出差异。

对你无法判断的代码、数据处理或专业结论，复核人员应具备相应能力。多一个模型的赞同不等于已经证实正确。

用明确结论结束验收

结论：通过／需要修正／证据不足。
已检查：对应完成条件的编号和实际结果。
未检查：尚未覆盖的环境或操作。
限制：目前不能支持的输入或使用方式。
下一步：修正后需要重验哪些项目。

完成记录应该让下一位接手者能够复查，而不必重新相信一次口头承诺。涉及 Agent 权限时，还可以参照任务与权限边界指南。

亲手复跑：同一份输入，修正前后各验一次

本页提供一组新编写的教学练习，使用三条虚构议程。输入的时间顺序是14:00、09:30、11:00，其中一条标题只有空格。要求是按时间排序、每条记录保留一次、空标题显示“待定”、原始输入不被修改。

练习包中的脚本包含两个处理函数：baseline 故意原样复制记录，corrected 则清理标题并排序。它们接受同一份输入、接受同一组四项检查。2026年9月6日实际本地运行结果如下：

检查	baseline	corrected
时间升序	失败	通过
每个ID保留一次	通过	通过
空格标题显示待定	失败	通过
原始输入保持不变	通过	通过

下载下方完整练习包，解压后按 README 运行。脚本不访问网络、不写入文件，也不需要安装依赖。你可以对照CSV记录结果，再试着移除标题清理逻辑，观察对应检查如何失败。

这证明的是固定样例中的两个缺陷被发现并修正。练习只接受有效的当天 HH:mm 时间和字符串标题，没有验证跨日、时区或异常数据，因此不能把四项通过写成“任何议程都能正确处理”。