最近看到不少同学聊一个话题，就是 AI 把代码写完之后，到底还要不要认真 review。
不少人的流程已经悄悄变了：先让 AI 出方案、写计划文档，方案过清楚之后直接让 AI 执行，自己几乎不看，最多最后再跑个 review skill 就进测试了。
说实话，这套流程效率是真高，而且你会发现 AI 写的代码有时候比自己还规整，信任感蹭蹭往上涨，review 也越来越“意思一下”。
但只要碰过线上事故的人都知道，复杂逻辑、边界场景、那种藏得很深的隐性 bug，恰恰是 AI 最容易翻车、也最难被一眼看出来的地方。
今天分享 编程导航 里一位同学的纠结：AI 写代码越来越强，自己 review 越来越敷衍，但心里又总觉得不踏实，一起看看导师给到的建议，相信对你有帮助。
鱼友问题
想跟大家讨论个问题：现在 AI 写完代码之后，你们还会认真 review 吗？
我之前一直是会 review 的，但最近有个同事跟我聊了一下，他的流程基本是：先让 AI 出计划、写文档（类似 Cursor plan），把方案过清楚之后，直接让 AI 执行，自己几乎不 review，最多最后再让 AI 跑个 review skill，然后就进测试了。
这事最近有点让我纠结。因为说实话，我越来越觉得 AI 写代码的能力比我强，有时候它写出来的代码甚至我自己都不一定完全看得懂，而且信任度也越来越高了。
现在每天不是对着 Cursor 聊，就是对着 Claude Code 聊，review 也开始变得越来越“意思一下”。
但另一方面，又总觉得“不 review”心里有点虚。尤其是复杂逻辑、边界场景、隐性 bug 这种，真的能完全交给 AI 吗？想听听大家现在真实的工作流。
导师回答
AI 写完代码必须 review，但 review 的方式确实要变了，从过去那种“逐行读懂每一行”，变成“把控架构、卡死关键点和边界”。完全不 review，不是不出事，只是还没轮到他出事。
先说你那位同事的流程，其实没你想的那么离谱。他把大量精力放在了前期的 plan 和方案确认上，本质是把 review 前置了，方案对了，代码方向就不会跑太偏，这一步做得很对。
真正有问题的，是后半段“自己一行不看、全靠 AI 跑个 review skill”这部分。
你得想明白一件事：AI review AI，本质还是同一个模型在自我检查。它当初为什么没考虑到那个边界，review 的时候大概率还是想不到。这种交叉验证能抓住一些低级错误，但对那种“逻辑自洽、跑起来也没报错，可业务上就是错的”的坑，基本是抓瞎的。
我个人的做法是分场景，不搞一刀切：
像 CRUD、样板代码、改个文案、加个字段这种，AI 写完扫一眼 diff 就行，没必要逐行抠，抠了也是浪费时间。
但只要碰到这几类，建议亲自 review：复杂的核心业务逻辑、各种边界和异常分支、并发和事务、跟钱相关的、涉及删除数据和权限的。这些地方一旦出问题，造成线上资损，大概率是你背锅而不是 AI。
再说你那句“代码我自己都看不懂了”，这句话其实是个危险信号。
看不懂有两种：一种是用了你不熟的新写法，那是好事，正好学；另一种是逻辑绕、命名乱、AI 硬凑出来的，这种你更得停下来。你都看不懂的代码，出了线上问题，半夜被告警喊醒的时候，你拿什么去定位？
继续让 AI 去改 bug 只会越改越乱，最后变成屎山代码，根本没办法维护。
分享几个我自己常用的小技巧，亲测好使：
一个是让 AI 解释“为什么这么写”。它要是能讲清楚每个分支的取舍，说明它真的想过；要是开始车轱辘话来回绕，那这段代码你就得重点盯了。
另一个是逼着 AI 先写测试用例，但测试用例你必须自己看，重点看它有没有覆盖空值、超大值、并发、异常这些边界。AI 写正常路径的代码很强，但它经常默认“用户都会按规矩来”，边界这块是它的老毛病。
还有就是养成 review diff 的习惯，只盯改动的部分，而不是每次都通读全量代码，效率会高很多。
说到底，AI 越强，我们程序员越是需要做好最后的把关、决策能力。代码可以让 AI 写，但最终交付的责任在你身上，这个是甩不掉的。
