AI时代，开发者的竞争力到底是什么

最近用 AI 写代码的时间越来越多，手上的活也渐渐从"怎么写"变成了"怎么想"。结合这段时间的体会，我聊聊自己的看法：AI 时代，开发者的竞争力到底是什么。

第一，是开发者的品味

说实话，写代码这种"细节活"，AI 已经干得比大多数人好、比大多数人快了。具体的语法、API 用法、怎么实现某个功能，这些根本不需要你再操心，丢给 AI 就行。

但顶层的东西，AI 现在还替代不了——比如你怎么做抽象。

同一个需求，有人抽象出来的接口一眼就能看懂，改起来顺手；有人抽象出来的东西，功能是能跑，但稍微一改就牵一发动全身。这种"品味"很难用语言教会 AI，它更像是你长期写代码、看过无数烂代码和好代码之后沉淀下来的一种直觉。

还有架构怎么设计、模块怎么划分、哪些东西该抽出来复用、哪些东西该保持简单，这些决策带来的影响，往往要过几个月、几年才能体现出来。AI 擅长的是在给定的框架里把活干好，而"定框架"这件事，还得靠人的品味。

再具体到开发功能时，我一般是这么做的

上面的品味偏"顶层"，说回日常开发一个具体功能，我总结了几点：

第一，明确需求与逻辑

作为人类，你要先自己把需求分析清楚，就像你自己写代码一样——你要知道每一行具体的逻辑是什么、它的边界是什么。这一点非常重要，因为 AI 不会替你思考"这个需求本身对不对"，你的需求描述得越清楚，它做出来的东西才越接近你要的。

第二，与 AI 协作，让它发散思维

每次写需求的时候，可以先和 AI 讨论一下，让它去发散思维：有哪些边界情况、有哪些可行的做法、有哪些坑可能会踩。把各种边界都讨论清楚之后，再由你来定夺。AI 是个很好的"参谋"，但拍板的人得是你。

第三，考验人的判断与取舍能力

到最后，考验的其实是你的问题判断能力。现在 AI 盛行，很多事情可以做也可以不做，而在有所取舍的地方，非常考验你对软件工程的理解。比如：

• 这段代码能不能稳定跑 5~10 年？ 是追求短期内能跑，还是考虑长期的演进和维护？
• 什么事情能交给 AI，什么事情不能？ 像安全、合规这些地方交出去出错的代价太大，就得自己上。

说实话，这也是我最近的困惑：真正到了做技术取舍、选方案的时候，我自己也有点不知道怎么做的感觉。

软件工程的理解和取舍，非常看重你的经验——也就是"你知道什么"。很多东西你见过、踩过坑，才知道哪个方案好；没见过的话，光靠想是想不出来优劣的。而 AI 恰恰相反，你让它给方案，它一口气能给你五六个，各有各的道理、每个都说得通。选项太多的时候，人做选择反而更难，这非常考验人。

所以这件事其实是分人群的：对工作时间长、什么技术都接触过的老开发者来说，AI 时代反而更友好——细节活 AI 干完了，你只需要用经验和判断做决定就行。但对新进来的开发者就不太友好了：各种东西自己都没亲手做过、没踩过坑，经验值几乎是零，再叠加 AI 给的多选题，反而更容易迷茫。以前新人是从一行行代码里慢慢攒经验，现在这条路被 AI 占了，怎么在 AI 时代积累"你知道什么"，可能是新人开发者要面对的最大问题。

第四，了解 AI 的底层原理

我们不需要自己去写 LLM 这些东西，但一些 AI 的原理是需要理解的，比如：

• 上下文机制：知道它为什么"记不住"、上下文窗口是有限的，你才会去裁剪、压缩输入；
• 提示词的优化：知道怎么描述，它才能更好地理解你的意图；
• 工具的调用与裁剪：工具不是越多越好，裁掉多余的工具，反而能减少出错的概率。

这些算是使用 AI 时的"内功"。懂了原理，踩坑的时候才知道坑在哪，不会一脸懵。

第二，测试是必须写的

AI 写的代码确实让人满意——语法正确、逻辑完整、注释齐全，看起来天衣无缝。

但你要小心一点：最终的验证结果不一定是对的。

AI 最会的本事就是自圆其说。它不会告诉你这里有 bug，它会很自信地跟你讲"这个逻辑已经处理了""这个边界情况考虑到了"，哪怕它根本没写。你问它有没有问题，它永远会给你一个听起来很合理的答案。

所以，测试类必须写。跑一遍，过就是过，不过就是不过，代码不会骗人。

这也是我最近用 AI 编程最深的一个感受：如果你自己不写测试、不去验证，AI 交付给你的只是一堆"看起来对"的代码，实际对不对，它自己说了不算。测试才是你跟 AI 之间唯一可信的仲裁者。

第三，人还得会读代码

测试解决的是"跑得对不对"，但光靠自动测试还不够——还有一条线是"人看得懂、review 得动"。

AI 现在写代码太快了，但合入之前总得有人把关。你能不能在一堆 AI 写出来的代码里看出问题、看出坏味道，判断出"它这么写到底对不对"，这同样是"你知道什么"的体现。经验这东西，在 review 的时候特别明显——老手扫一眼就能发现的隐患，新手翻半天可能都没感觉。

所以我的建议是：AI 写的代码，别直接合。自己先过一遍，看不懂的地方、觉得别扭的地方，就追问它为什么这么写。这个过程既是给 AI 把关，也是给自己长见识。

第四，e2e 也可以安排上

单测验证的是局部逻辑，但整个系统串起来对不对，光靠单测是不够的。

尤其当 AI 帮你改了一部分代码，你可能根本不知道它动了哪些地方、影响了哪些链路。这时候 e2e 测试就派上用场了——把关键的用户流程整个跑一遍，从入口到出口，验证系统整体还是不是那个样子。

我的建议是：核心业务流程的 e2e 尽量安排上。你不用覆盖所有场景，但主链路一定要有。有了它，你才能放心地让 AI 去改代码——改完跑一遍 e2e，绿了就是没改坏，红了就知道哪里出问题了。

最后

总结下来，我的看法是：

• 写代码的能力会越来越不值钱，因为 AI 越来越强；
• 顶层设计的能力会越来越值钱，因为抽象和品味很难被替代；
• 验证的能力会越来越重要，因为 AI 会自圆其说，只有测试能替你把关；
• 判断与取舍的能力会越来越值钱，因为软件工程的理解（能不能跑 5~10 年、什么能交给 AI）是 AI 给不了你的。

回到前面那个问题——新人怎么办？我的看法是：没有捷径，但也不用太悲观。经验这东西，AI 替不了你攒；但反过来，它也没帮任何人跳过攒经验的过程，所有人都是从"什么都不知道"走过来的。该读的代码还是要读，该追的 bug 根因还是要追，该自己动手写的东西还是要自己写——只是现在多了一个前提：得刻意避开 AI，或者让 AI 写完之后，自己再完整读一遍、改一遍、想清楚它为什么要这么写。AI 能帮你干活，但帮不了你长见识，见识只能自己一点点攒。

以后开发者的竞争力，不再是你敲代码多快、记得多少 API，而是你的品味、你的验证与把关能力、你的判断取舍，以及你对 AI 原理的理解——只有足够了解工具，才能更好地驾驭它。工具越来越强，最终决定项目质量的，还是那个掌舵的人。