提示词工程实战：10个技巧与模板，让大模型输出更精准

聊一个我天天在用的东西：提示词工程。同样一个模型，有人一句话就能拿到能直接用的结果，有人来回磨了十几轮，拿到的还是一堆正确的废话。这个差距，99%出在提示词上，而不是模型本身。这篇文章我想把这两年自己在项目里反复验证过的10个提示词技巧，连同那些我随手存下来的模板一起整理出来。这些不是理论推演，全是实际用过、改过、排过雷的东西。不管你是刚接触提示词工程的新手，还是已经被各种"花式提问"绕晕的普通用户，只要你需要和大模型打交道，这篇文章就能让你少走不少弯路。

1. 提示词工程的核心认知与设计逻辑

1.1 提示词工程真正解决的问题是什么

很多人以为提示词工程就是"把问题问得详细一点"，这个理解太表面了。大模型本身是一个基于海量文本训练出来的概率模型，它给出的每一个词，都是在预测"在这个上下文里，下一个词最该出现什么"。也就是说，它不是在"理解"你的需求，它是在"猜"你的需求。你给的文字内容越清晰、边界越明确，它猜对的概率就越高。

所以提示词工程解决的核心问题，其实是三个：输出质量的稳定性、输出格式的可控性、以及一次对话的可用性。我自己的体感是，如果拿一份表意模糊的提示词去问模型，可能十次里只有两三次能碰运气出好结果；但一份结构完整的提示词，几乎每次都能得到70分以上的输出，剩下不够好的部分，再微调两句就行。

这里我拿做饭打比方。同一个锅、同样的食材，有人做出来就是家常味，有人做出来就是米其林摆盘。差别不在锅，而在对火候、顺序、调料的控制。提示词就是你对大模型的火候控制和放盐顺序。你放多放少、先放后放，直接决定成品。

1.2 好提示词的三层结构：角色、任务、约束

我自己写提示词有个习惯，不管你是什么场景，凡是高质量的输出，提示词里一定包含这三层信息：

第一层，角色。让模型以一个什么身份来思考和表达。比如"你是一名从业十年的数据分析师"和"你是一个刚入行的实习生"，同样的问题，输出的措辞、深度、结构完全不同。大模型在海量语料里见过无数种身份的表达方式，你给了身份，它就会自动对齐这个身份的语言体系。

第二层，任务。你希望它做什么，这一步要写得像给外包需求文档一样明确。明确不是"帮我分析一下数据"，而是"请你基于我提供的数据，找出转化率下降的主要原因，并按影响程度从高到低排列"。这个任务描述中，动作、对象、目标、输出顺序必须全部说清。

第三层，约束。限定它不能做什么、输出成什么样。比如字数限制、必须用Markdown表格、禁止使用专业术语的解释、不要分点直接给结论等。约束不只是限制，它更大的作用是帮模型缩小搜索空间，把可能跑偏的范围圈起来，让答案更集中。

这三层不是需要你每一次都写全，但当你发现输出不理想时，回看提示词八成是某一层缺失了。我排查提示词问题，第一件事就是检查这三个部件有没有少。

1.3 为什么同样一个模型，你能拿到的结果天差地别

有一个现象特别有意思：同一个模型，同一个问题，不同人问出来的结果完全不一样。这不是玄学，是提示词在起作用。你给模型的上下文越完整，它越能准确匹配到你想要的那个答案空间。相反，如果你的提示词只有问题，模型就只能靠猜测来补全所有缺失的信息，那结果自然千奇百怪。

我常跟朋友说，和大模型对话，你要把它想象成一位能力很强但没有读心术的新同事。你安排任务时讲得越具体，它的执行力越强；你只说一句"这个东西你看着办"，它就只能给你一个"平均水平的答案"。所以，那些"用得好的人"不是运气好，而是他们在心里自动把这一套上下文补全了。

2. 提示词工程实战：10个立刻能上手的技巧

2.1 角色设定法：给模型装一个专业大脑

这是我最先推荐掌握的技巧，简单、见效快，几乎所有场景都适用。用法就一句话：在对话开头给模型一个明确的角色定义，而不是让它无身份泛泛回答。

