最近 GitHub 上快速受到关注的两个项目很值得注意：一个是GSD，另一个是Matt Pocock 的 skills 与 sandcastle。它们看起来并不是传统意义上的“大平台”，也不是又一个代码编辑器或 IDE，但它们揭示了一个趋势：AI 编程正在从“让模型帮我写代码”，走向“让 Agent 系统组织软件生产”。

如果说 Claude Code、OpenClaw、Cursor、Codex 这一类工具代表了 AI 编程的第一阶段，那么 GSD 和 Matt Pocock 的这些项目，已经明显进入了第二阶段。而真正值得讨论的是第三阶段：一种以 AI 为主体、由认知图谱、契约系统、运行环境、质量反馈和人类专家调用共同组成的全智能软件工厂。

本文想与大家一起梳理这条演化路径：从智能开发工作台，到流程化 Agent 工坊，再到真正的软件工厂，并尝试描绘一个真正的“AI软件工厂”有可能如何构成。

一、GSD 和 Matt Pocock 为什么值得关注？

GSD 的全名是Get-Shit-Donw，名字很粗粝，它要解决的问题是：当我们用 Claude Code 或类似 AI 编程工具开发一个稍微复杂的项目时，聊天上下文很快会膨胀，模型开始忘记早期决策，任务边界变模糊，代码质量下降，开发逐渐进入所谓的上下文腐烂。

GSD 的思路不是再造一个模型，而是在 Claude Code、Codex、Gemini CLI、Cursor 等工具之上，加一层轻量级的流程和上下文工程。它会引导项目从想法开始，经过需求讨论、阶段规划、原子任务拆分、分 wave 执行、验证、debug、交付。它会维护一组类似PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、PLAN.md、SUMMARY.md、UAT.md的文件，把一次长长的对话，变成一个可持续推进的项目状态系统。

GSD 的核心价值在于正把 AI 编程从“聊天驱动”推进到“规格与流程驱动”。另外还值得一提的是同期受到关注的OpenSpec。它聚焦于更小的功能变更颗粒度：每一次功能变更。与GSD不同OpenSpec 的哲学是fluid not rigid，它不制造阶段门，而是在每一次代码变更前插入一个轻量级的规格契约层，提供变更级的对齐协议。两者共同指向同一个方向：Agent 写代码之前，必须先有规格；规格，是人机协作的共同语言。

Matt Pocock 的项目则是另一个方向。mattpocock/skills提供了一组面向真实工程实践的 AI 技能，比如追问需求的/grill-me，把讨论整理成 PRD 的/to-prd，拆 issue 的/to-issues，测试驱动开发的/tdd，问题诊断的/diagnose，架构审查的/improve-codebase-architecture等。

这些 skills 的价值不在于炫技，而在于它们把资深工程师的工作习惯沉淀成了可调用的 Agent 能力。它强调的不是“vibe coding”，而是让 Agent 按照真实工程师会采用的方法来工作：先澄清需求，再写文档，再拆任务，再测试，再诊断，再重构。

Matt Pocock 的另一个项目sandcastle则更进一步：它关注 AI coding agent 的沙箱化运行。Agent 不应该直接在主工作区里任意修改代码，而应该在隔离的 Docker、Podman、Vercel sandbox、分支或 worktree 中运行。它提供了运行 Agent、观察结果、记录 commit、管理分支、并行执行与 review 的基础设施。

这两个项目之所以迅速流行，不是因为它们创造了什么全新的 AI 能力，而是因为它们回应了一线开发者在实际使用 AI 编程工具时遇到的真实痛点：上下文会腐烂，流程需要管理，工程纪律不能丢，多个 Agent 需要隔离。这些痛点的集中爆发，标志着 AI 编程正在跨越一个重要的分水岭——从“一个 Agent 帮你写代码“，走向“一套系统帮你组织软件生产“。

这就是下一阶段的开始。

二、第一阶段：智能开发工作台

回顾起点。Claude Code、Cursor、GitHub Copilot、Codex CLI——这些是过去两年 AI 编程的主力军。它们的共同模式是：

一个人 + 一个强 Agent + 工具调用 + 项目上下文。

这一阶段的典型能力包括：

• 读取项目文件；

