1. 为什么提示词工程值得单独拎出来讲我接触大模型应用开发差不多两年多从最早拿API瞎试到后来带团队做Agent产品中间踩过的坑基本能写一本小册子。提示词工程这个词现在被说得有点烂很多人觉得不就是“会说话”吗但真正落到生产环境里你会发现同一个模型、同一个任务提示词差一句话输出质量能差出一个数量级。这不是玄学是实打实的工程问题。这篇文章想聊的是我自己的完整方法论从最基础的参数调优到思维链、ReAct、APE这些进阶技巧再到怎么把它们组合成一套可复用的工作流。适合谁看如果你已经在用大模型做产品、写Agent、或者做自动化流程但总觉得输出不稳定、调起来靠运气那这篇应该能帮你省不少时间。如果你刚入门也没关系我会把每个概念用生活化的例子讲清楚保证你能跟着操作。先说一个我自己的判断提示词工程的核心不是“写一句好话”而是控制模型的输出空间。模型本质上是一个概率分布你的提示词就是在这个分布上做条件约束。参数调优是在调分布的“形状”提示词技巧是在调条件的“精度”。两者缺一不可。很多人只关注提示词文本忽略了temperature、top_p这些参数结果就是“明明提示词写得很好输出还是飘”。下面我按自己的实战顺序一层一层拆开讲。2. 参数调优先把模型的“性格”摸清楚2.1 温度、top_p、top_k到底在调什么刚上手的时候我也觉得这些参数很抽象。后来我用了一个类比把模型想象成一个正在选词的作家。temperature决定这个作家有多“放飞”——温度低他永远选最稳妥的那个词温度高他愿意冒险选一些冷门但可能有创意的词。top_p是“只从概率最高的那堆词里选堆的大小由p决定”比如top_p0.9就是只考虑累计概率前90%的词。top_k更直接就是“只从概率最高的k个词里选”。这三个参数的关系是top_k和top_p是筛选范围temperature是在筛选后的范围里调整随机性。我实测下来的经验是不要同时大改三个参数否则你根本不知道是哪个起了作用。我的习惯是固定top_k和top_p只调temperature先找到合适的“性格”再微调范围。具体数值上我整理了一个自己常用的对照表任务类型temperaturetop_ptop_k说明代码生成0.1-0.30.940要确定性不能瞎编API数据抽取0.0-0.20.830几乎要完全确定文案创意0.7-0.90.9560要多样性允许发挥对话闲聊0.6-0.80.950平衡自然和稳定逻辑推理0.2-0.40.8540要严谨但别太死板这个表不是金科玉律但作为起点很稳。我试过在代码生成任务上把temperature开到0.8结果模型开始“发明”不存在的库函数排查了半天才发现是参数问题。2.2 那些容易被忽略的参数frequency_penalty和presence_penalty这两个参数很多人直接跳过但在长文本生成里特别关键。frequency_penalty是惩罚“已经出现很多次的词”值越高模型越不愿意重复。presence_penalty是惩罚“已经出现过的词”只要出现过就压一压不管出现几次。我踩过的坑做产品描述生成时模型总是反复用“高效”“便捷”这种词读起来很腻。把frequency_penalty调到0.5之后重复明显减少。但注意这两个值别开太大我试过开到1.5结果模型为了不重复开始用一些很别扭的同义词反而更奇怪。我的建议是0.3到0.8之间根据任务微调。还有一个max_tokens这个不是调“性格”的是调“篇幅”的。但有个细节如果你设得太小模型可能话说到一半被截断输出不完整设得太大又浪费token。我的做法是先跑几次看正常输出的token数然后设成平均值的1.5倍左右留点余量。2.3 参数调优的实操流程别靠感觉靠记录我见过太多人调参数就是“改一下跑一下感觉不行再改”。这样调一天也调不出所以然。我的流程是固定提示词先不动文本只调参数。准备一组测试用例至少10条覆盖典型场景和边界情况。每次只改一个参数其他保持不变。记录每次的输出用一个简单的表格打分比如1-5分。找到最优参数组合后再回头优化提示词。这个流程看起来笨但能帮你建立“参数-效果”的直觉。我大概跑了三四轮之后对什么任务该用什么参数就有感觉了后面调起来快很多。注意不同模型对参数的敏感度不一样。同一个temperature0.7在模型A上可能很稳在模型B上就飘了。换模型时参数要重新校准别直接套用。3. 提示词结构设计从“说清楚”到“说得巧”3.1 系统提示词和用户提示词的分工系统提示词是给模型定“人设”和“规则”的用户提示词是具体任务。很多人把两者混在一起写结果就是规则和任务纠缠模型容易顾此失彼。我的做法是系统提示词只放“不变的东西”——角色、输出格式、禁忌事项用户提示词放“这次要做什么”。举个例子我做代码审查助手时系统提示词是这样的你是一名资深代码审查员。你的输出必须包含三部分 1. 问题列表按严重程度排序 2. 每个问题的修复建议 3. 整体评分1-10分 不要输出任何与代码审查无关的内容。用户提示词就是直接贴代码加一句“请审查以下代码”。这样分工之后输出格式稳定了很多不会出现“有时候给建议有时候只给评分”的情况。3.2 少样本示例给模型“打个样”比说一百句都管用Few-shot是我觉得性价比最高的技巧之一。你不需要解释规则直接给两三个例子模型就能模仿。我试过做一个情感分类任务写了一大段规则说明准确率只有70%多后来改成给5个例子准确率直接到90%以上。但例子不是随便给的。我的经验是例子要覆盖不同类别别全是正面的。例子要包含边界情况比如模棱两可的。例子格式要完全一致输入输出对齐。例子数量3-5个通常够用太多会占token且可能过拟合。有个细节例子的顺序也有影响。我试过把最难的那个例子放最后模型表现更好可能是“近因效应”。这个不是绝对的但值得试试。3.3 输出格式约束让模型“填表”而不是“写作文”如果你需要结构化输出最稳的办法是在提示词里直接给出格式模板让模型填空。比如请按以下JSON格式输出 { sentiment: positive/negative/neutral, confidence: 0.0-1.0, keywords: [词1, 词2] }这比说“请输出JSON”要稳得多。我实测下来给了模板之后格式错误率从15%降到2%以下。如果模型还是偶尔跑偏可以在系统提示词里加一句“只输出JSON不要任何解释文字”。提示有些模型对JSON模式有原生支持比如通过response_format参数指定。如果你的模型支持优先用原生方式比提示词约束更可靠。4. 思维链与ReAct让模型“想清楚再动手”4.1 思维链把“黑盒”变成“白盒”思维链的核心就一句话让模型把推理过程写出来再给答案。为什么有用因为模型是逐token生成的如果直接让它给答案它可能“跳步”如果让它先写推理后面的答案就建立在前面推理的基础上逻辑连贯性会好很多。我试过一个数学应用题直接问答案模型经常算错加一句“请一步一步推理”正确率明显提升。但思维链不是万能的简单任务加了反而啰嗦。我的判断标准是任务需要多步推理就用不需要就不用。思维链的写法也有讲究。最基础的是“Lets think step by step”但这句话现在有点被用烂了效果不如以前。我更喜欢结构化思维链比如请按以下步骤分析 1. 提取题目中的已知条件 2. 确定需要求解的目标 3. 选择合适的公式或方法 4. 逐步计算 5. 验证结果是否合理这样模型不是“随便想想”而是按你给的框架想可控性更强。4.2 ReAct推理和行动交替进行ReAct是Reasoning Acting的缩写核心是让模型在推理和调用工具之间交替。比如做一个查询天气的AgentReAct的流程是Thought用户想知道北京天气我需要调用天气API。Action调用get_weather(北京)Observation返回“晴25度”Thought拿到结果了可以回答用户。Answer北京今天晴气温25度。这个模式的好处是模型不会瞎编它必须等工具返回结果才继续。我做过一个对比不用ReAct模型经常编造天气数据用ReAct之后准确率接近100%。ReAct的提示词模板我一般这样写你可以使用以下工具 - get_weather(city): 查询城市天气 - search(query): 搜索信息 请按以下格式输出 Thought: 你的思考 Action: 工具名(参数) Observation: 工具返回结果 ...重复直到得到答案 Answer: 最终答案关键点是格式必须严格否则解析器会挂。我踩过的坑模型有时候会自己编一个“Observation”而不是等真实工具返回。解决办法是在提示词里强调“Observation由系统提供你不要自己写”并且在解析时严格校验。4.3 思维链和ReAct怎么选这两个不是互斥的可以组合。我的经验是纯推理任务数学、逻辑用思维链就够了。需要外部信息的任务查数据、调API用ReAct。复杂任务可以先用思维链拆解再用ReAct执行每一步。有个细节ReAct的token消耗比思维链大因为多了Action和Observation。如果成本敏感简单任务别上ReAct。5. APE与提示词自动优化让模型自己写提示词5.1 APE是什么为什么有用APEAutomatic Prompt Engineering的思路是与其人工写提示词不如让模型生成一批候选提示词然后评估哪个最好。这个思路我第一次看到觉得有点“套娃”但实际用下来在特定场景下确实能省事。我的做法是先人工写一个“种子提示词”然后让模型基于它生成10个变体再用一组测试用例评估每个变体的效果选最好的那个。这个过程可以迭代几轮。我试过做一个文本分类任务人工调了半天的提示词准确率卡在85%用APE跑了两轮找到一个我没想到的表述方式准确率到了91%。5.2 APE的实操步骤和注意事项具体步骤准备种子提示词不用完美能跑就行。生成候选让模型“基于以下提示词生成10个不同风格的变体保持核心意图不变”。评估用测试集跑每个候选记录准确率或其他指标。选择Top 3再让模型基于它们生成新一轮变体。重复2-3轮直到提升不明显。注意事项评估集要够大至少50条否则波动太大。别让模型自己评估自己要用客观指标或人工标注。生成的变体要控制多样性否则可能全是同一种风格。成本要考虑APE会消耗不少token适合高价值任务。我个人的体会APE适合“你知道要什么但不知道怎么表达”的场景。如果任务本身定义不清APE也救不了。5.3 提示词版本管理别把好提示词弄丢了这个是我踩过的大坑。早期我改提示词就是直接在代码里改改着改着发现“还是三天前那版好”但已经找不回来了。后来我养成了习惯每个提示词都存版本用Git管理每次改动写清楚改了什么、为什么改、效果如何。我的提示词文件结构大概是prompts/ code_review/ v1.txt v2.txt v3.txt README.md # 记录每版的变化和评估结果README里我会写v2把“请检查代码”改成“请按严重程度列出问题”准确率从78%到85%。这样后面回溯很方便。6. 常见问题与排查技巧实录6.1 输出不稳定同样的输入结果不一样这是最常见的问题。原因通常有三个参数太随机、提示词有歧义、模型本身有波动。排查顺序先把temperature降到0看是否稳定。如果稳定了就是参数问题。如果temperature0还不稳定检查提示词是否有模糊表述比如“尽量”“可能”“适当”这种词。如果都排除了可能是模型服务端的波动这种情况只能通过重试或换模型解决。我遇到过一个案例提示词里写了“请简洁地回答”结果模型有时候给一句话有时候给三段。后来改成“请用不超过50字回答”就稳定了。模糊的形容词是稳定性的天敌。6.2 模型不遵守格式要求明明说了“只输出JSON”模型还是加了一句“好的以下是JSON”。解决办法在系统提示词和用户提示词里都强调格式双重保险。用负面示例“不要输出任何解释文字不要加‘好的’‘以下是’等前缀”。后处理兜底用正则提取JSON部分别完全依赖模型。如果模型支持用原生结构化输出。我现在的习惯是提示词约束 后处理兜底两层防护。纯靠提示词总有翻车的时候。6.3 长文本处理时模型“忘记”前面的内容这是上下文窗口的限制。我的应对策略关键信息放开头和结尾中间放次要内容。用分隔符明确分区比如用“### 背景 ###”“### 任务 ###”。如果太长先摘要再处理别硬塞。重要规则在系统提示词里重复一遍。我试过处理一份5000字的文档模型总是忽略中间的一段要求。后来我把要求拆成“系统提示词里的全局规则”和“用户提示词里的具体任务”问题就解决了。6.4 常见问题速查表问题可能原因解决办法输出太随机temperature/top_p太高降低到0.2-0.4输出太死板temperature太低提高到0.6-0.8不遵守格式提示词约束不够加模板负面示例后处理编造信息没有工具约束用ReAct强制等Observation忘记上下文上下文太长关键信息前置用分隔符重复用词没有惩罚参数加frequency_penalty推理跳步没有思维链加“一步一步推理”或结构化步骤工具调用格式错模板不清晰严格定义格式加解析校验6.5 几个我踩过的坑坑一提示词越长越好不是。我试过写一个800字的提示词结果模型反而抓不住重点。后来精简到300字效果更好。提示词要“信息密度高”不是“字数多”。坑二所有任务用同一套参数不行。代码生成和文案创意的参数需求完全不同必须分开配置。坑三忽略模型差异同一个提示词从模型A换到模型B效果可能差很多。换模型时提示词和参数都要重新校准。坑四不做A/B测试凭感觉改提示词很容易“改好了这个弄坏了那个”。一定要用测试集验证。7. 我的完整工作流从需求到上线7.1 需求拆解先想清楚要什么拿到一个任务我第一件事不是写提示词而是问自己输入是什么、输出是什么、怎么判断好坏。这三个问题想不清楚提示词写出来也是白写。比如做一个“会议纪要生成”功能输入是会议录音转文字输出是结构化纪要判断标准是“关键决策和待办事项是否完整”。想清楚之后提示词的方向就有了。7.2 快速原型先跑通再优化我的习惯是先写一个“能跑”的提示词参数用默认值跑几条测试用例看效果。这个阶段不追求完美只求“方向对”。如果方向不对后面怎么调都是白费。原型阶段我会特别关注模型是否理解任务、输出是否在预期范围内、有没有明显的格式问题。如果这三个都OK再进入优化阶段。7.3 迭代优化参数和提示词交替调优化阶段我会按这个顺序先调提示词结构把任务说清楚。再调参数找到合适的“性格”。加Few-shot示例提升稳定性。如果任务复杂加思维链或ReAct。最后用APE做一轮自动优化看有没有惊喜。每一轮都用测试集评估记录变化。我一般会跑3-5轮直到提升不明显为止。7.4 上线监控别以为调完就完了上线之后我会监控几个指标输出格式错误率、用户反馈、token消耗。如果格式错误率上升可能是模型更新了或者输入分布变了需要重新校准。我遇到过一次模型服务商悄悄更新了模型导致原来的提示词效果下降。后来我加了一个“提示词版本”字段每次请求都记录方便回溯。8. 一些零散但有用的经验关于提示词的语言中文任务用中文提示词英文任务用英文提示词混合任务看主要语言。我试过用英文提示词做中文任务效果不如中文提示词可能是模型的中文语料和英文语料的分布不同。关于特殊符号用###、---、这些分隔符能帮模型区分不同部分。我习惯用### 任务 ###这种格式清晰且不容易和内容混淆。关于角色设定给模型一个具体角色比泛泛的“你是一个助手”要好。“你是一名有10年经验的Python后端工程师”比“你是一个程序员”效果更好因为前者激活了更具体的知识分布。关于否定指令模型对“不要做什么”的遵守程度不如“要做什么”。与其说“不要编造数据”不如说“如果不知道请回答‘我不知道’”。正面指令更有效。关于测试集一定要有。没有测试集你就是在盲调。测试集不用大20-50条就够但要覆盖典型场景和边界情况。关于成本思维链和ReAct会增加token消耗APE更甚。上线前算一下成本别调爽了发现用不起。关于模型选择不是越大的模型越好。有些任务小模型加好提示词效果不输大模型成本还低。我一般会先用小模型试不够再换大的。关于提示词复用把常用的提示词片段抽出来比如“输出格式要求”“角色设定”做成模板用的时候拼装。这样维护起来方便也容易保持一致。关于文档每个提示词都写清楚用途、参数、测试结果。过一个月回头看你会感谢自己。关于心态提示词工程没有“银弹”就是一个不断试错和迭代的过程。别指望一次写好也别因为一次失败就放弃。我调过最久的一个提示词花了三天但上线后效果很稳值了。最后分享一个我最近在用的技巧让模型自己解释为什么这样输出。在提示词里加一句“输出答案后用一句话解释你的推理依据”。这样不仅能验证模型的逻辑还能帮你发现提示词里的歧义。我试过几次模型解释的时候暴露了我提示词里没说清楚的地方改完之后效果明显提升。这个技巧在调试阶段特别好用上线时可以去掉省token。