为什么你的prompt总是调不好？试试这个结构化调优工具
你有没有过这种感觉——同样的 prompt，改了十几次，还是会在某些情况下翻车？
上周我遇到一个真实案例：用户想让 AI 帮忙分析销售数据，结果遇到”数据量少”就随机编数字。换了七八种说法，从”不要编造数据”到”必须基于真实数字”，效果都不稳定。直到有人推荐了一个叫 prompt-tuner 的工具，按它的流程走了一遍，问题居然真的解决了。
这个工具到底是什么
prompt-tuner 是一个结构化的 prompt 调优工作流，专门用来修复”prompt 行为不一致”的问题。它不教你写 prompt——那是 prompt engineering 的活儿；它是用来调试已有的 prompt，让它不再在特定情况下发疯。
核心逻辑用一句话概括：不要用 case-specific 的修复去解决逻辑问题。
3 条铁律，违反就直接重来
这是 prompt-tuner 的核心价值观：
① 永远不硬编码——不要写”当用户说X时就输出Y”来让某个 case 通过。这样做会让 prompt 在其他 case 上出问题。
② 永远不跳过逻辑确认——修改之前，必须先总结出这个 prompt 的抽象逻辑是什么，得到用户确认再动。
③ 永远先读文档——动手改之前先找相关 .md 文件、注释、测试用例，理解清楚再动手。
听起来是常识？但实际工作中我见过太多人跳过这三步直接改 prompt，结果越改 bug 越多。
四步调优流程
Phase 1：理解先于修改
找 prompt 所在目录的所有 .md 文件、注释、测试用例，总结出三层抽象：Intent（这个 prompt 到底要干嘛）、Rules（核心规则是什么）、Edge cases（边界情况有哪些）。然后用自己的话复述给用户确认。
Phase 2：诊断问题
把出问题的 case 分类——是 Logic gap（prompt 根本没覆盖）？Ambiguity（描述太模糊）？还是 Overfitting risk（你想用硬编码 case 来修，但它本身就是错的）？
最后一步才提修复思路，并说明这个修复会影响哪些其他场景。
Phase 3：泛化修改
这是关键的一步。坏的方式是”当用户说’你好’时回复’你好'”——好的是”对用户的问候语，用简洁友好的方式回应，并主动询问需求”。
修改完之后还要跑一遍 diff，确认没有硬编码任何具体值。
Phase 4：验证
先跑回原来失败的 case，确认通过了。然后想 2-3 个相邻但不同的场景，模拟跑一遍，看有没有引入新问题。
适合谁用
当你遇到以下情况，prompt-tuner 特别有效：
- Prompt 在大多数情况下正常，但特定输入会导致奇怪输出
- 你发现自己反复改 prompt 来修特定的 case，但每次改了其他地方又出问题
- 接手别人的 prompt，需要在不破坏现有功能的前提下做修改
- Prompt 行为不一致，同类输入有时对有时错
如果你现在手上就有一个”怎么都调不好”的 prompt，试着用这 3 条铁律 + 4 步流程跑一遍，大概率能找到真正的根因——而不是一直在表面打补丁。
GitHub 链接：https://github.com/xiangu152/my_claude_skills（skill 在 /dev_claude_code/prompt-tuner 目录下）
评论区
登录后可评论。