Vibe Coding on Code Plato

AI时代，还有必要练习编程吗？

Mon, 25 May 2026 00:00:00 +0000

AI时代已经开始流行所谓的 “Vibe Coding” 了，那么还有必要练习编程吗？

我认为，还是有必要的。

虽然我之前写过一篇文章，提到可以利用 AI 来帮助精炼阅读内容、快速理解文章结构，但有几个现实问题并不会因为 AI 的出现而改变。

人脑单位时间内能够学习到的知识量，其实并不会改变。简单来说，无论未来 AI 技术发展得多快，你学习知识的速度并不会同步变快。学习本身并没有真正的捷径。
AI 在训练时，既学习了好的代码，也学习了坏的代码。有时候坏代码不一定是"错误代码"，它可能只是充满坏味道、难维护、架构混乱的代码。如果你自己看不出来问题，那么 AI 往往也看不出来。

例子1

很多东西，有经验的人第一眼看过去，和没有经验的人看到的是完全不同的。

比如在 React 中，当你看到这样一段代码：

const phone = {
 name: 'iPhone',
 price: {
 payInFull: 1000,
 monthlyFin: 99
 }
};

某天，产品经理让你增加一个"快照页面"。这个页面需要展示商品当前状态的一个快照，即使商品后续状态发生变化，快照页面里的内容也不应该改变。

AI 很快帮你生成了这样一段代码：

const phone = {
 name: 'iPhone',
 price: {
 payInFull: 1000,
 monthlyFin: 99
 }
};

<Snapshot {...phone} />

你看到 {...phone}，心里想：

“这个我懂，不就是对象拷贝吗？”

结果没过多久，客服部门报告了一个 Bug：在父组件内修改价格后，快照页面里的价格竟然也一起改变了。

你非常困惑，觉得这不应该发生。

经过研究后，你发现：

<Snapshot {...phone} />

并不等于：

const snapshot = {...phone}

前者只是 React 的一种 props spread 语法糖。

于是你修改了代码：

const phone = {
 name: 'iPhone',
 price: {
 payInFull: 1000,
 monthlyFin: 99
 }
};

const snapshot = {...phone};

<Snapshot {...snapshot} />

结果还是不行。

后来你才发现，真正需要的是：

const snapshot = structuredClone(phone);

如果是曾经踩过类似坑的人，或者真正认真学习过 JavaScript 对象引用机制的人，往往一眼就能看出问题所在。

例子2

你有没有过这样的经历：

看教程的时候，感觉什么都会；真正开始自己写的时候，却一个字都写不出来。

我前段时间在学习一门 Data Science 课程。课堂上老师讲的内容，对于一个工程师来说其实并不复杂。

top1 = Table.read_table(path_data + 'top_movies_2017.csv')

但当我真正开始做作业时，题目要求我读取 top_movies_2017.csv，我却突然大脑一片空白。

我不断尝试：

read_csv
import_csv

等等各种可能的方法。

但奇怪的是，这个 Table.read_table 我明明在课本上看过很多遍。

后来我意识到，人脑学习知识的方式并不仅仅是"阅读"。学习往往是多种感官共同参与的过程。

可能有听觉，有触觉，有遇到挫折后的思考，还有不断尝试与失败的过程。而这些过程本身，其实也是记忆的一部分。

很多知识，并不是"看懂了"就真的学会了。

总结

虽然 AI 可以帮助我们快速提炼文章纲要、总结重点，但它更多只是给了我们一张地图。

它可以帮助我们跳过一些暂时不感兴趣的内容，避免把时间浪费在不重要的部分。

但我们必须清醒地认识到：

如果你学习知识本身的速度并没有真正变快，那么也不要轻易相信"AI时代普通人也可以编程"这种过度乐观的话。

“普通人可以生成代码”，并不等于"普通人可以写出可维护的商业产品"。

AI 可以帮助你加速。

但它无法替代你真正理解系统、理解代码、理解工程复杂性的过程。

AI时代应该怎么写代码：督导和编排

Wed, 20 May 2026 00:00:00 +0000

程序员的迷茫

程序员这个行业从来没有像现在这么迷茫过。我看到太多不同的说法：

有个老板要求员工的 AI 写代码率必须超过 70%
有的人手写代码，然后让 AI 来写单元测试、做测试
有人在面试时被问到是否用过 Claude Code，会觉得很生气
有人说 vibe coding 是一场赌博
有人说程序员要失业了，我们不再需要程序员了
有人说只要用 TDD、BDD 写出来的项目就会很稳定
有人说 AI 写出来的代码，测试都能通过，但实际一运行就挂掉
有人说 AI 编程是个骗局，只是各大厂商为了卖 token 的营销手段

2 个坏消息

其实这些说法都对了一部分，也错了一部分。我想说两个坏消息：

Cursor 会死，JetBrains 会死，甚至 Copilot 也会死，几乎整个 IDE 产业最后可能都不存在
虽然已经裁了很多程序员了，但裁得还不够

我不喜欢坏消息，但我也不喜欢假装一切都很好。这就像你明明有重大疾病，却不去体检一样。这样只会害了你。

AI 编程的极限

这几个月 AI 编程领域高歌猛进。看起来它似乎是无敌的，最终会统治世界。确实，我们现在对 AI 编程的开发还远远没有到极限。

但是，AI 编程是有极限的。

