AI编程的三阶段演化：哪些方向真正值得投入，哪些被高估了

最近读到一篇万字长文《OpenClaw和Claude Code只是第一阶段》，把AI编程的演化拆成了三个阶段：智能开发工作台→流程化Agent工坊→AI软件工厂。框架很有洞察力，但有些地方我觉得过于乐观了。

我把原文的观点、GitHub上正在发生的事、以及自己的判断整理了一下，聊聊AI编程到底走到了哪一步，哪些方向真的值得关注，哪些可能被高估了。

先说结论

AI编程正在从"让模型帮我写代码"走向"让Agent系统组织软件生产"------这个大方向没错。但：

第二阶段（流程化Agent工坊）远没有走到尽头，正在快速演化中
第三阶段（AI软件工厂）的终点图景清晰，但实现路径模糊，存在几个根本性的未解决问题
真正值得投入的是那些解决真实痛点的轻量方案，而不是宏大的"软件工厂"构想

一、AI编程走到哪了？

第一阶段：一个人加一个Agent

Claude Code、Cursor、Copilot------过去两年的主力军。一个人+一个强Agent+项目上下文，本质是给开发者配了一副AI外骨骼。

这个阶段的天花板很明显：上下文腐烂。项目一大，聊天历史不断膨胀，模型开始遗忘早期决策、偷工减料、产生幻觉。任何用过Claude Code做稍复杂项目的人都经历过。

第二阶段：用流程来驾驶Agent

GSD（59.1k Stars）、OpenSpec、Matt Pocock的skills和sandcastle------这些项目在过去几个月快速走红，原因很简单：开发者已经在用实践投票，表明"一个人加一个Agent"的模式不够了。

核心转变：从"人类手动驾驶Agent"到"用流程和规格来驾驶Agent"。

GSD通过一组结构化文件（PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md......）把项目状态从聊天历史中抽离出来
OpenSpec在每次代码变更前插入轻量级规格契约层
Matt Skills把资深工程师的工作习惯沉淀成可调用的Agent能力
Sandcastle让Agent在隔离环境中工作，防止互相污染

第三阶段：AI软件工厂

多个Agent组成一家能持续交付的软件公司------认知图谱、Worker/Checker结对、契约系统、Trace Graph、Human-as-a-Skill。

听起来很美。但问题是：谁来触发从第二阶段到第三阶段的跳跃？核心组件在当前技术中找不到对应物。

二、第二阶段正在发生的事

第二阶段已经形成了丰富的工具生态，而且正在沿几个明确的方向快速演化。

多Agent编排的三层架构

层级	模式	代表工具	场景
Tier 1	进程内Agent	Claude Code Agent Teams、OMC	交互式结对编程
Tier 2	本地编排器	Claude Squad、Conductor、OpenCode+OmO	3-10个Agent并行
Tier 3	云端异步	Claude Code Web、Copilot Coding Agent	关电脑回来收PR

最聪明的开发者根据任务大小在不同层级之间切换，而不是只用一种。

四个已验证的关键模式

1. Ralph Loop------最简单也最有效的模式

核心思想：每次只做一个小任务，做完就清空上下文重来。用Git代替上下文窗口作为记忆层。

为什么有效？因为小的、有边界的任务比一个巨大的prompt产生更好的代码。每次迭代都是干净状态，没有累积性幻觉。已被Anthropic采纳为官方插件。

2. Architect-Executor-Reviewer三角色循环

几乎所有编排工具都在趋同采用这个模式。Architect分析需求制定计划，Executor写代码，Reviewer检查输出。问题严重就回到Architect重新规划。

3. 多模型路由------省钱又不牺牲质量

不是所有任务都需要最强模型：

编排/协调 → Claude（强指令遵循）
深度推理 → GPT
日常探索 → 本地Qwen（Ollama，零成本）
重复性任务 → 最便宜的模型

成本可降低30-50%，同时保持关键路径的质量。

4. Worktree隔离+跨工具知识持久化

Git worktree已成为并行Agent开发的标准基础设施。Forge Orchestrator让Claude Code积累的知识对Codex CLI可用------一周后，系统比你更了解你自己的代码规范。

