我见过不少同学同一个模型、同样的账号写出来的效果能差出一大截。有人把提示词当成说话想到什么写什么有人把它当成写代码每个词都在明确告诉模型要干什么。差距就在这个认知上。提示词工程不是什么玄学它是一套可以学习和复用方法。这篇文章整理了我实际工作中最常用的10个提示词技巧每一个都能立刻上手还附上了可以直接抄作业的模板库。适合平时要用AI写文案、做分析、写代码、处理信息的同学不管你是刚接触提示词的新手还是已经玩了一段时间想系统化的老手都能在里面找到对你有用的东西。1. 提示词工程的底层认知你写的是指令不是留言很多人第一次接触AI对话时习惯用发微信的方式跟模型沟通帮我看看这个呗写得好一点再改改。这些说法在人际交往里没问题因为人会自动补全语境、语气、背景和预期但模型不会。它本质上是一个基于海量文本训练的下一词预测器你的指令越模糊它的输出就越随机。我常跟团队说的一句话是提示词工程不是把话说得礼貌而是把需求翻译成模型能执行的指令。你在写提示词的时候其实是在做一次需求规格说明。需求文档写得清楚的人提示词一般也写得不差反过来适应了提示词工程的人回去写需求文档通常也更利落。因为两者底层是同一个能力把抽象目标拆成可验证的具体步骤。1.1 模型不会猜潜台词它只会按字面执行举个例子。你有两个同事一个跟你要一个方案另一个跟你说针对老用户复购率连续三个月下滑的问题我需要一份复盘方案包含数据现状、原因假设和3个可落地的提升措施明天下午3点前给我格式用一页PPT能讲完的简报。你更愿意接哪个模型也一样。后者就是一段合格的提示词雏形。它包含了任务、背景、约束、交付格式和验收标准。很多提示词翻车不是因为模型笨而是因为我们给了它一个需要猜的需求然后怪它猜错了。我做了个小实验来验证这个认知。同样是让模型写一段产品介绍指令一写帮我写一个保温杯的介绍指令二写你是一位电商文案专家请为定价199元的保温杯写一段150字左右的小红书风格介绍突出便携和12小时保温两个卖点语气活泼但不夸张结尾加3个推荐场景标签。指令二生成的内容可以直接放到商品页里微调使用而指令一的输出更像保温杯是一种喝水容器的百科词条。同一个模型差别全在提示词。1.2 一个万能设计公式角色、任务、背景、约束、格式、示例如果你想快速进入设计提示词的状态用这个公式起步就够了一段完整的提示词 角色 任务 背景 约束 格式 示例角色模型以什么身份回答决定了它调用的知识范围和语气。任务明确动词加对象比如提取对比改写修复不要用处理一下这种模糊动词。背景这个任务为什么存在给谁看现状如何。约束字数、受众、禁止项、风格边界。格式表、JSON、列表、代码块给一个模板更佳。示例如果有参考范式直接给模型看比形容词描述一百遍都管用。不是一个提示词必须包含全部六项而是你要有意识地检查自己漏了哪几项。大多数效果不好的提示词漏的都是约束和示例。下面这10个技巧本质上就是围绕这个公式的某个维度做强化。2. 让模型听懂需求5个输入侧技巧这一组的核心目标是降低模型理解偏差。模型经常没听懂往往不是因为它的语义理解能力差而是你的需求在文本层面就不完整。前5个技巧每一个都能让你少说几句话反而得到更准的结果。2.1 技巧1角色设定——给回答一个明确的立场角色设定的作用是给模型一个知识过滤器。同样是解释什么是数据库索引如果你让小学科学老师来解释它会用卡片盒和目录打比方如果你让DBA来解释它会从B树和磁盘IO说起。模型不是不知道数据库索引是什么而是不确定你希望它以什么角度回答角色设定帮它缩小了范围。我实测下来的心得是角色越具体越好但不能只给头衔。比如你是运营专家就太单薄你是一位在本地生活行业做了8年、擅长用数据分析指导门店增长的运营专家就立体得多。附加的信息不是废话它是在告诉模型应该调用哪一块语料、用什么样的判断标准来组织回答。一个可以立刻上手的模板你是{具备某种背景/经验/立场}的{职业或身份}。 请以这个身份完成以下任务{具体任务}。 注意无论你扮演什么角色都要基于事实回答不要因为角色设定而虚构数据。最后一句尤其重要。很多把角色玩砸了的情况是模型入戏太深开始编造作为资深专家我见过无数案例却不给实际依据。角色设定提供的是话术和视角不是编造事实的授权。2.2 技巧2示例锚定——用范例代替抽象描述要说十个技巧里哪个性价比最高我会投示例锚定。你不需要向模型解释我想要什么样的风格直接给它一个例子它就能模仿得七七八八。这背后是上下文学习的能力模型在推理时会参考输入中已有的模式你要做的就是把你想复制的模式塞进上下文里。最典型的场景是批量处理。比如你要把20条客服反馈改写成标准格式与其写请以严肃专业的语气、不超过50字、包含问题类型和处理建议不如直接给模型一条已经写好的范例参考下面的格式处理我的每条输入 输入客户投诉物流慢要求退款 输出 问题类型物流时效 处理建议核对物流节点向客户致歉并告知预计到达时间 其他备注无 下面是新输入 输入{要处理的内容}注意示例要给输入输出成对的内容而不是只给输出。模型需要从成对关系里学习映射逻辑这是很多人容易忽略的细节。只给一个输出示例它可能只能模仿格式学不到识别输入关键信息这个步骤。还有一点示例的数量和质量比数量重要。1个高质量示例通常比5个随意示例效果好。如果可能给2个示例其中一个覆盖边界情况比如上面例子里再加一条输入客户没说清楚问题只有一句你们怎么回事然后示范如何在信息不足时标记其他备注信息不足。这样模型遇到类似边界输入时就不会硬编一个答案出来。2.3 技巧3步骤拆解——把复杂任务切成可执行小段人类做一个复杂项目靠的是流程管理模型处理一个复杂问题同样需要流程化。你让它分析这份销售数据并给出建议它会给你一份面面俱到但没重点的泛泛之谈。你让它先计算环比变化率再标注连续下滑的产品线最后针对下滑产品线给出原因假设它的输出质量会成倍提升。步骤拆解的核心逻辑是把模型的注意力引导到过程上而不是让它直接跳到结论。市面上常说的思维链本质也是这个思路让模型先展示推理过程再给出答案。复杂任务的准确率提升靠的不是模型突然变聪明而是分步之后每一步的失败率可以被控制。一个通用模板请按以下步骤完成任务 第1步{从原始信息中提取/整理需要的字段} 第2步{执行计算/分析/对比并解释依据} 第3步基于第2步的结果给出{最终结论/方案/建议} 输出时请完整保留每一步的结果方便我核验。我个人的经验是拆解的粒度以每一步能用一句话说清为上限。拆得太细比如连第1步打开文件第2步读取第一行都写进去反而会限制模型的处理方式让它变蠢。拆到人可以直接执行的子任务这一层是最合适的。2.4 技巧4显式约束——把潜规则写成明规则写得简洁一点专业一点有感染力一点——这些词不是约束是形容词。模型对形容词的解读高度依赖上下文你心里想的简洁可能是300字模型理解的简洁可能是800字。显式约束的意思是把评价性的形容词翻译成可度量的规则。举几个翻译方式简洁一点 → 控制在150字以内分为不超过3个要点专业一点 → 使用该领域术语不解释基础概念面向有3年以上经验的从业者有感染力 → 多用短句和动词开头用一个具体场景引入避免抽象形容你可能会担心约束太多会把模型锁死。确实有这个风险我的经验是一次提示词里的硬性约束不要超过五六条。约束超过这个数量模型会出现顾此失彼的典型症状字数达标了格式丢了格式对了语气又不对。还有一个优先级技巧如果你有一条特别重要的约束把它放在任务指令的附近或者在后面单独强调一句最重要的要求是{约束X}其他要求可以为此让路。模型在处理长提示词时也有注意力分布越靠前和越靠后的内容遵循度往往越高埋在中间的多条约束容易被稀释。2.5 技巧5负面排除——明确画出输出禁区显式约束解决的是应该怎么做负面排除解决的是绝对不能怎么做。模型对否定指令的理解能力不如肯定指令所以你不能只写不要瞎编而要具体到如果信息不足请明确回答无法从现有信息判断不要自行推测。负面排除最常见的应用场景是那些模型容易犯顺手牵羊错误的任务。比如让模型翻译一份合同它可能顺手把语气翻译得比原文更强硬让模型修复一段代码它可能顺手优化了旁边的代码逻辑。这些都属于你没让它做但它做了的情况。用负面排除可以把它拦住约束 - 翻译时忠实原文语气不要自行润色或弱化 - 只修复导致报错的部分不要重构其他函数或改动原有代码风格 - 如果遇到不确定的术语保留原文并在括号里标注再补一个实战技巧负面排除最好和替代方案一起出现。单纯说不要用负责这个词模型可能改成一堆同样空泛的替代词。但你如果写不要用负责这种笼统表述请改成主导了什么带来了什么结果模型就有了明确的替换方向。一句话总结就是给负面清单时顺手给一个正面指引效果翻倍。3. 让结果更接近交付标准5个输出侧技巧如果说前5个技巧解决的是模型有没有理解我后5个技巧解决的就是模型给出的结果能不能直接拿去用。很多人把提示词的终点放在模型回答完那一刻但其实从回答到可用中间还有5个可以施加影响力的环节。3.1 技巧6结构化输出——让内容可解析、可复用我处理的提示词任务里最怕看到的一句话是请生成一份分析报告。模型会输出一大段排版精美但无法程序化处理的文本你还要花时间整理成表格或结构化数据。与其事后转换不如在提示词阶段就要求结构化输出。结构化输出的最低标准是输出格式能被机器解析或者能被你直接复制进另一个工具使用。JSON是程序处理最友好的格式Markdown列表适合直接贴文档表格适合对比信息。你只要在提示词里写明格式并提供字段名模型的遵循度就很高请从以下招聘JD中提取关键信息用JSON格式输出字段包括 job_title, company, location, experience_years, salary_range, required_skills, responsibility 如果某个字段原文没有写null不要编造。这类提示词的值钱之处在于它把模型当成了信息抽取管道的一部分。我平时做竞品调研时会对几十个页面跑同样的提示词再把JSON合并到表格里。没有结构化输出之前这一步人工整理至少要一两个小时现在只需要清理数据。给字段名时建议用英文或拼音避免不同系统之间的编码问题和引号转义问题。另外如果你打算在同一个对话里继续追问可以在提示词结尾加一句只输出JSON不要输出任何解释文字否则模型经常会贴心地加一句以下是根据您的要求提取的信息这会给后续程序解析制造麻烦。3.2 技巧7上下文重述——别让模型在长对话里失忆长对话像一场沟通马拉松。你和模型聊了30轮中间改过需求、调整过风格、确认过几个细节到第31轮你觉得它应该还记得最开始的要求于是直接说再按这个思路优化一下。结果它给你输出的东西更像是基于最近5轮对话的理解而不是基于最初的目标。这不是模型故意敷衍而是长上下文中的信息密度太高早期约束被大量后续内容稀释了。我用了一个很笨但有效的办法关键信息重述。具体来说当对话进入一个新阶段时不再依赖模型记住之前的所有细节而是把必要的信息重新整理一遍综合之前的讨论本次需求的关键信息如下 - 产品定位针对25-35岁都市白领的即食燕麦片 - 内容形式小红书种草文案200字左右 - 核心卖点热量低、饱腹感强、冲泡方便 - 已确定的口味不要出现的语气过于夸张和功利 请在保留以上要求的基础上根据最新的信息{新信息/新反馈}输出更新版本。这个技巧的本质是把模型的内存外包给自己。你不再要求一个对话保持状态而是每次都给模型一份浓缩的需求快照。很多人不习惯这么做觉得重复信息很啰嗦。但我测下来清晰地把关键约束重新说一遍比反复说记住我之前说的有效得多。我还习惯把最重要的指令放在消息的最后一段因为模型对上下文末尾的内容通常有更强的注意力。3.3 技巧8迭代修正——把一次成稿变成精雕细琢很多人对AI生成的期待是一次到位事实上一次到位是例外迭代才是常态。我写任何重要内容都会做好至少两轮修改的准备。这不是说第一次生成的质量差而是因为模型的技术定位决定了它擅长快速生成候选稿而不是一次满足所有隐性需求。迭代修正的用法很简单不是从头再来而是在已有内容基础上做增量修改。你要修的是具体维度比如在第二段补充一个用户案例从180字压缩到120字把语气从书面改成口语。每次只提出一个方向的修改你就能清晰地看到变化发生在哪里也便于判断方向对不对。一个容易踩的坑是用模糊的再润色一下不够好这样的指令。模型不知道你说的不够好是哪里不够好它只会随机调整一遍甚至把本来不错的地方改坏了。正确的修正是针对性的先指出具体问题再描述你希望的结果。比如第二段的逻辑链条不够紧从产品好到值得买之间的过渡太突兀请加一句关于价格优势的说明。迭代到什么时候停我的经验是当你发现最新一次修改只带来边际变化、没有新增价值时就该停了。模型优化有一个快速收敛区间过了那个区间之后你再让它改它可能只是在不同的表达方式之间来回横跳。3.4 技巧9多方案对比——用评估代替凭空创作这是一个容易被人忽略但极其好用的技巧。当任务没有一个明显标准答案时比如起名字、规划内容选题、设计活动方案让模型直接给一个答案它通常会给你一个平均水平的答案。但如果让它先给出3个不同方向的方案再对比各自的优缺点输出质量会有明显提升。原因是多方案生成激活了模型的发散模式对比评价又切换回了收敛模式。模型在一段输出里同时完成了发散和收敛这个过程的整体质量远高于直接收敛出一个答案。一个实战模板针对{需求}请提供3个差异明显的方案。 方案一偏稳妥适合{场景A} 方案二偏创意适合{场景B} 方案三偏激进适合{场景C} 每个方案给出核心思路和1-2句说明。 最后请告诉我如果只能选一个你推荐哪个为什么注意差异明显四个字一定要写。不写的话模型给的三个方案可能只是用词不同本质是同一个方案换三种说法。另外必须推荐一个并说明理由这个要求能倒逼模型做出决策而不是给一堆选项让你自己选。我不需要模型替我承担决策责任但我需要它展示出决策依据这样我能更快判断它思路里的亮点和盲点。3.5 技巧10自检复核——让模型当自己的审稿人最后一个技巧是让模型审查自己的输出。这听起来有点绕但确实有效。模型在创作模式下会为了流畅输出而牺牲准确性当你切换指令让它进入审查模式时它的注意力会完全换一套标准很多生成阶段漏掉的问题在这个阶段能被发现。我常用的自检指令分两种。一种是通用性的请检查以上回答找出事实性错误、逻辑漏洞、格式遗漏并输出修正版。检查时请不要直接重写先逐条列出你发现的问题。让模型先列出问题而不是直接给修正版是有意的设计——如果它直接给修正版你很难分辨它到底有没有真正发现问题还是只是把文本重新换了一种说法。另一种是场景针对性的。写代码时让它检查上面的代码是否存在边界条件未处理、异常未捕获、变量命名不一致的问题写商业分析时让它检查结论是否有数据支撑以及是否包含了足够的前提假设说明。关于自检有一个我必须诚实分享的边界模型的自检能力不等于事实核查。它更像是一个文本逻辑复核而不是外部事实核验。如果模型第一次回答时的信息来源本来就是错的它的自检通常发现不了这个问题甚至可能在自检时把原本正确的信息也改成了另一个错误版本。所以涉及到具体的数字、时间、引用和人物信息最终一定要人工过一遍模型自检只能用来捕捉逻辑和格式问题。4. 模板库落地从技巧到可复制的武器库技巧讲完接下来要把它们沉淀成能直接复用的东西。很多人的做法是收藏一屏幕的万能提示词用的时候却发现效果平平。模板不是越多越好而是要看它是否由清晰的思路支撑。下面这套模板库是我在工作中反复打磨出来的每个模板都组合了上面2到3个技巧你可以直接改掉括号里的内容就用。4.1 通用提示词骨架一张表看懂所有要素先把10个技巧收拢成一个通用骨架你在构思任何一个新提示词时可以用它打底要素说明示例角色模型以什么身份/视角回答你是一位从事本地生活行业8年的运营经理任务期望模型完成的动词性目标分析这3家门店的月度销量差异原因背景任务为什么要做、给谁看报告将提交给区域负责人用于调整下月策略约束字数、受众、边界、优先级结论不超过5条每条都要有数据依据格式输出的组织形式使用表格展示对比并用一句话总结示例期望的输出范式参考下列模板的撰写方式写提示词时从这行表格从上往下过一遍。如果哪一栏是空白的问自己一句这里不写清楚模型会怎么猜。绝大部分翻车的提示词都是因为某一栏留白太多。4.2 四个高频场景的完整模板场景一产品种草文案你是一位熟悉小红书内容风格的美妆产品文案专家。 任务为下面这款洁面乳写一篇种草文案。 产品信息{粘贴产品资料} 要求 1. 字数控制在250字左右段落短小方便手机阅读 2. 开头第一句直接点出核心卖点不要铺垫 3. 语气真实、口语化不要使用夸张词藻 4. 不虚构个人使用体验用产品成分和质地等客观信息支撑 格式直接输出正文结尾加3个#话题标签这个模板的组合逻辑是角色设定美妆文案专家负责语气和知识聚焦显式约束4条要求负责格式和边界负面排除不虚构体验负责防止模型编造用户反馈。场景二数据诊断分析你是资深数据分析师。 任务根据以下销售数据找出连续三个月下滑的产品线。 数据{粘贴表格数据} 请按步骤执行 1. 提取每个产品线近6个月的销售额 2. 计算环比变化率标注出连续下滑的月份 3. 基于已有数据给出不超过3条可能原因假设 输出要求 - 用表格呈现计算结果 - 结论写在表格下方 - 只基于数据本身分析不要推测团队管理、市场政策等外部因素 - 如果数据不足以得出结论请明确说数据不足不要强行给结论这个模板的核心是步骤拆解和负面排除的组合。第3步里的只基于数据本身分析非常关键否则模型会给你一堆关于可能是市场竞争加剧可能产品口碑下滑这类无法验证的漂亮废话。场景三代码Bug排查你是擅长Python后端调试的资深工程师。 任务帮我找下面这段代码为什么报错。 代码和报错信息{粘贴} 约束 1. 只分析当前代码不要建议重构整个项目 2. 先说明根因再给最小可复现的修复方案 3. 修改后的代码必须和原代码风格保持一致 4. 如果信息不足直接说你还需要哪些上下文不要猜测 输出格式根因 - 修复方案 - 修改后的代码写代码提示词时我特别强调只分析当前代码不要重构整个项目这两句负面排除是因为模型在解决局部问题时经常顺手动到旁边的代码产生大量你根本不想看到的改动反而提升了代码合并的复杂度。场景四文档总结归档请总结下面的会议纪要要求 1. 按决定事项、待办任务、争议未决三部分输出 2. 每部分用无序列表每项不超过30字 3. 人名保留原样不要用负责人A之类的替代 4. 如果原文对某件事没有明确结论归入争议未决不要替你补全结论 文本{粘贴会议纪要}这类模板的重点是结构化输出加自检的痕迹。你指定了三部分结构模型就不太会输出一段流水账第4条约束则是让它不要脑补会议中根本没达成的共识。4.3 模板的正确打开方式替换、组合、存档模板使用有一点要特别注意模板里的每一条要求最好都能对应到你遇到的实际问题上。不要因为模板里写着不要虚构个人使用体验就把这句话原样用在完全不相干的任务上。模板的价值是告诉你这个维度值得约束而不是这句文案是万能咒语。我更推荐的用法是按自己的高频任务创造模板。找一个你最常让AI做的事比如写周报然后尝试用上面10个技巧组装一段提示词给它一个角色加上格式要求加上一两条负面排除试几轮后把效果最好的版本存下来。三个月后你会积累出一批真正属于自己的提示词资产而不是永远在收藏别人的万能句式。存档时除了提示词本身我还会在注释里写清楚这个模板用在哪类任务、上次用效果如何、改过哪几个版本。对像维护代码注释一样维护你的提示词模板。这是把临时技巧变成长期生产力的关键一步。5. 实测翻车与自查这些坑我帮你踩过了我总结的这10个技巧并不是一开始就全部有效每一招都有踩坑的黑暗历史。把印象最深的坑写出来目的是让你少走弯路。5.1 角色入戏太深任务被风格带偏有一次我做法律条款解读给模型设定的角色是擅长把复杂法律术语翻译成大白话的科普编辑。模型确实把话说得通俗了但代价是丢失了法律文本中必要的精确限定把一些在特定条件下有效的表述简化成了普适结论。这就是角色设定带来的副作用模型为了贴合角色风格牺牲了任务本身的严谨性。后面我再设定角色时会补一句即使作为{角色}也要在专业性和准确性上保持最高优先级或者可以用通俗的语言解释但不能因为通俗而省略重要的限定条件。角色设定是风格导向的它不该凌驾于事实导向之上。当任务本身要求精确时角色的话术要弱任务的标准要强。5.2 示例选得不对反而成了干扰用示例锚定时我翻过最大的车为了让模型输出一个我非常满意的方案我给了它一个自认为完美的示例。结果模型不仅模仿了示例的结构也模仿了示例的用词甚至把示例里过时的数据和特定场景也带进了新任务。我花了几轮迭代才把那些从示例里学来的杂质清理干净。原因在于示例的力量比我们想象的大模型会把示例中所有特征都当作可能复制的模式包括你根本没打算让它学的那些细节。解决方法是示例要精简只保留你想让模型复制的核心模式。如果你想让模型学会的是结论先行、用数据支撑的叙事方式那么示例就只展示这种结构的骨架不要在示例里加入太多具体的行业背景或个性化表达否则模型会以为那是你也想要的内容。5.3 一份15分钟快速自查清单最后给你一份自查清单。每次拿到一段不理想的输出时不要急着怪模型先用它逐项排查。以我个人的经验80%的问题能在这里找到答案[ ] 任务动词是否明确有没有用处理一下看看这类模糊词[ ] 是不是缺少角色设定导致模型不知道用什么视角回答[ ] 有没有给出背景信息模型知不知道这份输出给谁看、做什么用[ ] 是否用形容词代替了可度量的约束字数、格式、受众是否写清了[ ] 有没有明确的负面清单哪些绝对不能出现[ ] 是否提供了示例示例本身是否干净、有代表性[ ] 输出格式是否提前指定还是让模型自由发挥[ ] 如果任务复杂有没有做步骤拆解还是让模型一口气憋出答案[ ] 这是第一次生成还是可以进入迭代修正流程我有没有给出具体修改方向这份清单我打印过一份贴在公司工位上。很多看似模型太笨的问题逐项检查下来其实是提示词里某个环节的缺失。把清单跑一遍再决定是改提示词还是换工具比无头苍蝇式地重试高效得多。最后分享一个我自己坚持了很久的习惯每当写出一个效果惊艳的提示词我就顺手存进模板库并在后面标注当时的需求背景。三个月后我发现真正高频复用的是那二三十个带场景说明的模板而不是网上收藏的万能提示词。提示词工程走到最后拼的不是一时灵感而是你有没有把每次成功的方法沉淀下来。别怕一开始慢这些技巧用多了之后写一条高质量提示词也就是一两分钟的事但产出的结果会稳定地比随手写的那些高一个档次。