来看对比。你直接问："帮我写一封催客户付款的邮件"，模型可能给你一封礼貌但毫无力度的模板。但如果你说："你是一位经验丰富的销售总监，擅长用温和但坚定的语气催收账款，请帮我给一个拖延了30天、合作关系良好但资金周转出现困难的客户写一封催款邮件，目标是既不伤和气又能让对方给出明确的付款时间。"这封邮件的质量会完全不一样。

为什么有效？因为当角色定义越具体，模型调用的语料范围就越聚焦。它会自动模拟这个角色应有的语言风格、知识结构和表达习惯。我做项目管理时，会把角色设定写得很细，比如"你是一位有十年全栈开发经验、参与过大型系统重构的技术负责人"，而不是简单一句"你是程序员"。角色的背景越详细，输出的专业深度就越接近这个段位。

进阶用发是"角色+背景+目标"三段式。把当前所处的情境也交代给模型，比如客户是谁、双方什么关系、事件的前因后果，它就能在角色的基础上，围绕背景和目标组织语言，回答的贴合度会再上一个台阶。

2.2 示例引导法：给模型一个模仿的样板

大模型最擅长的事情之一就是模仿。你给它一两个优质样例，它会顺着你给的样例格式、词汇密度、句式结构往同样的方向输出。这个方法在业内叫Few-shot提示，也就是少样本学习。

实操中的做法是，在提示词里放1到3个"输入—输出"的示例。比如我要模型帮我提取简历里的关键字段，我不会写"请提取姓名、年龄、工作经验"，而是给他一个真实的示例：

输入：张三，男，2015年毕业于XX大学计算机专业，毕业后在A公司做了两年Java开发，负责订单系统的维护，随后跳槽到B公司担任技术主管。 输出： 姓名：张三 学历：本科 专业：计算机 工作年限：9年 最近职位：技术主管 核心技能：Java、系统维护、团队管理

给了这个示例后，模型在处理其他简历时，输出的字段和格式都会对齐示例。这里有个很重要的经验：示例的质量决定了输出的质量。你给的示例本身是粗糙的，那模型学到的就是粗糙的风格；你把示例打磨得精炼，它后续产出的内容也会精炼很多。我建议示例数量控制在2到3个，太多反而会让模型只机械模仿而忽略你真正想处理的新问题。

2.3 步骤拆解法：让模型一步一步思考

这个技巧在处理复杂问题时非常管用。大模型有个特点，你让它一步到位给出最终答案，它往往会在中途省略关键推理环节，直接跳到结论，结论的质量就不稳定。但如果你要求它把推理过程一步一步展开，它的准确率和逻辑完整性会明显提升。

最经典的用法是在提示词末尾加上一句"请一步一步思考，并把关键推理步骤列出来"。不要小看这一句，它本质上是在告诉模型：我需要完整的过程，而不是跳跃的结论。模型在按步骤输出时，每走一步都会重新校正一下当前的状态，等于给自己加了多道检查锁。

举个例子，我让模型帮我做一份季度复盘分析报告。我不说"帮我写个复盘"，而是说："请按以下步骤处理：第一步，把本季度的核心数据和目标进行对比；第二步，找出差距最大的三个指标，分析可能的原因；第三步，针对每个原因提出一条可执行的改进措施；第四步，用结论先行的结构输出最终报告。"这样把大任务切成四段，每段模型都有明确的着力点，输出的报告逻辑性和深度都会好很多。

这里要提醒一点：步骤不要碎片化，4到6步是体验最好的区间。步骤过多，模型容易在中间某一步开始跑偏，而且输出会变得冗长；步骤过少，又起不到拆解的作用。

2.4 格式约束法：输出前先画好格子

模型默认的输出风格是自然段落，但很多时候我们需要的是表格、列表、JSON或特定结构的文本。如果你不明确告诉它格式，它就会按自己的习惯随手写。解决的办法就是主动指定输出格式，把"格子"画好让它往里填。

我最常用的格式约束是这几类：

• 表格格式：适合对比分析、数据整理、排期规划。提示词里写明"用Markdown表格输出"，并指定列名。模型就会自动把信息分门别类填进格子。
• 列表格式：适合步骤说明、要点总结。写明"用有序列表，每项不超过20字"。
• 结构化代码格式：适合需要程序解析的场景，写明"输出为JSON格式，包含name、age、items三个字段"。
• 段落格式：适合文章、邮件等连贯性内容。写明"每段不超过5行，段落之间用空行分隔"。

