提示词工程这件事我一开始也走过不少弯路。最早我以为它就是个会说话就行的活儿——把需求写清楚模型自然给你想要的答案。结果真上手才发现同一个模型、同一个任务提示词差几个字输出质量能差出一个数量级。后来我花了大概半年时间把参数调优、思维链、ReAct、APE这些方法一个个拆开试踩了无数坑才慢慢摸出一套自己用着顺手的方法论。这篇就把我完整的思路和实操细节摊开讲从最底层的参数怎么调到高级的思维技巧怎么组合再到实际项目里怎么落地。不管你是刚接触提示词的新手还是已经写过一堆prompt但效果不稳定的老手应该都能从里面找到能直接抄作业的东西。1. 先搞清楚参数调优到底在调什么很多人一上来就猛写提示词完全忽略参数结果怎么改都差口气。我早期也是这样后来才明白提示词和参数是两套独立的杠杆得配合着用。提示词决定模型往哪个方向想参数决定模型想得多发散、多保守。这一节我把几个核心参数掰开讲清楚。1.1 temperature不是越低越好而是要看任务类型temperature控制的是输出的随机性。数值越低模型越倾向于选概率最高的词输出越确定、越保守数值越高越愿意选低概率词输出越发散、越有创意。我见过太多人无脑把temperature设成0觉得这样最准确。但实际上很多任务设0反而会出问题。比如创意写作、头脑风暴这类任务temperature0会让输出极其死板翻来覆去就那几个套路。而事实性问答、代码生成、数据提取这类任务确实应该往低了调。我自己的经验值是这样的任务类型推荐temperature原因数据提取/格式化输出0 ~ 0.2需要严格确定性不能有发挥代码生成/调试0.1 ~ 0.3需要准确但偶尔需要一点变通事实性问答0.2 ~ 0.4平衡准确性和表达自然度通用对话/客服0.5 ~ 0.7需要自然、有变化创意写作/头脑风暴0.8 ~ 1.0需要发散鼓励多样性诗歌/故事创作1.0 ~ 1.2追求意外性和艺术感注意不同模型对temperature的敏感度不一样。有的模型0.7就已经很发散了有的模型1.0还挺稳。换模型的时候temperature一定要重新试不能直接搬。还有一个细节temperature和top_p不要同时调。这俩都是控制随机性的同时调会互相干扰很难判断到底是哪个参数在起作用。我的习惯是固定top_p1只调temperature这样变量单一好定位问题。1.2 top_p采样池的水位线top_p又叫核采样nucleus sampling它的逻辑是把所有候选词按概率从高到低排累加概率到top_p为止只从这个核里采样。比如top_p0.9就是只从累计概率前90%的词里选。和temperature的区别在于temperature是改变概率分布的形状top_p是截断概率分布的范围。temperature调高所有词的概率差距被拉平top_p调低直接砍掉尾部低概率词。实际用下来我的建议是新手先只调temperature把top_p固定在1.0。等你对temperature的手感很熟了再考虑用top_p做精细控制。因为top_p调低会让输出变得安全但平庸很多时候你以为是提示词的问题其实是top_p把好词都砍掉了。1.3 max_tokens别让它成为隐形杀手max_tokens限制的是输出长度。这个参数看起来简单但坑特别多。第一个坑设太小输出被截断。模型话说到一半突然停了你以为是模型能力问题其实是max_tokens不够。尤其是让模型做推理、写长文的时候一定要留足余量。第二个坑设太大模型会注水。有些模型发现你给了很大的输出空间会不自觉地啰嗦把一句话能说清的事展开成三段。这时候反而要主动限制max_tokens逼它精炼。第三个坑max_tokens和上下文窗口的关系。输入输出不能超过模型的总上下文窗口。如果你输入很长max_tokens又设得很大可能会直接报错。我一般会先算一下总窗口 - 输入token数 - 安全余量200左右 可用的max_tokens。1.4 频率惩罚和存在惩罚控制重复的利器frequency_penalty和presence_penalty这两个参数很多人根本不用但在特定场景下特别有用。frequency_penalty按词出现的次数惩罚出现越多惩罚越大用来压制复读机现象。presence_penalty只要词出现过就惩罚不管出现几次用来鼓励模型引入新话题、新词汇。我的经验做长文生成时frequency_penalty设0.3~0.5能明显减少重复做头脑风暴时presence_penalty设0.3~0.6能让模型给出更多不同角度的点子。但这两个值都别设太高超过1.0容易让输出变得不连贯、逻辑断裂。1.5 参数调优的实操流程说了这么多参数实际怎么调我总结了一个流程先固定提示词只调参数。提示词不动把temperature从0.2到1.0每隔0.2试一遍看输出变化趋势。找到大致区间后做精细扫描。比如发现0.5~0.7之间效果最好就再试0.5、0.6、0.7。参数定下来后再优化提示词。这时候提示词的改动效果才能被清晰观察到。换模型必须重新调参。不同模型的默认行为和参数敏感度差异很大不能直接迁移。这个流程看起来笨但能帮你建立对参数的肌肉记忆。调多了之后你看到任务类型就能大概猜出该用什么参数区间。2. 提示词的结构化写法让模型不再猜参数调好了接下来是提示词本身。我发现一个规律新手写提示词像发微信老手写提示词像写需求文档。区别在哪结构化。模型不会读心术你给的信息越结构化、越无歧义它输出就越稳定。2.1 角色、任务、约束、格式四件套缺一不可我现在写任何提示词都会先过一遍这四件套角色Role告诉模型你是谁。比如你是一位有十年经验的Python后端工程师。角色设定能激活模型在相关领域的知识输出更专业。任务Task明确要做什么。用动词开头一句话说清。比如审查以下代码并找出潜在的性能问题。约束Constraints说明不能做什么和必须满足什么。比如不要修改原有逻辑必须兼容Python 3.8。格式Format规定输出长什么样。比如用Markdown表格输出三列问题、严重程度、修复建议。这四件套里格式约束是最容易被忽略但收益最大的。你只要把输出格式规定死模型输出的可用性会大幅提升。因为很多时候我们不是要模型想得多好而是要它输出得能直接用。2.2 少样本示例比长篇解释管用十倍有段时间我特别爱写长篇大论的提示词把各种情况都解释一遍。后来发现给两三个示例比写五百字解释管用得多。这就是few-shot prompting。示例的写法有讲究示例要覆盖边界情况。别只给典型例子把容易出错的边界情况也放进去。示例格式要完全一致。输入输出的格式、标点、换行都要统一模型会模仿这个模式。示例数量2~5个比较合适。太少不够说明模式太多会占用上下文还可能导致过拟合。示例顺序有影响。模型对最后几个示例的印象更深把最重要的示例放最后。我做过一个对比同一个分类任务纯文字说明的准确率大概70%加3个示例后直接到90%以上。示例的性价比极高。2.3 分隔符把不同信息块隔开当提示词里包含多种信息指令、背景、输入数据、示例时一定要用分隔符隔开。常用的有三引号输入数据XML标签input.../inputMarkdown标题## 输入数据分隔线---我个人的偏好是XML标签因为模型对标签结构的识别很稳而且标签可以嵌套适合复杂结构。比如task提取以下文本中的公司名称和融资金额/task examples example input某某科技完成A轮融资5000万元/input output公司某某科技金额5000万元/output /example /examples input某某智能获得B轮2亿元投资/input这种写法模型几乎不会搞混哪部分是示例、哪部分是真实输入。2.4 输出格式的强约束技巧如果你需要模型输出JSON、XML这类结构化数据光说请输出JSON是不够的模型经常会在JSON前后加解释文字。我的做法是明确说只输出JSON不要任何其他文字。给出JSON的schema或示例。在提示词末尾再强调一次格式要求模型对末尾内容印象深。必要时用预填充prefill有些API支持你预先填好输出的开头比如直接填{模型就会接着往下写JSON不会加废话。预填充这个技巧特别实用能省掉大量后处理代码。如果你的API支持强烈建议用起来。3. 思维链与推理增强让模型想清楚再答参数和结构都搞定后就该上高级技巧了。第一个要讲的就是思维链Chain of ThoughtCoT。这个技巧的原理很简单让模型把推理过程写出来再给答案准确率会显著提升。因为模型在生成推理步骤的过程中相当于做了更多的计算把复杂问题拆解了。3.1 零样本CoT一句让我们一步步思考的威力最早的CoT需要给示例后来发现只要在提示词末尾加一句Lets think step by step让我们一步步思考模型就会自动展开推理。这就是零样本CoT。我实测下来这句话对数学题、逻辑题、多步推理任务的提升非常明显。但要注意不是所有任务都适合。简单的分类、提取任务加这句话反而会让输出变啰嗦。中文场景下请一步步分析或先分析再回答效果类似但具体措辞要试。有些新模型已经内置了推理能力加这句话可能没效果甚至干扰要看模型特性。3.2 自洽性采样多跑几次投票自洽性Self-Consistency是CoT的升级版同一个问题用较高的temperature跑多次得到多个推理路径和答案然后投票选出现最多的答案。这个方法的逻辑是正确答案往往有多条推理路径都能到达而错误答案的推理路径比较随机。所以多次采样后正确答案会聚集。实操要点temperature设0.5~0.8太低的话每次输出都一样投票没意义。跑5~10次比较合适太少投票不可靠太多成本高。适合有确定答案的任务比如数学、逻辑推理。开放性问题不适合。我用这个方法做过数学应用题单次准确率大概75%跑7次投票后能到90%左右。代价是token消耗翻了7倍所以要权衡成本和准确率。3.3 思维树把线性推理变成树状探索思维树Tree of ThoughtsToT更进一步不只让模型线性推理而是让它同时探索多个思路评估每个思路的前景然后选择最有希望的继续深入。这个方法适合需要试错和回溯的任务比如解谜、规划、创意设计。实现上一般需要多轮调用让模型生成多个可能的下一步思路。让模型评估每个思路的可行性。选择最优的几个继续展开。重复直到得到答案。ToT的效果确实好但实现复杂、token消耗大一般任务用不上。我建议先把CoT和自洽性用熟遇到真正复杂的规划问题再考虑ToT。3.4 推理增强的常见坑讲几个我踩过的坑推理过程太长导致答案被截断。模型洋洋洒洒推理了一大段结果max_tokens不够答案没出来。解决办法是留足输出空间或者在提示词里限制推理长度。模型假装推理。有些模型会写一堆看起来像推理的话但其实是套话没有真正拆解问题。这时候要给它更具体的推理框架比如先列出已知条件再列出未知量再建立关系。推理和答案不一致。模型推理过程得出A最后答案却写B。这种情况在长推理里偶有发生解决办法是让它根据上述推理最终答案是。4. ReAct框架让模型会用工具ReActReasoning Acting是我认为最实用的高级技巧之一。它的核心思想是让模型在推理和行动之间交替——先想一步决定要不要调用工具看工具返回结果再想下一步直到解决问题。4.1 ReAct的基本循环ReAct的循环是这样的Thought思考模型分析当前状态决定下一步做什么。Action行动模型选择一个工具并给出调用参数。Observation观察工具返回结果喂回给模型。重复1-3直到模型认为可以给出最终答案。这个框架让模型从闭卷考试变成开卷考试——它可以查资料、算数、调API能力边界大大扩展。4.2 手写一个ReAct循环不依赖任何框架纯手写ReAct循环其实不难。核心就是一个while循环def react_loop(question, tools, max_steps10): prompt build_react_prompt(question, tools) for step in range(max_steps): response call_llm(prompt) # 解析response判断是ThoughtAction还是Final Answer if Final Answer: in response: return extract_final_answer(response) action, action_input parse_action(response) observation tools[action](action_input) prompt f\n{response}\nObservation: {observation}\n return 达到最大步数未得到答案关键点在于提示词的设计要让模型严格按照Thought: ... Action: ... Action Input: ...的格式输出这样才好解析。格式一旦跑偏解析就会失败。4.3 工具设计的原则ReAct的效果很大程度上取决于工具设计。我的经验工具描述要清晰。模型靠描述来判断什么时候用哪个工具。描述里要写清楚这个工具做什么什么时候用输入格式是什么。工具粒度要合适。太粗一个工具干所有事模型不会用太细几十个工具模型会选错。一般5~10个工具比较合适。工具要能容错。模型给的参数可能不对工具要返回清晰的错误信息让模型能自我纠正。工具返回结果要简洁。返回一大堆无关信息会占用上下文还可能干扰模型判断。4.4 ReAct的常见失败模式死循环模型反复调用同一个工具得不到有用信息。解决办法是设max_steps上限或者在提示词里提醒如果多次尝试无果请给出当前最优答案。格式跑偏模型不按Thought/Action格式输出。解决办法是给示例并且在解析失败时重试。工具选择错误模型选了不合适的工具。这通常是工具描述不够清晰或者工具太多。忽略观察结果模型看到工具返回结果后还是按自己原来的想法走。这时候要在提示词里强调必须基于Observation继续推理。5. APE让模型自己优化提示词APEAutomatic Prompt Engineering是个很有意思的思路与其人工反复改提示词不如让模型自己生成一批候选提示词然后评估哪个最好。5.1 APE的基本流程让模型针对任务生成多个候选提示词比如10个不同角度的。用每个候选提示词跑一批测试样本得到输出。评估每个候选提示词的输出质量可以用模型打分也可以用准确率等指标。选择得分最高的提示词或者把几个好的片段组合起来。这个方法的好处是能跳出人的思维定式。我自己写提示词容易陷入固定套路让模型生成候选经常能冒出一些我没想到的角度。5.2 评估环节怎么做APE的难点在评估。如果任务有标准答案比如分类、提取直接算准确率就行。但如果是开放任务比如写作、摘要评估就麻烦。我的做法是用另一个模型实例做评估给它评分标准让它打分。多维度评估准确性、完整性、格式合规性、简洁性分别打分。人工抽检模型评估只能做粗筛最终还是要人工看一批样本。5.3 APE的适用边界APE不是万能的。它适合任务定义清晰、有明确评估标准的场景。需要大量提示词变体的场景。人工调优遇到瓶颈的场景。它不适合任务本身模糊、没法评估的场景。对延迟敏感的场景APE要跑很多次调用。一次性任务投入产出比不划算。6. 把技巧组合起来一个完整的实战案例光讲技巧容易散我用一个实际案例把前面的东西串起来。任务是从一堆用户反馈里提取问题、分类、并给出优先级建议。6.1 任务拆解与方案设计这个任务可以拆成三步提取每条反馈的核心问题。把问题分类功能缺陷、体验问题、需求建议等。根据出现频率和严重程度给优先级。我决定用结构化提示词 few-shot示例 CoT的组合。参数上提取和分类用temperature0.2保证稳定优先级建议用temperature0.5允许一点判断空间。6.2 提示词的具体写法role你是一位资深的产品经理擅长从用户反馈中提炼关键信息。/role task分析以下用户反馈完成三件事 1. 提取每条反馈的核心问题一句话 2. 将问题分类功能缺陷 / 体验问题 / 需求建议 / 其他 3. 给出优先级建议高 / 中 / 低并说明理由/task constraints - 核心问题要具体不要泛泛而谈 - 分类只能从给定类别中选 - 优先级判断要考虑影响用户范围、严重程度、修复成本 /constraints examples example input每次打开App都要重新登录太烦了/input output 核心问题登录状态无法保持每次打开需重新登录 分类体验问题 优先级高 理由影响所有用户每次使用都触发严重损害体验 /output /example /examples format 用Markdown表格输出列为序号 | 核心问题 | 分类 | 优先级 | 理由 /format input [用户反馈内容] /input6.3 实测效果与迭代第一版跑下来提取和分类都不错但优先级判断偏保守大部分都给了中。我分析原因是提示词里没给优先级的具体标准。于是加了一段优先级判断标准 - 高影响超过50%用户或导致核心功能不可用 - 中影响部分用户或影响非核心功能 - 低影响少数用户或有替代方案加上标准后优先级分布合理多了。这个迭代过程说明模型输出不符合预期时先别怪模型看看是不是自己没把标准说清楚。6.4 成本和效果的权衡这个任务如果用最贵的模型跑效果最好但成本高。我的做法是分层提取和分类用便宜模型优先级判断用贵模型。因为提取分类是相对确定的任务便宜模型够用优先级判断需要更多判断力值得用贵模型。这种分层策略在实际项目里很实用能在效果和成本之间找到平衡点。7. 我踩过的那些坑和总结出的经验最后分享一些零散但实用的经验都是真金白银换来的。7.1 提示词不是越长越好我早期有个误区觉得提示词写得越详细越好结果写了一大堆模型反而抓不住重点。后来发现提示词的关键是信息密度不是长度。每句话都要有明确目的没用的客套话、重复强调都删掉。一个精炼的200字提示词往往比啰嗦的800字效果好。7.2 换模型要重新验证不同模型对同一提示词的响应差异很大。有的模型吃few-shot有的模型更吃指令有的模型对格式敏感有的模型对角色设定敏感。换模型后一定要拿一批测试样本重新跑一遍别想当然地直接迁移。7.3 建立自己的提示词库我现在维护着一个提示词库按任务类型分类每个提示词都记录了适用场景、参数配置、实测效果、迭代历史。这样遇到类似任务可以直接复用和微调效率高很多。提示词工程很大程度上是经验活积累很重要。7.4 别忘了评估很多人写完提示词看几个输出觉得还行就上线了。这是大忌。一定要建评估集哪怕只有几十条也要有。评估集能帮你客观判断改动是变好了还是变差了避免感觉变好了的错觉。7.5 保持对模型更新的关注模型迭代很快今天好用的提示词明天可能就失效了也可能新模型直接内置了你费劲实现的技巧。所以要保持关注定期回归测试。我一般每个月会把核心提示词在新模型上跑一遍看看有没有变化。这套方法论不是一天形成的是在一个个项目里磨出来的。核心就一句话把提示词工程当成一门需要实验和度量的工程学科而不是玄学。参数要调、结构要设计、技巧要组合、效果要评估每一步都扎实做输出质量自然就稳了。