1. 提示词工程最常见的误解不是把话写长而是把约束写清楚我见过太多人把提示词工程理解成“给 AI 写小作文”——角色设定铺一大堆、背景描述恨不得从盘古开天写起、语气助词全加上结果模型输出还是跑偏。我也走过这个弯路直到有次在一个文案生成项目里我写了一段 300 字的提示词里面角色、语气、受众全有但客户要的 20 条短文案我拿到手的 20 条里有 17 条结构雷同、信息重复连标点风格都一模一样。那次之后我换了个思路把提示词当成“需求文档”来写而不是“背景小说”来写。提示词工程的核心不是字数多而是约束准确——你要明确告诉模型三件事输入是什么、处理逻辑是什么、输出长什么样。其余那些“你是一位资深文案专家”“你的文字要富有感染力”之类的表述有用的部分其实很少真正决定输出质量的是结构化约束和示例定义。那段时间我拿着同一个模型、同一个业务场景反复对比了“长背景式提示词”和“结构化约束式提示词”的实际输出结果很稳定结构化约束的提示词在格式符合率、信息覆盖率和二次修改成本上全面胜出。所以这篇文章里分享的 10 个技巧基本都是围绕“如何把约束写清楚”展开的而不是教你怎么把话写得更漂亮。2. 十个立刻见效的技巧先搞懂这几个手里的模型马上听话一半2.1 技巧一角色设定后面必须跟“所以你要做什么”很多人写角色设定的方式是这样的“你是一位资深的数据分析师。”然后就没下文了。这个写法的问题在于模型收到的是一个身份标签而不是一套行为准则。它知道自己“是”数据分析师但你希望它怎么处理手头的数据它还是得靠猜。猜来猜去结果就不稳定。我习惯的写法是角色加任务边界你是一位资深的数据分析师。你的任务是基于用户提供的原始数据表格输出结构化的分析结论。你的输出必须包含三个部分数据概览、关键发现、风险提示。不允许编造数据所有结论必须来自输入表格中可验证的字段。如果你认为数据不足以支撑某个结论请明确写“数据不足无法判断”。对比下来后半段那几句“必须包含”“不允许”“如果……请……”才是真正起作用的约束。角色只是给模型一个大概的“语感方向”行为约束才是让输出稳定的关键。所以你每次写角色写完之后多问自己一句它知道了自己的身份然后呢把“然后”写清楚。2.2 技巧二用输出格式锁定结果而不是用形容词描述结果“请用清晰简洁的格式输出”“请用专业的方式呈现”——这类形容词对模型的约束力约等于零。模型不知道你说的“清晰”到底是分点还是列表也不知道“专业”到底是严谨措辞还是数据支撑。与其描述格式不如直接画格式。比如我需要模型整理用户反馈我会给一个明确的输出结构请将下面的用户反馈整理为结构化记录严格按以下字段输出用户ID原样保留核心问题一句话概括不超过20字问题类别从以下类别中选择功能缺陷/体验问题/建议需求/其他情绪倾向积极/中性/消极原文关键句引用原文不超过50字实测下来用这种“画字段”的方式模型输出的字段完整率几乎在 95% 以上而用“请整理成清晰的结构化记录”这种写法经常缺字段、混格式。输出的组织方式一旦被明确定义模型的发挥空间被收窄反而更稳定可控。2.3 技巧三给一个“反面示例”比给十个正面要求都管用这是十个技巧里我觉得最容易被忽略的一个。人的注意力机制对“不要做什么”往往更敏感大语言模型的训练数据里也有大量的人类反馈数据所以给一个反面示例能非常有效地降低特定错误的发生概率。举个实际例子。我初期写文本润色提示词时只写了“请把以下文本润色得更正式”结果模型把一句“我们下周开会讨论预算”润色成了“我们拟于下周就预算事宜召开专题研讨会议”。倒也没错但完全不符合我想要的“正式但克制”。后来我改成请将以下文本润色得更正式。 要求保留原意不增加不存在的细节不使用夸张或浮夸的表达。 反面示例 输入我们下周开会讨论预算。 错误输出我们拟于下周就预算事宜召开专题研讨会议。加上反面示例之后输出明显收敛了。模型不是不懂“正式”这个词而是它见过的“正式”长什么样太多了你需要帮它锁到你想要的那个具体区间。这个技巧在代码注释、邮件回复、短视频脚本等风格敏感的场景里尤其好用。2.4 技巧四一个成功示例胜过十句口头要求“请用互联网黑话风格写”——模型确实能写但写出来的风格可能“太黑话”了满屏赋能、抓手、闭环别说用户看不懂我看都头疼。更可靠的方式是给一个具体的成功示例让模型模仿你的示例。示例的作用不是让模型背诵而是给模型一个高维度的模式参考。举个场景我需要模型把我的技术博客改写成社交媒体版本如果我写“请改写得通俗易懂一些”模型大概率会往“删减术语”这个方向走但结果常常变得平庸。如果我在提示词里直接给一个具体的改写前后对照原文本框架采用了模块化架构设计便于各功能组件独立迭代。 改后这套框架把功能拆成了一个个独立的小模块哪一个要升级就升级哪个互不干扰。模型会从示例里学到“保留核心信息、具体化抽象描述、用生活化类比”这三个隐含规律。而且有了这个示例输出的风格漂移会明显减少也不会出现“明明让你通俗结果写成段子手”的尴尬。2.5 技巧五复杂任务走 Chain of Thought但别让模型把过程全写出来Chain of Thought 现在是写提示词几乎绕不开的方法。我自己的经验是遇到需要推理、计算或多步骤判断的任务直接在提示词里写“请一步步分析不要直接给结论”效果往往立竿见影。但有个地方很容易被忽略——chain of thought 不等于让模型把所有推理过程都写进最终输出。很多时候你只想要一个简洁的结论但模型会给你一大篇“思考过程”反而影响交付质量。我的做法是把“思考”和“输出”分开请先内部逐步分析这个问题最后只输出以下内容 结论单独一行 依据列出3条以内核心依据每条不超过20字这样既拿到了思考带来的准确性提升又不会被冗长的思维链拖累输出格式。我在做竞品分析报告时用过多次逻辑质量明显好于直接提问而输出长度又完全可控。2.6 技巧六开放式问答尽量加“备选选项”“请评估这个方案的可行性”和“请评估这个方案的可行性从高、中、低三个等级中选择”这两句提示词的效果差距很大。前者模型可能会写一篇八百字的小论文洋洋洒洒谈风险谈收益但你看完还是不知道它到底觉得可不可行。后者直接把决策收敛到三个选项模型在输出前要先做一次分类判断结果就更有参考价值。这个技巧的本质是给模型降低输出难度。大语言模型本质上是做概率预测选项越集中它猜中的概率越高。如果你给出的选项符合业务逻辑模型做“选择题”的准确率通常远高于做“问答题”。当然选项不必太细三到五个为宜太多反而制造新的混乱。这个技巧我在做内容审核分类和用户需求归类的项目里反复在用稳定且省心。2.7 技巧七用“条件分支”处理业务里的模糊地带业务场景和考试题最大的区别是——现实里到处是“如果”。你让模型给用户写一封催缴通知它写好了但如果用户已经付过款了呢如果用户是 VIP 呢如果用户是未成年呢提示词里没有这些分支模型就只能按它默认的理解走结果自然容易翻车。处理方式并不复杂把可能的分支显式写出来根据用户状态执行以下逻辑如果用户已付款输出致歉信说明由于系统延迟导致通知误发。如果用户为 VIP输出提醒信语气温和并附加人工客服联系方式。其他情况输出标准催缴通知包含金额、截止日期、缴纳方式。条件分支模式在客服、销售、运维等有明确业务逻辑的场景里极其好用。我经常把一套业务规则整理成五六个“如果……则……”模型输出的正确率比我预想的高很多。这个技巧的另一个好处是把业务逻辑外置到提示词里后续维护也方便——业务规则变了改提示词就行不用改代码。2.8 技巧八让模型“引用原文”快速降低幻觉率幻觉问题大概是所有人用大模型时最头疼的事情之一。尤其当任务是总结、提取或者问答模型一本正经地输出一个来源不明的“事实”时你要去核实它的每一句话那这个工具的效率优势就全没了。我在处理需要高可信度的任务时有个习惯强制模型引用原文。例如请基于以下文章回答用户提问。你的回答必须标注信息来源格式为“根据原文第X段……”如果原文中没有相关信息请直接回复“原文中没有提到这一点”。这个提示词一加上输出质量和没用它时完全是两个层级。模型会倾向于从给定的上下文中找答案而不是自己去“自由发挥”。我拿一篇 3000 字左右的产品说明文档做过测试不加引用要求的时候模型自己脑补了三个文档中根本不存在的功能点加上引用要求之后零脑补。如果你的业务对信息准确性要求很高这个技巧建议直接纳入标配。2.9 技巧九一次只改一个变量把提示词迭代当实验做这个技巧不带任何技术门槛但我觉得它是“业余用”和“职业用”之间的一道分水岭。很多人调试提示词的方式是第一次结果不好就整个重写一版第二版结果还是不好再全部推翻再来。这样的做法有两个问题第一你根本不知道是哪句改动让结果变好或变坏的经验完全没法沉淀第二提示词越大全量重写的风险越高可能前面跑通的部分也跟着坏了。我的习惯是把提示词当成受控实验来做。每次迭代只改一个变量——要么只加一个示例要么只改一个输出格式要么只调整角色描述。改完记录输出效果再决定下一步。围绕同一个任务做四五轮迭代之后你会很清楚地知道每个变量对结果的影响方向。这个过程中积累下来的每一版提示词都值得留存它们就是你的“模型调参日志”。2.10 技巧十把跑通的提示词沉淀成模板而不是每次都从零开始最后一个技巧听起来有点像大道理但落实起来最简单也最有效。我见过不少人的对话框里存了几十段提示词但都是按场景随手写的彼此之间没有结构关联下一次写新任务时又从零开始。我的做法是一旦某个提示词在真实任务里连续跑通过几次就把它整理成模板用变量名标出可变部分存到一个专门的模板库文件里。比如文案生成类任务我会把“产品名”“卖点”“目标人群”“语气风格”抽成变量写成一个通用模板。下次遇到类似任务直接把模板复制出来填上变量就能用第一版输出质量就比从零写的提示词高出一大截。模板库的积累到了十来个核心模板之后你会明显感觉到效率提升了不止一个台阶。3. 直接可抄的模板库四个高频场景的现成配方3.1 模板一结构化信息提取适合客服反馈、评论分析、调研问卷你是一个信息提取助手。请从用户输入中提取以下字段并以 JSON 格式输出 { 用户ID: 若原文未提供则填 未知, 反馈主题: 20字以内, 问题类别: 功能缺陷 / 体验问题 / 建议需求 / 其他, 紧急程度: 高 / 中 / 低根据用户情绪判断, 用户原话: 选取最能代表问题的一句话不超过50字 } 如果原文信息不足以填写某个字段请填“数据不足”不要编造。这个模板适合把一段一段的原始反馈批量清洗成结构化数据。我设定了 JSON 输出格式之后后面可以直接脚本解析不需要人工二次整理。一次处理几十条回复时稳定性非常好。3.2 模板二文本改写润色适合公众号、邮件、技术文档请对下面的文本进行改写。要求如下保持原意不变不新增事实。语气调整为{{语气风格}}。输出长度控制在原文长度的{{比例}}倍以内。避免口号式表达避免过度修辞。 反面示例 输入这个方案我们已经讨论了三次。 错误输出这个方案我们已经进行了三轮深度且全面的探讨与磋商。 原文 {{待改写文本}}这个模板的核心是“负面示例 显式约束”。我把“不新增事实”放在最前面是防止模型顺手给你补充一些你不知道从哪冒出来的“合理”细节。日常写公众号、行业分析文章时这个模板的可用度很高。3.3 模板三多选项决策辅助适合方案选型、优先级排序你是一名中立的分析助手。以下是候选方案列表 {{候选方案描述}} 请完成以下任务用一句话概括每个方案的核心思路。从以下维度比较各方案成本、实现难度、风险、上线速度。每个维度给出“高 / 中 / 低”或“快 / 中 / 慢”的评级。基于上述比较给出你的推荐方案。如果认为没有明显最优项请说明各自适用场景。这个模板的好处是它没有让模型直接给结论而是先建立评价框架再基于框架给结论。用下来比“你觉得哪个方案好”靠谱得多模型会明显更“冷静”不容易被某一个方案的标题带跑。3.4 模板四从原文里找答案适合知识问答、法律条款解释、产品文档检索请仅根据下面提供的文本回答用户问题。 回答规则所有结论必须引用原文内容引用格式为“原文提到……”。如果原文没有相关信息请直接回复“原文中未找到相关信息”不要根据常识推测。回答控制在150字以内。 原文 {{背景资料}} 用户问题{{问题}}这个模板解决了绝大多数“模型自己编答案”的场景。凡是需要做资料问答、产品 FAQ 生成、档案检索的建议直接套这个。你给它的资料范围越明确它回答的边界就越清楚。4. 实际项目中的失败复盘三个最典型的坏倾向4.1 角色越具体越好不角色太窄反而限制输出有一阵子我在做知识类内容自动生成一开始给模型的角色是“一位拥有20年从业经验的资深注册会计师”。结果模型输出里频繁出现会计术语语言风格过于专业普通读者根本看不懂。后来我把角色改成“一位擅长用简单例子解释专业概念的财务科普作者”输出的可读性立刻上来了。这个问题的本质是角色的细节不仅赋予能力也圈定视野。你给模型一个窄角色它自然会偏向那个角色的行话和思维模式。所以设定角色时先想清楚你要的是这个角色的专业深度还是这个角色的沟通效果。两边都要的场景最好在角色后面加上明确的沟通对象“你是资深专家但你的读者是完全没有背景知识的新手”这两句话加不加输出风格差很远。4.2 反面示例加得太多模型变得缩手缩脚我在 2.3 里说了反面示例的种种好处但反面示例也不是越多越好。有次我做一个短视频口播稿生成的提示词一口气加了六个反面示例把“不要过于正式、不要过于口语、不要有网络流行语、不要使用感叹号、不要出现专业术语、不要超过30秒”全部塞进去。结果模型产出的稿子确实一个雷都不踩但同时也完全失去了表达力——语言干巴巴的一点感染力都没有像被阉割过的保险条款。反面示例本质上是在限制模型的输出空间。限制得太多模型就会往“不出错”的方向过度收敛输出的多样性、趣味性、文采全没了。我现在给自己定了一个经验法则反面示例集中在最不能接受的那一两个行为上其余靠正面描述和语气词引导效果反而好得多。4.3 期望一次成功实际上提示词工程是微调迭代的过程刚开始做提示词工程的人最容易有的心态是期待第一版提示词就能直接交付。我自己也犯过这个病。有一回客户要一批用于海外市场投放的产品卖点描述我自认为提示词写得天衣无缝结果第一批输出里充斥着“世界一流”“卓越品质”这类在英文投放里极其悬浮的表达。我当时的第一反应是“这模型不行”冷静下来才发现是我没在提示词里约束“避免空洞夸大用语”。后来我复盘时意识到提示词工程和生产一个实体产品没有本质区别都有原型、测试、反馈、迭代的过程。第一版能做到 70 分已经不错了剩下 30 分就是靠一轮轮的微调逐步逼近。区别只在于代码工程里的 Bug 你能直接看到报错信息但提示词的“报错”长什么样需要你自己定义——你想要的输出长什么样你心里得先有那张“标准答案图”。5. 模板库之外三个提高提示词复用效率的小习惯模板只是静态的文本真正让提示词在长期使用中越来越顺手的是配套的使用习惯。我在跑了一段时间的提示词项目后逐渐沉淀出三个小习惯这里一并分享。第一个习惯是给每个模板配上“使用说明”。模板里哪些变量适合什么场景、哪些字段容易让模型出错、上一次使用时发现什么问题全部写在模板文件里。下次打开你不需要重新回忆上下文直接看说明就能上手。我自己的模板文件里有些模板下面写的备注比模板本身还长但正是这些备注让我在三四个月后还能快速捡起一套旧的流程。第二个习惯是记录“失败输出片段”。每次迭代提示词时我会把模型跑偏的输出原样粘到模板文件里并标注“发生条件后续追加了 XX 约束后”。这看起来像给自己添麻烦实际价值非常大——它能帮你快速定位到某个具体约束和某个失败模式之间的因果关联。你就不需要靠记忆去维护这些经验了。第三个习惯是控制一次对话里任务的颗粒度。不要试图在一个提示词里让模型完成“分析数据 写报告 生成图表说明 给领导写摘要”一条龙。任务越复杂变量越多出错的概率越大。我更倾向于把大任务拆成几个小提示词一个环节一个环节来每个环节的输出都检查一遍再进入下一个。速度慢一点但总返工时间反而更短。6. 如果你只愿意记住一个概念先定义输出再约束过程写到最后我把十多个技巧压缩成一句可以在脑子里反复调用的话先定义输出再约束过程。很多提示词之所以不听话不是模型能力不够是你对“输出”本身的定义就不够具体。你只说了“帮我想几个选题”模型就只能瞎猜选题的口径、范围、字数、风格、目标用户。可如果你先说清楚“输出5个选题每个选题包含核心卖点一句和适合人群一句”模型的动作立刻就被框住了。我在做了大量提示词项目之后越来越觉得提示词工程的本质就是一场“预期管理”。你在文本里把预期描述得越精确、越具体、越可验证模型的输出就越接近你的预期反之预期越模糊模型的自由度就越大翻车概率也越大。这不是什么玄学更不是什么不可解释的能力它只是把“需求表达”这个基本功换了一种方式重新做了一遍。至于标题里承诺的“立刻上手”——别贪多十技巧速成不现实。你可以只用上其中两三个把它们变成每天都要用的肌肉记忆。等哪一天你发现在一个新场景里顺手写出的提示词已经天然包含角色、格式、条件分支这些要素那时候你回头看最早写的第一版提示词会明显感觉到自己跨过了一个阶段。