大模型提示词工程方法有哪些

做 AI 应用的人常卡在同一个地方：模型能跑通 demo，但一到真实业务就时好时坏，改了几十版提示词也说不清是哪出了问题。这篇按「先定位问题、再选方法」的顺序，把提示词工程里常用的几类方法、它们各自治什么病、什么时候不适用讲清楚，最后给一份可以直接照着走的排查顺序。

做 AI 应用的人常见一个状态：模型能跑通 demo，接进真实业务就时好时坏。改了十几版提示词，自己也说不清到底哪一版好、好在哪。问题往往不在「提示词写得不够玄」，而在没先分清这一版的问题该不该用提示词解决。

这篇按「先定位、再选方法」的顺序拆。每节给的是判断标准和可执行动作，不是概念名词解释。方法的适用边界会一起写清楚，避免把提示技巧用在不该用的地方，白花时间和调用成本。

先判断这一版问题该不该用提示词解决

动手改提示词之前，先给当前失败分个类。判断标准很简单：把同一段输入重跑几遍，看失败是不是集中在同一类错误上。如果每次都栽在同一个地方，比如字段总缺一个、格式总解析不了，那基本是提示结构的问题，改提示有解。如果结果每次都飘得不一样，方向都对但细节随机，那更可能是采样参数或任务定义本身没定清楚，改措辞收效有限。

结构化方法：把指令拆成固定槽位

结构化说白了就是把一大段自然语言拆成几块固定位置：角色、任务、输入、约束、输出格式各占一块。好处是好复用、好排错——出问题时能一眼看出是哪块没写清，而不是对着一整段话猜。这种写法适合输入结构稳定、要批量跑的任务。

• 输出格式用示例或结构描述钉死，字段名和层级一次讲清，下游才好解析
• 约束条件单独列，一条约束一行，方便逐条增删对比效果
• 任务描述里只写「做什么」，别把「不能做什么」混进去，两类信息分开管
• 模板里留出输入占位，代码侧拼接，别让模型去猜哪段是数据哪段是指令

这套方法不适用的情况也得说：如果每次输入的形态差异很大，硬套固定槽位反而会让模型漏掉真实信息。这种情况更适合先用自然语言把关键信息描述清楚，再逐步抽槽位。

推理引导方法：让模型分步，而不是一步给结论

分步推理适合有中间计算、多条件判断、需要权衡的任务。做法不是简单加一句「请一步步思考」，而是把「先做什么、再做什么」写进指令，让路径可控。步骤别超过三四步，太长模型会中途跑偏。

1. 定义步骤把任务拆成三到四步，每步有明确产出，写进指令里
2. 要求分步输出让模型按步骤给中间结果，方便你定位是哪步出的错
3. 结论单独成段要求最后单独给结论段，方便从长输出里抽取，不用整段正则
4. 验证稳定性同一组输入多跑几次，看中间步骤是否每次都走同一条路

不适用的场景很明确：纯抽取、分类、改写这类本身没有推理链的任务，强行分步只会引入噪声，还更慢更贵。判断标准是问自己一句：这个任务有没有「中间态」值得保留？没有就别分步。

上下文与示例方法：少给规则，多给例子

规则写多了会互相打架，模型顾此失彼。几个典型示例往往比一长串约束有效，尤其是格式和风格类要求。关键在示例的挑选，不在数量。

• 示例要覆盖边界情况，光给正例模型学不会什么时候该拒绝或该留空
• 正例反例成对给，模型更容易学到分界线在哪
• 长文档任务里，参考材料和执行任务分区放，中间加分隔标记，减少张冠李戴
• 上下文长度有成本，先用少量例子跑一遍，不够再加，别一上来就塞满

这一招不适用的情况：如果任务要求的是精确匹配某个外部规范，而示例覆盖不全，模型会照着有限的例子外推，反而错得离谱。这时候规则清单比示例更靠得住。

上线前的对照与排查顺序

改提示词最怕凭感觉。固定一组测试输入，改动前后各跑一遍，看的是错法有没有变少，而不是单条结果像不像。单条像不代表整体稳，错法变少才说明方向对。

1. 任务定义是否清楚能不能用一句话说清输入和期望输出，说不清就先别改措辞
2. 输出格式是否可解析下游代码能不能稳定拿到字段，拿不到先钉格式
3. 示例是否覆盖边界把之前出过错的输入拿出来，看示例里有没有同类情况
4. 是否该分步任务有没有中间态，有就加分步，没有就别加
5. 是否需要外部知识接入模型答不出的事实类问题，走检索增强而不是继续改提示词

把版本和改动记下来，别只留最后一版，出问题时能对比才知道是哪次改动带来的。要换别的模型前，先去站内的模型库和测评页面核对能力口径，别把调好的一版提示词直接套到另一个模型上。各家的价格和模型差异可以到 价格追踪（/price-watch） 和 测评榜单（/rankings） 看当时的数字。