去年团队开始用 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 变慢？