AI Coding Agent 改完程序之后，你最容易问：
「帮我检查有没有 Bug。」
这句不是错。
但范围太大。
Reviewer 最后可能列出：
命名问题。
格式问题。
几个一般建议。
真正危险的地方反而没有被你特别追问。
今天只学一个方法。
AI 改完 Code、准备开 Pull Request 以前：
固定把 Review 分成三栏。
影响范围。
规则冲突。
未解风险。
第一栏：影响范围
先不要问：
「这几行 Code 写得漂亮吗？」
先问：
「我改这里，还有谁会一起受到影响？」
这就是 Blast Radius。
例如 Coding Agent 修改：
登录 API 的 Response Format。
目前这个 Repository 的 Test：
全部通过。
但另一个 Repository 里的：
Mobile App。
Admin Dashboard。
Billing Service。
可能还在依赖原本格式。
如果 Reviewer 只看这次 Diff：
不一定容易发现。
Qodo 的 Codebase Context 可以利用 Repository、PR History、Specification、Live Git State 与跨 Repository 关系协助分析这种影响。
所以第一栏固定问：
这次修改可能影响哪些其他 File、Service、Interface 或 Repository？
第二栏：规则冲突
接下来才问：
「这次修改有没有违反我们原本的规则？」
例如团队可能早就规定：
Production Database 不得直接修改。
特定 API 必须向下兼容。
敏感数据不得写进 Log。
付款流程不能自动 Retry。
某些 Directory 不得增加新的 Dependency。
程序本身可能：
可以跑。
Test 也通过。
但仍然违反公司真正的 Engineering Rule。
Qodo Agentic Toolbox 的 Get Rules 与 Rule Enforcement，就是把这类组织、Repository 或工作范围规则带进 Agent Workflow。
所以第二栏固定问：
这次修改是否和目前适用的 Engineering Rules、Specification 或既有设计决策冲突？
第三栏：未解风险
第三栏最重要。
不要要求 AI：
「找到问题就全部自己修掉。」
有些问题确实可以直接修。
例如：
漏掉明显的 Error Handling。
少一个安全的 Validation。
漏掉一个对应 Test。
但有些问题不是「修 Bug」。
而是在做：
决策。
例如：
要不要破坏旧 API 兼容性？
这次能不能改变退款逻辑？
要不要允许 Retry 造成不同 Production Behavior？
数据保存方式要不要改？
这些事情如果 Agent 自己选一个看起来合理的答案：
技术上可能完成。
商业上却可能完全错。
所以第三栏固定问：
有哪些问题无法安全自动解决，需要人类决定？
三栏合起来，就变成一个很简单的 Review Prompt
例如：
「先 Review 目前 Local Changes，不要开 PR。结果分成三组：第一，这次修改可能影响哪些其他 File、Service、Interface 或 Repository；第二，有没有违反目前适用的 Engineering Rules 或 Specification；第三，有哪些问题会影响 Production Behavior、数据、权限或架构，需要人类决定。能安全修正的明确问题可以提出修法；有决策性的问题先停，不要替我决定。」
你不一定每次都要完全照字面输入。
真正要记住的是：
影响范围 → 规则冲突 → 未解风险。
为什么不是先叫 AI 修？
因为 Review 和 Fix 是两个不同阶段。
假设 Reviewer 发现：
付款 Retry 没有 Idempotency Key。
这可能是相对明确的技术风险。
Agent 可以提出修法。
但如果 Reviewer 发现：
目前 Requirement 根本没有写：
失败付款究竟可以自动重试几次。
这就不是单纯漏一行 Code。
而是：
需求还没决定。
这时最好停下来问人。
Qodo 官方自己的 Agentic Toolbox 范例，也采类似界线：
安全能处理的问题让 Agent 处理。
可能改变 Production Behavior 的决策留下给 Developer Review。
「影响范围」要排第一，不是最后
很多人 Review Code 的顺序是：
先找语法。
再找 Bug。
最后才想到：
其他功能会不会坏。
对 Agent 写的 Code，这个顺序可以反过来。
因为 Coding Agent 一次可能在几分钟里：
改十个文件。
创建新 Interface。
调整 Config。
再补一套 Test。
每个 File 单独看：
都很合理。
真正的问题可能在：
File 和 File 之间。
Service 和 Service 之间。
甚至：
Repository 和 Repository 之间。
所以先问 Blast Radius：
通常比先挑 Coding Style 更有价值。
「测试通过」也不能跳过这三栏
假设 Agent 回报：
All tests passed.
很好。
但这只能证明：
目前真的有跑到的 Test 没有失败。
它不能自动证明：
另一个 Repository 没受影响。
没有漏掉公司规则。
Requirement 本身没有问题。
没有缺少重要 Test。
Production Environment 和 Local Environment 完全相同。
所以正确顺序比较像：
Agent 修改。
跑相关 Test。
做三栏 Review。
处理可以安全处理的 Finding。
把未解风险交人。
再开 PR。
不是：
Test 绿灯 → 直接 Deploy。
Qodo 为什么特别适合放在 PR 前？
因为 Agentic Toolbox Reviewer 可以检查：
Committed Change。
Uncommitted Change。
甚至新的 Untracked File。
也就是程序还在你目前 Working Tree 里：
就可以先 Review。
这和等到 PR 开出去后才发现问题不太一样。
现在的目标变成：
问题还在作者脑中有 Context 的时候就先找出来。
能在 Local 阶段解决：
就不用变成：
Reviewer Comment。
第二个 Commit。
再 Review 一次。
但 Pre-PR Review 不等于正式 PR Review 可以取消
这是另一个很容易误解的地方。
Qodo 自己也明确区分：
Local／Pre-PR Review。
以及真正的 Pull Request Review。
前者的目的：
让作者在开 PR 以前先把明显问题整理掉。
后者还有：
团队共同讨论。
Approval。
Merge Control。
最终 Push 后版本验证。
所以 Pre-PR Review 是：
提前增加一层。
不是：
拿掉后面那一层。
今天实际只做这一件事
下次 Claude Code、Codex、Kiro 或其他 Coding Agent 改完功能：
不要马上说：
「开 PR。」
先多做一次 Review。
而且不要只问：
「有没有 Bug？」
固定要求输出：
1. 影响范围
哪些 File、Service、Interface、Dependency、Repository 可能一起被影响？
2. 规则冲突
有没有违反目前的 Team Rule、Specification、安全规则或既有设计？
3. 未解风险
有哪些问题不能靠 AI 自己安全决定，需要人来选？
然后再做下一步。
前两栏里：
明确、低风险、可验证的问题。
可以让 Agent 修。
第三栏：
只要牵涉：
Production Behavior。
权限。
数据。
商业规则。
架构取舍。
先留给人。
真正重要的不是多找一个 AI 说「LGTM」
如果 Coding Agent 说：
「完成了。」
Reviewer Agent 又说：
「Looks good。」
两个 AI 都同意：
不代表得到两份真相。
真正有价值的是第二个 Agent：
问了和第一个 Agent不同的问题。
第一个 Agent 的任务是：
把功能做出来。
第二个 Reviewer 的任务应该是：
找出：
它影响了谁。
违反了什么。
还有什么不能自己决定。
角色不同：
第二层 Review 才真的有意义。
所以今天的一分钟技巧只有一句：
AI 改完 Code，开 PR 前不要只问「有没有 Bug」；先分成「影响范围、规则冲突、未解风险」三栏。
当第三栏还有答案：
先不要叫 AI 自己猜。
那就是人该回来的地方。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 一分钟教学｜2026/08/24：Slack Code 验收条件怎么写？先用「现在／要变成／不能动」三格再叫 AI 改程序
AI 快问快答｜2026/08/24：Slack Code 看完 Plan、Code Diff、Preview，就可以直接部署 Production 吗？
AI 快问快答｜2026/09/07：QWEN.md 已写「Production 不可直接修改」，就代表 Qwen Code 一定不会越界吗？
