基于 Anthropic 内部最佳实践（Boris 分享）+ 个人实操总结的可执行操作手册。核心理念：头脑风暴 → 计划 → 执行，前期功夫占最大分量。底层逻辑见 [[AI协同开发的第一性原理]]

总览：三阶段工作流

模糊想法
  │
  ▼
┌─────────────────────────────────────────────┐
│  第一阶段：头脑风暴（该不该做？做什么？）        │
│  ├─ 关卡1：问题审视（这个想法在解决什么？）     │
│  ├─ 关卡2：最小可行性验证（技术上做得到吗？）   │
│  └─ 关卡3：方案比较 + 预验尸（用哪种方案？）    │
│                                               │
│  ⚠️ 占总精力 30-40%（最容易被跳过，也最值钱）   │
└──────────────────────┬──────────────────────┘
                       │ 三个关卡全部通过
                       ▼
┌─────────────────────────────────────────────┐
│  第二阶段：计划（怎么做？）                     │
│  ├─ Plan 模式出详细方案                        │
│  ├─ 创建/更新项目 CLAUDE.md                    │
│  └─ 规划测试场景                               │
│                                               │
│  占总精力 20%                                  │
└──────────────────────┬──────────────────────┘
                       │ 计划审查通过
                       ▼
┌─────────────────────────────────────────────┐
│  第三阶段：执行（动手做）                       │
│  ├─ 并行 worktree 工作流                      │
│  ├─ 建立测试 → 自动修 bug                     │
│  └─ 子代理分流                                │
│                                               │
│  占总精力 40-50%                               │
└─────────────────────────────────────────────┘

大部分人的精力分配是 5% / 10% / 85%。这就是做到后面越偏越远的根本原因——计划建立在未经验证的假设上，执行得越好偏得越远。

第一阶段：头脑风暴（该不该做？做什么？）

Boris 的9条建议全都是"怎么高效造东西"（Delivery）。但如果你造的是错误的东西，效率越高浪费越大。头脑风暴阶段解决的是"该不该造"和"造什么"。

这个阶段是整个流程中最容易被跳过、也最值钱的环节。 正式团队里，这对应的是产品经理、技术负责人、设计师坐在一起讨论的环节。一个人开发时，你可以用 Claude 模拟不同角色来获得多视角的碰撞。

多角色模拟（一个人的 team）

在头脑风暴阶段，不要只用一种视角和 Claude 对话。你可以在不同关卡中让 Claude 扮演不同角色：

角色	在哪个关卡使用	它会关注什么
产品经理	关卡1 问题审视	用户需求真不真实？市场上有没有替代品？
技术负责人	关卡2 可行性验证	技术风险在哪？架构怎么选？
魔鬼代言人	关卡3 预验尸	这个方案会怎么死？最坏情况是什么？

具体用法——在每个关卡的 prompt 前加角色设定：

你现在是一个经验丰富的产品经理。
不要从技术角度思考，从用户需求和市场角度审视我的想法。

或者更高效的方式——让 Claude 一次性从多个角色输出意见：

分别从以下三个角色的视角评估我的项目想法：
1. 产品经理：需求是否真实？用户画像清不清晰？
2. 技术负责人：技术风险在哪？有没有更简单的实现方式？
3. 投资人/魔鬼代言人：这个项目会怎么失败？最大的坑是什么？

每个角色独立给出观点，如果三个角色之间有分歧，指出来。

关卡1：问题审视

在你写任何代码之前，开一个 Claude 对话，纯聊，不写代码：

我有一个项目想法：[你的想法]

不要帮我规划怎么实现。先帮我审视这个想法本身：
1. 这个想法到底在解决什么问题？把问题用一句话说清楚。
2. 这个问题真的存在吗？有没有可能是我臆想的？
3. 现有的解决方案是什么？我的方案比它们好在哪里？
4. 如果这个项目做成了，最核心的一个功能是什么？只能选一个。
5. 谁会用这个？为什么他们会用我的而不是现有的？

挑战我的每一个回答，不要附和。

通过标准：你能说出一句话——“这个项目要解决的核心问题是X，给Y人群用，核心功能是Z。”

没通过：说不清楚，或者被 Claude 问到自相矛盾 → 想法不成熟，继续聊或者先放一放。

关卡2：最小可行性验证

不做完整原型，只验证技术风险最高的那一个点——“如果这个做不到，整个项目就不成立"的关键点。

我想做 [核心功能Z]。