• 理解代码结构；

• 修改代码；

• 调用 shell、git、测试命令；

• 根据错误日志修复问题；

• 在 IDE 或终端中与开发者协同。

Claude Code 在这一阶段尤其典型，它已经做到了相当高的成熟度：能直接读取和修改代码文件，能运行终端命令和测试，能通过CLAUDE.md加载项目规则，能用子 Agent 分治子任务，能压缩长会话的上下文，有权限控制和安全沙箱。它本质上是一个装备精良的超级程序员工作台。

OpenClaw 这类开放式工具，则更多体现了可扩展性和多 Agent 组织的可能性。它们让人看到：AI 编程工具不一定只能是封闭产品，也可以成为一种可组合的 Agent Harness。

这个阶段的特征很清晰：

• 人类是主体，Agent 是增强工具。

• 上下文窗口是全部工作空间，对话历史就是项目记忆。

• 没有显式流程，工作推进依赖人类的判断和指令。

• 没有结构化的任务分解，Agent 做什么取决于人类说什么。

• 没有系统化的质量保证，代码质量取决于 Agent 的单次输出质量和人类的 review 能力。

这个阶段像是给开发者配了一副强大的AI外骨骼，创造了巨大的个人生产力提升，也让许多没做过程序员的人可以成为Vibe coding的编程者。但它的天花板也显而易见：当项目规模超过单个上下文窗口的容量，当任务复杂度超过单次对话的承载能力，当需要多个并行的工作流同时推进时——一个人加一个 Agent 的模式就开始吃力了。

三、第二阶段：流程化 Agent 工坊

GSD、Matt Pocock 的 skills 和 sandcastle，代表了第二阶段的雏形。这个阶段的核心转变是：从“人类手动驾驶 Agent”到“用流程和规格来驾驶 Agent”。

GSD 给出了流程：从项目愿景、需求、路线图，到阶段计划、原子任务、分 wave 执行、验收和交付。它把上下文从聊天记录中抽离出来，沉淀到文件系统里。文件不只是文档，而是项目记忆、流程状态和轻量契约。

Matt Skills 给出了工程习惯：追问、PRD、issue、TDD、诊断、架构审查、triage。这些 skills 像是一组可插拔的工程方法模块。它提醒我们，未来的软件工厂不能只有一个巨大的万能 prompt，而应该有许多小而硬、可审查、可替换、可组合的技能。

Sandcastle 给出了运行环境：Agent 应该在隔离环境中工作，有自己的分支、日志、提交记录和执行结果。否则多个 Agent 并行开发时，很快就会互相污染、互相覆盖、无法合并。

第二阶段的本质是：

AI 编程开始拥有流程、技能、沙箱和反馈闭环。

这个阶段的特征：

• 流程开始显性化。开发不再是一个无结构的对话，而是有阶段、有计划、有验证的工序。

• 上下文管理从“聊天历史“升级为“项目状态“。STATE.md、CONTEXT.md、PLAN.md等文件成为跨上下文窗口的记忆载体。

• 多 Agent 角色开始分化。Planner、executor、checker、verifier、debugger 各司其职。

• 质量保证开始制度化。不是依赖 Agent “一次写对“，而是有计划检查、执行验证、用户验收测试、失败后的调试循环。

• 工程纪律被编码为可执行约束。TDD、诊断流程、架构审查不再是口头建议，而是 Agent 必须遵循的技能定义。

这已经不再是一个人和一个聊天窗口的关系，而更像是一个会拆任务、开分支、派工、跑测试、做验收的小型 Agent 工坊：有人负责计划，有人负责执行，有人负责 review，有人负责验证，代码在分支里运行，结果被记录，失败可以 debug。

但它仍然不是真正的、完整的软件工厂。

四、趋势：从手工组织到自动组织

把第一阶段和第二阶段放在一起看，趋势已经非常清楚。软件开发正在从“人类手工组织上下文、任务、代码和反馈“，转向“Agent 系统自动组织上下文、任务、执行环境和验证循环“。

第一阶段，人类组织一切，Agent 执行指令。第二阶段，流程和规格开始替代人类的部分组织工作，但流程本身是人类预设的。那么第三阶段的自然推演就是：系统本身能根据业务目标，自动生成组织结构、生产工序、质量体系、运行环境和专家调用机制。

