AI 跟我说，一件事做完了。
我现在不会马上点头，而是先问六个问题。它们不是为了增加一层形式，而是为了确认：这份成果不只在制作者这边看起来完成，也真的到了接收者手里。
改的是不是我要的那个项目？
开始验收前，先确认项目、交付物和约定范围。同名副本、旧工作目录或另一个相似项目都可能给出正确结果，但它们不是这次要交付的东西。
如果源头身份互相冲突，应该先停下来对齐，而不是挑一个最方便的继续。
检查过的，是不是刚改好的这一版？
测试通过必须和明确版本绑在一起。如果测试跑在 A 版、打包用了 B 版、最后交付的又是 C 版，三个“成功”也不能拼成一个可信的完成结论。
版本可以是 commit、文件哈希、发布包编号或另一个能重复回读的标识。重点不是格式，而是每一层都指向同一份成果。
新版本真的到了交付环境吗？
本地生成了文件，不等于目标环境已经收到。对一份文档，交付环境可能是约定的共享位置；对一个自动化，可能是实际运行的任务；对应用或网站，则是真正装载该版本的环境。
这一问只确认“送到了哪里”，还不证明别人已经能用。
接收者能不能打开同一版？
交付者自己能看见，不等于接收者能访问。权限、路径、账号、缓存或网络都可能让两个人看到不同结果。
对本地交付，这可以是从约定位置重新打开；对公开交付，则必须回到公开页面读取。本地证据不能替代公网回读。
关键操作和失败路径都走得通吗？
打开页面只是第一步。按钮、表单、下载、生成结果或一段关键操作，需要在接收者的实际表面上验证。
还要选择一个相关的安全失败路径，例如无效输入、无权限或缺少必要文件。看见一次失败不等于失败处理通过；只有结果符合预期，才能记为已验证。对确实没有交互的静态成果，审核者可以说明负路径不适用，但不能因为缺测试而自动豁免。
做了什么、还有什么没解决，都写回原记录了吗？
状态记录不是一张“完成证书”。它应该让下一个人看见变更、实际证据、已知缺口和下一个安全动作。
已观察、失败、不可用和尚未检查是不同状态。缺少证据时，应该保留为未知，而不是顺手改成“不适用”。如果仍有未解决项，检查结果应停在 blocker，交给人决定是否可以延期。
六问的结果不是自动批准
这六问可以把一句 done 变成一份可复核的候选记录，但它不会自动部署、发布、联系接收者或替人作出验收决定。
网页能打开，只是第一步。别人拿到手能不能用，才是接下来要确认的。AI 说做完了，是它的回答；能不能交出去，还得我们自己确认。