不要做完整方案。帮我找出这个功能中技术风险最高的一个环节。
就是那个"如果这个做不到，整个项目就不成立"的关键点。

然后用最少的代码写一个概念验证（proof of concept），只验证这一个点。
不需要 UI，不需要完整流程，不需要错误处理。
能跑起来证明"技术上做得到"就够了。

举例：做城市数据聚合工具 → 技术风险最高的是"目标网站能不能被稳定抓取” → 写50行脚本验证 → 能抓到就继续，抓不到就换方向。代价只是半小时，而不是做了两周后才发现。

通过标准：概念验证跑通了，技术上可行。

没通过：关键技术点做不到 → 换方向或换技术方案，在这里止损代价最小。

关卡3：方案比较 + 预验尸

确认了"该做"和"做得到"之后，找最优方案。最优解不是想出来的，是比较出来的。

第一步：要求3个根本思路不同的方案

我要实现 [核心功能Z]。

给我3个完全不同思路的方案。不是细节不同，是根本思路不同。
每个方案用3句话描述：
1. 核心思路是什么
2. 最大的优势是什么
3. 最大的风险是什么

然后告诉我：如果你只能选一个，你选哪个？为什么？

第二步：对推荐方案做预验尸

对你推荐的方案，做一次预验尸（pre-mortem）：
假设这个方案6个月后彻底失败了。
最可能的3个失败原因是什么？
每个失败原因有没有提前预防的办法？

通过标准：预验尸的失败原因你能接受（有预防手段或概率低）。

没通过：预验尸暴露了致命风险 → 换方案，重新走关卡3。

技术选型（三关卡通过后）

AI 能帮你做什么

技术选型的信息收集和利弊分析是 AI 的强项。关键是给出你的具体约束，而不是问"什么框架最好"：

我确认了要做的项目：[一句话描述]

我的约束条件：
- 一个人开发
- 熟悉的语言/框架：[xxx]
- 不熟悉但愿意学的：[xxx]
- 预算：[免费/有限/不限]
- 项目类型：[工具/网站/API/爬虫...]

基于这些约束：
1. 推荐一个最适合的技术栈组合（不要推荐最流行的，推荐对我最合适的）
2. 推荐一个开发工具组合（IDE/AI工具/部署方式）
3. 特别说明：哪些"流行选择"我应该避免？为什么对我不合适？

第3点最有价值——让 AI 帮你排除不适合的选项，比让它选"最好的"更靠谱。“最好的"取决于上下文，但"明显不适合你的"可以客观判断。

AI 帮不了什么

“最佳工具流程"不存在。 别人的工具组合是他们在自己的约束条件下试出来的：

某人的"Opus → Codex → Sonnet"编排模式，前提是每天烧上千美金 + 做了大量项目后总结
某人的3套前端设计方案，前提是他做的是重前端产品
照搬别人的流程大概率翻车——因为你的预算、技术背景、项目类型都不同

工具策略：先用透一个，再加

当前阶段只用 Claude Code 一个工具就够。原因：

你还在建立基本习惯（Plan模式、CLAUDE.md、测试）
多模型编排的前提是你能判断"什么任务适合什么模型”——这需要实践积累
等你用 Claude Code 完整做完2-3个项目后，你自然会发现它哪些环节不够好——那时再加 Codex 或 Cursor 补短板，才是有的放矢

没有人一开始就知道最优工具组合，都是做了足够多项目后总结出来的。

第二阶段：计划（怎么做？）

通过三个关卡后，你已经知道做什么、技术可行、用哪种方案。现在才进入 Boris 说的"复杂任务先做计划”。

Plan 模式

硬规则：什么时候必须用 Plan

改动涉及 3 个以上文件 → 必须先 Plan。

这个标准不需要思考，机械执行就行。3 个文件以上意味着有跨模块依赖，Claude 没有计划就容易顾此失彼。

具体操作

第一步：进入 Plan 模式

先不要写代码。进入计划模式。

我要实现 [功能]。
背景：[为什么需要]
约束：[技术限制]
验收标准：
- [标准1]
- [标准2]

帮我规划完整的实现方案。

第二步：审查计划

Claude 输出计划后，检查：它理解的需求和你想的是否一致？文件拆分是否合理？有没有遗漏？

第三步：用"批判者"角色二次审查

现在以资深工程师的视角严厉审查这个计划。
找出：
1. 遗漏的边界情况
2. 可能翻车的环节
3. 架构上的隐患
不要客气，直接指出问题。