过去的软件开发，是人类在手工组织一切：人类理解需求，人类拆任务，人类维护上下文，人类写代码，人类跑测试，人类判断失败原因，人类协调多人协作，人类决定什么时候返工。

AI 工具出现后，最初只是帮人类完成其中一部分工作，比如写代码、解释错误、生成测试。但现在，GSD 和 Matt Pocock 这些项目表明，AI 系统正在开始接管更上层的组织工作。

也就是说，软件开发正在从人类手工组织上下文、任务、代码和反馈，转向Agent 系统自动组织上下文、任务、执行环境和验证循环，这是一个非常重要的转变。

因为软件开发的难点从来不只是“写代码”，真正困难的是在复杂需求、复杂架构、复杂依赖、复杂团队和复杂反馈之间保持一致性。一个大项目之所以难，不是因为每一行代码都很难，而是因为所有东西互相牵连：需求影响架构，架构影响模块，模块影响接口，接口影响测试，测试失败又可能反过来说明需求或架构本身有问题。

单个 Agent 即使再强，也会被这种复杂性淹没。上下文窗口再大，也无法无限承载整个软件系统的全部细节。更现实的方向不是让一个 Agent 记住一切，而是让多个 Agent 在清晰的组织结构中分工协作。

这就引出了第三阶段：真正的 AI 软件工厂。下面，我们尝试畅想和描绘这第三阶段的构成和形态。

五、第三阶段：AI 软件工厂

5.1 真正的AI软件工厂是什么

真正的 AI 软件工厂，不是一个更会写代码的聊天机器人，也不是一个更漂亮的 IDE。它应该是一个能够根据产品目标自动生成组织结构、生产工序、质量体系、运行环境和专家调用机制的智能系统。

它的目标不是替代某一个程序员的键盘，而是重构整个软件生产过程。

可以这样理解：

第一阶段解决“一个 Agent 如何成为优秀程序员”。第二阶段解决“Agent 如何按工程流程工作”。第三阶段解决“多个 Agent 如何组成一家能持续交付的软件公司”。

这个软件工厂的核心，不是单一模型，而是一套由认知图谱、认知单元、契约系统、运行环境、反馈归因和人类专家共同构成的生产系统，是一座能根据产品目标，自动搭建组织结构、生成工序、签订合同、派遣工人、检验产品、处理返工、并在必要时请来外部专家的软件制造厂，是让多个 Agent 组成一家能设计、分工、执行、质检、返工、演化，并调用人类专家的软件公司。

5.2 认知时空图谱：工厂的组织结构

真正的软件工厂首先需要一张认知时空图谱。

所谓“时”，是软件开发的阶段演进：

业务需求→ PRD → 业务架构 → 流程设计 → 软件架构 → 模块设计 → 模块开发 → 模块测试 → 集成测试 → 交付

所谓“空”，是同一阶段内可以并行展开的任务空间。例如多个模块可以并行设计，多个接口可以并行实现，多个测试可以并行运行，多个 Agent 可以同时工作。

这张图谱不是一次性生成的瀑布计划，而是渐进式展开的。上游认知单元完成并被确认之后，系统才生成下游认知单元。需求没有澄清，就不应该贸然生成架构；架构没有稳定，就不应该贸然拆模块；接口契约没有确定，就不应该让多个 Agent 各写各的。

因此，AI 软件工厂中的任务组织不是简单的 todo list，而是一张动态演化的生产图谱。这与 GSD 的“先 discuss 再 plan 再 execute”是同一思路，但被推广为一种通用的、可查询、可审计、可回滚、可重构的动态图结构。

图谱中的每个节点不是一个模糊的“任务“，而是一个有严格定义的认知单元。每个认知单元都有状态、输入、输出、依赖、责任 Agent、验收标准和失败反馈路径。每条边都表示某种依赖或约束：需求约束架构，架构约束接口，接口约束实现，实现接受测试验证，测试失败反过来触发归因和返工。

这张图谱的价值在于：它让软件生产从“线性聊天”变成“结构化协作”。

5.3 认知单元：工厂的基本生产细胞

