调试基础：什么是提示词调试？
说实话，我刚入行那会儿，对「调试」这个词特别抵触。
总觉得写提示词嘛，跟聊天一样，哪需要什么调试？
直到有一次，我给一个电商客户写商品描述生成器。写了十几版，模型就是输出不对。不是漏了价格，就是忘了规格。客户催得紧，我急得满头汗。
后来我静下心，把每版提示词拆开看，才发现问题出在一个标点符号上。嗯，就一个符号。
从那以后，我彻底明白了——提示词调试，不是可有可无的步骤，而是吃饭的本事。
到底什么是提示词调试？
说白了，调试就是「找茬」。
你写了一段提示词，模型给了你一个输出。你觉得不对劲，于是你开始问自己：
- 哪里不对劲？
- 是格式错了，还是内容偏了？
- 是提示词没说清楚，还是例子给错了？
这个过程，就是调试。
我的定义：提示词调试，就是通过系统性地分析模型输出与预期之间的差距，找到提示词中的问题点，并修正它的过程。
你想想看，这跟程序员调bug有什么区别？
程序员写代码，跑起来报错，然后看日志、找原因、改代码。我们写提示词，跑起来输出不对，然后看结果、找原因、改提示词。
本质上一模一样。
为什么调试是提示词工程师的核心技能？
我见过太多人，写提示词全靠「蒙」。
第一版不行，就改几个词再试。还不行，就全删了重写。运气好，试个七八次能成。运气不好，试一天都搞不定。
这不是调试，这是瞎试。
真正的调试，是有方法、有步骤的。它为什么是核心技能？三个原因：
- 模型不是人，它不会「猜」
你跟人说「帮我写个产品描述」，人能理解上下文。但模型不行。它严格按照你给的指令执行。指令有歧义，输出就偏。调试就是消除歧义的过程。 - 一次写对几乎不可能
我做了几百个项目，没有一次是第一版就完美的。你想想看，连我自己都做不到，你凭什么觉得自己可以？调试不是补救，而是必经之路。 - 调试能力决定上限
初级工程师靠运气，高级工程师靠方法。你会不会调试，直接决定了你能处理多复杂的任务。
我的经验：一个会调试的工程师，效率至少是普通人的3倍。不是因为他写得快，而是因为他改得准。
调试与迭代的关系
这两个词经常一起出现，但很多人搞混了。
我打个比方你就明白了：
- 调试是「修」—— 发现问题，解决问题
- 迭代是「改」—— 基于调试的结果，生成新版本
调试是迭代的前提。没有调试，迭代就是瞎改。反过来，迭代是调试的载体。没有迭代，调试的结果无处安放。
它们的关系，可以用一个循环来表示：
写提示词 → 跑输出 → 调试分析 → 修改提示词 → 再跑输出 → 再调试 → ...这个循环，就是提示词工程师的日常工作。
我记得有一次，帮一个金融客户做风控报告生成器。前前后后迭代了12个版本。每次迭代前，我都会做一次完整的调试。第3版解决了格式问题，第7版解决了数据准确性，第11版才搞定语气风格。
如果没有调试，我根本不知道每个版本该改什么。
避坑指南：我曾经犯过一个错误——调试和迭代混在一起做。一边分析问题，一边改提示词。结果改完发现，问题没解决，反而引入了新问题。后来我学乖了：先调试，再迭代。一步是一步，别跳步。
调试的核心流程
我总结了一个四步法，你可以直接拿来用：
| 步骤 | 做什么 | 关键问题 |
|---|---|---|
| 1. 定义预期 | 明确你想要什么输出 | 理想的输出长什么样？ |
| 2. 对比差异 | 把实际输出和预期对比 | 差在哪里？格式？内容？语气？ |
| 3. 定位原因 | 找到提示词中导致差异的部分 | 是指令不清？还是例子不对？ |
| 4. 修正验证 | 修改提示词，重新测试 | 改完后，问题解决了吗？ |
这四步，每一步都不能省。
尤其是第一步。很多人上来就改，连自己想要什么都没想清楚。你想想看，目标都不明确，你怎么知道改对了没有？
我的习惯：每次调试前，我会先写一个「理想输出样本」。哪怕只有一句话，也要写出来。这样对比的时候，才有参照物。
调试的三种常见场景
根据我的经验，调试主要发生在三种场景下：
- 场景一：输出格式不对
比如你要JSON，它给你Markdown。这种最好调，加个格式说明就行。 - 场景二：输出内容偏了
比如你要产品卖点，它给你写产品历史。这种需要检查指令是否清晰，例子是否到位。 - 场景三：输出质量不稳定
同一段提示词，这次好下次差。这种最头疼，往往需要调整温度参数或者增加约束条件。
这三种场景，覆盖了我90%以上的调试工作。
你遇到的大部分问题，都可以归到这三类里。先分类，再调试，效率会高很多。
小技巧：如果你不确定问题出在哪，可以先跑三次同样的提示词。如果三次输出都不一样，那就是稳定性问题。如果三次都一样但都不对，那就是提示词本身的问题。
写在最后
调试这件事，说难不难，说简单也不简单。
难的是，你要有耐心去分析，而不是凭感觉乱改。简单的是，只要你掌握了方法，大部分问题都能在几轮迭代内解决。
我见过太多人，因为不会调试，把提示词写得越来越长、越来越复杂，结果问题反而更多。
记住一句话：好的调试，是用最少的改动，解决最核心的问题。
下一章，我会带你具体看看，调试时应该关注哪些「信号」。这些信号，就是模型在告诉你——「嘿，这里有问题！」