主页
2026-08-04 · 新版式样例 · 模块 A「让 Claude Code 稳定交付」第一课
你肯定遇到过这个场景
你跟 Claude Code 说:「给我的游戏加一个每日签到系统,要有连续签到奖励」。它哗哗写了 20 分钟,你一看:UI 放错了页面、奖励数值是它自己编的、断签规则跟你想的完全不一样。你开始一轮轮地「不对,应该是……」,改到第五轮,代码已经被缝补得没法看了,还不如推倒重来。
问题不在模型,在于你把「需求澄清」这一步外包给了它的想象力。复杂需求稳定交付的核心是一条流水线:先定义「什么叫做对了」,再让它动手。下面四步就是这条流水线。
技巧 1:别直接开工,先让它把需求写成 spec 给你审
解决的问题:一句话需求里藏着十几个你没说的决定(数值、边界、交互),Claude 会替你猜,猜错就返工。
把第一条指令从「做 X」改成「先别写代码,把 X 整理成一份 spec.md:目标、非目标、数据结构、边界情况、验收标准,列出所有你需要我拍板的决定」:
先别写代码。把「每日签到系统」整理成 spec.md,包含:
1. 目标与非目标 2. 数据结构与存储位置
3. 边界情况(断签/补签/跨时区/改设备)
4. 3-5 条可执行的验收标准
5. 需要我拍板的决定,逐条列出让我选
它会把「断签清零还是保留?奖励曲线线性还是翻倍?」这类问题摆到你面前——5 分钟拍板,省掉 5 轮返工。spec.md 留在仓库里,就是后面所有步骤的锚点。
📖 Anthropic:Claude Code best practices(先探索再计划再编码)
技巧 2:Plan Mode 审计划,计划落成带验收命令的 plan.md
解决的问题:它一口气改 15 个文件,你既看不过来,错了也不知道错在哪一步。
spec 定稿后按 Shift+Tab 进 Plan Mode,让它基于 spec.md 出实施计划,并要求计划按阶段拆分、每阶段自带验收命令:
基于 spec.md 出实施计划,写入 plan.md:
- 拆成 3-4 个独立可验证的阶段
- 每阶段写明:改哪些文件 + 验收命令(如 xcodebuild test -only-testing:SignInTests)
- 阶段之间我确认后才继续
对比一下:没有 plan.md 时,你在审「一大坨 diff」;有了它,你每次只审「阶段 2 是否通过了阶段 2 的验收命令」。对话会被压缩,文件不会——这就是长任务不漂移的锚。
技巧 3:验证器优先——先写测试,让它对着测试迭代
解决的问题:「看起来做完了」和「真的做对了」之间的差距,靠你肉眼盯是盯不住的。
在动手实现前,先让它把 spec 里的验收标准变成会失败的测试:
根据 spec.md 的验收标准先写测试(现在应该全部失败),
然后逐阶段实现,每阶段结束自动跑测试,不过就自己修,
不要改测试来迁就实现。
再配一条 Stop hook,让「跑测试」不依赖它自觉(.claude/settings.json):
{"hooks":{"Stop":[{"hooks":[{"type":"command",
"command":"swift test 2>&1 | tail -5"}]}]}}
这一步是稳定输出的分水岭:有验证器,它能自己收敛;没验证器,它只能靠你当验证器。UI 类需求测试难写?用「构建通过 + 截图给你人工验收」当验证器,也远好于没有。
📖 Anthropic best practices:给 Claude 一个可迭代的目标(TDD 工作流)
技巧 4:阶段之间 /clear,失败了回滚重来而不是缝补
解决的问题:长会话越聊越乱——上下文里塞满了失败尝试,它开始重复犯错、越改越碎。
每完成一个阶段:git commit → /clear → 下一阶段开场只说「读 spec.md 和 plan.md,继续阶段 3」。干净上下文 + 两个锚点文件,比一条塞满历史的超长会话稳定得多。某阶段连改三轮还不对?别继续缝补——git checkout . 回滚,在 plan.md 里把这个阶段的描述写得更细,重开一次。重试一次的成本,几乎总是低于在错误方向上缝补三次。
今日实操(约 15 分钟)
拿你手头任何一个「一直想做但怕它做砸」的需求:只做技巧 1——让 Claude 输出 spec.md 并把待拍板决定列给你。验收标准:它列出的决定里,至少有 2 个是你原本没想到要说明的。有,这套流水线就已经开始替你省返工了。
本课小结:spec 拍板 → 分阶段计划(带验收命令)→ 测试先行 → 阶段间清上下文、敢于回滚。一句话:把「什么叫做对」写成文件和测试,Claude Code 的稳定性就从「碰运气」变成「流水线」。
下一课(第 7 课):怎么判断该给多少上下文?