提示词工程5步框架：从模糊需求到可复用系统

1. 为什么大多数人写提示词的方式从根上就错了

我见过太多人把提示词当成"咒语"来用。打开对话框，敲一句"帮我写个文案"，结果不满意，就换一句"你是一个资深文案专家，请帮我写个文案"，还是不满意，再换"请你扮演一位有20年经验的4A广告公司创意总监，用极具冲击力的语言帮我写一篇小红书爆款文案"——然后觉得好像好了一点，但又说不清为什么好。

这种"试错式"的提示词写法，本质上和买彩票没有区别。你每次都在赌，赌对了就复制下来当模板，赌错了就继续换措辞。问题是，你根本不知道它为什么对了，也不知道换个场景还能不能用。

我刚开始接触大模型的时候也是这样。2023年初那会儿，我花了整整两周时间，收集了上百个所谓的"神级提示词模板"，存在备忘录里，用的时候翻出来改一改。结果呢？大部分模板换个任务就废了。写代码的模板拿去写文案，出来的东西四不像；角色扮演的模板拿去问数据分析，模型开始编数据。

后来我才想明白一件事：提示词不是咒语，是工程。

咒语的特点是"念对了就灵"，工程的特点是"有输入、有处理、有输出、有反馈、有迭代"。你把提示词当咒语，就只能靠运气；你把提示词当工程，才能稳定复现结果。

这个认知转变，是我认为区分"会用AI"和"真正懂AI"的分水岭。而市面上90%以上的提示词教程，教你的都是"怎么念咒语"——给你一堆模板，让你去套。套得好算你运气好，套不好是你不会变通。

所以这篇文章要讲的，是一套完整的提示词工程框架。不是给你几个模板就完事，而是让你理解：一个高质量的提示词是怎么被"设计"出来的，它的每个部分承担什么功能，为什么这样组合有效，以及当效果不好的时候你应该调哪里。

这套框架我把它拆成5个步骤。每一步都有明确的输入和输出，你照着走一遍，就能把一个模糊的需求变成一套可复用、可迭代、可迁移的提示词系统。

注意：这篇文章假设你已经用过大模型，知道基本的对话交互方式。如果你还没用过，建议先随便找个大模型聊几句，感受一下它的基本能力边界，再回来看这篇。

2. 第一步：把"我想要什么"翻译成模型能理解的任务定义

2.1 大多数人卡在第一步：需求本身就是模糊的

我做过一个小范围的调查，问了身边30多个用AI辅助工作的朋友一个问题："你写提示词的时候，脑子里想的是什么？"

超过一半的人回答："我想的是'我要一个好东西'。"

这就是问题所在。"好东西"不是一个任务定义，它是一个期望。模型不知道你心里的"好"是什么标准——是字数多？是语气正式？是结构清晰？是创意炸裂？还是数据准确？

我举个例子。假设你想让模型帮你写一份周报。如果你输入"帮我写一份周报"，模型会给你一个通用模板：本周完成了什么、下周计划做什么、有什么问题。看起来很合理对吧？但如果你实际想要的是"用数据说话、突出业绩增长、语气积极但不浮夸、控制在300字以内、适合发给直属领导看"，那模型给你的东西就完全不能用。

任务定义的核心，是把你的"期望"翻译成"约束条件"。

期望是主观的、模糊的、存在于你脑子里的。约束条件是客观的、具体的、可以写出来的。提示词工程的第一步，就是完成这个翻译过程。

2.2 任务定义的三要素：动作、对象、约束

我总结了一个简单的公式，叫"任务定义三要素"：

动作 + 对象 + 约束 = 可执行的任务定义

• 动作：你要模型做什么？写、改、分析、总结、翻译、分类、生成、对比、评估……动词要精确。
• 对象：动作作用在什么内容上？一段文本、一组数据、一个概念、一个场景……
• 约束：输出的边界条件是什么？字数、格式、语气、受众、必须包含/排除的内容……

拿"帮我写个文案"这个模糊需求来拆：

你看，拆完之后，任务定义就从一个"期望"变成了一个"规格说明书"。模型拿到这个规格说明书，输出的东西大概率就是你想要的。

2.3 一个实操技巧：用"反向提问"逼自己把需求想清楚

但问题来了：很多时候你自己也不知道自己想要什么。你只知道"现在这个不对"，但说不清"什么才是对的"。

这时候我推荐一个方法：反向提问法。

