AI Spark 知识库

外观

计划驱动开发 ​

对任何非简单的任务使用 /plan 模式。Claude 以只读方式探索代码库，然后提出实现计划供你审批。

目录 ​

  1. TL;DR
  2. /plan 工作流
  3. 适用场景
  4. 计划文件结构
  5. 与其他工作流集成
  6. 技巧
  7. 进阶：自定义 Markdown 计划（Boris Tane 模式）
  8. 延伸阅读

TL;DR ​

Plain
1. 进入计划模式（按两次 Shift+Tab）或提出复杂问题
2. Claude 以只读方式探索代码库
3. Claude 将计划写入 .claude/plans/
4. 你审查并批准
5. Claude 执行

/plan 工作流 ​

第一步：进入计划模式 ​

使用 Shift+Tab 切换计划模式（按两次循环：普通 → 自动接受 → 计划）：

Plain
# 按两次 Shift+Tab 进入计划模式
# （UI 中会显示计划模式指示器）

或提出自动触发计划模式的复杂问题：

Plain
我应该如何重构认证系统以支持 OAuth？

第二步：Claude 探索 ​

在计划模式下，Claude：

  • 读取相关文件
  • 搜索模式
  • 理解现有架构
  • 不能进行任何修改

第三步：Claude 编写计划 ​

Claude 在 .claude/plans/[name].md 创建计划文件：

Markdown
# 计划：为 OAuth 重构认证

## 摘要
在保持现有邮箱/密码认证的同时添加 OAuth 支持。

## 需修改的文件
- src/auth/providers/index.ts（添加 OAuth 提供商）
- src/auth/middleware.ts（处理 OAuth Token）
- src/config/auth.ts（OAuth 配置）

## 需创建的文件
- src/auth/providers/oauth.ts
- src/auth/providers/google.ts

## 实现步骤
1. 创建 OAuth 提供商接口
2. 实现 Google OAuth 提供商
3. 更新中间件以检测 Token 类型
4. 添加 OAuth 路由
5. 更新配置 schema

## 风险
- 迁移期间破坏现有会话
- 不同提供商间的 Token 格式差异

第四步：你审查 ​

审查计划的：

  • 完整性（所有需求均已覆盖）
  • 正确性（适合你的代码库的方法）
  • 范围（未过度工程化）

第五步：批准并执行 ​

Plain
看起来不错。按计划执行。

或请求修改：

Plain
修改计划：同时添加 GitHub OAuth 支持，不仅仅是 Google。

适用场景 ​

使用计划模式 ​

场景原因
多文件修改提前查看所有受影响的文件
架构变更在编码前验证方法
新功能确保实现完整
陌生代码库让 Claude 先探索
高风险操作执行前先审查

跳过计划模式 ​

场景原因
单行修复明显，低风险
拼写错误更正无需规划
简单问答探索性质，非实现
添加注释微小改动

计划文件结构 ​

计划存储在 .claude/plans/ 中，文件名自动生成。

典型的计划章节 ​

Markdown
# 计划：[标题]

## 摘要
[1-2 句概述]

## 背景
[为何需要此变更]

## 需修改的文件
[将发生变更的现有文件列表]

## 需创建的文件
[新文件列表]

## 需删除的文件
[待删除文件列表（如有）]

## 实现步骤
[有序步骤列表]

## 测试策略
[如何验证变更]

## 风险与应对
[可能出错的地方及应对方式]

## 待确认事项
[执行前需澄清的问题]

与其他工作流集成 ​

计划 + TDD（测试驱动开发） ​

Plain
# 进入计划模式（按两次 Shift+Tab），然后：

我需要实现一个限流器。
先规划测试用例，再规划实现。

Claude 会按正确的 TDD（测试驱动开发）顺序规划测试和实现。

计划 + 规格优先 ​

Plain
# 进入计划模式（按两次 Shift+Tab），然后：

查看 CLAUDE.md 中的支付处理规格。
创建一个满足所有验收标准的实现计划。

计划 + 任务工具 ​

计划批准后，Claude 可以拆解为任务：

Plain
已批准。从这个计划创建任务并开始实现。

技巧 ​

明确说明范围 ​

Plain
# 太模糊（进入计划模式后通过按两次 Shift+Tab）
改进 API

# 更好
为 /users 端点添加基于游标的分页。
保持与现有客户端的向后兼容性。

请求修改计划 ​

Plain
计划看起来不错，但：
- 添加网络失败的错误处理
- 暂时跳过缓存优化
- 包含回滚程序

用于架构决策 ​

Plain
# 进入计划模式（按两次 Shift+Tab），然后：

我正在考虑两种状态管理方案：
A) Redux Toolkit
B) Zustand

探索代码库并推荐哪个更适合。

保存计划作为文档 ​

.claude/plans/ 中的计划作为决策文档：

  • 为何选择某些方法
  • 预期发生变化的文件
  • 实现顺序的理由

进阶：自定义 Markdown 计划（Boris Tane 模式） ​

来源：Boris Tane，Cloudflare 工程负责人——"我如何使用 Claude Code"（2026 年 2 月）。9 个月的生产使用经验。

当计划模式不够用时，在编写任何代码之前进行迭代式人机协作规划。

为何选择自定义计划而非 /plan ​

因素计划模式（原生）自定义 .md 计划
持久性上下文压缩时丢失在压缩中存活，可共享
审查面基于聊天，线性结构化文件，可 diff
迭代对话中来回在文件上标注，重新运行
共享状态每会话独立人机之间的「共享可变状态」
最适合标准功能，<30 分钟任务复杂功能，架构决策

