提示词为什么时灵时不灵：推理模型与通用模型的差异

现象：同一段 prompt，换个模型就翻车

很多人以为提示词是「通用技巧」，写好一份可以到处用。实际上提示词是和模型强绑定的——尤其在有「推理模型」之后，同一条指令在两个模型上的最优写法正好相反。

典型冲突：

通用模型：你让它「一步一步思考」，效果变好
推理模型：它本来就内部思考，你再让它输出步骤，反而拖慢、变贵、还容易把答案搅乱

理解这一点，比背 100 条提示词技巧有用。

一、两类模型的机制差异

	通用对话模型	推理模型（reasoning）
思考方式	直接生成答案	先生成长链思考，再给结论
你对思考过程的控制	靠 prompt 引导	由模型内部完成，外部难以干预
延迟	低	高（思考 token 都算时间和钱）
适合任务	抽取、改写、分类、闲聊	数学、逻辑、多步推理、复杂代码
提示词要点	给步骤、给示例	给目标、给约束，别给步骤

关键推论：推理模型的「思考 token」是计费的，也可能出现在返回里。如果你让它「详细写出推理过程」而它内部已经推理过一遍，等于为了同一件事付两遍钱。

二、通用模型的写法：把步骤写出来

对通用模型，CoT（Chain of Thought）确实有效——因为它需要外部线索来组织推理。

请按以下步骤处理用户问题：
1. 先判断问题类型（售后 / 售前 / 投诉）
2. 如果是售后，抽取订单号与问题描述
3. 根据问题类型选择对应话术模板
4. 输出 JSON：{"type": "...", "order_id": "...", "reply": "..."}

要点：

步骤要具体到可执行，「请认真分析」这种话没有信息量
few-shot 比描述更有效：给 2~3 个「输入 → 期望输出」的完整示例，胜过写 200 字规则
格式用 schema 约束，不要靠文字描述格式

三、推理模型的写法：只说目标，不给步骤

推理模型自己会拆步骤。你给步骤反而可能限制它的搜索空间，或者和它的内部推理冲突。

【目标】判断这份合同里的违约金条款是否对我方不利。
【约束】
- 只依据合同原文，不要引入外部假设
- 若条款存在歧义，明确指出歧义点，不要猜测
【输出格式】结论（有利/不利/不明确）+ 依据的条款原文 + 一句话理由

要点：

给目标 + 约束 + 输出格式，不给过程
明确「不确定时怎么办」：推理模型倾向于给出确定答案，你必须显式要求它说"不确定"
不要在 prompt 里写 "let's think step by step"：对推理模型是冗余的
复杂任务可以给评估标准而不是步骤：「好的答案应满足以下 3 条…」

四、五个高频反模式

1. 把「格式要求」写成散文

❌ 「请用 JSON 格式回答，包含 type 和 reply 字段」
✅ 用结构化输出（JSON schema / response_format），或给完整示例

散文描述格式的合规率远低于 schema 约束。生产环境必须是后者。

2. 让模型「尽量准确」但不说怎么算错

❌ 「请务必准确，不要出错」
✅ 「如果信息不足，输出 {"error": "insufficient_info"}，不要编造」

负向要求（"别做 X"）对模型的效果远小于正向的兜底路径。你要给它一条合法的「我不知道」出口。

3. few-shot 示例风格不一致

示例里有的用中文、有的用英文；有的带单位、有的不带。模型会忠实模仿这种不一致，输出跟着乱。

示例必须是「同一模板的不同数据」，格式一个字符都不能差。

4. system prompt 越写越长，互相打架

几十条规则的 system prompt，经常出现「第 3 条要求简洁、第 27 条要求详细」。模型只能择一，结果不稳定。

规则超过 15 条就要拆分：把不同任务的 prompt 拆成不同模板，而不是堆在一个 system 里。

5. 用同一个 temperature 跑所有任务

抽取/分类：temperature=0（要确定性）
创意/改写：0.7~1.0（要多样）
事实问答：0~0.3

一个值跑全部，要么抽取不稳定，要么生成太死板。

五、一份可套用的提示词骨架

# 角色
你是 {具体角色，越具体越好}。

# 任务
{一句话说清要做什么}

# 输入
{数据结构说明}

# 规则
1. {可执行的规则 1}
2. {可执行的规则 2}
3. 若无法确定，输出 {"error": "..."}，不要编造。

# 输出格式
{schema 或完整示例}

# 示例（few-shot，可选但强烈建议）
输入：...
输出：...

这个骨架对通用模型直接可用；对推理模型，删掉「# 规则」里的步骤化描述，保留目标、约束和输出格式即可。

六、怎么验证提示词真的改好了

凭感觉调 prompt 是最大的时间黑洞。三条纪律：

固定评测集：20~50 条真实样本，覆盖边界情况（空输入、超长、歧义、恶意注入）
改一处、测一次：一次改多个地方，出了问题不知道是哪个改坏的
记录版本：prompt 也是代码，要进版本管理；否则「上周效果明明很好」无法复现

# 最小可用的评测骨架
for case in eval_set:
    out = call_model(build_prompt(case.input))
    ok = validate(out, case.expected)   # 结构校验 + 内容比对
    results.append(ok)
print(f"通过率 {sum(results)}/{len(results)}")

小结

通用模型：给步骤、给示例
推理模型：给目标、给约束、给兜底
格式一律用 schema，不用散文
一律给「我不知道」的合法出口
一律有固定评测集，否则调 prompt 就是玄学