具体操作是：先随便写一个粗糙的提示词，让模型生成一版结果。然后不要直接说"不好，重写"，而是问自己三个问题：

1. 这版结果里，哪个部分是我想要的？（保留）
2. 哪个部分是我不要的？（排除）
3. 如果让我改，我会改哪个词、哪句话、哪个结构？（具体化）

把这三个问题的答案写下来，你就得到了一组具体的约束条件。然后把这些约束条件加回提示词里，再生成一版。

这个方法我用了大半年，基本上两到三轮就能把一个模糊需求收敛到可用的提示词。比一开始就憋一个"完美提示词"效率高得多。

提示：不要指望一次就写出完美的任务定义。提示词工程是迭代的，第一版的任务定义粗糙一点没关系，关键是要有"根据输出反推约束"的意识。

2.4 任务定义阶段的常见坑

坑一：把背景信息当任务定义。比如"我们公司是做跨境电商的，最近在推一款新产品，市场部人手不够，我想用AI帮忙……"——这些都是背景，不是任务。模型不需要知道你的公司情况，它需要知道"你要它做什么"。

坑二：约束条件互相矛盾。比如"要详细，但不要超过100字"、"要专业，但要让小学生也能看懂"。这种矛盾会让模型无所适从，输出质量断崖式下降。

坑三：把"不要什么"当成主要约束。"不要写得像AI"、"不要太正式"、"不要用套话"——这些否定式约束模型很难执行，因为它不知道"不这样"应该"怎样"。更好的做法是给出正面示例："参考以下风格：……"

3. 第二步：给模型一个"身份坐标系"，而不是一个角色标签

3.1 "你是一个资深XX"为什么越来越不好用了

早期大家写提示词，特别喜欢加一句"你是一个资深的XX专家"。这招在2023年确实好用，因为那时候模型对角色指令很敏感，加个角色就能明显改变输出风格。

但现在你再加这句话，效果越来越弱了。为什么？因为模型变聪明了，它知道"资深专家"这个标签本身不包含任何具体信息。你说"你是一个资深文案"，和说"你是一个文案"，在模型看来差别不大——它不知道你这个"资深"体现在哪里，是更注重创意？更注重转化率？更注重品牌调性？

角色标签是名词，身份坐标系是参数。

角色标签告诉模型"你是谁"，身份坐标系告诉模型"你从哪个角度思考、优先考虑什么、用什么标准判断好坏"。

3.2 身份坐标系的四个维度

我一般从四个维度来构建身份坐标系：

维度一：专业领域。不是"文案专家"，而是"专注消费品行业的小红书内容创作者"。领域越具体，模型的输出越有针对性。

维度二：经验年限与阶段。不是"资深"，而是"有5年经验，经历过从0到1起号阶段，也操盘过百万粉账号"。这会影响模型对问题的判断角度——新手关注技巧，老手关注策略。

维度三：工作方法偏好。比如"习惯用A/B测试验证文案效果"、"倾向于先分析竞品再动笔"、"注重数据反馈而非个人审美"。这决定了模型在生成内容时的思考路径。

维度四：沟通风格。比如"说话直接，不喜欢绕弯子"、"喜欢用类比解释复杂概念"、"对模糊表述零容忍，会主动追问细节"。

把这四个维度组合起来，你就得到了一个立体的身份坐标系。比如：

你是一位专注消费品行业的小红书内容创作者，有5年经验，经历过从0到1起号和百万粉账号操盘两个阶段。你的工作习惯是先分析竞品笔记的互动数据，再决定内容方向。你说话直接，对模糊的需求会主动追问，不喜欢用"高端大气上档次"这类空泛词汇。

这段描述比"你是一个资深文案专家"长了十倍，但效果好不止十倍。因为它给了模型一个具体的"思考位置"。

3.3 身份坐标系和系统提示词的关系

如果你用的是API或者支持系统提示词的产品，身份坐标系应该放在系统提示词里。系统提示词相当于给模型设定了一个"默认人格"，后续所有对话都在这个框架下进行。

如果你用的是普通对话框，身份坐标系就放在第一轮对话的开头。后续对话中如果发现模型"跑偏"了，可以重新强调身份坐标系的某个维度。

这里有一个经验：身份坐标系不需要每次对话都重复。但如果对话轮次超过10轮，或者你切换了任务类型，建议重新锚定一次。因为长对话中模型的注意力会漂移，重新锚定能把它拉回来。

