2026年了大语言模型的硬能力还在往上冲但真正决定产出质量的往往不是模型本身而是你递到模型面前的那段文字。这段文字业内叫提示词Prompt围绕它形成的一整套方法论就是提示词工程。说句实话我见过不少人手里攥着很强的大模型却因为提示词写得稀烂硬是把模型用成了人工智障。写“帮我生成一个方案”模型就回一份满是套话的框架写“帮我把这段文字润色一下”模型就把“很好”改成“非常出色”等于没改。反过来我也见过有人靠精心设计的几段提示词把同一个模型用出三倍效率。差距不在模型就在提示词上。这篇文章会把提示词工程这条完整路线捋一遍从零样本提示、少样本提示到链式思考Chain-of-Thought、自洽性再到思维树Tree of Thoughts。每一节都会配上可复用的写法、参数选择和实际踩坑记录。适合刚接触大模型的新手也适合已经用了一段时间、但总觉得输出不稳定的开发者。1. 提示词工程到底在解决什么问题1.1 一句话理解提示词工程大语言模型本质上是一个超大的“文字接龙”系统你给它一段前缀文字它根据训练阶段见过的海量文本模式逐字预测下一个词。这里真正要紧的是模型预测的是“最可能的下文”未必是“最正确的答案”。“最可能”和“最正确”之间的那条缝就是提示词工程的发力空间。提示词工程做的事情就是对输入文字做结构化设计——包括指令、上下文、示例、格式约束——把模型推向你真正想要的那条输出路径。它解决的问题非常具体让输出更准确稳定、控制输出格式以便程序解析、激发模型的推理能力而不是让模型跳步瞎猜以及在有限的上下文长度里用最小的成本换取最好的效果。我经常给初学者打一个比方大模型像一个知识量很大但理解力捉急的实习生。你交代任务的方式越模糊他越容易自由发挥你把背景、边界、交付标准都说清楚他才有机会干得靠谱。提示词工程就是“给实习生写任务单”的那套手艺。1.2 为什么2026年了还得专门学这个这两年大模型的能力肉眼可见地在涨有人说提示词工程迟早会被模型自己取代。我的判断是这个说法过于乐观。只要用户还是通过自然语言和模型交互输入文字的质量就永远是输出质量的杠杆。模型再强也不能替你把你脑子里那个不太成形的需求变成清晰指令。更重要的是提示词工程的地盘不止是“聊天”。你在做检索增强生成RAG时检索出的内容要靠提示词让模型“只依据给定材料回答”你在搭智能体Agent时工具调用的规则、任务拆解的步骤全都要写进提示词里你在写自动化数据流程时结构化的输出约束也全靠提示词控制。可以说提示词是上层应用和底层模型之间最直接的那层胶水。所以我的建议是别把提示词工程当成玄学也别当成替代深度学习的捷径。它就是一项基础技能——不需要你写代码但需要你系统性地练习和复盘。1.3 这篇文章的阅读路线内容是按难度递进排的。零样本和少样本是地基链式思考是第一次质变思维树是进阶玩法。不同基础的人可以这样看完全没接触过提示词的新手从第2节开始一路往下读中间不用跳。已经在日常工作中大量使用模型的人重点看第3节和第4节这两节是提升推理类任务效果的关键。遇到具体问题的人可以直接翻到第7节里面是常见问题速查。后面每个章节都会先讲清原理再给可复用的模板最后附上我在调试过程中遇到过的坑。你可以把它当成一篇“带注释的实战笔记”来用而不是看完就忘的科普。2. 从零样本到少样本提示词的地基2.1 零样本提示别小看“直接问”零样本提示Zero-shot指的是不提供任何示例只靠一句指令让模型完成任务。比如“把这句话翻译成英文”“把这封邮件按重要性排序”这些都是零样本。很多人每天都在用却不知道它有名字也远远没有把它用好。零样本提示的最大价值是低成本、高灵活适合边界清晰、模型“显然会做”的任务。但它的效果有个明显的滑坡点任务越复杂、输出越开放零样本就越不稳定。原因在于只有一句指令时模型需要自己猜测你心里的输出格式、详略程度和判断标准猜错太正常了。我自己踩过的一个典型坑是早期让模型做文本分类只写了一句“把下面这段文字分类为正面或负面”。模型确实分了类但结果不稳定有的输出“正面”有的输出“情感正面”还有的输出一长段解释。后来我意识到问题不在模型而在指令没有定义输出格式。零样本不是“随便写一句话”它同样需要把任务目标、输入范围和输出要求讲清楚。零样本提示的写法有一条底线把“做什么、输入是什么、输出长什么样”三件事写清楚。下面是一个很常见的对比写法提示词示例效果评价模糊帮我看看这段评论模型不知道你要干嘛输出开始自由发挥清晰判断这条商品评论的情感倾向只输出“正面”或“负面”两个词评论内容...任务边界清楚输出格式可控结果稳定提示零样本提示里最容易提升效果的一个动作不是加更多形容词而是定义输出格式。把“让模型自己决定怎么说”改成“你规定它怎么说”稳定性立刻上一个台阶。我们团队内部有一条不成文的规则每条提示词在发出之前先问一句“模型能一眼看出我要的输出格式吗”答不上来就先改提示词。2.2 少样本提示给模型找几个“参考答案”少样本提示Few-shot是在提示词里放入若干组“输入-输出”示例让模型按照示例的格式和逻辑回答新输入。写法不复杂效果却常常立竿见影——尤其是对格式敏感、判断标准比较主观的任务。举个例子。我想让模型判断商品评论的情感倾向并且保持输出格式统一。零样本版本只写“判断情感”效果不稳定少样本版本就可靠很多将下面的商品评论按情感分类只输出“正面”或“负面”。 正面电池续航很顶一整天重度使用还剩30% 负面连上蓝牙耳机以后一直断连体验很差 正面屏幕素质超出预期看视频非常舒服 负面边框缝隙大用了一个月就开始掉漆 评论系统很流畅就是有点发热 情感模型会照着示例的格式输出“正面”而且稳定得多。为什么几个示例的作用这么大因为示例同时完成了三件事第一锁定了输出格式第二展示了任务所需的判断粒度第三相当于给模型划定了搜索答案的范围。少样本提示还有一个隐藏用法用示例来做“定义”。如果有一个概念很难用文字说清比如某种内容风格你可以直接给三个符合该风格的例子让模型通过例子理解概念这比用抽象术语描述有效得多。我经常用这个办法辅助写风格化文案效果比任何形容词堆砌都好。2.3 样本怎么选效果差很多许多人以为示例随便从历史数据里捞几个就行实际上示例的选择非常影响效果。我总结出几条原则。第一示例要覆盖不同子类避免集中在单一模式。还是情感分类的例子如果三个示例都是“电子产品很满意”模型遇到“物流太慢”这种非电子产品的评论判断就会不稳。第二示例要和真实任务分布接近。你在生产环境里遇到的大多是中立、含混的表达示例就不要全是极端的“很喜欢”或“很差”加入一两条中性评论模型反而学得更准。第三数量不是越多越好。我实测过很多任务2到4个精心挑选的示例往往就够用继续增加到十几条效果提升趋近于零还可能因为上下文过长占用宝贵的token。第四示例顺序有影响。把最典型、和真实输入最像的示例放在最前面容错率更高。这不是什么高深理论是模型注意力机制带来的实际体验差异。提示如果你对某个示例本身没有把握宁愿不放。模型会模仿示例的所有特征错误示例比没有示例的杀伤力更大——它会“学会”你展示的错误模式。我自己就因此吃过亏有一次分类任务里放了一条标注错误的示例整整半天输出都是乱的最后去掉那条示例立刻恢复。所以在少样本提示里示例质量第一数量第二。2.4 提示词的核心组成要素把几十条有效提示词拆开看会发现它们普遍由三块构成角色与背景设定、任务指令、输入数据与输出要求。角色与背景设定解决“以什么身份、在什么情境下做事”的问题比如“你是一名资深数据分析师”或者“你在帮一位完全不懂技术的新手解释概念”。任务指令解决“具体要我干什么”的问题这里的关键是动词要具体——用“列出”“计算”“翻译”“判断”这类动作少用“处理”“分析一下”这类含糊词。输入数据与输出要求解决“处理什么、交付什么”的问题包括输入内容的边界、输出格式、长度限制、是否需要解释理由等。这三块平时不需要每次都写全。简单任务一句话就能搞定复杂任务才需要完整结构。但我建议你在写复杂提示词的时候脑子里始终有这个框架它会帮你发现自己漏了哪一块。很多人写提示词写到一半才发现忘了给输入或者忘了定义输出格式就是因为没有一个框架在脑子里兜底。3. 链式思考把推理过程摊开给模型看3.1 为什么“直接给答案”不如“给推理过程”做数学题、逻辑推理、多步规划时直接让模型给最终答案效果往往不稳定。打个比方一个人心算三位数乘法容易出错但让他拿起笔列出竖式每一步都写在纸上错误率大幅下降。链式思考Chain-of-Thought简称CoT干的就是这件事——先让模型把中间推理步骤写出来再给出最终结论。这个技巧刚提出时是配着示例用的在少样本示例里把推理过程也展示给模型看模型就会模仿这个“先想后答”的过程。原理上说模型生成中间步骤时每一步只做相对简单的“下一步”预测错误不会直接跨越多个逻辑步骤因此整体可靠性大幅提升。我在实际使用中对CoT的感受是推理类任务的提升幅度往往比换一个更大的模型还要明显。尤其是在数学应用、逻辑判断、路径规划这些场景里“请一步一步推理”这五个字看着朴实效果却堪称立竿见影。3.2 触发CoT的几种写法CoT的触发方式主要有三种成本从低到高排列。第一种是零样本CoT在提示词最末尾加一句“Lets think step by step”中文场景也可以写成“请一步一步推理再给出结论”。这种方式改动最小适合你不确定要不要给示例时先快速试一下。第二种是带上完整推理示例的少样本CoT。在示例里展示“先考虑什么再计算什么最后得到什么”模型会模仿整个推理结构。比零样本CoT更稳但要花更多token写示例。第三种是显式要求“给出理由”。适用于需要可解释性的场景比如“先说明你的判断依据再给出结论”。要注意顺序让模型先写推理再给结论。如果反过来模型先给结论再编理由编造的空间更大。用户小明有12个苹果分给3个朋友每人2个又买来5个请问现在有几个 要求请一步一步列出计算过程再给出最终答案。一个很常见的坑是在简单任务上也强制触发CoT结果模型开始长篇大论解释。你问“2加2等于几”它非要写一段“首先我们观察两个数字……”——这种过度解释不但浪费token还可能把很多事情搞复杂。我的习惯是只有“答案路径不止一步”的任务才用CoT。3.3 自洽性同一道题做多遍投票定答案CoT还有一个大名鼎鼎的进阶玩法叫自洽性Self-Consistency。思路非常简单同一个问题让模型用稍高的随机性比如把temperature调到0.7跑好几遍每遍都输出完整的推理过程和最终答案跑完5到10遍后把多个结果放在一起最终答案取多数票。为什么这招有效因为每条推理链都可能在某一步走偏。单个推理链的错误是随机的而正确的答案往往在多次采样中更容易重复出现。多跑几遍之后随机错误相互抵消真正的答案自然浮出水面。这相当于开了一场“小范围头脑风暴”模型自己当了好几个考生最后按多数人的答案交卷。自洽性的代价是成本API调用量翻5到10倍因此不要无脑用。我通常只在两类场景里启用一类是错误代价很高的任务比如生成关键代码逻辑另一类是模型回答明显不够稳定、多次运行结果飘忽不定的任务。日常简单问答完全不需要。3.4 温度参数与它的影响聊到自洽性就必须提温度temperature它是和提示词同等重要的参数但常常被忽略。温度控制模型的随机程度温度越低输出越保守、越倾向重复性选择温度越高输出越发散、越容易出现意料之外的内容。做提示词调试时我的建议是先把温度当作提示词的一部分共同调整简单固定答案的任务温度调低比如0到0.3需要创意、发散的任务温度调高比如0.7到1.0。零样本和少样本里说到的“稳定性问题”很多时候不是提示词写得不好而是温度太高。反过来自洽性方法需要多次采样有一定多样性所以温度反而不能设太低否则多次运行结果高度相似投票就没有意义了。4. 思维树从一条路变成一棵树4.1 思维树解决什么问题CoT的本质是让模型沿着一条推理路径走下去。问题一旦复杂到一定级别单一路径很可能走偏或者走进死胡同——就像下棋只顾一条线的棋手再强也会输给会多看几个分支的人。思维树Tree of Thoughts简称ToT正是针对这个短板出现的。ToT不要求模型一条路走到黑而是把推理过程展开成一棵树每一步生成多个候选思路逐个评估优劣选最有希望的分支继续深入如果某个分支走到尽头发现不对还能回溯到之前的节点换一条路再试。你可以把它理解成给模型装了一个“分支搜索自我评估”的外挂。这套思路听起来很学术落地时并不复杂。核心就三个动作生成候选思路、评估候选思路、选择并继续。下面我用一个具体的例子拆开讲。4.2 思维树的完整流程假设任务是一个多步骤规划安排一次团建要在预算内完成场地预订、餐饮、交通和天气预案。直接让模型出方案它会一次性输出一个粗糙的整体方案细节互相矛盾。改成ToT流程后做法是这样第一步拆解步骤把任务拆成几个关键节点比如确定人数和预算、选择场地、规划餐饮、安排交通、设计预案。第二步对每个节点让模型生成多个候选方案。第三步让模型或者你自己写规则对候选方案打分评估标准就是方案的合理性、成本、风险。第四步挑出得分最高的候选作为下一步的基础。第五步继续执行下一节点如果前一步选择导致后续无解或矛盾就回溯换一个候选。这个流程可以用一段伪代码来描述步骤列表 拆分任务() 当前方案 [] while 还有未处理的步骤: 候选列表 对当前方案生成N个候选思路 打分列表 评估(候选列表) 最佳候选 选择最高分() 当前方案.append(最佳候选) 如果 当前方案的可行性评估不通过: 回溯到前一步骤重新选择候选 返回 当前方案和普通CoT相比ToT最大的区别是显式引入“评估”和“回溯”。CoT遇到错路就一路错到底ToT至少给自己留了回头路。4.3 什么时候该用思维树什么时候别用ToT不是银弹它的成本相当高。每走一步都要生成多个候选还要评估和比较API调用次数比CoT高出一个数量级响应时间也显著拉长。所以用它之前先判断任务是不是真的需要“搜索式推理”。适合ToT的任务有这么几个特征存在多个可能的中间分支而且分支之间差异明显单次推理容易陷入死胡同需要回溯结果可以通过规则或模型进行相对客观的评估。典型场景包括数独、填字游戏、逻辑谜题、活动规划、多条件约束的资源分配。不适合ToT的场景包括简单查询、翻译、摘要、情感分类这类没有“多步分支”的任务。给这种任务上ToT完全是杀鸡用牛刀。我见过有人给“写一句欢迎语”套上ToT结果花了十几倍的时间产出的质量却并没有比直接写更好。4.4 思维树的成本控制技巧如果确认任务需要ToT怎么把成本控住我自己的做法是第一只在关键步骤做分支。不是每一步都需要生成5个候选前面几步可能直接推理就行到了真正容易走偏的决策点再分支。以活动规划为例统计人数这种步骤根本不需要分支真正需要多种方案的是“选场地”和“定交通方式”这种决策点。把分支集中在这些点上整个流程的调用次数会少很多同时保留了大部分收益。第二候选数量从3个起。很多人在第一次用ToT时觉得生成5个、8个候选才显得“全面”但实测下来3个候选和5个候选的效果差距很小token成本却差了将近一半。原因是真正有区分度的思路通常就那么一两个其余候选都是陪跑。所以我的建议是先设3个跑一遍观察输出质量不够再往上加。如果3个候选就已经能得到满意答案就别为了“安全感”多花那笔token钱。第三能写规则就不要让模型打分。模型评估的优点是灵活缺点是贵且不稳定同一个候选在不同温度下可能得到不同分数。在一些场景里合理的规则比模型评估更靠谱。比如在活动规划里我可以规定“预算超过5000直接淘汰”“交通时间超过2小时的方案扣10分”。这样评估步骤就从一次大模型调用变成了几条简单的代码比较成本几乎为零。当然规则写不了太复杂的情况还是得让模型来做评估但先用规则过滤掉明显不行的候选再用模型精评效果和成本都是最优解。第四设置回溯上限。让程序最多回溯两到三层防止模型在错误分支上无限折腾。我在早期测试时没有设上限有一次模型在一个错误分支上反复生成了十几个候选全部被评估为“不可行”但流程依然没有终止最后白白花掉了大量token。后来我在流程里加了一个回溯计数器超过上限后就直接返回当前最优解不再继续搜索。这个改动让整个ToT的平均耗时下降了大概四成产出质量并没有明显下降。所以不要迷信“无限搜索”工程上一定要给探索设置边界。5. 角色设定与系统提示词给模型一个“人设”5.1 角色扮演为什么有效稍微用过模型的人都知道在提示词里写“你是一名资深数据分析师”“你是小学老师”输出风格会在方向上发生明显变化。很多人觉得这是玄学其实背后有明确原理模型在训练阶段见过海量的角色化文本从“专家咨询”到“角色扮演对话”这些文本天然带有不同角色的语言风格和思维套路。你在提示词里指定角色等于把模型输出的概率分布往那个角色的方向拉了一把。用角色设定还有一个很实际的好处变相约束输出深度。我写“你是一名有10年经验的一线运维工程师”和写“请解释一下什么是反向代理”模型对解释的深度和专业度判断是不同的。角色设定能在不增加任何示例的情况下让模型自动调整术语密度、例子类型和说话口吻。不过角色设定不能替代清晰的指令。一个常见的误区是写了“你是资深专家”但任务指令含糊模型照样会输出一堆漂亮的空话。角色是管道指令才是水管道再高级水不清也白搭。5.2 系统提示词的写作框架在接入大模型接口时系统提示词就是那条“总纲”。我建议按五个部分写角色定位、任务边界、输出要求、约束条件、交付标准。角色定位写清楚“你是谁”任务边界写清楚“你要做什么不需要做什么”输出要求写清楚格式、长度、风格约束条件写清楚必须避免的行为交付标准写清楚“什么样的结果算合格”。下面是一个可以直接套用的参考模板【角色】你是一名资深内容策划擅长化繁为简。 【任务】把用户输入的文章改写成一篇适合在行业社区发布的分享笔记。 【要求】保持专业术语准确但用通俗的话解释总字数控制在500字以内结尾用一句个人经验收尾。 【约束】不新增原文没有的信息不使用“总之”“综上所述”这类模板化开头。 【交付】先输出改写后的正文再单独输出一句话说明本次改写保留了哪些核心信息。这个框架不是万能药但它能逼着你在设计系统提示词时想清楚每一件事而不是把需求憋成一个模糊的“帮我想想”。5.3 负面提示与约束条件怎么写才有效写“不要做什么”在提示词里是技术活。模型的训练目标里并没有真正的“否定”语义——当你写“不要提到成本”模型反而对“成本”这个词高度敏感更容易出现相关内容。这不是模型蠢是自然语言里否定机制本来就靠不住。更可靠的做法是正向描述期望行为。把“不要说废话”改成“直接给出结论不超过100字”把“不要出现错误”改成“在计算完成后检查一遍单位是否一致”。把注意力引导到“该做什么”上比反复强调“不要做什么”有效得多。如果确实有必须排除的内容可以把它表述为“除非……否则不要……”并且放在输出要求的后面作为补充规则而不是放在开头。位置也有讲究模型对长提示词前中段内容的遵循度通常不如首尾所以最重要的输出约束我一般放在开头和结尾两个位置各强调一遍。6. 实操指南四个高频场景的提示词模板6.1 代码生成场景程序员的日常里代码生成可能是最常用到提示词的场景。直接让模型“写一个XX函数”得到的结果往往只是“能跑”而不是“符合项目规范”。我的标准模板包含五个要素目标、约束、输入输出、边界、测试用例。请用Python实现一个函数功能是解析用户输入的逗号分隔字符串返回去重后的列表。 要求 - 兼容中英文逗号 - 不去重时保留原始顺序 - 空字符串返回空列表 - 需要处理结果包含空白字符的情况 请给出完整代码附带注释解释关键逻辑并给出三个测试用例。加上“附带注释”和“测试用例”之后模型输出的代码明显更完整也更容易直接接入项目。边界条件必须显式给出——“空字符串返回空列表”这一类需求在默认情况下模型通常不会替你想到。6.2 长文摘要场景长文本摘要最大的坑是“什么都想保留”结果摘要变成了浓缩版原文信息密度极低。给模型的摘要任务应该明确四个维度输入长度、摘要长度、保留要素、输出结构。下面是一段关于新能源汽车市场的调研报告请用200字以内的摘要概括。 要求 - 保留三个关键信息市场规模、主要趋势、潜在风险 - 只用客观陈述不添加评价 - 先写摘要正文再用一句话说明这份报告里最重要的一个数字是什么“先写摘要正文再单独说明关键数字”这种结构是我从多次实测里总结出来的小技巧——它逼着模型两条路走两遍第一遍压缩信息第二遍重新审视信息比只让模型“概括一下”可靠得多。6.3 数据分析场景让模型做数据分析时最容易出现的问题是模型直接给一堆泛泛的“趋势向好”“需要注意风险”这类废话。要治这个毛病关键是要求模型“先计算再解释”。把“分析一下这些数据”改成“根据提供的数据先算出具体指标再基于指标解读”。下面是某店铺一周的销售数据请先计算四个指标日均销售额、环比增幅、高销量商品Top3、低销量商品Top3。 然后基于这些指标用三点概括本周表现每一点都要引用指标数值。 数据 {数据}关键是要求每一条结论“都要引用指标数值”。这能有效约束模型不要凭空发挥同时也让结论具备可查证性。6.4 结构化输出场景做程序对接时结构化输出是刚需。直接让模型“输出JSON”它经常会多出markdown代码块标记或者字段名和你预想的不一致。解决办法是在提示词里把字段名和字段含义都写清楚然后给一个示例输出。请从下面的客户反馈中提取关键信息以JSON格式输出。 字段customer_name客户名称、issue_type问题类型取值只能为售后/物流/质量/其他、satisfaction满意度取值为1到5的整数、summary一句话总结 示例输出 {customer_name: 张先生, issue_type: 物流, satisfaction: 2, summary: 配送时间超过承诺客户不满} 反馈内容{内容}给示例输出这一步特别重要。对模型说“输出JSON”和给一个真实的JSON样例效果差距远超你的直觉。前者意味着模型需要自己猜测字段格式后者直接锁定了格式。另一个实用技巧是在提示词里加一句“不要输出JSON之外的任何文字包括markdown标记”可以省去程序侧大量清洗解析的工作。7. 常见问题与排查技巧7.1 输出不稳定同一问题每次回答都不一样这是遇到最多的一个问题。优先级从低到高的排查顺序是先看温度参数是不是太高。对固定答案类任务把温度降到0到0.3变化会立刻明显减小。再看少样本示例是否充分。如果任务本身有格式或标准加2到3个示例通常就能把输出拉回正轨。最后看是不是问题太开放。比如“介绍一下这个产品”这种任务模型每次组织语言的方式都不同可以把范围收紧成“列出该产品的三个优点每个用一句话说明并给出一个适用人群”。这三个步骤能解决大约八成的“不稳定”剩下的两成往往来自模型本身的采样随机性需要接受它或用自洽性方法投票解决。7.2 指令被忽略模型自说自话明明提示词里写了“只输出分类结果”模型还是输出了一大段解释。这种情况通常有两个原因。第一个原因是指令被淹没在长提示词里了。模型在处理长文本时对开头和结尾的内容保持注意力的时间更长中段的约束很容易被忽略解决方法是把关键约束移到开头或者末尾再强调一遍。第二个原因是指令和目标被示例带偏。如果少样本示例内部没有严格遵守“只输出分类结果”模型会学着示例的坏习惯来这时候检查示例并把示例也改成严格格式问题通常会很快消失。如果两招都试过了依然出问题还可以尝试把输出格式要求从“只是不要什么”改成“必须是什么”比如从“不要输出别的”改成“必须先输出分类词再另起一行输出理由”这样模型更容易执行。7.3 模型一本正经地胡说八道幻觉问题没法彻底消灭但可以在提示词层面显著压制。最有效的两招是要求模型只依据给定材料回答当材料里没有对应信息时明确说“未找到相关信息”以及要求模型在输出中标注信息来源或原文片段。不过要注意标注来源这招只在模型视野内有原文时才有效如果模型本来就没见过正确信息再怎么标注也救不了。所以面对高幻觉风险的任务优先做的是把参考材料喂给模型而不是指望它回忆训练数据里的内容。这也能顺便解决很多“知识过时”的问题。7.4 提示词太长token成本居高不下提示词长度问题比很多人想象中影响更大。定长的系统提示词放在每次请求里都会烧token积累起来成本可观。我建议定期做一次“提示词瘦身”把示例从10条减到3条观察效果是否还能保持把冗余的背景描述删除只留和当前任务相关的部分把长段落改成结构化要点对于启动成本高的大段示例考虑用模型离线生成一次把结果存下来避免每次请求都贴原文。曾经有一个内部工具提示词从800字压缩到300字后单次请求成本下降了超过一半输出质量几乎没有变化。压缩的核心原则是删冗余、留指令——示例和角色设定可以精简但输出格式和任务目标绝不能省。7.5 返回内容格式崩了结构化输出偶发崩坏是程序对接时最头疼的问题。除了第6节说的“给示例要求不要额外输出”之外还有两个补充手段。一是要求模型在数组或对象前后不要输出任何内容这个重复一遍确认。二是在代码里做容错截取第一个{到最后一个}之间的内容再尝试解析。这两招能救回绝大多数格式崩溃的场景。解析失败时与其让整个流程报错不如设计一次重试逻辑把上一次输出和强制格式要求一起再发给模型。我在实际项目里发现大多数格式错误在第二次重试时能自行修复真正需要人工介入的比例很低。8. 一些实操心得写到这里分享几个我在大量调试提示词后沉淀下来的习惯。第一条提示词也得很版本管理。我在本地建了个提示词库按任务类型分目录每次改动只改一处并把改动结果记录在一个简单的文档里。这听起来很笨但真的帮我省下大量重复调参时间。今天调好的提示词过两周哪怕原样贴回去也可能因为模型版本更新而效果漂移有历史记录才能快速定位。第二条调试顺序是“先简单后增强”。我见过很多人一上来就写了一大坨角色、示例、思维链结果效果不好都不知道是哪部分拖的后腿。我的惯例是先用最简版本跑通确认模型能在基础水平上完成任务再逐步增加示例、角色、CoT等技巧。每加一层都验证一次这样出了问题回滚掉最后加的改动就行。第三条温度也是提示词的一部分。不要只盯着提示词文本温度和采样参数对结果的影响经常比你在提示词里多写的两句话更大。调试时把参数和提示词一起记录才能复现结果。第四条最重要的体会是提示词工程的核心不是“把提示词写长”而是“想清楚任务本身”。所有技巧都只是手段——角色、示例、思维链的作用都是为了给模型划清边界、提供支撑。你对自己要解决的问题理解越深你的提示词就越有力。这个能力不依赖任何特定品牌的大模型换模型、换场景都不会过时。最后再提一个扩展想法思维树、自洽性这些方法完全可以固化成代码做成一个提示词编排层。以后你只需要提供任务和初始提示程序自动完成多分支生成、评估、回溯这些动作。我目前就把一套ToT流程封装成了内部工具跑规划类任务时不再需要手写一整段复杂提示词效果稳定很多。提示词工程不是终极终点它是通往更可靠AI应用的第一块基石。