我们要知道，我们现在用来编程的 AI，其实不是 AGI。我们既然是专业人士，就不要再用"AI"这个笼统的词了。我们真正使用的是大语言模型（LLM）。

大语言模型的工作原理，本质上是预测下一个 token。这跟抽象思维、大局思维、创造力并不是一回事。

所以，大语言模型有几个非常致命的问题：架构偏移、软件熵增、上下文困境、token 滥用。

架构偏移：如果你让 LLM 长时间独立完成一件事情，它最终可能会偏离轨道，走到一个你完全想不到的方向。
软件熵增：如果你让 LLM 自己写一个大型项目，最终很可能会生成屎山代码。实际上甚至不需要大型项目，只要让它写一个稍微复杂一点的模块，都可能出现代码质量失控。我甚至发现，让它帮我写一个类的单元测试，它也能写出屎山代码。
上下文困境：当上下文过长时，LLM 的工作效率会明显下降，因为过长的上下文会让它"分心"。于是你会陷入两难：压缩上下文，会丢失信息；不压缩上下文，LLM 又几乎无法高效工作。你当然可以通过摘要、归档以及渐进式披露来缓解这个问题，但代价就是性能下降。LLM 每做一次修改，都可能需要思考很久。
token 滥用：这是一个非常现实的问题。token 是要付费的，而且并不便宜。你没有无限的 token 可以挥霍。但由于缺乏监管的 AI 容易写出糟糕的逻辑和单元测试，最终会导致你修改逻辑时的 token 消耗越来越高，让维护成本变得越来越昂贵。

程序员的作用

程序员不会失业，但"写代码的程序员"这个职业会逐渐消失。

写代码的方式会彻底改变，而且会分成两个阶段：督导和编排。

督导

有人问，用 AI 写代码的比例多少比较合适。

我的答案是：100%。

当人类开始使用拖拉机播种之后，人工播种的比例是多少？是 0%。

用了 AI 写代码之后，人类已经没有必要继续用缓慢、而且容易拼写错误的方式手写代码。你真正要做的事情，是"督导"。

督导的作用，就是克服 LLM 的那 4 个核心问题。

程序员的大部分时间，将不再是写代码，而是审核 AI 写的代码、提出修改意见，并防止 AI 下次再犯同样的错误。或者指导 AI 用更好的实践去管理代码。

所以，设计模式、代码整洁、代码品味、重构、如何写好的单元测试——这些以前看起来很高级的东西，现在会变成基础能力。

原因很简单，不是为了"优雅"，而是为了一个很现实的目标：

写出可维护、bug 更少、并且节省 token 的代码。

IDE 的终结

但这样一来，其实已经不太需要传统 IDE 了。

因为 IDE 本质上是为了"人类写代码"而诞生的。

如果 AI 写的代码不会出现低级错误，也不需要 auto-complete，而人类自己又不再直接写代码，那么 IDE 中那些辅助人类编写代码、重构代码的功能，其意义就会大幅下降。

未来也许还会有 IDE，但会是非常轻量级的 IDE：秒开、功能简单，只保留一些最基础的能力。

而且这种东西很难再形成高利润产业，因为它太简单了，最终一定会出现大量开源、免费的替代方案。

就像胶卷和录像带租赁行业一样，这个产业最终会逐渐消失。

编排

单独开一个 agent 写代码，效率其实还是不够高。

你可以回忆一下，当你拿到一个新的 requirement 时，你是怎么工作的。

你肯定不是直接开始写代码。

你会先细化需求、设计实现方案，有时候甚至还需要先做 POC 验证方案，然后才开始真正写代码、测试功能。

所以，最终整个软件开发流程都会 AI 化。

但由于上下文问题的存在，又无法让一个 agent 完成所有事情。

注意：这并不是"上下文长度限制"这种可以单纯靠技术升级解决的问题，而是 LLM 工作原理本身带来的限制。

所以，未来真正的开发环境，很可能会变成一个完整的 AI 工作流。

整个工作流中，会有多个不同角色的 AI 工作者：

开发方案设计者 + N 个开发者 + 测试方案设计者 + N 个测试者

之所以没有"需求分析者"这个角色，是因为这部分最好仍然由人类亲自完成。

因为需求分析只要偏移一点点，后面的整个架构就可能彻底偏掉。

但这个工作流并不是搭建完就没事了。

因为如果你让它自己无限制地运行，它绝对会耗费大量 token，最终给你生成一个不可维护的屎山代码库。这就是架构偏移。

虽然 OpenAI 和 Anthropic 都在研究长时间运行的 AI 项目开发，但你可以把这些研究理解成"实验室中的理想环境"。

它们不需要太在意 token 消耗，但你需要。

而且我相信，它们所谓的"长时间运行项目"，本质上也是有督导存在的。人工需要不断增加规则、纠正 AI 的工作方式。

这其实也就是现在越来越多人提到的 Harness Engineering。

于是，程序员最终的工作，就会变成：

搭建、调试并使用这个 AI 工作流。

因为你仍然需要督导 AI。

总结

因为 LLM 在原理上存在一些暂时无法解决的问题，所以程序员这个职业，短时间内仍然会以另一种形态继续存在。

直到真正的 AGI 出现的那一天。

但我还是希望大家尽快开始转型，否则很可能会被这个时代淘汰。