3.4 一个反直觉的发现：身份越具体，模型越"敢说"

我实测下来有一个很有意思的现象：当你给模型一个非常具体的身份坐标系时，它反而更愿意给出有观点的、甚至有点"冒犯"的建议。

比如你问"这个文案怎么写"，模型会给你一个四平八稳的模板。但如果你说"你是一个说话直接、对套话零容忍的文案老手"，模型可能会说："你这个产品卖点太普通了，0糖0卡现在满大街都是，建议换个角度，从'喝完之后嘴里不发酸'这个体感切入。"

后者明显更有价值。原因很简单：具体的身份坐标系给了模型"判断标准"，它知道在这个标准下什么是好的、什么是差的，所以敢下判断。

注意：身份坐标系不是越长越好。四个维度各写一两句就够了，写太多会稀释重点。关键是每个维度都要有具体信息，不要用空泛的形容词。

4. 第三步：用"结构化输入"替代"自然语言描述"

4.1 为什么你的提示词总是"漏信息"

很多人写提示词是线性的：先说背景，再说要求，再说格式，最后补一句"哦对了，还要注意……"。这种写法的问题在于，模型处理线性文本时，后面的信息会覆盖前面的，或者前面的信息会被后面的冲淡。

我做过一个测试：同一个任务，用线性描述和用结构化描述分别写提示词，让模型生成10次，然后对比输出质量。结构化描述的版本，输出一致性明显更高，而且很少遗漏约束条件。

结构化输入的核心，是把提示词从"一段话"变成"一张表"。

4.2 我常用的结构化提示词模板

我不喜欢那种特别复杂的模板，什么"角色-背景-任务-要求-示例-格式"六大块，写起来累，模型读起来也累。我一般用四个模块：

【任务】用一句话说清楚要做什么。 【输入】提供任务所需的原始材料。 【约束】列出必须遵守的规则，用编号。 【输出格式】明确输出的结构、长度、风格。

举个例子，假设我要让模型帮我分析一份用户反馈：

【任务】从以下用户反馈中提取核心问题，并按优先级排序。 【输入】 （粘贴用户反馈原文） 【约束】 1. 只提取产品功能相关的问题，忽略物流和客服态度问题。 2. 每个问题用一句话概括，不超过30字。 3. 按出现频次从高到低排序。 4. 如果某个问题只有1条反馈提到，标注"低频"。 【输出格式】 用表格输出，三列：问题描述、出现频次、优先级。

这个模板的好处是：模型不需要从一段话里"猜"你的意图，每个模块的信息都是独立的、明确的。你写的时候也轻松，不用考虑起承转合，填就完了。

4.3 结构化输入的三个关键细节

细节一：约束条件要编号。编号的约束模型更容易逐条执行。我试过用无序列表和编号列表分别写约束，编号列表的执行准确率明显更高。

细节二：输入材料要加分隔符。如果你在提示词里粘贴了一段原文，一定要用分隔符把它和指令隔开。常用的分隔符有：三个引号、三个减号、XML标签（如<input>...</input>）。不加分隔符的话，模型可能会把你的指令和原文混在一起理解。

细节三：输出格式要给示例。如果你对输出格式有严格要求，最好给一个示例。比如你要模型输出JSON，就给一个JSON示例；你要模型输出表格，就给一个表格示例。模型对示例的模仿能力远强于对文字描述的理解能力。

4.4 结构化输入在复杂任务中的优势

当任务涉及多个步骤、多个条件、多个输出时，结构化输入的优势会非常明显。

比如你要让模型帮你做一份竞品分析，涉及：收集信息、对比维度、得出结论、给出建议。如果用线性描述，你可能会写成："帮我分析一下这几个竞品，从价格、功能、用户评价几个方面对比，然后告诉我哪个更有优势，最后给点建议。"

模型拿到这段话，可能会漏掉某个维度，或者把结论和建议混在一起。

但如果你用结构化输入：

【任务】对以下3个竞品进行对比分析，并给出选型建议。 【输入】 竞品A：…… 竞品B：…… 竞品C：…… 【约束】 1. 对比维度：价格、核心功能、用户评价、适用场景。 2. 每个维度用一句话总结每个竞品的表现。 3. 结论部分明确指出哪个竞品在哪个场景下最优。 4. 建议部分给出2-3条具体行动建议。 【输出格式】 第一部分：对比表格（4行3列） 第二部分：结论（不超过100字） 第三部分：建议（编号列表）

