Explore-Plan-Code 工作流

用 Claude Code 的 Explore-Plan-Code 工作流先理解代码库，再审查计划、分步实现、验证结果，减少任务偏移。

Explore-Plan-Code 适合大多数非简单开发任务。它把探索、规划、实现和验证拆开，避免 Claude Code 在还没理解项目之前就开始编辑文件。

快速结论

当任务涉及多个文件、不熟悉模块，或认证、计费、数据库、部署、MCP、共享架构等高风险区域时，优先使用 Explore-Plan-Code。

阶段	核心问题	是否应该编辑文件
Explore	当前系统是什么样？	不编辑
Plan	最小安全改动是什么？	不编辑
Code	已批准的哪一步要实现？	只做窄范围编辑
Verify	项目是否证明改动有效？	只修相关失败
Handoff	改了什么，还剩什么风险？	不编辑

阶段 1：Explore

第一步是梳理相关文件和当前行为：

Find the files involved in user search. Explain the route, UI components, data fetching, server validation, tests, and risky assumptions. Do not edit files.

好的探索结果应该包含：

相关文件，以及为什么相关。
当前数据流。
应该沿用的现有约定。
可能验证这个区域的命令。
需要用户确认的未知点。

阶段 2：Plan

要求 Claude Code 输出可审查的计划，而不是一句泛泛的“我会实现”：

/plan Based on the file map, propose the smallest safe plan to add user search. Include affected files, implementation order, tests, rollback steps, and open questions.

进入 Plan Mode 通常有四种方式：

入口	适合场景
`Shift+Tab`	在当前 CLI 会话里切到 Plan Mode，避免继续编辑。
`/plan`	让当前这一条提示只做规划，特别适合 Explore 之后使用。
CLI 启动参数	用 `claude --permission-mode plan` 开启高风险任务。
项目默认配置	在谨慎项目中把 `permissions.defaultMode` 设为 `plan`。

一个好计划应该包含：

部分	应该看到什么
范围	会改什么，不会改什么。
步骤	按顺序拆成小的实施单元。
测试	明确命令或手工检查。
风险	数据、认证、性能、兼容性或体验风险。
回滚	改坏后如何安全撤回。

当 Claude Code 给出计划后，把“批准计划”理解成一次模式切换。批准后会退出 Plan Mode，并按你选择的方式进入实现阶段，例如 auto、accept edits 或逐步手动审批。如果计划太大，应该继续给反馈让它改计划，而不是直接批准。

阶段 3：Code

一次只批准一步：

Implement step 1 only. Keep the diff small. Do not touch the UI yet. After editing, show the changed files and run the relevant test command.

实现阶段保持窄范围：

每次只批准一个模块或一个步骤。
不做顺手重构。
除非计划明确说明，否则不新增依赖。
不做无关清理。
如果计划和代码现状不一致，暂停并回到 Plan。

阶段 4：Verify

让 Claude Code 使用项目自己的检查方式：

Run the existing tests for user search and the production build. If something fails, explain whether it is related before fixing it.

不同改动适合不同验证：

改动类型	有用检查
UI 组件	组件测试、本地浏览器预览、响应式检查。
API route	单元测试、集成测试、请求示例。
认证或支付	现有回归测试、手工流程、权限审查。
内容或文档	构建、路由状态、metadata、内部链接。
数据库	migration dry run、回滚计划、影响表审查。

阶段 5：Handoff

最后输出一段其他开发者可以接手的摘要：

Summarize changed files, behavior changes, validation results, and remaining risks. Keep it concise and include commands that were run.

长会话切换任务前，使用 /compact 或先写一段交接摘要。

常见错误

错误	修正方式
一开始就说“帮我做这个功能”	先要求文件地图和当前行为。
计划里没有测试	要求写出明确验证命令。
一次批准整个计划	每次只批准一个实施步骤。
Claude 顺手重构附近代码	重申范围，拒绝可选清理。
假设变化后仍继续执行	回到 Plan Mode，更新计划。

提示词模板

功能开发

Explore the current onboarding flow. Do not edit files. Return the relevant files, data flow, existing validation, and smallest safe path to add a company-name step.

Bug 修复

Reproduce the likely cause of this bug from the code. Do not edit files. Identify the affected files, root-cause hypothesis, and one minimal fix.

重构

/plan Analyze this refactor first. Separate behavior-preserving changes from behavior-changing changes, list tests, and propose rollback steps.

官方来源

下一步：测试驱动开发 - 把测试纳入验证阶段。