1. 为什么你调了半年Prompt，结果还是忽好忽坏
我早先犯过一个典型的错误：把生成式AI当成一个“会猜心的同事”，总以为只要把问题讲得足够清楚，它就能给出我想要的答案。后来做了几十个真实项目才发现，稳定输出从来不是“碰运气”，而是系统设计出来的。同样的诉求，用不同的指令结构去表达，效果能差出三到五倍。
你可能会问，那提示词工程到底在解决什么问题？我的回答是：它解决的是“模型对你意图的还原度”。模型不是一个理解者，它更像一个概率预测机器。你给它的文字，它的一切行为都是从这些文字和既有知识中预测出来的。所以“怎么说”往往比“说什么”更容易决定结果的质量。这不是玄学，而是上下文工程里最基本的逻辑：模型不知道你想要什么，它只知道自己“应该输出一段看起来合理的文字”。你给的约束越清晰，它的预测空间就越小，输出自然就越靠谱。
这里我想先引入“上下文工程”这个概念。现在圈内有个共识，上下文工程其实比提示词工程的外延更大。提示词工程关注的是“指令本身怎么写”，上下文工程关注的是“模型在生成时，眼前到底有哪些信息可以用”。指令是对行为的约束，上下文是对知识的供给。两件事都做对了，输出才会稳定；只做对其中一件，就会出现“提示词写得挺好，结果还是跑偏”的尴尬情况。
我见过太多人反复调提示词，每次都不顺手。表面看是在调措辞，实际上是在乱枪打鸟。真正的问题往往集中在四个地方：
- 没有定义清晰的输出格式，模型只能靠“猜”来排版；
- 上下文信息投喂不足，模型拿不到足够的前提条件；
- 没有给任何示例，抽象要求全靠模型自由发挥；
- 没有设置检查机制，错误观点到了输出阶段不会被拦截。
这四个问题，其实就是后面十个技巧要逐一击破的靶子。先说结论：提示词工程不是“会聊天”，而是“会布置任务”。你现在要做的，不是把提示词写得更漂亮，而是把它当成一份“临时工入职说明书”来写。说明书越完整，临场发挥的偏差就越小。
我也看到过一种说法，说提示词工程快被“上下文工程”取代了。我的看法是，两者不是替代关系，而是递进关系。你把上下文喂得再足，如果指令写得稀碎，输出也还是一团乱麻。反过来也一样。所以后面这十个技巧里，有几个属于指令层面的，有几个属于上下文层面的，实际用的时候建议直接组合使用，不要指望某一个技巧单独解决所有问题。
2. 基础篇：让指令更稳定的五个通用技巧
这五个技巧是我认为性价比最高的。它们不需要你理解复杂的模型原理，只要照着改表达方式，输出质量的提升几乎是立竿见影的。
2.1 技巧一：给模型写“人设工作档案”，而不是一句话身份
很多人一上来就写“你是一个资深分析师”，然后开始提问。这句话有效，但效果有限。因为它只定义了身份标签，没有定义工作风格、知识边界、输出偏好和禁忌。
我比较推荐的做法，是把角色描述扩展成一份两三百字的“工作档案”，里面包含四类信息：
- 岗位职责：这个角色主要负责完成什么类型的任务；
- 专业背景：它有哪些知识储备，说话的专业深度如何；
- 表达风格：用词习惯、语气，是简洁还是详细；
- 输出禁忌：哪些事情不能做，比如不能编造数据、不能给模糊结论。
举个例子。普通写法是：“你是一位资深技术博主，请写一篇关于提示词工程的文章。”这种写法模型写出来容易特别“AI味”，每个段落都像在按八股结构展开。
升级写法是：
你是一位拥有十年经验的技术博主，主攻AI应用方向，喜欢用生活化的类比解释复杂概念。 写作时请遵循以下要求： 1. 开头直接描述真实场景，不要用“随着技术的发展”这类万能开场； 2. 每个观点必须有具体案例或数据，不能空谈； 3. 段落之间要有因果关系，不能只是罗列要点； 4. 结尾要落在个人经验或操作建议上，不要升华总结。你会发现，同样的主题，按第二版写出来的内容结构完全不同。因为模型拿到了更具体的“风格约束”。从原理上讲，工作档案其实是在压缩模型的生成空间。它的候选输出范围变小了，命中你需求的可能性自然变大了。这个技巧和上下文工程的关系在于：它本身就是在给模型补充一种“行为上下文”，属于低成本、高收益的一类操作。
2.2 技巧二：把“前情提要”塞进上下文，避免模型在真空中工作
很多人的提示词失败，不是指令本身有问题，而是模型缺少必要的背景信息。比如你让它“帮我分析这个数据”，但完全没有交代这个数据是什么、从哪里来、分析目标是什么、给谁看。模型只能先猜测，再基于猜测输出。一旦猜错方向，结果自然就没法用。
我的习惯是，任何任务描述都至少包含四个要素：背景、目标、对象、约束。这在上下文工程里通常被叫做“任务简报”。你可以把它理解成给模型看的“前情提要”。模型不是一个会主动追问的助理。你如果不说，它不会问“你有没有更多背景资料”，它只会默默编一套合理的假设，然后用这套假设回答问题。
所以与其抱怨模型答得不对，不如检查一下自己有没有把该说的话说完。下面是一个很典型的对照：
- 不写上下文：请总结下面这篇文章的核心观点。
- 写完整上下文：这篇文章是产品团队上周发的季度复盘，目标读者是公司管理层。请用三句话总结核心观点，并且明确区分“已完成事项”和“风险项”，如果原文没有提到风险项，也请明确说明。
加了背景之后，模型的输出维度立刻被收窄。它知道该从哪个角度提炼，也知道了表达格式。这个技巧在长文本处理场景里尤其重要。你一次性把全部材料贴进去，比一句一句“追加解释”要稳定得多。因为大语言模型在长对话里会存在注意力偏移的现象，早期信息对后期输出的影响会逐渐衰减。把关键背景放在离任务指令最近的位置，实际效果往往最好。
2.3 技巧三：先定输出格式，再谈内容
这是我个人最看重的一个技巧。很多人写提示词，脑子里想的是“要什么内容”，很少去想“内容长成什么样”。模型返回结果之后，他们再手动调整格式，等于把本该模型干的活揽到了自己身上。我的建议是，把格式要求写进提示词的开头，而且写得越具体越好。
比如你需要一份对比表格，就明确告诉模型：
请用Markdown表格输出，表头依次为：对比维度、方案A、方案B、适用场景、注意事项。 每个维度下必须给出明确结论，不能写“视情况而定”。如果你需要它输出一篇文章，可以在提示词里直接给出文章结构，让它照着填充。这看起来是在约束模型，实际上是在帮它降低生成难度。因为当模型知道每一段的主题是什么，它就不需要自己构思整体布局，只需集中精力把每段内容写好。输出质量自然会提升。
我实际操作中还会用一个小技巧：把“格式要求”和“内容要求”分开写，中间用分隔线标注。这样模型能更清晰地分辨“这段文字是要求”还是“这段文字是素材”，避免格式要求被当成内容来理解。这算是我自己踩过几次格式混乱的坑之后总结出来的经验。
2.4 技巧四：用一个示例代替十句解释
提示词工程里有个概念叫Few-shot，也就是少样本学习。给模型一个或者几个例子，比用抽象语言描述你想要的风格、结构或语气更直接。原因是模型非常擅长模式匹配。你给它一个匹配模式，它就能近似复制这个模式；你只给它一段抽象描述，它反而容易抓不住重点。
举个例子，如果你希望模型帮你改写一段客服回复，与其反复说“语气要友好、不要太生硬、不要用套话”，不如直接给它一个标准示例：
原始客户消息：你们产品太难用了，我要退货。 标准回复：非常抱歉给您带来不好的体验。我是客服小林，想先确认一下您具体在哪个环节遇到了问题，这样我好帮您找到最快的解决办法。您看方便描述一下吗？模型看到这个示例之后，会自己归纳出“道歉—共情—引导—提供方案”的话术结构，然后照着这个结构去处理其他客户消息。这个方法几乎可以套用到所有内容生成场景，从邮件写作、文章风格模仿到代码注释规范。
不过要注意，示例的质量决定输出的上限。如果你给的示例本身很水，模型就会学习到这种“水感”。所以我会在示例旁边标注一句话：“请严格按照示例的表达风格和结构输出。”这样做能进一步缩小偏差。
2.5 技巧五：把否定约束改写成正面指引
我发现很多人在提示词里习惯性写“不要……”：不要写废话、不要用AI味、不要总结、不要说空话。这类否定式的约束，模型处理起来并不稳定。它可以被一个“不要”字跳过，却很难针对否定指令做精细调整。更有效的做法，是把它转化为“正面要求”。
对比一下这两组：
负向表述：不要写无聊的开头。
正向表述：请用一个反直觉的数据或真实场景来开头。
负向表述：不要用套话。
正向表述：每个结论都用可验证的事实或案例支撑。
为什么正面指引更有效？因为模型的生成过程本质上是按概率挑选下一个词。一个“不要”会降低候选词的概率，但它并不清楚你真正想要的候选词是什么。而一个正面的指令，等于把目标候选词的范围直接划了出来。把“不要什么”翻译成“要什么”，这是提示词工程里性价比极高的一个动作。
当然，不是所有否定句都要禁止。有些硬性安全约束，比如“不要输出非法内容”“不要编造数据来源”，仍然有必要保留。这类约束用于兜底，而正面指引用于引导。主次分明，效果最好。
3. 进阶篇：让模型帮你把质量关的五种机制
这五个技巧，和前面五个最大的不同在于：前面是调整“输入结构”，后面是设计“生成机制”。你让模型从“一次性输出”变成“多阶段生产”，相当于在交付之前加了几道质检工序。
3.1 技巧六：用步骤拆解把大任务切成小任务
很多人让模型“写一份市场分析报告”，模型写出来通常是一堆大路货。这是因为这个任务太大了，模型无法在所有维度上都保持深度输出。如果你把任务拆成几步，比如第一步先整理框架，第二步逐个填充关键结论，第三步补充数据支撑，第四步检查逻辑连贯性，每一轮的质量都会明显上升。
步骤拆解的核心逻辑，是降低单次生成的复杂度。你可以把它类比成修车：不会有人让一个技师“把车修好”，而是会说“先检查发动机异响，再检查刹车片磨损，最后给出维修清单”。每一步的指令越聚焦，输出的可预期性就越强。
实际操作中，我会在提示词里直接要求模型“分步完成”：
请按照以下步骤来处理这个任务： 第一步，列出所有可能的切入角度； 第二步，从中选出三个最有说服力的角度； 第三步，每个角度分别给出论点和论据； 第四步，把三个角度串联成一篇逻辑连贯的文章。 每一步完成后，都请输出当前阶段的成果，再进入下一步。这种写法还有个额外好处：你可以随时在中间介入。如果你发现第二步选错了角度，可以直接打断它，要求重选，而不需要整个任务重新做一遍。这在长文本生成场景里非常实用，也是我处理复杂任务时最常用的手段。
3.2 技巧七：把思维过程藏进“草稿区”
思维链（Chain of Thought）是这两年非常流行的一个技术概念。它的核心思想是：让模型先把推理步骤写出来，再给出最终答案，而不是直接跳到最后。这个方法对数学题、逻辑题、方案对比类任务尤其有效。
但如果你直接把所有内部推理过程暴露给用户，体验不一定好。所以我的做法是增加一个“草稿区”设计：
在正式回答之前，请先在草稿区完成以下步骤： 1. 用自己的话列出关键事实； 2. 写出你看待这个问题的分析思路； 3. 记录你能想到的潜在反方观点； 然后，基于草稿区的内容，输出干净整洁的正式回答。 正式回答中不得出现草稿区内容。这个设计最棒的地方，是把模型内部推理变成了一次“可观察、可干预”的中间产物。你不仅能看到结论，还能看到它是怎么一步步得出结论的。如果结论有问题，你也可以直接检查草稿区，快速判断是哪个环节出了问题，而不是对着错误的结论瞎猜。
3.3 技巧八：交付之前，先让模型自己当一回审查员
模型有时候会一本正经地胡说八道。这不是它故意骗你，而是它在生成时并没有一个“自我纠错”的环节。写代码的人都知道，写完代码要跑测试；写文章的人都知道，定稿前要通读一遍。提示词工程里也有对应的做法，我称之为“迭代式自检”。
你可以这样写：
在完成初稿之后，请以严谨的审查员身份检查以下内容： 1. 是否存在事实性错误或逻辑矛盾； 2. 是否有模糊不清、模棱两可的表达； 3. 是否遗漏了用户核心需求中的任何一项； 4. 信息密度是否足够，有没有大段空话。 如果发现问题，请列出问题清单并给出修改版本。不要跳过检查步骤。这个技巧对长文档生成价值极大。因为模型在连续长文生成中，容易在后半部分“忘记”开头的限定条件。自检机制相当于按了一次“刷新键”，让它重新审视全文。你付出的成本只是多一轮对话，但获取的结果通常会更干净。
不过我要提醒一句，自检不等于完全可靠。它更多是一种概率上的质量提升，而不是绝对的正确性保障。关键数据仍然需要人为核验，尤其是涉及姓名、数字、引文这类硬事实的时候，不要偷懒。
3.4 技巧九：给你的模板加一个“可变区域”
做模板库的目的不是为了“一招吃遍天”，而是为了在稳定的结构上快速换血。真正可复用的模板，一定要留下一块自定义区。我把模板设计成三个部分：固定指令区、可变参数区、输出约束区。
举个例子，我的“会议纪要模板”长这样：
【固定指令区】 你是一名项目助理，请根据下面的会议记录生成结构化会议纪要。 【可变参数区】 - 参会方背景：{这里填项目背景} - 重点议题：{这里填本次会议主题} - 会议记录原文：{粘贴原文} 【输出约束区】 请按以下格式输出：会议结论、待办事项（含负责人和截止时间）、风险项、下次会议需确认的问题。 不输出任何与会议记录无关的内容。你每次使用时，只需要替换“可变参数区”里的内容，其他部分保持不动。这样做的最大好处是，你可以把常用的好Prompt沉淀成自己的个人资产，并且反复验证它在不同场景下的稳定性。很多人觉得写提示词是一次性的临时操作，其实不是。真正专业的玩法，是把高价值提示词持续积累、迭代，再回到模板库里。
3.5 技巧十：给Prompt做版本管理，像管代码一样管它
最后这个技巧可能听起来不像提示词技巧，但它救了我很多次。当你连续调试一个复杂提示词的时候，很容易出现这种情况：改着改着，效果反而退回去了。如果没有记录，你就只能凭记忆往回找，效率极低。
我的做法很简单：给每个重要提示词建立版本记录，记录版本号、修改时间、修改目的、前后效果对比。不需要专门用什么软件，一个表格或者一个Markdown文件就够了。把Prompt当作一份代码来维护，是很值得养成的习惯。
这里也涉及一个问题：怎么判断一个修改是“更好”还是“更差”？我的建议是，每次只修改一个变量。同时改三处，如果效果变好了，你根本不知道是哪处起了作用。但如果一次只改一处，你就能建立清晰的因果关系。这个习惯让我做模型应用时的试错成本降了一大半。
版本管理还有一个更深层的价值。当多个Prompt模板共用同一个核心逻辑时，改一次核心逻辑，你可能要同步更新五个模板。如果没有版本记录，大概率会漏改。有了版本记录，你至少能通过全局搜索找到所有相关模板，避免上下文中出现旧指令和新指令打架的情况。
4. 可以直接复制的10个模板库
这一节我把前面十个技巧沉淀成可以直接用的一套模板。每个模板都加了编号，方便你在自己的项目里引用。使用时重点替换“【 】”里的内容即可，不用从头开始写。
4.1 模板一：人物角色与写作风格模板
用途：写文章、写文案、生成社交媒体内容时统一风格。
你是【具体的职业身份】。你有【N】年从业经验，最擅长处理【具体领域】的问题。 你在表达时喜欢【风格1】和【风格2】，避免【负面风格】。 请针对【具体主题】写一段【篇幅】内容。 要求：开头用【具体切入方式】，每个观点都配【案例/数据/类比】，结尾落在【可执行的建议】。4.2 模板二：长文结构生成模板
用途：写博客、报告、方案之前的“搭骨架”环节。
请针对【主题】生成一份文章大纲。 要求： 1. 包含一个反直觉的核心观点； 2. 按“问题背景—根因分析—解决方案—实操步骤—风险提示”的结构展开； 3. 每个一级标题下至少有两个二级标题； 4. 总大纲控制在【N】个一级章节以内。4.3 模板三：数据解读与报告模板
用途：把一堆数据和事实，转化成决策者看得懂的结论。
下面是一组数据/事实材料：【粘贴内容】 请按以下方式输出： 1. 数据概览：三句话说清楚整体情况； 2. 关键发现：列出三个最重要的信号； 3. 风险提示：列出两个可能被忽略的隐患； 4. 行动建议：给出两个可直接落地的下一步动作。 注意：不要捏造数据，所有结论必须来自材料原文。4.4 模板四：学伴模式模板
用途：学习新知识时，用AI模拟对谈式教学。
你现在是一名【学科】老师，正在教一个【基础/进阶】水平的学生。 请先问我三个问题，判断我的真实水平，再根据我的回答定制讲解。 讲解时请遵守： 1. 每个概念先用一个日常类比解释； 2. 再给出一个实际案例； 3. 最后让我做一道题验证理解； 4. 如果我的回答有误，只提示方向，不要把答案直接告诉我。4.5 模板五：通用会议纪要模板
用途：会议记录转结构化纪要和待办清单。
请根据以下会议记录生成纪要：【粘贴内容】 输出格式： - 会议结论：用三句话总结； - 待办事项：列表形式，每一项包含【事项、负责人、截止时间】； - 风险项：如果原文中提到了风险，请原样摘录； - 下次议程：建议两个下次会议的讨论主题。4.6 模板六：翻译与本地化模板
用途：不只是翻译语言，还要翻译语气和文化语境。
请把以下内容翻译成【目标语言】：【内容】 要求： 1. 保留原文的语气，如果原文是口语化风格，译文也要口语化； 2. 专业术语用【目标文化】里习惯的说法，而不是直译； 3. 翻译完成后，请用一句中文解释你在哪些地方做了本地化调整。4.7 模板七：代码生成与评审模板
用途：生成代码、审查代码、解释代码时统一使用。
请完成以下编程任务：【任务描述】 约束： 1. 使用【语言/技术栈】； 2. 优先考虑可读性和边界条件处理； 3. 输出代码时需要附带注释，解释关键逻辑； 4. 最后列出一个可能出错的边界场景，并说明如何处理。4.8 模板八：邮件与工作沟通模板
用途：把零散的想法改写成适合不同对象的正式沟通内容。
我要给【对象身份】写一封关于【事项】的邮件，希望达到【目标】。 请帮我改写为正式版，要求： 1. 开头直接说明来意； 2. 在第二段补充背景和我的诉求； 3. 给收件人一个明确的行动选项； 4. 语气要友好但不卑微； 5. 总字数控制在【N】字以内。4.9 模板九：自我检查与纠错模板
用途：在生成完毕之后用于“二次打磨”。
以下是某模型的初稿：【粘贴内容】 请以挑剔的编辑视角审阅它，并输出： 1. 三个最大的问题：按严重程度排序； 2. 每个问题的具体修改建议； 3. 优化后的完整版本； 4. 用一句总结说明这次修改的核心变化。4.10 模板十：通用任务提示词工作台模板
用途：如果上面几个模板都不匹配，直接用这个万能底座。
背景：{描述任务发生的前置条件} 目标：{描述你希望达成的最终结果} 受众：{描述这份输出给谁看} 格式：{描述输出结构、排版、长度} 示例：{如果有，提供一个标准示例} 禁忌：{列出绝对不能出现的内容} 交付方式：{描述是否需要分步输出、是否需要附上思考过程}这个十号模板，其实就是前面说的“任务简报”结构。把它作为家庭底座，遇到新场景时先按这个结构写一遍，再针对具体需求做增删。十个技巧塞进一张模板表之后，你手里等于有了一把可以随时调用的扳手。
5. 最后说点实际的：把提示词调试当成产品迭代
前面讲了很多技巧和模板，但我想强调一点：真正应用时，别把它们当静止的配方，而要把它们当成需要持续迭代的产品。同一个模板，在不同版本的模型上，表现可能不一样；同一个任务，换一批上下文材料之后，也有可能失效。保持“上一版哪里不对、这一版改了什么、结果如何”的记录习惯，比背诵任何技巧都更重要。
我个人现在的工作流基本是这样的：先用第十号模板搭底座，把背景、目标、受众、格式写清楚；然后针对具体任务，从前面九个模板里找相似度最高的一个做替换；第一版跑通之后，再根据输出质量微调一两个约束条件；确认稳定之后，把相对通用的部分沉淀回模板库。整个过程大概只需要两三轮，而且改动都有记录，不会出现“也不知道哪一版更好”的情况。
还有一个常被忽略的点：提示词不要只在一个产品里验证。同样的写法，在不同的模型产品里表现可能不一样。你可以把同一段提示词放在两三个工具里各跑一次，看哪个适配性最好。这样做的好处是，你能分清“哪些表现是提示词带来的，哪些表现是模型底色带来的”，后续调整也就更有依据。
关于“上下文工程”和“提示词工程”的关系，我再多说一句：两者现在有交融的趋势，但对我们使用者来说，不需要纠结概念边界。你只要记住，模型生成质量约等于指令质量、上下文质量与模型能力的乘积。提示词工程管前两项，模型能力是你管不了的部分。把能管的部分做到位，就已经能把大多数人的平均输出水平拉开一大截。
文末再分享一个很小的习惯：我每次写完一个复杂提示词，都会把它复制到自己的备忘录里，用一句话标明“这个提示词解决什么问题”“在什么样的条件下稳定”。下次遇到相似问题时，先搜备忘录，再从头开始写。这个习惯帮我节省的时间，远超我花在学习任何高级技巧上的时间。模板库真正发挥威力，也是从你开始认真做记录那一刻开始的。