认知单元是 AI 软件工厂的原子生产单位。它不是只有一个 prompt，也不是只有一个 Agent，而是一组完整的工作机制：

认知单元 = Worker + Checker + Contract + Runtime + Memory + Escalation Policy

Worker是负责产出的 Agent。它接收输入契约，在自己的上下文窗口中工作，使用被分配的技能（skills），最终生成产物。

Checker是负责验收的 Agent。它与 Worker 共享同一份契约，但拥有独立的上下文窗口。Checker 不是简单地“看一眼说通过“，而是要对照契约逐条验证、运行测试、检查一致性、指出缺陷并给出修改方向。

Worker/Checker 结对是内生的、结构化的，不是可选的、临时的。每个关键任务都应该天然包含“生产者”和“审查者”。这是从 GSD 的 plan-checker 和 Sandcastle 的 sequential-reviewer 中提取的设计原则，但被提升为不可妥协的基本生产纪律。每一个认知单元，无论是写 PRD 的、做架构设计的、写代码的、还是做测试的，都必须有 Worker/Checker 对。这就像制造业中“自检“不能替代“质检“——生产和检验必须由不同的主体完成。

Worker 和 Checker 的上下文是严格隔离的。Worker 不会被 Checker 的推理过程污染，Checker 不会被 Worker 的实现路径锚定。如果 Checker 多轮否决 Worker 的产物，系统不会无限循环，而是触发升级策略（Escalation Policy）——这将在后文详述。

每个认知单元还有自己独立的Memory，用于记录该单元的工作历史、决策记录和上下文摘要。这借鉴了 GSD 的 .planning/目录和STATE.md的思路，但将其标准化为每个认知单元的标配。

认知单元的技能是可装配的。借鉴 Matt Skills 的可插拔理念，一个“支付模块开发“认知单元的 Worker 可能装配了 payment-domain-skill、api-design-skill、tdd-skill，而它的 Checker 装配了 security-review-skill、contract-verification-skill、regression-test-skill。不同的认知单元根据自身职责装配不同的技能组合。

一个系统如果只有 Worker，没有 Checker，它就会不断产生看似合理但无法信任的结果。一个系统如果只有 Checker，没有运行环境，它又只能做语言层面的评论，无法形成真实验证。

所以，认知单元必须把生产、检查、运行和反馈合成一个闭环。

5.4 三个平面：设计与契约、工作、运行环境

真正的AI软件工厂至少需要三个相互关联的运作平面。

第一个是设计和契约平面。

这里存放需求、PRD、架构决策、接口契约、数据模型、测试标准、验收标准、领域词汇和版本关系。它类似 GSD 的 planning 文件，但应该更进一步，成为统一的 Contract Registry。

Contract Registry 不是普通文档库，而是多 Agent 协作的共同语言。它要回答：这个模块的输入是什么？输出是什么？接口如何调用？错误如何处理？哪些行为是必须满足的？哪些需求已经被哪个代码实现覆盖？哪个测试验证了哪个需求？

第二个是工作平面。

这里运行各种认知单元。PRD 单元、架构单元、模块开发单元、测试单元、集成单元、归因单元，都在这里被调度。它负责拆任务、分配 Worker/Checker、控制依赖顺序、管理并行度、处理阻塞、触发返工。

第三个是运行环境平面。

这里是真实代码、依赖、数据库、容器、分支、worktree、CI、测试日志和运行结果所在的地方。没有这个平面，AI 软件工厂就只是在文档中自我感觉良好。代码必须能跑，测试必须能失败，失败必须能被记录，记录必须能反馈到认知单元。

这三个平面缺一不可。契约平面定义“应该做什么“，工作平面负责“怎么做“，运行环境平面验证“做得对不对“。运行环境的测试结果反馈给 Checker，Checker 对照契约判定是否通过，未通过则要求 Worker 返工。

只有设计平面，没有运行平面，会变成纸上谈兵。只有运行平面，没有契约平面，会变成混乱试错。只有工作平面，没有契约和运行反馈，会变成一群 Agent 在互相聊天。

真正的软件工厂必须让三者闭环：设计和契约平面→ 工作平面 → 运行环境平面 → 反馈归因 → 设计和契约平面

