夜雨聆风写在前面：为什么你总在敲"继续"
如果你认真用过 Claude Code（或者任何同类的 AI 编程智能体），大概率撞过这堵墙：
让它干活 → 干一半停下 → 你打"继续" → 又停 → 再打"继续"……
三个小时过去，你突然意识到自己已经敲了四十遍"继续"。AI 看起来很能干，但它不会自己跑到终点，更不会自己判断"这活到底干完没有"。
这篇文章想解决的，正是这个问题。我们不做花哨的演示，而是从一个空目录开始，亲手搭出一套能够自走、低成本、可并行的开发智能体框架。跟着步骤走完，你手里会留下一个技术栈无关的脚手架，可以直接套用到自己的项目上。
这个思路的源头，是 Anthropic 的 Nicholas Carlini 做过的一个著名实验：用 16 个并行的 Claude 智能体，跑了大约 2000 个会话、持续两周，几乎全自主地写出了一个十万行规模的 C 编译器（能在 x86/ARM 上跑起 Linux 6.9）。不过那个实验用 Docker 把每个智能体隔离开，是个不带编排的大型原型，普通人很难复刻。
我们要做的不是照搬，而是把那个实验里提炼出的四条教训，用无需 Docker、单会话内的SubAgent重现出来：
别让它停——用机制保证自走，而不是靠你不停催。 **用测试定义"完成"**——让"做完了"这件事可以被机器判定。 并行起来——把相互独立的活同时干。 压缩输出、守住上下文——别让冗长的中间结果把上下文撑爆。
先搞清楚 Claude Code 的四种"扩展点"
2026 年的 Claude Code 有好几个扩展位，一旦混淆，整个设计就会塌掉。所以动手之前，先把这四样东西分清楚：
| CLAUDE.md | 每次启动都加载 | ||
| Skill | 仅在需要时动态加载 | ||
| SubAgent | |||
| 斜杠命令（Slash Command） |
真正决定成本的是右边两列。每次都被加载进上下文的只有 CLAUDE.md，其余都是按需加载。
这就是成本设计的命门。每次全量加载的 CLAUDE.md 和提示词，越长，"上下文计费"就越重——一个中等大小的 CLAUDE.md 就要几百到一千 token，再塞进模板，可能还没开始读代码就烧掉几千 token。如果你一天要自走几十个任务，这笔账绝对不能忽视。
所以策略很简单：**把步骤和模板放进Skill里，让 CLAUDE.md 只当"向导"**。这就是"压缩输出"这根支柱的具体落地。
成品长什么样
整套东西搭完，目录结构是这样的：
my-project/├── CLAUDE.md # 向导（骨架 + 停止点 + Skill调用）├── SPEC.md # 运行后由 feature-spec 生成├── .claude/│ ├── agents/ # SubAgent（执行层：分配模型）│ │ ├── implementer.md│ │ └── reviewer.md│ └── skills/ # Skill（知识层：按需加载）│ ├── feature-spec/SKILL.md # 生成规格书（自带模板）│ ├── structured-review/SKILL.md # 结构化评审（用户触发）│ └── e2e-runner/ # E2E（自带脚本）│ ├── SKILL.md│ └── screenshot.sh└── tests/ # 测试规约与脚手架（真实测试与实现同放）启动时只要敲一句 claude。父智能体读 CLAUDE.md，把任务拆开，并行跑SubAgent，在需要的阶段加载Skill，最后把结果整合起来。并行真正发力的地方有三处：调查、实现、验证。
整体流程可以画成这样：
父智能体 (Claude Code) └ CLAUDE.md（向导）+ 仅在需要时加载 Skill Phase 1 调查 〈并行・读〉 Explore │ ▼ Phase 2 规格书 声明并行分组 │ ▼ ◆ 停止① 规格由人类审批 │ ▼ Phase 3 实现 〈并行・写〉 implementer │ ▼ Phase 4 整合闸门 〈串行・1人〉 全测试 + lint 全绿 │ ▼ Phase 5 验证 〈并行・读〉 reviewer │ ▼ ◆ 停止② /structured-review 由人类判断四个支柱：为什么是"并行 + 循环"
把前面那四条教训落到工程上，就是四个相互咬合的机制：
规格驱动：实现之前，先用规格书把"要做什么"敲定。 并行：让相互独立的活同时跑（调查、实现、验证）。 循环：满足完成条件之前持续自走。 TDD：让"完成"变成机器能判定的状态。
这四个里，规格驱动是地基。没有规格就并行，每个智能体会按自己的理解动手，整合的时候矛盾全爆出来。**规格书是所有智能体共同的"标准答案"**，并行才成立。
特别要在规格阶段就声明清楚：哪几组任务彼此独立（也就是同时写也不会冲突）。这是后面并行实现的前提。
下面我们就一步步把这四根支柱织进文件里。
STEP 0：搭骨架
先把目录建好，连 skills 目录也一并挖出来：
mkdir my-project && cd my-projectmkdir -p .claude/agents .claude/skills teststouch CLAUDE.mdSTEP 1：把 CLAUDE.md 写成"向导"
CLAUDE.md 每次启动都会被读，所以这里只写骨架和停止点，具体步骤全交给Skill。
# Parallel Subagent Framework## 实施时的定制（请替换）- 测试命令: <测试命令> # 例: bun run test / pytest- Lint 命令: <Lint命令> # 例: bun run lint / ruff check- UI 目录: src/components/ / 数据获取: src/api/ / DB: prisma/schema.prisma## 流程（骨架）Phase 1 调查(并行) → Phase 2 规格书(声明并行分组) → [停止① 人类审批] → Phase 3 实现(TDD・并行) → Phase 4 整合闸门 → Phase 5 验证(并行) → [停止② 结构化评审]## 各阶段调用哪个Skill- Phase 2（规格书）→ 使用 skill「feature-spec」- 需要 E2E / 截图时（随时・流程外）→ 使用 skill「e2e-runner」- Phase 5（验证）之后 → 提示用户用 /structured-review 并停下## 绝对规则- 只在「规格评审（停止①）」和「结构化评审（停止②）」两处征求确认。- 其余一律不停，自主推进。- 停止①：给出规格书后，人类未审批前不得进入 Phase 3（实现）。- 停止②：结构化评审必须等人类用 /structured-review 触发，不得擅自执行。两个要点：把命令写成 <测试命令> 这样的占位符，做到技术栈无关；把停止点固定在"①规格评审"和"②结构化评审"两个地方。
STEP 2：用内置 Explore 把调查并行化
调查阶段直接用 Claude Code 的内置SubAgent Explore：只读、默认走 Haiku，快且便宜。你不用自己写 explorer.md，只要在 CLAUDE.md 里用自然语言下指令，Claude 会自动委派给 Explore。
往 CLAUDE.md 里追加：
## Phase 1: 调查（并行・用内置 Explore）把以下三项调查，各自用独立SubAgent**并行**执行。- 调查 UI 目录。把相关组件的文件路径、props 类型、state、主要事件处理器，用列表汇报。不要写代码。- 调查数据获取目录。把 API 端点、类型、hook，用列表汇报。不要写代码。- 调查 DB / schema。把表结构、关系、数据访问层，用列表汇报。不要写代码。每项调查只用**列表**汇报，不要长篇大论。起作用的是两点：**"只调查、别写代码"（角色分离）** 和 "用列表汇报"（输出最小化）——避免冗长输出把父智能体的上下文填满。
几个容易踩的坑
CLAUDE.md 里的指令是"请求"而非"保证"。 你写"并行执行"，Claude 是否真并行，取决于模型判断。要确保并行，可以用 shell 脚本同时起多个 claude -p（headless 执行）进程，或用 /batch 命令展开并行智能体。想让它"中途不停、一口气跑完"，可以用 /goal 命令设置完成条件。
claude -p（headless / SDK 执行）可能走按量计费。 普通交互会话吃 Pro / Max 订阅额度，但 headless / SDK 方式在某些环境或套餐下会被算作 API 按量计费。批量大量跑很容易把账单撑爆，接入自动化前务必确认自己套餐下的计费方式，以及到底是哪把 key / 哪套认证在跑。
关于 Explore 的模型。 文档上说 Explore 默认用 Haiku，但有些环境或版本会继承会话模型；如果你装了大量 MCP server 或插件，可能超过 Haiku 的提示词体积上限导致 Explore 失败。这时用 CLAUDE_CODE_SUBAGENT_MODEL 环境变量设个兜底模型。
STEP 3：把规格书做成"Skill"（自带模板）
这一步是规格驱动开发的真正落地。调查结果固化成规格书，人类审批，之后的实现、测试、评审全部以这份规格为准——**规格书成为所有智能体共同的"标准答案"**。
模板如果写进 CLAUDE.md，每次都会进上下文，所以做成Skill，只在生成规格书那一阶段加载：
---name: feature-specdescription: 从调查结果生成功能规格书。新功能实现流程中用于敲定规格。---规格书分两部分输出：## Part 1 — 规格（★人类要审的部分）- 能做到什么（用户视角、不带技术术语）- 界面示意 / 操作流程 / 验收条件（清单）- 需要截图的点打上 📸（与 STEP 7 的 e2e-runner 对应）## Part 2 — 实现计划（给 AI 看，无需审批）- 实现集清单（按依赖顺序）/ 各集的测试观点 / 类型与数据访问层方针- 并行分组声明：写明各集**会动哪些文件**，把互相只动不同文件的集归到同一"波"（可同时实现）。会动共享文件的连接不放进波，留给整合闸门。规格书输出到 SPEC.md。展示时只给人看 Part 1，Part 2 说明"是技术细节，无需审批"。分两部分的理由有两个：
降低审批门槛：审批者哪怕不是工程师，只读用户视角的 Part 1 就能拍板。 埋下并行实现的前提：Part 2 的并行分组声明提前确定"哪些集文件独立、哪些有依赖"，所以实现阶段能安全并行。规格驱动和并行在这里是连成一片的。
生成规格书是流程上必须经过的一步。Skill是"由模型判断是否触发"的，光靠自动触发可能不被调用。所以更稳妥的做法是：**在 CLAUDE.md 的流程里用名字显式喊"用 skill feature-spec"**。
再给 CLAUDE.md 补一段，关键是把停止①（规格评审）固定在这里：
## Phase 2: 规格书（用 skill「feature-spec」）把调查结果用 skill「feature-spec」整理进 SPEC.md（两部分 + 并行分组声明）。- 只给人看 Part 1，Part 2 说明"技术细节，无需审批"。- 【停止①】给出规格书后，人类未审批前不得进入 Phase 3。STEP 4：写 TDD 实现规约和"防偷懒"条款
实现过程中始终生效的质量规约，绑定到 reviewer SubAgent里。先是 TDD 基本节奏：
## 实现集的推进方式（RED → GREEN → REFACTOR）1. 先写测试（RED）2. 写出能通过的最小实现（GREEN）3. 重构（REFACTOR）4. 确认测试通过 → 进入下一集5. 失败就自己修。修 3 次还过不了就汇报。然后是自走智能体里最关键的"封堵偷懒路子"：
## 绝对不许做的事- 删除/禁用测试来假装"通过了"- 偷偷放松测试的期望值（断言）来蒙混过关- 无视失败继续往下走- 每次都甩锅给人类问"怎么办？""别放松期望值"这条，是只禁止删除堵不住的一个隐蔽后门，必须单独写明。
并行实现与整合闸门（并行的主战场）
并行读不会冲突，难的是并行写。 同一个文件被多个智能体动，整合时就会坏掉。所以设两个条件：
文件独立：同时跑的几个集只动各自不同的文件（规格书里已声明并行分组）。满足这点甚至连 worktree 都不需要——大家各建新文件，自然不冲突。 隔离：如果保证不了独立、或多个集要动既有文件，就把每个实现者分到单独的 git worktree，防止写入冲突。
并行实现之后，必须放一道整合闸门。动共享文件的连接（合成、路由）只在这里由一个智能体串行做，最后让全部测试 + lint 转绿。
## Phase 3: 实现（TDD・并行）按规格书 Part 2 的"并行分组"同时启动多个 implementer，各自 RED→GREEN→REFACTOR。- 每个集只写自己的文件和自己的测试（不碰共享文件）。- 文件独立明确则不需 worktree；不确定就用单独 worktree 隔离。- 有依赖的集放到下一波（依赖顺序由规格书声明）。## Phase 4: 整合闸门（并行实现后必放一道・由父智能体串行）- 父智能体（或某一个 implementer）把各集成果连接起来（碰共享文件只在这里）。- 跑全部测试 + lint 确认全绿。检查有无冲突、重复、声明外的文件改动。STEP 5：按角色分配模型（执行层）
SubAgent定义在 .claude/agents/ 下，用 front matter 的 model 字段按角色固定模型。重点是按角色分配，而不是按任务动态切换。
implementer.md：
---name: implementerdescription: 功能实现 / Bug 修复用。处理复杂实现。tools: Read, Edit, Write, Bashmodel: opus---你是实现负责人。以规格书（feature-spec 的 Part 2）为"标准答案"，遵循以下质量规约用 TDD 实现。（RED→GREEN→REFACTOR 流程、绝对不许做的事、并行实现规则……同上）reviewer.md：
---name: reviewerdescription: 代码质量评审用。代码改动后使用。tools: Read, Grep, Glob, Bashmodel: sonnet---你是资深评审。只读，只用列表返回问题点（不做自动修复）。（应被遵守的质量规约 + 评审观点：正确性 / 规格覆盖率 / 重复与过度实现 / 类型安全……）只返回所负责维度的问题点，是否修复交给父智能体判断。角色与模型的对应大致如此：
opus | ||
sonnet | ||
haiku |
两个提醒：
model用别名写。 写全 ID（如claude-opus-4-6）的话，每出新模型就得改一堆文件；用别名（opus/sonnet/haiku），Claude Code 会自动解析到最新对应模型。工具名要确认。 tools字段能填的工具名会随版本变化，用/tools命令查当前可用清单，用准确的名字。
每个SubAgent都在自己的上下文里跑，不会挤占主对话。
STEP 6：把结构化评审做成"用户触发Skill"
这是我觉得整篇里最该划重点的部分。
并行智能体为了省上下文而运行，结构上宏观视角会变弱：每个集单看都是绿的，但全局看可能还残留重复或遗漏。所以要在测试和 lint 转绿"之后"，强制插入一道人类必须停下、亲眼看的评审。
但让人类一上来就精查全局太重，于是做成两段：
机器侧的预筛：人类评审前，先插一道"把验证按观点拆开并行跑"的工序——不是把全部丢给一个评审，而是按维度分叉成多个评审（正确性 / 规格覆盖率 / 重复与范围 / 类型安全），即扇出（fan-out）。只读评审同时启动，各自只返回列表问题点。只读不冲突，还能用维度分担捞出单一评审会漏掉的宏观问题。这是并行的第三处（验证并行），也是风险最低、最容易加上的并行。 人类的判断：带着这些问题点，最后由人类用 /structured-review停下来拍板。
第一段对应流程里的 Phase 5，给 CLAUDE.md 补一段：
## Phase 5: 验证按观点并行执行（只读・停止②之前）测试、lint 转绿后，按维度并行启动 reviewer（只读不冲突）。- 正确性（Bug、边界条件）- 规格覆盖率（验收条件 vs 实现/测试）- 重复、过度实现、遗漏- 类型安全、数据层一致性每个评审只用列表返回问题点。是否修复由父智能体判断（不自动修复）。带着问题点去 /structured-review。这是个绝对要触发的停止点。Skill自动触发"有时不被调用"，所以加上 disable-model-invocation: true 做成仅用户触发，用 /structured-review 显式调用：
---name: structured-reviewdescription: 实现后的结构化评审（人类最终检查）。disable-model-invocation: true---确认以下各项，向人类汇报后停止：- 界面需要的 CRUD / 逻辑是否齐全- 有没有过度实现、重复、遗漏- 领域一致性是否成立很多自走流程只把停止点设在"实现前的规格评审"，实现后只要测试绿就自动收工。既然知道宏观视角弱，实现后也该设关卡。 停止就两处：规格评审和结构化评审。
一个已知问题：设了
disable-model-invocation: true的Skill，也有在会话恢复（--resume）时被模型看到的 bug，或反过来用户显式调用斜杠命令时 Claude 却拒绝执行的情况（2026 年 2 月时点的 GitHub Issues）。不顺时，在 CLAUDE.md 的绝对规则里同时写明"结构化评审必须等人类用 /structured-review 触发，不得擅自执行"会更稳。
STEP 7：把 E2E 做成"Skill"（自带脚本）
Skill的真正价值在这里体现：E2E 只在那一阶段才需要，而且能把脚本一起打包。把 screenshot.sh 直接塞进Skill文件夹：
---name: e2e-runnerdescription: 生成并执行 E2E 测试与截图。 「写个 E2E」「确认下界面动作」时使用。allowed-tools: Read, Write, Bash---1. 把规格书的 📸 标记与截图点对应起来2. 用 Playwright 生成测试，放到 e2e/3. 用 ./screenshot.sh 截全部界面，存到 screenshots/（screenshot.sh 随本Skill文件夹一同打包）这样只有用到 E2E 时模板和脚本才加载，其他阶段一个字节都不占。而且 E2E 用"写个 E2E"触发很明确，这里交给自动触发就行。
STEP 8：用 /goal 锁定完成条件，并装上"断路器"
这是循环的安全装置。与其用自然语言写"别停"，不如用 2026 年 5 月在 Claude Code v2.1.139 引入的 /goal。
/goal 的机制是：设定完成条件后会一直自走到达成为止，每个回合结束后由另一个评估模型（默认 Haiku）读会话记录判断条件是否达成。不满足就不交还控制权，进入下一回合。
/goal 把"全部实现集绿 且 lint 通过 且 结构化评审通过"全部完成这样"别停"就不再靠措辞，SubAgent凭心情中途退场的事故也会减少。
/goal评估器的局限：评估模型只读会话记录判断，不会读文件、也不执行命令。也就是说，Claude 只要汇报"测试全过了"，评估器就信。完成条件要设成Claude 能在对话中明确给出的输出（粘贴测试结果、lint 输出等）。像"代码质量高"这种主观条件不起作用。
自走和失控只有一线之隔，所以必须装断路器：
## 断路器- 流程开始时 `/goal` 设一次再进入自走（写法见下）。- 完成条件要紧（模糊条件就是无限循环的燃料）- `/goal` 条件里**把回合或时间上限写成条件句**（例：「or stop after 20 turns」）- Auto 模式下不要无条件批准所有工具- 测试修复每集最多 3 次（局部上限）- 整个流程的上限也务必要有（光靠局部上限护不住钱包）上限要写进"条件句"而非 flag。
/goal有三种形态：/goal <条件>设定目标、/goal查状态、/goal clear解除。回合上限等要写在完成条件的句子里，官方示例就是「or stop after 20 turns」这样的回合/时间从句。评估器只看会话里出现过的内容，所以累计 token 能在状态里看，却不宜当停止条件，用回合/时间来卡更稳。条件句最长 4000 字符。/goal本质是会话作用域的、基于提示词的 Stop hook，只在批准了信任对话框的工作区生效。
局部上限（修复 3 次）之外，整个流程的上限也一定要有。
跑起来
搭完了，剩下就是启动：
claude# 或者claude -p "在用户列表页加一个搜索功能"父智能体读 CLAUDE.md 骨架，按这个流程走：
Phase 1 并行调查：用内置 Explore 同时调查。 Phase 2 规格书 → 停止①： feature-spec输出带并行分组声明的规格书，求审批并停下。Phase 3 并行实现：审批后，同时实现各独立集。 Phase 4 整合闸门：把连接收束到一处，让测试 + lint 转绿。 Phase 5 并行验证 → 停止②：验证按观点拆开并行跑，带着问题点用 /structured-review再次停下。
调查、实现、验证三面并行，同时只在需要的阶段加载Skill，上下文始终很轻。
一个容易混淆的点
走完 STEP 0～8，你手里留下的是这套框架脚手架本身。开头"成品长什么样"里出现的 SPEC.md、src/ 下的实现文件，是这套脚手架实际跑起来时由 feature-spec 和 implementer 生成的产物，脚手架里一开始并不包含它们。别误以为模板里就该有这些文件。
写在最后
从零搭到尾，最后沉淀下来的其实很朴素：
把"要做什么"作为规格固定下来。 唯独"最后那道结构化评审"，始终是人类的活。
只要守住这个顺序，以及那两道绝不松手的关卡——规格评审与结构化评审——并行智能体就会变成一件非常顺手的武器。
它不再是一个需要你每隔几分钟催一次"继续"的工具，而是一条能自己跑到终点、还顺手把测试和评审都过一遍的流水线。剩下你要做的，就是把注意力从"操作工具"挪回到"做决策"上。
-- END --
推荐阅读