这样模型就很难漏掉任何东西，因为每个部分都被明确框定了。

提示：结构化输入不是让你写得更长，而是让你写得更"清晰"。有时候结构化之后，提示词反而更短了，因为你去掉了那些模棱两可的过渡句。

5. 第四步：设计"输出契约"，让模型知道什么算合格

5.1 输出契约是什么

输出契约是我自己起的一个名字，指的是：你对模型输出结果的验收标准。

大多数人写提示词，只告诉模型"做什么"，不告诉模型"做到什么程度算好"。结果就是模型给你一个60分的东西，你觉得不行，但说不清哪里不行，只能笼统地说"再改改"。

输出契约的作用，就是把"好"这个模糊的标准，变成可检查的条目。

5.2 输出契约的四个维度

我一般从四个维度来定义输出契约：

维度一：内容完整性。必须包含哪些信息？比如"必须包含至少3个数据支撑"、"必须覆盖用户提到的所有问题"。

维度二：结构规范性。输出的组织形式是什么？比如"必须用三级标题"、"必须用表格呈现对比"、"每段不超过5行"。

维度三：语言风格。语气、用词、句式有什么要求？比如"避免使用'赋能''抓手'等词汇"、"每句话不超过40字"、"用主动语态"。

维度四：边界条件。什么情况下算不合格？比如"如果信息不足，必须明确说'信息不足'，不能编造"、"如果问题超出范围，必须拒绝回答"。

把这四个维度写清楚，模型就有了一个"自我检查清单"。它在生成内容的时候，会不自觉地按照这个清单来组织输出。

5.3 一个完整的输出契约示例

假设你要模型帮你写一份产品需求文档（PRD）的摘要：

【输出契约】 1. 内容完整性： - 必须包含产品目标、目标用户、核心功能、成功指标四个部分。 - 每个部分至少3句话。 - 如果原始材料中缺少某个部分，标注"待补充"。 2. 结构规范性： - 用四个二级标题分别对应四个部分。 - 每个部分用无序列表呈现要点。 - 全文不超过500字。 3. 语言风格： - 用陈述句，不用疑问句。 - 避免"大概""可能""也许"等模糊词汇。 - 技术术语首次出现时用括号加简短解释。 4. 边界条件： - 不编造原始材料中没有的数据。 - 如果某个部分的信息与另一个部分冲突，在末尾用"冲突提示"标注。

这个契约写完之后，你拿到模型的输出，就可以逐条检查。哪条没满足，就针对性地让模型改哪条。而不是笼统地说"再改改"。

5.4 输出契约和评估迭代的关系

输出契约不仅是给模型看的，也是给你自己看的。它让你在评估输出的时候有据可依，而不是凭感觉。

我自己的习惯是：每次写一个重要的提示词，都会先写输出契约，再写任务定义。因为输出契约会反过来影响任务定义——如果你发现输出契约里有一条"必须包含数据支撑"，但你的任务定义里没提供数据来源，那就说明任务定义需要补充。

输出契约是提示词工程的"验收标准"，没有它，迭代就是盲目的。

注意：输出契约不要写得太死。有些任务本身就需要模型发挥创造力，你把契约写得太细，反而会限制它的输出质量。一般来说，分析类、总结类、格式类任务适合详细的输出契约；创意类、头脑风暴类任务适合宽松的输出契约。

6. 第五步：建立"迭代回路"，把一次性提示词变成可复用系统

6.1 为什么你的提示词用完就废

大多数人写提示词是一次性的：遇到一个任务，写一个提示词，用完就扔。下次遇到类似任务，重新写一遍。这样做的结果是，你永远在重复劳动，而且每次的质量都不稳定。

提示词工程的最后一步，是把提示词从"一次性消耗品"变成"可复用资产"。

可复用资产的特点是：有版本、有注释、有适用场景说明、有迭代记录。

6.2 迭代回路的三个环节

我自己的迭代回路包括三个环节：记录、归因、抽象。

环节一：记录。每次用提示词，都记录三样东西：输入是什么、输出是什么、你满不满意。不用很复杂，一个简单的表格就行。

环节二：归因。当输出质量不满意时，不要笼统地说"不好"，而是定位到具体是哪个模块出了问题。是任务定义不清晰？是身份坐标系不对？是约束条件有矛盾？还是输出契约太宽松？

