最近大半年我一直在帮团队搭大模型相关的应用流程前后也带过十几个刚开始接触提示词工程的同事。观察了这么多案例之后我发现一个特别反直觉的现象能不能用好大模型跟会不会写代码、懂不懂算法关系不大真正拉开差距的是对提示词工程的理解深度。同一个任务有人写三行提示词模型一次就给出能直接用的结果有人写了五百字“小作文”模型照样绕圈子。差别不在运气而在方法。这篇文章就是把我这些年踩过坑、反复验证过、现在还在用的 10 个提示词技巧整理成清单每个技巧都配了可以直接复制使用的模板。无论你是刚入门的新手还是已经在做 Agent 应用的开发者里面这些方法拿过去就能用不需要额外学习任何框架或工具只需要一个能聊天的对话框。1. 先搞明白模型是怎么“读”提示词的很多提示词写不好根源不是技巧不够而是对模型的理解出了问题。所以在讲具体技巧之前先花点篇幅说清楚两件底层的事模型的读取方式以及上下文位置对结果的影响。1.1 概率预测器思维模型不是在“理解”而是在“续写”大语言模型的本质是一个根据前文预测下一个 token 的概率系统。你在对话框里输入提示词模型做的不是“读懂你的意图然后执行”而是计算所有可能的下一个词的概率分布选出最顺理成章的那一个再继续滚动生成。这意味着你提示词里的每一个词、每一个标点、每一处换行都在悄悄影响这个概率分布。想通这一点很多困惑就能解释。为什么同样一个任务换个说法结果就天差地别因为不同的用词会把模型引导到不同的“语义簇”。举个例子你写“帮我看看这段代码有什么问题”模型会进入代码审查模式你写“这段代码为什么跑不通”模型会进入故障排查模式。虽然意思相近但模型生成后续文本时倾向的方向完全不同。我在实战中最大的心得就是不要默认模型“应该明白我的意思”而要默认模型“只能沿着我写的字面意思走”。凡是重要的意图必须写清楚。1.2 上下文位置效应开头定基调结尾定输出Transformer 架构里的自注意力机制让模型在生成每个 token 时理论上可以“看到”输入序列里的所有位置。但理论和实践是两回事。大量实测下来会发现一段很长的提示词里开头位置的信息往往决定了模型“以什么身份、什么角度”去处理任务结尾位置的信息则最容易被模型当成“当前最需要响应的指令”而中间位置的信息容易被分散注意力甚至忽略。这就像给同事发需求消息。你通常会在开头说“我需要你做什么”中间补充背景资料结尾强调“什么时候交、用什么格式”。如果顺序乱了或者中间塞了太多无关紧要的东西对方很容易抓错重点。给模型写提示词也一样。我建议所有提示词都按这个结构组织开头一句话说明任务目标、场景、你要扮演的立场中间参考资料、示例、背景信息等辅助内容结尾输出格式、约束条件、需要执行的具体步骤这个结构几乎适配所有场景。下面要讲的 10 个技巧本质上都是在不同维度上优化这个“开头-中间-结尾”的信息布局。2. 两个基础技巧角色设定与分步指令先讲两个最基础、也最好上手的技巧角色锚定和分步拆解。这两个技巧单独用都有效组合起来效果更稳。2.1 技巧一角色锚定法一句话把模型“拉进”专业语境角色锚定是目前传播最广、也最容易被误用的技巧。它的核心作用是把模型生成内容时所在的“上下文空间”压缩到特定领域。模型训练数据里包含了大量不同领域的语料不设定角色时它等于在所有这些语料上取平均设定角色后模型会更容易激活与该角色相关的知识分布。我实测下来角色锚定在内容创作、代码审查、文案改写、专业咨询这几类场景效果最明显模板也很简单你是一位有10年经验的[领域]专家擅长[核心能力]。 请帮我[具体任务]。 要求[具体要求]举个例子同样是润色一段产品介绍不设定角色模型可能给你一版“好看但通用”的文案设定为“面向早期用户的科技产品文案专家”模型会主动补上用户场景、价值主张、行动号召这些结构区别很明显。但角色设定不是越多越好也不是随便什么角色都行。我自己踩过一个大坑让“资深律师”角色去写轻松活泼的社媒文案结果输出了一股“法律意见书”味怎么改都改不回来。这个问题的根源和解决办法我放在文末的踩坑记录里细说。2.2 技巧二分步拆解法把复杂任务切成模型能消化的步骤很多复杂任务一次性让模型完成错误率会成倍上升。原因不难理解任务的每一步都有各自的概率优化空间步骤越多路径越复杂模型就越容易在中途“跑偏”。分步拆解的核心就是把一个大任务人为切成几个小步骤让模型一步步走每一步的输出都被约束在上一步的结果之上。最简单的用法是这样请按以下步骤完成[任务] 第1步[子任务1] 第2步[子任务2] 第3步[子任务3] 每一步完成后先输出该步骤的结果然后再进行下一步。最终把所有结果整合成[输出格式]。这一步看起来很简单但在多次实跑中效果极其稳定。我见过一个团队用这个方法处理“从会议记录里生成项目计划”的任务——不拆步骤时模型经常遗漏风险项按“先提炼决策、再识别任务、最后排优先级”三步走之后输出质量立刻提升了一个档次。还可以在分步之后加一句校准指令“在正式开始之前先用一句话复述你对任务的理解。”这句话能逼模型先对齐任务目标如果理解错了你在第一步就能发现不用等它跑完全程。2.3 为什么这两个技巧组合使用效果最好角色锚定解决的是“模型站在什么立场回答”的问题分步拆解解决的是“模型按什么路径回答”的问题。两者组合使用时模型从一开始就被约束在正确的专业语境里同时沿着明确的推进轨迹操作相当于同时锁定了方向和路线。我常用的组合模板长这样你是一位资深的[领域]专家。 请帮我完成[任务]。 按以下步骤执行 第1步[子任务1] 第2步[子任务2] 最后按[输出格式]输出结果。在实践里这套组合几乎可以套用到所有“比较复杂但步骤可以被拆开”的任务上比如写方案、分析数据、设计实验、规划学习路径等等。它的核心价值是降低了模型输出的不确定性而不确定性正是很多提示词“时灵时不灵”的背后原因。3. 让输出格式可控的三个技巧很多人在提示词工程里最头疼的问题就是模型听懂了我的话但输出的格式完全不是我要的。这一章讲三个能让输出格式变可控的技巧。3.1 技巧三格式限定法用结构把输出“焊死”如果你只是说“请用表格输出”模型不一定知道你要几列几行、表头是什么、内容偏向哪个维度。格式限定法的核心是由你定义完整的输出结构让模型往里填内容。结构本身就是最高效的约束。例如做竞品分析我经常用这个模板请分析以下 3 款产品的差异[产品A]、[产品B]、[产品C] 输出格式 ## 竞品概览用表格产品名称 | 核心定位 | 目标用户 | 价格区间 ## 优势对比分点列出每款产品的核心优势 ## 劣势与风险分点列出每款产品的明显短板 ## 差异化机会给出结论性建议注意这里的技巧我不仅限定了“要分为哪几节”还在括号里限定了每一节里的具体字段。这样模型在生成内容时没有任何自由发挥的结构空间只能按照预设维度去组织信息。这个方法在生成数据分析报告、学习计划、复盘文档等场景里都非常好用。3.2 技巧四示例驱动法一个好例子顶过十句描述如果你试过用大段文字描述想要的输出风格、措辞倾向、信息密度但模型就是不听话那大概率是因为“描述”本身就是有歧义的。模型需要把文字描述转译成生成策略这个转译过程会损失大量信息。而示例不同——示例直接给出了从输入到输出的完整映射模型只需要模仿这个映射不需要做额外的语义转译。Few-Shot 提示的标准用法是给 2 到 4 组完整的输入输出对请将以下句子改写成更专业、更有说服力的表达。 示例1 输入这个产品很好用。 输出本产品在可用性方面表现优异操作路径清晰用户学习成本低。 示例2 输入价格有点贵。 输出当前定价处于行业中高水平但结合功能完整性来看具备一定的性价比优势。 现在请改写 输入这个软件更新之后快了很多。 输出我实测下来2 到 4 个示例效果最好。少于 2 个模型学不到稳定规律多于 4 个示例本身的特殊细节可能会干扰模型“过拟合”到示例里。另外示例之间要尽量覆盖不同情况最好能体现你期望的“变化范围”而不是给几个几乎一样的例子。3.3 技巧五负面约束法明确“不要做什么”比想象中更管用大模型在“不要做什么”上的遵循能力通常弱于“要做什么”。但这不代表负面约束完全没用。实际经验是把负面约束当成“事后纠正”专门用来清理模型的高频毛病比如啰嗦、编造、过度承诺。请注意以下约束 1. 不要使用“总之”“综上所述”等总结性套话 2. 不要编造数据或事实如果信息不足请明确说“信息不足” 3. 不要给用户任何形式的承诺只陈述事实信息。但有两个细节需要特别提醒。第一条负面约束一次不要超过三条写多了模型反而抓不住重点一条都执行不好。第二条不要只给负面约束最好框架是“正面要求为主负面约束收尾”就像路标一样先指路再禁行。如果一整段全是“不要不要不要”模型的生成过程会变得很别扭输出结果容易生硬。4. 管理上下文与推理深度从“能答”到“答得对”前三章讲的基本是“让模型听指挥”。这一章要解决更深一层的问题当任务本身比较复杂、信息量很大时怎么让模型答得对、答得准。4.1 技巧六上下文预算管理关键信息该放哪里、怎么放大模型有上下文窗口能接收的 token 数量有限。但“塞得下”不等于“效果一样好”。上下文越长模型对中间部分的注意力越容易分散关键指令被“淹没”的风险越大。我的做法是给提示词建立清晰的分区用分隔符隔离不同信息块【任务背景】 用2-3句话说明当前场景和目标 【参考资料】 放需要模型参考和处理的所有资料内容可长可短 【任务要求】 放具体的执行指令比如分析什么、回答什么 【输出格式】 放期望的输出结构比如分点、表格、JSON等 请基于以上信息开始执行任务。这个结构之所以有效是因为它为模型建立了一个“信息类型”的认知框架——模型能区分哪些是背景、哪些是素材、哪些是需要严格遵循的指令。如果没有分区模型很可能把参考资料里的内容当成指令执行或者把指令当成背景忽略掉。我见过最典型的反面案例有人把任务要求写在了一大段资料的中间模型直接无视了在那里逐字复述资料内容。4.2 技巧七思维链提示强制模型先推理再给结论对于数学、逻辑、规划、代码排查这类推理型任务直接要求模型给答案错误率会明显偏高。原因在于跳步生成时模型需要在一开始就精确“猜到”结果这对概率预测来说太难了。但如果让模型先逐步推理再给结论每一步只需要在当前已经生成的推理基础上往前推进一小步错误率就能大幅下降。基本模板请逐步分析下面的问题每一步都说明你的推理依据最后再给出结论。 问题[问题]进阶版是在示例里直接展示推理过程也就是“思维链 Few-Shot”效果更强示例 问题一个商店促销原价200元的商品打8折再减20元最终价格是多少 推理原价200元打8折后是160元再减20元最终是140元。 结论140元。需要注意思维链不是“写得越长越好”。如果不加限制模型会生成大量自我感动式的废话。我会在提示词里加一句“只输出必要的推理步骤删除与结论无关的说明”。4.3 技巧八自校正循环让模型自己给自己挑错技巧八的思路是把“一次生成”升级为“生成审查”两个阶段。模型第一次生成的答案可能包含错误这个错误在自我纠错阶段有一定概率被识别出来尤其是格式性错误、遗漏要点这类“显性问题”。我的模板请重新检查你上面的回答重点检查以下内容 1. 是否完整回答了用户提出的原始问题 2. 是否存在事实性错误、猜测或编造 3. 是否满足输出格式要求 如果发现问题请直接输出修正后的完整版本如果没有问题请回复“无需修改”。实测下来自校正循环对“遗漏要点”和“格式不符”两类问题的改善比较明显对深层次的事实性错误改善有限因为模型纠错的依据仍然是它自己的知识库如果它本身不知道某个事实检查的时候也发现不了。所以自校正循环适合作为质量兜底不能完全替代人工审查。5. 迭代交互技巧别指望一次问出完美答案前八个技巧都是“单轮提示词”层面的优化。但真正的实战里很多复杂任务不可能靠一轮对话就解决。这一章讲两个需要在多轮对话中使用的技巧。5.1 技巧九澄清追问法把模糊需求一步步问清楚很多提示词失败不是模型不行而是任务目标本身就没定义清楚。与其在一条提示词里塞进所有可能的情况不如先让模型帮你澄清需求。注意是“帮你澄清”不是让你自己想清楚再写实际操作中后者的成本太高了。模板在回答我的问题之前请先向我确认以下 2-3 个问题 1. [关键决策点1] 2. [关键决策点2] 3. [关键决策点3] 基于我的回复再给出完整答案。我经常用这个方法处理“帮我写一份XX方案”之类的开放式任务。模型会问目标用户是谁、核心资源有哪些、预算边界是什么……几轮下来你会发现真正要的东西往往和最初想的不一样。比如一个同事让我帮他想“用户增长方案”追问几轮后才发现他要的只是一个活动页面的文案结构根本不需要一整套增长体系。澄清追问节省了双方的时间也避免了“答非所问”的无限循环。5.2 技巧十元指令法让模型帮你设计提示词最后一个技巧建议所有人掌握当你面对一个不熟悉的领域、不确定该写什么约束条件时直接让模型帮你写提示词。模型训练语料里包含了大量提示词工程相关的内容这就意味着它本身“知道”很多提示词模板。模板你是一位提示词工程专家。请帮我设计一个提示词用于完成以下任务 [任务描述] 设计要求 1. 包含角色设定、具体步骤、输出格式 2. 明确关键约束条件 3. 使用清晰、无歧义的语言。 请直接输出设计好的提示词并附上一段简要说明解释你的设计思路。这个方法最大的价值是降低起步成本。你不需要在完全陌生的领域里靠猜去写约束模型给你的版本虽然不一定完美但作为第一版起点足够了接下来可以配合前面的澄清追问、自校正循环逐步迭代。我在写一些跨领域的分析任务时经常先用元指令生成初版然后按自己的需求改两三个地方整个过程不超过两分钟。6. 附赠模板库10 个场景直接抄作业把前面 10 个技巧浓缩成可以直接复制使用的模板按场景分四组罗列。这里每个模板都经过我反复使用和修改稳定性和通用性都经过了实际任务验证你可以直接复制到对话里试试。6.1 通用写作与表达类角色你是一位有10年经验的[领域]内容专家。 任务请把下面这段文字改写成[目标风格]比如更专业/更通俗/更有说服力。 原文[粘贴原文] 要求 1. 保留原文的核心事实和关键信息 2. 输出结构先给改写后的完整文本再分点说明你做了哪些调整 3. 不要添加原文里不存在的数据或案例。任务请基于以下要点扩展成一篇完整的[类型]文章。 要点 - [要点1] - [要点2] - [要点3] 输出结构 一级观点开头段 三级支撑每个要点展开2-3句 结尾建议给出一个可执行的行动建议 篇幅全文约[字数]字语言[要求语气]。6.2 数据处理与分析类角色你是一位资深数据分析师。 任务分析以下数据找出关键趋势和异常点。 数据[粘贴数据或表格] 步骤 第1步初步描述数据整体情况字段、范围、明显特征。 第2步识别关键趋势并用数据支撑你的判断。 第3步指出异常数据点并推测可能原因。 输出格式用表格列出趋势项和异常项最后给出一段结论性总结。 请按步骤执行每出一步先输出这一步的结果。任务请把这段原始记录整理成结构化清单。 原始记录[粘贴内容] 输出格式Markdown表格 | 序号 | 事项 | 负责人 | 优先级 | 状态 | 备注 | 最后单独输出一个“待确认项”列表列出记录中存在歧义或信息缺失的地方。 约束不要修改原始记录里的事实信息只做整理和归纳。6.3 编程辅助类角色你是一位有10年经验的[语言]工程师擅长代码审查和性能优化。 任务审查下面这段代码找出潜在的 Bug、性能问题和安全隐患。 代码 [粘贴代码] 输出格式 ## 问题列表按严重程度排序 1. [严重程度] 问题描述、位置、原因 ## 修复建议 给出修改后的关键代码片段 ## 补充测试建议 给出需要补充的边界测试用例 约束只分析已给出的代码不要假设不存在的结构。任务帮我写一个[功能描述]的[语言]函数。 输入输出示例 输入[示例输入] 期望输出[示例输出] 输入[示例输入2] 期望输出[示例输出2] 要求 1. 函数签名明确包含类型标注 2. 处理边界条件空值、极值、异常输入 3. 输出代码后附一段简短说明解释核心逻辑和复杂度。6.4 头脑风暴与知识问答类角色你是一位熟悉[领域]的创意策划专家。 任务针对以下主题进行头脑风暴。 主题[主题] 要求 1. 先给出 5 个完全不同的切入角度 2. 从每个角度延伸出 2 个具体可执行的方案 3. 最后为每个方案标注所需资源和潜在风险。 约束优先考虑低成本、可快速验证的方案。请基于以下参考资料回答我的问题。 【参考资料】 [粘贴资料] 【问题】 [具体问题] 要求 1. 优先引用参考资料里的信息在答案后标注对应来源段落 2. 如果参考资料中没有相关信息请明确说“资料中未提及”不要自行补充 3. 回答控制在[字数]字以内结论前置。7. 实战踩坑记录模板失效的三种典型情况技巧和模板都给了但直接复制粘贴未必能跑通所有场景。下面这三个坑是我在实战中反复踩过、也帮团队排查过很多次的专门写出来帮你避雷。7.1 角色设定与真实任务冲突小心“角色反噬”前面提到我让“资深律师”写轻松文案翻车的案例。这个现象的背后逻辑是角色设定一旦过强模型会把“角色身份”置于“实际任务”之上导致它用角色习惯的表达方式去执行所有任务。你让它写活泼文案它依然在使用法律文书的用词和行文节奏。解决办法有两个方向。一个是弱化身份标签、强化能力标签——把“你是一位资深律师”改成“你擅长法律领域的分析和表达”另一个是在角色设定后明确补充任务的语气风格比如“虽然你擅长法律分析但本次任务需要轻松、口语化的表达请完全切换为这种风格”。第二个办法我测试过很多次比单纯弱化角色更稳定。7.2 “请用简洁的语言”这类模糊指令基本等于没说这是我见新人用得最多、也最无效的指令。原因很简单模型没有“简洁”的量化标准。你觉得 500 字才算简洁模型觉得 2000 字已经压缩过了。没有具体数字和结构约束模型只能按照训练数据里的“平均值”来生成结果自然不是你想要的。正确做法是把“简洁”翻译成可量化的约束。比如“回答控制在 100 字以内”“只保留结论和关键数据删除所有修饰语”“分 3 点每点不超过 20 字”。同样的道理适用于所有抽象形容词——具体、友好、有深度、专业都要翻译成模型能执行的具体指令否则执行效果全看运气。7.3 提示词也需要版本管理别把工程资产随手丢提示词写出来之后不是一劳永逸的。同一个提示词换了模型、换了参数、甚至换了输入数据的长度效果都可能变化。很多团队只保存最终版提示词一旦效果变差完全没有回溯依据只能从头再试。我现在把所有对外发布的提示词都纳入版本管理格式很简单用表格记录就够版本日期模型修改内容效果评估v12024-01-10某模型初始版本输出冗长结构不清晰v22024-01-12某模型增加格式限定结构清晰但遗漏关键数据v32024-01-15某模型增加2个Few-Shot示例稳定达标这个习惯看起来不起眼但在项目长期迭代、模型升级、团队成员协作时能省下大量重复试错的时间。提示词工程做到最后其实拼的是工程化习惯不是灵光一现的写法。最后再说点我自己的体会。用了这么久的提示词最大的变化不是掌握了多少模板而是建立了一种“从模型的视角看问题”的习惯。每次写提示词之前我都会先问自己如果我是模型光看这段文字我知不知道用户到底想要什么、按什么结构输出、边界在哪里带着这个问题去写很多低级错误从一开始就能避开。技巧会更新模型会升级但这个视角不会过时。你也试试。
10个提示词工程实战技巧：让大模型输出更精准可控
最近大半年我一直在帮团队搭大模型相关的应用流程前后也带过十几个刚开始接触提示词工程的同事。观察了这么多案例之后我发现一个特别反直觉的现象能不能用好大模型跟会不会写代码、懂不懂算法关系不大真正拉开差距的是对提示词工程的理解深度。同一个任务有人写三行提示词模型一次就给出能直接用的结果有人写了五百字“小作文”模型照样绕圈子。差别不在运气而在方法。这篇文章就是把我这些年踩过坑、反复验证过、现在还在用的 10 个提示词技巧整理成清单每个技巧都配了可以直接复制使用的模板。无论你是刚入门的新手还是已经在做 Agent 应用的开发者里面这些方法拿过去就能用不需要额外学习任何框架或工具只需要一个能聊天的对话框。1. 先搞明白模型是怎么“读”提示词的很多提示词写不好根源不是技巧不够而是对模型的理解出了问题。所以在讲具体技巧之前先花点篇幅说清楚两件底层的事模型的读取方式以及上下文位置对结果的影响。1.1 概率预测器思维模型不是在“理解”而是在“续写”大语言模型的本质是一个根据前文预测下一个 token 的概率系统。你在对话框里输入提示词模型做的不是“读懂你的意图然后执行”而是计算所有可能的下一个词的概率分布选出最顺理成章的那一个再继续滚动生成。这意味着你提示词里的每一个词、每一个标点、每一处换行都在悄悄影响这个概率分布。想通这一点很多困惑就能解释。为什么同样一个任务换个说法结果就天差地别因为不同的用词会把模型引导到不同的“语义簇”。举个例子你写“帮我看看这段代码有什么问题”模型会进入代码审查模式你写“这段代码为什么跑不通”模型会进入故障排查模式。虽然意思相近但模型生成后续文本时倾向的方向完全不同。我在实战中最大的心得就是不要默认模型“应该明白我的意思”而要默认模型“只能沿着我写的字面意思走”。凡是重要的意图必须写清楚。1.2 上下文位置效应开头定基调结尾定输出Transformer 架构里的自注意力机制让模型在生成每个 token 时理论上可以“看到”输入序列里的所有位置。但理论和实践是两回事。大量实测下来会发现一段很长的提示词里开头位置的信息往往决定了模型“以什么身份、什么角度”去处理任务结尾位置的信息则最容易被模型当成“当前最需要响应的指令”而中间位置的信息容易被分散注意力甚至忽略。这就像给同事发需求消息。你通常会在开头说“我需要你做什么”中间补充背景资料结尾强调“什么时候交、用什么格式”。如果顺序乱了或者中间塞了太多无关紧要的东西对方很容易抓错重点。给模型写提示词也一样。我建议所有提示词都按这个结构组织开头一句话说明任务目标、场景、你要扮演的立场中间参考资料、示例、背景信息等辅助内容结尾输出格式、约束条件、需要执行的具体步骤这个结构几乎适配所有场景。下面要讲的 10 个技巧本质上都是在不同维度上优化这个“开头-中间-结尾”的信息布局。2. 两个基础技巧角色设定与分步指令先讲两个最基础、也最好上手的技巧角色锚定和分步拆解。这两个技巧单独用都有效组合起来效果更稳。2.1 技巧一角色锚定法一句话把模型“拉进”专业语境角色锚定是目前传播最广、也最容易被误用的技巧。它的核心作用是把模型生成内容时所在的“上下文空间”压缩到特定领域。模型训练数据里包含了大量不同领域的语料不设定角色时它等于在所有这些语料上取平均设定角色后模型会更容易激活与该角色相关的知识分布。我实测下来角色锚定在内容创作、代码审查、文案改写、专业咨询这几类场景效果最明显模板也很简单你是一位有10年经验的[领域]专家擅长[核心能力]。 请帮我[具体任务]。 要求[具体要求]举个例子同样是润色一段产品介绍不设定角色模型可能给你一版“好看但通用”的文案设定为“面向早期用户的科技产品文案专家”模型会主动补上用户场景、价值主张、行动号召这些结构区别很明显。但角色设定不是越多越好也不是随便什么角色都行。我自己踩过一个大坑让“资深律师”角色去写轻松活泼的社媒文案结果输出了一股“法律意见书”味怎么改都改不回来。这个问题的根源和解决办法我放在文末的踩坑记录里细说。2.2 技巧二分步拆解法把复杂任务切成模型能消化的步骤很多复杂任务一次性让模型完成错误率会成倍上升。原因不难理解任务的每一步都有各自的概率优化空间步骤越多路径越复杂模型就越容易在中途“跑偏”。分步拆解的核心就是把一个大任务人为切成几个小步骤让模型一步步走每一步的输出都被约束在上一步的结果之上。最简单的用法是这样请按以下步骤完成[任务] 第1步[子任务1] 第2步[子任务2] 第3步[子任务3] 每一步完成后先输出该步骤的结果然后再进行下一步。最终把所有结果整合成[输出格式]。这一步看起来很简单但在多次实跑中效果极其稳定。我见过一个团队用这个方法处理“从会议记录里生成项目计划”的任务——不拆步骤时模型经常遗漏风险项按“先提炼决策、再识别任务、最后排优先级”三步走之后输出质量立刻提升了一个档次。还可以在分步之后加一句校准指令“在正式开始之前先用一句话复述你对任务的理解。”这句话能逼模型先对齐任务目标如果理解错了你在第一步就能发现不用等它跑完全程。2.3 为什么这两个技巧组合使用效果最好角色锚定解决的是“模型站在什么立场回答”的问题分步拆解解决的是“模型按什么路径回答”的问题。两者组合使用时模型从一开始就被约束在正确的专业语境里同时沿着明确的推进轨迹操作相当于同时锁定了方向和路线。我常用的组合模板长这样你是一位资深的[领域]专家。 请帮我完成[任务]。 按以下步骤执行 第1步[子任务1] 第2步[子任务2] 最后按[输出格式]输出结果。在实践里这套组合几乎可以套用到所有“比较复杂但步骤可以被拆开”的任务上比如写方案、分析数据、设计实验、规划学习路径等等。它的核心价值是降低了模型输出的不确定性而不确定性正是很多提示词“时灵时不灵”的背后原因。3. 让输出格式可控的三个技巧很多人在提示词工程里最头疼的问题就是模型听懂了我的话但输出的格式完全不是我要的。这一章讲三个能让输出格式变可控的技巧。3.1 技巧三格式限定法用结构把输出“焊死”如果你只是说“请用表格输出”模型不一定知道你要几列几行、表头是什么、内容偏向哪个维度。格式限定法的核心是由你定义完整的输出结构让模型往里填内容。结构本身就是最高效的约束。例如做竞品分析我经常用这个模板请分析以下 3 款产品的差异[产品A]、[产品B]、[产品C] 输出格式 ## 竞品概览用表格产品名称 | 核心定位 | 目标用户 | 价格区间 ## 优势对比分点列出每款产品的核心优势 ## 劣势与风险分点列出每款产品的明显短板 ## 差异化机会给出结论性建议注意这里的技巧我不仅限定了“要分为哪几节”还在括号里限定了每一节里的具体字段。这样模型在生成内容时没有任何自由发挥的结构空间只能按照预设维度去组织信息。这个方法在生成数据分析报告、学习计划、复盘文档等场景里都非常好用。3.2 技巧四示例驱动法一个好例子顶过十句描述如果你试过用大段文字描述想要的输出风格、措辞倾向、信息密度但模型就是不听话那大概率是因为“描述”本身就是有歧义的。模型需要把文字描述转译成生成策略这个转译过程会损失大量信息。而示例不同——示例直接给出了从输入到输出的完整映射模型只需要模仿这个映射不需要做额外的语义转译。Few-Shot 提示的标准用法是给 2 到 4 组完整的输入输出对请将以下句子改写成更专业、更有说服力的表达。 示例1 输入这个产品很好用。 输出本产品在可用性方面表现优异操作路径清晰用户学习成本低。 示例2 输入价格有点贵。 输出当前定价处于行业中高水平但结合功能完整性来看具备一定的性价比优势。 现在请改写 输入这个软件更新之后快了很多。 输出我实测下来2 到 4 个示例效果最好。少于 2 个模型学不到稳定规律多于 4 个示例本身的特殊细节可能会干扰模型“过拟合”到示例里。另外示例之间要尽量覆盖不同情况最好能体现你期望的“变化范围”而不是给几个几乎一样的例子。3.3 技巧五负面约束法明确“不要做什么”比想象中更管用大模型在“不要做什么”上的遵循能力通常弱于“要做什么”。但这不代表负面约束完全没用。实际经验是把负面约束当成“事后纠正”专门用来清理模型的高频毛病比如啰嗦、编造、过度承诺。请注意以下约束 1. 不要使用“总之”“综上所述”等总结性套话 2. 不要编造数据或事实如果信息不足请明确说“信息不足” 3. 不要给用户任何形式的承诺只陈述事实信息。但有两个细节需要特别提醒。第一条负面约束一次不要超过三条写多了模型反而抓不住重点一条都执行不好。第二条不要只给负面约束最好框架是“正面要求为主负面约束收尾”就像路标一样先指路再禁行。如果一整段全是“不要不要不要”模型的生成过程会变得很别扭输出结果容易生硬。4. 管理上下文与推理深度从“能答”到“答得对”前三章讲的基本是“让模型听指挥”。这一章要解决更深一层的问题当任务本身比较复杂、信息量很大时怎么让模型答得对、答得准。4.1 技巧六上下文预算管理关键信息该放哪里、怎么放大模型有上下文窗口能接收的 token 数量有限。但“塞得下”不等于“效果一样好”。上下文越长模型对中间部分的注意力越容易分散关键指令被“淹没”的风险越大。我的做法是给提示词建立清晰的分区用分隔符隔离不同信息块【任务背景】 用2-3句话说明当前场景和目标 【参考资料】 放需要模型参考和处理的所有资料内容可长可短 【任务要求】 放具体的执行指令比如分析什么、回答什么 【输出格式】 放期望的输出结构比如分点、表格、JSON等 请基于以上信息开始执行任务。这个结构之所以有效是因为它为模型建立了一个“信息类型”的认知框架——模型能区分哪些是背景、哪些是素材、哪些是需要严格遵循的指令。如果没有分区模型很可能把参考资料里的内容当成指令执行或者把指令当成背景忽略掉。我见过最典型的反面案例有人把任务要求写在了一大段资料的中间模型直接无视了在那里逐字复述资料内容。4.2 技巧七思维链提示强制模型先推理再给结论对于数学、逻辑、规划、代码排查这类推理型任务直接要求模型给答案错误率会明显偏高。原因在于跳步生成时模型需要在一开始就精确“猜到”结果这对概率预测来说太难了。但如果让模型先逐步推理再给结论每一步只需要在当前已经生成的推理基础上往前推进一小步错误率就能大幅下降。基本模板请逐步分析下面的问题每一步都说明你的推理依据最后再给出结论。 问题[问题]进阶版是在示例里直接展示推理过程也就是“思维链 Few-Shot”效果更强示例 问题一个商店促销原价200元的商品打8折再减20元最终价格是多少 推理原价200元打8折后是160元再减20元最终是140元。 结论140元。需要注意思维链不是“写得越长越好”。如果不加限制模型会生成大量自我感动式的废话。我会在提示词里加一句“只输出必要的推理步骤删除与结论无关的说明”。4.3 技巧八自校正循环让模型自己给自己挑错技巧八的思路是把“一次生成”升级为“生成审查”两个阶段。模型第一次生成的答案可能包含错误这个错误在自我纠错阶段有一定概率被识别出来尤其是格式性错误、遗漏要点这类“显性问题”。我的模板请重新检查你上面的回答重点检查以下内容 1. 是否完整回答了用户提出的原始问题 2. 是否存在事实性错误、猜测或编造 3. 是否满足输出格式要求 如果发现问题请直接输出修正后的完整版本如果没有问题请回复“无需修改”。实测下来自校正循环对“遗漏要点”和“格式不符”两类问题的改善比较明显对深层次的事实性错误改善有限因为模型纠错的依据仍然是它自己的知识库如果它本身不知道某个事实检查的时候也发现不了。所以自校正循环适合作为质量兜底不能完全替代人工审查。5. 迭代交互技巧别指望一次问出完美答案前八个技巧都是“单轮提示词”层面的优化。但真正的实战里很多复杂任务不可能靠一轮对话就解决。这一章讲两个需要在多轮对话中使用的技巧。5.1 技巧九澄清追问法把模糊需求一步步问清楚很多提示词失败不是模型不行而是任务目标本身就没定义清楚。与其在一条提示词里塞进所有可能的情况不如先让模型帮你澄清需求。注意是“帮你澄清”不是让你自己想清楚再写实际操作中后者的成本太高了。模板在回答我的问题之前请先向我确认以下 2-3 个问题 1. [关键决策点1] 2. [关键决策点2] 3. [关键决策点3] 基于我的回复再给出完整答案。我经常用这个方法处理“帮我写一份XX方案”之类的开放式任务。模型会问目标用户是谁、核心资源有哪些、预算边界是什么……几轮下来你会发现真正要的东西往往和最初想的不一样。比如一个同事让我帮他想“用户增长方案”追问几轮后才发现他要的只是一个活动页面的文案结构根本不需要一整套增长体系。澄清追问节省了双方的时间也避免了“答非所问”的无限循环。5.2 技巧十元指令法让模型帮你设计提示词最后一个技巧建议所有人掌握当你面对一个不熟悉的领域、不确定该写什么约束条件时直接让模型帮你写提示词。模型训练语料里包含了大量提示词工程相关的内容这就意味着它本身“知道”很多提示词模板。模板你是一位提示词工程专家。请帮我设计一个提示词用于完成以下任务 [任务描述] 设计要求 1. 包含角色设定、具体步骤、输出格式 2. 明确关键约束条件 3. 使用清晰、无歧义的语言。 请直接输出设计好的提示词并附上一段简要说明解释你的设计思路。这个方法最大的价值是降低起步成本。你不需要在完全陌生的领域里靠猜去写约束模型给你的版本虽然不一定完美但作为第一版起点足够了接下来可以配合前面的澄清追问、自校正循环逐步迭代。我在写一些跨领域的分析任务时经常先用元指令生成初版然后按自己的需求改两三个地方整个过程不超过两分钟。6. 附赠模板库10 个场景直接抄作业把前面 10 个技巧浓缩成可以直接复制使用的模板按场景分四组罗列。这里每个模板都经过我反复使用和修改稳定性和通用性都经过了实际任务验证你可以直接复制到对话里试试。6.1 通用写作与表达类角色你是一位有10年经验的[领域]内容专家。 任务请把下面这段文字改写成[目标风格]比如更专业/更通俗/更有说服力。 原文[粘贴原文] 要求 1. 保留原文的核心事实和关键信息 2. 输出结构先给改写后的完整文本再分点说明你做了哪些调整 3. 不要添加原文里不存在的数据或案例。任务请基于以下要点扩展成一篇完整的[类型]文章。 要点 - [要点1] - [要点2] - [要点3] 输出结构 一级观点开头段 三级支撑每个要点展开2-3句 结尾建议给出一个可执行的行动建议 篇幅全文约[字数]字语言[要求语气]。6.2 数据处理与分析类角色你是一位资深数据分析师。 任务分析以下数据找出关键趋势和异常点。 数据[粘贴数据或表格] 步骤 第1步初步描述数据整体情况字段、范围、明显特征。 第2步识别关键趋势并用数据支撑你的判断。 第3步指出异常数据点并推测可能原因。 输出格式用表格列出趋势项和异常项最后给出一段结论性总结。 请按步骤执行每出一步先输出这一步的结果。任务请把这段原始记录整理成结构化清单。 原始记录[粘贴内容] 输出格式Markdown表格 | 序号 | 事项 | 负责人 | 优先级 | 状态 | 备注 | 最后单独输出一个“待确认项”列表列出记录中存在歧义或信息缺失的地方。 约束不要修改原始记录里的事实信息只做整理和归纳。6.3 编程辅助类角色你是一位有10年经验的[语言]工程师擅长代码审查和性能优化。 任务审查下面这段代码找出潜在的 Bug、性能问题和安全隐患。 代码 [粘贴代码] 输出格式 ## 问题列表按严重程度排序 1. [严重程度] 问题描述、位置、原因 ## 修复建议 给出修改后的关键代码片段 ## 补充测试建议 给出需要补充的边界测试用例 约束只分析已给出的代码不要假设不存在的结构。任务帮我写一个[功能描述]的[语言]函数。 输入输出示例 输入[示例输入] 期望输出[示例输出] 输入[示例输入2] 期望输出[示例输出2] 要求 1. 函数签名明确包含类型标注 2. 处理边界条件空值、极值、异常输入 3. 输出代码后附一段简短说明解释核心逻辑和复杂度。6.4 头脑风暴与知识问答类角色你是一位熟悉[领域]的创意策划专家。 任务针对以下主题进行头脑风暴。 主题[主题] 要求 1. 先给出 5 个完全不同的切入角度 2. 从每个角度延伸出 2 个具体可执行的方案 3. 最后为每个方案标注所需资源和潜在风险。 约束优先考虑低成本、可快速验证的方案。请基于以下参考资料回答我的问题。 【参考资料】 [粘贴资料] 【问题】 [具体问题] 要求 1. 优先引用参考资料里的信息在答案后标注对应来源段落 2. 如果参考资料中没有相关信息请明确说“资料中未提及”不要自行补充 3. 回答控制在[字数]字以内结论前置。7. 实战踩坑记录模板失效的三种典型情况技巧和模板都给了但直接复制粘贴未必能跑通所有场景。下面这三个坑是我在实战中反复踩过、也帮团队排查过很多次的专门写出来帮你避雷。7.1 角色设定与真实任务冲突小心“角色反噬”前面提到我让“资深律师”写轻松文案翻车的案例。这个现象的背后逻辑是角色设定一旦过强模型会把“角色身份”置于“实际任务”之上导致它用角色习惯的表达方式去执行所有任务。你让它写活泼文案它依然在使用法律文书的用词和行文节奏。解决办法有两个方向。一个是弱化身份标签、强化能力标签——把“你是一位资深律师”改成“你擅长法律领域的分析和表达”另一个是在角色设定后明确补充任务的语气风格比如“虽然你擅长法律分析但本次任务需要轻松、口语化的表达请完全切换为这种风格”。第二个办法我测试过很多次比单纯弱化角色更稳定。7.2 “请用简洁的语言”这类模糊指令基本等于没说这是我见新人用得最多、也最无效的指令。原因很简单模型没有“简洁”的量化标准。你觉得 500 字才算简洁模型觉得 2000 字已经压缩过了。没有具体数字和结构约束模型只能按照训练数据里的“平均值”来生成结果自然不是你想要的。正确做法是把“简洁”翻译成可量化的约束。比如“回答控制在 100 字以内”“只保留结论和关键数据删除所有修饰语”“分 3 点每点不超过 20 字”。同样的道理适用于所有抽象形容词——具体、友好、有深度、专业都要翻译成模型能执行的具体指令否则执行效果全看运气。7.3 提示词也需要版本管理别把工程资产随手丢提示词写出来之后不是一劳永逸的。同一个提示词换了模型、换了参数、甚至换了输入数据的长度效果都可能变化。很多团队只保存最终版提示词一旦效果变差完全没有回溯依据只能从头再试。我现在把所有对外发布的提示词都纳入版本管理格式很简单用表格记录就够版本日期模型修改内容效果评估v12024-01-10某模型初始版本输出冗长结构不清晰v22024-01-12某模型增加格式限定结构清晰但遗漏关键数据v32024-01-15某模型增加2个Few-Shot示例稳定达标这个习惯看起来不起眼但在项目长期迭代、模型升级、团队成员协作时能省下大量重复试错的时间。提示词工程做到最后其实拼的是工程化习惯不是灵光一现的写法。最后再说点我自己的体会。用了这么久的提示词最大的变化不是掌握了多少模板而是建立了一种“从模型的视角看问题”的习惯。每次写提示词之前我都会先问自己如果我是模型光看这段文字我知不知道用户到底想要什么、按什么结构输出、边界在哪里带着这个问题去写很多低级错误从一开始就能避开。技巧会更新模型会升级但这个视角不会过时。你也试试。