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，在提示词最末尾加一句“Let's 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应用的第一块基石。
