AI Native 手册
产品篇

开发：先出计划，再写代码

Plan mode 出计划，你批准后再实现；大功能拆工单，长任务分会话，实现类子 agent 不并行

亲历产品阶段 · 开发更新于 2026-10-16

开发阶段的规矩只有一条：先出计划，你批准了，Claude 才动文件。计划存进 docs/plans/YYYY-MM-DD_<slug>-plan.md，和 spec 用同一个 slug。大功能先拆成工单；一个会话装不下就分会话；并行只用在互不相干的任务上。

产物人工关卡衡量指标
plan 文件、代码 diff、测试你批准计划：Plan mode 下批准之前，Claude 改不了文件首轮实现就能合并的比例；合并后的代码和 plan 还对不对得上

为什么

Playbook 把“Plan mode 作为默认起点”列为开发阶段的第一招：计划要写清改哪些文件、按什么顺序、用哪些测试证明；反复追问，直到一个没看过这段对话的工程师只读 plan 就能实现；批准后的计划提交进仓库，实现跑偏了就在同一个提交里更新 plan。

道理很朴素：改计划比改代码便宜得多。计划阶段发现方向错了，损失几分钟；代码写完才发现，损失的是一整轮实现和审查。

怎么做

用 Plan mode 出计划

按 Shift+Tab 在几种权限模式之间循环切换，状态栏出现 plan mode on 就进入了 Plan mode；也可以直接在一句提示前面加 /plan：

/plan 读 docs/specs/2026-10-16_monthly-export.md，出一份实现计划：改哪些文件、按什么顺序、每一步用什么测试证明

批准之前追问三个问题：这个改动可能弄坏什么？哪一步风险最大？你考虑过但没选的方案是什么？批准前可以按 Ctrl+G 在编辑器里直接改计划。批准后让 Claude 把计划存成 docs/plans/2026-10-16_monthly-export-plan.md 并提交。

想让项目默认从 Plan mode 开始，并让计划文件直接写进仓库，在项目的 .claude/settings.json 里设：

{
  "permissions": {
    "defaultMode": "plan"
  },
  "plansDirectory": "docs/plans"
}

plansDirectory 不设时，计划文件存在 ~/.claude/plans/，文件名随机生成；设了之后写进仓库的 docs/plans/，再按约定改名即可。

用 bypass 启动时，Plan mode 只是一句指令

官方文档写明：在可以使用 bypass 权限的交互式会话里，Plan mode 不再拦截修改，Claude 在计划阶段尝试的编辑和命令会直接执行。想让“批准之前不能改文件”真正生效，就别用 bypass 启动。

可选：让另一个模型审一遍计划

跨字段的不变量，比如“订单改成已退款时，金额和流水必须同时变”，在计划阶段就能抓到，比写完代码再审便宜得多。把计划交给另一个模型家族看一遍：

codex exec "审查 docs/plans/2026-10-16_monthly-export-plan.md：找出遗漏的边界情况和会被破坏的不变量，只报告问题，不要改文件"

为什么一定要换模型家族，见发布：AI 审查，人来批准。

按计划实现

/mattpocock-skills:implement 按 docs/plans/2026-10-16_monthly-export-plan.md 实现

implement 会在约定好的测试层用 tdd 一步步实现，过程中经常跑类型检查和单个测试文件，最后跑一次全量测试，再调用 code-review 审一遍，然后提交到当前分支。试用中

需要某个库的最新用法时，让 Claude 用 context7 查，不要凭记忆写。装好 context7@claude-plugins-official 之后，在提示里说一句“用 context7 查一下这个库最新的用法”即可。

大功能先拆工单

一个会话装不下的功能，用 to-tickets 拆成“曳光弹”式的竖切工单：每张工单都打通从数据到接口到界面再到测试的一条窄路径，能单独演示，大小正好装进一个新会话，并写明被哪些工单阻塞。

/mattpocock-skills:to-tickets docs/specs/2026-10-16_monthly-export.md

然后一张一张地 /mattpocock-skills:implement，每张之间用 /clear 清空上下文：工单本身是自包含的，上一张的上下文可以扔掉。试用中

还有两个更重的选项：

  • /mattpocock-skills:implement-spec：把整个 spec 的工单当成依赖图，让多个后台子 agent 在各自的 worktree 里并行实现，再合到一条集成分支。这和我“实现类子 agent 不并行”的经验相冲突，只有工单之间确实不碰同一批文件时，我才会考虑用它。
  • /mattpocock-skills:wayfinder：给一团迷雾的大工程用。它在 Issue 上维护一张决策地图，每个会话只解决一个决策，产出的是决定而不是代码；地图走清了，再回到 to-spec 和 to-tickets。

长任务：计划和执行分开会话

写计划会烧掉大量上下文。我做过一次几百个冲突的上游大合并，在同一个会话里写计划又执行，计划把上下文烧光了，执行阶段质量明显下降。现在的规则：冲突 30 个以上建议拆，50 个以上必须拆。计划写完、审完、提交后关掉会话，开新会话只读计划执行。

Matt 的说法可以作为一般任务的参照：模型推理保持敏锐的窗口大约 15 万 token（他称为 smart zone），接近了就在最近的阶段边界收口。三种收口方式：

  • 计划文件本身：plan 已经在 docs/plans/ 里，新会话只读它，这是最稳的
  • 内置开关：在设置里加 "showClearContextOnPlanAccept": true，批准计划时会多一个“批准并清空上下文”的选项，只带着计划开始实现
  • /mattpocock-skills:handoff：把当前会话压缩成一份交接文档，存在系统临时目录，不进仓库；文档里会写明下一个会话该调用哪些 skill

并行与子 agent

  • 互不相干的任务各开一个 worktree：claude -w export-csv、claude -w fix-rate-limit（-w 是 --worktree 的简写），每个会话在自己的分支上干活，不会互相改到同一份文件。也可以用 claude --bg 开后台会话，claude agents 查看进度。
  • 从两三个会话开始：Playbook 的建议是审查跟得上再加；改同一批文件的任务放在一个会话里顺序做。
  • 实现类子 agent 不并行，审查类可以：并行实现改到同一处代码，冲突处理的成本比省下的时间还多。
  • 子 agent 用最强的模型：有工程不变量的任务降级到小模型，单次看不出问题，累积起来不变量频繁被破坏，审查兜不住。只有批量重命名、移动文件这类纯机械的任务例外。

派子 agent 时，提示词里必须自带这几样：任务原文（不要让它自己去读计划）、绝对路径的工作目录、CRITICAL do-not 段（禁止 reset、rebase、force push、amend、在有未提交改动时切分支）、关键约束的原文摘录、回报格式、自查清单。模板见子 agent 提示词模板。

常见坑

相关

设计：从 intent 到 spec

一次会话里把 intent 拷问成可以开工的 spec，顺手留下术语表和 ADR；spec 以仓库里的文件为准

测试：让 Claude 能自己验证

给 agent 一条能自己跑的反馈回路：一条命令验证、先写失败的测试、UI 改动亲眼看到，用证据判断完成

本页目录

为什么怎么做用 Plan mode 出计划可选：让另一个模型审一遍计划按计划实现大功能先拆工单长任务：计划和执行分开会话并行与子 agent常见坑相关