参考资料

• OpenAI Prompt Engineering
• OWASP Prompt Injection

Prompt Engineering（08） - 提示词迭代与调试

读完后，你应能完成以下任务：

• 绘制“Prompt Engineering（08） - 提示词迭代与调试 / 先破除一个幻觉”的关键对象与数据流，解释“新手最大的误区是：以为高手是「一次就写出完美提示词」的。”，并用源码位置、日志或 Trace 标注证据。
• 为“Prompt Engineering（08） - 提示词迭代与调试 / 调试三步法”设计正常与异常输入，验证“先说清楚问题到底是什么，越具体越好。”，输出首个偏差位置与回归测试结果。
• 实现“Prompt Engineering（08） - 提示词迭代与调试 / 第二步：定位到「是哪句话」导致的”的最小代码或配置，检验“提示词是由一句句指令拼起来的。”，输出命令、结果与 Diff，并说明不适用边界。

本章目标：建立科学调试提示词的方法论，告别「玄学改词」——知道问题出在哪、一次改一处、能对比版本。

---

一、先破除一个幻觉

新手最大的误区是：以为高手是「一次就写出完美提示词」的。

真相是——没有人一次写对。 哪怕是经验丰富的人，第一版提示词也常常是「能跑但不够好」。区别只在于：高手知道怎么有章法地把它改好，而新手是「不行就整段重写、瞎碰运气」。

提示词工程里，写出第一版只是开始。真正的功夫，在于迭代。这一章就讲：怎么改，才不是玄学。

---

二、调试三步法

碰到不满意的输出，按这个顺序来，别上来就乱改：

2.1 第一步：明确「哪里不对」

先说清楚问题到底是什么，越具体越好。把「感觉不太好」翻译成可定位的描述：

• 是格式不对？（要 JSON 给了大白话）
• 是内容不对？（事实错误、答非所问）
• 是风格不对？（太啰嗦、语气不合适）
• 是漏了要求？（让它做三件事只做了两件）
• 是不稳定？（这次对，换条输入又错）

问题描述得越准，越容易找到对应该改哪句话。

2.2 第二步：定位到「是哪句话」导致的

提示词是由一句句指令拼起来的。出问题时，要去想：是哪一句（或哪句缺失）导致了这个现象？

• 输出太长 → 可能是没写长度约束，或某句话诱导它展开。
• 格式飘 → 可能是没给示例，或格式说明含糊。
• 漏做任务 → 可能是多个要求挤在一句话里，被忽略了。

2.3 第三步：一次只改一处（单变量法）

这是整章最重要的一条。每次只改一个地方，然后看结果变化。

为什么？如果你一次改了三处，结果变好了，你根本不知道是哪一处起的作用——下次遇到类似问题，你还是不会修。一次改一处，你才能积累「哪句话管哪个效果」的真知识。

类比写代码调 Bug：你不会一次改十行再跑，那样出了问题根本不知道是哪行。提示词同理。

---

三、单变量调试法：具体怎么做

像做科学实验一样：控制变量，每次只动一个，记录结果。

操作要点：

1. 固定输入：用同一条测试输入，别改了提示词又换了输入，否则你分不清是哪个变量带来的变化。
2. 一次只改一处：加一句约束、换一个词、调一下示例——只动一样。
3. 记录每一版：把「改了什么 → 结果如何」记下来。哪怕用个文本文件、表格都行。
4. 多跑几次：模型有随机性。一条输入只跑一次可能是运气。重要的改动，同一输入跑 3 次看是否稳定。
5. 用「难例」测：拿最容易翻车的那条输入来测。简单输入怎么改都对，说明不了问题。

记录可以简单到这样：

v1：原始版                    → 输出太长，没按 JSON
v2：v1 + 「只输出JSON」        → 格式对了，但漏了 summary 字段
v3：v2 + 加一个含 summary 的示例 → 全部正确，跑 3 次都稳

一眼就能看出每一步的因果，这就是科学调试。

---

四、何时该「修补」，何时该「重写」

不是所有问题都靠小修小补。判断标准：

继续修补（单变量微调）——当：

• 大方向对，只是细节不到位（少个字段、太长、语气偏一点）。
• 改一两处就有明显改善。

推倒重写——当：

• 改了五六处，每次按下葫芦浮起瓢，整体还是不行。
• 提示词已经被你打满补丁，又长又乱，自己都理不清逻辑了。
• 你发现根本的思路就错了（比如本该用 few-shot 却一直在堆文字描述，本该拆成两步却硬塞一个提示词里）。

