我最近越来越明确一个判断：

AI开发的效率提升，不是线性的，而是阶梯式的。

在AI开发初期，真正有意义的升级大概有三次。每一次跨过去并逐渐跑顺，体感上都可能接近一次10倍效率提升。

这里的“10倍”不是精确Benchmark，而是工程现场里的数量级变化：任务能变长，返工变少，人不再被AI的虚假进展牵着走，项目开始从不可控变得可控。

这三次升级分别是：

第一次，用好Plan Mode，进入Spec + Plan。

第二次，测试驱动，或者说Eval优先。

第三次，多Session并行治理，也就是orchestration。

它们的难度不断提升。根据我身边的样本观察，大部分人很长时间，甚至几个月，都无法真正跨过第一阶段。

第一次升级：从零碎对话到Spec + Plan

第一道门槛，是从零碎对话进入Spec + Plan。

很多人用AI开发，一直停留在这种状态：这里改一下，那里修一下，报错了再问，结果不对再补一句。

这种方式处理小任务很快。但任务一长，AI就会开始跑偏：忘记前面的约束，把临时方案当成最终方案，在长对话里不断补丁摞补丁。

更麻烦的是，它会制造一种“好像一直在推进”的感觉。

这就是AI开发里最常见的虚假进展感。

Plan Mode真正的价值，是把AI从即时对话拉回到结构化执行。

有效的Spec，要说明需求、边界、非目标、验收方式和风险点。

有效的Plan，要把任务拆成可以执行、可以检查、可以回退的步骤。

这一关的难点，不是会不会写文档，而是你能不能和AI有效沟通：让长对话收敛，判断文档有没有真实信息量，识别AI是在解决问题，还是只是把混乱写得更漂亮。

很多人跨不过第一阶段，不是因为不会点Plan Mode，而是无法判断Plan是否有效。

一份很长的文档，不等于AI理解了任务。

有效的Plan，应该让问题变小，边界变清楚，执行路径变确定。否则它只是把混乱换成了文档格式。

多数热门技术，主要还在第一道门槛之前工作

AI圈经常讨论很多技术和技巧，比如Prompt Engineering、Prompt模板、System Prompt、角色设定、简单的Agent角色卡、代码补全、IDE里的局部上下文提示、面向单次任务的Skill，等等。

这些东西当然有价值。

但它们主要在进入第一道门槛前工作，优化的是AI的单次回答质量、局部生成效率和短任务体验。

它们能让AI更听话，回复更稳定，局部代码写得更快，也能减少重复沟通成本。

但它们通常不解决第一道门槛本身。

第一道门槛要解决的是：AI能不能从零碎对话进入长任务执行。

这要求任务被正确定义，Spec有真实信息量，Plan能持续收敛，执行路径越来越清楚，而不是在长对话里不断堆补丁。

如果这些问题没有解决，再好的Prompt模板，再多的Skill，也只是让AI更高效地完成短任务，或者更流畅地制造“看起来像进展”的内容。

所以很多人追了很多AI工具和技巧，但真实开发能力没有发生数量级提升。

他们提升的是门槛前的局部效率，而不是跨过门槛后的长任务执行能力。

真正跨过第一道门槛后，你不会再只关心“怎么让AI这一次答得更好”，而会开始关心：任务定义是否清楚，Spec能否支撑长任务，Plan有没有把问题拆小，长对话是在收敛还是发散，AI给出的文档有没有真实信息量。

这些问题变成主要关注点，就说明你开始从“使用AI”，进入“管理AI执行任务”。

这时，第一次效率升级的条件才开始出现。

第二次升级：从写完再看到Eval优先

跨过第一道门槛后，AI已经能执行更长的任务。

但很快会遇到第二个瓶颈：你怎么知道它真的完成了？

这就是测试驱动，或者更现代一点说，叫Eval优先。

AI开发里，结果验收和评估会变成真正的瓶颈。

因为AI交付天然不稳定。它可能局部写对、整体写错；可能修复一个问题，同时引入三个新问题；也可能非常自信地告诉你“已经完成”，但关键路径根本没跑通。

第二次效率升级的起点，是工作顺序的改变。

不要先让AI写一大堆代码，再靠人工肉眼检查。

而是先设计验收标准：怎样算通过，哪些场景必须覆盖，哪些边界不能破，哪些结果可以自动测试，哪些只能人工验收。

人的工作重点，要从“检查AI写了什么”，转向“定义什么叫写对了”。

这一步跨过去后，AI才开始进入可迭代的闭环。

测试失败，AI继续修。

测试通过，人再看关键部分。

当这套闭环逐渐跑顺后，效率空间会明显打开，因为人不再把大量注意力浪费在低价值的反复检查上。

但这一关的难点，是理解测试的工作边界。

不是所有地方都要追求100%测试覆盖。

有些适合单元测试，有些适合集成测试，有些只需要关键路径验收，有些视觉、体验、产品判断只能靠人工或半自动Eval。