在实际项目中，我经常把格式约束和模板一起使用，让模型在指定框架内填充内容。这样做最直接的好处是，多轮的输出之间格式高度一致，后处理成本大幅降低。你要是做过批量内容生成，就会明白这件事有多香。

2.5 反面约束法：明确告诉模型不做什么

大多数人在写提示词时只关注"要什么"，却忘了说"不要什么"。反面约束的价值在于它能够剔除那些看着没错、但不符合要求的输出。模型其实很像一个非常配合但有时过于灵活的助理，你不说不要什么，它就会按最常规的方式给你输出的东西。

举个例子，我写小红书文案的时候，禁止项是这样的："不要用'首先''其次''最后'这类过渡词，不要用'亲''宝子'等过度亲昵的称呼，不要出现'绝绝子''yyds'等网络流行语，不要写超过3行的开头铺垫。"这几个负面约束一加，文案的风格立刻从"AI味模板"变成了"真人分享"。

反面约束的写法有一些窍门。第一，要具体，不要写空泛的"请写得自然一点"，而是直接列出你不想要的措辞和表达方式。第二，数量要适度，3到5个负面约束比较合适，写太多模型容易混乱。第三，把重要约束放在后半部分，模型对提示词后半段内容的记忆会更清晰。

2.6 分步交互法：像带新人一样分阶段推进

很多人拿到一个复杂任务，恨不得一口气把整个需求都倒给模型，让它一把输出所有东西。结果模型消化不了那么多信息，输出又乱又浅。我现在的习惯是，把复杂任务拆成多轮对话，每一轮只处理一个阶段性目标，确认好前面一步的结果，再继续下一步。

举个我常做的案例。我让模型帮我策划一场线下活动的方案。我不会让它直接输出完整方案，而是分三步：第一次，只让它输出活动主题和核心创意，提供三个选项；我从中选一个；第二次，让它在选定主题的基础上列出活动流程框架；第三次，把流程细化成包含时间、环节、负责人、物料的执行清单。

这种做法的好处有很多层。最重要的一点是，每一轮的输出都能作为下一轮的输入，模型对需求的理解会更深入，不会出现"开头说了A需求、写到最后变成B风格"的情况。而且我可以在中途纠偏，不会等模型把所有内容都生成完才发现方向不对，那时候返工成本就高了。分步交互法唯一的代价是多花几轮对话，但换来的是结果可控，这笔账怎么算都划算。

2.7 关键词强化法：用指令词锁定重点

所谓关键词强化，就是在提示词中主动使用一些有"强约束力"的指令词，把模型的注意力引向特定内容。常用的指令词包括："重点强调""必须包含""禁止遗漏""优先考虑""忽略"。这些词本质上是在给模型划重点，让它知道哪些信息权重更高。

我在做产品需求文档的时候会这样用："请输出一份PRD，必须包含以下部分：用户场景、功能清单、优先级划分、验收标准。优先考虑上线成本最低的方案。忽略品牌声量因素，只关注功能落地效率。"这里"必须包含"定义了文档的骨架，"优先考虑"定下了主次，"忽略"排除掉干扰项。模型在组织输出时，就会围绕这几个关键词分配内容重心。

再分享一个细节：关键词不要淹没在长段文字中间，最好单独成行，或者用一句清晰的指令收尾。比如在提示词最后另起一行写"重点强调：这个方案的关键成功标准是转化率提升20%，所有建议都必须围绕这个目标展开。"模型对提示词末尾的内容留意度很高，这个位置放核心要求，效果立竿见影。

2.8 多轮迭代法：把提示词当成需要调试的代码

没有哪条提示词是第一次写就完美的。我在实际使用中反复提醒自己，提示词不应该是"我提问它回答"的静态过程，而是一个需要不断调试和迭代的动态过程。第一版输出不满意，就回到提示词里改，而不是无限追问同一个问题。

改的时候有个重要原则：一次只改一个变量。假如你同时改了角色设定、格式约束、背景补充，模型输出变化了，但你根本不知道是哪个改动在起作用。正确的做法是列出一份初始提示词，跑一遍；输出不满意，就只调整一处——比如把角色写得更细，再跑一遍；如果还没到预期，再换另一个变量，比如增加一个负面约束。每次只动一个点，才能建立"提示词改动—输出变化"之间的对应关系。

