AI 时代程序员的护城河是什么？

一个被忽视的问题

最近经常有人问我："AI 这么强，程序员还有出路吗？"

这个问题本身就暴露了一个盲区：提问的人还在用"程序员"这个身份思考自己的职业。

问题出在"程序员"这三个字上。这个词本身没毛病，但它把人的思维框住了。你开始觉得自己就是一个"写代码的"，AI 写得比你快，你就慌了。

但换个角度想：一个做建筑的人不会因为挖掘机出现就失业。他需要的是理解"要建什么"，不是"怎么挖土"。

AI 就是那台挖掘机。你该操心的是会不会建房子。

时代变了，但大多数人的思维方式没变

用一个简单的类比。

农业时代，90% 的人种地。关注的都是"种什么、怎么种、够不够吃"。后来有了拖拉机，一个人能干十个人的活。那些只会种地的人慌了，但有人开始研究"这块地适合种什么、怎么卖出去、怎么规划明年的产量"。

工业时代，大家进工厂，关注的都是"怎么造得更快、更便宜"。后来有了自动化流水线，机器比人快一百倍。只会拧螺丝的人慌了，但有人开始研究"这个产品用户需要吗、怎么设计、怎么卖到国外去"。

信息时代，大家学编程，关注的都是"用什么框架、怎么优化性能、怎么写出优雅的代码"。现在 AI 来了，代码生成速度比人快几十倍。只会写代码的人慌了。

看出规律了吗？

每个时代的技术变革，淘汰的从来不是"从事这个行业的人"，是"只会用旧方式做事的人"。工具在升级，但大多数人还在用上一个时代的思维方式工作。

从"程序员"到"工程师"

我一直觉得，别把自己定位为程序员，要定位为工程师。

这两者的区别在哪？

程序员关注的是"怎么写"。用什么语言、什么框架。说白了，都是手段，是工具。

工程师关注的是"解决什么问题"。这个需求合理吗？用户真正想要什么？有没有更简单的方案？上线之后出了问题怎么排查？

我近几天写过一篇文章叫《60 行代码让 Agent 输出更加完美》，核心观点就一句话：好的 Prompt 工程，不是话术技巧，是工程思维。你得先搞清楚"要做什么"，再想"怎么做"。

这个逻辑在 AI 时代只会越来越重要。"怎么做"这件事，AI 已经做得比你好了。你剩下的价值，全在"做什么"和"为什么"上面。

三件事，AI 做不了

说了这么多，具体哪些能力是 AI 短期内无法替代的？我觉得有几个。

1. 理解真实需求

用户说"我想要一个商品详情页"，AI 会直接给你生成一套完整页面，轮播图、规格选择、评价列表、推荐商品一应俱全。但真实的场景可能是：这个详情页的核心目标是提升转化率，那应该先做 A/B 测试验证主图方案，而不是上来就堆功能；或者用户数据表明 80% 的访问来自小程序，那 WebView 的性能瓶颈才是优先要解决的问题。

理解需求不是"听到什么做什么"。它要求你具备业务判断力，知道用户说的和想要的可能不是一回事，知道什么时候该追问，什么时候该简化。

这个能力来自你对业务的理解、对用户的同理心、在真实项目里踩过的坑。AI 没有这些经历，它只能基于文字做推理。

2. 做决策和取舍

技术方案从来不是非黑即白的。用微服务还是单体？自己实现还是用现成方案？先上 MVP 还是直接做完整版？这些问题的答案取决于具体上下文。

这些决策需要权衡：技术债务、开发成本、团队现状、业务阶段、上线时间。每个项目的答案都不一样。

AI 的默认倾向是"全都要"。它会给你一个功能完备、扩展性强、类型安全的方案。但真实世界里，最好的技术决策往往不是"最完美"的，是"最适合当前情况"的。

我给 AI 编码定过一个原则：代码要简洁到让同行一眼就能看懂。这条标准在 AI 时代更加关键，因为现在你就是那个需要做取舍的人。

3. 系统性思维

写一个函数，AI 比你强。写一个模块，AI 也比你快。但设计一整套系统，从需求分析到架构设计，从接口定义到部署方案，这件事远超当前 AI 的能力边界。

