9 步纪律化循环

新手用 Claude Code，靠的是「灵光一闪的好 prompt」；高手用 Claude Code，靠的是一条反复跑、不靠运气的流水线。

社区有一篇流传很广的「9 步循环」文章，把高手的做法拆成了 9 个固定环节。这一篇就把这 9 步一次讲透——它不是 9 个孤立技巧，而是一条从探索到交付的完整流水线：每一步都为下一步铺路，缺一步就会在某个环节漏水。

核心思想：区别不在模型，在模型外面的循环

先说最重要的一句话：

高手和新手的区别，不在用的模型多强，而在模型外面套的那层循环。

同一个 Claude，新手让它「直接改这个 bug」，改完收工，下一个 bug 又从零开始。高手则把流程固化下来——探索、规划、规则、拆块、强制、验证、审查、闭环、打包——每个任务都走同一条流水线，结果可复现、质量可预测。

这就像工厂流水线和手工作坊的区别：手工作坊靠师傅手感，良品率随缘；流水线靠工序，每一道都有标准。Claude Code 的 9 步循环，就是给「AI 写代码」装上流水线。

而且这条流水线配一次就够——把规则写进 CLAUDE.md、Hooks、斜杠命令，以后每个任务自动走，你不用每次重新交代。

第 1 步：动手之前先探索

新手拿到任务就喊「帮我实现 XXX」，Claude 一头扎进去改代码，改完发现踩了一堆隐藏依赖。

第 1 步是先探索。让 Explore 子代理去摸清现状：这块代码在哪个文件、调用链怎么走、有哪些约定、改这里会动到谁。Explore 是只读的、独立上下文的侦察兵——它读一万行代码回来只给你一份摘要，不污染主会话。

> 用 Explore 子代理彻底摸清 src/auth/ 目录，告诉我现在认证流程是怎么走的、有哪些对外接口不能动。

探索的价值在于让你和 Claude 在同一张地图上。不探索就动手，等于闭着眼开枪。

第 2 步：Plan 模式做方案

探索完，别急着写代码。进 Plan 模式，让 Claude 先想后做——把方案摆出来，等你批准。

> 进入 plan mode，给我一个实现 OAuth2 刷新令牌的详细方案，包括要改哪些文件、边界情况、风险点。

Plan 模式下 Claude 只读不写，把方案列清楚：功能拆解、实现顺序、边界情况、风险点。你看完点头，它才切出去动手。这把「思考成本前置」——前面花十分钟想清楚，胜过后面花两小时返工。（Plan First 详解单开一篇讲。）

第 3 步：标准写进 CLAUDE.md

方案里定下的约定——命名规范、错误处理方式、测试要求、不许碰的文件——别只在对话里说一遍。对话会忘，写进 CLAUDE.md 才是公约。

CLAUDE.md 是项目级的记忆文件，每次会话开始自动读。它像一个贴在墙上的公约：所有人都看得见，但执行靠自觉。把规则写进去，Claude 每次开干前都会读到。

# 项目公约

## 代码规范
- 用 TypeScript，不用 any
- 错误用 Result<T, E> 模式，不抛异常
- 测试必须覆盖 happy path + 2 个边界情况

## 禁区
- src/legacy/ 目录不许动
- .env 文件不许读不许写

CLAUDE.md 的关键属性是建议性——Claude 会努力遵守，但没有强制力。下一章会讲怎么用 Hooks 把规则变成铁律。

第 4 步：拆小块构建

批准方案后，别让 Claude 一口气把整个功能写完。拆成自包含的小块，每块都能独立审查、独立测试。

为什么拆小？三个理由：

能审查——一次改 50 行，你扫一眼就知道对不对；一次改 500 行，你只能祈祷。
能回退——/rewind 回到上一块，不连带丢掉前面正确的部分。
上下文不爆炸——小块改动对应小块讨论，主会话不会被一份巨型 diff 塞满。

> 把这个任务拆成 5 个自包含的小块，每块改完停下来给我看 diff，我确认后再做下一块。

「自包含」是关键词——每块改完，相关测试能过、代码能编译，不是个半成品。

第 5 步：Hooks 强制规则

CLAUDE.md 是「公约」，Hooks 是「门卫」。公约靠自觉，门卫靠强制——Hooks 在工具调用的必经之路上 100% 必运行，规则不符合就拦下。

举个例子：你要求「所有改完的代码必须过 prettier」。写进 CLAUDE.md，Claude 大概率会跑，但偶尔会忘。挂个 PostToolUse Hook，每次 Edit/Write 之后强制跑 prettier，忘不了。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write $CLAUDE_FILE_PATHS" }
        ]
      }
    ]
  }
}

Hooks 和 CLAUDE.md 的分工很清楚：

机制	性质	何时用
CLAUDE.md	建议性（靠自觉）	命名规范、设计偏好、文档要求
Hooks	强制性（100% 运行）	格式化、禁止改某文件、必须跑测试、安全检查

该自觉的写进公约，该强制的挂上门卫。（Hooks 深入有完整 9 大事件详解。）

第 6 步：让代码证明它管用

「写完了」不等于「做完了」。第 6 步是让代码自己证明管用——写测试，自动跑，「完成」的定义是测试通过。

> 给这次改动补上测试，跑一遍 npm test，全绿了再告诉我做完了。

这步的关键是自动跑。别让 Claude 说「应该没问题」就收工，让它真的把测试命令敲一遍，把输出贴给你看。测试不绿，就不算完成。

