先说个可能不太合时宜的观察：用 AI 写代码，写代码这件事本身，确实快到有点离谱。
一个我以前要花两天半才能搓出来的后台管理页，现在一杯咖啡的功夫就躺在那儿了，还带响应式布局，还带 TypeScript 类型，还贴心地写了注释。生成速度大概是以前的十倍，这点不吹牛。
然后我把代码合并进主干，跑了一遍测试，转了一圈，点了发布。上线用了四十分钟。而当初那"两天半"里，真正花在敲键盘上的时间可能只有三个小时——剩下的时间，本来是花在想清楚这玩意到底该长什么样上的。
现在敲键盘这环没了，想清楚这环还在，只是被挪到了更靠后的位置，并且变得更难、更隐蔽、更容易在评审会上被当场戳穿。
这就是我想聊的：AI 没有消灭开发瓶颈，它只是把瓶颈搬家了——而且搬到了一个大多数人还没来得及装监控的地方。
一、瓶颈从「生产」搬到了「审查」
软件工程有个老规律：成本会从你最擅长的地方流走，流到你最不擅长、但又最必要的地方。
手写代码时，团队的瓶颈是打字速度，所以出现代码产量崇拜，出现"这个需求很简单，一天就能搞定"的豪言。现在打字这环被 AI 接管，于是瓶颈变成了：
你得在一堆看起来"很专业"的代码里，快速判断出哪一行是错的。
这两件事难度完全不是一个量级。
手写代码的坏处很明显，你一眼能看出不对劲。新人写的分页逻辑，命名混乱、条件漏边界，那种"这味儿不对"几乎是生理性的。你不需要会写，只需要会看。
AI 写的代码坏在另一个地方：它太像"对的"了。语法规范，缩进漂亮，变量名自解释，注释还给你画了流程图，读起来非常顺，顺到几乎不会停下来质疑。而一个真正的 bug——不是语法错误，是"并发场景下这里会重复扣款"——在那种流畅的阅读体验里几乎是隐形的。
我自己的经验是：AI 生成一段代码后，第一遍扫过去觉得"挺好"，问题往往就藏在第二遍、第三遍里。这就是流畅性错觉：代码读起来不费劲，会让人误以为自己已经读懂了。
更扎心的是责任转移。以前出了 bug 是"谁写的谁负责"；现在代码是 AI 写的，人是"审核并合并"的。两种责任模型的隐含假设完全不同，但组织流程往往还停留在前一种。
于是极其常见的场景出现了：AI 一天生成 20 个 PR，团队花两天去审，最后发现其中 3 个要改、2 个不能合，真正撑起这个迭代的还是那 2 个手工写的功能。写得快，合得慢，总产能原地踏步，但所有人都感觉很忙。
二、AI 代码的隐藏税：意图缺失
这比"写得烂"严重得多。
人手写代码时，很多关键信息是隐含在动作里的：
- 为什么这里用悲观锁——因为历史上出过重复扣款；
- 为什么这个接口不做缓存——上游数据每分钟都在变，缓存会读脏；
- 为什么这里要判空——上游老系统常年还在推 null；
- 为什么这个字段不能改——财务对账脚本按位置解析 CSV。
这些"为什么"，在你手写时自然留在代码的形状里。老手看得出，新人问一句就有答案。
AI 写代码时，这些"为什么"全丢了。它只拿到"做什么"（还可能是猜的），拿不到"为什么"，于是给你一个在逻辑上成立、在历史上必然翻车的完美实现。而且那段漂亮的注释还会加剧问题——它会写"// 安全地处理空值情况"，语气笃定得像在陈述事实。
所以我现在的判断标准是：AI 写的代码不是"对不对"的问题，而是"它凭什么这么写"的问题。只要一个 PR 我看不明白"凭什么"，就不合。哪怕测试全绿，哪怕逻辑看着没毛病。这不是保守，是把"意图缺失"这笔隐形债务挡在门外。
三、心法：怎么让 AI 产出「能被审查」的代码
几条我自己一直在用的，效果比换模型明显得多。
1. 先让它写"设计说明"，别急着写代码
超过一个函数的需求，先让它输出：涉及哪几个文件、数据流是什么、边界怎么处理、哪些地方它拿不准。这一步的产物才是真正要审查的东西，代码只是执行结果。
更重要的是，这一步会把它的"不确定"暴露出来——它标出拿不准的地方，就是你必须补信息的地方。直接让它写代码，这些不确定会被它用自信的语气填平。
2. 限制 diff 规模
一个 PR 改 3 个文件是评审，改 30 个文件是放弃评审。我会明确要求它一次只改一件事：先加字段并兼容旧数据，再改读取逻辑，最后切写入。每步单独合、单独回滚。能不能被审查，取决于 diff 有多小，跟代码质量关系不大。
3. 让它先写测试，再写实现
顺序反过来效果天差地别。先写实现再补测试，测试会变成"给实现找台阶"：代码跑通了，测试自然绿，而绿色只是对现状的复述，没有筛查力。
反过来，先写测试，等于把"我期望什么"和"它怎么实现"解耦了。测试挂了，说明它理解错了需求——这时候你改的是需求共识，让实现追上来，比事后读三遍 diff 划算得多。
4. 让它自己「找茬」，而不是让它自己「修好」
反直觉但有效的经验：别让 AI 一次性把问题修掉。正确做法是两轮：第一轮只让它列出"这段代码可能存在的 5 个问题，标出严重程度"；第二轮再针对你确认的那几条去改。
为什么？因为一个同时承担"发现问题"和"解决问题"的 AI，会自动把问题往好解释的方向圆回来——它倾向于证明自己没错。拆开两件事，它才会老老实实列问题。
5. 把「人写的」和「AI 写的」在结构上隔开
现在的习惯是：AI 生成的代码尽量集中在一个目录或一个模块，通过清晰接口跟手写代码对接。
好处不是方便甩锅，而是责任边界清晰。核心逻辑是我写的、我懂、我负责；胶水层和样板代码是 AI 写的、我审过、我签字。出事故我能一分钟定位到问题在哪一层。混在一起写，谁都说不清"这段逻辑是谁的判断"——这不是甩锅，这是可维护性。
四、什么时候该把 AI 关掉
有几个场景我是硬性不让 AI 碰的：
- 安全相关代码：认证、鉴权、加密、支付核心。AI 写的这类代码正确率看着很高，漏一个边界条件就是事故。
- 性能敏感路径：热点循环、大数据量处理。AI 会写出"教科书式正确但很慢"的代码，因为它优化的目标是可读性，不是你的 QPS 预算。
- 你还没想清楚的地方：需求本身模糊时，AI 的作用是加速模糊——它会给你一个非常完整、非常有说服力的错误答案。这是最危险的一种错误，因为它带着文档和注释。
第三条尤其值得强调。太多人搞砸在"帮我优化一下订单处理逻辑"这句话上：AI 输出了 200 行干净利落的实现，比我原来写的还漂亮——上线才发现业务上根本不是那回事。AI 极度擅长把一个模糊的想法包装成一个清晰的方案，这可能是 AI 辅助开发最大的隐性风险：它让你跳过了"想清楚"，而人往往在跳过思考之后，才发现自己根本不知道要什么。
五、真正的护城河是判断力
往前看，我反而觉得 AI 让"思考"的权重更高了。写代码的门槛削薄之后，语法、样板、CRUD、文档、测试脚手架都能交出去，于是区分度平移到了三件事上：
- 你能不能判断 AI 说得对不对——需要你真的懂，只懂一点是危险的；
- 你知不知道该要什么——需求定义能力，永远是稀缺的那一环；
- 你能不能为结果负责——AI 不会为线上事故道歉。
这三件事拼起来就是我理解的"资深工程师"。而这套能力，恰恰是 AI 最难从代码库里学会、也最不会被自动化掉的部分——它不在代码里，在你的脑子里和对业务的理解里。
所以我的建议很直接：把 AI 当成一个速度极快、记忆极好、但完全不需要为自己的输出负责的初级同事。你不会因为他写得太快就放弃 code review，也不会因为他说得很有道理就签字背锅。最好的用法，是给他边界清晰的任务和足够的上下文，然后用对待人的方式对待他——包括不放过他的错误。
最后说个细节。
我审 AI 代码的时间比写 AI 代码的时间多。但我也发现，我花在这段时间里思考的东西，比过去写代码时思考的多得多。过去我把思考花在"怎么用 Redis 存这个计数"；现在我把思考花在"这个计数到底允不允许有误差，误差多久能被业务感知"。
这不是升级，是把精力挪到了更值钱的地方。但前提是——你得真的挪，而不是跟着 AI 一起在语法糖里打转。
AI 让你有了十倍的产能。别让它顺便带走你的判断力。那才是你真正的那一份。
