简介《AI引擎Prompt指令设计绿皮书》是一份面向ChatGPT、Claude、Bard等主流AI工具的Prompt设计指南适合内容运营、职场办公及个人学习等场景使用。书中先讲解指令写作的七个技巧公式包括明确定义需求、提供足够上下文、使用简单直白的语言、详细说明输出要求、举例示范、添加限制条件以及多次迭代优化再按应用场景整理出新媒体运营、简历写作、求职面试、个人发展四大模块并给出小红书笔记万能指令、短视频开头写作指令等可直接套用的现成模板方便举一反三。整份资源以PDF形式提供共1个文件体积3.64MB附带完整目录和更新日志便于按章节快速查阅。目前已有6677人浏览学习适合内容创作者、职场人士以及对AI工具感兴趣的入门和进阶用户作为Prompt设计参考手册帮助摆脱低质量回复、提升AI输出的一致性与可用性。1. AI引擎的油门在用户手里Prompt指令设计到底是什么长期做AI应用落地的人慢慢会对一种现象脱敏同样的模型、同样的算力、同样的数据管道有的团队交付出来的对话体验像丝滑的助理有的却像喋喋不休的复读机。差别往往不在模型而在往AI引擎里喂的那段指令。Prompt指令设计就是研究“怎么把需求翻译成模型能严格执行的语言”的那套方法。它不是让模型更聪明而是让用户手里那个油门更能发挥引擎本身的动力。适合正在搭RAG、做自动化、写客服机器人和做内容生成工具的人。这篇笔记我把实际项目里验证过的模板、参数、翻车记录一次讲透。2. 指令设计的地基角色、任务、格式三要素Prompt工程师从零开始设计指令第一件事不是堆砌技巧而是把指令拆成三个可管理的问题模型以什么身份回答、它到底要完成什么动作、输出长成什么样子。这三块决定了模型生成时的落点。把这三件事写清楚后面再加few-shot、思维链才是在同一个地基上盖楼。2.1 角色设定让模型知道自己是谁角色不是装饰。给模型一个角色说明等于给它划定一个知识调用范围和语言风格范围。比如“你是一名资深运维工程师”和“你是一个友好的客服”背后的用词密度、专业缩写比例和语气收敛程度完全不同。常见的一个坑是角色写得过于宽泛例如“你是一个数据库专家”这样的设定对模型约束力很弱。我一般会把角色说明写成一段两行内的句子带上岗位、服务对象和不做什么。一个我常用的写法是你是一名有十年经验的数据库运维工程师负责回答开发者的数据库性能问题。 你的回答要直接给结论然后解释原因不输出任何与问题无关的寒暄。这里的逻辑是第一个句号前定义了身份第一个句号后定义了交流风格。模型在生成时会把“工程师”和“直接给结论”作为顶层约束而不是等到内容生成完再过滤。如果你只写了岗位没写交流风格模型往往会按训练数据里的平均对话习惯输出语气飘忽不定。角色设定的另一个作用是压缩上下文。好的角色说明本身就在告诉模型“哪些知识不用反复引用”比如设定成“资深运维”模型就不需要再解释什么是索引、什么是锁等待。这个压缩在长会话里尤其值钱因为token预算会直接影响成本。反过来角色设定别堆太多形容词。“你是最厉害的、无人能及的文案大师”这类措辞模型不会更努力只会把输出淹没在浮夸词里。从实测表现看角色这一栏在Prompt里占的token权重不高影响却很直接。同一个任务切换成“严谨的审计师”和“开朗的培训讲师”输出里出现数字精确度和语气词量的差异非常明显。这意味着角色设定是一个典型的低成本高杠杆旋钮值得在每条业务Prompt里单独留一个位置。2.2 任务描述把模糊需求压成明确动词任务描述是最容易被写废的部分。很多人把任务写成一个名词短语比如“生成一段产品介绍”“写一个关于云计算的说明”这等于把选材和侧重点全权交给模型。模型在预测下一个词时没有动词就没有强制的行为区间。我在实际项目中总结出一个任务描述公式任务 动作 对象 约束条件。动作尽量用“列出、对比、解释、重写、翻译、总结”这类有明确输出的动词对象写具体的材料或数据约束条件写长度、风格、立场、输出的边界。这里有一个容易被忽略的细节约束条件是给模型的行为限制不是给模型的目标。比如“不要超过80字”是行为限制“写得有吸引力”是目标两者要分开写否则模型容易在追求吸引力时牺牲长度约束。一个示例请对比“MySQL 8.0”和“PostgreSQL 15”在以下维度上的表现 1. 事务隔离级别 2. 分区表维护成本 3. 高可用方案成熟度 输出成一个三列的对比表格每行一个维度每列不超过 80 字。注意这里的动作是“对比”对象是两个具体数据库维度列表直接给出。对比这个动作如果没有维度模型通常会自己发明四个维度其中至少一个不是用户关心的。这种“动作对象约束”的结构还有一个好处后续调参时你能一眼看出是哪一处约束没生效。当任务本身比较复杂时我还会在动作描述里加上“先…再…最后…”这种顺序连接词。这相当于给模型一个临时的程序计数器防止它在一次生成本里突然跳到结论。比如先抽取关键词再分类最后生成摘要这种流程化描述比一句“给我做个完整分析”稳定得多。顺序词不要超过三个超过之后模型没法在生成本中维护太长的状态机效果反而下降。任务描述里还有一个容易踩的坑把context和task混在一起。比如“根据用户买的商品生成感谢信该商品是跑步机用户姓王”这里的“跑步机”是背景“写感谢信”是任务。如果混成一句模型偶尔会把“跑步机”当作主题来发挥反而忘了写信。正确做法是背景放在前面一句任务动词另起一句。2.3 输出格式用结构约束取代口头要求输出格式是Prompt设计里性价比最高的部分。同样一个任务口头说“请以列表形式输出”模型给出的格式可能千奇百怪直接给一个JSON结构模型就会严格按结构来。原因是模型对标记语言和代码块的结构敏感度远高于自然语言描述。一个我在生产环境验证过的格式约束{ summary: 一段不超过50字的概括, points: [观点1, 观点2, 观点3], risk_level: low|medium|high }配合的指令是“严格按照上述JSON结构输出不要输出其他文字。如果无法判断risk_level字段输出unknown。”模型见到这样一个明确的schema生成时的词汇候选空间会被压到很小。相比自然语言里的“请输出JSON”这个方案把JSON样例放到了指令里模型更容易对齐。格式约束最容易出的问题是不给兜底。如果我让模型判断风险等级却没定义“无法判断时怎么办”模型会硬选一个等级这比给不出答案更麻烦。所以我在格式模板里永远留一个“unknown”或“无”的合法值。另外输出格式要在整个指令里只定义一次不要前面定义了JSON后面又加一句“也可以输出表格”这种模棱两可会让模型失去对齐依据。关于格式载体我目前的排序是结构化数据类任务优先JSON阅读类任务优先Markdown交互类任务优先纯文本。JSON适合被程序解析Markdown适合带层级的长文纯文本适合聊天场景。这个选择也决定了后续下游程序解析的复杂度。如果你在做一个RAG系统输出格式选错后面的解析脚本就要跟着返工这是Prompt设计里不多见的可以提前止损的决策点。3. 从零跑通一个可用Prompt最小模板与两种主流程前面讲清楚了三个地基支点这一章直接给能抄作业的东西。工作里最常见的诉求不是设计一条完美Prompt而是用最小的改动让一条指令从“能用”变成“稳定”。我把它拆成一个最小模板和两种主流程。3.1 五段式最小模板一条提示词覆盖大部分场景我日常项目的起点基本是一个五段式结构角色、背景、任务、格式、边界。这五段在Prompt里按顺序排列每段用一行分隔。prompt f角色你是{role}负责{service}。 背景当前环境是{context}用户的问题是{user_query}。 任务请完成以下{action}必须包括{required_items}。 格式用Markdown输出使用列表和加粗。 边界不要输出与问题无关的内容不要推测数据来源。这段代码里{role}和{context}这些占位符在程序里会被业务数据动态填充。五段式的核心在于把不同信息类型放在不同段落里模型在解析时会把“背景”里的信息当作约束而不是当作任务本身。如果你把背景和任务混在一起写模型偶尔会把背景内容当作要执行的动作就会跑偏。参数说明上role、service、context、action、required_items是五个必填位。role和action前面说过了context是给模型的参考材料比如用户日志、商品信息、工单内容required_items是最低限度的需求清单宁可少列不要多列列得太多模型会在次要项上浪费表达空间。service这个字段我单独拿出来是因为很多人会把服务和背景搞混。服务描述的是“你在这个任务里提供什么价值”比如“负责给开发者的数据库问题给出诊断结论”背景是“当前环境是什么”两者承担的约束作用不同。关于边界这一栏最好的写法是“不要做什么”而不是“要做什么”。模型对否定指令的敏感度其实不低但前提是它要放在Prompt的后半段。如果放在开头模型读完就忘了放在格式之后作为收尾强调遵守率会明显上升。如果你发现模型经常输出了一堆废话就检查一下边界里有没有明确列出禁止项。3.2 单轮直给流程适合一次性生成场景单轮直给适用于每次请求都是独立任务、不需要记住前文的场景。比如批量生成商品描述、给每条工单写回复草稿、把一段会议记录转成待办事项。这种场景下Prompt应该做成一个纯函数即输入进去的材料和约束决定输出不依赖任何历史状态。def generate_product_desc(product_info: dict) - str: prompt f 角色你是电商文案编辑擅长提炼产品卖点。 背景产品信息如下{product_info} 任务写一段面向年轻消费者的商品描述突出实用性和性价比。 格式三段式每段不超过60字第三段以“适合”开头。 边界不要编造产品参数。 response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.3, max_tokens300 ) return response.choices[0].message.content逻辑说明这个函数把业务数据通过product_info注入Prompttemperature设成0.3是为了让输出在“稳定”和“自然”之间取平衡。如果设成0描述会偏干瘪设成0.7以上卖点会飘。max_tokens设300和“三段式每段不超过60字”是对应的留出约30%的余量以防格式换行挤占token。单轮直给场景里有一个常见翻车点在Prompt里写“记住你是电商文案编辑”这句话没任何意义因为模型不保留上一次请求的状态。每次调用都是重新开始所以角色、背景、任务、格式、边界五段必须在一个Prompt里写全。这也是为什么我坚持把单轮Prompt写成纯函数。批量调用单轮Prompt时有一个隐藏性能点不要每次调用都重复组装Prompt字符串。把静态部分比如角色和格式定义放在外层常量只拼接动态部分能省下不少token。虽然单次省的量不起眼但一天跑几十万次调用时这个优化直接体现在账单上。我见过有团队在prompt上反复做字符串拼接每次多出几百个重复token月底账单多了一截还以为是模型调贵了。3.3 多轮迭代流程适合复杂任务复杂任务比如“先分析文本再生成摘要最后把摘要翻译成英文并在翻译中保留术语一致性”这种单轮Prompt也可以写但一旦用户中途追加需求完全重写Prompt比继续追加历史消息要昂贵得多。多轮迭代流程更适合这类需要逐步逼近的场景。messages [ {role: system, content: system_prompt}, {role: user, content: 第一轮请找出下面这篇文本里的所有产品名和型号 text}, {role: assistant, content: assistant_result_1}, {role: user, content: 第二轮基于上面识别出的实体生成一个摘要不能引入外部知识。}, {role: assistant, content: assistant_result_2}, {role: user, content: 第三轮将摘要翻译成英文保持术语一致输出成表格。}, ]逻辑说明三轮对话把一个大任务拆成了“识别-生成-翻译”三个阶段每一轮拿到的上下文比单轮里一次性塞入任务描述要短模型在每一阶段的注意力更集中。这里有一个很重要的坑多轮迭代中assistant的历史输出会被当作下一次推理的上下文所以中间轮次的Prompt一定要写“只输出结果不要解释过程”否则历史里的废话会被写进下一次请求污染上下文。多轮流程相对单轮的代价是token消耗高。如果任务可以一次并行处理没必要硬上多轮。我一般根据两个信号判断要不要用多轮一是任务是否能拆成顺序依赖的步骤二是用户的反馈是否有“保留上一轮结果再改局部”的需求。两者任一满足多轮更划算。多轮里还要注意system prompt的处理。系统指令在每一轮都会生效而不是只在第一轮生效所以不要把一次性的信息塞进system prompt。比如“本次对话要分析的文件是xxx”应该放在第一轮user消息里而“你是翻译助手输出必须是英文表格”这种长期约束才放system。放反了的话后续追加的轮次里模型会迷失方向。4. 参数与指令的协作temperature、top_p、max_tokens怎么调提示词不是唯一的控制变量。同样的Prompt换一组采样参数输出质量会有肉眼可见的波动。这一章把工程师最常揪住的三个旋钮讲透并且说明它们和Prompt之间的协作关系。很多人调参失败是因为只碰参数不回头改Prompt这个习惯要先纠正。4.1 temperature随机性的刻度盘temperature控制的是采样时对低概率词的偏好程度。数值越低模型越倾向于选择概率最高的词输出越确定数值越高低概率词被选中的机会越大输出越发散。默认值通常落在0.7到1.0之间但业务场景里我很少直接用默认值。分类、抽取、格式转换这类任务我会把temperature压到0.1到0.3之间。文案创作、头脑风暴、广告语生成这类任务我会放到0.7到0.9。这里有个反直觉的现象temperature设成0并不完全等同于确定性因为模型后端可能还有top_k和重复惩罚等其他采样逻辑参与。temperature和Prompt的关系我习惯这样理解Prompt负责框定“输出空间”temperature负责在这个空间里做探索。如果模型在较低温度下的输出仍然不对说明Prompt的约束没写到位这时候加温度是雪上加霜。我在项目里常用的调参顺序是先固定temperature在0.3把Prompt调到稳定再按任务特点上下浮动温度。任务类型temperature 建议top_p 建议适用场景说明抽取、分类、格式化0.1 - 0.30.7 - 0.9事实要准确格式要稳定摘要、翻译、改写0.3 - 0.50.9需要一定自然度但不能天马行空营销文案、创意写作0.7 - 0.90.9冒险多一点允许低频词出现这张表不是绝对标准更像是我做项目时的参考基线。具体的数值会因模型而变同样的temperature在不同代际的模型上输出发散程度可能不同。所以表格里给了范围没给死值。4.2 top_p核采样的截断策略top_p是另一个采样旋钮控制模型在生成时只考虑累积概率达到p的候选词集合。比如top_p0.9意味着模型只在概率排名前90%的候选词里采样。它和temperature一样作用于输出的随机性但机制不同。temperature改变的是概率分布的“形状”top_p改变的是候选集合的“范围”。实操中这两个参数可以配合也可以各管一个。主流服务商一般不建议同时大改两个参数典型做法是改一个。我个人的习惯是用temperature做主要随机性控制top_p固定为0.9作为安全网。如果模型在temperature较低时输出内容还是太杂我会把top_p下调到0.8缩小候选词集合。top_p和Prompt协同的关键点在于约束密度。当Prompt里已经有明确格式约束时top_p高一点也不会太危险因为模型被JSON结构框死了可当Prompt比较宽松时top_p就是最后的刹车。反过来如果输出过于呆板不是只调top_p就能救回来的回到Prompt里增加“用口语化表达”这一条约束往往更直接。4.3 max_tokens给输出留够空间max_tokens是模型生成的最大token数。这个参数表面看只是长度限制实际上它和输出完整性强相关。如果设得太小模型在生成过程中被硬截断经常出现半句话、半张表、没闭合的JSON括号。如果设得太大浪费算力和等待时间成本也要翻。一个经验值是按预期输出字符数的1.5到2倍来估计token上限。中文场景里一个token大约相当于0.6到0.8个汉字英文大约0.75个单词。比如你希望输出300字的商品描述max_tokens设300到400比较稳。注意这个估算只覆盖正文如果输出里还有Markdown符号、JSON键名、换行符都会占token。max_tokens还有一个容易被忽略的副作用它影响模型对“完整回答”的决策。如果剩余token额度明显不足模型会倾向提前收尾。所以在设计Prompt时别在任务描述里要求“输出长篇大论”同时把max_tokens调小这等于给模型一个自相矛盾的目标。token额度要给足但也不能给到完全无限制因为在长输出里模型更容易累积重复。4.4 一套可复制的参数调优封装流程把三个旋钮组合起来常规做法是写一个小函数固定一个Prompt快速跑几组参数看差异。我一般会这样封装def run_with_params(prompt, temp0.3, top_p0.9, max_tokens500, times5): outputs [] for i in range(times): resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperaturetemp, top_ptop_p, max_tokensmax_tokens ) outputs.append(resp.choices[0].message.content) return outputs这个函数做的事情很简单同一段Prompt用同一组参数跑5次返回一个输出列表。拿到列表后我会人工或脚本检查三件事格式是否都合法、内容长度是否稳定、关键信息是否出现。如果5次输出格式一致性低于80%优先改Prompt如果格式稳定但内容分散再调温度。调试顺序建议是先固定temperature0.3、top_p0.9、max_tokens按预估给跑出一组基线然后单独拉高temperature到0.7跑一组观察发散方向再单独降低top_p到0.7跑一组观察候选收窄效果最后组合出一个最稳的参数组。这个过程每次改动只动一个变量问题定位才不会嫁错对象。还有个实际项目里常见的坑不少人习惯把temperature和top_p联动调低结果输出过度保守改写任务的用词变得干瘪。这时候不是参数错了而是Prompt里缺了“保持表达自然”的风格约束。参数调优和Prompt改写要交替进行不是一条道走到黑。5. 避坑指南Prompt设计最常见的五个翻车现场这一章记录我做提示词工程时翻过车、也看团队翻过车的地方。每一条都按现象、原因、解决三段来写可以直接当排查手册用。这里的案例都来自真实调优场景不是理论推演参数和写法都能直接拿去对照。5.1 现象模型答非所问回了一堆解释文字现象我让模型“输出三个具体建议”它却先讲了一堆“建议的重要性”和“建议的维度分类”到最后都没有给具体建议。原因Prompt里没有明确“只输出建议本身”这一约束而且任务动词是“谈谈建议”而不是“列出建议”。“谈谈”是一个开放动作模型会把相关的背景知识一并输出。解决把动作从“谈谈”改为“列出”并在边界里加一句“不要输出建议的前置说明或总结”。修复后的Promptprompt 任务针对下述问题列出三条可执行建议。 问题{issue} 格式每行一条每条不超过30字。 边界不要输出引言、解释或总结直接给建议。这段修复的要点在于“直接给建议”这个边界放到了Prompt末尾模型在读到边界时已经完成了前半段内容的编码末尾指令会压住生成阶段的倾向。如果只改前面的动词不改边界效果会差一截。5.2 现象输出格式不稳定有时是JSON有时是正文现象同样带有“输出JSON”的Prompt有时候返回的是代码块包裹的JSON有时候是纯JSON偶尔还混着解释文字。原因模型训练数据里“JSON”这个词和代码块有强关联光说“输出JSON”它可能默认带代码块。而“不要输出其他文字”没有放在格式约束同一行导致优先级不够。解决在格式定义后面直接加“输出裸JSON不要使用Markdown代码块不要输出任何解释”。// 推荐写法 { result: 严格输出上述JSON结构不要Markdown代码块不要任何其他文字 }注意这里我用注释来解释实际Prompt里这个注释不要写进去只是给阅读者看的。模型看到一个内嵌JSON样例时会直接模仿样例的结构。配合的调试手段是用程序检查输出是否由一对花括号完整包裹如果不是就触发重试一次。这种做法能掩盖大部分小概率的不稳定输出但根本解法还是在格式约束里把“不要代码块”写死。5.3 现象模型一本正经地编造事实现象让模型总结一篇文档里提到的数据文档里根本没有某个数值模型却给出了一个合理但不存在的数字。原因模型在生成时倾向于让回答“完整”缺数据会触发补全机制。如果没有在Prompt里声明“缺失就写无”这个兜底它就会编一个。解决给所有需要事实的字段都增加“如果原文未提供则输出null或unknown”的兜底说明。prompt 总结以下文档中提到的项目周期、预算和负责人。 文档{document} 格式JSON { project_duration: 填写文档中的周期原文未提及则写null, budget: 填写文档中的预算原文未提及则写null, owner: 填写文档中的负责人原文未提及则写null } 这里的关键是每个字段都单独写了兜底而不是在文档末尾统一写一句“没有的信息不要编”。单个字段写兜底模型在生成每个字段时都要做一次“这个信息是否存在”的判断兜底会更可靠。习惯了统一写兜底的团队通常只会在第一层防住幻觉字段级别的兜底才真正把幻觉概率压低。5.4 现象多轮对话越到后面越跑偏现象前几轮回答很精准第8轮开始回答变得冗长且重复。原因多轮对话里历史消息逐渐变长模型的注意力被旧消息分散加上中间轮次的assistant输出没做“只输出结果”约束冗余内容被当成上下文重用。解决定期压缩历史消息把关键信息抽成一个固定格式的state替代原始历史消息同时要求中间轮次assistant只输出结果。def compress_history(history: list, max_rounds: int 6) - list: if len(history) max_rounds * 2: return history latest history[-max_rounds * 2:] summary_prompt f请压缩以下对话历史为一段摘要保留用户需求和已确认结论{history[:-max_rounds]} summary call_model(summary_prompt) return [{role: system, content: f对话历史摘要{summary}}] latest这段代码的逻辑是在历史超过6轮之后用一次模型调用把旧历史压成摘要再替换掉旧消息。压缩后的摘要保留了用户的核心需求和已确认的结论丢弃中间寒暄和冗余推理。每次压完摘要token占用会大幅回落模型的指令遵循能力也跟着回稳。5.5 现象指令里写了“不要”模型反而照着做了现象明确写了“不要提到预算”生成的文本里却出现了预算相关词汇。原因有些模型对否定词的处理不稳定它可能只关注了关键词“预算”而没有处理“不要”的语义。这个在较小的开源模型上更容易出现。解决把否定表达改成肯定表达。“不要提到预算”改成“只讨论工期和范围”让模型有明确的正面行为。这是一条血泪经验。早期我写Prompt老是喜欢堆叠否定词后来发现模型不是逻辑处理器它是在玩概率补全否定词在长文本里会被淡化。现在只要发现“不要”类约束失效我会第一时间去检查能不能用一个肯定动作来替代。判断否定词是否生效有一个简单方法跑四五轮看输入与输出的语义方向。只要连续出现输出往反方向跑的情况就不必强行修补参数或指令结构直接改成肯定句即可。这里的成本和收益不成比例所以我的经验是永远把“不要”当作最后手段。6. 把Prompt变成可复用资产版本管理与评测方法这一章收在工程方法上Prompt不能当一次性字符串用完就扔。团队协作里Prompt的迭代速度远高于模型版本如果没管理好一次回归失误就要耗费大量返工时间。6.1 用版本表记录每次改动的实际影响我给Prompt做版本管理的起点是一张表格记录了版本号、改动位置、改动内容、影响指标。不要只记录“改成什么样了”还要记录“为什么改”。有一次我为了提升输出格式稳定性把JSON样例改得更细结果温度高了之后输出更长导致max_tokens被截断。如果没有记录改动位置这个根因会找不到。版本改动位置改动内容影响观测v1.0初始版角色任务格式格式稳定率 78%v1.1边界增加“不要代码块”格式稳定率 89%v1.2参数temperature 0.7→0.3内容准确率 6%多样性下降这张表的用途有两个一是回滚当新版本效果变差能精确回到上一个版本而不是从头再调二是沉淀团队成员接手时能知道每个改动的背景。Prompt改动的评估周期我一般设为一周因为有些问题要在足够多的真实流量里才能暴露。6.2 建一个回归测试集用固定用例守护质量底线Prompt是代码就该有测试。只有一条Prompt时靠感觉没问题一旦同时维护5条以上的业务Prompt回归测试就是必需品。我一般维护一个20到30条用例的回归集覆盖不同类型的输入形态。test_cases [ {case: 短输入, input: 库存不足, expect: 包含解决方案}, {case: 长输入, input: 产品介绍全文1024字..., expect: 输出包含核心参数}, {case: 特殊字符, input: AB: 特价100%, expect: 不出现Markdown解析错误}, ] def run_regression(prompt_func, test_cases, n5): for tc in test_cases: outputs [prompt_func(tc[input]) for _ in range(n)] pass_rate sum(1 for o in outputs if tc[expect] in o) / n print(f{tc[case]}: pass_rate{pass_rate:.2f})这段测试代码的逻辑是每个用例跑5次统计通过率。通过的标准可以是包含某个关键词、JSON能被解析、或者长度不超限。注意“expect”字段不要写得过于严格否则测试会在合理波动下误报反而让人不再信任测试结果。通过率低于0.8就说明Prompt在某个输入形态下不稳定需要回到设计流程里去调。6.3 我的最后一条习惯我的习惯是每次上线一条新Prompt强制自己写三个问题如果用户只给五个词它能输出什么如果用户给一万字的文档它会不会被淹没如果用户没说任何格式要求它会不会自己创造格式。这三个问题帮我挡住了大多数生产事故。提示词设计做到后面比的不是谁掌握了更炫的技巧而是谁愿意把指令当作正儿八经的产品资产来维护。希望帮到你。本文还有配套的精品资源点击获取