最近做项目的时候，我突然想明白了一件事：可能再过几年，我们回头看现在，会发现程序员这个职业真正发生变化的，并不是“AI 开始帮我们写代码了”，而是代码本身的位置变了。

以前做一个东西，最大的障碍往往是“不会写”。一个想法出现在脑子里，接下来就是漫长的实现过程：查文档、找框架、设计接口、写代码、调试、改 Bug。很多时候，一个想法最后没有变成产品，不是因为想法不好，而是因为实现成本太高。所以过去我们花了大量时间学习“怎么实现”，怎么写得更快，怎么写得更好，怎么设计得更优雅。

但 AI 出现以后，这件事正在慢慢反过来。现在真正让我停下来的问题，经常已经不是“这个东西怎么写”，而是**“我到底应该让它写成什么样？”** 这两个问题看起来很像，其实完全不是一回事。

AI 可以非常高效地，帮你做出一个错误的东西

以前我会觉得，只要把需求描述清楚，然后让 AI 把代码写出来，项目跑起来，这件事基本就完成了。后来慢慢发现，不是。

AI 真正让我产生警惕的地方，甚至不是它会犯错，而是它可以非常快、非常认真、非常完整地，把一个没有想清楚的东西做出来。页面有了，接口有了，数据库有了，测试通过了，Docker 跑起来了，甚至已经部署上线了。一切看起来都像是“完成了”，可某个瞬间你会突然问自己：所以呢？它真的解决问题了吗？

它解决的是我最开始想解决的那个问题吗？还是说，我只是成功地做出了一个“可以运行的东西”？这个问题让我想了很久。

以前代码写得慢的时候，我们反而不太容易意识到这一点。因为“实现”本身太难了，大量精力被代码吸走，以至于一个项目只要真的跑起来，就已经足够让人产生很强的成就感。但现在不一样，AI 把实现速度拉得越来越快，一个过去可能需要几周的东西，现在几天甚至几个小时就能看到雏形。

于是，以前被“实现成本”遮住的问题开始露出来了：当实现不再是最难的事情以后，你究竟要实现什么？

我觉得这才是 AI 编程真正有意思的地方。它表面上是在降低程序员的门槛，实际上却把另一道门槛抬得越来越高——判断。

“做出来”和“做好”，开始变成两件完全不同的事

以前我们很习惯说一句话：“功能做完了。”但现在我越来越觉得，这句话不够了。

尤其是在 AI 系统里，程序没有报错，不代表答案是对的；Agent 顺利执行完，不代表任务真的完成了；所有接口都返回 200，也不代表用户的问题真的被解决了。一个系统完全可以在技术上运行得非常漂亮，同时在真正的问题上答得一塌糊涂。

所以我慢慢意识到，未来真正困难的事情，可能不是让机器工作，而是定义什么叫“工作得对”。

这句话让我重新理解了“工程能力”这四个字。

以前提到工程能力，我首先想到的是代码能力、架构能力、调试能力、性能优化能力。这些当然依然重要，但 AI 时代似乎正在这些能力上面再增加一层：你能不能把一个模糊的想法变成一个清楚的问题？能不能把“做得好一点”变成机器能够理解的具体要求？能不能提前告诉机器哪些事情绝对不能发生？当机器给出一个看起来不错的结果以后，你有没有办法证明它是真的不错，而不是“我感觉不错”？

想明白这些以后，我对 AI 编程的理解发生了一点变化。我不再觉得最重要的是 怎么让 AI 多帮我写一点代码，而是开始在意 怎么让 AI 在一个我真正想清楚的方向上工作。

如果方向本身是模糊的，AI 越快，可能只是让我们更快地走向一个错误的地方。如果问题没有定义清楚，那么再漂亮的架构、再复杂的 Agent、再先进的模型，都只是在精确地解决一个模糊的问题。

AI 把实现变快，也把“想清楚”这件事提前了

以前开发慢，我们其实有很多时间在写代码的过程中不断思考。写到一半发现需求不对，改；接口设计到一半发现逻辑有问题，再改。很多产品思考，其实是在漫长的开发过程中被迫完成的。

AI 把这个过程压缩以后，这种缓冲反而少了。以前一个星期以后才会出现的问题，现在可能一个下午就摆在你面前。代码已经写完了，页面也能用了，可你突然发现自己甚至没有认真想过：这个功能到底为什么存在？

所以 AI 并没有让“思考”变得不重要，反而要求我们更早地思考。代码之前的东西，开始变得比以前更重要。

这也让我重新思考人与 AI 的分工。未来可能并不是简单的“AI 写代码，人不用写了”，而更像是：人负责定义，机器负责展开。

人说清楚要去哪里，机器寻找怎么去；人划定边界，机器在边界里寻找方案；机器给出结果，人判断结果是否符合目标，然后再让机器继续修改。如果这个方向成立，那么程序员真正需要守住的东西，其实不是键盘，而是对问题的控制权。

工程能力没有消失，只是被往上推了一层

框架会变，模型会变，今天流行的工具，几年以后可能完全是另一套。但面对一团模糊的信息，能不能找到真正的问题；面对一个复杂的问题，能不能划出清楚的边界；面对一个看似漂亮的答案，能不能判断它到底对不对；面对一个已经运行的系统，能不能知道下一步应该改哪里——这些能力不会因为模型升级而突然失效。

它们以前其实就很重要，只是 AI 出现以后，突然变得更加显眼了。

所以最近我有一个越来越强烈的感觉：AI 并没有让工程能力变得不重要，它只是把“工程能力”这四个字，从代码里往外推了一层。

以前我们更多站在代码里面解决问题，以后可能越来越多地站在代码上面设计问题。代码依然重要，但它开始更像一个结果。就像建筑最终会被施工出来一样，真正决定它是什么的，并不只是砌砖的速度。我们还需要知道为什么要建这栋房子，它应该是什么样，以及建完以后，凭什么说它达到了最开始的目的。

想通这一点之后，我突然觉得很多事情都顺了。为什么现在项目可以越做越快，却不一定越来越好；为什么 AI 越来越强，自己反而越应该学会思考；为什么“会用 AI”最终不会是一种特别稀缺的能力；以及为什么以后人与人之间真正拉开差距的，可能不是谁能让 AI 写出更多代码，而是谁能够更清楚地告诉机器：我们到底在解决什么？

然后还有后半句：

它到底有没有解决？

所以现在，如果让我重新理解 AI 时代的工程能力，我大概会把它浓缩成一句话：

AI 时代，代码正在变成产物；真正的工程能力，是定义正确的问题、给出精确的约束，并建立机制证明机器确实解决了它。

以前，我更在意的是“怎么把它做出来”。

现在我开始觉得，在这个问题前面，还应该永远放着另一个问题：

我想清楚了吗？