第四步：确认后执行

计划确认，开始实现。按计划中的步骤顺序执行，每完成一个步骤告诉我。

高级用法：双 Claude 审查（配合 worktree）

任务特别重要时：

主 worktree Claude 写计划
把计划复制到副 worktree Claude：“以幕僚工程师身份审查这个计划，找出漏洞”
把审查意见带回主线修改
修改后再执行

跑偏时的应急操作

停。当前方向不对。
切回计划模式，基于目前已经实现的部分，重新规划剩余工作。
不要硬推当前方案。

沉没成本谬误在 AI 开发中同样存在。已经写了一半的错误代码不值得继续。

项目级 CLAUDE.md

为什么重要

CLAUDE.md 是你和 AI 之间的契约文档。新会话能在 30 秒内理解项目上下文、编码风格和雷区。它也是你能积累的少数不会被模型升级冲掉的资产。

创建模板

在项目根目录创建 CLAUDE.md，从 4 块开始：

# 项目名称

## 项目概述
[一两句话说明这是什么、解决什么问题]
技术栈：[框架、语言、数据库、部署方式]

## 文件结构约定
- `src/components/` — React 组件
- `src/api/` — API 路由
[根据你的项目实际情况填写]

## 编码规则
- 状态管理使用 [xxx]
- API 调用统一通过 [xxx] 封装
[你项目中的其他约定]

## 踩过的坑（持续更新）
[最初为空，随使用逐渐积累]

每块 2-3 行就够。关键是先有这个文件。

纠错即更新

每次纠正 Claude 的错误后追加：

把这次错误的原因和正确做法，总结成一条简短的规则，
追加到项目根目录的 CLAUDE.md 的"踩过的坑"部分。

每周 Review

每周 5 分钟看一遍：删过时的、合并重复的、把高频规则移到显眼位置。也可以用 /reflection 命令让 Claude 帮你整理。

进阶：笔记目录模式

规则多了之后：

project/
├── CLAUDE.md              ← 核心规则 + 指向笔记目录
├── .claude-notes/
│   ├── api-conventions.md
│   ├── database-rules.md
│   └── common-mistakes.md

测试场景规划

测试在计划阶段规划场景，在执行阶段编写代码。

测试是什么？（从零理解）

你平时验证功能正不正常：打开页面手动操作看结果。测试代码就是把"手动点一遍"写成脚本让机器自动跑。

# 你的业务代码
def parse_city_info(raw_html):
    ...
    return {"name": "北京", "population": 21540000}

# 测试代码（机器自动跑）
def test_parse_city_info():
    html = "<div class='city'>北京</div>..."
    result = parse_city_info(html)
    assert result["name"] == "北京"          # 检查结果对不对
    assert result["population"] > 0          # 人口应该是正数

运行就一行命令：pytest（Python）或 npm test（Node.js）。输出：绿色全过 = 没问题，红色有失败 = 出 bug 了。

让 Claude 列测试场景（先列清单，不写代码）

分析这个项目，列出你认为最关键的 5-8 个测试场景。

用这个格式：
- 场景名称：[xxx]
- 测试什么：[用大白话描述]
- 如果这个坏了会怎样：[影响是什么]

先列清单，不要写测试代码。等我确认后再写。

你审查清单

你不需要看懂测试代码，只需要用业务直觉判断：

这些场景是不是我最怕出问题的地方？
有没有遗漏？有没有多余的？
判断标准：“如果这个功能坏了，我慌不慌？” 慌的就该测。

确认后：

场景确认。按这个清单写测试代码。写完后直接运行，确保全部通过。

第三阶段：执行（动手做）

通过发现和计划阶段后，你已经有：

明确的问题定义和核心功能（头脑风暴阶段产出）

经过验证的技术方案（头脑风暴阶段产出）

详细的实现计划（计划阶段产出）

确认好的测试场景（计划阶段产出）

现在才是 Boris 那些执行效率技巧发挥作用的时候。

并行 worktree 工作流

worktree 和普通分支的区别

普通分支 = 时间上的切换

git checkout -b feature-bugfix

整个项目目录只有一份。切分支时所有文件被替换成目标分支的状态。你在分支A跑着 Claude，想去分支B做另一件事——必须停下A的工作，stash 或 commit 当前改动，然后切过去。一次只能做一件事。

worktree = 空间上的并行

git worktree add -b feature-bugfix ../my-project-side