真正重要的不是迷信测试，而是知道什么情况该追求什么程度的测试覆盖。

如果不理解这一点，测试驱动也会变成形式主义：写了很多测试，但没有覆盖真正的风险。

现在AI圈常说的harness，大体也是这个阶段的思想：不能只把需求丢给AI，然后等它说“完成了”，而是要在AI外面包一层可执行、可反馈、可验证的工程外壳。

但harness这个词本身，并不负责解释如何实现有效验收。

真正难的仍然是：什么叫完成，什么值得测试，测试边界在哪里，哪些交给自动化，哪些必须人工判断。

Anthropic和OpenAI的公开路线，也指向同一件事

这套分阶段升级，并不是我一家之言。

比如Anthropic公开发表的工程内容，会发现它们其实也在指向同一条路线。

Claude Code的最佳实践里，核心建议不是“多用某个神奇功能”，而是先探索、再规划、再编码。也就是先让AI理解问题和上下文，再进入执行。

这对应第一道门槛：Spec + Plan。

同样，Anthropic反复强调要给Claude一个可以验证自己工作的方式。测试、构建结果、截图对比、输出差异、lint、脚本检查，都可以成为AI能读懂的反馈信号。

这对应第二道门槛：Eval优先。

再往后，Anthropic讨论的Parallelization、Worktree、多Session，本质上都在讨论同一件事：当单个上下文、单个执行链不够时，如何把任务拆开，让多个执行单元并行工作，再把结果汇总回来。

这对应第三道门槛：多Session并行治理。

所以我这里说的三次升级，不是为了发明一套新名词。

更准确地说，这是把行业里正在浮现的工程路线，放回真实开发过程里重新描述：

先让任务可定义。

再让结果可验证。

最后让多个任务可并行治理。

第三次升级：从单Session执行到多Session并行治理

第二次升级解决的是单个任务的可信交付。

但真实项目继续变复杂后，新的瓶颈会出现：一个Session已经不够用了。

这里的重点，不只是上下文太长会污染AI注意力。

更重要的是，单Session天然无法充分利用AI的并行能力。

如果所有任务都塞在一个对话里顺序推进，AI再快，也只是一个更快的单线程执行器。项目效率仍然被单条任务链限制住。

第三次效率升级的核心，是脱离单Session思维，逐步学会把项目拆成多个可以并行推进的任务单元。

这时候真正重要的问题变成：任务间并行串行怎么安排，如何处理依赖关系，边界怎么切，哪些上下文需要共享，哪些任务必须等前置结论出来再启动。

这就是完整的Session治理。

它不是简单地多开几个窗口让AI同时干活。

如果任务拆分不合理，并行只会制造更多混乱：多个Session改同一块代码，方案互相冲突，结果难以合并，问题回流后没人能判断责任边界。

所以第三阶段的关键，不是“更多Session”，而是“合理并行”。

每个任务都应该进入标准流程：Spec明确目标和边界，Plan拆出步骤、依赖和风险点，Worktree隔离修改，PR承载结果、证据和审查，测试和验收决定是否合并。

这一步的本质变化，是从“我和AI完成一个任务”，变成“我在管理一组可并行的AI执行单元”。

人的工作会变成：任务怎么拆，并行串行怎么排，边界怎么切，不同Session结果怎么汇总，冲突怎么解决，证据怎么保留，合并顺序怎么安排。

上下文污染仍然是问题，但它只是多Session治理里的局部问题。

更大的问题是：你能不能把复杂项目拆成一组边界清晰、依赖明确、可以并行推进、最终能够合并回主线的任务。

到了这个阶段，新的效率空间不只来自AI写代码更快，而来自项目执行方式改变。

过去，一个人一次只能推进一条任务链。

现在，一个人可以同时管理多条AI执行链。

只有任务边界合理、验收标准清楚、合并机制可靠，AI的效率才有机会被真正放大。

这时，第三次效率升级的空间才真正被打开。

知道这些阶段，也不等于能跨过去

即使你知道并相信这个分阶段升级过程，升级仍然非常难。

因为每一次升级，都不是多学一个工具，而是适应一种全新的工程复杂度和信息吞吐量。

第一阶段，你要从“和AI聊天”，转向“定义任务、收敛问题、判断文档质量”。

这要求你能把模糊需求变成有效Spec，能看出Plan是真收敛还是假完整，能识别AI制造的虚假进展感。

第二阶段，你要从“看AI写了什么”，转向“先定义什么叫写对”。

这要求你习惯先设计测试和验收标准，理解测试覆盖的边界，知道哪些风险值得自动化，哪些只能人工判断。

第三阶段，你要从“管理一个Session”，转向“治理多个并行任务单元”。

这要求你适应更高的信息吞吐量：多个Spec、多个Plan、多个Worktree、多个PR、多个测试结果、多个阻塞点、多个依赖关系。

难点不只是防止上下文污染，而是判断任务拆分是否合理，并行关系是否可控，边界切错后会不会导致后续合并灾难。

