开门见山说一句：把大模型用好，真正的分水岭不在模型选得有多新，而在提示工程做得有多扎实。这些年我接手过不少大模型实战项目，也带过团队，发现一个非常普遍的现象：同一位开发者，用同一个模型，写提示的方式不同，产出质量能差出好几倍。提示工程不是网上传的“念几句咒语”，它是一套可以被学习、被复现、被迭代的方法，也是目前普通人驾驭大模型投入产出比最高的技能。这篇文章不聊虚的，主要讲清楚三件事：提示词为什么能改变模型输出、一套结构化提示词怎么写、遇到模型不听话时怎么排查和修正。无论你是做研发、做产品、做运营，还是纯粹想用大模型提效率的内容创作者，这篇文章都值得你花二十分钟读完。
先说一个我常跟团队打的比方。大模型就像一个知识面极广但极度依赖指令的同事：你只跟他说“把方案写了”，他大概率会交给你一份四平八稳但毫无亮点的东西；你告诉他目标、受众、结构、风格、禁忌和参考样例，他就能交出一份接近可用的初稿。提示工程干的事情，就是把需求从“随口一提”变成“结构化任务书”。这话听着简单，做起来有大量细节，下面我从原理到实操一层层拆开讲。
1. 为什么提示工程是大模型实战的第一道门槛
1.1 提示工程到底是什么
一句话版本：提示工程是通过设计输入给模型的自然语言指令，来稳定、可控地激发模型能力的技术。
很多人第一次用大模型，觉得这东西“有手就行”，能打字就能用。确实，使用门槛很低，但“能用”和“用好”是两回事。早期的模型能力有限，随便问和精心设计提示，差距没那么明显；现在的模型能力上来了，反而更考验使用者的表达水平。就像一辆动力很强的车，排量摆在那，但你能不能把这股动力平顺地发挥出来，取决于驾驶技术。提示就是你的方向盘和油门。
我在实际项目中会把提示词当成“需求文档”来看待。一份好的需求文档，要有背景、目标、范围、验收标准、注意事项；一份好的提示词，同样要有任务指令、上下文信息、输出格式、约束条件和参考样例。把这几样写清楚，模型才能稳定输出你想要的东西。
1.2 模型越强，越考验“问问题”的水平
我做过一个粗糙但很有说服力的对比测试：随便挑了二十个日常任务，包括写周报、提炼会议纪要、生成SQL、分析数据、给产品起名等，一半用非常口语化的提问（比如“帮我写个周报”），一半用结构化的完整提示。同样跑一遍，结构化提示的一次通过率，比口语化提问高出一倍以上，而且输出内容的可用性差距很大。口语化提问得到的回答常常要二次修改，结构化提示得到的回答基本贴脸可用。
这里有个值得注意的趋势：模型的基础能力在快速提升，但提示工程的杠杆作用没有变小，反而变大了。原因很简单，模型越强，它能完成的任务跨度越大，如果你给的信息足够清楚，它就能把更强的能力发挥出来；反过来，指令模糊，它能力再强也只能靠猜。猜对了算运气，猜错了你还要返工。
从投入产出来看，提示工程也是性价比最高的方向。它不需要你懂模型训练，不需要标注数据，不需要部署复杂框架，只需要你把自然语言表达这件事做到极致。对一个团队来说，花两周时间把核心成员的提示工程水平拉齐，比换一个更大的模型带来的收益往往更明显。
1.3 先认清提示的边界，才不会被反噬
强调提示工程重要，不代表它是万能的。我见过一些人误以为“只要提示写得好，什么都能搞定”，结果踩坑之后反过来抱怨大模型不行。提示工程的边界，最好提前说清楚。
提示词改变不了三样东西：一是模型训练时的知识截止时间，它不知道截止日期之后的新事件；二是模型本身的推理上限，一个模型如果原本就解不出某类复杂数学题，提示写得再花哨也没用；三是模型没有外部实时信息，除非你另外接上检索工具或外部数据源。提示工程能做到的，是把模型已经具备的能力稳定地激发出来，控制它输出的格式和风格，引导它使用更可靠的推理路径，并在一定程度上抑制幻觉和错误。
所以正确的心态是：提示工程能帮你把模型的能力用到八成以上，但不能无中生有地创造模型不具备的能力。理解了这一点，你才能真正把精力花在“通过提示把需求表达清楚”上，而不是对着模型念咒语。
2. 提示词结构化：把需求说清楚的底层框架
2.1 建议所有提示词都包含的五个部件
我拆解过大量实战效果稳定的提示词，发现它们基本都离不开五个部件：角色、背景、任务指令、输出规则、参考示例。
- 角色：告诉模型“你现在以什么身份来回答”，比如“你是一名有十年经验的资深数据库工程师”。
- 背景：补充任务相关的前置信息，包括目标读者是谁、这个任务用在什么场景、你已经做过哪些尝试。
- 任务指令：用一两句话把要模型做的事情说清楚，比如“请从以下会议记录中提炼出行动项”。
- 输出规则：规定回答的结构、格式、长度、语言风格、不能出现什么。
- 参考示例：给一个“输入什么、期望输出什么”的样例，帮助模型对齐你的期望。
不是所有任务都要写满五件套。任务越复杂、越重要，越值得把五个部件补全；简单任务，比如“把这段话润色得更口语化”，只需要任务指令加一句输出规则就够了。但只要你遇到一次“输出完全跑偏”的情况，大概率就是这五件套里缺了某一块。
2.2 角色与背景到底怎么写才有效
角色设定的作用，是引导模型调用特定领域的词汇、思维方式和表达习惯。同一句话，你让“你是AI助手”去回答，和让“你是一名专注于企业服务领域的资深产品顾问”去回答，后者给出的用词、分析维度、结论颗粒度都会明显更专业。这不是玄学，而是模型在训练阶段学习过大量不同角色的语料，角色设定相当于帮它选择了更合适的“说话频道”。
我自己测试下来，角色写得越具体，效果越明显。比如“你是有十年企业数字化转型咨询经验的专家”就比“你是专家”要好。但注意不要过度堆砌头衔，一大串“资深的、顶级的、业界知名的”反而会让模型输出油腔滑调。写角色时也要和任务匹配：你让模型写代码，就别给它设置“文学评论家”的角色，这是常识，但在实际提示词里经常能看到这种错位。
背景信息的作用是减少模型猜谜的空间。我曾经让模型写一份“市场推广方案”，结果它默认目标受众是C端用户，产出的方案完全不适用，因为这是个B端SaaS产品发布会。后来我在背景里明确写上“产品是面向企业客户的办公协同软件，推广对象是企业IT负责人，预算约十万元，周期一个月”，产出立刻就可用了。背景信息里最值钱的内容是：谁在用、解决什么问题、用什么口径、有哪些限制条件。
2.3 输出规则：把模型的回答从“可用”变“好用”
很多人写提示词，只写了任务，忘了写输出规则，模型就按照它最习惯的“总分总”文章结构给出一大段正确的废话。输出规则至少应该包含三点：格式、长度、风格。
格式方面，你可以要求“用Markdown表格输出”“按JSON格式返回”“每一条要点前面加序号”等等。这里有一个小技巧：如果你需要结构化程度很高的输出，直接给模型一个模板让它填，比用语言描述格式高效得多。比如做信息提取，你给它一个JSON样例，它就能照着样例输出。
长度方面，与其说“写短一点”，不如给具体约束。“控制在300字以内”“每条不超过一百字”“只输出结论不输出过程”，效果都要比模糊的“简洁一点”好得多。风格方面也是如此，你可以要求“使用口语化表达”“避免‘首先其次再次’式结构”“每一段都用一个生活化类比开头”，这些规则会让输出明显更有个性。
我强烈建议在输出规则里加上“不做的事”。比如“不要道歉”“不要解释你的思路”“不要输出与结论无关的内容”。模型有个毛病，特别喜欢在前面加一句“作为一名AI助手，我无法……”，或者在回答结束后来一段总结升华，这些都可以用明确的“不做清单”压掉。
2.4 用分隔符和结构标记降低指令混淆
当提示词里既有背景、又有资料、又有好几条要求时，模型有时会搞不清哪些是“要处理的内容”、哪些是“要执行的指令”。一个简单且有效的做法是用明确的标记把不同区块分隔开。
比如我常用的模板是：
请完成以下任务。 ### 任务 写一段200字以内的产品功能说明。 ### 背景 产品是一款面向企业用户的在线表单工具，用户多为行政和人事人员，非技术背景。 ### 要求 - 说明“表单逻辑设置”这个功能的价值； - 用生活化类比解释； - 不要使用专业术语； - 输出只包含正文，不要标题。 ### 参考样例 （这里放一段你期望风格相近的文字）我用###这样的符号，而不是仅仅换行，是为了让模型更明确地识别“指令边界”。你还可以用三引号把参考资料包起来，用破折号分割不同章节。对于超过一个屏幕的长提示，这些标记能明显减少“模型把指令和资料混在一起”的情况。另外有一个容易被忽略的点：提示词越长，指令越容易被淹没在中间位置，所以最重要的任务指令要么放在最前面，要么放在最后面，尽量别卡在中间。
3. 实战：五个高频场景的提示词方案
3.1 内容创作场景：从“正确的废话”到可用初稿
内容创作是大模型最常用的场景之一，但也是“正确的废话”重灾区。直接说“帮我写一篇公众号推文”，模型通常会给你一篇结构工整、内容空洞的文章。我用来救场的提示词框架大致是这样：
你是一名资深自媒体编辑，公众号主攻职场效率方向，读者是25-35岁职场白领。 请围绕“高效开晨会”这个话题，写一篇公众号推文初稿。 要求： 1. 标题给出3个候选，风格要有反差； 2. 开头100字内直接抛出一个让读者有共鸣的场景； 3. 正文分3个部分，每部分先给操作步骤，再配一个反例和正例的对比； 4. 每个部分结尾用一句话总结； 5. 语气口语化，不要用“总而言之”这类总结词； 6. 全文1200字左右。 参考风格： （粘贴一段你平时觉得不错的文章开头）这个提示的关键在于：既定义了读者画像，又锁定了结构，还给出风格锚点。很多人写内容类提示时只关心“写什么主题”，不关心“写给谁、什么结构、什么语气”，模型就只能按它默认的方式输出。另外，初稿是用来改的，别指望模型一稿定型。我会在初稿基础上继续发几个迭代指令，比如“第二部分的例子换成财务人员工作场景”“结尾加一句行动号召”，这样出来的稿子已经接近可直接发布的水平。
3.2 代码生成与调试场景：让模型先分析原因再动手
让大模型写代码，最忌讳的是直接甩一段报错让它“修复”。模型经常不分析原因，直接给你一个表面能过、实际埋雷的改动。我在代码类提示中会强制加入两个步骤：先解释问题根因，再给出修改后的代码。
你是一名资深后端开发工程师。 请分析下面这段Python代码中存在的问题，并修复它。 ### 代码 （粘贴你的代码） ### 报错信息 （粘贴完整报错栈） ### 环境 Python 3.10，使用pandas 2.0，运行在Linux服务器。 ### 要求 1. 先列出可能导致报错的3个原因，并说明哪个最可能； 2. 给出修复后的完整代码，只输出代码块，不要额外解释； 3. 如果修复涉及外部依赖变化，额外用一行说明； 4. 不要修改原始函数的签名。“先列出可能原因再给代码”这个设计，是为了逼模型走一遍推理而不是凭检索凑答案。我在实践中发现，只要加上这一步，修复正确率明显提升。还有一个细节：务必提供代码运行环境和依赖库版本。模型对版本差异很敏感，明明是新版API移除了某个参数，它可能还在给你旧版写法。
调试场景还有一个容易踩的坑：不要一次性塞入几百行代码让模型“找问题”。模型处理超长代码时会顾此失彼，建议只保留相关的函数和调用点，把无关的初始化过程用注释代替。你帮模型减轻负担，模型才能帮你看清问题。
3.3 数据分析场景：先算后说，结论要有依据
让模型从一堆数据里找洞察，很容易得到“销售额逐月上升，说明业务增长良好”这类正确但无用的结论。真正有用的分析提示，必须要求模型“先给出计算依据，再给出结论”，并且明确数据口径。
你是一名商业数据分析师。 以下是某电商店铺近6个月的订单数据，字段包括：日期、订单量、销售额、客单价。 ### 数据 （粘贴CSV格式数据） 请完成以下分析： 1. 按月汇总订单量、销售额、客单价，并计算环比变化率； 2. 指出变化最明显的月份，并分析可能与哪些因素相关； 3. 基于数据给出3条可执行的经营建议； 4. 每条结论必须标注依据哪一行数据得出，禁止编造数据。 ### 输出格式 表格展示汇总结果，后面用列表给出结论和建议。这里有一条铁律：所有结论必须和输入数据对得上号。模型在生成文本时天然倾向于“顺滑表达”，如果数据给得不完整，它会自己脑补数字。通过在提示里强制“必须标注数据依据”，能显著降低这种幻觉。
顺便说一句，很多人在分析场景犯的错是给模型一堆原始数据，却不告诉它“什么是关键指标”。你可以在提示里帮它圈定重点：“重点关注客单价的环比变化，因为最近有调价动作”——这个前置信息，往往比任何参数调节都管用。
3.4 信息提取场景：用字段清单逼模型交出结构化结果
合同、简历、病例、工单、评论……这些非结构化文本里提取信息，是大模型最拿手的任务之一，前提是你把“要提取哪些字段”定义得足够清楚。
你是一名信息抽取引擎。 从下面这份会议纪要中提取结构化信息，只输出JSON，不要输出其他内容。 ### 会议纪要 （粘贴文本） ### 需要提取的字段 - meeting_topic：会议主题，字符串 - date：会议日期，格式YYYY-MM-DD，缺失则填空字符串 - participants：参会人姓名列表，数组 - decisions：决策事项列表，每个元素包含“content”和“owner”两个字段 - action_items：行动项列表，每个元素包含“task”“assignee”“due_date”三个字段 - risks：风险列表，数组，无风险则返回空数组 ### 输出格式 严格按以下JSON结构返回，不要添加JSON以外的任何内容： { "meeting_topic": "", "date": "", "participants": [], "decisions": [], "action_items": [], "risks": [] }这个方案的核心是“把字段数据结构化给到模型”。你不需要教它什么是JSON，只要给出清晰的字段定义和示例结构，它就能稳定输出。我在多个合同提取项目里都用这套写法，准确率比一开始“帮我提取一下重点信息”要高得多。
需要注意两个坑。第一，长文本可能超窗口，模型只看到头尾就丢失中间内容。解决办法是分段提取再合并，或者先让模型做分块摘要，再对摘要做最终提取。第二，提取结果必须做校验。模型偶尔会输出非法的JSON，少个逗号、多个字段都发生过。稳妥的做法是把模型输出接入一个JSON解析器，解析失败就重试一次，重试时把“上一次输出非法JSON”作为错误信息反馈给它，模型通常会自己修正。
3.5 复杂推理场景：让模型把推导过程明明白白写出来
遇到逻辑推理、数学题、策略分析这类任务，最怕模型“一口报答案”。它在生成时是按概率逐词预测的，跳过中间推理直接给答案，非常容易错。让模型把推导过程一步步写出来，相当于强制它多走几步路，正确率会明显上升。
请解决以下问题。在输出最终答案之前，先一步一步地写下你的推理过程。 ### 问题 某公司有三个部门，A部门人数是B部门的2倍，C部门比B部门多5人。三个部门总人数为45人。问B部门有多少人？ ### 要求 1. 先列方程，再逐步计算； 2. 推导过程写完后，空一行输出最终答案，格式为“答案：XX”； 3. 如果过程中发现矛盾，单独标注。这种“先过程后结论”的写法，在处理分析类任务时同样适用。比如让模型给你一份产品改进建议，你可以要求它“先列出用户反馈中出现的5类问题及证据，再排序，最后给改进建议”，这样它就没办法直接编一个看似合理的结论。
另外我还常用一招叫“自我验证”：在提示的最后加上一句“完成之后，请检查你的推导过程是否存在逻辑漏洞，如果有，修正后再输出”。就这么简单的一句话，常常能让模型自己发现并纠正错误。当然，它不能保证百分之百正确，但它能有效减少那些“一眼假”的错误。
4. 参数调节：提示词之外的半张控制面板
4.1 temperature：创意与稳定的旋钮
提示词决定了模型“往哪个方向跑”，参数则决定了它“跑得多稳、多野”。其中最常用的是temperature，你可以把它理解为“混乱程度旋钮”。
temperature的常见取值在0到1之间，有的接口允许更高。数值越低，模型越倾向于选择概率最高的下一个词，输出更稳定、更可预测，适合代码生成、信息提取、数学计算这类追求准确的任务；数值越高，模型越愿意选概率不那么高的词，输出更多样、更有惊喜感，适合头脑风暴、文案创作、起名这类任务。
我的经验值：信息提取和代码任务设在0.1以下，最好直接设0，以获得确定性输出；常规写作和润色设在0.5到0.7；需要创意发散时可以设到0.8到1.0，但要有心理准备，它可能给你一句惊艳的句子，也可能给你一段偏离主题的废话。记住一句话：高temperature不等于高质量，它只是高随机。如果你发现模型输出“很嗨但很空”，先检查temperature是不是调太高了。
4.2 top_p：核采样，另一个随机性开关
top_p是另一种控制随机性的参数，它的含义是：采样时只从累积概率达到某个阈值的候选词里选。比如top_p=0.9，表示模型只从概率最高的、累积占比90%的词里挑，剩下那10%的低概率词根本没机会被选中。
从效果上讲，top_p调低会让输出更保守，调高会让输出更多样。很多主流模型的接口文档里都有一条建议：temperature和top_p通常只需要改其中一个，不要同时大幅调整。原因很简单，两个参数都是控制随机性的，同时调高会叠加出不稳定的输出，同时调低又会把模型压得太死。我个人的习惯是：固定top_p在0.9左右不动，主要调temperature来改变输出风格。
4.3 max_tokens：给输出定个预算
max_tokens控制模型最多能输出多少个token。token不是字，一个token大概对应0.7到1个汉字，英文一个单词通常一两个token。这个参数很多人不重视，但它直接影响生成结果的完整度和成本。
如果你设置太小，模型会把结果截断在中间，输出一段没有尾巴的话；设置太大，不仅吃掉更多计算量和时间，还容易出现“生成到后面开始重复”的问题。我建议先估算任务需要的输出长度再做设置。比如提取十个字段的JSON，给1000 token就足够了；写一篇两千字文章，给3000 token比较稳妥。工程上宁可在拿到结果后自行检查是否截断，也别图省事给一个太大或太小的值。
4.4 频率惩罚与存在惩罚：控制重复与话题广度
还有两个参数，虽然不如前两个常用，但在特定场景很关键。
频率惩罚（frequency_penalty）用来惩罚反复出现的词，值越高，模型越不敢重复自己说过的话。这个参数对缓解“模型来回绕圈、同一句话反复说”有明显效果。存在惩罚（presence_penalty）用来鼓励模型聊新话题，值越高，模型越倾向于引入新的词和话题。我曾在做长文本生成时遇到模型在第三段开始复读第一段内容的情况，把频率惩罚提高到0.3左右后，问题立刻缓解。
但这两个参数也是要慎用的。惩罚太高，输出会变得东一榔头西一棒子，缺乏连贯性。我的建议是因为它们的交互效果比较微妙，先固定其他参数，只动其中一个，观察变化再决定要不要保留。
4.5 参数组合速查表
这里整理一份我常用的参数组合，给你当参考起点：
| 任务类型 | temperature | top_p | max_tokens | 备注 |
|---|---|---|---|---|
| 代码生成 / SQL查询 | 0.0 - 0.2 | 0.9 | 按需求估 | 低随机，保证语法稳定 |
| 信息提取 / 分类 | 0.0 - 0.2 | 0.8 - 0.9 | 按字段数量估 | 低随机，避免格式漂移 |
| 数据总结 / 分析 | 0.2 - 0.4 | 0.9 | 按报告长度估 | 有一点灵活性，但保住逻辑 |
| 营销文案 / 起名 | 0.7 - 1.0 | 0.9 | 偏大 | 高随机，接受发散 |
| 日常对话 / 润色 | 0.5 - 0.7 | 0.9 | 中等 | 平衡稳定和自然 |
这表不是标准答案，但它能帮你省去很多从零试起的成本。实际项目里，参数和提示词要一起调：提示词越清晰，参数就可以越激进；提示词模糊，参数再低也救不回来。
5. 常见问题与排查技巧实录
5.1 模型不听话？先查指令冲突，再查提示位置
“我明明说了要输出JSON，它偏偏给我一段解释”，这类抱怨我在项目里听过无数次。遇到这种情况，我的排查顺序是固定的。
第一步查指令冲突。提示词里有没有两个要求互相打架？比如既要“详细展开”又要“控制在100字内”，既要“口语化”又要“学术严谨”，模型在这种互相矛盾的要求面前，往往会取一个它认为合理的中间值，结果两边都不满意。解决方法是删除次要要求，保留最关键的那一个。
第二步查指令位置。模型对长提示的注意力并不均匀，它更关注开头和结尾的内容，中间的指令容易被忽略。如果你关键要求写在了一大段背景资料的中间位置，模型很可能“看是看到了，但没当重点”。解决办法是把最重要的指令放到开头，或者在结尾再强调一遍，比如在提示最后加一句“再次强调：只输出JSON，不要任何其他内容”。我自己测试过，同样一句规则，放在结尾比放在中间的效果好很多。
5.2 同样提示结果忽好忽坏？控制随机性
很多人遇到过“同样的提示词，上午跑出来很好，下午跑出来很烂”的情况。如果模型本身的更新没变，大概率是随机性在作怪。
排查步骤很直接：先看你的temperature是不是设高了。如果是，把它降到0.2以下再试。如果你已经把temperature设为0还是不稳定，那就说明问题不在随机性，而在提示词本身或者任务难度。
还有一个工程上的兜底手段，我强烈推荐：同一条提示跑三次或五次，把结果拿来投票。对代码任务，可以比较哪个结果通过率最高；对文案任务，可以挑最符合要求的一版。这个方法成本很低，但对稳定性要求高的场景效果拔群。我在一个数据提取项目里就是靠“三次结果取多数”把准确率从93%提到了将近99%。
5.3 模型一本正经地编答案？四招压制幻觉
幻觉是大模型绕不开的话题。模型不是数据库，它没有“查不到就说不知道”的机制，它只会生成“看起来合理的答案”。我在实战里总结出四招，按效果从强到弱排序。
第一招，明确要求“只基于提供材料回答”。在提示里写“只能依据上文提供的资料回答，资料中没有的信息一律回答‘未知’”。这一招能挡掉大部分幻觉。第二招，给“不知道”一个出口。很多幻觉是因为模型不想承认自己不知道，你要在提示里明确允许它说“无法回答”。比如写“如果信息不足，直接回复‘信息不足，无法判断’，不要猜测”。第三招，要求输出内容标注来源或依据。比如每一句分析后面括号注明来自哪一段原文。这一招让模型不敢随便编造。第四招，在任务完成后让模型“自查一遍”。加上“请检查以上回答中是否存在编造信息，如有，请删除并修正”，有时能触发模型自我纠正。
5.4 长上下文任务内容丢失？分段、定位、再汇总
当输入内容很长时，模型会表现“记头记尾忘中间”的现象——它能记得你最开始给的背景和最后给的指令，但中间一大段内容里的关键细节会被忽略。这在处理几万字的文档时尤其明显。
我常用的对策有三种，按场景选择。第一种，把关键信息前置。如果你知道某个细节很重要，把它单独摘出来放在提示的最开头，并在背景区重复一遍。第二种，分段处理。把长文档切成若干块，分别让模型提取要点或完成子任务，再把每段结果交给模型做汇总。第三种，检索增强。当文档实在太大时，先用简单的关键词或向量检索找到最相关的段落，只把相关段落喂给模型。这个方法效果最稳定，但需要一点工程成本。
5.5 提示词也要迭代：从糟糕结果到稳定结果的复盘
很多人以为提示词是一锤子买卖，写出来不好用就觉得是模型不行。实际上，我手上所有稳定可用的提示词，几乎都经过至少三五轮迭代。迭代的方法非常朴素：跑一次，看错误，改提示，再跑一次。
我举一个实际经历。某次让模型帮一个团队从客户访谈记录里提炼需求，第一版提示只写了“提炼用户痛点”。结果模型给出的是十条“用户觉得体验不好”这种空话。我观察错误模式后发现，模型缺乏两样东西：评价标准和动作建议。于是我在提示里加了“每一条痛点必须对应一段访谈原文依据”，并且要求“针对每条痛点给出一个可行的产品优化动作”。第三版跑出来的结果，信息密度和可执行性立刻上了一个台阶。
迭代提示词时，我的节奏很固定：先定位“模型在哪里跑偏”，再猜测“是哪个信息没给够”，然后修改对应的那一个部件，而不是推翻重来。你改得越精准，提示词迭代得越快。
5.6 常见问题速查表
| 问题 | 可能原因 | 建议解法 |
|---|---|---|
| 输出内容与要求格式不符 | 格式规则模糊或埋在中间 | 给具体模板，把规则放到开头或结尾 |
| 回答太泛、没有深度 | 缺少背景和角色约束 | 补充读者画像、专业角色、明确分析维度 |
| 结果不稳定、时好时坏 | temperature偏高或任务太难 | 调低温度；多次运行取多数或最优 |
| 模型编造数据或事实 | 没有约束信息范围 | 强制基于材料回答、允许说“不知道”、要求标注依据 |
| 长文本中间信息丢失 | 上下文过长或位置效应 | 关键信息前置、分段处理、检索增强 |
| 输出被截断 | max_tokens 设置不足 | 估算输出长度，按任务加大预算 |
| 反复重复已说内容 | 解码偏差或惩罚不足 | 适当提高频率惩罚；检查输入是否重复 |
这张表覆盖了大部分日常工作中的提示词问题。如果你遇到的不在上面，不妨先把它拆成上面几类，再对症下药。
6. 进阶：从提示词到提示体系的升级
6.1 把提示词当代码管理：模板化与版本化
当你的项目里出现二三十个提示词之后，继续靠聊天记草稿就是灾难。我的习惯是把提示词当成代码一样管理。每个提示词一个文件，统一存放在项目目录下，文件里标注清楚用途、适用模型、使用场景和变量占位符。需要动态注入的内容用{{变量}}这样的占位符标识，调用时再替换。
版本管理同样重要。改提示词之前，先备份旧版本；线上出现问题，立刻回滚到上一个可用版本。很多团队在模型应用上线后遇到“这次改提示反而更差了”的情况，如果没有版本记录，你连“改之前是什么样”都说不清楚，排查起来非常痛苦。我强烈建议从项目第一天就养成这个习惯。
6.2 建立评估集，改提示不再提心吊胆
提示词改动有个很典型的风险：“修好了一个case，弄坏了一片case”。你为了修正某类错误改了提示词，结果另外几类原本处理正常的任务开始输出烂结果。防止这个问题的唯一靠谱手段，就是准备一个评估集。
评估集不用很复杂：收集20到30条代表性的输入，每条配上“期望输出满足什么标准”的说明，跑完一遍人工打分。每次改提示词，跑完整套评估集，对比分数变化。这个做法一开始会觉得很耗时，但它能防止你在后面的迭代里反复踩同一个坑。对于追求稳定交付的团队，效果非常明显。
6.3 提示工程在大模型应用架构中的位置
最后把视野拉高一点。提示工程不是只发生在聊天窗口里。在现代大模型应用架构里，提示词几乎是无处不在的“最小单元”：做检索增强生成，需要设计“如何从检索结果中提炼答案”的提示；做智能体，需要设计“让模型决定调用哪个工具”的指令；做数据标注，需要设计“让模型按标注规范输出”的模板；做模型评估，也需要设计“让模型判断回答是否合格”的评分提示。
换句话说，提示工程是整座大模型应用大厦的砖块。你可以不会微调模型，可以不会复杂架构，但只要你能把提示词写得出色，你就能在应用层创造大量价值。反过来，如果提示词本身写得粗糙，上层架构再精巧，最后的输出质量也一样会被拖垮。
写到最后分享一个我坚持了很久的习惯。每次我用大模型做一件自己不太熟悉的事，都会先试着把这件事拆成“谁、什么背景、要什么结果、按什么结构、有什么限制”这五行字再发给模型。单看这五步都很简单，但把它们变成肌肉记忆，这需要刻意练习。大模型迭代得再快，把需求表达清楚这件事永远不会过时。从你手头最常做的那类任务开始，用这套方法重构一遍提示词，跑几组对比，你很快就能看到差别。