物理上多了一个目录，两个目录同时存在、各自独立。主目录跑 Claude 做功能开发，副目录同时跑另一个 Claude 修 bug——两件事并行，不需要 stash，不需要停下手头工作。

一句话总结：worktree 的核心价值不是给 git 用的，是给"同时开多个 Claude 会话"用的。如果你不需要并行跑多个 Claude，普通分支完全够用。

起步：2 个 worktree

主 worktree：当前主线任务，需要你深度参与
副 worktree：不需要你深度参与的任务——跑测试、自动修 bug、代码审查

创建 worktree：

# -b 创建新分支
git worktree add -b feature-bugfix ../my-project-side

# 基于特定分支创建
git worktree add -b feature-bugfix ../my-project-side main

# 分支已存在时不需要 -b
git worktree add ../my-project-side feature-bugfix

启动独立 Claude 会话：

# 新终端标签页
cd ../my-project-side
claude

给副线下任务：

分析这个项目中所有失败的测试，生成修复方案。
先出计划，等我确认后再执行。
执行完成后不要自动 commit，我需要先 review diff。

完成后清理：

git checkout main
git merge feature-bugfix
git worktree remove ../my-project-side

实用技巧

给终端标签页命名和颜色编码（Windows Terminal 右键标签页）
副线任务选择标准：不需要你实时决策的任务
稳定管理 2 个后再考虑加第三个（推荐做"只读分析"用途）

自动修复 bug

前提：有测试覆盖

没有测试就让 Claude 自动修 bug 等于赌博。 在计划阶段你已经规划了测试场景并让 Claude 写好了测试代码。

验证测试能跑通：

pytest                # 或 npm test

如果有测试失败，让 Claude 修复测试本身（不是修改业务代码去迁就测试）。

自动修 bug 模式

简单 bug（副 worktree 执行）：

这个 bug 的现象是：[描述]
复现步骤：[步骤]

修复这个 bug。修完后运行完整的测试套件确认没有引入新问题。
不要 commit，等我 review。

CI 失败：

去修复失败的 CI 测试。先分析失败原因，然后修复。
修复后重新运行测试确认全部通过。

关键原则：

每次修完 bug 都跑测试——这是你的安全网
给目标不给步骤——不要微观管理 Claude 怎么修
Claude 修两轮还没好 → 停下来自己看，可能有你没告诉它的上下文

子代理

解决什么问题

对话越长 Claude 表现越差——上下文被塞满，注意力被稀释。子代理在独立的干净上下文中执行子任务，结果汇报回来，主会话不被污染。

什么时候用子代理 vs 重开会话

情况	选择	原因
子任务与当前任务相关	子代理	需要主会话上下文
新任务与当前无关	重开会话	干净上下文更好
感觉 Claude 开始"变笨"	先试子代理，不行就重开	可能是上下文过长

使用方式

在 prompt 中加"使用子代理"或 “use subagents”：

使用子代理完成以下任务：
搜索整个代码库，找出所有直接操作 DOM 的地方，列出文件名和行号。

适合子代理的任务：搜索、分析依赖、独立重构、写测试 不适合的任务：需要反复沟通确认的、需要整个对话上下文的、跨模块架构决策

保持主会话干净

一个会话一个主题 — 完成就结束
探索性子任务甩给子代理
感觉质量下降就重开 — 不要舍不得当前上下文

贯穿全程的实践

以下实践不属于某个特定阶段，而是全程适用。

Prompt 技巧

场景匹配

场景	推荐风格
明确的小改动	简短指令型：“把按钮文案改成’确认'”
新功能开发	上下文丰富型（默认模式）：附带背景、约束、验收标准
技术选型/架构	对话协商型：先讨论方案再动手

四个杀手句式

1. 审查句式 — 拿到方案后用

以资深工程师的视角严厉审查这段代码/方案。
找出所有问题、隐患和可以改进的地方。
不要说"看起来不错"，我需要真实的批判。

2. 推翻重来句式 — 方案能跑但不够好时用

基于你现在掌握的所有信息，废弃当前方案。
重新实现一个更优雅的解决方案。解释为什么新方案更好。

3. 证明句式 — 验证正确性

向我证明这个改动是正确的。
对比改动前后的行为差异，用具体的输入输出说明。

4. 规格句式 — 开始任务前

我需要实现 [功能]。
背景：[为什么]
约束：[限制]
验收标准：
- [标准1]
- [标准2]
先出方案，不要直接写代码。

心态转变