很多人不是不会多开Session，而是一多开就失控。

并行本身不会自动带来效率。

只有被治理的并行，才会带来效率。

所以，AI开发的升级不是“知道正确答案”这么简单。

它更像是人的工作方式，被AI推着进入更高复杂度。

每跨过一层，AI能承担的任务变大，但人需要处理的治理复杂度也会同步上升。

这也是为什么三次升级难度不断提高。

它们不是工具熟练度升级，而是工程复杂度适应能力升级。

真的有1000倍效率吗？

看到三次10倍，有人可能会问：这是不是意味着AI开发真的有1000倍效率？

10倍、1000倍都是虚数，无法精确度量，但量级是真的。

关键在于，这里的效率不是简单任务的速度叠加。

复杂任务不是简单任务重复1000次。

如果方法没有升级，效率会在接近某个复杂度门槛时迅速下降，甚至逼近停滞。

常见状态是：AI一直在工作，人一直在沟通，代码一直在变化，文档一直在增加，但项目没有真正向前推进。

这不是速度不够，而是旧方法已经失效。

所以，每一次10倍效率升级，首先打开的是一个新的效率空间。

第一阶段跨过去后，打开的是长任务执行空间。

第二阶段跨过去后，打开的是可验证交付空间。

第三阶段跨过去后，打开的是并行治理空间。

但打开效率空间，不等于立刻达到这个空间里的最大效率。

你知道一种新工作方式，开始使用新的流程，通常只是获得了继续推进的可能。

要接近这一层工作方式下的效率上限，仍然需要大量磨合：Spec质量、Eval边界、任务拆分、依赖判断、合并机制、证据管理，以及人的信息吞吐量，都要逐步适应。

每一层跑顺之后，你又会很快遇到更高复杂度的问题。

用原来的方法继续硬推，效率会重新下降，甚至再次卡死。

这时候，更换工作方式不是魔法，而是让你从停滞区进入新的可优化区。

所以，AI开发里的效率提升，更像是复杂度阶梯上的跃迁，而不是线性加速。

10倍不是精确数字，1000倍也不是精确数字。

但从工程现场看，量级变化是真实存在的。

因为你能推进的任务类型变了，能承载的项目复杂度变了，能让AI稳定工作的范围变了。

这才是“效率提升”最重要的含义。

三次升级，本质是复杂度上限的提升

这三次升级，表面上看是工具和流程：Plan Mode、Spec、测试、Eval、Worktree、PR、Session治理。

但背后真正改变的，是人和AI协作时可承载的复杂度上限。

第一次升级，让AI能执行长任务。

第二次升级，让AI交付可以被验证。

第三次升级，让多个任务可以被并行治理。

所以这不是简单的“写代码速度更快”。

而是任务规模提升了，交付稳定性提升了，并行能力释放了，人的注意力也从反复救火转向更高层的工程治理。

过了第一道坎后，很多人看到的东西会逐渐趋同。

因为真实项目会不断把问题压到同几个瓶颈上：任务定义、结果验收、任务拆分、并行治理、证据合并。

这些问题绕不过去。

工具可以变化，模型可以升级，接口可以越来越漂亮，但复杂项目里真正决定效率上限的，仍然是这些结构性问题。

大部分人卡在哪里？

根据我身边的样本观察，大部分人很长时间都跨不过第一阶段。

有些人用了几个月AI开发，仍然停留在对话式使用：想到哪里说哪里，AI回什么就接什么，出问题再让AI修，修完再出新问题。

这时候他们会觉得AI很强，但也很不靠谱。

这个判断并不矛盾。

AI在局部任务上确实很强，但他们还没有建立让AI稳定交付长任务的工作流。

第一阶段最难的地方，在于它不是一个工具按钮，而是一种沟通能力和判断能力。

你要能把模糊需求变成有效Spec，让长对话不断收敛，识别AI生成内容里的真实信息量，看出“看起来有进展”和“真的推进了问题”之间的差别。

这对很多人来说，比写代码本身更难。

因为它要求的不是语法能力，而是复杂问题表达能力、结构化判断能力和工程直觉。

结语：AI开发的门槛正在转移

AI让写代码变容易了。

但它没有让复杂项目自动变简单。

恰恰相反，AI把一部分原来属于执行层的难度压低了，同时把真正的瓶颈推到了更高层。

过去，很多人的开发能力差距体现在代码熟练度上。

现在，差距会越来越体现在：能不能定义任务，能不能设计验收，能不能拆分边界，能不能治理并行，能不能管理多个AI执行单元。

AI开发的早期红利，不是人人都能自动获得的。

真正的红利，属于那些能持续完成并磨合工作流升级的人。

从零碎对话，到Spec + Plan。

从写完再看，到Eval优先。

从单Session硬扛，到多Session并行治理。

这三步逐渐跨过去并跑顺，AI才不只是一个会写代码的助手，而会逐渐变成复杂项目里可被管理、可被验证、可被放大的生产力。