Prompt 效果不好时如何系统调试？

简化版

Prompt 调试应先复现并给失败分类，再逐层排查输入、检索/工具、指令、模型和后处理；一次只改一个假设，用冻结样本集比较。不要凭单个案例反复改措辞。保留最终渲染 Prompt、模型参数、证据和输出，建立最小失败样例与回归集，确认修复没有引入新的切片退化。

第一步把“效果不好”变成可测错误：事实错、漏条件、格式错、拒答过度、风格不符或延迟超限。第二步做替换实验：给定正确证据后是否恢复、换确定性解析器是否恢复、同 Prompt 多次采样是否稳定。由此区分 Prompt 问题与检索、数据、模型能力或代码问题。

调 Prompt 时优先消除冲突、补输入输出契约、增加必要正例和边界条件，而非堆叠强调词。每个改动记录版本、假设和预期影响；在 golden set、历史失败集和安全集上运行，比较主指标、分桶、Token 和延迟。通过后灰度，并持续把新失败归档。

复现 -> 分类 -> 定位层级 -> 提出单一假设 -> 最小改动 -> 回归 -> 灰度 -> 归档

“回答不好”无法指导修改。需要保存具体输入、期望、实际输出和判断依据，把失败标成事实性、完整性、指令遵循、结构解析、安全、风格或性能。不同错误需要不同工具：格式错可用 schema，知识缺失可能需检索，Prompt 不一定是根因。

错误标签要允许多选，但标出主要根因与表面症状。例如输出 JSON 少字段是表面格式错，根因可能是上下文被截断；若只在末尾补“务必输出完整”，问题会复发。

记录模型及版本、temperature、seed（若支持）、系统与用户消息、动态模板变量、检索片段、工具结果和解码上限。只保存 Prompt 模板不够，因为线上真正输入可能在渲染、转义或截断时变化。

{
  "prompt_version": "p-42",
  "model": "model-x-2026-09",
  "temperature": 0,
  "retrieved_ids": ["d17", "d93"],
  "rendered_prompt_hash": "..."
}

随机生成任务可重复 5~20 次估计失败率。一次成功不能证明修复，单次失败也可能是采样波动。

排障心法：没有可复现输入，就没有 Prompt bug，只有一段无法验证的故事。

把流水线拆成输入处理、检索、上下文组装、模型生成、解析和业务校验。用真值替换某一层：若塞入正确证据后答案恢复，主要瓶颈在检索；若直接给标准 Prompt 仍失败，可能是模型能力或规则冲突；若原始文本正确但解析失败，修解析器。

这种消融比盲目加规则更快，也能避免把系统 bug 推给模型。

常见缺陷是目标含糊、规则冲突、缺少输入边界和输出契约。先用一句可验证的话定义任务，再列优先级和例外；把外部内容包成不可信数据；用 schema 或示例表达格式。删除“聪明地”“尽量优质”等无法验收的形容词。

同一规则出现两遍且措辞不同，是隐患。可以把 Prompt 解析成结构段，检查重复约束、未绑定变量和互斥要求，例如“答案必须简短”与“逐项详细解释”。冲突不解决，多加“严格遵守”只会放大不确定性。

从真实失败中删除无关内容，直到再删一步就不失败，得到最小反例。它能暴露真正触发因素，也减少每次调试 Token。比如 30 页合同最终缩到两个互相矛盾的日期，说明问题是冲突策略，不是长上下文本身。

每次只修改一个主要变量，例如增加一个边界示例或调整证据顺序。若同时改十处，即使指标提升也无法归因。记录“假设—变更—预期切片—结果”，失败实验同样保留，避免团队重复试错。

至少包含稳定 golden set、刚修复的历史失败、边界/对抗样本和正常流量抽样。每个 bug 修复后把最小反例加入集合，但要控制近重复，避免评测只围绕旧 bug。数据按语言、长度、任务和风险切片。

若版本 B 把格式成功率从 90% 提到 99%，但事实准确率从 85% 降到 75%，不能上线。报告主指标与护栏、样本数和置信区间，并检查输出变长是否只是隐藏了格式解析问题。

离线通过后用少量流量灰度，记录 prompt_version 和完整链路。监控任务成功、人工转交、格式错误、成本、P95 与安全事件。异常可按版本即时回滚，不应在线直接编辑同一 Prompt 内容。

新失败经脱敏后进入 triage，先判断是否代表新错误簇，再加入回归。若大量 case 都需要增加局部例外，说明 Prompt 已产生维护债务，应把确定性逻辑移到代码、检索或结构化状态，而非继续增长文本。

Prompt 调试可记成“复、分、替、单、归、灰”：先完整复现，给失败分类，用真值替换定位层级；每次只验证一个假设；把修复案例加入多维回归；最后灰度并按版本监控。调试的产物不只是一段新文字，而是可复现证据、错误分类和防复发测试。