怎样通过智能体做代码审查

想象一个购物清单页面：能打开，条目能添加，按钮看着也正常。但一个跑起来的界面，还说明不了背后的代码是不是想清楚了。开发者会专门抽出时间通读一遍代码，找出漏掉的错误，商量一下当初的决定。这项工作完全可以交给智能体，它做得很好，只是需要您把任务讲清楚。

1. 团队里怎样检查代码

在一个小团队里，一位开发者接到任务：做一个购物清单，能一条一条地添加和删除条目。他写好代码，试着添加了面包和牛奶，又删掉了面包，一切正常。在把工作交出去之前，他又把改动通读了一遍：删掉一段忘了清理的代码，改了一个看不懂的名字。这叫自查。

接着他请一位同事看看代码。这位同事懂编程语言，他会去读：添加是怎么实现的，程序怎样挑出要删除的条目，剩下的清单又会怎样。这样的通读叫代码审查，也就是 code review，做检查的人叫审查者。

同事发现了一个问题：程序是按名称挑选要删除的商品的。如果清单里有两条"牛奶"，点其中一条可能会把两条都删掉。作者测试的是面包和牛奶，这种情况他根本没碰上。

审查者在相应的代码旁边留下一条意见："现在这里会删掉所有同名的商品。允许出现重复的条目吗？如果允许，应该只删掉选中的那一条"。作者澄清了需求：重复条目是允许的，因为它们可能是给不同的人添加的。讨论之后，他改了挑选条目的方式。同事再看一遍改动，确认意见已经被处理了。

图中展示的是带意见的审查流程：代码从作者传给同事，再回来修改。如果二次查看之后还有疑问，讨论和修改会再来一轮。等到没有实质意见了，同事就批准这次改动。

这就是常见的工作流程：写好，给人看，收到意见，讨论，修改。有时意见不少，有时一条也没有。也有作者解释了理由，同事就打消疑问的情况。审查不要求您同意每一条意见。

这种通读也会讨论代码是否好懂：下一个开发者能不能看明白，同一条规则要不要改好几个地方。同事顺带也会了解这部分新代码是怎么写的。项目的知识就这样慢慢分散到多个人手里，而不是只留在作者一个人那儿。

这里很容易把审查和测试混为一谈。添加两件商品、点一下按钮，检查的是运行起来的程序的行为；读删除的代码、弄清楚它会挑中哪些条目，做的是审查。审查过程中也可以运行一下程序，验证自己的猜测。这两种方式互相补充。

2. 怎样把审查交给智能体

现在设想一下，这个购物清单是 Claude Code 按您的描述写出来的。您能说清楚页面上该发生什么，却读不懂背后的程序逻辑。审查里的技术部分，同样可以交给智能体：它会读文件，用大白话解释找到的问题。

团队故事里的角色都还在。有写代码的作者，也有专门拿到一项任务的检查者。在 Claude Code 里，可以用 subagent 来充当这个角色：它是一个助手，主智能体会把具体工作交给它。在这里，它负责读代码、给出意见。

让作者把自己的成果再检查一遍，同样有用。而一个单独的审查者能带来另一种视角：它接到的任务就是评估结果。把需求告诉它，让它明白哪些做法是可以接受的。比如，禁止重复商品从形式上能解决删除的问题，但会改变页面本来该有的行为。

Claude Code 关于审查的建议里提到，最好安排一个单独的检查者，并给出明确的标准。同一份建议还提示把注意力放在影响正确性和需求的意见上。我们把这个思路用到项目的一小块上试试。

组织一次审查，您需要做的不多：描述想要的行为，再从确认过的问题里挑出要修的。读程序逻辑、找出原因、逐条分析技术上的异议，这些都可以交给智能体。

图中有三个角色：您给出需求、挑选要修的地方；主智能体组织工作、修复代码；检查者研究代码和意见。主智能体把需要的材料交给它们，再把结果带回给您。如果没有问题被确认，修复这一步就跳过。下面用三个请求把这套流程走一遍。

最后您得到的是：一份讲清楚问题的说明，一份复核结果，一份修复报告。就算某条意见其实是错的，也有用处：您避免了一次不必要的改动。

如果想给这类审查配一个常驻的助手，关于创建和启动 subagent 的材料会有帮助。怎样给它准备更详细的任务，在关于任务书和结果格式的文章里有讲。

请求 1. 检查已经写好的代码

在项目文件夹里启动 Claude Code。接下来的三个请求都发给主会话：主智能体自己会把工作分给助手。这里以及下文都用这个购物清单当例子，用到自己的项目时，把行为描述换成您自己的。

让一个单独的 subagent 审查当前项目里购物清单的代码。
检查添加和删除条目的部分。
要求：允许重复的名称；只删除选中的那一条；
不能添加空商品。

读一下当前代码以及跟它相关的项目部分。
找出违反这些要求的错误。
不要改代码，不要添加新功能。
对每条意见都用大白话解释：
可能出什么问题，在什么操作下触发，为什么你这么判断。
指出代码里的位置，方便另一个智能体后续核实。
如果没发现问题，就直接说明。列出检查过什么，
还有哪些不清楚。把报告存到 REVIEW_REPORT.md 里。
我不懂编程语言：解释结论时不要要求我去读代码。