决策规则：已知范围的任务使用计划模式（按两次 Shift+Tab）。预期会有误解或希望在写一行代码之前明确签署方法时，使用自定义 .md 计划。

三阶段工作流 ​

Plain
┌─────────────────────────────────────────────────────────────────┐
│  阶段 1：研究                                                   │
│  → 强调性提示 → research.md（书面，非口头）                     │
├─────────────────────────────────────────────────────────────────┤
│  阶段 2：规划（标注循环）                                       │
│  → plan.md 草稿 → 人工标注 → 智能体更新 → 重复                 │
│  → 退出：计划获批，无未解决问题                                 │
├─────────────────────────────────────────────────────────────────┤
│  阶段 3：实现                                                   │
│  → 机械执行，决策已定                                           │
└─────────────────────────────────────────────────────────────────┘

阶段 1：强调性研究 ​

Claude 在没有强力信号时会浅尝辄止。使用强调性语言强制深度：

Plain
深度研究这个代码库中的认证系统。
详细了解会话管理的内部机制。
涵盖边缘情况、现有模式和任何非显而易见的依赖。

将你的发现写入 research.md——不要实现任何东西。

为何有效：「深度」、「详细」、「内部机制」将 Claude 从表面扫描转向深入调查。输出必须写入文件——口头摘要在上下文压缩时会消失。

Research.md 应包含：

  • 现有模式和约定
  • 文件路径和关键函数
  • 非显而易见的依赖
  • 已识别的约束和风险

阶段 2：标注循环 ​

Boris Tane 模式的核心。在 plan.md 上迭代，直到准备就绪，在任何实现之前。

Plain
┌──────────────────────────────────────────────────────────────┐
│                      标注循环                                 │
│                                                              │
│  人工提示 ──→ 智能体写 plan.md                               │
│       ↑                    ↓                                 │
│  标注计划         人工审查 plan.md                           │
│  （添加注释，              ↓                                 │
│   提问，           发现问题？                                │
│   标记权衡）              ├─ 是 → 标注 → 循环              │
│                           └─ 否 → 批准 → 阶段 3             │
│                                                              │
│  典型：批准前 1-6 次迭代                                     │
└──────────────────────────────────────────────────────────────┘

守卫提示——始终包含以防止过早实现：

Plain
基于 research.md，编写实现 [功能] 的计划。

包含：方法、受影响的文件路径、关键决策的代码片段、
已考虑的权衡和未解决的问题。

写入 plan.md。暂不实现任何内容。

plan.md 应包含的内容：

Markdown
# 计划：[功能名称]

## 方法
[策略和理由]

## 受影响的文件
- path/to/file.ts — 变更内容和原因
- path/to/other.ts — 变更内容和原因

## 关键实现细节
[非显而易见部分的代码片段——非完整实现]

## 权衡
- 选项 A vs B：因 X 选择 A
- 已考虑但拒绝：Y（原因）

## 待确认问题
- [ ] 我们应该处理边缘情况 Z 吗？
- [ ] 这会影响移动端客户端吗？

标注示例：

Markdown
## 方法
使用存储在 httpOnly cookie 中的 JWT Token。
<!-- 人工标注：✓ 同意。但也考虑刷新 Token 轮换 -->

## 待确认问题
- [ ] 我们应该在中间件中处理 Token 过期吗？
<!-- 人工标注：是，集中处理——不要留给每个路由 -->

退出标准——计划准备就绪的条件：

  • 无未解决问题
  • 权衡已记录并达成一致
  • 文件路径具体（非「某个认证文件」）
  • 关键片段展示方法，而非仅描述

「Markdown 文件充当你和智能体之间的共享可变状态。」——Boris Tane

阶段 3：机械实现 ​

计划批准后，实现变成执行——无需做出创意决策。

Plain
实现 plan.md 中的所有内容。
按顺序逐项处理。
完成后用 [x] 标记任务。
不要在任务之间停下来寻求确认——继续直到完成。

实现期间的反馈：

  • 保持简洁：短语或截图，非大段文字
  • 决策已定——将范围变更重定向回 plan.md
  • 若出现意外情况：暂停，更新 plan.md，继续

心态转变：阶段 3 是机械执行。所有思考在阶段 2 完成。

互补技术 ​

技术内容适用时机
精选实现实现 plan.md 的子集计划过大，逐步交付
范围裁剪实现前从计划中移除项目降低风险，专注核心
参考引导指向现有代码：「按照 auth.ts 的方式做」强制一致性
回滚并重新定范围git revert + 以更窄的计划重新开始计划出错，干净重置

延伸阅读 ​

  • 「exploration-workflow.md」 — 规划前先探索替代方案
  • 「../ultimate-guide.md」 — 第 2.3 节 计划模式
  • 「tdd-with-claude.md」 — 与 TDD（测试驱动开发）结合
  • 「spec-first.md」 — 与规格优先结合
  • 「iterative-refinement.md」 — 计划后迭代优化
  • 「task-management.md」 — 使用 Tasks API 跨会话追踪计划执行
  • 「dual-instance-planning.md」 — 进阶：使用两个 Claude 实例（规划者 + 执行者）进行质量导向工作流

来源：飞书 · AI Spark 知识库 ｜ 原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/Peu9w9KMRipIahkDfJwciriCnhc ｜ 归档：2026-06-04