我最近看 AI 编程这条线，有一个很强烈的感受：新词来得太快了。

去年之前还在讨论 Prompt。2026明显加速了，大家开始说 Skill，说不要每次都写一大段提示词，要把可复用的能力沉淀下来。最近又开始说 Loop，说 Agent 不能只回答一次，要能自己执行、观察、修正、继续。

我刚把 Loop 这件事想明白，又看到 RTS。

一开始我有点疲惫。

倒不是 RTS 这个说法不好。我真正疲惫的地方，是自己又被拖进了新名词里。每一个词看起来都很新，每一个词都像要开一扇门，但你追着追着就会忘记最开始的问题：这些东西到底想解决什么？

所以这篇文章，我不想再追名词。

我想把这件事从头捋一遍。Prompt、Skill、Loop、RTS，这些东西一路往前走，背后不变的东西是什么？如果 RTS 继续往前，开发工具会变成什么？

我的分析结论很简单：

AI 编程真正变化的地方，是人类正在从“亲自做事的人”，一点点变成“设计任务系统的人”。

再往后走，它大概率会走向 Agent Control Plane。

也就是一个能管理 Agent、任务、上下文、验证、权限、成本和合并流程的控制平面。

一、最早的问题：人还在一遍遍教 AI

Prompt 阶段，我们其实是在手把手教 AI。

你想让模型做一件事，就得把背景、目标、约束、输出格式、注意事项，全都塞进一段提示词里。

短任务还好。写邮件、翻译、解释概念，模型一般能接住。

但任务一长，问题就出来了。

它会忘前文，会误解你的目标，会在一个小地方走偏。你发现以后，只能重新解释一遍。它再偏，你再拉回来。

这时候你表面上是在用 AI，实际上一直是你在维持整个任务。

你像一个人坐在副驾驶，不停提醒司机：这里左转，那里减速，前面别走错。

这就是 Prompt 的瓶颈。

它把 AI 接进了工作流，但人的注意力没有被解放出来。你还是要盯着，你还是要反复说，你还是要处理每一次偏航。

二、Skill 出现以后，人开始少说重复的话

后来大家开始谈 Skill，我觉得这一步是很自然的。

因为所有认真用过 AI 的人，都会很快遇到一个问题：很多话每次都要重复。

你有一套写测试的习惯。

你有一套审查代码的标准。

你有一套写公众号的结构。

你有一套拆需求的方法。

每次都把这些东西重新塞进 Prompt 里，很笨，也很浪费。

Skill 做的事情，就是把这些可复用的能力提前封装起来。下次你不用再解释一遍“我希望你怎么做”，而是直接调用那套流程。

这一步的本质，是把人的经验从一次性对话里拿出来，变成可以反复使用的模块。

它有点像软件工程里的函数。

第一次写一段逻辑时，你可能直接写在业务代码里。写多了以后，你会发现它应该被抽出来。因为它不是某一次任务的临时表达，它已经变成了一种能力。

Skill 也是这样。

它让 AI 不再每次都从零开始，也让人不用每次都重复交代。

但 Skill 还不够。

因为很多任务不是“照流程做一次”就能完成的。写代码尤其如此。你做一步，结果会变。测试会报错，环境会缺依赖，需求会露出新的边界。复杂任务需要来回修正。

所以会走到 Loop。

三、Loop 真正让我意识到：AI 开始像做事的人了

Loop 这个词，我觉得比 Skill 更重要。

Skill 解决的是复用，Loop 解决的是推进。

AI 不再只是按你的要求输出一个答案，而是开始进入一个循环：执行一步，看结果，发现问题，修改，再执行。

写代码时，这个变化很明显。

过去你让 AI 写一段代码，它给你一个版本。能不能跑，得你自己试。

到了 Loop，它可以自己跑测试。测试失败了，它去读报错。读完再改。改完再跑。

这个过程很像人做事。

人也不是一上来就把所有事情做对。人是试一下，发现不对，改一下，再试。

所以 Loop 的意义，不只是“多跑几轮”。它让 AI 从回答问题，开始靠近执行任务。

但我后来又发现，Loop 也有一个很明显的边界：它通常还是一条线。

一个 Agent 沿着一条路径往前走。它可以纠错，可以回头，可以继续试，但它大多数时候还是单线程的。

这在小任务里够用。

可是一旦任务变复杂，单线程就慢了。

同一个 bug，可能有好几种切入方式。可以从测试失败入手，可以从 issue 描述入手，可以从最近的 commit 入手，可以先做复现，也可以先读架构。

