大需求先让它面试你产出 SPEC.md

你脑子里的需求有一堆没说出口的决策点:技术选型、边界情况、什么不做。与其等 Claude 猜错再返工,不如让它先“面试”你,把答案沉淀成一份带验收标准的 SPEC.md,确认后再动手。

一句话结论

结论大特性先发一条极简 prompt,让 Claude 用 AskUserQuestion 工具连环提问澄清需求,把完整规格写进 SPEC.md;你确认后开一个全新会话拿着 spec 实现。官方这是 best practices 的原生工作流:新会话上下文干净、只专注实现,而且你手里留有一份可对照验收的书面 spec。

做法步骤

发起面试。用下方 prompt(官方模板的中文版)替换掉方括号里的一句话描述。预期:Claude 开始用选择题/追问的方式问你技术实现、UI/UX、边界情况、风险与取舍——官方文档强调它会问到你“还没想到”的部分,这正是价值所在。
认真答,别糊弄。本站观点面试环节你多花十分钟,实现环节少返工几小时。拿不准的问题就答“由你推荐并说明理由”,让决策显式化。
审 SPEC.md。面试覆盖完后 Claude 写出 SPEC.md。官方好 spec 的标准:自足(点名涉及的文件与接口)、写明什么不做(out of scope)、以一个端到端的验证步骤收尾,证明特性真的能跑。官方原话方向:把 spec 磨精确,比盯着实现过程更划算。
确认后开新会话实现。官方spec 定稿后另起一个会话执行:干净的上下文完全聚焦实现。本站观点实现 prompt 直接引用 @SPEC.md,并要求按 spec 里的阶段逐段交付、每段跑完验收标准再进下一段。
复杂改动配合 plan mode。官方实现阶段可用 plan mode(Shift+Tab 切换,状态栏显示 plan mode on,或 claude --permission-mode plan 启动)先出实现计划、Ctrl+G 在编辑器里直接改计划,批准后才动代码。explore→plan→code 的完整节奏见 D5 · plan mode 课。
收尾对照 spec 验收。本站观点让一个没参与实现的 subagent 拿 SPEC.md 对照 diff 挑差距(做法见对抗式 review),验证手段本身怎么设计见给它能自己跑的验证。

可直接抄的 prompt

我想做[一句话描述需求]。请用 AskUserQuestion 工具详细“面试”我:
问技术实现、UI/UX、边界情况、隐患和取舍;不要问显而易见的问题,
专挖我可能没考虑到的难点。一直问到全部覆盖为止,然后把完整规格写入 SPEC.md,
必须包含:涉及的文件与接口、明确不做的范围(out of scope)、
分阶段的实现计划,以及每个阶段可执行的验收标准(跑什么命令、看到什么才算通过),
最后是一个端到端验证步骤。写完先给我确认,确认前不要改任何代码。

spec 确认后,在新会话里发:

按 @SPEC.md 实现第一阶段。完成后运行该阶段的验收标准并贴出结果,
全部通过再停下来等我确认,不要自行开始下一阶段。

来源与最后核实日期

官方Best practices — Let Claude interview you / Explore first, then plan, then code——面试 prompt 模板、SPEC.md、新会话执行、好 spec 标准,抓取于 2026-08-05。
官方Common workflows — Plan before editing——plan mode 的进入方式与审批流,抓取于 2026-08-05。
最后核实:2026-08-05 · volatility:low(方法论为主,仅 AskUserQuestion、plan mode 等名称绑定产品)。