三、GSD和OpenSpec：两种规格驱动的哲学

GSD：给Agent一套阶段化施工流程

GSD（Get Shit Done）是GitHub上目前最火的AI编程框架，59.1k Stars，被Amazon、Google、Shopify的工程师使用。

它的工作流程是一个四步循环：Discuss → Plan → Execute → Verify

最有意思的是它的Wave并行执行。Agent不串行地一个接一个做任务，而是把任务按依赖关系分成Wave------无依赖的并行执行，有依赖的等前序完成：

复制代码

Wave 1（并行）     Wave 2（并行）     Wave 3
用户模块 | 商品模块 → 订单API | 购物车 → 结账UI

每个Wave在全新的200K上下文中执行，主会话上下文始终保持在30-40%。每个任务完成后立即原子commit。你走开，回来看到干净的git历史和完成的工作。

还有一个贴心的设计------模型分级：

配置	规划	执行	验证
quality	Opus	Opus	Sonnet
balanced	Opus	Sonnet	Sonnet
budget	Sonnet	Sonnet	Haiku

关键决策用强模型，日常执行用便宜模型。不想动脑就选balanced，想省钱就选budget。

OpenSpec：流动的规格契约

OpenSpec的设计哲学与GSD相反：

复制代码

→ fluid not rigid（流动而非僵化）
→ iterative not waterfall（迭代而非瀑布）
→ built for brownfield（支持已有项目，不只新项目）

它的核心粒度不是"项目"，而是"变更"。每次你想改一个功能：

复制代码

/opsx:propose "加暗黑模式"
→ 自动生成 proposal.md、specs/、design.md、tasks.md
→ /opsx:apply 逐步实现
→ /opsx:archive 归档

怎么选？

从零开始的新项目 → GSD，它的milestone→phase→plan体系为整个生命周期提供了完整框架
已有代码库的增量开发 → OpenSpec，每个功能变更独立走规格流程，不要求整个项目重构
共同价值：把"人脑中的隐式想法"变成"可审计的显式规格"

四、第三阶段：图景清晰，但路径模糊

文章描绘的AI软件工厂------认知图谱、Worker/Checker结对、三平面闭环、Trace Graph、Human-as-a-Skill------作为概念框架是自洽的。读完后能形成一个完整的心理模型。

但"图景清晰"不等于"路径清晰"。

跳跃点没有定义

从"人类写ROADMAP.md"到"系统自动生成认知时空图谱"之间，没有一个可操作的中间状态。是渐进的？还是需要新的技术组件？文章没有回答。

核心组件在现实中不存在

构件	文章描述	现实状况
认知时空图谱	动态演化的生产依赖图	只有简单的任务依赖树
Trace Graph	需求→架构→代码→测试的因果链	只有Git blame和CI日志
契约平面	多Agent共享的Contract Registry	是静态Markdown文件
自动归因	测试失败自动定位到架构或需求层	模型因果推理能力远不够

这些不是工程问题（搭好框架就行），而是能力问题------当前LLM不具备可靠的长期规划、因果推理和自我评估能力。

验证问题是最大的未解难题

文章把"验证"嵌入到Worker/Checker对中，但回避了一个根本问题：Checker本身怎么保证正确性？

如果Checker和Worker都基于同一种LLM，它们会犯同类错误（系统性盲区）。在制造业中质检有卡尺和光谱仪，在软件中自动化测试能覆盖一部分，但正确性验证和业务意图验证是两回事------测试能证明代码做了什么，但无法证明代码做了你真正想要的事。

三个根本性问题

1. 规格化的成本悖论

好的规格本身就是创造性工作。大量需求在写代码的过程中才会变清晰。过早的形式化会锁死错误的理解。第二阶段的轻量方案（几个Markdown文件）之所以有效，恰恰因为它们是不完整的------留了人类判断的空间。

2. 人类角色的"调参难题"

Human-as-a-Skill要求系统知道自己什么时候需要人类（metacognition）。当前LLM倾向于过度自信------它经常"不知道自己不知道"。该叫人时没叫，可能导致错误方向上的大规模返工；不该叫时频繁叫，人类成为瓶颈。

