大模型提示词设计7大原则:从角色设定到迭代调优

📅 发布时间:2026/10/20 3:53:06
大模型提示词设计7大原则:从角色设定到迭代调优
1. 先搞清楚提示词为什么值得认真设计你有没有遇到过这种场景让AI帮你写一份方案你洋洋洒洒打了几百字它回你一篇看着很顺滑、实则没有任何信息量的空话你让它做个会议总结结果它只是把你发的聊天记录重新排了个版该提炼的结论一条没提炼。这时候你大概率会摔键盘说一句“这AI真笨”。但以我自己的使用经验来说绝大多数“翻车现场”问题根本不在模型能力而在提示词本身。提示词就是你和大模型沟通的唯一窗口——你说不清楚它就做不对你没给边界它就只能靠猜你没给参考标准它就只能按照训练数据里最“平均”的样本来回你。那结果自然是又空又泛还带着一股不对劲的“AI味”。这篇文章要聊的就是我做提示词设计这段时间以来总结出来的7条最底层、最通用的原则。不管你是普通用户、内容运营、产品经理还是刚接触大模型的开发者只要照这套逻辑去写提示词大概率能把模型输出质量从“勉强能用”提升到“接近初稿水平”。我在这篇文章里不会堆术语也不会扯什么高深理论讲的都是能直接复制到自己工作流里的写法。需要先说清楚一个判断标准什么样才算好的提示词我认为有三个层面。第一是可控输出风格、格式、结构能稳定复现第二是达意模型理解的任务和真实目标一致而不是“字面意思一致但实际跑偏”第三是可维护提示词改了某个参数行为变化能预期而不是牵一发而动全身。后面的7条原则本质上都是在服务这三个标准。2. 原则一先给角色再谈任务2.1 为什么角色设定不是花架子很多人在写提示词的时候喜欢上来直接说“帮我写一段产品介绍”然后就没有然后了。模型确实能写但它是按照一个“没有身份的泛化AI”在写——语气平均、措辞保守、结构僵硬。你读起来就觉得不对但说不出哪里不对。问题在于大模型在训练时见过海量的写作样本而“产品介绍”这个短语对应的样本分布太宽了。不指定视角和身份就等于让一个没有表情、没有立场的机器人在写八股文。但如果你先给它一个具体角色比如“你是某科技公司的资深产品运营写过上百条高转化的朋友圈文案”模型就会自动从记忆里检索与之匹配的语料分布——语气、用词、节奏感全部都会向这个角色靠拢。这背后的机制其实就是“上下文对齐”。角色的作用是帮助模型锁定一个合适的语言风格、专业视角和信息筛选标准。同样一句“帮我写个开场白”让语文老师来写和让脱口秀演员来写结果一定完全不同。不是模型做不到是你忘了告诉它“该请谁来做这件事”。所以我的习惯是任何一次对话开始之前先花十秒钟想清楚——我到底想请一个什么身份、什么背景、什么目标受众的人来干这个活然后把这个身份明确写进提示词第一句。2.2 角色设定的写法与常见误区角色描述要具体到什么程度我提供一个可以套用的格式身份 经验领域 服务对象 说话风格。四要素不必每次都凑齐但越多输出的稳定度越高。反面案例是这样子的你是一个文案专家帮我写一段推广文案。这个角色给了等于没给。“文案专家”四个字太宽泛资深编辑、广告策划、公众号小编都可以叫文案专家但他们写出来的东西完全不是一个路数。模型只能平均结果就是平庸。我平时常用的是这种写法你是一名有8年消费品牌操盘经验的市场总监特别擅长把复杂的卖点翻译成普通用户听得懂的大白话。你的目标用户是25-35岁、平时没时间研究参数的一线城市白领。请用你的语言风格帮我写一段智能手环的上市预热文案。注意区别第二段提示词不仅描述身份还补了用户画像和沟通对象。这样一来模型知道该用什么词汇等级、什么信息颗粒度、什么情绪基调来回应你。角色设定还有一个常见的坑角色之间互相冲突。有人会写“你既是严谨的医生又是幽默的段子手”模型会不知道怎么平衡输出就容易摇摆。如果你确实需要两种风格的结合建议拆成两轮对话不要塞在同一段提示词里。另外角色的说服力也会影响输出质量。比如“你是有着某某背景的顾问”这个背景描述越具体模型越容易进入状态。背景描述不需要完全真实——它本质上是在调用模型训练数据中的语料分布不需要通过什么资质审核。3. 原则二任务指令要具体到能执行3.1 模糊目标会让模型失去判断依据提示词里出现频率最高的失败句式我觉得是“帮我优化一下这段话”“帮我总结一下这个文档”“分析一下这个数据”。问题出在哪出在“优化”“总结”“分析”这三个词每一个都有一百种理解方式。你说“总结一下”模型不知道你是要一句话梗概、三行摘要、还是按结构拆解的完整大纲你说“分析一下”它不知道你是要优缺点分析、竞品对比、还是风险预警。它只能平均化理解给一个看似合理、实则什么都没有交付的回答。这就好比你去餐厅点菜只说“来点吃的”厨师只能按他以为的标准给你做——你大概率不满意但你还说不出哪里不对因为你的需求本身就没定义清楚。所以我在练习提示词设计的前期养成过这样一个习惯下笔之前先问自己三个问题。任务对象到底是什么希望模型产出的交付物形态是什么有没有硬性的限制条件比如字数、预算、风格、时间范围把这三个问题回答清楚了写出来的任务指令基本上就不会跑偏。一个好的任务描述应该让模型不用反推你的意图。反推的次数越多错误空间就越大。反推到极端情况模型会把你的意图误解到完全不相干的方向去。3.2 把目标拆解成可判断的约束条件任务指令写得具体不等于写得啰嗦。很多人误以为“写得多写得好”于是把提示词堆到上千字各种无关细节都有核心任务反而被淹没。这其实是另一个极端。真正有用的做法是把任务拆成几个可以逐条验证的约束条件。用我实际调过的案例来说明。之前我需要从一个会议记录里提取行动项一开始写的是帮我提取这个会议记录里的关键信息。结果模型给出了“会议讨论了产品迭代方向”“各方就排期达成初步共识”这类完全正确的废话。后来我把任务改成从这份会议记录中提取所有包含明确责任人、截止日期和可交付成果的句子。按三个字段输出责任人、截止时间、交付物。无法同时满足这三个条件的句子不要列入。会议记录在下面……测试下来输出质量完全不一样。原因很简单我把“关键信息”这个模糊概念替换成了“责任人截止时间交付物”三要素同时满足的明确过滤规则。模型有了判断标准就不再自由发挥了。任务指令还有一个隐含要求一次只交代一个主任务。不要想着在一个提示词里同时让它“总结、翻译、润色并结合我们品牌风格重新改写”步骤太多它容易顾此失彼。如果确实有多个任务就拆成多轮对话或者用后面会讲到的步骤化原则来分步完成。4. 原则三上下文是提示词的氧气4.1 缺失背景导致的典型翻车第二条原则解决的是“让模型知道做什么”第三条原则解决的是“让模型知道基于什么做”。两者经常被混在一起但其实是两个独立环节。你可以把任务理解成是构造函数而上下文是传入这个函数的数据源——没有参数函数再正确也跑不出结果。举例来说你让AI帮你写一封客户回绝邮件。如果你只写“帮我写封回绝邮件”它能给你写一封但大概率充斥着“感谢贵司的信任与支持”“期待未来有合作机会”这类万能模板句。它不知道你们和客户的关系紧不紧张不知道你是想委婉拒绝、还是态度坚决不知道是否要给替代方案——这些信息缺失模型就只能走平均路线模板化是必然结果。这类翻车案例的共性不是模型不懂写作而是语境不足。模型在回复时只能依据你提供的信息来建立判断模型。你给的背景越薄它的推断空间就越大而推断空间越大输出就越不可控。我自己在做AI辅助方案设计时特别深刻地体会过这一点。一开始我以为只要把任务描述清楚就够但后来发现让模型了解“我们是谁、用户是谁、上次尝试过什么、什么不能做”往往比任务本身更能影响输出质量。4.2 上下文填充的三个层次根据自己的实践我把上下文分成三个层次每次写提示词都按这个顺序来补充第一层是背景层回答“这件事发生在什么场景里”。比如面向什么行业、产品处于什么阶段、用户是谁、竞争对手大概是什么情况。不需要写很长两三句话说清楚关键背景就够。第二层是约束层回答“有哪些硬性边界”。预算范围、合规要求、必须保留的信息、绝对不能使用的表述、字数限制等。模型最怕没有边界因为它生成本质上是在一段连续空间里采样没有边界等于无限空间输出自然飘。第三层是口径层回答“有哪些已经确定的表述口径”。比如公司内部约定俗成的术语、项目代号、特定翻译方式。这一层非常容易被忽略但它往往是专业人士和普通用户写提示词水平差距最大的地方。一个术语口径不对整篇内容的专业度都会下来。结合来看一个好的提示词结构通常是角色背景任务约束也就是先交代你是谁、再交代环境、再说要干什么、最后说不能怎么干。这样一套下来模型要做的事情已经非常明确发挥空间被限制在一个合理的通道里输出质量自然就会稳定。5. 原则四输出格式不失控5.1 格式失控的真实场景很多人检查提示词效果时只看内容对不对忽略了形式。但实际使用中格式问题往往比内容问题更容易让你恼火。比如让它列三个要点它输出一整段散文让它填表格它给一堆Markdown嵌套列表让它输出JSON它多跟你解释几句废话。严格来说这算不上模型的“错误”因为大模型本来就是概率生成——你没规定输出形式它只能猜一个大概率的形式。但形式一旦失控后续流程就没法自动化。我之前做个简单的数据处理要求模型输出一个JSON数组它每次都给我包上大段的解说文字解析程序根本没法直接跑。后来我认识到这不是模型不听话而是我没把“输出格式”当成任务的核心部分来写。格式约束还有一个隐藏价值它让你更容易检查模型是否理解你的意图。当你明确规定“只输出JSON不要任何解释”而模型仍然输出了解释这本身就是一种反馈信号——说明它的注意力没被格式约束吸引到你可以通过强化表述来修正。5.2 模板锁格式的实战写法格式约束最有效的做法不是描述你想要的格式而是直接把模板写出来让模型往里填内容。描述格式是模糊的模板是精确的。举例来说请根据对话内容按以下JSON结构输出评估结果不要输出任何其他内容{ 情绪: , 需求: , 建议动作: }这样模型就不太可能输出多余的东西因为模板本身已经定义了结构。这里有个细节模板里字段名尽量用自然语义的短词不要用变量名风格的字段比如“user_emotion_level_1”因为模型对自然语义字段的理解更稳定。对于散文类输出可以用“结构说明示例格式”的组合句。比如让它写一份方案请按以下结构输出背景说明150字以内、问题诊断3条、解决方案分3步展开、所需资源清单表格形式。不要输出“以下是方案”之类的引导语。实测下来“不要输出引导语”这种负向约束普遍有效。因为很多模型有很强的“开场白冲动”你不禁止它就总爱带一句“好的以下是……”。格式约束放在提示词末端一般比放在开头效果更好。开头部分已经说的都是角色和任务如果中途插入大段格式说明可能模糊主任务。把格式模板放在最后作为交付要求的一部分模型执行度最高。这个操作我试过不同位置差别确实存在放在末尾的结构符合率会更高。6. 原则五复杂任务分步做6.1 让模型先思考再作答如果你让模型直接回答一个复杂问题它经常会给出一个“跳跃式结论”——看起来挺完整但中间的推理链条缺失、步骤混乱。比如让它做个市场分析它直接给你最终建议没有推导过程。这对很多需要判断依据的场景根本不适用。不是说模型没有推理能力而是模型在短平快的回答模式下会倾向于用最少生成步骤来猜测一个“最短路径答案”。如果这个最短路径的某个节点判断错了整个结论就错了而且你没机会在结果里看到是哪一步错了。我常用的解法是要求模型“先展示推理过程再给出结论”即在提示词里明确要求它分步执行。这样模型在每一步生成时都会基于前面已生成的内容来推导下一步减少跳跃和幻觉空间。这和人在复杂问题上的处理习惯是一致的——先列大纲再写正文先拆流程再逐项执行每一步都能被检查。在实际使用中分了步骤之后还有一个额外收益出错定位变得容易。以前模型输出一个不对劲的结论散户完全不知道问题出在哪整个回答都要推翻。分步之后你一眼就能看出是哪一步的推理歪了只需要把这一个步骤单独修正后续还可以继续用它生成的结果。6.2 步骤化的具体写法步骤化不是简单地说“请一步一步作答”大模型对这些通用套话已经免疫了效果一般。更有效的做法是你自己在提示词里定义好步骤流程让模型按你的流程执行。举一个我常用的框架请按以下步骤处理这份用户反馈 第一步提炼反馈中涉及的核心问题用不超过20字的短语列出最多5条。 第二步针对每个核心问题判断它属于产品功能问题、使用说明问题还是服务流程问题。 第三步结合判断结果给出优先处理建议和理由理由控制在2-3句。 最后汇总成一份简洁的处理报告。这样做的效果非常明显因为每一个步骤的输出都限定了格式和任务模型不会跳过某个环节也不会在某个环节上过度展开。步骤之间自然形成了一条工作流模型只需要按部就班地完成即可。步骤化还有一个变体就是用“思考链”式的提示词。如果你希望模型在处理信息时更严谨可以在任务前面加类似“先不要急着给出结论请先分析已知信息和未知信息之间的差距再结合差距做出推断”的中性描述。这种提示方式特别适合那些需要综合判断而非简单生成的任务比如竞品分析、风险判断、面试问题设计等场景。需要注意的是步骤数量不要超过五个步骤过多时模型同样会丢失前文聚焦。我测试超过五步的任务时越发容易在中途遗漏步骤要求。如果需要十步以上的流程就直接拆成多次对话每次对话只负责其中的两三个步骤这样反而更稳定。7. 原则六示例往往比规则更管用7.1 示例的本质是“抄作业”聊完了角色、任务、上下文、格式、步骤接下来这条原则很反直觉有时候你写了再多的规则不如直接给模型看一个例子。因为规则是抽象描述示例是具体参照而大模型对具体例子的“模仿”能力远强于对抽象规则的理解能力。举例来说你想让模型帮你改写一段客服话术。你写“语气要亲切表达要清楚不要太官方”——模型给你的结果可能还是带着一股客服腔。但你给它一组改写前后的对照例子原文是什么改写后是什么两组例子看下来模型很快就学会了你要的字数密度、语气颗粒度、口语化的减字方向。这就是“少样本学习”few-shot的本质用实例划定一个风格区间让模型在区间内创作。我开发提示词模板时基本上走到了一个固定阶段如果试了四五次模型的输出风格还不满意就不会再调整规则描述而是直接去写示例。很多规则的微调在某个阈值之后就很难再通过语言描述来定向只有示例能快速把风格“锚定”到期望位置。7.2 示例设计的三个关键细节第一个细节示例要成对出现至少给2-3组。单组示例不够模型很容易生硬地模仿那一组的表层结构。给两组以上的对照它才能提取出共同规律。比如你想让它把口语对话转成书面通知就给两三条“口语原话→书面通知”的对照它模仿出来的结果会稳定得多。第二个细节示例的质量比数量重要。你给一个烂例子模型会照着烂出同一水平的作品。示例风格要尽量贴近你真实想要的最终效果而不是“差不多”的效果。我见过有人随便拿一个旧的模型输出当示例来用结果新提示词的效果被那个旧输出水平锚定住了。第三个细节示例的摆放位置要离任务近。通常的写法是“下面给出几条参考示例……请参考以上示例的风格完成以下任务……”把示例放在任务指令和待处理材料之间。这样模型在生成时示例还保留在较近的上下文窗口里记忆衰减最小模仿效果最好。示例还有一种更高阶的使用方式用反例来划定禁区。比如你要的不是纯正式报告而是偏演讲风格。你可以写明“以下是一条错误示范过于书面化。请注意避免。”模型遇到反例一般能有效避开相似表述。这个技巧在其它资料里不太常见但我测试下来对有些模型的效果确实稳定。8. 原则七好提示词是改出来的8.1 期望一次成型是提示词实践里最大的误区我刚接触AI提示词设计的那段时间总抱着一种学生心态——写一次提示词然后就期待它给一个能直接用的好结果。结果当然是一次次落空。后来我才想明白一个关键认知提示词和代码非常像都是在跟一个“执行环境”互动。代码要debug提示词一样要debug。没有人写第一版代码就能稳定运行也没有人写第一版提示词就能输出完美结果。那些看起来很顺滑的结构规范、模板、格式校验全都是反复调出来的。你看到的优秀提示词案例是“迭代后的结果”不是“第一版的结果”——理解这一点心态就会健康很多起码不会再因为一次失败就怀疑模型能力或者怀疑自己的水平。把提示词当成一个待调优的程序来看整个工作方式就完全不同了。你会有意识地记录版本、控制变量、观察错误类型而不是每次失败了就推翻重来、凭感觉重新写一段。凭感觉重写的效率极低因为你根本不知道改动哪个部分导致了什么变化所有优化都变成碰运气。8.2 一套实用的提示词迭代流程我给自己设计了一个很简单的迭代流程基本固定成三步。第一步记录原始提示词和模型输出。用得顺手之后你会发现最值钱的不是“某个魔法提示词”而是你自己团队反复测试后沉淀下来的那套稳定版本——记录到修改日志里用版本号标注提示词1.0、提示词1.1、提示词2.0你会很直观地看到问题点和演化路径。第二步分类错误类型一次只修一个变量。常见的错误类别包括内容跑偏与主题关联度不足、格式违规结构不是预期、风格不符语气不对、信息遗漏该覆盖的点没覆盖。每次修改只针对其中一类做调整不要同时改五个地方否则你根本不知道哪个改动起了作用。第三步用对比测试验证改动效果。改完提示词之后用同一套测试材料分别跑旧版和新版对比输出差异。如果新版在某个维度上有明显提升就保留如果没有就回滚再试另一种改法。这套流程看起来简单但非常管用——它把“感觉不好”这种模糊反馈转化成了“格式符合率”“遗漏率”“风格偏离程度”这样可判断的具体指标。迭代过程中还有一个常用杠杆加约束。大多数第一版提示词的问题都是约束太少而不是太多。当你觉得输出泛泛而谈时优先做加法——加背景、加角色细节、加格式模板、加反例特征。等输出变“稳定但僵硬”时才考虑做减法——删掉多余的约束给它更多创造空间。先后顺序把握好提示词调优会顺利很多。9. 避坑速查清单与实战小抄9.1 高频翻车点与对应修改方向迭代过程中我逐渐整理出了一张高频问题对照表基本覆盖了平时遇到的大部分提示词失效场景。你在调试时可以对照它来快速定位问题翻车症状常见原因推荐修改方向输出空洞、大而全缺乏角色和背景约束增加身份设定与用户场景描述答非所问任务指令存在歧义把指令改写成“对象交付物限制”格式格式混乱、结构不一致未显式规定输出模板在末尾附上JSON结构或Markdown模板风格千篇一律没有提供风格锚点给出正面示例或反例明确风格边界推理跳跃、结论先行问题太复杂却要求即时生成拆解步骤每一步限定输出范围频繁出现事实性错误未限制信息来源与知识截止线要求它标注“不确定”并只基于给定材料回答多次调整仍无改善一次变量改太多回滚到上一版单次只修改一个参数这张表属于典型的“排查手册”不需要背遇到问题来对号入座就行。每一条背后都是我踩过的真实坑——有些问题你看一眼就知道怎么修有些则需要反复测试好几轮之后才总结出规律。做成速查表之后日常提示词开发的效率会提高非常多。9.2 我日常使用的基础提示词骨架结合上述7条原则我沉淀了一套基础的提示词骨架你们可以直接拿去做模板。虽然不是万能的但覆盖了绝大多数日常写作、分析、总结类任务。你是一位具体身份擅长核心能力。目标用户是用户画像说话风格请参考风格描述或示例。 任务背景这件事发生的场景2-3句话。 请完成以下任务对象交付物要求具体到能逐条验证。 参考示例如有给出2-3组对照。 输出要求按以下结构输出模板。不要输出任何多余的解释或引导语。 注意硬性边界与禁止事项。这个骨架看起来简单但组合起来之后几乎每个原则都覆盖到了。日常使用时不需要每次都把它完整写一遍重点根据任务情况拆取需要的部分。任务越复杂骨架里的字段就越是不能省。我的习惯是把这套骨架存成模板每次用时把里面的占位内容替换掉。用久了之后你会发现自己形成了“提示词词库”——针对不同场景的几个固定前缀、几十个常用字段描述、几组惯用反例表达全部沉淀成自己的套件。这套东西才是真正的核心竞争力比临时翻各种提示词教程高效得多。我最后再分享一个小体会提示词设计这件事入门看教程提升靠攒案例。不要指望看几篇文章就能顿悟也不要把别人的模板原封不动拿过来用——不同的人写出来的风格习惯完全不同模板体和具体的需求场景绑定很深一定要自己在反复迭代中攒出属于自己的版本。相信我等你积累到几十条稳定模板的时候再回头去看那些“万能提示词公式”类的文章你就知道差距在哪里了。