如果只让一个 Agent 一条路走到底，它很可能在一个错误方向上消耗很久。

这个时候，RTS 这个比喻就突然变得有意思了。

四、RTS 说的不是游戏，是人的位置又变了

RTS 是实时战略游戏。

这个比喻最直观的地方在于：你不能只盯着一条生产线。

真正会玩 RTS 的人，要同时看资源、基地、兵线、侦察、前线和防守。他不会把注意力全部放在某一个小兵怎么走位上。

放到 AI 编程里，意思也很清楚。

你不再只开一个 Agent，让它慢慢想、慢慢改、慢慢跑。

你会同时拉起多个工作区，分给多个 Agent，让它们从不同方向去试。

一个去复现问题。

一个去读测试。

一个去查历史提交。

一个去做最小修改。

一个尝试更大的重构，但先放在隔离环境里。

人类做什么？

人类不再盯每一行代码。

人类看方向，看风险，看哪些路线值得继续，哪些路线应该停掉。某个 Agent 做出了一个看起来能跑但侵入性太强的方案，人要叫停。另一个 Agent 找到了一个很小的修复点，人要判断它是不是足够稳。

这就是 RTS 方法里最打动我的地方。

它不是一个炫技概念。它说的是人的位置变化。

在 Prompt 阶段，人是提示词作者。

在 Skill 阶段，人是能力封装者。

在 Loop 阶段，人是循环设计者。

到了 RTS，人变成了调度者。

你问的问题变了。以前是“我怎么把这段代码写对”，现在是“我怎么让多条尝试同时发生，并且在合适的时候介入”。

这个转变很大。

因为它承认了一件事：人的注意力比 token 贵。

只要试错成本足够低，很多时候就没必要让一个人坐在那里苦想最优路径。你可以让系统多试几条路，再让人判断哪条路更可信。

五、但 RTS 也会很快撞到墙

RTS 听起来很兴奋，但它也不是终点。

你同时开三个 Agent，可能还能盯得住。

开五个，已经有点吃力。

开十个、二十个呢？

很快，问题就从“能不能并行”变成“并行以后谁来管理”。

这才是关键。

如果每个 Agent 都在改代码，每个 Agent 都生成 diff，每个 Agent 都有自己的解释和失败记录，人类很快会被新的工作量淹没。

你原来是被写代码淹没。

现在可能被 review 淹没，被合并淹没，被判断这些候选方案淹没。

更麻烦的是，多 Agent 并不天然更聪明。

如果任务边界不清楚，它们会互相踩文件。

如果共享状态不清楚，它们会基于过期信息做判断。

如果没有验证机制，它们会一起产出一堆看起来很努力、实际没法合并的东西。

所以 RTS 真正往前走，一定不能只停留在“开更多 Agent”。

它需要一套管理层。

谁来分配任务？

谁来决定每个 Agent 读什么上下文？

谁来隔离工作区？

谁来跑测试？

谁来比较多个候选方案？

谁来记录失败路径？

谁来生成 PR 证据包？

谁来决定什么时候必须叫人？

这些问题一出现，下一步就很清楚了：Agent Control Plane。

六、Agent Control Plane 是什么

我理解的 Agent Control Plane，不是一个更大的聊天窗口，也不是一个更花哨的 IDE。

它更像一个任务控制系统。

它知道现在有哪些任务在跑，哪些 Agent 在工作，分别用了什么模型，在哪个 worktree 里改了什么文件，跑过哪些测试，失败过哪些路线，当前风险在哪里。

开发者不再一个个窗口盯过去，而是在一个控制平面上看整体状态。

它至少要管几类东西。

第一，任务队列。

哪些任务可以并行，哪些任务必须串行，哪些任务风险高，哪些任务只是小改。

第二，Agent 池。

不同 Agent 可以有不同角色。有的负责复现，有的负责修复，有的负责写测试，有的负责审查，有的负责总结失败经验。

第三，上下文装载。

上下文不是越多越好。要给 Agent 足够的信息。少了会误判，多了会迷路。

第四，工作区隔离。

每个 Agent 在独立 worktree 或 sandbox 里尝试，避免互相污染。

第五，验证流程。

测试、lint、类型检查、安全扫描、回归测试，应该成为系统默认动作。不能只靠 Agent 自己说“我觉得好了”。

第六，候选方案比较。

多个 Agent 产出多个方案以后，系统要能比较它们：改动范围、测试结果、复杂度、风险、可回滚性。

第七，证据包。