环节三：抽象。当一个提示词在某个任务上稳定输出高质量结果时，把它抽象成模板。抽象的方法是：把具体的任务内容替换成占位符，保留结构和约束。

比如"写周报"的提示词，抽象之后变成：

【任务】撰写一份{周期}工作汇报。 【输入】{本期完成事项}、{下期计划}、{遇到的问题}。 【约束】 1. 用数据量化成果，每个事项至少一个数字。 2. 问题部分必须附带解决方案。 3. 全文不超过{字数}字。 【输出格式】三个二级标题：本期成果、下期计划、问题与方案。

这个模板就可以复用到月报、季报、项目汇报等场景。

6.3 提示词版本管理的一个实用技巧

我不建议用复杂的版本管理工具，太重了。我的做法是：在提示词文件的开头加一个注释块，记录版本号和变更原因。

# 版本：v3 # 变更：增加了"必须包含数据"的约束，因为v2的输出太笼统。 # 适用场景：周报、月报、项目汇报。 # 已知问题：如果输入材料中没有数据，模型会编造，需要加"信息不足时标注"的约束。

这样你过几个月回头看，能快速知道这个提示词是怎么演化来的，为什么有这些约束。

6.4 从"提示词"到"提示词系统"

当你积累了一定数量的提示词模板之后，可以开始考虑把它们组织成一个系统。

我的做法是按任务类型分类：写作类、分析类、编程类、创意类、沟通类。每个类别下面有若干模板，模板之间可以组合。

比如"写一份产品发布文案"这个任务，可以拆成：分析类模板（分析目标用户和竞品）+ 创意类模板（生成文案角度）+ 写作类模板（撰写最终文案）。三个模板串联起来，就是一个简单的提示词系统。

这样做的好处是：你不需要为每个具体任务写一个全新的提示词，而是用已有的模块组合。效率更高，质量也更稳定。

提示：提示词系统的搭建不需要一步到位。先积累单个模板，用着用着自然会发现哪些模板可以组合、哪些可以复用。不要为了"系统化"而系统化。

7. 这套框架在实际场景中怎么跑：三个真实案例拆解

7.1 案例一：用框架写一份数据分析报告

原始需求："帮我分析一下这份销售数据。"

第一步：任务定义。

• 动作：分析并撰写报告
• 对象：一份包含月度销售额、产品类别、地区分布的Excel数据
• 约束：面向管理层，突出趋势和异常，不超过800字，附带3条行动建议

第二步：身份坐标系。

你是一位有8年经验的数据分析师，擅长从销售数据中发现业务问题。你的习惯是先看整体趋势，再看异常点，最后归因到具体业务动作。你说话直接，不堆砌术语，喜欢用"这意味着……"来连接数据和结论。

第三步：结构化输入。

【任务】分析以下销售数据，撰写一份面向管理层的分析报告。 【输入】（粘贴数据） 【约束】 1. 先总结整体趋势，再分析异常点。 2. 每个结论必须有数据支撑。 3. 行动建议要具体到可执行的动作。 【输出格式】趋势总结、异常分析、行动建议三个部分。

第四步：输出契约。

• 必须包含至少3个数据引用
• 异常分析部分必须指出可能的原因
• 行动建议不超过3条，每条不超过50字
• 如果数据不足以支撑某个结论，标注"数据不足"

第五步：迭代。第一版输出后，发现"异常分析"部分太笼统，归因不具体。于是在约束里加了一条："每个异常点必须给出至少2个可能原因，并说明哪个更可能。"第二版明显改善。

7.2 案例二：用框架生成一套小红书内容选题

原始需求："帮我想几个小红书选题。"

第一步：任务定义。

• 动作：生成选题
• 对象：一个主打"办公室养生"的账号
• 约束：面向25-30岁职场女性，选题要有话题性，能引发互动，每个选题附带一个切入角度

第二步：身份坐标系。

你是一位专注生活方式领域的小红书运营，操盘过3个从0到10万粉的账号。你的方法是先看近期热门话题，再结合账号定位找结合点。你注重选题的"互动潜力"，会优先选择那些能引发评论和收藏的选题。

第三步：结构化输入。

