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 出现的那一天。

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

AI编程 on Code Plato