文件 REVIEW_REPORT.md 就是一份普通的文本报告。这个名字是我们自己起的，换成别的也行，它的作用是让下一个请求知道该复核哪些意见。"不要改代码"这条要求把检查和修复分开了，写报告本身是允许的。

在我们这个例子里，一个有用的回答大概会是这样："如果添加两件同名商品，删除其中一件会把两件都删掉。代码是按名称挑选条目的，所以两条匹配的记录都会受影响"。这只是一个示范回答，不是对您项目的真实检查结果。

后果您一看就懂：有人会丢掉一条本来想留下的记录。文件名和代码里的位置是留给下一个智能体的，方便它找到原因。这部分您自己不用去啃。

3. 怎样复核这些意见

做审查的智能体自己也会出错。比如它写道："清单里可以添加一件空商品"。听着挺有道理，但对空输入的检查其实已经在程序的另一部分里了，只是它没读到那里。这条意见描述的问题根本不存在。

这种说得很笃定、实际上却是编出来的说法，通常叫 AI 的幻觉。在审查里这尤其麻烦：智能体给出一个修复方案，您却花时间去改一段本来就没问题的代码。所以，代码写完之后要复核，针对它提出的意见同样要复核。

第一步已经做完了：让审查者看过了作者的成果。现在把这份报告连同当前项目一起交给另一位检查者。它的任务是：弄清楚每条意见是不是站得住脚。它有权不同意第一位审查者的看法。

请求 2. 核实审查者的报告

让另一个 subagent 对照当前项目代码和上一个请求里的要求，
复核 REVIEW_REPORT.md。把这些要求明确告诉它。

对每条意见都弄清楚：描述的问题是否真的存在。
检查相关的代码部分：可能需要的处理其实已经有了。
不要把第一份报告当作证据。如果结论需要
运行来确认，就用现有手段跑一遍。
不要改项目代码。

对每一条都写明：已确认、已推翻，
还是暂时无法判断。用清楚的语言说明依据。
把读代码得出的结论和实际运行得到的结果分开写。
不要把没做过的检查说成已经做过。
把结果存到 REVIEW_CHECK.md，并简单跟我说一下。

之后您会得到一份 REVIEW_CHECK.md，里面是复核的结果。在我们这个学习用的例子里，第二个智能体可能会确认重名的问题，同时推翻关于空输入的那条意见："空字符串在添加条目之前就会被拒绝。第一位审查者漏掉了这项检查"。

有了这些，就足够决定下一步了。删除的问题可以交出去修复；空输入这条意见不需要改任何东西。如果智能体写"暂时无法判断"，让它说明缺了什么信息。有时候这个问题得回到您这边：比如，两条重复的记录该算一件商品，还是两件？

再复核一遍能过滤掉不少凭空编造的意见，但不能保证全部清除干净：两个智能体可能重复同一个错误。所以回答里必须有依据：检查者到底在项目里发现了什么，或者运行之后得到了什么结果。光说一句"同意上一个智能体的看法"是不够的。

4. 修复和二次审查

现在挑一个要修的问题。为此只需弄清楚这个问题对页面预期行为的影响。在我们的例子里，多删商品明显碍事，所以就选这一条。有人建议加排序功能，可以先放一放，反正它和修复删除功能没什么关系。

把选中的那条意见完整地交给智能体，别让它去猜"修一下第一个错误"到底指的是什么。改完之后，让它再检查一遍结果。这是团队故事的延续：同事看的是已经修好的版本。

请求 3. 修复并检查结果

修复 REVIEW_CHECK.md 里确认过的问题：
删除一件商品时，所有同名的条目都会一起消失。
应该只删除选中的那一条，允许出现重复的名称。
审查里的其他建议现在先不要实现。

修复之后，用现有手段检查添加和删除商品，
包括两件同名商品的情况。
然后让一个单独的 subagent 再审查一遍修复后的代码：
原因是不是真的没了，添加和删除是不是还能正常工作。
把最初的要求和这次要修的问题描述都告诉它。

用简单的话跟我解释：改了什么，做了哪些检查，
二次审查的结果是什么。
如果有什么没能检查，单独说明。
不要给任务加新的改进。

用到自己的项目时，把关于商品的那段换成您报告里确认过的问题。其余流程可以保持不变：修复、检查、再单独看一遍结果。

一份好的结论会说清楚具体的事情："现在每条记录都能单独删除了。用两个同名条目测试，第二条留在了原地。二次审查没再找到之前那个错误的原因"。只有真正做过这些检查，才能这样写。如果智能体只读了代码，它就该说明这一点。

您也可以自己打开页面，试试常见的操作。这不需要懂编程语言，只是对可见结果的一次额外检查；修复的技术审查仍然是智能体的工作。如果它没办法把程序跑起来，报告里就该留下这个明确的限制，而不是一句"肯定都能用"的承诺。

不必把每一轮都变成没完没了的打磨。如果选中的问题已经修好、检查过，二次审查也没发现相关的新错误，这项任务就可以收尾了。就这样。新的想法值得另开一次讨论。