当我让 AI 处理代码审查时出现了什么问题（以及我如何修复）
Source: Dev.to
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。
I – 你并未意识到的问题
以下是大多数开发者目前的做法：
- 他们写代码。
- 把代码粘贴到 ChatGPT 或 Claude，问一句：“这段代码好吗？”
- AI 回答说可以（或提出一些小改动）。
- 然后他们直接合并。
他们以为自己很高效，实际上却在大规模地累积技术债务。
问题不在于 AI 的输出，而在于把判断外包后，你的大脑会发生什么。
当你让 AI 负责代码审查时，你不再去问 为什么。你不再质疑架构。你也看不到代码库中的模式，因为你不再被迫在脑中同时保持多个上下文。
代码审查不仅仅是捕捉 bug；它还是维护整个系统工作方式的心智模型。
印刷术让抄写员失业。古腾堡之前，书商雇佣数十名受过训练的工匠手工抄写手稿——这是一项需要多年才能掌握的技能。等他们意识到时，这项技能已经没有价值。
但编辑的角色出现了——他们的工作是决定哪些内容值得印刷。
这种模式是技能向上抽象。
你不必亲自写每一行代码，但你绝对需要知道哪些行代码是关键的。
那么这一次为什么不同？
因为大多数开发者把 AI 当作拼写检查器使用，而实际上应该把它当作研究团队来利用。
II – 单模型审查是伪装成确定性的猜测
我一直在使用 Claude Opus 4.1 处理所有任务。模型很棒，分析能力出色，TypeScript 也很强——但它也有盲点。
有一天，我让它审查一个不必要重新渲染的 React 组件。Claude 建议使用 memoization。这个建议还算合理，我于是采用了。
随后，我出于好奇把同样的代码交给 GPT‑5 检查。GPT 指出真正的问题是 prop drilling——memoization 只是在处理症状，而不是根本原因。
那一刻，我恍然大悟。
每个 AI 模型的训练方式都不同。每个模型各有优势：
- Claude 擅长细致的分析。
- GPT 更善于把握架构模式。
- Gemini 能捕捉 Claude 漏掉的边缘案例。
如果只使用单一模型，你得到的并不是一次完整的代码审查，而是该模型的视角，而这种视角必然存在盲区——因为你已经停止了多角度的审视。
平庸与卓越之间的差距在于 taste（审美/品味）。当每个人都能生成代码时，能够判断哪些代码值得信赖的能力才是真正的技能。
这正是 在多个模型之间运行相同审查 不再是一个功能，而是一种全新的思考方式。
III – 实际出现的问题（以及它给我的教训）
生产环境的 bug 很微妙：一个缓存层在预发布环境运行良好，但在高负载下失效。AI 已经审查了逻辑——逻辑是正确的。AI 没能捕捉到的是实现中隐藏的假设——缓存失效会同步发生。
为什么 AI 没能捕捉到它？
因为我没有给它足够的上下文。我粘贴了函数代码，但没有展示完整的数据流或解释部署架构。AI 只能审查你展示给它的内容，而在快速迭代时，你往往只给它最少的信息。
三种可预测的失败模式
| 故障模式 | 描述 |
|---|---|
| 上下文崩溃 | 你粘贴了 50 行代码；AI 只审查这 50 行，但 bug 实际上出现在这些代码与另外 200 行未包含的代码交互时。当你在整个代码库中分析代码时，就不会再遗漏集成错误。 |
| 架构盲点 | AI 在局部优化方面表现出色，但在系统设计上很糟糕。它可能会提出一个让单个函数更快的巧妙方案，却让整个架构变得更加脆弱。 |
| 信心问题 | AI 从不说“我不知道”。它会给出答案，而因为它表达流畅，你会信任它——即使它是错误的。 |
能够看清这些问题的人并没有放弃 AI；他们不再把它当作全能的预言机，而是把它当作需要指导的初级开发团队成员。
IV – 如何实际使用 AI 进行代码审查（而不破坏你的判断）
| Level | Description |
|---|---|
| Level 1 – 粘贴者 | 复制代码，粘贴到聊天机器人中，接受它的任何回答。你已经把思考外包了。 |
| Level 2 – 提示工程师 | 编写更好的提示，加入更多上下文，获得更好的答案——但你仍然受制于单一模型的视角。 |
| Level 3 – 编排者 | 将相同代码在多个模型上运行，进行比较、综合。注意 Claude 捕捉到的 GPT 漏掉的内容，反之亦然。 |
| Level 4 – 架构师 | 在特定审查任务中使用 AI，同时你掌控系统思考。你知道该用哪个模型来做什么，并已构建工作流。 |
大多数开发者从未超出 Level 1。以下是提升的方式：
Step 1: 停止孤立审查
不要只粘贴孤立的函数。粘贴完整的上下文：调用方、数据流、部署约束。当你在审查前从文档中提取模式时，你可以捕捉到 AI 看不到的假设。
Step 2: 始终使用多个模型
将你的代码至少在三种不同模型上运行。寻找分歧——分歧是值得调查的信号。瓶颈不在于获取审查，而在于在发布前知道该信任哪种视角。
Step 3: 让 AI 展示其工作过程
不要只接受单一的“是”或“否”。让模型解释它为何建议更改，阐述推理过程，并指出它所做的任何假设。这迫使 AI 暴露其思考过程，给你提供验证——或拒绝——的机会。
V – 协议
早晨：架构评审（20 分钟）
在编写任何代码之前，我向三个模型提出相同的架构问题：
“鉴于 [system constraints]，以这种方式实现 [feature] 的权衡是什么？”
我寻找分歧。它们一致时，我快速推进；出现分歧时，我放慢速度并思考。
开发期间：上下文丰富的提示
我不再审查单个函数。我审查：
- 函数
- 调用方
- 数据流
- 错误处理
- 部署上下文
我每次都粘贴 全部 内容。
合并前：多模型分析
我将最终代码通过以下模型进行分析：
- Claude Sonnet 4.5 – 逻辑分析
- GPT‑5 – 架构模式
- Gemini 2.5 Pro – 边缘情况
当它们的结论一致时，我信任；出现分歧时，我进行调查。
每周：回顾故障
每周五，我查看本周的 bug，回顾 AI 的审查，找出 AI 漏掉的地方及原因，并更新我的提示。
目标： 不是完美，而是迭代——构建一个每周都变得更聪明的系统。
VI – 实际花费
你可能在想：“这听起来工作更多，而不是更少。”
你说得对。要把 AI 用好需要付出努力——比把它用不好、甚至不使用时都要多。但你会得到：
| 之前（单模型，快速粘贴） | 之后（多模型，语境丰富） | |
|---|---|---|
| 审查时间 | 每次审查 5 分钟 | 每次审查 15 分钟 |
| 漏洞捕获率 | ~70 % | ~95 % |
| 判断力提升 | 无 | 快速提升 |
| 代码质量趋势 | 下降 | 持续提升 |
额外的 10 分钟不是开销，而是投资。你不仅在审查代码，还在训练自己看清关键所在。
- 快速但目光短浅的开发者 会在前六个月保持快速，随后花六个月时间调试自己制造的烂摊子。
- 现在放慢脚步的人 将在六个月后变得更快，因为他们的判断力会更加敏锐。
VII – 你应该提出的问题
- 你是用 AI 来加快思考，还是用它来避免思考？
- 当 AI 建议修改时，你能解释为什么那个修改更好吗？
- 如果明天不能使用 AI，你的代码质量会下降吗？
如果你诚实回答，可能会感到不舒服。这种不适正是关键——它说明你把判断外包了，却称之为效率。
差距正在显现：
- 把 AI 当作拐杖的开发者 vs. 把 AI 当作杠杆的开发者。
- 让模型替自己思考的人 vs. 把多种视角组织起来做出更好决策的人。
转变
代码审查已经被抽象到更高层次。你不需要捕捉每一个分号，但你 必须 了解系统。
- AI 不会取代你。
- 会组织 AI 的开发者将取代不会的开发者。
在接下来的六个月里弄清楚这一点的人，将在完全不同的层次上构建。那些仍然把代码粘贴到 ChatGPT 并接受返回结果的人，将继续困惑于为何生产环境频频出问题。
智能应该是流动的，而不是碎片化的。
你不必选边站——你 orchestrate all of them。
— Leena :)