昨天下午，我盯着屏幕上一条条 PR 评论发呆。
一个同事提交了 500 行代码。我花了半小时看完，写了三行 comment。CI 跑了 10 分钟，lint 没过，还有两个明显的逻辑漏洞我没看出来。
我他妈在干什么？
要是 AI 能替我干这活，我是不是该去干点更值钱的事？正好看到 Anthropic 给 Claude Code 上了个“智能体代码审查”功能。不是那种静态分析工具，也不是 Copilot 那种被动补全，而是个会主动翻代码、问问题、甚至跟你吵架的 agent。
我决定写点东西，聊聊这事到底意味着什么。
Photo by Marek Prášil · Pexels
从“被动工具”到“主动队友”
传统代码审查工具，不管是 SonarQube 还是 CodeRabbit，本质都是规则引擎加模式匹配。你提交代码，它跑一遍，告诉你“这里有个 null pointer 风险”、“那里变量命名不规范”。它不关心你为什么要这么写，也不管上下文。
Claude Code 这次的做法不一样。它不是“扫描器”，是“参与者”。
根据我看到的信息，这个 agent 会主动理解你代码的意图，然后基于整个代码库的上下文，给出有逻辑的审查意见。它不在后端跑个脚本，而是直接嵌入到 Claude Code 的工作流里，像一个 senior engineer 那样跟你对话。
我试过跟 AI 吵代码。它有时候比人还较真。这到底是好事还是坏事？
审查的“人格化”是个双刃剑
Photo by Markus Spiske · Pexels
我见过最有效的代码审查，不是“这里应该用 const”的鸡毛蒜皮，而是“你这个设计在三个月后会导致缓存雪崩”的深度分析。
传统工具做不到后者，因为需要理解业务、架构、甚至团队习惯。Claude Code 的 agent 如果能做到，那它就不是工具，是队友。
但问题来了：队友有性格。一个太 aggressive 的 agent，能让新人不敢提交代码。一个太 soft 的 agent，等于没用。
Anthropic 这次没公开太多细节，但“基于智能体”这个描述，意味着它不再是确定性的。它会根据上下文做判断，会问问题，甚至会反驳你。
我有点担心，如果 agent 开始在 PR 里写“这个实现方式不够优雅”，那代码审查就变成了一场人机辩论赛。
对团队协作的隐形重构
代码审查从来不只是技术活。它是团队的知识传递、代码风格统一、甚至新人 onboarding 的关键环节。
如果 Claude Code 的 agent 承担了大部分“低级审查”——比如逻辑漏洞、边界条件、性能隐患——那人类的审查者就能把精力集中在更高层的事情上：架构合理性、可扩展性、业务对齐。
听起来很美好。代价是什么？
代价是：新人不再有机会通过“被 review 低级错误”来学习。代价是：团队的 code review 文化可能从“互相帮助”变成“让 AI 先过一遍，人再看”。
我不确定这是进步还是退化。但我知道，很多团队本来就不怎么认真做 code review，AI 来了之后，他们更有理由偷懒了。
技术层面：不是所有代码都适合“主动审查”
我写过后端、前端、也写过嵌入式 C。不同领域的代码审查标准完全不同。
Claude Code 的 agent 如果只针对 TypeScript 或 Python 优化，那它就是玩具。如果它能理解 Go 的 goroutine 模型、Rust 的生命周期、甚至 SQL 的查询计划，那才叫真本事。
Anthropic 没说它支持哪些语言或框架，我猜，初期肯定围着 JavaScript/TypeScript 生态打转。毕竟 Claude Code 本身就跟前端开发工具链绑定较深。
但真正让我犹豫的是：一个 agent 如何判断“这个代码是否过度工程”？这种判断需要经验，而经验是 AI 最难模拟的东西。
我的真实判断
我不觉得“智能体代码审查”会取代人类审查者。至少短期内不会。
但它会改变“谁在什么时候做什么”这件事。如果你是团队的 tech lead，现在就得开始想：你的 code review 流程里，哪些环节可以交给 agent，哪些必须由人来 hold。
对我来说，最值钱的能力不是“写代码”，是“判断什么代码值得写”。AI 能帮我们省掉低级审查的时间，但帮不了我们决定方向。
所以我的困惑很简单：当 AI 开始主动审查我们的代码，我们是不是也该开始主动审查 AI 的审查？
别急着回答。先去跑一轮试试，然后回来告诉我，你被 AI 怼了几次。