❌ “帮我看看有没有问题” → Claude 倾向于说"看起来不错"
✅ “严厉审查，找出所有问题” → Claude 会认真找茬
❌ 拿到第一个能跑的方案就接受
✅ “废弃这个，给我更好的方案” → 第二个方案质量通常更高

语音输入

打字时你会下意识压缩信息（打字有成本），说话没有这个摩擦。语音输入直接解决"知道该写详细 prompt 但懒得打那么多字"的问题。

Windows：Win + H 启动语音输入

推荐场景：头脑风暴阶段和 Claude 聊想法、Plan 模式写初始 prompt、描述 bug 复现步骤

不推荐：写代码片段、简短指令

终端环境

多 worktree 时给标签页命名和颜色编码（Windows Terminal 右键标签页）
/statusline 自定义状态栏，显示上下文使用量和 git 分支
Ctrl + Shift + T 新建标签页

Skill 化（被动积累，不要急）

当前策略：被动收集重复操作，攒够再做。

建一个候选清单，每次发现自己在想"这个我上次也说过"时记一条：

# Skill 候选清单
| 日期 | 重复操作描述 | 出现次数 |
|------|------------|---------|

出现次数 ≥ 3 时，用 /cc:create-command 封装成命令。

用 Claude 学习

接手新代码库时：

使用子代理全面分析这个项目的架构。
用 ASCII 图表画出整体架构、数据流、依赖关系。

理解复杂逻辑时：

这个函数逻辑很复杂，我看不懂。
1. 用 ASCII 流程图画出执行流程
2. 逐块解释每一步在做什么、为什么
3. 标注容易出错的地方

数据分析：配置 MCP 或 CLI 后，让 Claude 直接查数据库跑分析。

完整决策树

📋 新项目/新功能
  │
  ├─ 第一阶段：头脑风暴
  │   ├─ 关卡1：问题审视 → 说清核心问题和功能
  │   ├─ 关卡2：最小验证 → 50行代码验证关键技术点
  │   └─ 关卡3：方案比较 → 3个方案 + 预验尸
  │       └─ 任一关卡没过？→ 止损，调整方向
  │
  ├─ 第二阶段：计划
  │   ├─ 创建/更新 CLAUDE.md
  │   ├─ Plan 模式出方案 → "资深工程师审查"
  │   └─ 规划测试场景 → 你审查场景清单
  │       └─ 跑偏了？→ 立刻切回计划模式
  │
  └─ 第三阶段：执行
      ├─ 主 worktree 做功能 + 副 worktree 做杂活
      ├─ 写测试代码 → 跑通 → 自动修 bug
      └─ 子任务 → 子代理 / 长了就重开会话

📋 修 Bug
  │
  ├─ 有测试？→ 副 worktree + "修复它，跑测试确认"
  └─ 没测试？→ 先让 Claude 写测试，再修 bug

📋 每次纠正 Claude 错误后
  │
  └─ "总结规则，更新 CLAUDE.md"

📋 感觉 Claude 变笨了
  │
  ├─ 子任务相关 → 子代理
  └─ 新话题 → 重开会话

总览：三阶段工作流#

第一阶段：头脑风暴（该不该做？做什么？）#

多角色模拟（一个人的 team）#

关卡1：问题审视#

关卡2：最小可行性验证#

关卡3：方案比较 + 预验尸#

技术选型（三关卡通过后）#

AI 能帮你做什么#

AI 帮不了什么#

工具策略：先用透一个，再加#

第二阶段：计划（怎么做？）#

Plan 模式#

硬规则：什么时候必须用 Plan#

具体操作#

高级用法：双 Claude 审查（配合 worktree）#

跑偏时的应急操作#

项目级 CLAUDE.md#

为什么重要#

创建模板#

纠错即更新#

每周 Review#

进阶：笔记目录模式#

测试场景规划#

测试是什么？（从零理解）#

让 Claude 列测试场景（先列清单，不写代码）#

你审查清单#

第三阶段：执行（动手做）#

并行 worktree 工作流#

worktree 和普通分支的区别#

起步：2 个 worktree#

实用技巧#

自动修复 bug#

前提：有测试覆盖#

自动修 bug 模式#

子代理#

解决什么问题#

什么时候用子代理 vs 重开会话#

使用方式#

保持主会话干净#

贯穿全程的实践#

Prompt 技巧#

场景匹配#

四个杀手句式#

心态转变#

语音输入#

终端环境#

Skill 化（被动积累，不要急）#

用 Claude 学习#

完整决策树#