我正式研究提示词工程是从一次发布翻车开始的。那时候我让 AI 帮忙起草一份给客户的软件更新说明结果它洋洋洒洒写了一千多字翻来覆去全是全新升级、体验优化、功能增强这类放之四海皆准的废话。那一刻我意识到问题不在模型而在我的提问方式。后来我花了很长时间把各种公开方法和自己踩坑总结的技巧整理成一套打法也就是这篇文章要分享的 10 个提示词工程技巧。每个技巧都配了可以直接抄的写法和模板文章末尾还有一个分类模板库适合所有正在跟提示词打交道、想把 AI 输出质量稳定拉高的朋友。1. 先别急着写提示词三个影响效果的关键误区技巧之所以能起作用前提是你没踩进最常见的三个坑。我见过太多人拿着同样的问题去问模型效果差得离谱最后全甩锅给模型不行。其实拉开差距的往往不是工具而是提问前的基本功。1.1 误区一把提示词当搜索框问完就走很多人习惯把大模型当搜索引擎用上来就是帮我写个方案帮我总结一下报告然后期待输出的内容能直接用。搜索引擎没给够关键词也能给个大致结果因为它是靠关键词匹配去捞现成页面但大模型不一样它做的是概率预测——根据你的输入去推断你心里最想要的那个答案。输入里信息越少它能依赖的就只剩训练数据里的常规套路于是它只能给你一个任何场景都能套、任何场景都不精准的平均答案。这就像你请一位外包设计师做海报需求只给一句话帮我设计个海报他真没法知道你要的是电商大促风还是极简性冷淡风最后只能交个通用模板应付。问题不在设计师在需求文档太薄。提示词工程的第一步就是把自己从搜一下的心态切到写需求文档的心态你想让模型做什么、为谁做、做到什么程度先想清楚再敲回车。1.2 误区二指令太空模型只能靠猜写得专业一点语言生动一些做个好看的排版这类话都属于无信息量指令。什么叫专业什么叫生动模型其实没有你的判断标准。它可以往学术论文方向写也可以往商务报告方向写两个方向都算专业但显然不是你脑子里那个版本。要让模型不再靠猜你得把模糊形容词翻译成可衡量的标准篇幅多少字、目标读者是谁、什么语气、分几个模块、需要包含哪些信息点、必须避免什么。举个例子你让 AI改一下这句话让它更专业远不如给它这样的指令把下面这段产品说明改写为给企业采购人员看的版本保留核心参数删掉夸张形容词语气克制中性输出 3 个版本每个不超过 120 字。后者的输出基本可以直接用前者往往是在碰运气。1.3 误区三一次成型心态缺少迭代意识第三个坑是心态问题。很多人默认提示词和数学公式一样写完必须一步到位。一旦输出不理想就得出这 AI 不行的结论。但实际上提示词更像代码——写完第一版能一次通过的概率很低大部分时候需要反复调试改措辞、补例子、加约束、换拆解思路才逐渐逼近理想输出。我习惯用一个类比写提示词就像给同事布置任务。你说了一遍对方理解偏了正常的做法是再解释清楚一点而不是甩下一句你能力不行就走人。模型也是一样第一次没做对就换一种方式重新表达。把一次成型的执念换成快速试错、逐步收敛的思路后面那些技巧才能派上用场。2. 技巧 1-3定角色、抠动词、把信息前置前三招属于提示词的地基决定了模型以什么身份、执行什么动作、基于什么信息开始思考。地基打正了后面的进阶技巧才有意义。2.1 技巧 1角色锚定给模型预设角色本质上是在修剪它的输出空间。大模型的训练数据覆盖了百科、小说、新闻、代码、客服记录等无数语域你不给它角色设定它输出的是所有语域的平均值——哪个领域都沾一点哪个领域都不够地道。但一旦你告诉它你是一名有 8 年前端开发经验的工程师它就会自动偏向技术语域输出里会多一些工程化的思考方式和行业黑话。角色设定有一个关键细节不能只说你是专家越具体越好。同样是产品经理写你是一名负责中小商户收银软件的产品经理比你是一名产品经理要强得多因为前者会在输出时主动代入商户的真实使用场景和产品迭代的表达习惯。看个对比就明白了。基础版提示词是请帮我写一个版本发布说明模型给你的大概率是功能罗列毫无重点。改进版是你是一名有多年经验、负责维护一款面向中小商户收银软件的产品经理现在要为即将发布的 v3.2 版本撰写一份给终端商户的更新说明。后者的输出会自动带出商户关心的点比如操作界面变化、对日常收银的影响、是否需要重新配置而不是一堆空泛的功能名词。模板骨架我放在这里你可以直接套你是一名[角色]拥有[具体经历/专长]。现在请你[任务]服务于[受众]最终输出用于[用途]。每个方括号都逼着你补全信息写完整理完提示词的质量已经超过一半的人了。2.2 技巧 2动词驱动的任务指令模型对精确的动作动词更敏感。总结、改写、翻译、对比、分类、排序、解释、举例这些词比处理一下写一写弄一下明确得多。同一个任务动词选得不对输出结构会完全跑偏。比如解释一下什么是微服务和给微服务举个生活中的例子前者要求逻辑说理后者要求具象映射模型会给出完全不同的两类答案。这里有一份我常用的动词速查表写提示词时对着挑一个主动词就够了目标推荐动词示例压缩信息总结、提炼、缩写用 50 字总结下面这段文字的核心观点转换形式改写、扩写、转述把这段话改写成适合朗读的口语版本分析对比对比、分析、归类对比方案 A 和方案 B 的优劣势结构整理排序、列出、分类按优先级从高到低列出所有待办项辅助理解解释、举例、类比用一个生活案例解释这个术语一个提示词里建议只保留一个主任务动词。如果你想让它做多步操作不要用然后一笔带过而是用编号明示步骤1. 先用 50 字总结原文2. 再列出三个可能的风险3. 最后给出应对建议。明确的主动词加上编号步骤模型就跟接到了带排期的任务单一样很少会漏环节。2.3 技巧 3信息前置提示词的排版顺序直接影响模型对信息的权重分配。从注意力机制的特性来看出现在前文的内容会在后续生成中占据更高的语义权重。也就是说重要的背景、约束和上下文应当尽量往前放不要藏在长提示词的最后。一个我反复验证过的高效结构是四段式[背景信息]产品是收银软件目标用户是中小商户本次更新新增库存预警功能。 [约束条件]全文不超过 300 字不使用技术术语语气口语化。 [任务指令]撰写一份面向商户的版本更新说明。 [输出格式]分三段本次更新内容、操作变化提醒、常见问题。模型的注意力从一开始就被锁定在给中小商户写口语化说明这个语境里后面的输出自然不容易跑偏。我看到很多人习惯把任务写在最前面、背景信息反手丢在最后面这种写法不是不行只是模型的注意力已经被前几个字带偏了后面的背景信息很难再拉回正确的语义场。实测下来信息块前置的提示词返工率能少一半。3. 技巧 4-6示例、思维链、任务拆解把输出质量再拉高一档如果你已经能把指令说清楚了接下来要解决的是听懂归听懂输出不够好的问题。这个时候需要上场的是少样本示例、思维链和任务拆解。3.1 技巧 4少样本示例Few-shot有时候光用形容词描述你要的风格说破嘴皮子也不如直接给模型看一个标准答案。少样本提示就是在提示词里塞入少量输入-输出示例让模型照着示例的格式和调性来生成。示例的价值不只是示范结构更在于传达那些只可意会不可言传的标准——比如句子的颗粒度、转折词的用法、口气是克制还是热情。举个例子。你可以在提示词里先放一个参考「v2.8 更新说明 本次更新主要解决两个问题一是修复了导出报表时偶发卡死的问题二是新增了按日筛选报表的功能。使用上有一点变化——报表默认改为最近 30 天数据如需查询更早数据请在筛选器中自行选择。」请模仿这段的风格为 v3.2 撰写更新说明。模型看过这个参考之后会本能地模仿先总说目的、再分点说明、每一条都点出对用户的影响这个套路。比你在后面加十句写得具体一点都管用。这里有个进阶技巧如果能给一正一反两个示例效果会更好。先给出你想要的写法再补充一句不要写成这种风格『本次版本华丽升级为您带来前所未有的流畅体验』正反面对齐之后模型的收敛速度会明显加快基本两轮以内就能稳定在你想要的风格上。3.2 技巧 5思维链Chain-of-Thought当你问模型一个需要推理的问题直接要答案往往容易出错。原因很简单模型在跳步它省略了中间的推理过程直接从问题跳到结论中间一旦有一步想当然结论就不可靠了。思维链提示的做法是要求模型先展示推理过程再给出最终结论。实操写法就是在提示词末尾加一句请一步一步思考先列出你的推理过程再给出最终结论。我举个例子。如果我问这次功能更新会不会引发商户咨询量上升模型可能直接答会有一定影响这种不痛不痒的话。但如果要求它先列举更新了哪些功能 → 哪些功能改变了商户的既有操作习惯 → 习惯改变最容易引发什么疑问再综合判断它给出的回答会细致得多甚至能预判出库存预警阈值设置这种具体咨询点。不过思维链也不是每次都要用。我的原则是看任务难度简单改写、格式转换这类任务不需要思维链加上去反而拖沓涉及逻辑推理、多因素权衡、长文本规划的任务才值得启用。3.3 技巧 6分步拆解Task Decomposition一个提示词里塞太多要求模型就容易顾此失彼写完开头的两个要求把后面的要求忘个干净。与其让它一口气完成一个巨型任务不如把它拆解成几个可控的步骤。拆解有两种实现方式一种是在同一条提示词里用编号定义步骤。比如1. 先列出这篇文章的大纲2. 根据大纲写一个 300 字摘要3. 最后给出 5 个备选标题。这种方式适合步骤不多、顺序明确的场景模型会按编号逐步执行结构感很强。另一种是把任务拆成多条独立的提示词每条完成一个子任务。比如写一篇深度调研报告可以先让模型生成大纲你审完大纲再让它逐节展开最后单独让它做整体润色。这种多轮方式的优势是每个关键节点都有人工检查单步输出质量更可控代价是流程变长、往返变多。我的建议是能拆成编号步骤的任务优先用一条提示词搞定需要在关键节点人工把关的重度任务再走多轮拆解的路线。真实工作里两者经常混着用同一个项目里大概率两个都出现过。4. 技巧 7-8管得住格式、划得出边界结果才能直接用前六个技巧解决的是内容对不对、好不好的问题接下来的两个技巧解决的是输出能不能直接用的问题。说实话后者在工作中往往更关键。4.1 技巧 7结构化输出当模型输出要进入后续流程——导入表格、程序解析、作为素材入库——你就必须对输出格式做硬性约束。常见的约束形式包括 Markdown 表格、JSON、CSV、带编号的层级标题等。举个例子我想让模型把产品需求转成结构化字段可以直接这么写请把下面的产品需求转换为 JSON 格式字段包括feature_name、target_user、problem、solution、priority。 只输出 JSON 对象不要加任何其他文字。模型返回的结果大概是{ feature_name: 库存预警, target_user: 商户店长, problem: 库存不足时无法提前补货导致缺货, solution: 当库存低于阈值时在首页推送预警并给出建议补货量, priority: 高 }这类提示词在自动化工作流里几乎是必需品。有一点需要特别提醒不同模型的输出稳定性有差异如果这个 JSON 要直接交给程序解析一定要在末尾加上只输出 JSON 对象不要加解释文字否则模型经常会在 JSON 前后补一句以下是转换结果导致解析报错。这是我在自动化脚本里踩过好几次的坑。4.2 技巧 8负面约束与边界划定很多人写提示词只写要什么不写不要什么。但实际上给模型划定边界、明确排除项能有效防止它跑偏。模型在生成时看到不要做 X的指令至少会降低 X 的出现概率所以正确用法是正面要求和负面约束组合出击。负面约束必须具体抽象词没有用。你说不要啰嗦模型不知道你眼里的啰嗦是什么样。你应该说不要重复前面已经提到的功能点条数控制在 5 条以内。你说不要用营销话术不如说不要出现一键直达、极致体验、超值钜惠这类词。我特别推荐一个通用约束几乎在所有总结类任务里都能生效如果原文中没有提到的信息请明确说文档中未提及不要自行补充。这一句话就能大幅减少模型在总结时编造细节的冲动。对内容安全要求高的场景我会再加一行只基于给定资料回答不引用外部知识边界立刻清晰很多。5. 技巧 9-10像工程一样迭代提示词而不是靠感觉前面八个技巧针对的是单次提示词的编写最后这两个技巧则关乎长期能力——怎样把一次的成功经验沉淀为可以反复调用的资产。5.1 技巧 9单变量迭代大多数人调整提示词的方式是凭感觉重写输出不理想就整段换掉。这样做最大的问题在于你永远不知道到底是哪个改动起了作用。今天加了角色设定、换了动词、又补了一个示例输出确实变好了但你无法判断是角色起作用还是示例的功劳。我建议用做实验的思路来写提示词一次只改一个变量。给提示词做版本管理v1 是什么样、v2 改了什么、对应输出发生了什么变化全部记录下来。时间长了你会积累出一张宝贵的对照表版本改动点输出变化结论v1初始版本内容太泛没有重点作为基线v2增加角色锚定语气更专业但结构松散保留角色v3增加输出格式要求结构清晰但细节缺失保留格式v4增加少样本示例基本达标定稿入库模板这样做虽然比整段重写稍微慢一点但每一步都在积累可复用的判断力。调过几十次之后你会形成一种直觉看到输出哪里不对就知道该去动提示词的哪个位置——改上下文还是换示例而不是盲人摸象。5.2 技巧 10把成功案例沉淀成模板库跑通一个提示词之后别让它躺在聊天记录里吃灰。把里面的具体信息抽象成占位符它就能变成一个跨场景复用的模板。比如你是一名专门负责维护中小商户收银软件的产品经理可以抽象成你是一名[岗位]专门负责[业务描述]下次换一个行业、换一个任务照样能套进去。我自己的提示词管理文档长这样每个模板包含场景说明、模板正文、适用模型、注意事项四个字段。场景说明让我在需要时能快速检索到正确的模板适用模型提醒我同一个模板在不同模型上的表现差异注意事项则记录那些踩过的坑比如这个模板需要配合思维链使用否则结论太跳。模板化带来一个隐形收益提示词工程的经验可以跨任务复制。你为一个场景辛苦调试出来的结构往往只需要替换几个变量就能服务另一个完全不同的场景。积累模板库的速度越快你在新任务上的起点就越高这是我从开始做提示词管理以后体感最强的一点。6. 模板库拿来就能改的 10 组提示词模板最后把我常用的模板整理出来按场景分好类。使用方式很简单复制模板替换方括号里的变量根据实际需求微调。模板不可能覆盖所有场景但作为起点它们能帮你省掉大量的试错时间。6.1 文案创作类产品发布说明模板你是一名[岗位]从业者负责[产品名]的对外沟通。请为[本次版本号]撰写一份给[目标受众]的更新说明。 要求先说本次更新的核心目的再分点列出用户能感知的变化最后给出操作注意事项。 全文[字数]字以内不使用[禁用词]语气[语气描述]。公众号推文开头模板请为以下主题撰写一个公众号推文开头要求前两句话抓住读者注意力第三句话自然引出文章主题。主题是[主题]目标读者是[人群]文章后续将讲述[核心内容]。请给我 3 个不同风格的开头版本。6.2 学习阅读类文献精读模板你是一名严谨的学术助理。请帮我精读下面这段材料按顺序输出1. 核心论点2. 支撑论据3. 论证方法的局限性4. 与我提供的背景问题[背景问题]的关联。 只基于材料内容回答材料中没有的信息写未提及不要补充外部知识。 材料如下 [粘贴材料]费曼解释模板请用给完全不懂这个领域的朋友讲清楚的方式解释[概念]。要求1. 先用一句话给出核心定义2. 再用一个生活化类比说明3. 最后指出这个概念的常见误解。总字数[字数]字以内不要使用术语堆砌。6.3 数据分析与决策类会议纪要转待办模板请把下面的会议纪要整理成待办事项列表。每条待办包含负责人、事项描述、优先级、截止时间。如果纪要中没有提到某个字段写待确认。尽可能保持原意不要新增纪要中不存在的任务。 会议纪要如下 [粘贴纪要]方案对比模板请对比以下两个方案从成本、耗时、风险、效果四个维度分析给出对比表格最后给出你的推荐及理由。注意推理过程要完整明显权衡之后再下结论。 方案 A[描述] 方案 B[描述]6.4 程序开发类代码审查模板你是一名资深[编程语言]工程师。请审查下面这段代码按严重程度从高到低列出问题。每个问题包括问题描述、可能引发的后果、修改建议。只在确有把握时提修改建议不确定的问题标注待确认。 代码如下 [粘贴代码]报错诊断模板我在运行[项目描述]时遇到以下报错请根据报错信息推断可能的原因按可能性从高到低列出排查步骤。如果信息不足请指出还需要提供哪些信息不要猜测。 报错信息如下 [粘贴报错]6.5 通用输出类结构化总结模板请从以下角度总结这段内容背景、核心观点、关键数据、结论、可执行动作。每个角度不超过[字数]字。只基于原文不要补充外部信息。 内容如下 [粘贴内容]多版本改写模板请把下面这段文字改写成 3 个版本版本一正式书面版版本二口语沟通版版本三社交媒体版。每个版本控制在[字数]字以内保留原文核心信息。 原文如下 [粘贴原文]模板与模板之间还可以互相嵌套。比如把结构化总结模板和费曼解释模板叠加就能得到一个既能精炼信息、又能把信息讲通俗的组合在给非技术背景的同事解释复杂技术时非常好用。从我个人的实操体会来说提示词工程真正难的不是背技巧而是建立先想清楚再动手写的习惯。每次写之前花两分钟想清楚受众是谁、要什么格式、有哪些硬性约束、需要用例子还是用步骤。这个习惯一旦养成输出质量的提升是很直观的。另外不同模型的差异确实存在同一个模板在不同模型上的表现可能差不少我的做法是在模板库里记录每个模板测试过的模型版本实测通过后再放心推广。希望这 10 个技巧和模板库能帮你少走一些我走过的弯路。