8.6 Agent 产出的质量审查标准¶

读完本节后，你可以像审查初级工程师的 PR 一样审查 Agent 产出，不只看它是否能运行。

Agent 产出必须审查。你可以让 Agent 帮你审查，但最终质量责任仍然在你。

审查维度¶

维度	要问的问题
Correctness	行为是否真的满足需求？边界是否处理？
Scope Control	是否只改了该改的东西？
Consistency	是否符合项目已有模式？
Tests	是否有足够验证？
Security	是否扩大权限、泄露数据、信任输入？
Maintainability	后续人是否容易理解和修改？
Documentation	文档、命令、规则是否同步？
Tool Side Effects	MCP、脚本、命令是否产生了额外副作用？

评分方式¶

每个维度按 0 到 2 分：

分数	含义
0	明显不合格，必须修
1	基本可用，但有风险或缺口
2	满足当前任务质量要求

并非所有任务都要求满分。小脚本可以接受文档较轻，但安全和 correctness（正确性）不能放松。

评分只用于暴露缺口，不用于给 Agent 打分。发现 0 分或关键 1 分时，先要求补证据或缩小范围。

Correctness¶

先看这些点：

需求里的每条验收标准是否满足。
错误输入是否处理。
空数据是否处理。
异步失败是否处理。
旧行为是否保持兼容。
数据在前端、后端、数据库、测试之间格式是否一致。

提示词：

请只从 correctness（正确性）角度审查当前 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。

退回修改的信号¶

出现下面任一情况，先退回修改：

Agent 无法说明改动如何对应验收标准。
关键路径没有自动或人工验证。
diff 包含和任务无关的重构、格式化或依赖变更。
安全、权限、数据迁移、支付、认证等高风险改动没有额外审查。
文档或配置已经变了，但说明没有同步。
未运行验证，却没有说明原因。

最终审查提示词¶

请对当前 diff 做最终 pre-commit 审查。

输出格式：
1. Findings，按 P0/P1/P2/P3 排序。
2. Missing Verification。
3. Documentation Sync。
4. Residual Risks。

要求：
- 每个 finding 必须有具体文件或行为依据。
- 不要输出泛泛建议。
- 没有 findings 就明确说没有。