Claude Code 调 prompt 总改崩？这个结构化工作流能救你

你的 Claude Code 调 prompt 是不是经常「改完这个 case、坏了那个 case」？来回补丁打了一堆，模型却越来越难伺候？

今天挖到一个专治这种病的 Skill——Prompt Tuner，来自开发者 xiangu152。它不是教你写 prompt 的工具，而是教你怎么系统化地调 prompt 的工作流。

🔍 核心思路：逻辑优先，别急着改

大多数人的调 prompt 方式是「哪里不对改哪里」——结果往往是按下葫芦浮起瓢。

Prompt Tuner 的思路完全不同：先读懂现有 prompt 的抽象逻辑，再动一个字。

工作流分四个阶段：

第一阶段：理解再动手

调 prompt 前，必须先找到并阅读相关的逻辑文档（LOGIC.md、DESIGN.md、规则注释等），然后用标准格式总结出一份「逻辑摘要」——不是描述具体 case，而是抽象出背后的通用规则。

必须让用户确认这份摘要后才能继续。这一步很多人嫌麻烦跳过，但恰恰是最关键的。

第二阶段：诊断而非修补

遇到问题先分类：

• 逻辑空白：prompt 根本没覆盖这个场景 → 加通用规则
• 逻辑冲突：prompt 前后矛盾 → 修冲突
• 歧义：prompt 太模糊 → 澄清指令
• 过拟合风险：你的「修复」只对这个 case 有效 → 停止，重新泛化

这个分类框架很实用，能帮你避免「用 case-specific 补丁解决通用问题」的陷阱。

第三阶段：泛化编辑

这是灵魂。Skill 要求你写的是通用规则，而不是针对特定输入的特定输出：

• ❌ 坏例子：当用户说"你好"时，回复"你好！有什么可以帮你的？"
• ✅ 好例子：对用户的问候语，用简洁友好的方式回应，并主动询问需求

修改前后还要明确说出影响范围：「这个改动也会影响 X 和 Y 场景」。

第四阶段：验证

原始 case 通过了还不够，还要测试「相邻 case」——逻辑相近但不完全相同的输入——确认没有引入新的问题。最后再让用户确认没有回归。

🚫 反模式：四种必须 STOP 的情况

Skill 里特别强调了四个反模式，遇到就要喊停：

1. 硬编码：把 case-specific 的值写进 prompt 里
2. 暴力补丁：一个 case 一条 exception，堆到 prompt 里全是 if-else
3. 跳过确认：不等用户确认就自己改了
4. 宣布胜利：过了原始 case 就结束，不测相邻 case

📦 怎么用

这个 Skill 来自一个 Claude Code 技能集合仓库 xiangu152/my_claude_skills，里面的 prompt-tuner 就是主推的这个 Skill。

安装方式：

cp -r prompt-tuner ~/.claude/skills/

触发关键词：tune prompt、fix prompt、prompt 调优、改 prompt、调整提示词

💡 适用场景

• 当你的 system prompt 改了之后行为不一致
• 当某个 case 通过了但新 case 又挂了
• 当你发现 prompt 里开始出现一堆 if-else 式的补丁
• 当你想建立一套可持续的 prompt 版本管理逻辑

Prompt Tuner 不负责帮你写 prompt，它负责让你改 prompt 的过程不出岔子。如果你经常自己调 prompt 推荐试试，特别是用在生产环境里——它能帮你少走很多弯路。

GitHub 仓库：xiangu152/my_claude_skills

GitHub: https://github.com/xiangu152/my_claude_skills