系统性思维是你能在脑子里同时 hold 住几十个变量，理解它们之间的关系，做出全局最优而不是局部最优的决策。这是经验和判断力的结合，不是靠训练数据堆出来的。

这也是为什么我在研究多 Agent 协作的时候，特别强调文件冲突规避和任务边界划分。因为一旦系统复杂度上来了，协调能力就成了成败的关键。

具体怎么做

道理讲完了，来点实在的。

把 80% 的精力放在"理解问题"上

我见过太多人（包括我自己），拿到需求就开干。结果做了一半发现方向不对，推倒重来。

AI 时代更不能这样。你让 AI 帮你干活，但你自己都没想清楚要什么，AI 只会用它最擅长的"猜测"来填你的需求空白。猜对了是运气，猜错了你得花更多时间去纠偏。

在你写出第一行代码（或给 AI 第一条指令）之前，先把这些问题想清楚：

• 真正要解决的问题是什么？
• 有没有更简单的方案？
• 哪些部分是确定的，哪些是不确定的？
• 不确定的部分，最简验证方式是什么？

建立自己的"问题框架"

什么是问题框架？就是你在面对一个新需求时，大脑里自动弹出的一套检查清单。

比如我面对一个功能需求，脑子里会过这些问题：

• 这个需求背后的业务目标是什么？
• 最小可用版本是什么？
• 哪些地方可能出错？
• 上线之后怎么验证效果？
• 依赖了哪些外部系统？它们稳定吗？

这些问题不是每次都完整走一遍，但它们像肌肉记忆一样，在你做决策的时候提供支撑。

在 AI 时代，你的价值不是"知道答案"，是"知道该问什么问题"。

保持"工程师"的视角，不要变成"提示词工程师"

"提示词工程师"这个词我很反感。它把人定位成了"和 AI 对话的人"，好像你的全部工作就是想怎么跟 AI 说话。

但你想想，一个项目经理的价值不在于"会说话"，在于"知道该让团队做什么"。跟 AI 协作也一样。你的价值在于定义清楚目标、制定验收标准、把控输出质量，不是研究怎么用更花哨的 prompt。

工具是你的手，不是你的脑。

拥抱工具，但不要依赖工具

最后说一点很现实的。

AI 确实在改变我们的工作方式。写代码的速度快了很多，很多重复性工作可以被自动化了。这是好事。

但如果有一天你的所有工作都是"让 AI 帮你做"，然后你 review 一下，那你其实已经变成了一个"AI 的质检员"。这个位置不稳固，因为 AI 的输出质量在持续提升，总有一天质检这个环节也不需要了。

更危险的一种情况是：一旦 AI 工具出故障，你就手足无措了。AI 服务宕机、API 限流、模型版本更新导致输出变差，这些事我遇到过不少。这时候如果你连"自己写代码"这件事都做不到，就真的被动了。我第一次遇到 CodeBuddy 挂掉的时候，对着屏幕发呆了一会，然后开始沉思：我有多久没自己从头写一个函数了？

所以现在我会给自己准备一套降级方案：CodeBuddy 挂了，切 CodeBuddy CLI；CLI 也不行，还有 OpenCode。总得留一条路，不至于一个工具出问题就停工。这跟系统设计里的容灾是一个道理，只不过容的对象变成了你自己的工作流。

你需要保留一部分"自己动手"的能力。不是说所有代码都自己写，而是核心的、复杂的、需要深度思考的部分，你要有能力自己搞定。这样即使 AI 帮不了你，你也不会束手无策。

写在最后

回到开头的问题：AI 时代程序员的护城河是什么？

不是某门语言、某个框架、某种算法。这些东西 AI 都会，而且学得比你快。

护城河是：理解真实需求的能力，知道用户要什么而不是只听到用户说了什么；做决策和取舍的能力，在多种方案中选出最适合当前情况的那个；还有系统性思维，能 hold 住复杂系统的全局视角。

没有一条是通过"学更多的技术"获得的。它们需要你深入业务，积累经验。

说得直白一点：AI 时代，"码农"确实危险了。但"工程师"从来没这么值钱过。

别纠结于"程序员"这个 title 了。叫自己工程师吧。然后，去解决真正的问题。