Claude Code 先审计划再改代码的实用指南

Claude Code 最贵的失误，可能是它很快做出了一个错误决定：代码能跑，改动也合理，却解决了另一个问题。作者用 Plan Mode 给这种偏航加了一道检查：先读代码、列出改法，等人确认后再执行。

这套方法适合跨文件重构、陌生仓库和迁移任务，但不值得用于每个小改动。更需要看清的是，Plan Mode 属于工作流程，不能直接当作安全沙箱。原文称已于 2026 年 10 月 27 日核对官方文档，具体行为仍要结合运行环境和权限配置理解。

什么时候值得先花几分钟审计划

作者开头描述了一种代价：Agent 花约 4 秒选定方案，20 分钟后交出涉及 12 个文件的 diff，开发者才发现方向偏了。这是经验描述，不是耗时实验，但问题很典型：检查一份实现的成本，往往高于检查一个决定。

Plan Mode 把任务分成调查和执行两个阶段。调查时，Claude 可以读取文件、搜索代码、运行探索命令、提问和写计划；审批后，再按所选权限执行。已有的 CLAUDE.md、工具和会话历史仍然生效。

第一步走错的代价越高，计划越值得提前审。

作者建议用于跨多个文件的重构、跨模块重命名、数据库迁移、公共 API 调整，以及带破坏性变更的依赖升级。刚接手的仓库也适合：先看 Claude 如何解释结构，能帮助判断它是否读懂了代码。需要交接或评审的工作，则多了一份可放进 PR 描述的材料。

反过来，错别字、常量修改、给类型补字段、快速问答，以及十分钟后就会删除的实验，通常可以跳过。作者还给出一个实用信号：小任务已经改了三轮计划，可能该缩小任务，而不是继续完善计划。

一份可审批的计划，要写到文件和约束

进入 Plan Mode 可以用 /plan、claude --permission-mode plan，或按 Shift+Tab 切换。默认循环是 default、acceptEdits、plan；从 auto 出发时会先回到 default，因此应看状态栏。Windows 上若 Node 或 Bun 未启用 VT 输入模式，可用 Alt+M。

项目默认模式可在 .claude/settings.json 中把 permissions.defaultMode 设为 "plan"。VS Code 的起始模式不读取这个项目设置，要在用户设置中配置 claudeCode.initialPermissionMode。作者只建议陌生仓库默认开启，否则修个错字也要经过规划。

真正影响计划质量的，是任务描述。下面这段示例提前约束了 Redis 复用、鉴权行为和文件范围，/plan 必须位于消息开头：

/plan Add per-user rate limiting to the API. Use the existing Redis client.
Do not change the auth middleware's public behavior. Show me which files
you would touch before touching any.

重点看第二行：鉴权中间件的公共行为属于必须守住的边界，不能留给模型自行推断。

作者随后给出的计划包含具体落点：新增 src/middleware/rateLimit.ts，复用 src/lib/redis.ts；按 req.user.id 限流，未认证请求回退到 IP；在 src/app.ts 的鉴权之后注册；在 src/middleware/rateLimit.test.ts 覆盖触限、重置和无用户场景；最后在 README.md 记录环境变量。

这只是一个接近真实任务的示例，原文没有提供对应仓库或测试结果。它展示的价值在于：文件、顺序、原因和边界都能被逐项检查。相比「更新相关中间件」，这样的计划更容易暴露误解。

审计划时，可以追问哪些文件没读、哪一步风险最高、匿名路由怎么办。方向不对就选 No, keep planning。小修正可以按 Ctrl+G，在默认编辑器里直接删除步骤、调整顺序或补约束，保存并关闭后让 Claude 使用修改后的版本。

计划默认保存在 ~/.claude/plans/，也可通过 plansDirectory 改到项目目录，方便团队查看和版本管理。

审批通过后，权限究竟怎么变

审批菜单决定后续执行方式。Yes, and use auto mode 会进入由分类器审核操作的 auto mode；会话不支持时，显示为 Yes, auto-accept edits instead。Yes, manually approve edits 则保留逐次编辑审批。

若会话启用了 bypass permissions，首项会变成切换至 BYPASS PERMISSIONS，后续不再提示，效果对应 --dangerously-skip-permissions。按 Enter 前，需要读清菜单。

开启 showClearContextOnPlanAccept 后，还会增加批准并清空规划上下文的选项。长时间调查留下的死路和旧假设，可能干扰执行；清理后从获批计划开始，有助于减少这些干扰。不过，执行需要的约束也应写进计划。

更容易误解的是规划阶段的命令权限。原文按优先级列出三种情况：

• 交互式终端中若 bypass permissions 可用，规划操作不经过分类器或常规提示；显式 ask 规则和关键路径的 rm 删除仍会提示。
• 若 auto mode 可用，且 useAutoModeDuringPlan 开启，shell 命令由分类器审核；该设置默认开启。
• 若 auto mode 不可用，或关闭上述设置，超出内置只读集合的命令需要审批。

因此，git log、ls 等探索操作能运行，不代表任何 shell 命令都天然只读。尤其在原文描述的交互式 bypass 条件下，禁止编辑的限制不会强制执行，模型仍被要求只规划，但尝试的操作可能直接运行。

Plan Mode 是审批工作流，不是安全边界。

原文称，非交互式 claude -p、Agent SDK 会话和 VS Code 聊天面板仍保留规划限制。脚本或 CI 可以这样请求一次迁移分析：

claude -p --permission-mode plan "Plan how to migrate the users table to UUID primary keys"

关键是 -p --permission-mode plan 的组合：原文将它定位为一次性产出计划，未描述交互审批后继续执行的流程。

我的判断

作者最有价值的建议，是把「读懂需求」变成可审查的产物。普通模式里说一句「先写计划，不要改代码」，缺少明确的审批菜单和编辑工具限制；在支持限制的环境里，Plan Mode 更适合承担正式检查点。

但计划写得具体，不代表实现正确。Express 示例里的匿名请求回退到 IP，就是一个需要业务确认的选择；文件路径齐全，也不能替代测试与 diff 审查。

作者认为，规划增加的几分钟和 token，能通过减少返工赚回来，但没有给出对照数据。收益多大，仍是经验之谈。他还关联了一篇涉及 32,784 行的工作流文章，原文没有展开证据，不能据此证明大型任务的普遍效果。

opusplan 通过 /model 选择，规划时使用 Opus，执行时切换到 Sonnet。这个分工有道理，但「执行大多机械」有前提：计划足够完整，代码没有暴露新问题。原文没有给出成本或质量对比。

大型调查还可使用内置 Plan subagent，其 Write、Edit 被禁用；自定义 subagents 也能分担研究、减少主会话上下文占用。它们改善了组织方式，但读者仍需验证调查结论。

能拿来做什么

• 对跨组件、跨模块的前端重构，先用 /plan 写清目标、公共 API 约束和文件范围，再检查方案是否触及不该改的调用方。
• 给 Express 或其他 Node 服务增加中间件时，要求计划说明注册顺序、身份信息来源和异常分支，把业务选择提前拿出来确认。
• 在脚本或 CI 中使用 claude -p --permission-mode plan 生成迁移建议，将其作为待审材料；原文未描述这种调用自动进入审批执行阶段。
• 小任务直接修改；计划越来越大时先切小范围。执行若仍偏航，可考虑清理规划上下文或使用 /compact；发生意外编辑时，原文建议用两次 Esc 或 /rewind 撤回，并检查 bypass 配置。