人类 review 的时候，不应该只看一坨 diff。最好能看到：它为什么这么改，试过哪些路，哪些测试过了，哪些风险还在，回滚方式是什么。

第八，经验沉淀。

某条路线失败了，不应该只留在这次会话里。这个失败应该进入项目记忆，变成下次 Agent 不再重复犯错的上下文。

这就是 Agent Control Plane 和普通 coding agent 的区别。

普通 coding agent 是帮你做一个任务。

Agent Control Plane 是帮你管理一群做任务的 agent。

七、未来的开发者会更像系统设计者

如果这条线继续走，开发者的角色会继续上移。

这句话以前大家也说过很多次，但这次我觉得它变得更具体了。

以前说“开发者会变成产品经理”太泛。

现在看，开发者更像是在设计一个软件生产系统。

你要会写需求，但不只是写需求。

你要会定义验收标准。

你要会判断哪些任务适合并行。

你要会设计测试和验证。

你要知道哪些权限能放开，哪些操作必须卡住。

你要知道什么时候应该让 Agent 多试，什么时候必须人来做架构判断。

你还要知道哪些经验应该沉淀成 Skill，哪些规则应该写进项目 policy，哪些失败应该成为测试。

更重要的问题是：

我能不能设计一套让 AI 稳定产出、可验证、可回滚、可复用的系统？

这件事听起来更抽象，但其实更接近工程本身。

工程从来不是只把代码写出来。工程还包括边界、流程、验证、协作、风险和维护。

AI 只是把这个问题推到了台前。

八、这条线里真正不变的东西

回到最开始那个困惑。

为什么刚理解 Loop，又来了 RTS？

为什么这些词一层层冒出来？

我现在的理解是：它们没有在描述一堆互相独立的新潮玩法。它们一直围绕同一个瓶颈往前推进。

这个瓶颈就是人类注意力。

Prompt 想减少人的表达成本。

Skill 想减少人的重复成本。

Loop 想减少人的纠错成本。

RTS 想减少人的等待成本。

Agent Control Plane 想减少人的调度成本和判断负担。

每往前一步，人都从更底层的细节里退出来一点。

但这不代表人不重要。

恰恰相反，人的判断会变得更集中。

以前你的一小时，可能花在写代码、改报错、整理上下文上。

以后你的一小时，可能花在判断任务边界、验证标准、风险等级和系统规则上。

从某种意义上说，人不是被 AI 替掉了。

人是被迫站到了更高的位置。

站上去以后，问题也更难了。

因为你不能只会操作一个工具，你要理解一套系统怎么运转。

九、我会怎么判断一个 AI 编程工具有没有走到下一步

以后再看 AI 编程工具，我大概不会只问“它用了哪个模型”。

模型当然重要，但只问模型，太像只看发动机，不看整辆车。

我会问这些问题：

它能不能同时跑多条候选路线？

它能不能自动隔离每条路线？

它能不能自动生成和执行验证？

它能不能比较多个结果？

它能不能告诉我每个方案为什么留下、为什么放弃？

它能不能把失败经验沉淀下来？

它能不能控制权限和预算？

它能不能在真正需要人判断的时候，再把人叫进来？

如果这些问题都答不上来，那它可能还是一个更会写代码的助手。

如果这些问题慢慢能答上来，它就开始靠近 Agent Control Plane。

十、别把每个新词都理解成一个时代。

很多文章就是把每个新词都写成一个时代。

这样写看起来很清楚，其实很容易把人带乱。

真正值得写的，是一个普通开发者、产品人、创业者看到这些变化时的那种追问：

为什么会从 Prompt 走到 Skill？

为什么 Skill 之后还需要 Loop？

为什么 Loop 不够，又会出现 RTS？

为什么 RTS 继续往前，会需要一个控制平面？

沿着这条线看，很多东西就没那么玄了。

它一直在处理同一个问题：把便宜的计算组织起来，减少昂贵的人类时间消耗。

但减少人类时间，不等于减少人类判断。

恰恰是判断变得更贵了。

所以我会把这条演化线写成：

Prompt：人教 AI 做一次。

Skill：人把经验封装起来。

Loop：人让 AI 自己纠错推进。

RTS：人同时调度多条尝试。

Agent Control Plane：人设计一套系统，让调度、验证、记忆和风险控制自动运转。

这条线的终点暂时还看不清。

但方向已经很明显。

AI 编程不会只停留在“帮我写代码”。它会越来越像一套软件生产系统。

而开发者要学的，也不只是怎么和模型聊天。

更重要的是，怎么设计这套系统。