不知道你还记不记得第一次用大模型时的状态：满屏的字看得懂，但让它写一份你真正想要的东西，它却总是“答非所问”或者“一本正经地胡说八道”。很多人把这个归结为“AI笨”，但真实原因往往是你没有把它当做一个“能力很强但必须把话说清楚的同事”来沟通。这就是提示词工程（Prompt Engineering）存在的意义。
用大白话说，提示词工程就是“教AI听懂人话”的技术。它不涉及复杂的代码，也不需要你懂数学推导，它研究的是怎么设计输入给大模型的文本，让模型稳定、可预期地输出你想要的结果。这个技能几乎是所有大模型应用——写文档、做分析、生成代码、搭Agent、做知识库问答——的地基。不管你是产品经理、程序员、运营还是学生，只要你日常会用到ChatGPT、Claude这类工具，提示词工程就是你绕不开的必修课。
这篇文章我不打算给你罗列几十个“万能模板”让你背，而是想从底层逻辑出发，告诉你提示词为什么有效、怎么一步步写得更好、遇到翻车时怎么排查修复。看完你不需要记住每一个套路，但你会拥有自己设计提示词的能力。
1. 提示词工程的核心逻辑：先搞懂模型是怎么“读懂”你的
提示词工程之所以能被称得上“工程”，是因为它背后有一套可以重复验证的方法论，而不是开盲盒式地碰运气。想要系统掌握它，你得先理解大模型理解你指令的底层机制。
1.1 大模型的“阅读理解”是一个概率游戏
大模型本身并不“懂”人类的语义，它的工作方式是极其快速的模式匹配和概率预测。当它看到一句话时，它会根据训练中学到的海量文本规律，逐字逐句地预测接下来最有可能出现的token（你可以简单理解为片段或字词）。这个过程听起来很机械，但因为底层的参数量足够大、训练数据足够丰富，它在宏观上表现出了惊人的“语义理解能力”。
这带来的关键启发是：模型的输出质量，极大程度取决于你输入文本给它建立的“概率空间”。你给的上下文越具体、逻辑越清晰、限制越明确，模型就越容易被引导到正确的输出路径上。
我举个很直观的例子。如果你只是输入“写个方案”，模型内部被激活的概率分布是极其发散的——它可能写出年会策划、营销方案、产品方案、健身计划……任何方向都可以。但如果你输入“帮我写一份社区二手书店的线下活动推广方案，面向周围3公里的大学生，预算2000元，需要包含时间安排、物料清单和线上宣传话术”，模型的概率空间被迅速收窄，输出质量会得到肉眼可见的提升。
所以，提示词工程的第一步，永远是“信息增量”。在这个阶段，你不需要什么花哨的技巧，先把话说清楚、说完整。
1.2 从“对话”到“任务”：提示词的本质是任务描述
我见过很多人把提示词等同于“聊天话术”，这是一个理解的误区。聊天是开放式的、以互动为目标的；而提示词工程处理的大多是任务——你要模型生成一篇文章、抽取一段信息、改写一段代码、完成一次翻译。
当你把提示词的视角从“对话”切换到“任务”，你对它的编排方式就会发生根本改变。你会自然地开始关注：
- 任务的目标是什么（做什么）
- 任务的输入是什么（围绕什么做）
- 任务的约束是什么（不能做什么、必须做成什么样）
- 任务的输出格式是什么（交付物长什么样）
这四件事恰恰就是一条结构化提示词的核心骨架。与其去背那些动辄几百字的“神奇咒语”，不如把这四件事想明白，你的提示词就已经超过了80%的普通用户。
1.3 大模型的陷阱：它天生是“迎合者”
在学习提示词之前，你还需要建立一个重要的心理预期：大模型天生倾向于迎合用户。它不会主动指出你找它做的事不靠谱，更不会因为你没说清楚就反问你要什么。
它会顺着你的话往下接，即使你的要求是模糊的、矛盾的，它也会试着给你凑一个自洽的答案。这既是它强大的地方，也是它最坑人的地方。很多时候输出的质量差，不完全是模型能力不够，而是模型“发挥空间太大”。
这也是为什么我们需要“约束”和“示例”。一个优秀的提示词就像一个清晰的甲方brief，不给乙方（模型）留下自由发挥的余地。
2. 好提示词的结构拆解：五要素一个都不能少
我自己在带新人时，习惯把一条完整的提示词拆成五个要素：角色（Role）、任务（Task）、上下文（Context）、约束（Constraints）、格式（Format）。这五个词的首字母很好记，就像一个算是填空模板，你按照这个模板往里填内容，写出来的提示词就已经很能打了。
2.1 角色设定：先告诉AI它是什么
角色设定是提示词工程最容易见效也最容易被忽视的一环。“你现在是一名有10年经验的科技博客编辑”“你是一名严谨的数据库管理员”“你是一名擅长儿童绘本的插画师”，这些开场白式的句子，本质上是在为模型的输出“定调”。
角色描述不能是贴标签，越具体的角色，效果越好。因为角色描述中隐含了相应领域的表达方式、关注重点和禁忌。比如“你是一名有过多次手术室实战经验的外科医生”就明显优于“你是一名医生”，前者会让模型输出的内容更专业、更谨慎、更少废话。
需要注意的是，角色设定不是堆头衔，它需要配合任务描述来使用。如果一条提示词只写了角色没写任务，模型依然会懵；但有了角色，模型的表达方式会立刻切换。
2.2 动词优先：一句指令分清“主次”
写提示词时，指令动词决定了模型执行的动作。常见的指令动词有：写、总结、翻译、提取、改写、扩写、对比、规划、分类、评分、模拟、审查……选择的动词越精准，模型的输出就越贴合预期。
但实际操作中，我经常看到有人在一条提示词里混用多个动词，比如“帮我看看这篇文章的语法错误，然后总结一下中心思想，最后再给个修改后的版本”……这种多任务提示词不是说不能用，但模型会自行决定优先执行哪个、执行到什么程度。更推荐的做法是拆成连续的几条提示词逐一执行，或明确告诉它“按步骤完成：第一步……第二步……”。
单任务、单动词，永远是提示词执行可靠性的第一原则。
2.3 提供上下文：模型不知道你脑子里在想什么
上下文就是让模型“跟你在同一个频道上”的信息。举例子：你要它帮你写一封邮件，你不告诉它收件人是谁、你跟收件人的关系、你想传达的情绪，它写出来的东西就只能是四平八稳的“标准模板”，但可能完全不是你要的语气。
好的上下文输入应该包含：这个任务产生的背景、目标读者的画像、相关的前置材料（可能是一段文本、一批数据）、以及你希望模型知道的历史信息。上下文越充分，模型生成的个性化内容越强，套话感越少。
在实际工作中，“RAG（检索增强生成）”这类技术本质上也属于上下文的自动化补充，把知识库或数据库里检索到的相关信息嵌入提示词，让模型回答基于事实而不是凭记忆发挥。
2.4 约束条件：告诉AI哪些事情不能干
很多人的提示词只写了“要什么”，没有写“不要什么”。但模型恰恰需要“不要什么”来收窄概率空间。约束条件通常包括：
- 长度约束：如“控制在300字以内”“扩展至1500字左右”
- 风格约束：如“使用口语化风格”“避免专业术语”“语气幽默但不轻浮”
- 内容约束：如“不要编造数据，不确定的地方明确说不知道”“禁止提及价格”等
- 结构约束：如“必须包含小标题”“使用Markdown格式”“分点列出”
约束条件写得越具体，模型的输出可控性就越高。但如果约束写得太死太碎，也会让模型产生“不知道怎么执行”的混乱，甚至影响输出的流畅性。这就需要在实践中找到平衡，一次测试中先给核心约束，再按效果追加。
2.5 交付格式：输出是可以被“编程”的
在前四大要素之外，最容易被忽略的其实是输出格式的设计。模型是结构化的输出高手，只要你把想要的格式描述清楚，它可以完美地按JSON返回、画表格、生成代码块、按Markdown层级输出。
格式设定不只是为了好看，它直接影响了后续的自动化使用。比如你想用大模型批量提取文档中的合同信息，那你最好要求它按固定的JSON结构返回；如果你只是想快速浏览一篇文章，那Markdown小标题是最合适的交付格式。
提示：在格式要求中，能给出示例结构就一定要给示例结构。只说“输出JSON”远远不够，你应该直接给出这个JSON的字段样板，比如“{"公司名称": "", "合同金额": "", "签约日期": ""}”，模型会严格照做。
3. 进阶技巧实操：从能用到好用的四种技法
基础的五要素能让你写出一条“及格”的提示词，但想达到“高质量、可复用、跨场景”的水平，还需要掌握几个关键的进阶技法。
3.1 Few-shot（少样本示例）：用范例比用形容词更管用
如果你希望模型的输出遵循某种特定风格或特定结构，你几乎不可能用描述性的语言说清楚，最有效的方式是给它1到3个“输入-输出”的成对例子。这就是Few-shot的基本思路。
举个例子。你想让模型把一段口语化的用户反馈，改写为客服工单的正式描述。你说“请专业一点、正式一点”，效果是不可控的。但如果你给出：
输入：东西寄过来都压扁了，气死我了 输出：用户反馈外包装破损导致商品变形，表达较强不满情绪，建议优先联系用户致歉并安排补发。 输入：问客服半天没人理 输出：用户反馈咨询响应时间过长，无人工客服跟进，建议升级服务流程并今日内回访。看到这两个例子后，模型对“用户反馈转工单”的理解就不只是“正式”两个字，而是一套暗含的结构和用词习惯。它后续生成了第三条、第四条，风格都会无缝衔接。
Few-shot的本质是“用例子编程”。它是提升输出稳定性的最可靠手段之一。
3.2 Chain-of-Thought（思维链）：遇到复杂问题时让AI“先思考再回答”
大模型在不经过思考的情况下直接给答案，会在推理类问题上频频犯错。比如你直接让它答“33的平方根乘以2再加1是多少”，它可能在计算中间步骤出错。但如果你在提示词里加上一句“请先逐步推理，得出最终结论”，准确率会有明显提升。
思维链的原理，是把模型内部的隐式推理过程显式化，引导模型在回答之前先构建中间步骤。这就像要求一个人做题必须写步骤一样。你可以简单地在提示词末尾加上“请一步一步思考”，也可以更精细地要求它“先列出已知条件，再计算，最后给出结论”。
但在使用思维链时要注意一点：它只对需要推理的任务有效，如果让它做一个简单的事实问答或文案创作，思维链指令会让输出变得冗长繁琐，这时没必要过度使用。
3.3 结构化提示词模板：把零散指示固化成工作流
当一条提示词效果好、你在工作里反复使用它时，就应该把它固化成模板。模板不是让你把提示词写成一长段散文，而是拆成字段、按固定顺序组合。
一个可复用的提示词模板通常会这样组织：
# 角色 你是一名[角色描述] # 任务 请完成[具体任务] # 上下文 [相关背景/前置材料] # 要求 1. [约束1] 2. [约束2] # 输出格式 [交付格式说明/示例] # 示例 输入：... 输出：...用这种结构化的方式写提示词，有几大好处：
- 易于复用和维护，换场景只需要改“任务”和“上下文”。
- 模型对每个部分的执行更清晰，不会把“角色”和“任务”混在一起理解。
- 方便调试，哪个环节出了问题，直接定位到对应字段修改。
很多团队在做的“提示词库”“Agent提示词模板”本质上都是在做这件事——把优质的提示词沉淀成组织的知识资产。
3.4 温度参数：提示词之外的“隐藏按钮”
严格来说，温度（Temperature）参数不属于提示词文本本身，但在实际调用大模型API时，它和提示词是配套使用的。温度控制的是模型输出随机性的高低：温度越低，输出越保守、稳定、贴进概率最高值；温度越高，输出越发散、多样、有创造性。
实操中的匹配方案是：
- 做事实问答、代码生成、数据处理：温度调到0到0.3之间。
- 做文案创作、头脑风暴、聊天娱乐：温度调到0.7以上。
注意，如果你是通过网页版对话产品使用的，温度参数可能被埋在后台或者根本没有暴露给你。所以普通人能做的，是在提示词里加入“请保守回答”“请发挥创意”这类指令，间接影响模型的输出倾向。
4. 实操案例复盘：一个劣质提示词的进化全过程
光讲理论还是不够直观。下面我用一个真实复现过的场景来串一遍：从最初写出来的“劣质提示词”，到最终能稳定输出高质量内容的“成熟提示词”，你可以看到每一步优化背后的思路。
4.1 原始提问：为什么会得到一篇“废话”
假设我需要大模型帮我写一篇公众号文章，内容是介绍一款帮助整理笔记的软件。刚开始我是这么写的：
帮我写一篇关于笔记软件的文章，要显得专业一点。
在这个提示词下，模型大概率会输出一篇结构松散、信息量低、开头是“在当今快节奏的生活中”的万金油文章。为什么会这样？
因为我的输入里没有告诉模型：读者是谁、软件的核心卖点是什么、文章重点是功能还是场景、偏干货还是种草。模型只能用最通用的方式回答，通用就意味着平庸。
4.2 逐项补齐：从400字废话到可用的初稿
我先补齐了“上下文”和“任务边界”：
你是一名效率工具领域的资深博主。请帮我写一篇公众号风格的文章，介绍一款名为“某记”的笔记软件，目标读者是职场白领和大学生，他们抱怨过“笔记建了很多但从不回看”。 文章需要解释为什么传统笔记会变成“收藏夹吃灰”，并科普一种名为“渐进式总结”的笔记方法，顺便自然地带出“某记”如何支持这个方法。 字数控制在1200字左右，语言口语化，不堆术语，要像朋友聊天一样舒服。 文章结尾加一句引导读者留言区分享自己的笔记习惯。
稍微做一下信息增量，模型输出的文章已经有了清晰的主题和结构。但我发现它还是容易写得过于“广告腔”，对“渐进式总结”的讲解也不够通俗。于是我再加入一条约束：
不要使用“首先、其次、最后”这类过渡词；不要出现“高效”“强大”“赋能”这类词；请用具体的生活场景举例来解释概念，而不是描述概念本身。
这一步优化之后，文章的“人味”明显提升了。但我还发现一个细节：模型在介绍软件功能时，容易出现“编造功能”的倾向。对于真实产品来说这是致命的。最终我加上了这样的“红线约束”：
你无法确定是否存在某个功能，面向用户可以通过截图确认，所以凡是涉及“某记”具体功能特性和价格信息的内容，一律用“这里以实际版本为准”代替。
4.3 迭代方法论：一次测试、一次修改、一次回归
从上面这个案例可以看出，提示词的优化不是一个“一步到位”的过程，它是一个快速迭代的循环。我自己实操时遵循的流程是：
- 先草拟一个“说得过去”的提示词。
- 跑一次，输出结果贴到文档里。
- 逐句标出哪里不符合预期（太笼统、有编造、语气不对、结构不对）。
- 针对这些不符合项，回到提示词加约束或换描述。
- 重新跑，对比前后的差异。
- 直到输出“连续两次稳定达标”，就把提示词存为模板。
这套流程看起来慢，但它是建立“提示词手感”的最快路径。你做的每一次修改，本质上都提升了一次你与模型之间“沟通的带宽”。
5. 日常高频场景的提示词速查实践
了解了方法论，再给大家一些可以直接拿去改的场景化示例。这三个场景是大家在学习和工作中使用大模型时最高频的，覆盖了写作、信息处理和编码三大类别。我不是让你背模板，而是看我在实战中怎么做取舍。
5.1 文案写作场景：从“帮我写”到“帮我按架构写”
写作类提示词最容易犯的毛病是：“帮我写一份产品介绍文案”“帮我写个自我介绍”。这类“大而全”的指令让模型无从下手，它只能给你套话堆砌。
我自己的写作类提示词会倾向于先定“文章架构”，再要求模型“往架子里填肉”。
你是一名公众号编辑，擅长写“干货型”文章。请按以下提纲为我写一篇文章： 一、用场景故事引入（目标读者是谁、痛点是什么） 二、问题剖析（为什么旧的解决方法无效） 三、引出新方案（方法的核心原则，配一个案例） 四、执行步骤拆解（3-5步，每步配注意事项） 五、结尾互动引导 全文1800字左右，语言要求像朋友交谈，禁止使用“赋能”“抓手”等词。这个提示词的巧妙之处在于，它把“结构控制权”握在了人手里，而把“文笔发挥权”留给了模型。这样既保证了文章骨架符合发布平台的调性，又让模型发挥出了它长句和过渡方面的优势。
5.2 信息提取场景：让AI当你的“结构化阅读器”
在处理长文档、抓取关键信息时，提示词工程的价值会体现得极其充分。很多工作里的“找数据”“比对资料”场景，本质上是信息提取。
我分享一个适用于“合同关键信息提取”的提示词骨架：
请阅读以下合同文本，提取以下字段并严格按JSON格式返回： { "合同名称": "", "甲乙双方": {"甲方": "", "乙方": ""}, "合同金额": {"币种": "", "金额数字": "", "大小写": ""}, "签署日期": "", "履行期限": {"开始": "", "结束": ""}, "违约条款摘要": "", "争议解决方式": "" } 要求： 1. 所有字段必须基于原文事实填写。 2. 原文未体现的字段，填写“未提及”，严禁推测。 3. 金额需括注币种，日期格式统一为YYYY-MM-DD。 文本内容如下： <这里是粘贴的合同文本>这里有两个要点值得注意。第一点是“原文未提及的字段，填未提及”这个约束非常关键，它把模型的幻觉直接扼杀在摇篮里；第二点是JSON的结构定义，必须连字段层级都定义清楚，模型才能稳定输出。
对信息提取来说，通常会把temperature设为0，让每一次提取结果尽量一致，这是API调用层面的专业操作。
5.3 编程辅助场景：给AI一个“最小可运行”的任务
程序员用大模型写代码时，最常见的翻车是“提示词里只描述目标，不给运行环境”。比如你说“用Python写个爬虫抓京东商品”，模型是能写出代码，但大概率会引入你没有的依赖库、没有处理登录态、没有异常处理，甚至用了一些你没接触过的框架。
高效的做法是给它“最小任务信息”，并且要求它附带解释。比如：
我需要一段Python代码，实现以下功能： 1. 输入：一个包含URL列表的CSV文件（路径为input.csv，列名为url）。 2. 对每个URL发起HTTP GET请求，设置超时为10秒。 3. 提取网页标题和Meta Description。 4. 将结果输出到output.csv，包含url、title、description三列。 5. 如果请求失败，在description列记录错误信息。 6. 只允许使用requests和beautifulsoup4这两个库，并给出安装命令。 7. 代码需要可直接运行，请在关键逻辑处添加注释。写清输入、输出、参数、依赖、错误处理，模型生成的代码不光是能跑的，而且是能落到实际流程里的。很多程序员朋友觉得自己“提示词写得很清楚”，其实只写了目标和输出，输入格式、环境依赖、异常分支全是模糊地带，这必然导致代码可用性差。
6. 提示词翻车现场：典型问题与排查思路
提示词写多了之后你就会发现，每次翻车的原因大多是相似的。我整理了几个最高频的故障模式，并且把排查思路也一并写出来，方便你自己定位。
6.1 模型“幻觉”严重：输出看似合理，实则伪造事实
这是大模型使用中最危险的问题。尤其是当任务涉及具体数据、法规、新闻事件、个人信息时，模型可能一本正经地给出完全虚构的答案。排查思路是：
- 先检查你的提示词里有没有给出“事实依据”。如果你不给原文，模型就只能靠记忆或推测来回答。
- 如果在提取或总结场景，强制加上“所有内容必须基于原文，原文未提及的就是未提及”。
- 如果在知识问答场景，你要清楚地告诉它“不确定时就说明不确定”，并且把温度参数调低。
更进一步，对于信息准确度要求极高的任务，不要单纯依赖大模型的“记忆”，应该配合RAG或联网搜索来补全事实。
6.2 输出太平庸：全是“正确的废话”
模型输出的内容挑不出毛病，但没有任何亮点，味同嚼蜡。这种情况多半是真的“信息不足”。排查思路是：
- 确认自己的提示词里是否只有“需求”，没有“素材”。写文章时有没有给出好句子作为风格参考？写方案时有没有给出行业背景？
- 尝试加入一两个“反常识约束”，比如“开头不能使用‘随着’句式”“论点必须包含一个生活化类比”，这类要求会强迫模型偏离它默认的安全表达路径。
- 利用Few-shot示例。平庸的基本原因就是模型没有参照，直接给它一个你心中“有亮点”的样例，它会立刻有样学样。
6.3 输出不遵守格式：我要JSON它给Markdown
遇到这种问题，第一个排查点是你的格式描述是否足够明确。你只是写了“输出JSON”，模型理解你“意图”的空间就很大；你必须给出确切的字段结构，否则它认为自己输出一个JSON数组也算JSON。
第二个排查点是不要让格式要求“淹没”在长文本里。我见过不少人把格式要求埋在提示词的中后段，模型前段精力被大量上下文稀释，输出时根本没有注意到你的格式指令。更好的做法是：把格式要求单独放在“输出格式”这一节，并在提示词末尾重复一遍。
第三个排查点是，如果多次尝试仍然格式不对，直接把你的期望结果放进Few-shot示例里，模型会看一遍就会做了。
6.4 多轮对话中“忘记前文”：上下文过长导致的记忆错乱
长对话场景下，模型会在某个节点突然“忘记”你最开始说过的话。这并不是模型故意使坏，而是受限于上下文长度，或你在中途产生了大量无关对话信息，把早期重要信息挤出了注意力窗口。
排查思路是：在关键任务出现前，把你需要它记住的信息重新完整写一遍。与其寄希望于它记住你3小时前说过的那句话，不如每次给它“现场复习”。在构建Agent或多步骤工作流时，更推荐“让模型只专注当前这一步任务”，用代码保存和传递必要信息，而不是全塞进对话里。
6.5 提示词过长导致执行错乱
有一类朋友比较极端，在了解了五要素和进阶技巧之后，把提示词写成了一篇5000字的说明书，把所有可能性都写成规则。这样做的结果是：模型执行的准确率反而下降。
原因是模型需要同时“遵守的约束”越多，就越容易出现约束之间的冲突或遗忘。更合理的做法是：把长任务拆分成短任务，分步去做。比如一篇复杂调研报告，就不要让模型一次生成完，而是先让它列大纲、再分章节扩写、最后统一风格润色。每一步提示词短而聚焦，输出质量一定会更好。
7. 提示词工程也需要工作流管理
最后说说提示词进入实际工作流之后的事。这不是面向纯玩票用户的，但如果你想靠大模型提效，一定会走到这一步。
7.1 建立一个“提示词版本库”并持续维护
每一版优化过的提示词，都应该按“场景-版本-更新时间”命名存好。我自己习惯用表格维护一条记录：场景名称、适用模型、提示词全文、调用参数（温度等）、备注（适合在什么情况下用、容易出现什么问题）。
这个版本库的价值在于：当大模型版本更新后，同一批提示词的效果往往会变化。如果你没有版本记录，就只能在原地反复试错，无法跟踪到底是模型变了还是提示词变了。而一旦有版本库，升级新模型时直接跑一遍回归测试，哪条提示词退化了一目了然。
7.2 批量测试与回归：把提示词当代码对待
在偏工程化的场景里，我会强调对提示词做批量验证。比如一个信息抽取提示词，不要因为它在10条样本上效果不错就认为它稳定。你可以准备50条测试数据，手工标注结果，再用脚本调用模型跑批量预测，对比准确率。
我把这种思路称之为“把提示词当代码对待”。哪怕你是非程序员，也应该养成这个习惯：每次改提示词时，保存上一个版本；每次正式上线前，用固定的验证集测一遍。这种方法论会让你从“碰运气选手”进化成“稳定输出选手”。
7.3 新手学习路径：三阶段稳步进阶
很多刚接触提示词工程的朋友会问：我该从什么开始学？我给的建议是三阶段：
第一个阶段，先把基础五要素用好，找到50个自己工作和生活中反复出现的场景，用五要素写50条提示词并不断优化。这一步是建立基本功。
第二个阶段，研究高手写的提示词，去拆解它们为什么这么设计、有哪些约束在起作用、哪些信息是预先要做筛选的。拆解时把自己的理解记录下来。
第三个阶段，大量实践少样本（Few-shot）和思维链，并且尝试把提示词接入自动化脚本，比如调用API批量处理文件。到这个阶段，你不再需要看任何教程，因为你已经形成了自己的方法论。
我个人在实际操作中最深的体会是：提示词工程从来没有“最优解”，只有“当前场景下的更优解”。同一个任务，换了模型、换了数据、换了目标用户，提示词可能就要跟着调整。它更像是一门手艺，而不是一门科学。多练，多反思，多对比，你的“手感”自然就出来了。
最后再分享一个小技巧：你每次得到一条满意的提示词，不要急着用到爽，试着主动把它变差一次——删掉一个关键约束或者模糊掉一个角色的设定，看看输出会怎么变。这个“反向实验”会让你更深刻地理解提示词的每一个设计元素到底在起什么作用，比看一百篇文章都管用。