我自己的习惯是给常用提示词建一份迭代记录表，记录下每个版本的提示词、遇到的问题、输出质量等级。这样调着调着，就能找到针对某个场景最稳定有效的那版提示词。这个习惯前期看起来有点麻烦，但长期积累下来的模板库，就是你最宝贵的提示词资产，比任何网上抄来的模板都好用。

2.9 上下文打包法：一次把背景信息给齐

模型在回答你的问题之前，能掌握的信息完全来自对话上下文。你在提示词里给的背景信息越齐全，它就越能给出贴合你实际情况的方案。很多人抱怨AI给的答案"太通用""没有针对性"，80%的原因就是提示词里缺少足够的具体背景。

我总结了一套"上下文打包五要素"：目标是什么、当前状况是什么、目标受众是谁、有什么资源和限制、期望输出是什么。每次写重要提示词时，我都会在开头把五要素列一遍。比如我在做季度营销规划时，会这样写："我们是一个面向中小企业提供SaaS工具的产品团队，当前季度新增用户3000人、付费转化率2.5%，预算20万，目标是Q3结束前付费转化率提升到4%。请基于这些信息制定一份营销规划，包含渠道组合、预算分配、阶段目标。"

这段提示词里几乎没有废话，每一句都在给模型喂有效信息。模型拿到的背景越细，给出的方案就越贴合真实情况。五要素哪怕缺一个，输出的针对性都会打折扣，这个我在无数次实践中反复验证过。

2.10 指令权重法：用编号和顺序控制重点排序

最后一个技巧，我把它叫做"指令权重法"。它利用的是模型对提示词中内容顺序和编号的敏感度。放在靠前位置的内容，模型会理解为高优先级；单独成行、用编号列出来的要求，模型会认为每一条都必须遵守。

这个方法特别适合处理"多重要求并存"的场景。比如我自己写会议纪要总结的提示词是这样的：

请按以下要求整理会议纪要： 1. 输出格式：使用Markdown，包含"结论""决议""待办事项"三个部分。 2. 优先级：待办事项部分必须明确负责人和截止日期。 3. 风格：每条决议不超过40字。 4. 终极目标：让没参会的人读完纪要也能完全掌握会议全部关键信息。

四个编号，从格式到细节再到核心目标，模型会把每一行都当成独立的子任务去完成，而不是混在一起变成一团。特别是最后一条"终极目标"，它起到了托底的作用，即使前面几条模型执行得有点偏差，最后它也会围绕"没参会的人也能看懂"这个方向去做整体调整。

3. 提示词模板库：拿来即用的场景配方

3.1 通用写作模板

这个模板适合公众号文章、博客、工作汇报等一切需要成稿的写作场景。核心逻辑是"先定风格，再给素材，最后约束结构"。

角色：你是一位擅长把复杂内容写得通俗易懂的内容创作者。 任务：请基于我提供的素材，写一篇面向[目标读者]的文章。 素材：[粘贴你的素材内容] 要求： 1. 标题要包含核心卖点，控制在20字以内，至少给3个备选。 2. 开头3句话内勾住读者兴趣，不使用"随着""近年来"这类套话。 3. 正文用小标题分成至少4个部分，每部分逻辑独立。 4. 语言自然，避免形容词堆砌，不用"赋能""抓手"等空词。 5. 结尾给出一个明确的行动建议。

这个模板我每次用都会针对不同平台微调约束条。比如发小红书时，我会加一条"每段不超过3行，多用换行"；写工作汇报时，我会把第3条改成"先结论后论据，每部分不超过300字"。

3.2 编程辅助模板

写代码、debug、技术方案设计，这三个场景我都沉淀了对应的提示词模板。最常用的是代码生成这一版：

角色：你是一位有多年[语言]开发经验的资深工程师，熟悉工程化最佳实践，重视代码可读性和稳定性。 任务：请实现[功能描述]。 附加信息： - 运行环境：[操作系统、语言版本、相关框架版本] - 输入数据格式：[字段说明/示例] - 期望输出格式：[返回值结构/接口定义] 代码要求： 1. 先说明实现思路，再贴代码。 2. 关键逻辑必须写清楚注释。 3. 错误处理要完整，不能只顾正常路径。 4. 不允许使用已废弃的API。 5. 代码命名遵循[命名规范]。

