摘要：上一篇讲了"清晰比复杂重要"和三个瘦身的动作。但那套方法有个隐藏前提——你已经知道自己要什么。现实里大多数时候，你脑子里只有一句"我想让模型帮我管库存"，阈值、格式、异常处理全没想清。你不是在"写"清晰 Prompt，是在和模型来回拉扯把自己到底要什么"逼"出来。本文用库存补货的真实例子，把四轮调试循环摊开看，再盘点五个调试循环也救不了的结构性坑。
预计阅读时间：6 分钟
目录
- 第一轮：从一个模糊需求开始
- 第二轮：补阈值，看新偏差
- 第三轮：钉死格式和计算规则
- 第四轮：堵住最后一道缝
- 异常处理：被踩坑喂出来的补丁
- 收敛，而非一次性成型
- 调试循环也救不了的五个坑
- 跑一次，才是开始
上一篇我们聊了"为什么清晰比复杂重要"，以及用三个动作把臃肿 Prompt 瘦身的办法。但那套方法论有一个隐藏的前提假设——你已经知道自己要什么，只是表达得不够干净。
现实远没有这么体面。大多数时候，你坐在屏幕前，脑子里只有一个模糊的念头：“我想让模型帮我管库存”，至于阈值是多少、输出什么格式、异常怎么处理，你其实还没想清楚。你不是在"写"一个清晰的 Prompt，你是在通过和模型来回拉扯，把自己到底想要什么给"逼"出来。
这个过程和写代码修 bug 没有本质区别：先写一个能跑的版本，运行，看报错，定位问题，改一行，再跑。下面我用一个真实的例子，把"清晰"是怎么被一步步逼出来的全过程摊开给你看。
第一轮：从一个模糊需求开始
起点从来不是需求文档，而是一句模糊的话。我写下的第一版可能就是：
帮我看看这些原料库存够不够：珍珠15、椰果20、芋圆8、脆波波15我明知道这不够好，但还是先跑一次。这一步的目的不是要正确答案，而是让模型的错误输出暴露我自己没想清楚的地方。模型果然回了一大段：
珍珠的库存为15，从一般奶茶店的一般消耗来看，这个数量偏低，建议尽快补充。椰果的库存为20，数量较为充足……芋圆的库存为8，这个数量偏少……一看就知道三个"不知道"：它不知道阈值是多少，它不知道我要补货清单还是库存报告，它不知道该用什么格式。这些"不知道"，就是我第一版缺失的信息。我不是坐在那里苦思冥想该加什么约束，而是让模型的偏差告诉我"你还差什么"。
第二轮：补阈值，看新偏差
模型不知道阈值？我补一句：
对比阈值：珍珠20、椰果15、芋圆10、脆波波12，告诉我哪些不够。模型这次乖了，输出：
需要补货的原料有：珍珠（15<20）、芋圆（8<10）。椰果（20>15）和脆波波（15>12）库存充足。阈值对了，但两个新偏差冒出来：它只告诉我"不够"，没告诉我补多少；输出还是一段话，没法塞进程序。
第三轮：钉死格式和计算规则
针对这两个偏差，我再加两条约束：
只输出不够的原料。补货量 = 阈值 × 2 − 当前库存。以 JSON 输出，字段为 material、current_stock、threshold、replenish_quantity。模型输出：
以下是补货清单： [{"material": "珍珠", "current_stock": 15, "threshold": 20, "replenish_quantity": 25}, {"material": "芋圆", "current_stock": 8, "threshold": 10, "replenish_quantity": 12}]几乎完美了——字段对、计算对、格式对。但开头多了一句"以下是补货清单："。这句引导语人看着舒服，程序json.loads()解析时直接报错。
第四轮：堵住最后一道缝
针对这个偏差，加一条最小约束：
不要额外添加任何文字，只输出 JSON 字符串。模型终于吐出纯 JSON：
[{"material":"珍珠","current_stock":15,"threshold":20,"replenish_quantity":25},{"material":"芋圆","current_stock":8,"threshold":10,"replenish_quantity":12}]稳定了。这时候我把这个跑通的输出拎出来，固化成 Prompt 里的"示例"——示例不是第一步写出来的，是第四轮调试完之后从正确结果里"截图"下来的。
回头看，从第一轮那句"帮我看看库存够不够"，到第四轮的纯 JSON，我加了四条约束，每一条都对应一个真实出现过的偏差，没有一条是"以防万一"凭空加上去的。这就是为什么成品的 Prompt 看起来每句话都恰到好处——因为它每句话都是被一次偏差"逼"出来的，多余的话根本没机会存活。
异常处理：被踩坑喂出来的补丁
还有一类东西更不可能提前设计，就是异常处理。比如 Prompt 里这么一条：
若库存数据格式错误，返回 {"error": "库存数据格式错误，请提供类似'珍珠15、椰果20'的格式"}。这条规则哪来的？大概率是某次测试时有人传了珍珠15个，椰果20，芋圆=8这种带单位的乱码，模型要么硬算要么胡编，开发者被坑了一次，才补上这条。每一条异常处理规则，背后都是一次真实的事故。
这也是为什么同一个 Prompt 模板在不同团队手里会越改越不一样——各自踩过的坑不同，补的补丁也不同。就像同一款车的车主，各自根据自己的剐蹭位置贴不同的防撞条。
收敛，而非一次性成型
把这四轮连起来看，清晰的 Prompt 是一个收敛过程的终点：模糊需求 → 跑一次 → 看偏差 → 加最小必要约束 → 再跑 → 再看偏差 → 直到稳定。最后把稳定版本的约束整理成结构化的三要素（角色、指令、格式），补上示例和异常处理，就成了你在教程里看到的那个"模板"。
模板是结果，不是起点。起点的那个"跑一次"，才是 Prompt 工程真正开始的地方。光读模板学不会写 Prompt，就像光看别人修 bug 学不会调试一样。
调试循环也救不了的五个坑
但有些错误不是"偏差"，而是你在写 Prompt 时就已经埋下的结构性雷。它们的特点是：哪怕你跑十轮调试循环，只要没意识到根本原因，怎么加约束都修不好。下面这五个，是实践中出现频率最高的。
坑一：用否定句当约束
大语言模型对否定句的理解远不如肯定句。你写"不要"，它经常把"不要"后面的内容当成要执行的动作，因为它顺着语义续写时，注意力更容易落在名词而非否定词上。
反面：
不要推荐全糖的奶茶。模型很可能推荐的全是全糖——因为"全糖奶茶"这个词被反复强化了，而"不要"两个字在语义权重里几乎可以忽略。就像跟小孩说"别想粉色大象"，他脑子里全是粉色大象。
正面：
优先推荐少糖、无糖的奶茶。同样的意思，把"不要什么"换成"要什么"，模型就不会跑偏。这个坑在调试循环里尤其难发现，因为你看到模型推荐了全糖，第一反应是"我明明写了不要啊"，然后加更强烈的否定：“绝对不要推荐全糖！”——结果更糟。解药只有一个：把否定翻成肯定。
坑二：角色与任务脱节
很多人把角色当装饰品堆砌，写了一堆人设却和实际任务毫无关系。角色一旦与任务脱节，不仅没用，还会干扰模型——模型会花注意力去"扮演"那个角色，在无关的维度上发散。
反面：
你是一位拥有20年经验的资深营养师，精通膳食搭配、微量元素代谢、临床营养学。请根据用户偏好推荐一杯奶茶。模型会忍不住从营养学角度推荐（“建议选择低脂牛奶，减少糖分摄入，注意珍珠的热量较高……”），而你要的可能只是"清爽一点的果茶"。角色给了它一个错误的思考框架。
正面：
你是奶茶店店员，熟悉本店所有口味。根据用户描述的偏好（清爽/浓郁/香甜）推荐1-2款饮品，一句话说明理由。角色直接服务于任务——"店员"这个身份天然限定了推荐视角，不需要营养学知识，也不会往健康角度发散。角色不是越多越好，而是越贴合任务越好。一个判断标准：如果你把角色那句删掉，模型的输出质量会不会下降？如果不会，这个角色就是多余的。
坑三：格式要求只说"JSON"不说字段
输出格式不对，十有八九栽在这里。你以为说了"输出 JSON"就够清楚，但对模型来说，"JSON"只是一种容器，里面装什么字段、字段叫什么名字、值是什么类型，全是空的。
反面：
以 JSON 格式输出补货清单。模型可能给你{"结果": [{"原料": "珍珠", "数量": 15, "标准": 20}]}——是 JSON 没错，但字段名是你没预期的中文，你的程序解析material字段时直接拿到null。
正面：
以 JSON 格式输出，字段包括：material（原料名称，字符串）、current_stock（当前库存，整数）、threshold（阈值，整数）、replenish_quantity（补货量，整数）。不要输出示例中不存在的字段。不仅指定了字段名，还指定了类型，最后一句堵住了模型自作主张加额外字段的毛病。如果模型还是不听，OpenAI v1+ 还有一个兜底手段：response_format={"type": "json_object"}强制输出合法 JSON——但注意它只保证"是合法 JSON"，不保证"字段就是你想要的"，所以 Prompt 里的字段说明依然不可省。
坑四：Prompt 和参数打架
这是最隐蔽的坑。你的 Prompt 写得再清晰，只要有一个参数和它矛盾，效果就会被拉低，而且你很难定位问题出在参数上，因为你会本能地去改 Prompt。
最典型的是temperature。你在 Prompt 里写"输出要稳定、一致、每次都一样"，但temperature设成了 0.9——模型在采样时天生带有随机性，Prompt 再怎么强调"稳定"也压不住它。就像你一边踩油门一边喊"慢一点"，机械结构不会听你的口号。反过来，你想让模型写创意文案，Prompt 里说"发挥想象力，多给几种风格"，但temperature设成 0.1，它永远给你最安全的那个答案，创意无从谈起。
两类任务对应两档参数：
- 需要稳定、可复现的结构化输出（JSON、分类、提取），
temperature调到0.1~0.3； - 需要创意、发散的开放输出（文案、故事、头脑风暴），
temperature调到0.7~1.0。
Prompt 和参数必须指向同一个方向，否则就是左脚踩右脚。
坑五：忽视模型差异
同一段 Prompt 在 GPT 上跑得好好的，换成国产模型（通义千问、文心一言等）就答非所问。这不一定是模型能力差，而是不同模型对 Prompt 的"阅读习惯"有差异。
GPT 系列对结构化标记（# 角色、# 任务指令、# 输出格式这种标题式分区）接受度很高，能准确识别每个区块的职责。但部分国产模型对这种装饰性标题反而敏感，容易把标题本身当成内容的一部分来理解，导致注意力分散。
破法：给国产模型写 Prompt 时，减少结构化标题，改用更直接的自然语言句式。比如把——
# 角色 你是库存监控Agent。 # 任务指令 1. 读取库存数据…… # 输出格式 以JSON输出……简化成：
你是库存监控Agent，需要读取库存数据、对比阈值、筛选需补货的原料，最后以JSON输出（字段：material、current_stock、threshold、replenish_quantity）。一句话串完角色、动作、格式，对国产模型反而更友好。遇到兼容问题，第一反应不应该是"这个模型不行"，而应该是"我的 Prompt 是不是对这个模型来说太’重’了"。
跑一次，才是开始
回顾这两条线索——上一篇的"三个动作"教你如何精简，这一篇的"调试循环"教你如何从零构建——你会发现它们其实是同一件事的两面：精简是在已有 Prompt 上做减法，调试是在空白 Prompt 上做加法，而两者共同的原则都是"每一条约束都必须有存在的理由"。
模板是别人替你跑完整个调试循环后留下的成品。你拿过来可以直接用，但真正的能力不是"记住模板"，而是"会跑循环"。下次面对一个新任务，别急着去翻模板库，先写一句最朴素的话，丢给模型，看它回什么。
那个"回什么"里藏着的偏差，就是你下一步该加什么的地图。