Claude Code Prompt 的迭代方法：怎么一步步调优
我的 Claude Code Prompt 从 30 字迭代到 150 字，输出质量翻了三倍。
不是说 150 字就是标准答案。
是说那个迭代过程，让我彻底搞清楚了每一个字加在 Prompt 里的理由——哪些字是在解决真实的问题，哪些字是在给自己的焦虑找出口。
大多数人的 Prompt 迭代方式是：输出不好 → 加更多描述 → 再试一次。没有系统，靠感觉，加了什么删了什么也说不清楚。
这篇文章讲的是一套有结构的迭代方法。
为什么你的 Prompt 越改越乱
Section titled “为什么你的 Prompt 越改越乱”Prompt 迭代最常见的错误模式是：同时改太多东西 。
输出不满意，你把措辞也改了、约束也加了、例子也补了，然后得到一个更好的输出——但你不知道是哪个改动起了作用。下次遇到类似问题，你还是不知道该怎么改，只能再靠感觉试。
说人话就是：你在做实验，但你没有控制变量。没有控制变量的实验，得不到可复用的结论。
我自己花了很长时间才意识到这个问题。之前积累了一堆「有效的 Prompt」，但问我为什么有效，我说不出来。换个场景，那套 Prompt 就不管用了，我又得从头摸索。
后来我强迫自己每次只改一个变量，记录每次改动前后的变化，才开始真正积累可以迁移的经验。
迭代框架：五个步骤，每步只做一件事
Section titled “迭代框架：五个步骤，每步只做一件事”第一步：确认「基准输出」——知道你在从哪里出发
Section titled “第一步：确认「基准输出」——知道你在从哪里出发”迭代的起点是：先跑一次你现在的 Prompt，记录输出结果，把它当作基准。
不要凭记忆，要真的把输出保存下来。因为人的记忆会美化”改之前的版本”——你总会觉得改完之后进步了，哪怕实际上没有。
基准输出记录什么：
- 输出里有什么是你想要的
- 输出里有什么是你不想要的
- 有什么你想要但没有出现的
这三点就是你迭代的方向。
第二步：诊断——找到「最影响输出的一个问题」
Section titled “第二步：诊断——找到「最影响输出的一个问题」”有了基准输出，下一步不是立刻改 Prompt，是先诊断：输出不好，最主要的原因是什么？
这一步很多人会跳过，直接开始改。跳过的代价是：你在解决症状，不在解决原因。
我有一套诊断问题的分类：
A类：输出方向错了 ——它理解的需求和你的需求有根本性偏差。表现是：输出的东西和你要的东西不是同一类。
B类：输出范围不对 ——方向对了，但做多了或做少了。表现是：该有的没有，或者有大量你没要的东西。
C类：输出规格不符 ——内容对了，但格式、风格、细节不符合要求。表现是：功能实现了，但代码风格不对、文件放错了地方、用了不该用的库。
这三类问题，对应的修改方向完全不同。
A类问题：需要改任务描述，让它重新理解你在做什么。
B类问题：需要加边界约束，明确说「做什么」和「不做什么」。
C类问题：需要加规格约束，明确说「怎么做」。
诊断出是哪类问题，再决定改哪里。不诊断就改，是在盲目试错。
第三步：单变量修改——每次只改一处
Section titled “第三步：单变量修改——每次只改一处”确定了问题类型，做修改。
原则只有一个：每次只改一处，改完立刻测试，记录结果，再决定下一步 。
「一处」的定义是：一个完整的信息单元。加一条约束是一处，改任务描述里的一个关键词是一处，加一个输出格式要求是一处。
不要同时做这三件事。
这个原则执行起来需要克制，因为你通常能看到好几个「改这里肯定更好」的地方，想一次全改了。
抵住这个冲动。一次全改了，你不知道是哪个改动真的有效，下次还是不会。
第四步：验证——判断改动是否真的有效
Section titled “第四步：验证——判断改动是否真的有效”改完一处，跑一次，和基准输出对比。
判断标准：针对我改动的那个维度，输出是否变好了？其他维度是否变差了？
注意第二问。有时候改一处会让你想改的维度好了，但意外地让另一个维度变差——比如你加了一条约束让它不再生成多余代码，但同时它把某个你需要的错误处理也省掉了。
这种情况叫「副作用」。发现副作用，记录下来，在下一步修复。
如果改动没有效果，或者效果负面，撤回这个改动，重新诊断。
第五步：固化——把有效的改动写进模板
Section titled “第五步：固化——把有效的改动写进模板”验证有效的改动，立刻固化。
不要只在脑子里记住「这个约束有用」，要把它写进你的 Prompt 模板库。
我用一个简单的 Markdown 文件管理我的 Prompt 迭代记录：
## Prompt: Stripe Webhook 处理器
### 版本历史**v1（基准）**：帮我写一个 Stripe Webhook 处理器问题：生成了过多不需要的事件类型处理，没有幂等性检查
**v2**：加入了事件类型限定（只处理 checkout.session.completed）效果：多余事件消失，但幂等性还是没有诊断：B类问题（范围），改了后还剩 C类（规格）
**v3**：加入幂等性约束（查 WebhookEvent 表的 stripeEventId）效果：幂等性逻辑出现且正确副作用：无
**当前有效版本（v3）**：[完整 Prompt 内容]这个记录看起来麻烦，但它是你真正积累经验的方式。两个月后你面对一个新的 Webhook 需求，翻出这个记录，直接从 v3 出发，不用从头迭代。
实战演示：一个 Prompt 的完整迭代过程
Section titled “实战演示：一个 Prompt 的完整迭代过程”以「生成 Stripe 优惠码验证逻辑」为例，走一遍完整的迭代流程。
基准 Prompt（v1）：
帮我写一个验证 Stripe 优惠码的函数
基准输出问题诊断：
- 它写了一个调用 Stripe API 验证优惠码的函数
- 但没有处理「优惠码已过期」的情况
- 也没有处理「优惠码已达使用上限」的情况
- 函数直接 import 了 Stripe client，不方便测试
问题类型：B类（范围不够，漏了边界情况）+ C类（规格不符，依赖注入方式不对）
第一次修改（v2）：只解决 B类问题，加边界情况
帮我写一个验证 Stripe 优惠码的函数，需要处理以下情况：优惠码有效、优惠码不存在、优惠码已过期、优惠码已达使用上限
v2 输出验证： 四种情况都有了。但 Stripe client 还是直接 import 的，不好测试。B类问题解决，C类还在。
第二次修改（v3）：只解决 C类问题，改依赖注入方式
帮我写一个验证 Stripe 优惠码的函数，需要处理以下情况：优惠码有效、优惠码不存在、优惠码已过期、优惠码已达使用上限。
约束：Stripe client 作为参数传入，不要直接 import
v3 输出验证： 依赖注入正确，四种情况都有，可以直接写测试。
两步迭代，每步一个变量，清楚知道每个改动在解决什么问题。
大多数教程不告诉你的细节： v2 到 v3 的这一步，只加了一句「Stripe client 作为参数传入，不要直接 import」——这 20 个字，让代码从「能跑但难测试」变成「能跑且容易测试」。一个小的规格约束，影响了代码的长期可维护性。记录这个改动，以后所有涉及外部依赖的函数，这条约束直接复用。
坑一：以为「输出变好了」就是迭代成功，没有检查副作用
有一次我在迭代一个 API 路由的生成 Prompt，加了一条「必须实现错误处理」的约束之后，错误处理出现了。我很满意，固化了这条约束。
两周后用同一个 Prompt 生成另一个路由，发现代码里多了大量过度的错误处理——每一行数据库操作都有单独的 try/catch，每个 catch 都有不同的错误日志。整洁度下降了很多。
追回去看，是那条「必须实现错误处理」太模糊，在简单路由里等于让它把每个操作都包起来。
解决方案： 每次验证改动效果时，不只看「想要的东西有没有出现」，也看「有没有出现你不想要的东西」。前者是正向验证，后者是负向验证，两个都要做。
坑二：有效的 Prompt 没有记录，半年后找不到
我有一段时间确实在做迭代，也找到了几个特别好用的约束组合。但我只是在脑子里记住了「哦这个 Prompt 很好用」，没有写下来。
半年后换了一个新项目，类似的需求，我完全想不起来当时加了哪些约束，为什么有效，又从头摸索了一遍。
解决方案： Prompt 迭代记录不是可选的，是必须的。哪怕只是一个 Markdown 文件，把有效版本和关键改动点记下来。这个积累是你真正的「Prompt 资产」，不记录就等于没做过。
Prompt 迭代的本质是受控实验：每次只改一个变量，记录结果，积累可迁移的经验。
没有控制变量，你做的是随机漫步；有了控制变量，每次迭代都在真正提升你的能力。
最后一个实际的问题： 你现在手头有没有一个「反复用但效果不稳定」的 Prompt——今天能出好结果，明天同样用却出了垃圾？如果有，用今天这套诊断框架分类一下：它是 A类（方向错）、B类（范围不对）还是 C类（规格不符）的问题？