【任务】为"办公室养生"账号生成10个选题。 【输入】账号定位：面向25-30岁职场女性，主打"碎片时间养生"。 【约束】 1. 每个选题必须包含一个具体场景（如"下午三点犯困"）。 2. 选题要能引发互动（提问、投票、征集）。 3. 避免"多喝热水"这类老生常谈。 【输出格式】表格：选题、切入角度、互动设计。

第四步：输出契约。

• 10个选题场景不重复
• 每个选题的互动设计要具体（如"评论区征集你的提神方法"）
• 至少3个选题涉及"饮食"、3个涉及"运动"、3个涉及"心理"

第五步：迭代。第一版输出后，发现"心理"类选题偏少，而且互动设计比较雷同。于是在约束里加了"互动设计要多样化，不能全是提问"，并调整了输出契约的比例要求。

7.3 案例三：用框架辅助编程任务

原始需求："帮我写一个Python脚本处理Excel。"

第一步：任务定义。

• 动作：编写脚本
• 对象：合并多个Excel文件，去重，按日期排序
• 约束：用pandas，代码要有注释，处理异常情况

第二步：身份坐标系。

你是一位有6年经验的Python开发者，擅长数据处理。你的习惯是先确认数据格式和边界情况，再写代码。你注重代码的可读性和异常处理，不喜欢用过于复杂的写法。

第三步：结构化输入。

【任务】编写一个Python脚本，合并指定文件夹下的所有Excel文件。 【输入】文件夹路径：./data/，每个文件包含相同结构的表格。 【约束】 1. 用pandas读取所有.xlsx文件。 2. 合并后按"日期"列升序排列。 3. 去除完全重复的行。 4. 处理文件为空、列名不一致等异常情况。 5. 代码加中文注释。 【输出格式】完整可运行的Python代码，附带使用说明。

第四步：输出契约。

• 代码必须包含异常处理（try-except）
• 必须有至少3行注释解释关键步骤
• 必须说明依赖库和运行方式
• 如果遇到无法处理的情况，必须在注释中说明

第五步：迭代。第一版代码能跑，但没有处理"列名不一致"的情况。于是在约束里明确："如果不同文件的列名不一致，以第一个文件的列名为准，并打印警告信息。"第二版补充了这个逻辑。

8. 踩过的坑和绕过的弯：一些不太方便写在教程里的经验

8.1 提示词不是越长越好，但关键信息不能省

我有一段时间迷信"长提示词"，觉得写得越详细效果越好。结果写了一个800字的提示词，模型反而抓不住重点，输出质量还不如300字的版本。

后来我总结了一个原则：提示词的长度应该由任务的复杂度决定，而不是由你的表达欲决定。简单任务，三五行就够了；复杂任务，结构化写清楚就行。关键不是字数，而是每个字是否承载了有效信息。

8.2 模型说"我理解了"不代表它真的理解了

有时候你在提示词里写了一大堆约束，模型回复"好的，我理解了"，然后输出的东西完全不符合要求。这不是模型在骗你，而是它在长文本中丢失了部分约束。

我的应对方法是：把最重要的约束放在提示词的开头和结尾。模型对开头和结尾的注意力最强，中间部分容易被忽略。如果你有3条核心约束，第一条放开头，第三条放结尾，第二条放中间。

8.3 不同模型对同一提示词的反应差异很大

我同时用几个不同的大模型，发现同一个提示词在不同模型上的表现差异很明显。有的模型对角色指令敏感，有的模型对格式要求敏感，有的模型对示例模仿能力强。

所以我的建议是：不要指望一个提示词在所有模型上都好用。选定你常用的模型，针对它的特点调提示词。换模型的时候，重新调一遍。

8.4 提示词工程不是一劳永逸的

模型在迭代，你的任务在变化，提示词也需要持续更新。我自己的提示词库大概每两个月会做一次"体检"：把常用的提示词拿出来跑一遍，看看效果有没有下降，需不需要调整。

这不是浪费时间。一个维护良好的提示词库，能让你在大多数任务上节省80%的调试时间。

8.5 最后说一个心态问题

很多人学提示词工程，是想找到一个"万能模板"，一劳永逸地解决所有问题。这种心态本身就会让你失望。

提示词工程的本质，是把你对任务的理解，翻译成模型能执行的形式。你对任务理解得越深，提示词就写得越好。模型只是放大器，它放大的是你的思考质量。

所以，与其花时间收集模板，不如花时间想清楚：你到底要什么？你的验收标准是什么？什么情况下算合格？想清楚这些，提示词自然就写好了。