使用 AI Agent 做开发时，经常会看到这样的结果：

Task completed.

或者：

已完成修改，测试通过。

看起来任务已经结束。

但真正准备合并代码时，开发者往往还是会重新检查：

• 到底改了哪些文件；

• 测试是不是真的执行过；

• 只跑了单元测试，还是连Build也跑了；

• 有没有留下临时代码；

• 有没有影响任务范围之外的文件；

• Agent有没有跳过失败项。

所以问题并不是：

AI Agent会不会宣布“完成”。

而是：

它有没有足够证据证明这个任务真的可以交付。

---

一、“代码写完”和“任务完成”不是一回事

Agent最容易判断的是：

需求
↓
修改代码
↓
没有明显报错
↓
完成

但真实开发任务通常还需要：

修改代码
↓
测试
↓
类型检查
↓
Build
↓
检查Diff
↓
确认影响范围
↓
才能交付

所以如果Agent只是完成了代码生成，它其实只完成了：

实施阶段。

还没有真正完成交付阶段。

---

二、“测试通过”首先要问：跑了什么测试？

一句：

All tests passed.

信息其实非常少。

开发者真正需要知道的是：

执行了什么命令？
跑了多少测试？
有没有跳过？
有没有失败后换成更小范围测试？

例如：

npm test

和：

npm test -- user.service

意义完全不同。

后者可能只验证了一个局部模块。

所以Agent最好不要只输出：

测试通过。

而应该给出：

npm test -- user.service
27 passed
0 failed

这样才有验证价值。

---

三、单元测试通过，不代表项目真的能交付

很多任务可能出现：

Unit Test ✅
Build ❌

或者：

Test ✅
Type Check ❌

甚至：

Test ✅
Lint ✅
Build ✅
实际运行 ❌

所以不同项目应该有不同验证层级。

常见检查包括：

Unit Test
Integration Test
Type Check
Lint
Build
Smoke Test

不是每次都必须全部执行。

但Agent至少应该明确：

哪些验证做了，哪些没有做。

---

四、最重要的是形成一条“证据链”

一个更可靠的Agent交付结果应该能回答：

改了什么？

例如：

修改：
src/user/service.ts
src/user/service.test.ts

为什么改？

修复用户状态更新失败问题

怎么验证？

npm test -- user.service
npm run typecheck

结果是什么？

27 tests passed
TypeScript check passed

有没有未验证部分？

未执行完整E2E测试

这才是一条完整的：

修改 → 验证 → 结果 → 风险

证据链。

---

五、Diff本身也是重要证据

即使测试全部通过，最终也应该检查：

git diff

原因很简单：

测试主要告诉你：

已验证的功能有没有出错。

Diff则告诉你：

Agent到底动了什么。

例如一个小Bug，本来只需要修改：

2个文件

最后却出现：

11个文件变化

这时候即使测试通过，也值得重新检查。

因为Agent可能顺手做了：

• 重构；

• 格式化；

• 删除代码；

• 修改配置；

• 更新依赖。

这些都可能超出原始任务范围。

---

六、为什么Agent越自主，验证证据越重要？

以前AI更像：

你问
↓
AI给代码
↓
你自己执行

开发者天然参与了验证过程。

Agent模式则可能变成：

接收任务
↓
修改代码
↓
执行命令
↓
运行测试
↓
宣布完成

开发者看不到很多中间步骤。

所以Agent自主性越高，越需要：

把关键执行结果重新显式输出。

否则“自动化程度提高”可能同时意味着：

过程可见性下降。

---

七、不要只让Agent写任务总结

常见结尾是：

完成用户模块修改。

主要变化：
1. 修复状态更新
2. 增加测试
3. 优化错误处理

这属于：

总结。

但开发者真正需要的是：

交付报告。

两者差别在于交付报告必须包含验证信息。

例如：

修改文件：
...

执行命令：
...

测试结果：
...

Build结果：
...

未验证项：
...

潜在风险：
...

这样才方便Review。

---

八、可以固定一份Agent交付清单

例如每次完成开发任务后，都让Agent检查：

交付前请确认：

1. 列出本次修改的全部文件；
2. 说明每个文件为什么修改；
3. 列出实际执行过的测试命令；
4. 给出测试、Build和类型检查结果；
5. 检查完整git diff；
6. 确认是否存在临时日志、Mock或调试代码；
7. 标出没有验证的部分；
8. 如果存在风险，不要直接声明任务完全完成。

这样“完成”就不再只是Agent的一句话。

而是一个有标准的状态。

---

九、没有证据时，应该允许Agent说“未完全验证”

这是很重要的一点。

如果因为环境缺失：

数据库不可用
浏览器环境缺失
第三方服务无法访问

Agent无法完整测试，就应该明确说明：

代码修改已完成，但E2E未验证。

这比简单输出：

Task completed.

更可靠。

好的Agent工作流不是要求AI永远说“完成”。

而是要求它：

准确说明完成到什么程度。

---

最后

AI Agent说“任务已完成”，开发者仍然不敢直接合并，本质上缺的通常不是更多代码。

而是：

能够证明代码可以交付的验证证据。

真正可靠的任务结束状态应该包含：

修改范围 → 测试命令 → 验证结果 → Diff检查 → 未验证项。

未来AI Agent开发工作流的重点不会只是：

AI能不能把代码写出来。

还会越来越关注：

AI能不能证明自己写出来的代码值得进入主分支。

当“完成”从一句自然语言，变成一套可检查的交付证据时，Agent才真正开始接近工程化开发流程。

---

持续更新 Codex、Claude Code、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。