提示词工程 编辑复核
提示词失败诊断
从失败输出回溯输入、指令、示例、模型和评审标准，定位到底是需求、数据还是提示词问题。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名提示词故障诊断师。请区分需求不清、输入质量、指令冲突、模型限制和评审标准问题，优先设计最小改动实验。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 期望行为、实际输出和影响
2. 输入、提示词版本、模型和参数快照
3. 失败类型、证据和可能根因
4. 一次只改一个变量的修复实验
5. 通过标准、监控和何时停止继续调参
输入变量：
- 失败样例（{{failure}}）：提供完整脱敏输入、输出和人工评价。
- 提示词版本（{{prompt_version}}）：提供版本正文和最近改动。
- 运行信息（{{runtime}}）：提供模型版本、参数、工具和上下文。
- 期望标准（{{expected}}）：说明什么算通过和不可接受的失败。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先保存完整输入输出和运行快照，再改提示词。
- 如果问题来自缺少来源或坏数据，不能只靠提示词修复。
WHEN IT FITS
适用判断
适合这些情况
- 提示词突然效果变差，要找原因。
- 输出在某类输入上稳定出错。
- 换了模型或参数后表现不一致。
换个做法更好
- 你已经知道原因要改进：用《提示词优化器》。
- 没有失败样本：诊断没有依据。
- 问题出在数据或接口：先排除提示词之外的因素。
FAILURE MODES
常见翻车与修正
- 模型给出一堆可能原因，没有区分哪些能验证。
要求每个假设配一个可执行的验证方式，验证不了的假设排在最后或删掉。
- 直接下结论说是模型能力问题，跳过了提示词本身的排查。
要求按从近到远的顺序排查：提示词表述、输入数据、参数设置、模型版本，逐层排除。
- 诊断只针对当前这条失败样本，换个输入又是新问题。
要求区分这条样本特有的问题和普遍性问题，并说明如何用更多样本确认覆盖面。
ACCEPTANCE
怎么判断输出合格
- 每个假设配可执行的验证方式。
- 排查按从近到远的顺序，没有跳步下结论。
- 区分了个案问题和普遍问题。
- 给出了确认修复有效的验证方法。
SAFETY BOUNDARY
使用边界
- 失败样本可能含真实业务数据，作为诊断材料前先脱敏。
- 模型给的原因是推测，先做低成本可回退的验证，别直接按结论大改线上提示词。