经验信号：当你发现自己在「跟提示词较劲」、补丁越打越多时，往往是该退一步重写的时候了。 重写不是失败，带着前面调试积累的认知重写，往往又快又好。

---

五、一个真实的调试演进案例（v1 → v4）

任务：把一段客户反馈，整理成结构化工单。 我们一步步把它调好。

v1（原始版）：

帮我把这段客户反馈整理成工单：
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

结果：模型回了一大段自然语言描述，"这是一张工单：客户反映……"。问题：没法直接用，格式是大白话。

v2（加格式要求）：

帮我把这段客户反馈整理成工单，用 JSON 输出，包含 problem、platform、priority 三个字段：
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

结果：出 JSON 了，但 priority 填的是 "用户希望尽快" 这种自由文本。问题：priority 没有标准取值，没法用来排序。改动只动了「加格式要求」这一处。

v3（约束字段取值）：

帮我把这段客户反馈整理成工单，用 JSON 输出，包含三个字段：
- problem：问题描述
- platform：平台（iOS / Android / 其它）
- priority：优先级，只能是 高 / 中 / 低
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

结果：字段规范了，priority 是「高」。但模型在 JSON 前面加了句「好的，这是整理后的工单：」。问题：多余前言，程序解析会报错。这一版只动了「约束字段取值」一处。

v4（禁止多余文字 + 给纯净示例）：

你是工单整理助手。把客户反馈整理成 JSON 工单。

字段要求：
- problem：问题描述
- platform：平台，取值 iOS / Android / 其它
- priority：优先级，取值 高 / 中 / 低