我把这个模板里的角色设定得越接近当前项目背景，代码质量越高。比如加上"熟练使用Python3.10+和FastAPI"这一句，模型在选型时就会直接按这个技术栈来写，而不是给你一堆需要二次修改的通用代码。技术方案设计类任务同理，只需要把"任务"从"实现"改成"输出技术方案文档"，再把"附加信息"换成"现有系统架构、性能瓶颈、期望达到的效果"，一套模板可以复用出很多变体。

3.3 数据分析与决策模板

平时做数据分析，需要模型帮忙解读数据的时候，我习惯用下面这个结构。它的核心是把"怎么看数据"前面的业务背景全给足，让模型先理解了业务的来龙去脉，再来分析数据，否则数字只能变成空洞的罗列。

角色：你是一位业务数据分析师，熟悉[行业]常见的业务指标体系和归因分析方法。 任务：请对以下数据进行深度解读，并给出可落地的业务动作建议。 数据背景：[说明数据来自哪个业务环节，统计口径如何] 当前数据： [粘贴数据或表格] 分析要求： 1. 先总结关键发现，按重要程度排序。 2. 对异常指标做根因分析，区分外部因素和内部因素。 3. 给出至少3条可执行的增长建议，每条建议必须说明预期影响和所需资源。 4. 涉及同比环比时，必须标明基数，不许只写增减幅度。 5. 用"数据表现—原因分析—行动建议"三段式组织输出。

用这个模板时，最要紧的是把"数据背景"写准确。比如这组数据是日活还是周活、统计口径是去重还是按设备计算，这些不写清楚，模型可能默认按它理解的逻辑来分析，最后结论满天飞，落不了地。

3.4 总结提炼模板

总结类任务，比如读文章提炼要点、长材料整理摘要、会议纪要归纳，我用下面这个模板。它的特点是强制了输出结构，让总结出来的内容可以直接复用。

角色：你是一位高效的文字秘书，善于提炼长文的核心信息，过滤冗余细节。 任务：请总结以下内容的核心要点。 原文： [粘贴原文内容] 总结要求： 1. 输出格式：核心结论 / 关键论据 / 数据事实 / 行动项。 2. 核心结论不超过50字，必须直接回答问题。 3. 关键论据不超过5条，每条30字以内。 4. 出现数字和日期时必须保留。 5. 如果原文中有相互矛盾的信息，单独列出并说明。

这个模板最适合两类用途：一是给团队共享的大材料做快速摘要，二是给自己留档的参考资料库做定期精简。覆盖不同业务的资料整理需求，只要把"原文"这一段换成不同的内容，输出的结构始终统一，后续检索非常方便。

3.5 头脑风暴创意模板

做方案策划、选题规划时，我最怕模型给出一堆平庸的常见答案。后来我总结出一套能逼着模型跳出常规的模板，核心技巧是注入限制条件，减少常见路径。

角色：你是一位极具创意的策划人，擅长在严苛条件下提出出人意料但又可落地的方案。 任务：围绕[主题]进行头脑风暴，输出10个创意方案。 硬性限制： 1. 禁止使用[已用烂的套路，比如性价比、官方补贴等] 2. 方案涉及执行成本必须分成高/中/低三档说明 3. 每个方案必须包含一句话的核心创意点、目标人群、预期效果 4. 至少有3个方案是不依赖预算投入、纯粹靠创意驱动的 思维路径要求：先分别从"产品角度""用户角度""传播角度"思考，再交叉融合。

实践下来，这个模板能把模型从"标准答案模式"里拽出来一些。尤其是"硬性限制"那一栏，你框得越死，它越会被逼到意想不到的角度去找方案。头脑风暴的关键不是立刻拿到完美答案，而是用提示词制造更多可能性，再从中挑苗子。

3.6 翻译润色模板

模型做翻译和润色其实远强于多数在线翻译，但它默认输出的译文往往很"平"。要让译文有味道，给它的风格指令很重要。

