<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>思考 on HanGR的碎碎念</title><link>https://han-gr.github.io/tags/%E6%80%9D%E8%80%83/</link><description>Recent content in 思考 on HanGR的碎碎念</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Wed, 09 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://han-gr.github.io/tags/%E6%80%9D%E8%80%83/index.xml" rel="self" type="application/rss+xml"/><item><title>AI 时代，代码正在变成产物</title><link>https://han-gr.github.io/p/2026-09-09-ai-%E6%97%B6%E4%BB%A3%E4%BB%A3%E7%A0%81%E6%AD%A3%E5%9C%A8%E5%8F%98%E6%88%90%E4%BA%A7%E7%89%A9/</link><pubDate>Wed, 09 Sep 2026 00:00:00 +0000</pubDate><guid>https://han-gr.github.io/p/2026-09-09-ai-%E6%97%B6%E4%BB%A3%E4%BB%A3%E7%A0%81%E6%AD%A3%E5%9C%A8%E5%8F%98%E6%88%90%E4%BA%A7%E7%89%A9/</guid><description>&lt;p&gt;最近做项目的时候，我突然想明白了一件事：可能再过几年，我们回头看现在，会发现程序员这个职业真正发生变化的，并不是“AI 开始帮我们写代码了”，而是&lt;strong&gt;代码本身的位置变了。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;以前做一个东西，最大的障碍往往是“不会写”。一个想法出现在脑子里，接下来就是漫长的实现过程：查文档、找框架、设计接口、写代码、调试、改 Bug。很多时候，一个想法最后没有变成产品，不是因为想法不好，而是因为实现成本太高。所以过去我们花了大量时间学习“怎么实现”，怎么写得更快，怎么写得更好，怎么设计得更优雅。&lt;/p&gt;&#10;&lt;p&gt;但 AI 出现以后，这件事正在慢慢反过来。现在真正让我停下来的问题，经常已经不是“这个东西怎么写”，而是**“我到底应该让它写成什么样？”** 这两个问题看起来很像，其实完全不是一回事。&lt;/p&gt;&#10;&lt;h2 id="ai-可以非常高效地帮你做出一个错误的东西"&gt;AI 可以非常高效地，帮你做出一个错误的东西&#10;&lt;/h2&gt;&lt;p&gt;以前我会觉得，只要把需求描述清楚，然后让 AI 把代码写出来，项目跑起来，这件事基本就完成了。后来慢慢发现，不是。&lt;/p&gt;&#10;&lt;p&gt;AI 真正让我产生警惕的地方，甚至不是它会犯错，而是它可以非常快、非常认真、非常完整地，把一个&lt;strong&gt;没有想清楚的东西&lt;/strong&gt;做出来。页面有了，接口有了，数据库有了，测试通过了，Docker 跑起来了，甚至已经部署上线了。一切看起来都像是“完成了”，可某个瞬间你会突然问自己：&lt;strong&gt;所以呢？它真的解决问题了吗？&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;它解决的是我最开始想解决的那个问题吗？还是说，我只是成功地做出了一个“可以运行的东西”？这个问题让我想了很久。&lt;/p&gt;&#10;&lt;p&gt;以前代码写得慢的时候，我们反而不太容易意识到这一点。因为“实现”本身太难了，大量精力被代码吸走，以至于一个项目只要真的跑起来，就已经足够让人产生很强的成就感。但现在不一样，AI 把实现速度拉得越来越快，一个过去可能需要几周的东西，现在几天甚至几个小时就能看到雏形。&lt;/p&gt;&#10;&lt;p&gt;于是，以前被“实现成本”遮住的问题开始露出来了：&lt;strong&gt;当实现不再是最难的事情以后，你究竟要实现什么？&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;我觉得这才是 AI 编程真正有意思的地方。它表面上是在降低程序员的门槛，实际上却把另一道门槛抬得越来越高——&lt;strong&gt;判断。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;h2 id="做出来和做好开始变成两件完全不同的事"&gt;“做出来”和“做好”，开始变成两件完全不同的事&#10;&lt;/h2&gt;&lt;p&gt;以前我们很习惯说一句话：“功能做完了。”但现在我越来越觉得，这句话不够了。&lt;/p&gt;&#10;&lt;p&gt;尤其是在 AI 系统里，程序没有报错，不代表答案是对的；Agent 顺利执行完，不代表任务真的完成了；所有接口都返回 200，也不代表用户的问题真的被解决了。一个系统完全可以在技术上运行得非常漂亮，同时在真正的问题上答得一塌糊涂。&lt;/p&gt;&#10;&lt;p&gt;所以我慢慢意识到，未来真正困难的事情，可能不是让机器工作，而是&lt;strong&gt;定义什么叫“工作得对”。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;这句话让我重新理解了“工程能力”这四个字。&lt;/p&gt;&#10;&lt;p&gt;以前提到工程能力，我首先想到的是代码能力、架构能力、调试能力、性能优化能力。这些当然依然重要，但 AI 时代似乎正在这些能力上面再增加一层：你能不能把一个模糊的想法变成一个清楚的问题？能不能把“做得好一点”变成机器能够理解的具体要求？能不能提前告诉机器哪些事情绝对不能发生？当机器给出一个看起来不错的结果以后，你有没有办法证明它是真的不错，而不是“我感觉不错”？&lt;/p&gt;&#10;&lt;p&gt;想明白这些以后，我对 AI 编程的理解发生了一点变化。我不再觉得最重要的是 &lt;strong&gt;怎么让 AI 多帮我写一点代码&lt;/strong&gt;，而是开始在意 &lt;strong&gt;怎么让 AI 在一个我真正想清楚的方向上工作。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;如果方向本身是模糊的，AI 越快，可能只是让我们更快地走向一个错误的地方。如果问题没有定义清楚，那么再漂亮的架构、再复杂的 Agent、再先进的模型，都只是在精确地解决一个模糊的问题。&lt;/p&gt;&#10;&lt;h2 id="ai-把实现变快也把想清楚这件事提前了"&gt;AI 把实现变快，也把“想清楚”这件事提前了&#10;&lt;/h2&gt;&lt;p&gt;以前开发慢，我们其实有很多时间在写代码的过程中不断思考。写到一半发现需求不对，改；接口设计到一半发现逻辑有问题，再改。很多产品思考，其实是在漫长的开发过程中被迫完成的。&lt;/p&gt;&#10;&lt;p&gt;AI 把这个过程压缩以后，这种缓冲反而少了。以前一个星期以后才会出现的问题，现在可能一个下午就摆在你面前。代码已经写完了，页面也能用了，可你突然发现自己甚至没有认真想过：&lt;strong&gt;这个功能到底为什么存在？&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;所以 AI 并没有让“思考”变得不重要，反而要求我们更早地思考。&lt;strong&gt;代码之前的东西，开始变得比以前更重要。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;这也让我重新思考人与 AI 的分工。未来可能并不是简单的“AI 写代码，人不用写了”，而更像是：&lt;strong&gt;人负责定义，机器负责展开。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;人说清楚要去哪里，机器寻找怎么去；人划定边界，机器在边界里寻找方案；机器给出结果，人判断结果是否符合目标，然后再让机器继续修改。如果这个方向成立，那么程序员真正需要守住的东西，其实不是键盘，而是&lt;strong&gt;对问题的控制权。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;h2 id="工程能力没有消失只是被往上推了一层"&gt;工程能力没有消失，只是被往上推了一层&#10;&lt;/h2&gt;&lt;p&gt;框架会变，模型会变，今天流行的工具，几年以后可能完全是另一套。但面对一团模糊的信息，能不能找到真正的问题；面对一个复杂的问题，能不能划出清楚的边界；面对一个看似漂亮的答案，能不能判断它到底对不对；面对一个已经运行的系统，能不能知道下一步应该改哪里——这些能力不会因为模型升级而突然失效。&lt;/p&gt;&#10;&lt;p&gt;它们以前其实就很重要，只是 AI 出现以后，突然变得更加显眼了。&lt;/p&gt;&#10;&lt;p&gt;所以最近我有一个越来越强烈的感觉：&lt;strong&gt;AI 并没有让工程能力变得不重要，它只是把“工程能力”这四个字，从代码里往外推了一层。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;以前我们更多站在代码里面解决问题，以后可能越来越多地站在代码上面设计问题。代码依然重要，但它开始更像一个结果。就像建筑最终会被施工出来一样，真正决定它是什么的，并不只是砌砖的速度。我们还需要知道为什么要建这栋房子，它应该是什么样，以及建完以后，凭什么说它达到了最开始的目的。&lt;/p&gt;&#10;&lt;p&gt;想通这一点之后，我突然觉得很多事情都顺了。为什么现在项目可以越做越快，却不一定越来越好；为什么 AI 越来越强，自己反而越应该学会思考；为什么“会用 AI”最终不会是一种特别稀缺的能力；以及为什么以后人与人之间真正拉开差距的，可能不是谁能让 AI 写出更多代码，而是谁能够更清楚地告诉机器：&lt;strong&gt;我们到底在解决什么？&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;然后还有后半句：&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;它到底有没有解决？&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;所以现在，如果让我重新理解 AI 时代的工程能力，我大概会把它浓缩成一句话：&lt;/p&gt;&#10;&#10; &lt;blockquote&gt;&#10; &lt;p&gt;&lt;strong&gt;AI 时代，代码正在变成产物；真正的工程能力，是定义正确的问题、给出精确的约束，并建立机制证明机器确实解决了它。&lt;/strong&gt;&lt;/p&gt;&#10;&#10; &lt;/blockquote&gt;&#10;&lt;p&gt;以前，我更在意的是“怎么把它做出来”。&lt;/p&gt;&#10;&lt;p&gt;现在我开始觉得，在这个问题前面，还应该永远放着另一个问题：&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;我想清楚了吗？&lt;/strong&gt;&lt;/p&gt;&#10;</description></item></channel></rss>