5.5 Human-as-a-Skill：人类专家被技能化调用

在第一阶段，人类是驾驶员，Agent 是工具。在第二阶段，人类是监督者，Agent 在流程中工作。在第三阶段，关系发生了一个微妙但重要的反转——

人类成为系统可以按需调用的一种 Skill。

这不是说人类变得不重要了。恰恰相反，人类被提升为关键节点上的专家资源。系统不再是笼统地“让人类 review 一下“，而是能精确地识别：

什么时候需要人类介入——Worker/Checker 多轮冲突无法收敛、PRD 中存在歧义无法通过推理消解、架构决策影响面过大需要确认、安全风险超过预设阈值、端到端测试多轮失败归因指向需求层假设错误。

什么角色的人类——产品经理、架构师、安全专家、领域专家、程序员、测试工程师。

以什么方式调用——明确的输入（当前状态、冲突记录、备选方案）、明确的期望输出（决策、修改意见、确认）、明确的超时机制（人类不响应时系统如何降级处理）。

例如：

• 当需求存在多种业务解释时，调用产品经理 Skill；

• 当架构变更影响多个模块时，调用架构师 Skill；

• 当 Worker 和 Checker 多轮无法达成一致时，调用资深工程师 Skill；

• 当测试失败涉及权限、隐私、支付等高风险领域时，调用安全专家 Skill；

• 当端到端测试多次失败且无法定位责任模块时，调用测试专家或系统分析专家 Skill。

GSD 已经有了用户 approval 和 UAT 的机制，Matt Skills 的 /grill-me本质上也是一种人类参与的结构化交互。AI 软件工厂把这些实践推广为统一的 Human-as-a-Skill 框架：人类是系统的一部分，但不是瓶颈——系统只在真正需要人类智慧的地方调用人类，其余时间自主运转。人类专家不再只是“随时可以问的人”，而是被系统作为一种高价值、低频、强判断的外部能力来调度。

未来的软件工厂中，人类可能不是每一行代码的作者，却是关键问题的裁判、架构方向的把关者、业务语义的确认者和价值目标的定义者。

这会改变人类在软件开发中的位置：从手工劳动者，逐渐转向目标设定者、约束制定者、异常处理者和责任承担者。

5.6 图谱的演化、重构与回滚

软件开发不是一条直线，AI软件工厂也不可能一次就做对。代码会有 bug，架构会有问题，需求会有歧义，甚至需求本身会变。因此，认知时空图谱必须是可演化、可重构、可回滚的。

可演化，是指系统可以随着理解加深生成新的认知单元，意味着图谱在运行过程中可以生长。一个模块开发认知单元在工作过程中发现需要一个新的公共组件，系统可以动态生成一个新的认知单元来开发这个组件，并调整依赖关系。例如原本只有“支付模块”，后来发现需要拆成“支付编排”“支付渠道适配”“退款状态机”“对账任务”等多个单元。

可重构，是指系统可以调整图谱结构。当集成测试失败时，系统能沿着 Trace Graph（追踪图谱）回溯，根据判断来重构图谱。例如两个模块边界混乱，可以重新划分职责；某个公共能力被多个模块重复实现，可以提升为共享服务；某个接口契约频繁冲突，可以回到架构层重新设计。在最极端的情况下甚至需要回到 PRD 层面重新讨论。

可回滚，意味着图谱的每个状态都有版本。当一次重构引入了更多问题时，系统可以回滚到之前某个稳定版本的图谱状态，换一条路径重试。需求契约、架构决策、代码分支、测试结果和 Agent 产出都应该有版本记录。否则系统一旦走错方向，就只能靠人类从混乱中手工恢复。

这要求软件工厂拥有一张 Trace Graph，也就是从需求到代码再到测试反馈的因果追踪图：

需求→ PRD → 架构决策 → 接口契约 → 模块设计 → 代码提交 → 测试结果 → 失败归因 → 返工动作

当端到端测试失败时，系统不能只说“测试没过”。它应该尽量回答：是代码实现错了，接口契约错了，模块边界错了，架构假设错了，还是需求本身描述错了。

