考察点
这是一道偏实战的排查题。面试官想看你有条理的调试方法论，而不是「换个说法再试试」这种碰运气。能不能设计对照实验把「prompt 没写清」和「模型做不到」分开，是核心区分点。追问常往具体手段走：指令位置、约束冲突、要不要换模型、什么时候放弃 prompt 转微调。
参考答案
先建立一个判断框架
「不听指令」通常有三类根因，按出现频率排：
- Prompt 表达问题：指令有歧义、多个约束互相冲突、关键要求被长上下文淹没。占大头，大概率事件。
- Prompt 结构问题：指令本身清楚，但放错了位置、和示例矛盾、或者输出格式要求和任务描述打架。
- 模型能力问题：任务本身超出模型当前能力，比如复杂多跳推理、精确计数、长文档细粒度抽取。这类问题换写法救不回来。
定位方法：三个对照实验
实验一：换更强的模型试同一个 Prompt。 把同一 Prompt 丢给能力上限更高的模型（比如当前用的 7B/中档模型，换 GPT-4 级或旗舰开源模型跑几条）。强模型能稳定做对，说明指令本身可理解，问题出在模型能力或性价比档位上，要么升级模型要么降低任务难度；强模型也做错，基本可以断定是 Prompt 表达或任务定义有问题。
实验二：消融，把 Prompt 砍到最小。 删掉上下文、示例、附加约束，只留一条指令和一个最简输入。最小版本能跑对，说明问题在被删掉的某个模块里，逐个加回来做二分定位。常见的雷是：示例的输出格式和指令要求不一致（示例优先级往往高于指令），RAG 塞进来的上下文里含有和指令冲突的内容，多个约束叠加让模型顾此失彼。
实验三：人工当一回模型。 把 Prompt 原样给一个不了解需求的同事看，问他按这个指令会输出什么。人读出的理解和你的预期有偏差，说明指令本身有歧义——模型只是忠实地执行了字面意思。很多「模型不听话」归根结底是需求没说清，prompt 是需求文档，要用评审需求的标准评审它。
修复手段
确认是 Prompt 问题后，按力度从轻到重：
- 指令具体化、可验证化。「回答简洁点」改成「用不超过三句话回答，不列举背景知识」。模型无法执行无法验证的要求。
- 关键约束后置。长 Prompt 里模型对结尾内容更敏感，把最重要的约束放在输入数据附近重复一次。
- 拆分任务。一个 Prompt 干三件事出错，就拆成三次调用或让模型分步输出（先抽取再分类再总结），单步成功率远高于一步登天。
- 用示例锁格式。格式类问题（字段名错、多余的客套话）靠文字描述收敛慢，一两个输出示例比什么都管用。
- 声明优先级。指令之间可能冲突时，明确写「格式要求优先于内容完整性」这类元规则。
确认是能力问题后，选项是：换更大模型、降低任务难度（缩小抽取范围、简化分类体系）、上微调把任务模式训进去，或者承认这个任务当前不适合全自动，加人工兜底。
面试里值得强调的一句话
不要凭感觉调 prompt。每一次修改都要在固定的测试集上跑对比，否则你分不清改动是修好了还是碰巧这条 case 过了——这就引出 prompt 评估迭代的话题，面试官通常会顺势追问。
可能的追问
- 模型有时听有时不听，怎么判断？ 说明约束的鲁棒性不够。先统计失败率（跑 50-100 条同分布样本），失败率低于 5% 可以靠重试和输出校验兜住；高于这个水位就得从 prompt 结构或模型层面解决，重试治标不治本。
- temperature 调低能不能解决不听话？ 部分能。格式类的不稳定（偶尔多个空格、字段大小写漂移）降到 0 或接近 0 会明显改善；但指令理解错误和随机性无关，调低 temperature 只是让错误更稳定地复现。
- 什么时候该怀疑是示例的问题？ 输出里出现了你没写进指令、但写进过示例的「影子行为」——比如多余的解释段、特定的措辞风格，基本就是示例在带节奏。示例和指令冲突时模型往往跟示例走。