角色：你是一位精通中文和[目标语言]、对两种语言文化背景都有深入理解的资深译者。 任务：翻译以下文本。 原文：[待翻译内容] 翻译要求： 1. 先给出直译版本，再给一个意译版本。 2. 直译版严格忠于原文语义；意译版要符合目标语言的表达习惯，可以调整语序和句式。 3. 如果原文中有专有名词或文化隐喻，用括号注释说明。 4. 对翻译的难点用一句话解释你的处理原因。 5. 最终给出一个在商业场景下可直接使用的推荐版本。

这个模板用下来有个明显的好处：你不会只拿到一份译文，还能看到译者的思考过程。对于需要反复打磨品牌文案、产品介绍的人来说，这个"直译+意译+推荐"的结构，比普通翻译好用太多。

4. 常见问题排查与实战避坑

4.1 输出太泛泛，感觉像"正确的废话"

这个问题在提示词工程里最常见，原因几乎都是"信息给得太少，约束给得太松"。模型不知道你的真实场景，只能给你一套最通用的逻辑框架。每次遇到这类问题，我会系统性地检查三处：身份清不清晰、背景全不全、约束够不够。

身份不清就补角色设定，比如"资深产品经理"永远比"产品经理"好用。背景不全就按我前面讲的"上下文打包五要素"挨个补。约束不够就加负面约束，明确告诉模型不要写什么。这三步补完，泛泛而谈的概率会大幅下降。

4.2 格式输出不稳定，同样的提示词格式总变

这可能是最让人郁闷的问题。明明上一条提示词模型给出了漂亮的表格，第二天再来一次，它却用段落输出。原因在于，模型给出的输出有随机性，格式类要求如果没有在提示词里反复强调，就可能被它忽略。

我在格式稳定性上总结了两个技巧。第一，格式要求重复两遍，在提示词开头说一遍"输出用Markdown表格"，在末尾再强调一遍"严格按照题目指定的Markdown表格输出"。第二，在输出格式前加上"必须"或"严格"这类强约束词。做了这两步之后，格式稳定性有了明显提升。如果还是不稳定，就把示例格式直接贴进提示词，让模型照葫芦画瓢。

4.3 模型一本正经地编造事实

幻觉问题目前任何模型都避免不了，提示词的改进能降低概率，但不能彻底根除。在事实性要求高的场景中，我会在提示词里加一条："当你不确定具体数据、历史事件或引用时，明确回答'我不确定'，不要推测。"这一条很关键，它给了模型一个"诚实"的出口，否则模型为了满足用户的提问，会倾向于生成看起来合理的内容。

涉及到具体数字、权威来源的信息，我会提示"对于无法确认的内容标注为待核实，并说明哪些部分需要人工查证"。这样输出的内容即使有误差，也能在流程中快速被发现，而不是被当成事实直接采纳。把这个风险意识写进提示词工程的习惯里，能少踩很多坑。

4.4 一句话提示词能解决的事，别写得又长又复杂

和"提示词太简单导致输出泛泛"相比，另一个极端是提示词冗长、嵌套，把模型绕晕。我自己早期就犯过这个错，一口气写了20行要求，结果模型抓不住重点，输出反而比简单提示时更难用。

现在我的原则是：先搭骨架再补肉。第一版提示词先只写"角色+任务+核心输出要求"三行，跑一轮看基础方向对不对。方向对了，再根据不足的地方逐条增加细节和约束。这里我只会针对模型说明书式地逐层加码，避免一次投喂过多无关信息。提示词不是越长越好，而是"相关信息密度"越高越好。

4.5 常用问题排查速查表

我自己在实际项目里遇到问题，第一步就是拿这个速查表对照，很少落空。很多问题表面上看起来是模型不行，实际上都是提示词里的某一个环节没照顾到。

结尾

最后再分享一点我做提示词工程的个人心得：别把提示词工程当成一个可以速成的秘技，也别指望找到一条万能提示词然后一劳永逸。模型在更新，你的任务场景在变化，提示词也需要跟着迭代优化。我现在每次在项目中使用新提示词时，都会顺手把它保存到一个统一的本子里，并标注好使用场景、适用模型、踩过哪些坑。时间长了，这个本子就成了我个人最值钱的提示词模板库，很多新项目甚至都不用从零开始想提示词，直接在这个库里改改就能用。希望这10个技巧和模板，能帮你在自己的使用场景里省下一点时间和头发，这才是写这篇内容最想达到的目的。