这种能力在 GSD 中有初步体现——原子 commit 和 summary 构成了可追溯的执行记录。但 AI 软件工厂需要的是从需求到代码到测试结果的完整因果链——每一个产物都能追溯到它的来源，每一个失败都能定位到它的根因。

5.7 AI软件工厂概念框架

把以上构件组合在一起，AI 软件工厂的整体架构可以这样描述：

AI软件工厂是一个由契约驱动的、具备分形自我繁衍能力的、人类作为兜底智力资源的异步认知生产系统。

六、不是跳跃，而是生长

值得强调的是，这三个阶段不是互相替代的关系，而是层层包含的关系。

第三阶段的 AI 软件工厂不需要从零开始构建所有组件。Claude Code 是成熟的开发执行器——它可以被包装为认知单元中 Worker 的底层引擎。GSD 的 phase/wave/plan 是流程管理的验证过的模式——它可以被吸纳为图谱调度层的实现参考。Matt Skills 的可插拔技能理念——可以直接成为认知单元的技能装配机制。Sandcastle 的沙箱隔离——可以成为运行环境平面的基础设施。

也就是说，GSD、Matt Skills、Sandcastle 和 Claude Code 这些项目各自虽然都并不等于完整的软件工厂，但它们像几块已经浮出水面的拼图。

Claude Code 给了 Agent 一双会写代码的手。GSD 给了 Agent 一套阶段化施工流程。Matt Skills 给了 Agent 资深工程师的工作习惯。Sandcastle 给了 Agent 可隔离、可并行、可回收的工地。

而真正的 AI 软件工厂，要把这些能力组织成一张可演化的认知生产图谱。

GSD 和 Matt Pocock 的快速流行告诉我们一件事：开发者已经在用实践投票，表明“一个人加一个 Agent”的模式不够了。他们需要流程，需要规格，需要工程纪律，需要隔离环境。而这些需求的逻辑终点，就是一个能自动组织这一切的系统。

AI 软件工厂的早期形态可能不是一个宏大的平台，而是一组围绕现有开发工具链形成的协议层。就像 GSD 证明的那样——从一个 .planning/目录和几个 Markdown 文件开始，就已经能创造巨大的秩序增益。关键不在于一步到位，而在于每一步都在正确的方向上：

• 让流程可审计；

• 让技能可替换；

• 让契约可验证；

• 让失败可归因；

• 让人类被精确调用而非模糊依赖。

当这些原则被逐步落实，当认知单元、契约中心、追踪图谱和运行环境平面逐渐成型，AI 软件工厂就不再是一个遥远的构想，而是一个正在从 GSD 和 Matt Pocock 们的实践中自然生长出来的未来。

那个未来的样子是：你描述一个业务目标，系统自动生成认知时空图谱，自动创建认知单元，自动签订契约，自动派遣 Worker 和 Checker，自动在隔离环境中运行和测试，自动归因失败并触发返工，在关键节点精确调用人类专家——然后交付一个经过端到端验证的软件系统。

七、结语：软件工厂的真正含义

未来的 AI 软件工厂，不应该被想象成一个巨大的黑箱按钮：输入一句需求，输出一个完美软件。那种想象既不现实，也不可靠。

更可信的图景是：软件工厂会像一家高度自动化的软件公司。它有产品经理式的需求澄清，有架构师式的系统设计，有工程师式的模块实现，有测试人员式的验证，有运维式的运行环境，有审计式的追踪记录，也有在关键时刻调用人类专家的机制。

它不是取消软件工程，而是把软件工程中的隐性经验显性化、结构化、自动化。

从 OpenClaw 和 Claude Code 到 GSD 与 Matt Pocock，我们看到的是 AI 编程从个人增强走向流程组织。从 GSD 与 Matt Pocock 再往前，我们看到的则是软件开发可能进入一个更深的阶段：

软件不再主要由人类手工组织生产，而是由 Agent 系统在契约、图谱、沙箱、反馈和人类专家协同中自动组织生产。

它的最终目标，不是制造一个无所不知的超级 Agent，而是制造一个能分工、能协作、能质检、能返工、能追责、能演化，并能在关键处请人类专家介入的智能生产系统。

未来的软件工厂，不是一个更聪明的程序员，而是一家会自动搭班子、定合同、派工、验收、返工和进化的软件公司。