用AI写了两年代码，为什么有人越来越强有人停在原地

2026 年的大部分开发者都在用 AI 写代码。起点几乎一样：同一个工具，同一个模型，同一个项目类型。但两年下来，团队里会明确分化成两类人。

一类人的产出速度、系统设计能力、故障排查深度都在上升；另一类人的手速快了，但对系统怎么运转的理解在变浅——一旦 AI 给出的方案不对，他们就卡住了。

这种分化不是天赋差异，而是使用方式的结构性差异。下面三条机制，解释了分化是怎么发生的。

机制一：先想后问，还是先问再看

第一种人拿到需求，先花十分钟自己拆问题、画出数据流、想清楚难点在哪，然后带着具体的问题去问 AI：「这个并发场景我打算用乐观锁，你觉得在订单量和改单率都高的情况下是否有更好的方案？」

第二种人拿到需求，直接描述给 AI：「实现一个库存扣减服务」，然后开始读它生成的代码。

表面看第二种更快。但第一种在过程中形成了自己的判断，AI 的输出成了对照；第二种是在用 AI 的思维框架理解问题，一旦 AI 的方案有缺陷（比如没考虑超卖），他缺乏发现它的参照系。

分化点不是用不用 AI，是有没有先形成自己的假设。 假设会错，但有了假设才有「它和我预期不一样」这个信号。没有假设的人，读到的所有代码都显得合理。

机制二：把调试外包，还是把调试当成学习

线上出问题时，AI 是极强的助手——给它日志，它常能直接给出根因。

但这里有个微妙的陷阱：如果每次都是 AI 告诉你答案，你建立因果关系的能力就停止发育了。

我观察到强的人会做一件事：AI 给出根因后，回头问自己「我是怎么才能想到这个的」。然后把这个推理路径记下来——因为日志里的哪些信号组合指向了嫌疑对象。这个动作叫「逆向补课」，五分钟的成本，换来的是下次自己能想到。

弱的人拿到答案就结束了。半年后同样类型的问题，他还是得靠 AI。

机制三：规模感与现实感的断裂

AI 让三小时能写出以前三周的代码。这会带来一种危险的错觉：以为自己掌握了系统的复杂度。

真实的系统复杂度不在代码行数里，而在：数据边界、并发时序、依赖失效、灰度影响、运维可观测性。这些 AI 只能给你建议，没法给你体验。写得再快，没经历过一次线上回滚，对它的理解就还是纸面的。

强的使用者的做法是刻意保留真实反馈回路：自己上灰度、自己看监控、自己处理客诉。他们用 AI 压缩编码时间，但不压缩验证时间。

四个可以刻意练习的动作

如果不想停在这个平台上，这四件事值得每周做一次。

动作一：无 AI 设计，有 AI 实现

拿到新需求，先在不打开编辑器的状态下写一份设计（半小时），列出数据结构、关键接口、失败路径。然后再用 AI 实现，并且逐条对照设计看它偏离了哪里。偏离的地方，通常是它误解了你的意图，或者你想漏了——两种都是收获。

动作二：安全阀式审查

对自己完全信任的模块，每个月抽一次，把 AI 生成的代码从头读一遍，找出一个「如果出问题会在哪」的地方，然后验证它。这个动作会持续校准你对 AI 可靠性的估计，防止过度信任或过度怀疑。

动作三：一次性写对率复盘

AI 生成的代码，第一次提交后被 review 打回的比例是多少？如果长期高于 30%，说明你的上下文给得不够（缺规范、缺约束、缺示例）；如果低于 5%，说明可能你的 review 在放水。两个极端都值得查。

动作四：手写核心链路

团队的核心模块——支付、权限、对账、状态机——建议规定一个「必须手写并人工评审」的清单。不是为了效率，而是为了让至少每个人在某一块上有真实的掌控感。完全交给 AI 的团队，会在三年后发现自己没有能独立定位核心故障的人。

关于「AI 会让程序员消失」的现实判断

这两年最实际的变化不是岗位减少，而是岗位的分层变陡了。

能定义问题、能判断方案、能兜住风险的人越来越稀缺；只能照着描述调 API、拼界面、做样板代码的人，需求确实在收缩——因为这些正好是 AI 最擅长的。

所以问题不是学会不学 AI，而是你让别人看到的能力里，有多少是 AI 也能做的。回答这个问题的唯一方式，是去掌握那些 AI 提供不了的东西：判断、取舍、对系统的体感、承担责任。

小结

同样的工具，两种用法，两年后是两种能力水平。区别就三点：有没有先形成自己的假设，有没有逆向补课调试推理，有没有保留真实的反馈回路。这三点都不需要更多时间，只需要改变动作的顺序。