聊提示词工程之前先摆一个很现实的问题同一款大模型产品有人在十分钟里拿到了一份能直接用的方案有人来回调了半天得到的还是一堆正确的废话。差距不在工具而在提问的方式。我自己做内容开发和自动化流程改造时被这种落差折磨过很多次后来才慢慢意识到大多数人不是不会写提示词而是从来没把写提示词当成一个可以拆解、可以优化、可以复用的工程问题来对待。这篇内容把我实际项目里沉淀下来的 10 个技巧和配套模板整理成了一份可以“抄作业”的清单。每一条都遵循一个原则立刻能上手不需要理解复杂的算法原理改一改就能用在自己的场景里。适合刚接触大模型的小白也适合已经在用 AI 辅助开发、写作、分析数据但总觉得输出“差点意思”的朋友。以及在读完技巧之后我会聊聊目前圈子里讨论度很高的“上下文工程”这个概念——它本质上才是提示词工程的完全体。1. 先聊清楚提示词工程到底在解决什么问题1.1 提示词不是“打字”而是需求沟通的翻译层很多人以为提示词就是对话框里输入的那段文字其实不是。提示词承担的核心工作是翻译——把人的模糊意图翻译成模型能够精确执行的指令。大模型的本质是一个“根据上下文预测下一个词”的系统它没有真正的意图理解能力你给它什么上下文它就顺着这个上下文往下推进。也就是说它的输出质量完全取决于你喂给它的信息质量和指令清晰度。如果需求本身模糊模型只能用概率去补全一个“看起来合理”的答案结果自然不稳定。举个例子。你说“帮我写一个活动策划”模型大概率会给你一个五段式通用模板背景、目标、时间、地点、流程看着什么都有但其实什么都不能直接落地。如果你换成“我是一家社区书店要在下周六晚 7 点办一场以‘夏夜诗歌’为主题的朗读会目标人群是 20-35 岁的周边居民预算 2000 元请给我输出一份从开场到结束的 90 分钟流程安排并按 15 分钟为单位拆分”输出的内容会完全不一样。所以提示词工程真正解决的是三个问题输出不稳定、答案不精准、内容不可用。它不是在“教”模型而是在约束模型的概率空间让高概率的词落在你想要的方向上。1.2 提示词工程的四个基础认知先搭好框架再动手我在实际使用中总结了一套四步框架几乎可以套在所有场景里明确目标先搞清楚这次调用到底要得到一个什么东西是一段文案、一份代码、还是一个决策建议。组织信息把完成任务所需要的信息按逻辑顺序摆放重要的前置信息一定不能放在最后。约束输出明确格式、长度、风格、语气、必须包含的元素让模型没有“自由发挥”的空间。校验迭代把模型输出当作初稿通过追加指令修正偏差必要的时候抛回给模型让它自己检查。这套框架听起来很简单但大部分人的提示词连第一步都没做到。很多人上来就是“写个方案”模型根本不知道方案给谁看、要解决什么问题、输出形式是什么。这里还牵扯到一个最近被反复讨论的概念——上下文工程。很多人把它当成提示词工程的“升级版”我个人的理解是提示词工程偏向单次指令的设计而上下文工程更看重整个对话环境里信息的组织方式包括背景资料的丰富度、信息的排列顺序、模型生成内容的再沉淀和再利用。换句话说单次指令决定“这一轮回答”的成色上下文工程决定“多轮对话”整体能跑多远。后面技巧十我会展开讲。2. 10 个能立刻上手的提示词技巧每一个都经过实测2.1 技巧一给模型一个身份而不是直接说“帮我写”让模型扮演特定角色是我用过性价比最高的一招。原因不复杂身份设定会激活模型在训练数据里学到的对应领域知识组织方式相当于给输出划定了一个风格和视角的范围。实际对比一下同样是“分析这个产品的优缺点”直接问和加入身份是完全不同的结果。我的固定句式是“你是一位拥有 10 年经验的资深产品经理请从用户留存和商业价值两个维度分析以下产品的优缺点”后者的输出会明显更有结构化思维也更像行业内的人说的话。要注意两点一是角色要具体别只写“你是专家”这种空泛的表述要写明领域、年限、甚至服务的公司类型二是角色要和任务匹配让财务分析师写幽默段子输出质量一定会垮掉。模板示例你是一位拥有多年一线经验的【岗位/身份】擅长【核心能力关键词】。 请基于以下信息完成【任务描述】。 要求输出内容需体现【身份对应的专业视角】。2.2 技巧二任务指令拆成“动词 对象 约束条件”很多时候模型输出跑偏是因为指令里塞了太多信息模型抓不住主干。我自己在处理复杂需求时会把指令压缩成一个固定句式动词 对象 约束条件。这个结构的核心逻辑是让模型能清晰识别三件事要做什么动作、动作作用于什么对象、完成标准是什么。比如“总结”是动词“这篇文章”是对象“用 3 个要点概括每点不超过 50 字”是约束条件。三者齐全模型的输出才有边界感。我的真实体验是很多输出“假大空”的提示词恰恰是缺少约束条件。尤其在职场场景里“写一封邮件”这种指令几乎必然产生泛泛而谈的内容但如果你补上“收件人是跨部门同事语气要礼貌但直接正文不超过 150 字需要明确本周五前给出反馈”模型立刻就知道该怎么写了。模板示例请【动词】以下【对象】要求【约束条件1】、【约束条件2】。2.3 技巧三每个关键输出都配一个“示例”别用形容词描述我一直认为给模型描述“写得好一点”是世界上最没用的话因为“好”的标准实在是太主观了。真正有效的做法是直接给一个示例让模型照着样子输出。这就是常说的 few-shot 提示。这个技巧的背后是模型的“类比学习”本能给一个示例模型就能推断出你想要的风格、结构和详略程度。给两个风格不同的示例模型还能学会在两者之间做融合。举个例子我要让模型写小红书风格的产品文案与其说“写得生动活泼一点”不如直接给它一篇我自己认为合格的文案再让它模仿。我实测过给一个高质量示例的效果比写一整段形容词的效果好得多。模板示例请按以下示例的风格和结构完成新的写作任务。 示例 【示例内容】 现在请写【新任务内容】2.4 技巧四用“填空式”结构锁定输出格式技巧二解决的是内容跑偏技巧四解决的是格式混乱。当我对输出格式有明确要求时会用填空式结构在提示词里定义好每一段开头让模型只能在这个框架里填内容。比如需要模型输出一份产品需求文档我会这样限制“请按以下格式输出一、背景100 字以内二、用户痛点列出 3 点三、解决方案分 3 步说明四、验收标准用列表形式”。因为有了明确的章节前缀和字数限制模型几乎不会自主发挥跑题。这里有一个心理层面的原因格式本身会引导模型自动填充相关内容。给它一个空表格它就会想办法把表格填满而且填的内容会自动向表格标题靠拢。所以善用格式模板等于给模型提前画好了一条最省力的路径。模板示例请按以下结构输出 一、概述80 字内 二、核心问题三条每条用一句话 三、解决思路分步骤说明 四、落地清单逐条列表2.5 技巧五把“不要”翻译成“要”这是我在调提示词时踩过最多次的坑写负面约束时总是用“不要……”的句式但模型有时候就是会往“不要”的方向跑。后来我意识到模型理解关键词的方式更像加权它看到“不要啰嗦”反而强化了“啰嗦”这个词的存在感。正确的做法是直接告诉模型“要什么”。把“不要写得太长”改成“全文控制在 200 字以内”把“不要用太专业的术语”改成“用初中生能理解的语言表达”把“不要有错别字”改成“输出前请自行检查一遍错别字”。这个转变看着小实际效果非常明显指令的准确率会高很多。不是说负面约束完全不能用而是它只能作为补充不能作为主体。真正的主指令必须是肯定句、行动句告诉模型该做什么。你先告诉它正确路径再用“如果出现 XX 情况请避免”作为辅助规则这才是合理的组合方式。2.6 技巧六复杂任务先拆成步骤再一步步喂给模型有时候不是提示词写得不好而是任务本身太复杂超出了模型单次处理的能力上限。我见过最典型的情况是让模型“分析这个行业并输出一份完整商业计划书”结果模型把每个部分都写得非常浅。遇到这种任务我的做法是把任务拆解成流水线每个步骤只做一件事。第一步先让它整理行业背景第二步让它基于背景做用户画像第三步再让它根据用户画像设计产品方案最后再把前几步的输出拼起来让模型统一润色成完整文档。这样做的原因是模型在单次生成中能维持的“注意力”是有限的任务越复杂平均分配到每个模块的“注意力”就越少。拆开以后每个步骤都能拿到模型全部的生成能力质量自然会提升。虽然看起来多调了几次接口但整体效率和效果都要好于一次性输出。模板示例多轮第一轮请整理行业背景输出 200 字摘要。 第二轮基于摘要分析目标用户的核心需求列出 5 条。 第三轮基于以上分析设计产品方案按功能模块拆分。2.7 技巧七强制“二次自检”让模型自己找漏洞大模型的输出经常存在一种“确定性错觉”——它自己写得非常自信但细节处却漏洞百出。对抗这个问题的办法不是自己反复检查而是让模型自己执行一次自我校验。核心操作是在主任务后追加一句“请对以上输出进行检查列出可能的漏洞和不足并输出修订版”。我实测过的效果是第一次输出往往是“发散模式”内容全面但粗糙经过自检和修订后第二次输出会明显更精准。还有一个变体可以用于写作类任务先让模型输出初稿然后追加“以批判者的角度审视这段文字指出 3 个可以改进的地方说明原因再输出修改稿”。这种批评者和作者视角的切换能激活模型不同方向的知识组织方式比直接要求“写得好一点”有效得多。2.8 技巧八让模型先复述需求再开始执行这个技巧特别适用于需求复杂、信息量大的任务。你可以在发出正式任务之前先让模型用自己的话说一遍它接收到的需求。这样做的目的是让模型在真正执行前强制“消化”一遍你的指令把所有信息组织到正确的坐标里。我通常的句式是“在执行任务前请先用 3 句话复述你的任务目标、输入信息和输出要求确认理解后再开始”。这看起来浪费了一轮对话但实际上能避免至少两三轮的返工。尤其是当你的提示词超过 5 行时复述环节可以提前暴露模型可能误解的地方让你有机会修正指令。这个技巧背后有很妙的心理逻辑模型在复述需求时其实是在重新组织信息这个过程会强化它对任务的理解深度让后续生成不是直接从概率库中“蹦”出来而是先从需求框架里“顺”出来。2.9 技巧九用“如果……那么……”句式给模型写执行规则给模型写规则时逻辑条件句往往比形容词描述更好用。因为模型本质上是在做序列预测而“如果-那么”结构提供了一种清晰的逻辑路径缩小了接下来的预测范围。比如我要让模型写一封沟通邮件我会这样设定规则“如果收件人语气不佳那么回信要保持礼貌如果对方询问具体时间那么明确告知 3 月 15 日下午如果对方没有提到预算那么不要在回信中主动报价。”这样的条件规则一旦建立模型在生成内容时就会自动沿着一条“逻辑轨道”走而不是漫无目的地发挥。这个方法让我想到一个更底层的原则提示词的质量不取决于词语的花哨程度而取决于它为模型提供了多少确定的结构。条件句是结构里比较稳固的一种。2.10 技巧十管好上下文才是提示词工程真正的“尽头”现在很多人在聊“上下文工程是提示词工程的下一步”我非常认同而且在实战里已经开始依赖这个视角了。所谓上下文工程不仅包括你单次输入的提示词还包括对话累积的信息环境、外部知识注入、输出内容的再组织和再调用。我的实际操作有三点优化一是长对话里定期“压缩上下文”。当聊天记录变得很长我会让模型“把前面的讨论总结成 5 个要点作为后续对话的背景信息”然后开启新对话把总结粘贴进去。这样既能保住关键信息又能避免超长上下文导致的“中间遗忘”问题。二是主动注入外部知识。模型的知识库有截止日期遇到新政策、新事件时我会在提示词里粘贴相关资料片段让它基于这些材料而非记忆来回答。这一招在需要时效性的场景里几乎是必需的。三是利用“记忆索引”。我会在每轮重要输出后追加一句“用一句话概括本轮核心结论”这些结论会在后续对话里反复引用相当于给模型建立了一个临时的知识索引让它能快速找到更早之前的信息而不是每次都被最新一轮对话带偏。技术这东西玩到后面拼的往往是细节。这些细节看起来微不足道但组合起来就是“能用”和“好用”的分界线。3. 模板库我平时直接复制改用的 10 套模板3.1 通用创作模板覆盖 80% 的内容场景这套模板是我日常用得最频繁的结构上结合了技巧一、二、四和五。要点是先交代身份再明确任务最后用格式锁死输出。你是【身份描述】。 请【动词】以下内容【内容对象】。 要求 1. 风格【风格关键词】。 2. 篇幅【具体字数或行数限制】。 3. 结构【明确的分段结构】。 4. 避免出现【负面词或表述】。 输出前请自查一遍确保【核心质量标准】。以写产品介绍为例实际填充出来是这样的你是一位资深科技产品文案。 请撰写以下智能手表的电商详情页文案产品卖点为续航 14 天、血氧监测、轻至 28g。 要求 1. 风格简洁、有科技感但不堆砌术语。 2. 篇幅开头 30 字卖点 3 条每条约 20 字。 3. 结构先场景引入再罗列卖点最后一句行动号召。 4. 避免出现夸大疗效类表述。这套模板的灵活度很高把“身份描述”和“内容对象”替换掉就能用在大部分内容创作场景是我推荐优先收藏的基底模板。3.2 结构化分析模板处理“分析、总结、对比”类任务做信息整理和行业研究时我会用下面这套模板它综合了技巧六的“拆解”思路和技巧九的“条件逻辑”。请分析以下问题【问题描述】。 分析步骤 第一步列出影响这个问题的 3 个关键因素 第二步对每个因素说明其影响机制 第三步基于上述分析给出 2 个可执行建议。 规则 如果信息不足请直接标注“待补充信息”不要编造数据。 最终输出需包含结论摘要、分析过程、建议清单三部分。这套模板最核心的价值在于“分步指令”。我试过直接问“帮我分析市场趋势”模型输出不仅宽泛而且经常混淆“现状”和“趋势”。用这个模板后输出会严谨很多因为每一轮生成的焦点都被限制在一个明确的问题上。3.3 内容改写与润色模板解决“读起来缺点味道”的问题很多场景下初稿已经有了但质量欠缺。用这套模板可以把初稿速度和质量都提上去核心是“身份切换 示例引导 多版本输出”。你是一位【领域】编辑。 请对以下文字进行改写【原文】 改写目标【具体说明比如“更口语化”“更有节奏感”“更正式”】 请输出 3 个不同风格的版本 版本 A最接近原文风格只优化流畅度 版本 B大幅调整结构面向【目标受众】 版本 C保留核心信息但将篇幅压缩至【目标字数】以内。这套模板我用得最多的是公众号文章和产品文档的改写场景。三个版本的输出方式特别适合“先广度筛选、再深挖一条线”的创作节奏能帮我节省大量初稿时间。3.4 代码调试与开发辅助模板给程序员的专用版本虽然题目偏通用领域但我知道读者里有很多开发者这里单独给一套编程场景的模板非常好用而且是实测有效的。你是一位【语言】高级工程师。 请审查以下代码并指出【具体诉求比如“潜在的内存泄漏问题”】 代码 【贴代码】 输出要求 1. 按“问题严重程度”从高到低排列发现的问题 2. 每个问题标明所在行号和原因 3. 对每个问题给出修复后的代码片段 4. 如果你认为代码没有重大问题请直接回复“未发现问题”并附上 2 条优化建议。这个模板的关键在于“输出要求”部分它把代码审查从“这个代码怎么样”变成了“按严重程度列问题、给修复方案”的清单式输出模型不会给你无关废话。3.5 让模板真正复用的秘诀参数化 效果记录上面的模板可以直接粘贴使用但要想真正形成自己的“模板库”光复制是不够的。我的经验是每套模板至少用三次每次都记录下输出质量的变化好的输出结果要连带着提示词一起存入本地文件形成一个“提示词 - 输出 - 优化记录”的三元组。一段时间后你会发现真正有用的不是模板本身而是你和模型之间经过反复打磨后形成的“默契”。另外一个实操细节是模板里的占位符尽量用【】框起来这样每次修改时只需要全局搜索替换不用逐句调整省时省力。4. 常见问题排查与避坑清单4.1 模型“不听指令”时先检查这 5 个原因遇到模型输出完全偏离预期的情况先不要急着骂模型大概率是提示词本身出了岔子。按照以下顺序逐项排查基本能覆盖 90% 的问题第一指令顺序是不是反了核心任务应该放在最前面背景信息放在后面。如果模型读到第 3 段才发现你的真实意图它已经被前面冗长的铺垫“带偏”了。第二任务是不是太复杂如果任务本身需要多步推理但你没有拆解模型就会“一步到位”地泛泛而谈。第三输出格式有没有明说不给格式约束模型会默认采用它在训练中见最多的格式。第四示例给了没有评价标准主观的任务缺少示例等于让模型猜你要什么。第五有没有使用双重否定句式比如“不要用不正式的语言”这种写法模型很容易理解成要“不正式的语言”。每次模型输出不如预期就按这个顺序检查一遍优化效率会非常高。4.2 输出“千篇一律”怎么破两个加点技巧很多用户抱怨模型写出来的东西都是一个味道有一种“AI 味”。这个问题我在使用中也经常遇到后来总结出两个有效的改善方向。第一个方向是加强“目标对象”的设定。当你说“请为公司写一段欢迎词”时输出的确是通用模板但如果你说“请为一位刚从海外调回、第一次到上海分部任职的技术总监写欢迎词团队里有 10 个毕业生、5 个资深开发”内容的针对性会立刻提升因为模型的能力上限远比很多人以为的要高它缺的只是参考坐标。第二个方向是引入“风格混搭”。让模型模仿某个人或某种文体或者直接给出几个风格关键词的组合比如“将这段技术文档改写成适合播客口播的脚本语气轻盈但有信息密度多用短句”。风格越是具体输出越不容易“模板化”。4.3 一份提示词效果速查表对照着调整准没错问题表现可能原因对应调整策略输出太泛、没重点缺少任务对象与约束条件用技巧二的“动词对象约束”结构重写指令内容结构混乱没有给出格式定义用技巧四的“填空式”模板锁定输出结构风格不对味缺乏身份设定或示例用技巧一设定身份配合技巧三提供示例信息不准确模型在凭记忆编造主动注入外部材料限定它只能依据材料回答多轮对话后遗忘前文上下文过长、信息被稀释定期总结关键信息重新作为上下文注入输出总是“太正经”约束太多、自由度太低用技巧九条件句放行某些“可发挥空间”这张表是我自己电脑上的备忘录现在整理成表格分享出来。每次觉得模型输出“不可理喻”的时候先来表格里找一找有没有对应项基本都能找到根源。4.4 我踩过的几个坑希望你们绕开先说说“过度修饰”的问题。很多人觉得提示词越长效果越好于是会塞入大量形容词和背景故事。我的实测结论是有效的提示词不在于长度而在于信息密度。一段 300 字的提示词如果包含了完整的目标、对象、格式、评价标准效果远好过一段 1000 字但信息重复、逻辑混乱的“豪华配置”。第二个坑是“经常换模型不换提示词”。不同模型之间的指令理解能力、指令遵循能力差异很大同一套提示词在 A 模型上能跑出 90 分在 B 模型上可能只有 60 分。我的做法是给每个模型单独维护一套提示词模板版本不追求“一次编写处处运行”。第三个坑比较隐蔽很多人整个流程里只关注“输入”和“输出”完全忽略“迭代”。我曾经为了拿到一个理想的产品定位方案连续调了七八轮提示词每一次都基于上一轮的输出追加新的反馈。这个过程里模型不是一次生成的工具而是一个渐进式的思考伙伴。用好这个节奏比任何技巧都重要。最后一个建议是每次跑出高质量输出之后一定要把提示词存下来并备注当时的使用场景和效果评价。这不仅是模板库的起点也是你理解“为什么这条有效”的第一手资料。积累多了你会在里面发现很多有意思的规律比如某些句式在特定任务里的表现稳定优于其他句式这些规律比网上任何教程都更贴合你的实际业务。我自己做内容创作和产品方案已经用这套方法把重复性工作的耗时长比压缩到原先的三分之一。如果你想从“会聊天”进化到“能稳定产出”真正值得投入时间的不是追求更复杂的技巧而是把每一次和模型的对话当成实验把每一次成功的结果沉淀成资产。这就是我从提示词工程里学到的也是上下文工程教会我的更底层的道理模型能走多远不取决于它而取决于你为它搭建的上下文有多扎实。