这一步把「完成」从主观判断变成客观信号：测试通过就是完成，测试不过就是没完成，没有灰色地带。这也是后续审查能成立的前提——审查者要有可验证的东西可审。

第 7 步：第二个代理审查第一个

写代码的 Claude 自己审自己，永远觉得没问题。第 7 步是派一个干净上下文的审查子代理来挑刺。

为什么要干净上下文？因为写代码的那个 Claude 已经「沉浸」在自己刚写的逻辑里，对盲点视而不见。一个从零开始的审查代理，带着批判的眼光重新读一遍，反而能看出问题。

> 派一个 review 子代理，独立读这次改动的所有代码和测试，挑出：逻辑漏洞、未覆盖的边界、与项目公约冲突的地方。只读不改，给出审查清单。

官方 best-practices 里专门有一条「Add an adversarial review step」——对抗式审查。它不是走过场，是真的找一个「不同意你」的人来挑刺。这种对抗心态能挖出自我审查永远发现不了的盲点。

第 8 步：修复-重测-重审闭环

审查代理列出的问题，不是看一眼就完事。第 8 步是闭环：修掉 → 重跑测试 → 重新审查，循环到审查干净为止。

修问题 → npm test 全绿 → review 子代理再过一遍 → 还有问题？继续修 → ……

这个循环是质量的真正保证。它把「差不多行了」逼成「真的行了」——只要审查还能挑出问题，就继续转，转到挑不出为止。这有点像精密加工里的「研磨」：一遍遍磨，直到表面没有毛刺。

闭环的退出条件必须明确：审查代理给出「无重大问题」的清单，而不是你自己觉得差不多了。

第 9 步：斜杠命令打包整条流水线

前 8 步每次手动跑一遍？太累。第 9 步是把整条流水线打包成一个斜杠命令，比如 /ship，一条命令走完探索→规划→构建→测试→审查→修复。

把它写进 .claude/commands/ship.md，内容大致是这个结构（按你项目的实际情况调整）：

---
description: 走完 9 步循环，从探索到交付打包一次
---

# /ship 流水线

按以下顺序执行，每一步停下等我确认：

1. **探索**：派 Explore 子代理摸清 $ARGUMENTS 涉及的代码现状
2. **方案**：进 plan mode，给出实现方案、边界情况、风险
3. **确认公约**：检查 CLAUDE.md 是否有相关规则要遵守
4. **拆块构建**：把改动拆成自包含小块，每块改完给我看 diff
5. **Hooks 已挂**：确认格式化/测试 Hook 在位（不需要每次重挂）
6. **测试证明**：跑测试，全绿才算完
7. **审查**：派 review 子代理独立读改动，列出问题
8. **闭环**：修问题 → 重测 → 重审，直到干净
9. **交付**：git add 相关文件，准备 commit message

写好之后，每次只要打：

/ship 给 auth 模块加上 token 自动刷新

整条流水线就启动了。配一次，以后每个任务自动走这条线——这才是 9 步循环的真正威力。

流水线全景图

把 9 步串起来看，就是一条从「需求」到「交付」的流水线：

需求
  │
  ▼
[1] 探索 ──── Explore 子代理摸清现状
  │
  ▼
[2] 方案 ──── Plan 模式，先想后做
  │
  ▼
[3] 公约 ──── 规则写进 CLAUDE.md（配一次）
  │
  ▼
[4] 拆块 ──── 自包含小块，逐块审查
  │           │
  │           ▼
  │      [5] Hooks ── 强制规则（配一次）
  │           │
  │           ▼
  │      [6] 测试 ── 跑通才算完
  │           │
  │           ▼
  │      [7] 审查 ── 第二代理挑刺
  │           │
  │           ▼
  │      [8] 闭环 ── 修复→重测→重审
  │           │
  └───────────┘  （干净才出）
  │
  ▼
[9] /ship ──── 整条线打包成一条命令
  │
  ▼
交付

注意 [3] 和 [5] 是「配一次」的——CLAUDE.md 和 Hooks 写好之后，后续任务不用重配，自动生效。这就是「流水线」的意义：前期投入固定成本，后期每个任务都享受红利。

为什么这套循环有效

回头看这 9 步，每一步都在解决一个具体的失败模式：

步骤	防的是什么失败
1 探索	闭眼开枪，踩隐藏依赖
2 方案	边想边做，做到一半发现方向错
3 公约	每次重新交代规范，遗漏
4 拆块	一把梭，无法审查无法回退
5 Hooks	公约靠自觉，偶尔被忽略
6 测试	「应该没问题」的主观判断
7 审查	自审盲点，自己看不见自己的错
8 闭环	「差不多行了」就收工
9 打包	每次手动跑 8 步，太累坚持不下去

最后一条尤其重要——9 步如果不打包成命令，你坚持不了三周。/ship 把流程固化下来，让纪律不依赖意志力，这是流水线能长期跑下去的关键。

一句话总结

9 步循环是给 AI 写代码装上流水线：先探索再方案、公约写进 CLAUDE.md、拆小块构建、Hooks 强制规则、测试证明管用、第二代理审查、闭环修复到干净、/ship 一条命令打包。区别不在模型，在模型外面这套循环——配一次，每个任务都自动走。

下一步，去看 Plan First 原则——第 2 步「先想后做」的深度拆解。🚀