3. 演化与稳定性的矛盾

"可演化、可重构、可回滚"听起来很美。但演化的标准是什么？一次架构级重构可能导致所有下游认知单元失效，级联更新的复杂度可能超过人类手动处理。软件架构的演化至今是人类架构师的核心能力，因为它需要判断力而不是规则执行。

我的判断

第三阶段目前不是工程路线图，而是研究方向声明。它正确地指出了AI编程的终极形态，但实现路径需要多次范式转换。真正值得关注的是第二阶段内部正在发生的演化------它们才是驱动变化的真实力量。

五、第二阶段哪些方向真正值得投入

最值得做的两件事

P0：上下文工程

所有其他方向的基础。GSD通过结构化文件把项目状态外部化，Ralph Loop用Git做记忆层------本质上都在做同一件事：给Agent正确的上下文。

未来会出现某种"上下文分析器"，告诉你当前会话的利用率、哪些信息可以被外部化。跨工具知识持久化（Claude Code积累的知识对Codex CLI可用）在多工具混用的现实中价值很大。

P0：Ralph Loop

验证最充分、实现成本最低、效果最直接的模式。一个bash脚本就能跑。未来会与Wave并行执行结合，结合多模型路由。

值得关注的两个方向

P1：规格驱动开发（SDD）

社区有一句话总结得很精准："LLM写代码本身正在变成水电煤，差异化的关键在于谁来管理Agent的工作。"SDD就是那个管理层。

P1：质量门禁制度化

验证是多Agent系统最大的瓶颈。最有价值的演化是"跨Agent审查"------用Codex审查Claude写的代码。不同模型的系统性盲区不同，交叉审查能发现单一模型遗漏的问题。

长期杠杆

P2：多模型路由

oh-my-openagent的创建者在个人项目上花了$24K的LLM token费。不做路由优化，多Agent系统的成本会爆炸。

两个被高估的方向

被高估一：12+Agent模拟敏捷团队

BMAD Method编排了PM、Architect、Scrum Master、Developer、QA等12+个角色。但角色之间的沟通成本高，而且Agent不是人------一个Agent扮演"安全专家"和扮演"前端工程师"用的是同一个底层模型，角色分化只是prompt层面的。

更务实的做法是GSD的模式：不模拟角色，而是模拟工作流阶段。

被高估二：全自动"睡觉起来收PR"

目前只有规格非常清晰、边界非常明确的任务适合。如果规格有歧义，Agent会在错误方向上高速产出大量代码。更务实的做法是"半自动+人机交替"。

六、对开发者的建议

如果你还没开始用第二阶段的工具，建议按这个顺序：

第一周：在Claude Code中启用Agent Teams，写一个AGENTS.md描述你的项目规范。试一个简单的并行任务。

第二周：安装GSD，在一个真实功能上跑一遍discuss→plan→execute→verify。对比手动开发的输出质量和token成本。

第三周：试Ralph Loop。把一个功能拆成8-10个原子任务，让Agent循环跑一夜。早上review commits。

第四周：配置多模型路由。日常任务用本地模型（零成本），关键决策用云端模型。

核心原则：用轻量方案解决真实痛点，不要追求宏大叙事。

写在最后

AI编程正在经历一个重要的拐点。代码生成本身正在商品化------Claude、GPT、Gemini、DeepSeek、Kimi都能写代码，差异越来越小。

真正的竞争正在转移到上一层：谁来组织Agent的工作？谁能管理上下文、定义规格、保证质量、控制成本？

这个问题的答案不在某个万能的大模型里，而在那些解决真实痛点的轻量工具和实践中。

GSD用几个Markdown文件就解决了上下文腐烂。Ralph Loop用bash脚本就实现了高质量的无状态迭代。这些看起来不起眼的方案，才是真正驱动变化的底层力量。

第三阶段的AI软件工厂终会到来，但不是今天。今天该做的，是把第二阶段的基本功练好。

本文基于《OpenClaw和Claude Code只是第一阶段》（傲寒荐书，2026年4月29日）的延伸讨论，结合GSD（59.1k Stars）、OpenSpec等GitHub热门项目及2026年AI编程工具生态最新实践整理而成。