8.6 Agent 产出的评审标准¶
阅读完本节后，你应该能像 review 初级工程师的 PR 一样 review Agent 产出，而不是只看它有没有“跑起来”。
Agent 产出必须 review。你可以让 Agent 帮你 review，但最终质量责任仍然在你。
评审维度¶
| 维度 | 要问的问题 |
|---|---|
| Correctness | 行为是否真的满足需求？边界是否处理？ |
| Scope Control | 是否只改了该改的东西？ |
| Consistency | 是否符合项目已有模式？ |
| Tests | 是否有足够验证？ |
| Security | 是否扩大权限、泄露数据、信任输入？ |
| Maintainability | 后续人是否看得懂、改得动？ |
| Documentation | 文档、命令、规则是否同步？ |
| Tool Side Effects | MCP、脚本、命令是否产生了额外副作用？ |
评分方式¶
每个维度按 0 到 2 分：
| 分数 | 含义 |
|---|---|
| 0 | 明显不合格，必须修 |
| 1 | 基本可用，但有风险或缺口 |
| 2 | 满足当前任务质量要求 |
不是所有任务都要满分。小脚本可以接受文档较轻，但安全和 correctness 不能放松。
Correctness¶
检查：
- 需求里的每条验收标准是否满足。
- 错误输入是否处理。
- 空数据是否处理。
- 异步失败是否处理。
- 旧行为是否保持兼容。
- 数据在前端、后端、数据库、测试之间格式是否一致。
提示词：
请只从 correctness 角度 review 当前 diff。
逐条对照 Acceptance Criteria，指出未满足或无法确认的地方。
Scope Control¶
检查：
- 是否格式化了无关文件。
- 是否重构了未要求模块。
- 是否引入新依赖。
- 是否修改公共接口但没有说明。
- 是否把临时代码提交进来。
提示词：
请列出当前 diff 中所有可能无关的改动，并说明为什么它们可能无关。
不要修改文件。
Consistency¶
检查：
- 错误处理是否使用项目已有方式。
- 命名是否符合现有风格。
- 目录放置是否合理。
- 测试写法是否和已有测试一致。
- UI 组件是否复用现有组件。
如果 Agent 写了“全新风格”的代码，优先要求它回到现有模式。
Tests¶
最低要求：
- 新行为有测试。
- bugfix 有回归测试。
- 关键边界有覆盖。
- 如果无法写自动测试，要有手动验证步骤。
提示词：
请检查当前改动的测试覆盖。
指出哪些新行为没有测试，哪些边界没有覆盖，并给出最小补测方案。
Security¶
重点看：
- token、密钥、路径、内部 URL 是否泄露。
- 用户输入是否直接进入 shell、SQL、文件路径。
- 权限判断是否遗漏。
- 日志是否输出敏感数据。
- MCP 是否读取或写入了不该碰的数据。
高风险功能不接受“看起来没问题”。必须有具体验证。
Maintainability¶
检查：
- 是否有重复逻辑。
- 是否把业务逻辑塞进 UI 或 route handler。
- 是否过度抽象。
- 是否引入难懂的 clever code。
- 是否有必要的注释解释复杂逻辑。
Maintainability 不是“代码越抽象越好”，而是后续修改成本可控。
Documentation¶
需要同步文档的信号：
- 命令变了。
- 环境变量变了。
- API 变了。
- 目录结构变了。
- 用户可见行为变了。
- Agent 工作规则变了。
提示词：
请判断本次改动是否需要更新 README、AGENTS.md、CLAUDE.md、docs 或任务文档。
只列必须更新的文档和原因。
最终验收门槛¶
- [ ] P0 / P1 finding 已修复。
- [ ] 无关改动已移除或解释。
- [ ] 关键验证已运行。
- [ ] 未运行验证有原因。
- [ ] 文档同步已处理。
- [ ] 你本人看过 diff。
最终 review 提示词¶
请对当前 diff 做最终 pre-commit review。
输出格式：
1. Findings，按 P0/P1/P2/P3 排序。
2. Missing Verification。
3. Documentation Sync。
4. Residual Risks。
要求：
- 每个 finding 必须有具体文件或行为依据。
- 不要输出泛泛建议。
- 没有 findings 就明确说没有。