提示词工程简单说就是我们和大语言模型打交道的接口设计。同样一个模型有人能稳定产出结构清晰的方案有人则得到一堆车轱辘话差别往往不在运气而在提示词怎么写。这篇文章我不会从“什么是大模型”讲起直接聊实操如何把需求翻译成模型能理解、会执行的指令从最基础的模板到进阶的推理增强手法把隐晦的参数、边界和易错点一次讲透。适合刚入门的新手也适合已经写过一段时间但总觉得结果不稳定的老手。提示词工程这个名字听起来工程味很重但你越用越会发现它更像一种“需求翻译学”。模型本身没有意图所有输出都是对输入序列的续写。你的提示词越接近模型的理解方式输出越接近你想要的答案。而“理解方式”又由训练数据、指令微调、上下文窗口、解码参数共同决定。所以你想稳定控制输出就要同时掌握两条线一是写好提示词本身二是理解模型生成时的几个关键旋钮。两条线拧在一起才是完整的提示词工程。1. 提示词工程的核心是把意图说清楚1.1 模型不是搜索引擎也不是人很多人会把大语言模型当成升级版搜索框想到什么问什么。这种用法不是不行但结果往往平庸。模型本质上是一个自回归语言模型它根据前文所有 token 去预测下一个 token。你扔一句“帮我写篇文章”它能写但写出来的是它训练集中最常见的那种文章结构平淡、套路、没有重点。你扔一句“帮我写一篇面向新入职产品经理的周报要求用分点总结本周进展、下周计划语气务实不要废话”模型输出的结构立刻就不同了。模型既没有真实理解你的场景也没有记忆它是把所有注意力放在当前这段文本上做概率推断。所以提示词的全部意义就是用尽可能明确、完整、自洽的文本减少模型在“猜”上的自由度。你要把“任务背景、输入材料、期望格式、语气风格、禁忌事项”都说清楚而不是指望模型读心。1.2 输出不确定性从哪里来你可能会发现同一个提示词跑五次得到五份不同的结果。这种不确定性主要由两个来源构成第一采样参数。temperature 控制的是概率分布的尖锐程度temperature 越高低概率 token 被选中的机会越大输出越发散temperature 越低输出越偏向最高概率路径也更稳定。第二模型本身的无状态性。即使不改变提示词每次请求都是独立采样除非显式提供固定种子否则结果天然有波动。理解了这一点你就知道提示词工程的目标不是追求一次输出的“惊艳”而是追求“在可接受波动范围内的高质量”。这也是为什么后面我会反复强调示例、格式、约束条件和迭代验证它们都在压缩模型的概率空间让好结果出现的概率尽可能大。不要指望一句神来之笔式的提示词就能解决所有问题真正的工程做法是把一个复杂目标拆成多个可控步骤每一步都有明确校验点。2. 基础提示词四件套指令、分隔、示例、约束2.1 用指令动词做开头任务目标放在第一句提示词的结构不必嵌套太深但第一句话最好直接点明任务类型。你写“请从以下内容中提取关键风险点以列表形式输出”模型会优先按指令动作组织输出你写“我有一段文字你帮我看看这段文字写得怎么样并且告诉我哪里需要修改”模型也能做但“动作”不够聚焦。我建议的句式是[动作] [对象] [输出形式] [附加要求]。比如“改写”是一个动作“润色”是另一个动作两者并不完全等价。我曾给某开发者做过一个邮件改写提示词最开始写“帮我改一下这封邮件”模型改完了措辞确实更流畅但把原来的重点数据也顺带弱化了。后来我把动作用“保留全部关键信息的基础上压减字数”替换结果立刻不一样。动作描述越准确模型在语义空间中搜索的范围越小。2.2 用分隔符把指令和内容分开大模型对长文本里的“指令”和“待处理内容”容易混淆尤其是当内容本身含有很多祈使句时。处理办法是明确使用分隔符。常见的分隔符包括三引号、反引号、XML 标签等比如以下是需要处理的正文请提取其中所有日期和金额 文本 原定 3 月 15 日启动的项目因资金到账延迟预算调整为 12000 元预计 4 月 10 日前恢复。 /文本分隔符的核心作用是告诉模型注意力要切换了从“理解任务要求”切换到“处理内容本身”。如果不加分隔符模型可能会把正文里的句子误当成指令的一部分或者把指令中的样例误当成待处理内容导致输出混乱。实测下来用 XML 标签比用纯符号更稳因为模型在指令微调阶段见过大量类似格式。2.3 角色设定不是玄学是缩小专业范围角色设定本质上是给输出空间加先验。你对模型说“你是一名资深数据分析师”它会倾向于使用数据分析领域的概念框架和表达习惯你说“用小学五年级能听懂的语言解释”它会压制术语。这两个场景背后是不同的词语分布。但角色设定不能滥用。一个常见错误是把角色堆得像简历一样长“你是一名资深数据分析师又是一名营销专家还是一名心理学博士。”角色互相冲突时模型输出会变得又散又空。更好的做法是给角色限定任务范围。比如“你是一名只分析用户行为数据的分析师不讨论业务策略”这比单纯强调角色背景更有用。角色只是框架任务边界才是真正约束模型的地方。2.4 少样本示例比描述概念更有效有些抽象要求比如“语气要专业但不生硬”模型很难准确捕捉尺度。这时候给一个正例、一个反例效果远超大段解释。少样本提示就是把期望的输出形态直接展示给模型让它模仿这种模式。示例选择有几个要点示例必须和你真实要处理的对象属于同一类型示例数量通常一至三个即可一次给太多反而引入不一致示例最好覆盖边界情况。比如提取信息时第一个示例是一段短文本第二个示例是一段含干扰信息的文本这样模型既学到结构也学会排除噪声。示例还有一个附带好处它常常会把输出格式也一并约束住。你给一个 JSON 输出示例模型大概率会按 JSON 格式继续生成。2.5 约束条件要直接“禁止”或“必须”模型对否定式指令的理解比对肯定式指令更不稳定需要把约束具体化。比如“不要输出多余的话”不如“只输出以下三种状态符合、不符合、无法判断”。再比如“不要编造数据”不如“如果正文中没有明确出现的数据统一写为‘未提供’”。这里有个认知误区很多人认为禁止性提示词越严厉越好。实际上模型并不理解你的情绪强度它只做概率判断。与其写“绝对绝对不能出错”不如给一个可落地的替代方案。把每种情况的输出结果都定义清楚模型就没有自由发挥的空间了。3. 高级技巧思维链、自一致性与可控生成3.1 让模型把推理过程写出来复杂问题直接问答案模型容易凭印象作答因为它的训练目标不是严格计算。强制模型写出中间步骤效果会明显提升。这就是思维链提示的核心思路把隐式推理显式化。常用句式是“请逐步分析”。更有效的方式是直接要求模型按阶段输出比如“先列出已知条件再说明可能的风险最后给出结论”。每一步都是对模型注意力的重新分配。需要注意的是思维链并不是万能钥匙。对于非常简单的任务加这类要求反而冗长对于模型训练数据中极少出现的推理类型思维链也不一定能保证正确。它提升的是成功率不是确定性。3.2 自洽性采样让模型自己投票单次生成的思维链可能出错那就让它多跑几次再把多数答案作为最终结果这个思路叫自洽性采样。在大模型 API 里实现它就是在请求层做多次调用温度和采样参数保持一致然后把每次输出的结构化结果合并用简单计数或规则做聚合。这个方法特别适合两类任务一是需要“给出一个结论”的问答型任务二是存在客观标注的分类型任务。我做过一个实体抽取场景单次输出 F1 值大约 0.82改成五次采样加投票后稳定到 0.89。代价是请求次数和 token 消耗增加算力成本翻几倍。所以在生产环境里自洽性采样更适合离线评估、数据标注辅助等场景不适合高频低延迟的线上服务。线上可以考虑折中方案先跑一次如果结果置信度低于阈值再触发多轮采样。3.3 用多轮对话的工作流替代单次巨无霸提示词很多复杂任务比如“分析一份合同草案并生成修改意见及润色版本”塞进一条提示词不是不行但很容易顾此失彼。我更推荐拆成多轮第一轮输入合同文本让它提取条款清单。第二轮针对条款清单逐条生成风险分析。第三轮把风险分析转成给非专业人士的修改建议。第四轮做语言润色保留前三轮的结构。这样每一轮模型的任务都足够聚焦输出质量更容易控制。上面这些步骤可以放在一个对话上下文中利用模型的“继续”能力也可以通过代码逻辑串联多个独立请求。前者的好处是上下文连贯坏处是上一轮的偏差会累积到下一轮后者的好处是每轮都像一次全新计算灵活可控但需要自己管理中间状态。生产环境我建议以后者为主。3.4 可控生成的五个参数温度、top_p、max_tokens、seed、stop提示词工程不能只看文本还要看采样参数。这五个参数里我最常调的是温度和 top_p。temperature 是概率分布的缩放因子top_p 是核采样的累计概率阈值。两个参数并不建议同时大幅调整保留一个做主要控制就够了。我做分类任务时一般把 temperature 设为 0.2做创意写作设为 0.8 到 1.0。max_tokens 要预留足够空间给模型输出特别是思维链任务输出长度经常是直接回答的几倍。seed 参数在不同平台上的支持情况不同有些平台支持固定种子但即使在支持时它也只能让同批次请求更稳定不能保证跨平台一致。stop 参数适合约束输出结束位置比如告诉模型遇到“END”就停止配合特定输出标记使用。4. 面向真实场景的提示词模板与拆解4.1 写作场景风格迁移与克制型润色写作类任务的提示词最容易犯的毛病是“要求糊涂”。你说“帮我润色”模型就倾向于把每句话都变得更高级、更复杂结果信息密度反而下降。我常用的润色模板是请润色下面的文本要求 1. 保留全部事实信息包括数字、日期、人名和专有名词。 2. 句子长度不超过30字。 3. 不用成语和华丽形容词。 4. 输出只给出润色后的文本不加说明。 文本 ... /文本“克制型润色”是实战中特别重要的一组思路。如果你给模型下放风格评价权它会越写越冒险如果你规定它只能做局部调整它就守得住。我还习惯在润色模板里加一句“如果原文已经清晰不修改”这句话能有效避免模型多手改动。经验是给模型一个“不做”的选项往往比反复强调“不要过度修改”更有效。4.2 编程场景让模型写代码前的四步确认用大模型写代码的人八成遇到过一种情况模型输出一段看似完整的函数但隐藏了几个编译错误你把错误贴回去它又修好了。于是陷入“生成、报错、再生成”的循环。要跳出这个循环写代码提示词时就要做四步确认明确输入输出类型。比如“入参是 string 类型 JSON字段不确定输出类型统一为 number”。声明边界条件。比如“如果数组为空返回空对象而不是报错”。给出希望使用的依赖或禁止使用的依赖。要求生成包含关键注释的核心代码而非完整工程项目。一个实战中的有效模板是写一个 Python 函数函数名为 process_data输入一个 dict包含字段 id, name, tagslist[str]。 要求 - 用标准库完成不引入外部依赖。 - tags 去重并保留原顺序。 - 如果 id 为空返回 None。 - 输出为 dict键为 id 和 unique_tags。 - 直接输出代码不要解释。注意“直接输出代码不要解释”这种指令它能减少无意义的说明但如果任务确实复杂也可以改成“先给出思路再输出代码”。编程场景更值得关注的是让模型先写测试用例再写实现代码。把测试放前面相当于替模型定义了一个校验标准代码质量会显著提升。4.3 数据分析场景结构化抽取与幻觉抑制数据分析里最常遇到的提示词任务是信息抽取和表格转换。大模型做抽取不是逐字符匹配而是语义理解后重建文本所以可能出现信息遗漏或“合理外推”。抑制幻觉的关键是给模型一个安全的默认输出。举个例子从下面文本中抽取指定字段字段包括公司名称、成立年份、员工规模、办公城市、是否有融资。 要求 - 只抽取文本中明确提到的内容。 - 字段缺失时统一返回“未提及”。 - 输出为 JSON 格式键名固定。 文本 ... /文本当模型遇到模棱两可的表述时“未提及”就是这个安全默认值。如果没有这个约束模型会倾向于补充常识信息比如根据公司规模推测城市这是幻觉的典型来源。抽取类任务建议在提示词里同时给一个“只抽取不回填”的强调句可以显著降低外推概率。另一个有效做法是让模型先重述原文关键句再做字段映射。中间多一层结论可靠性会高出很多。4.4 知识问答场景引用来源与拒绝回答大模型问答最危险的是胡编来源。应对方法可以写在提示词中要求模型给出每个结论的出处在上下文中定位。对开放域问答你可以要求模型只在提供的知识库片段中作答超出范围时明确回复“知识库中未找到”。一个可靠的问答模板是仅根据以下资料回答问题。如果资料中没有相关内容回答“未在参考资料中找到”。 回答应包含引用的具体句子格式为结论 资料第X段。 参考资料 ... 问题 ...知识库问答在工程上几乎没有只靠提示词就能完全解决的。即便是很清晰的提示词也仍需要在代码或工作流层面加一层检索逻辑。提示词负责约束表达检索负责约束信息范围两者缺一不可。如果你发现模型还是答错多数情况不是提示词不够严格而是检索结果本身包含了过多噪声片段。这时候优先优化检索排序而不是继续加长提示词。4.5 模拟评测场景用提示词做质量打分除了直接回答提示词工程还有一个隐藏用途让模型当评审。你可以让模型基于自定义维度给文本打分这个“评审提示词”非常实用。比如做内容批量校对让模型从头审阅文案并提出修改建议再用另一条提示词对不同方案的修改结果做横向打分。评审角色和我之前说的角色设定不同它需要明确的评分标准和高信噪比输出。一个评分提示词至少要有四个部分评分维度、各维度权重、分数区间、评分理由的句式。没有这些模型给出的分数参考价值很低。实践中我还会专门要求模型在给出低分时引用文本中的具体片段作为依据。这样既防止幻觉也方便人工复审。5. 提示词工程的坑我替你踩过了5.1 提示词越长不代表效果越好很多初学者把提示词写成小作文以为信息越多越好。效果往往相反关键指令被大量无关描述淹没注意力被稀释。提示词长度和效果的关系不是线性增长而是先升后降。核心指令应放在最前面背景信息居中示例按需插入长段注意事项放最后。另外提示词里的每个词都可能被模型当成交互信息如果你的描述中存在互相冲突的说法模型只能挑一个概率最高的方向执行最终结果由不得你控制。5.2 模糊的“不要”其实是种诱导语言模型没有真正的否定逻辑它只是按上下文预测。你写“不要提到价格”模型仍然可能提到因为提到价格这个动作本身在概念上激活了相关 token。正确做法是替换名称例如写“只说明功能与适用人群不包含费用字段”并给出反例。少样本示例中的反例对抑制这类问题效果明显。5.3 指令冲突时模型会不知所措当提示词同时出现“输出简短”和“覆盖所有细节”时模型往往不知道应该偏向哪一条。这种隐性冲突在生产环境里特别常见因为提示词通常是迭代出来的前一个需求没删干净后一个需求又叠加进来了。我建议每次修改提示词后做一次“冲突扫描”如果某两个要求针对同一个输出维度就定优先级或拆分成多轮。5.4 一个容易被忽略的坑格式约束被 max_tokens 截断当输出内容较长时模型可能会在生成中途被截断导致 JSON 不完整或列表少了几项。提示词里对格式的要求再细致也救不回来。排查这个问题时先看响应里的 finish_reason 字段如果显示 length 而不是 stop就要增大 max_tokens。再做一层兜底用代码对返回结果做基本校验解析失败时自动重试而不是相信每一次输出。生产系统里把提示词输出当“不可信输入”处理才是正确姿势。5.5 常见问题速查表现象可能原因调整方向输出总是跑题指令动词模糊改成“提取、改写、分类、列出”等具体动作格式偶尔损坏max_tokens 不足或 stop 条件缺失增大生成上限加输出结束标记答案编造数据没有给安全默认值增加“未提及则输出未提供的约束”输出表现不稳定temperature 偏高降到 0.2 以下或加固定 seed示例没有被遵循示例与真实输入差异过大换用同一来源、同结构的示例指令被忽略关键句被大段背景淹没核心要求移到提示词开头6. 如何持续改进提示词版本管理与评测6.1 把提示词当成代码来管理提示词工程里常见的一种低效做法是“灵光一现式修改”在对话里不断追加“不对再来一版”最后连自己也分不清哪版最好。我建议像管理代码一样管理提示词每条改动留一个版本记录标明改动动机、改动前后对比输出、测试样例结果。不必用什么复杂工具一个 Markdown 文件或在线文档就够用重点是记录而不是凭感觉。版本管理有两个好处。第一你可以在回退时快速定位是哪条约束引起的质量退化。第二当你把提示词迁移到另一个模型或 API 版本时可以对照旧结果找出兼容性差异。不少大模型平台会发布新模型版本提示词在某一天突然变差多数原因是模型更新了但提示词没有配套调整。没有版本记录这种排查几乎无从下手。6.2 建立一个小型测试集没有测试集的提示词工程等于没有回归测试的代码。你不必准备上百条样本二十条足够覆盖常见情况。测试集里应当包含常规样本、边界样本、异常样本三类。常规样本保证基本功能正确边界样本比如超长文本、空字段、全大写文本保证提示词的鲁棒性异常样本比如输入中夹带恶意指令的场景保证模型不被带偏。很多平台会提供数据评测工具你也可以用简单的批量请求脚本跑测试。这里边最大的一个坑是为测试而测试测试集选得太简单提示词看起来无懈可击一上生产就崩。我的做法是从真实运行日志里随机抽取历史请求进入测试集每月更新一次。只有贴近真实数据分布的测试才有回归价值。6.3 评估维度准确、完整、规范、安全提示词效果的评估我习惯分四个维度打分。准确指核心任务是否完成完整指所有必要字段是否都有输出规范指格式是否严格符合约束安全指内容是否触碰合规红线。每个维度不是打一个笼统分而是对每个测试样本打通过或不通过再统计通过率。通过率低于 80% 的维度必须调整提示词而不是靠运气赌线上效果。安全维度要特别提一下。无论风格多激进、创意多开放提示词都不能让模型生成违背公序良俗或存在误导风险的内容。这既是价值底线也是工程稳定性要求。一个放任角色自由发挥的提示词可能第一次运行没问题第二次被带偏。持续检查安全维度不是限制创意而是保证输出长期可用。我个人在实际项目里踩过最多次的坑是兴致勃勃调出一个华丽的提示词模板满怀期待上线结果被少量边界样本打回原形。后来我把版本回退和测试集当成硬性流程质量和稳定性才真正稳定下来。这里边最值得记住的是一句话好的提示词不是一次写成的而是迭代出来的但每次迭代都需要能看见的证据而不是模糊的体感。若你手头正有几个用不顺手的提示词先别急着改句式按这个思路重建一遍版本记录大概率会发现很多问题根本不在措辞而在指令冲突和缺少约束。改掉这两点效果翻倍是常有的事。