产物审查——Agent 交付的代码改动怎么验收
产物是什么
在 Quest 语境下，产物（Artifacts）是 Agent 完成任务后交付给你的具体成果，包括：
- 文件改动：新增、修改、删除的文件列表 + 每个文件的 diff；
- 测试结果：Agent 跑了哪些测试、通过了哪些、失败了哪些、失败原因分析；
- 文档输出：Agent 生成的 README、API 文档、代码注释等；
- 任务总结：Agent 用自然语言总结「我做了什么、为什么、有什么注意事项」。
审查流程
第一步：看任务总结
Agent 的总结会先给你一个高层概览：
- 改动了多少个文件；
- 新增/删除了多少行；
- 主要做了什么（功能/修复/重构）；
- 有什么假设或注意事项（比如「我假设这个模块可以用新的 Logger 工具类，但如果项目不允许引入新依赖请告诉我」）。
先看总结，判断方向对不对，再深入细节。
第二步：看文件改动列表
Agent 会列出所有改动的文件：
| 文件 | 操作 | 行数变化 |
|---|---|---|
src/service/UserService.java | 修改 | +23 / -5 |
src/controller/UserController.java | 修改 | +34 / -2 |
src/dto/UserExportDTO.java | 新增 | +45 |
test/UserExportTest.java | 新增 | +67 |
点击文件名可以看到 逐行 diff——哪些行新增（绿色）、哪些行删除（红色）、哪些行修改。你可以像在 GitHub PR 里那样逐行审查。
第三步：看测试结果
Agent 跑完测试后会列出：
- 跑了哪些测试命令；
- 多少个通过、多少个失败；
- 失败的测试有哪些、失败原因是什么；
- Agent 是否已经自动修复并重跑了。
如果测试都过了，改动的质量会高很多。如果还有失败，Agent 可能在总结里标注了「测试用例 A 因为 XXX 原因没改，需要手动处理」。
第四步：决定接受还是拒绝
审查完毕后：
- 全部 OK → 点接受，改动应用到项目；
- 有小问题 → 不要拒绝，直接在同一 Quest 对话里追加：「UserExportDTO 里的 createTime 字段命名改成 createdAt，其他 OK」——Agent 会基于已完成的工作继续修改；
- 方向完全错了 → 点拒绝，任务回到草稿状态，你可以重新发起。
常见审查要点
| 要点 | 检查什么 |
|---|---|
| 文件范围 | 有没有不该改的文件被改了（比如误改了配置文件） |
| 改动粒度 | 有没有「顺手」改了无关的代码 |
| 风格一致性 | 新代码和项目现有风格是否一致（命名、缩进、注释规范） |
| 边界处理 | 异常、空值、并发场景有没有处理 |
| 测试覆盖 | 新增代码有没有对应测试，测试覆盖率够不够 |
| 性能影响 | 有没有引入 N+1 查询、全表扫描等性能问题 |
| 安全 | 有没有硬编码密钥、SQL 注入风险、未校验的输入 |
迭代审查
审查后的修改不要重新发起任务——直接在同一 Quest 对话里追加修正。比如：
「UserExportDTO 里的 createTime 字段改名成 createdAt；UserService 里分页默认值改成 15 条；其他都接受了」
Agent 会：
- 读取你当前的项目状态（已经接受的改动）；
- 理解新的修改点；
- 在现有基础上继续改；
- 再次交付。
这样迭代效率最高——避免从头规划和执行。
和 GitHub PR 的配合
如果你用 Git：
- 审查 Agent 交付的改动；
- 接受后，改动会以未提交状态存在于你的工作区；
- 你可以
git diff再次检查； - 自己写 commit message（或让 Agent 帮你写），然后 push、开 PR。
Agent 不会自动 commit——保持 Git 操作的完全可控。
下一步
- 接受改动后，想让 Agent 继续做另一个任务 → 回到 Quest 看板发起新任务
- 想了解 Agent 自动沉淀了什么知识 → 知识沉淀与记忆