输出要求：只输出 JSON，以 { 开头，不要任何前言或解释，不要代码块。

示例：
{"problem": "登录时崩溃", "platform": "Android", "priority": "中"}

客户反馈：
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

结果：

{"problem": "App 更新后频繁闪退", "platform": "iOS", "priority": "高"}

完美。格式干净、字段规范、可直接解析。

回看整个过程，每一版只改一处，每一处都针对上一版暴露的具体问题：大白话→加格式，取值乱→约束取值，有前言→禁止多余文字+给示例。这就是迭代的标准姿势——不是一次想周全，而是让每一版的问题，指引下一版的改动。

---

六、常见错误

1. 一次改一大堆：结果变好了也不知道是哪处起作用，等于白调。
2. 改提示词的同时换输入：两个变量一起变，分不清谁的功劳。
3. 只跑一次就下结论：模型有随机性，一次的好/坏可能是运气。
4. 用简单输入测试：怎么改都对，发现不了真问题。要用难例测。
5. 死磕到底不肯重写：补丁越打越多还不行时，重写往往更快。
6. 不记录版本：改到第五版忘了第二版做过啥，又绕回老路。

---

七、最佳实践

• 接受「第一版不完美」：把写提示词当成调试过程，而非一次成型。
• 先定位再动手：先说清「哪里不对」，再想「是哪句话」，最后才改。
• 严格单变量：固定输入，一次只改一处，改完就看结果。
• 记录每一版：「改了什么→结果如何」，哪怕一行字。
• 重要改动多跑几次：同输入跑 3 次确认稳定，别被随机性骗了。
• 拿难例测：用最容易翻车的输入检验，简单输入没参考价值。
• 该重写就重写：补丁打太多、思路根上错了，带着认知推倒重来。

---

八、本章小结

• 好提示词是「改」出来的，没人一次写对。高手强在有章法地迭代。
• 调试三步：明确哪里不对 → 定位是哪句话 → 一次只改一处。
• 单变量调试法：固定输入、一次改一处、记录版本、多跑几次、用难例测。
• 修补 vs 重写：细节问题就微调；补丁打满、思路错了就推倒重写。
• 核心心法：像调代码一样调提示词——控制变量，让每一版的问题指引下一版的改动。

到这里，第二阶段（核心技巧）就全部讲完了。结构化、少样本、思维链、格式控制、迭代调试——这五件工具凑齐，你已经能写出相当专业的提示词。下一阶段，我们把它们组合起来，攻克真实场景里的高频任务。

---

九、配套 Demo

见 提示词工程-demo/08-demo/：完整展示一个工单整理提示词从 v1 到 v4 的真实调试过程，每一版都标注了「发现什么问题、改了哪一处、结果如何」。照着读一遍，你就掌握了迭代的节奏感。

十、动手实践：demo：一个提示词的真实调试演进（v1 → v4）

这个 Demo 不用写代码。它完整记录一个提示词从能跑到好用的全过程， 让你亲眼看到第 08 章「单变量调试法」的节奏：每一版只改一处，让上一版暴露的问题指引下一版。

10.1 任务

把一段客户反馈，整理成程序能直接用的结构化工单。

固定测试输入（全程不变，这是单变量调试的前提）：

你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。

---

10.2 v1 · 原始版

帮我把这段客户反馈整理成工单：
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

• 发现的问题：模型回了一大段自然语言，「这是一张工单：客户反映……」，没法被程序解析。
• 改哪里：下一版加「格式要求」。

---

10.3 v2 · 加格式要求（只改这一处）

帮我把这段客户反馈整理成工单，用 JSON 输出，
包含 problem、platform、priority 三个字段：
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

• 结果：出 JSON 了，结构对了。
• 新问题：priority 填的是 "用户希望尽快" 这种自由文本，没法用来排序/筛选。
• 改哪里：下一版约束字段取值范围。

---

10.4 v3 · 约束字段取值（只改这一处）

帮我把这段客户反馈整理成工单，用 JSON 输出，包含三个字段：
- problem：问题描述
- platform：平台（iOS / Android / 其它）
- priority：优先级，只能是 高 / 中 / 低
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

• 结果：字段规范了，priority 正确填成「高」，platform 是「iOS」。
• 新问题：模型在 JSON 前面加了句「好的，这是整理后的工单：」，json.loads 会报错。
• 改哪里：下一版禁止多余文字，并给一个纯净示例。

---

10.5 v4 · 禁止多余文字 + 给纯净示例（只改这一处）

你是工单整理助手。把客户反馈整理成 JSON 工单。

字段要求：
- problem：问题描述
- platform：平台，取值 iOS / Android / 其它
- priority：优先级，取值 高 / 中 / 低

输出要求：只输出 JSON，以 { 开头，不要任何前言或解释，不要代码块。

示例：
{"problem": "登录时崩溃", "platform": "Android", "priority": "中"}

客户反馈：
"你们的 App 昨天更新后老是闪退，我是 iPhone 用户，希望尽快修复。"

• 结果：

  {"problem": "App 更新后频繁闪退", "platform": "iOS", "priority": "高"}
  

• 完美：格式干净、字段规范、可直接解析。

---

10.6 演进一览表

版本	改动（只一处）	暴露的问题
v1	原始随手问	输出大白话，没法解析
v2	+ 要求 JSON 格式	priority 是自由文本
v3	+ 约束字段取值	JSON 前有多余前言
v4	+ 禁止多余文字 + 给示例	✅ 完美

---

10.7 你应该带走的方法论

1. 固定输入：四个版本用的是同一条反馈，才能判断是哪处改动起了作用。
2. 一次只改一处：每版只动一个地方，因果清清楚楚。
3. 让问题指引改动：不是一次想周全，而是每版的问题告诉你下一步改哪。
4. 记录每一版：像上面的表格一样，「改了什么 → 出了什么问题」一目了然。

试试看：把 v1 到 v4 依次贴进 AI 工具跑一遍，感受「一处改动带来一处改善」的节奏。这就是专业调提示词的样子，不是玄学。

十一、总结

• 先破除一个幻觉：新手最大的误区是：以为高手是「一次就写出完美提示词」的。
• 调试三步法：碰到不满意的输出，按这个顺序来，别上来就乱改：
• 单变量调试法：具体怎么做：固定输入：用同一条测试输入，别改了提示词又换了输入，否则你分不清是哪个变量带来的变化。 -> 一次只改一处：加一句约束、换一个词、调一下示例——只动一样。 -> 记录每一版：把「改了什么 → 结果如何」记下来。 -> 多跑几次：模型有随机性。一条输入只跑一次可能是运气。重要的改动，同一输入跑 3 次看是否稳定。
• 何时该「修补」，何时该「重写」：不是所有问题都靠小修小补。
• 一个真实的调试演进案例（v1 → v4）：结果：模型回了一大段自然语言描述，"这是一张工单：客户反映……"。
• 常见错误：一次改一大堆：结果变好了也不知道是哪处起作用，等于白调。 -> 改提示词的同时换输入：两个变量一起变，分不清谁的功劳。 -> 只跑一次就下结论：模型有随机性，一次的好/坏可能是运气。 -> 用简单输入测试：怎么改都对，发现不了真问题。