去年团队开始用AI编程工具，大家都觉得写代码变快了。但一年下来我发现一个怪现象：写代码的时间确实少了，可Code Review的时间却越来越长。以前review一个PR，扫一遍逻辑、提两个问题就过了。现在每条改动我都要反复确认：这段是AI写的还是人写的？边界条件处理了吗？有没有隐藏的性能问题？review到后来，比我自己重写一遍还累。

一、AI写代码快，但review起来慢

今年初，我接手了团队的核心项目。组里几个同事都用Cursor和Copilot，产出确实高。但轮到我来review的时候，总觉得不对劲。

举个例子，有个同事提交了一个功能模块，代码跑起来没问题，但我逐行看的时候发现：一个组件里挂了三个useEffect，其中两个功能重叠。作者说他没注意，是AI自动补全的。这类问题成了常态：AI生成的代码往往能跑，但结构混乱、逻辑重复、缺少边界判断。

以前人工写的代码，你能感觉到作者的思路。AI写的代码像一锅大杂烩，看起来什么都有，但就是不舒服。review的时候，你不能只看逻辑对不对，还得帮作者删冗余、补缺失、理结构。这一套下来，时间不知不觉就翻倍了。

二、几种AI代码的“通病”

我总结了几类经常在review时遇到的AI痕迹：

1. 逻辑正确，边界全无

AI很擅长把主流程跑通，但空指针、超时、并发这些问题它不太会主动处理。比如一个查询接口，AI会写data.list.map(...)，但不会判断data是不是空。review时要帮它补上data?.list?.map，或者if (!data) return null。

2. 过度设计，简单问题复杂化

有时候AI会把一个很简单的事搞得特别“高端”。比如加个防抖，它给你写一个完整的自定义Hook，里面用了useRef、useCallback、useEffect，洋洋洒洒四五十行。但实际上只需要一个debounce函数。review这种代码，你得先理解它的实现，再判断是不是过度了。

3. 注释和命名像“机器翻译”

AI生成的变量名经常是data、items、config，看不出具体含义。函数注释要么没有，要么是“获取数据”这种废话。review时要帮忙改成有意义的命名，或者补上必要的注释，否则下一个人看不懂。

三、我的个人策略：怎么让review不那么痛苦

经过大半年，我摸索出几条还算管用的办法：

• 让AI先审AI：提交PR前，要求作者把代码再给AI（换一个模型）审一遍，根据建议改一轮。
• 差异化对待：工具类、单元测试、文档注释可以放心让AI写；核心业务逻辑建议手写或深度修改。
• 建立小规范：比如“useEffect必须有清理函数”、“API调用必须有loading和error状态”。AI不一定会遵守，但review时可以快速对照。

这些办法不能根除问题，但至少能把review时间拉回到可接受的范围。

四、反思

我现在对AI编程的态度很矛盾。一方面，它确实帮我省了不少重复劳动；另一方面，它又把负担转移到了review环节。以前一个人写代码，大家一起审；现在一个人写AI代码，另一个人替他审漏洞。

这不是AI的错，也不是工具的错，而是我们还没学会怎么和AI协作。也许未来会有更好的review流程，或者AI能自己审自己。但就目前而言，AI没有让我少加班，只是让我加班的内容从“写”变成了“审”。

五、最后

如果你也在经历类似的感受，点个赞让我知道不是一个人。评论区聊聊：你的团队有没有因为AI代码而review变慢？