Prompt模式库：角色、任务、约束、示例、评分器、反思和工具协议
摘要
本文把 Prompt 视为面向大模型的任务接口，而不是可复制咒语。角色、任务、约束、示例、评分器、反思和工具协议共同构成一套可组合、可诊断、可评测的模式库。文章强调，生产级 Prompt 的价值不在长度，而在于把目标、证据、边界、输出契约和失败路径清楚地传递给模型；模式库也不应沦为模板仓库，而应服务于任务拆解、质量控制和持续迭代。好的 Prompt 体系能让模型真正执行工作，坏的 Prompt 只会把模糊需求包装得更长。
关键词
Prompt 工程；模式库；任务接口；评分器；工具协议；反思；少样本提示；智能体
研究问题与方法
本文研究的问题是：如何把分散的 Prompt 技巧整理成可复用的工程模式。方法上，文章先把 Prompt 失败归因为角色错位、任务不清、约束冲突、示例污染、评分器无力、反思空转和工具协议缺失，再分别分析七类模式的作用边界。每一种模式都被放在“输入是什么、模型该做什么、输出如何验收、失败如何恢复”的结构中讨论。
模式组合可以看成从需求到可验收输出的接口编译过程。下面的图说明七类模式并不是顺序清单，而是围绕任务契约互相约束。
Prompt 复杂度可以用一个取舍表表达，便于判断什么时候加模式、什么时候减模式：
| 任务风险 | 最小模式组合 | 不宜省略的内容 | 主要成本 |
|---|---|---|---|
| 低风险改写 | 任务、约束 | 输出风格和长度 | 上下文开销 |
| 事实问答 | 角色、任务、来源约束、评分器 | 证据不足时的退出路径 | 检索和引用成本 |
| 工具执行 | 角色、任务、工具协议、错误恢复、评分器 | 权限、参数来源、停止条件 | 延迟和审计成本 |
| 高风险决策 | 角色、任务、来源约束、评分器、人工复核 | 不确定性和拒答边界 | 复核成本 |
Prompt不是一句魔法咒语，也不是越长越稳的说明书。它更像面向大模型的任务接口：把目标、上下文、边界、输入输出、质量标准和外部工具组织成模型能执行的结构。一个生产级Prompt体系，真正有价值的不是收集几百条模板，而是把反复有效的结构沉淀成模式库，让团队在不同任务里稳定复用，也能在失败时定位到底是角色错了、任务没拆清、约束冲突、示例污染、评分器太软、反思无证据，还是工具协议没有说清。
这篇文章把Prompt模式拆成七类：角色、任务、约束、示例、评分器、反思和工具协议。它们不是互相独立的技巧，而是一组可以组合的工程积木。角色决定模型站在什么职责上工作，任务决定它要完成什么，约束决定什么不能越界，示例决定输出模式和判断尺度，评分器决定好坏如何被衡量，反思决定失败后如何修正，工具协议决定模型如何与外部世界连接。把这七类组合好，Prompt就从“让模型听话”的话术，升级成“让模型会干活”的执行结构。
很多Prompt失败，不是因为模型不够聪明，而是因为输入没有给模型一个可执行的工作面。用户说“帮我优化一下”，模型不知道优化目标是准确率、转化率、可读性、性能、成本还是风险；用户说“写得专业一点”，模型不知道行业标准、读者水平、证据边界和发布渠道；用户说“调用工具查一下”，模型不知道何时查、查什么、查不到怎么办、工具结果如何转化为最终答案。模式库的意义，是把这些模糊要求变成清晰结构。
引言：模式库不是模板仓库
模板仓库通常给人一段可复制的长Prompt，告诉用户把方括号替换成自己的内容。这对入门有帮助，但不适合长期生产。真实任务会变化：今天是客服摘要，明天是代码评审，后天是合同审阅；今天用短上下文模型，明天接RAG，后天接数据库和审批工具。如果团队只会复制模板，就会在场景变化时不断打补丁，最后形成一堆没人敢动的超长提示词。
模式库关注的是可迁移结构。比如“角色模式”不是固定写“你是一名资深专家”，而是定义职责、权限、读者、判断标准和禁区；“示例模式”不是随便塞两个样例，而是控制示例覆盖面、格式一致性、反例边界和输出分布；“评分器模式”不是让模型说“请给自己打分”，而是给出维度、权重、证据要求、失败条件和复核路径。模式库让人知道为什么这样写，而不是只知道复制哪一段。
好的模式库还要能支持诊断。一个问答系统回答不稳定，不能只说“Prompt不好”。要能追问：角色是否过度宽泛？任务是否缺少完成条件？约束是否互相矛盾？示例是否暗示了错误格式？评分器是否只看语气不看事实？反思是否只是让模型重写一遍？工具协议是否允许模型在证据不足时编造？有了模式分类，Prompt迭代才不会变成玄学。
模式库也不是把所有技巧堆进同一条Prompt。生产系统要控制成本、延迟和可维护性。一个简单分类任务，也许只需要任务定义、标签说明和两个反例；一个高风险法律问答，可能需要角色、资料来源、拒答边界、引用规则、评分器和人工复核；一个工具型Agent，还要加入工具选择、参数约束、幂等、错误处理和结束条件。模式越多，认知负担越大，只有和任务风险匹配才有价值。
因此，Prompt模式库应该像工程规范一样使用：先识别任务类型，再选择最小可用模式组合，然后用评测数据迭代。不要为了显得复杂而堆概念，也不要把一次成功的对话当成通用方法。稳定来自结构、评测和反馈闭环，不来自神秘措辞。
角色模式：职责比人设更重要
角色模式最常见，也最容易被误用。很多人习惯写“你是一名世界顶级专家”“你有二十年经验”“你非常严谨”。这些词可能让模型回答更像专家，但不一定让结果更可靠。生产级角色不是人设装饰，而是职责声明。它要告诉模型：你负责什么，不负责什么，服务谁，以什么标准判断，遇到不确定信息如何处理。
一个有效角色通常包含四层。第一层是身份，例如“企业知识库问答助手”“代码变更评审员”“教学反馈教练”。第二层是目标，例如“基于已提供资料回答员工问题”“识别变更中的风险并给出可复现证据”“帮助教师改进题目讲解”。第三层是边界，例如“不得使用未提供资料编造制度”“不直接重写业务逻辑，只指出问题和建议”“不评价学生人格，只评价作答表现”。第四层是沟通对象，例如“面向一线员工”“面向提交代码的工程师”“面向家长或教师”。
角色模式的关键是减少角色冲突。一个模型同时被要求“像销售一样有说服力”“像法务一样保守”“像客服一样亲切”“像审计一样严格”，很容易在回答里左右摇摆。更好的做法是给不同任务选择主角色，再把其他要求变成约束。比如客服退款场景中，主角色是“帮助用户完成退款判断的服务助手”，法务和风控要求放在规则与拒答边界里，而不是让模型同时扮演四个人。
角色还要和权限绑定。一个“旅行规划助手”可以建议路线，但不能代表用户下单；一个“代码助手”可以修改文件，但必须遵守指定范围和测试要求；一个“财务分析助手”可以解释报表，但不能承诺投资收益。角色如果没有权限边界，模型会把语言能力误当成行动授权。真实系统必须在Prompt和工具层同时控制权限，不能只靠一句“不要做危险事情”。
角色模式还要考虑读者。给高管看的摘要，和给执行同事看的操作清单，结构完全不同；给初学者的解释，和给专家的评审，信息密度也不同。读者不是语气设置，而是信息选择标准。模型知道读者后，才知道哪些背景需要解释，哪些术语可以省略，哪些结论必须先给，哪些细节可以放后面。
角色模式的简洁写法可以是：“你是某类任务的执行者，目标是帮助某类读者完成某个决策或动作。你只能基于给定资料和可用工具工作。你必须指出不确定性，并在证据不足时请求补充信息或给出无法判断。”这比夸张的人设更稳定，因为它把模型放进一个可审查的职责框架里。
任务模式：把动词变成可验收结果
任务模式回答“到底要做什么”。很多Prompt看似写了任务，其实只写了愿望。“分析一下”“总结一下”“优化一下”“帮我看看”都不是可验收任务，因为它们缺少输入范围、处理步骤、输出形态和完成标准。模型会凭经验补全空白，于是不同轮次、不同模型、不同上下文会得到完全不同的结果。
可执行任务至少要包含四个要素：输入、动作、输出和验收。输入说明模型要处理哪些资料；动作说明模型要执行什么转化；输出说明交付物长什么样；验收说明结果满足什么条件。比如“请阅读下面三段客服记录，提取用户诉求、已发生事实、待确认问题和建议下一步，输出为四列Markdown表格；如果记录中没有证据，不要补写”。这类任务比“总结客服记录”更稳定。
复杂任务需要阶段化。一个长文写作任务可以拆成资料阅读、论点设计、结构安排、正文写作、事实复核和引用整理；一个代码任务可以拆成复现问题、定位原因、修改最小范围、运行测试和说明风险；一个Agent任务可以拆成计划、执行、观察、调整、验收和交付。阶段化不是让模型显得忙，而是减少一次输出里同时承担太多目标导致的遗漏。
任务模式还要区分“生成任务”和“判断任务”。生成任务要求模型产出内容，如文章、代码、摘要、邮件、计划。判断任务要求模型根据标准给出选择，如分类、评分、是否通过、风险等级。两者Prompt结构不同。生成任务需要风格、结构、素材和输出长度；判断任务需要标签定义、边界案例、证据引用和拒判条件。如果把判断任务写成开放生成，模型容易解释很多但不给明确结论；如果把生成任务写成标签分类，内容会僵硬贫乏。
任务模式还要处理多目标排序。真实需求常常有多个目标：准确、简洁、有说服力、合规、低成本、快。目标之间会冲突。比如“越详细越好”和“控制在一屏内”冲突，“鼓励用户购买”和“不夸大效果”冲突，“自动完成”和“必须确认后执行”冲突。Prompt要明确优先级：事实正确高于表达流畅，合规高于转化，用户确认高于自动执行，证据不足时拒答高于完整回答。
任务完成条件必须写清。对文章来说，完成可能是“形成可发布正文并列出参考资料”；对数据分析来说，完成可能是“给出结论、计算依据和异常点”；对工具Agent来说，完成可能是“目标状态已经由工具返回确认”。没有完成条件，模型容易在中间产物处停下，或者把计划当结果。生产系统里，任务模式应该让模型知道什么时候继续、什么时候停止、什么时候请求用户补充。
约束模式：让自由生成有边界
约束模式决定模型不能做什么、必须遵守什么。约束不是为了压制模型，而是为了降低错误空间。大模型天生擅长补全，它会根据上下文推测缺失信息。这个能力在创作中有用，在事实问答、工具执行、合规场景中却可能变成风险。约束模式的核心，是把可接受行为和不可接受行为写成清晰边界。
常见约束有事实约束、来源约束、格式约束、语气约束、权限约束、长度约束和安全约束。事实约束要求不编造；来源约束要求基于指定资料或工具结果；格式约束要求输出可解析；语气约束要求面向特定读者；权限约束要求不执行未授权动作；长度约束控制信息密度；安全约束避免泄露、越权和危险操作。不同任务需要不同约束，不能一条Prompt里混成口号。
约束要具体，不能只写“准确”“专业”“严谨”。准确意味着什么？是每个事实都要有来源，还是数字必须和表格一致，还是不能把猜测写成结论？专业意味着什么？是术语正确、结构清楚，还是符合行业流程？严谨意味着什么？是标出不确定性、列出反例，还是给出推理依据？把抽象词拆成可观察行为，模型才有执行标准。
约束也要避免互相打架。比如同时要求“只根据资料回答”和“没有资料时发挥常识补全”，会导致模型无法判断边界；同时要求“必须输出JSON”和“自然解释原因”，会让结构不稳定；同时要求“不要太长”和“覆盖所有细节”，会让模型随机取舍。Prompt中出现冲突约束时，模型通常不会报错，而是选一个看起来顺的方向执行。生产系统要主动消除冲突。
约束模式里的反例非常重要。只写“不要编造引用”不如写“如果资料中没有发布日期，输出‘资料未提供发布日期’，不要猜测日期”。只写“不要泄露内部字段”不如写“面向用户时不要出现接口名、字段名、日志编号、模型参数和调试状态”。反例能把边界从抽象规范变成具体行为，尤其适合格式、合规和客服场景。
约束还要配合失败路径。模型遇到约束无法满足时应该怎么办？如果缺资料，是拒答、追问，还是给出假设性建议？如果格式无法生成，是说明原因，还是返回空结构？如果工具失败，是重试、换工具，还是报告阻塞？没有失败路径，约束会变成软提示；有了失败路径，模型才知道守不住边界时如何安全退出。
示例模式：用少量样例校准输出分布
示例模式，也就是少样本提示，是Prompt工程里最实用的模式之一。模型不仅从指令中学习，也从示例中学习。示例能告诉模型输出格式、信息颗粒度、判断边界和风格尺度。Google的Prompt设计文档也强调，示例格式要保持一致，因为少样本示例的重要目标就是让模型学会响应格式。
示例不是越多越好。太少，模型可能抓不到模式；太多，模型可能过拟合示例，把新输入强行套进旧结构。示例选择应该覆盖关键边界：标准正例、标准反例、模糊案例、缺失信息案例和高风险案例。比如合同条款抽取任务，不仅要给“能抽取”的例子，也要给“资料没有，不得补写”的例子；客服分类任务不仅要给退款、咨询、投诉，也要给多意图混合时的优先级。
示例格式必须一致。输入部分、输出部分、分隔符、字段顺序、空值写法、引用写法都要统一。格式不一致时，模型会把随机差异当成可学习信号，输出就会漂移。比如一个示例用“原因：”，另一个用“解释：”，第三个用自然段，模型可能在最终输出里混用。生产系统里的示例应该像测试样例一样被维护。
示例还要避免泄露错误偏好。很多团队为了让模型“更聪明”，会给很长的优秀答案示例，却没有意识到示例中包含不适合当前任务的风格：过度展开、主动猜测、无来源判断、营销化语言、复杂格式。模型会学习这些隐含偏好。示例不是资料库，而是行为标定器。每个示例都应该回答：我希望模型学会这个例子的哪一点？
反例示范比单纯禁止更有效。比如风险评审任务中，可以给一个“看似完整但证据不足”的回答，然后标注它为什么不合格，再给合格版本。这样模型能学到失败形态，而不是只看到理想输出。评分器和示例结合时，效果更好：示例展示结果，评分器解释好坏。
示例模式还可以用于多轮任务。工具调用Agent可以给一个完整轨迹示例：用户目标、工具选择、工具参数、工具结果、下一步判断、最终回答。注意轨迹示例不必暴露不可见的内部思考，而应展示可审查的行动理由和观察结果。这样模型学习的是工具协议和状态转移，而不是散乱的“思考独白”。
评分器模式：把“好答案”变成可检查标准
评分器模式让模型或系统能够判断输出质量。没有评分器，Prompt迭代只能靠感觉。今天觉得这个回答好，明天换一个人又觉得不好。评分器把“好”拆成维度：事实是否正确，是否基于证据，是否回答用户问题，是否结构清晰，是否符合格式，是否遗漏关键条件，是否触碰禁区，是否能引导下一步。
评分器可以是人工标准、程序检查、模型评审或三者组合。程序检查适合格式、字段、字数、引用链接、JSON Schema、正则规则和工具返回状态；模型评审适合开放文本质量、语气、完整性和解释清晰度；人工评审适合高风险判断、价值判断和业务责任。不要让模型评分替代所有验收，也不要把所有开放质量都硬塞进正则。
评分器Prompt要写得像评审表，而不是像鼓励语。坏写法是“请判断答案是否优秀”。好写法是“按事实准确性、证据支撑、完整性、边界表达、可执行性五项评分；任何一项出现严重事实错误，总评不得通过；每项必须引用答案中的具体片段或指出缺失内容”。这样模型评审会更可复核。
评分器还要防止宽松化。模型作为评审员时，常见问题是偏好流畅、偏好长答案、偏好自信语气，容易放过事实错误。MT-Bench和Chatbot Arena相关研究指出，LLM-as-a-judge有位置偏差、冗长偏差、自我增强偏差和推理能力限制。生产系统使用模型评分时，要用盲评、成对比较、随机顺序、硬失败条件和人工抽检降低偏差。
评分器模式对Prompt迭代尤其重要。每次改Prompt后，不应该只跑几个漂亮例子，而要跑一组固定评测集，观察通过率、失败类型和回归点。OpenAI Evals这类框架的价值，就是把大模型应用的评测变成可重复过程。Prompt一旦进入产品，就应该像代码一样有回归测试，而不是靠临时聊天验证。
评分器也可以前置到生成过程。比如文章写作前先生成评分标准，写完后按标准复核；代码修改前先列验收命令，改完后执行；知识库问答前先确定证据要求，回答后检查每个结论是否能回溯。评分器不是最后挑错的工具，而是让模型从一开始就知道交付标准。
反思模式：修正不是自我陶醉
反思模式指让模型检查自己的输出、发现缺口并改进。它来自一系列推理与Agent研究，也来自实际产品经验。Chain-of-Thought和Self-Consistency说明，复杂问题中不同推理路径可能帮助模型得到更稳答案；Reflexion把外部或内部反馈转成语言记忆，用于后续改进；ReAct把推理与行动交错，让模型根据外部观察调整计划。反思模式的价值，是让一次生成不再是终点。
但反思很容易被滥用。最常见的坏写法是“请先反思，再给出答案”“请检查自己有没有错误”。模型可能会生成一段看似严谨的自评，却没有任何新证据。没有外部信息、没有评分标准、没有工具观察，反思往往只是同一个模型用另一种语气重复原判断。生产级反思必须绑定证据和验收，而不是把“想一想”当作可靠性来源。
有效反思有三种来源。第一是规则来源：用评分器检查是否满足格式、边界和完整性。第二是外部来源：用检索、数据库、测试、计算器、浏览器或业务接口验证事实。第三是多样性来源：让模型生成多个候选或多个角度，再用评分器选择更稳答案。Self-Consistency的思路适合数学和推理类任务，但在业务场景中仍要结合事实工具，不能只靠多数投票。
反思模式要有明确动作。发现事实缺证据，就回到检索；发现格式不合格，就修复格式；发现工具参数错误，就改参数；发现任务边界不清，就向用户追问；发现风险超过权限，就停止并说明原因。反思如果不能触发下一步动作，就只是文本装饰。模型说“我会更严谨”没有意义，真正有意义的是它下一步改了什么。
反思还要控制次数。无限自我检查会消耗成本并可能越改越差。生产系统可以设置最多两轮修正、失败类型白名单和终止条件。比如格式错误可以自动修复一次，事实缺失不能靠重写解决，必须查证或拒答；测试失败可以允许最小范围修复，连续失败则交付错误日志和阻塞原因。反思要服务完成任务，不要变成循环。
反思模式还要区分公开解释和内部推理。面向用户的回答应该给可审查依据、关键判断和不确定性，不需要暴露冗长思维链。对于许多产品，输出“结论、依据、限制、下一步”比输出长篇内心推理更安全。模型可以在受控流程中进行中间检查，但最终交付要面向用户可读、可验证、可行动。
工具协议模式：让模型会用外部能力
工具协议模式是Agent型Prompt的核心。工具让模型访问训练数据之外的信息和行动能力：搜索网页、查知识库、读文件、运行代码、计算、创建工单、发邮件、调数据库。OpenAI和Anthropic的工具文档都强调，模型不是自己执行函数，而是生成工具调用请求，由应用或服务执行，再把结果返回给模型。这个流程看似简单，实际决定了Agent能否可靠工作。
工具协议首先要说明工具用途。工具名、描述、参数和返回值必须面向模型可理解。工具名应该表达动作，例如search_policy比api_v2_query清楚；参数应该少而明确，例如user_id、date_range、query；返回值应该包含模型继续任务需要的信息，例如状态、摘要、来源、错误类型和可用下一步。不要把内部接口裸暴露给模型，让它猜字段含义。
工具协议要写何时使用工具。不是所有问题都要查，也不是所有问题都能凭常识答。比如“涉及当前政策、价格、库存、用户账户、订单状态、代码执行结果时必须使用工具”；“纯概念解释可以直接回答”；“用户要求基于上传资料时必须优先使用资料检索”。何时不用工具也要说明，否则模型可能为简单任务产生无谓调用。
工具协议要处理参数生成。模型容易在参数不清时猜测。生产Prompt应要求：缺少必要参数时先追问；能从上下文确定的参数才填入；日期、金额、单位、标识符必须保持原样；禁止把自然语言猜测当作ID。对于结构化工具，Structured Outputs或严格Schema能降低参数格式错误，但业务语义仍需要校验。Schema管形状，不能替代权限和事实判断。
工具协议必须定义错误处理。工具失败不是罕见情况，而是常态。网络超时、权限不足、资源不存在、参数不合法、速率限制、结果为空、返回冲突，都要有不同处理。模型收到“失败”两个字，很可能重复同一调用；收到清楚错误类型和建议，才可能修正。Prompt可以要求：参数错误先改参数，权限错误请求授权，结果为空说明未查到，超时最多重试一次，危险操作不得自动重试。
工具协议还要约束副作用。查询天气和发送邮件不是同一类工具。读操作、写操作、不可逆操作要分级。创建、删除、支付、发送、发布、审批这类动作，必须有确认、预览、幂等键和操作记录。模型不能因为“用户可能想要”就执行。工具层应强制权限，Prompt层应说明确认语义：用户明确授权前，只能准备方案或草稿，不能提交真实操作。
工具结果必须被引用和转化。模型调用工具后，不应忽略结果继续编造。最终答案要基于工具返回，必要时说明来源、时间、状态和限制。如果工具返回多个候选，模型要解释选择依据；如果工具返回证据不足，模型要承认无法判断。工具协议的目的不是让模型多动，而是让回答与现实状态连接。
组合模式：七类模式如何一起工作
真实Prompt通常是组合模式。以“企业制度问答”为例，角色是“基于制度资料回答员工问题的助手”；任务是“回答问题并给出可执行下一步”；约束是“只能基于检索资料，不编造政策，不出现内部字段”；示例展示有资料、无资料、资料冲突三种情况；评分器检查答案是否有依据、是否回答问题、是否说明限制；反思在证据不足时触发二次检索或拒答；工具协议定义如何查知识库、如何处理无结果和冲突结果。
以“代码评审助手”为例，角色不是“万能程序员”，而是“变更风险评审员”；任务是“指出会导致错误的具体问题”；约束是“按严重程度排序，必须给文件和行号，不评价风格偏好”；示例展示一个真正阻断的问题和一个不该报告的偏好问题；评分器检查每条发现是否可复现；反思要求删除证据不足的发现；工具协议允许读取文件、运行测试，但不允许改代码，除非任务明确要求修复。
以“长文写作助手”为例，角色是“面向中文读者的技术解释作者”；任务是“基于资料写出原创长文”；约束是“不抄原文，不重复段落，不出现后台说明”；示例校准段落密度和标题层级；评分器检查论点完整性、引用数量、事实边界和可读性；反思用于查漏补缺；工具协议用于联网检索和来源核验。写作Prompt如果只写“写一篇长文”，就会依赖模型习惯；组合模式能把写作变成可验收流程。
组合模式的顺序也重要。一般先角色，后任务，再上下文和约束，然后示例，最后输出格式与验收。工具型任务还要在任务前说明可用工具，在输出前说明何时结束。评分器可以作为单独Prompt运行，也可以嵌入生成Prompt中作为自检清单。复杂任务不必把所有内容塞在一条消息里，可以采用Prompt链：先生成结构，再写正文，再评分，再修订。
组合模式要控制信息层级。系统级规则放稳定边界，开发者级或应用级规则放任务策略，用户输入放具体需求，检索资料放上下文，示例放在任务附近。不要让临时资料覆盖核心安全边界，也不要让用户输入能改写工具权限。Prompt模式库的工程价值，正是在多层上下文里保持职责清楚。
最小可用组合通常是“角色加任务加约束加输出格式”。当任务开始不稳定，再加入示例；当输出质量难衡量，再加入评分器；当任务需要多步修正，再加入反思；当任务需要外部事实或行动，再加入工具协议。这样做能保持Prompt轻量，也能随着风险逐步增强。
落地：把Prompt当成可迭代资产
Prompt模式库要真正有用，需要版本化。每条核心Prompt都应该知道适用场景、输入要求、输出结构、依赖工具、评测集、已知失败和修改记录。否则团队会出现同一任务多份Prompt并存，谁也不知道哪一份在线上使用，哪一份通过了评测，哪一份只是某次演示临时写的。
落地第一步是建立任务分类。把系统中的AI任务分成问答、抽取、分类、写作、评审、规划、工具执行、对话路由等类型。每一类任务定义推荐模式组合。比如抽取任务默认使用任务、约束、示例和结构化输出；评审任务默认使用角色、评分器和反例；工具执行任务默认使用角色、任务、权限约束、工具协议和完成条件。
第二步是建立评测样本。每个Prompt至少要有正常样本、边界样本、恶意或异常样本、缺失信息样本。不要只测理想输入。生产中的失败常常来自模糊、缺项、冲突、过期和越权。评测样本越接近真实用户，Prompt越能抵抗演示幻觉。样本也要随业务变化更新，尤其是政策、价格、产品功能和工具接口变化后。
第三步是记录失败类型。不要只记录“效果不好”，要归因到模式层：角色漂移、任务不清、约束冲突、示例误导、评分器宽松、反思循环、工具误用、资料不足。每种失败对应不同修复手段。角色漂移要收紧职责，任务不清要补完成标准，约束冲突要明确优先级，工具误用要改描述和错误处理，资料不足要改检索或拒答策略。
第四步是把Prompt和系统能力分开。Prompt不能承担所有责任。权限控制、Schema校验、敏感信息过滤、幂等、防重复提交、日志追踪、人工审批、测试执行，都应该在系统层实现。Prompt负责让模型理解任务，系统负责保证边界真实生效。把安全和正确性全压在一句提示词上，不是生产级设计。
最后，模式库要服务用户结果，而不是服务Prompt美观。一个好Prompt不一定长，不一定术语多，不一定包含所有模式。它应该让模型在真实输入下稳定完成任务，让用户得到清楚、准确、可行动的结果。Prompt工程的终点不是写出漂亮提示词，而是把模型能力可靠接入产品和工作流。
常见配方：从简单任务到复杂Agent
模式库最实用的使用方式，是形成任务配方。配方不是死模板，而是模式组合的起点。团队拿到一个AI任务时，先判断它属于哪类，再选择默认配方，然后根据风险增减。这样既避免每次从零写Prompt，也避免把复杂场景压成一句“请认真回答”。
信息抽取类任务适合“任务、约束、示例、结构化输出”组合。任务要说明抽取对象、字段含义和输入来源；约束要说明缺失值如何处理，不允许补写；示例要覆盖正常字段、缺失字段和歧义字段；结构化输出要尽量用JSON Schema、表格或固定字段。抽取任务最怕模型把理解能力变成创造能力。只要资料中没有，宁可空着，也不能让模型补一个看似合理的值。
分类和路由类任务适合“标签定义、边界案例、优先级、拒判条件”组合。标签名不能只写一个词，要说明包含什么、不包含什么。边界案例决定模型遇到混合意图时如何选。优先级很关键，例如用户同时投诉和要求退款时，系统可能应该先进入投诉升级，再处理退款。拒判条件也要存在，输入太短、证据不足、标签不覆盖时，不应强行归类。
问答类任务适合“角色、来源约束、回答结构、拒答路径、引用要求”组合。企业知识库、政策咨询、技术文档问答尤其如此。模型要知道自己不是百科全书，而是基于给定资料帮助用户理解和行动的助手。资料支持什么就答什么，资料冲突就说明冲突，资料没有就追问或拒答。问答系统的可靠性通常不来自更漂亮的解释，而来自证据边界。
写作类任务适合“读者、目的、材料范围、结构、风格、评分器”组合。写作不是让模型自由发挥，而是让它为特定读者完成特定沟通目标。面向初学者的长文，需要概念铺垫、例子和过渡；面向决策者的报告，需要结论前置、取舍和风险；面向产品用户的文案，需要清楚、克制、可操作。评分器能帮助写作任务避免常见问题：重复段落、空泛判断、没有证据、标题层级混乱、内部术语外泄。
评审类任务适合“评审角色、硬失败条件、证据要求、严重程度排序”组合。评审不是改写，也不是表达个人喜好。评审智能体要找会影响正确性、安全性、用户理解或业务结果的问题。每条发现都要有证据，最好能定位到原文、代码、数据或工具结果。没有证据的怀疑可以作为开放问题，但不应伪装成确定缺陷。
规划类任务适合“目标、资源、约束、阶段、风险、验收”组合。规划最常见的问题是把愿景写成清单，看起来完整但无法执行。好的规划要说明先做什么、为什么先做、每步完成物是什么、哪些条件会改变路线、哪些风险需要提前确认。规划任务尤其需要把“不确定”显式列出，否则模型会把未知条件包装成确定步骤。
工具执行类任务适合“角色、任务状态、工具协议、权限边界、错误处理、完成条件”组合。模型要知道什么时候调用工具、如何填参数、如何根据工具返回调整、什么动作需要确认、失败后最多重试几次、最终完成凭证是什么。工具执行Prompt不应追求文学性，而要像操作规程。它越清楚，Agent越不容易乱动。
多轮对话类任务适合“会话状态、用户目标、澄清策略、阶段切换、记忆边界”组合。模型要知道哪些信息已经确认，哪些只是用户提到的背景，哪些需要继续追问，什么时候从咨询进入执行，什么时候应该总结当前状态。没有会话状态，多轮Prompt会被最近一句话牵着走，容易忘记前面已经确认的限制。
这些配方可以放进团队文档，也可以做成产品中的Prompt构建器。更成熟的做法，是让每个配方绑定评测集和失败案例。配方不是写完就结束，而是在真实任务中不断收窄边界、补充反例、拆分过重职责。Prompt模式库越贴近实际失败，越有工程价值。
反模式：看起来聪明，实际不稳
Prompt模式库也应该记录反模式。反模式不是不能用的句子，而是在多数生产场景中容易制造不稳定的写法。识别反模式，可以帮助团队少走弯路。
第一种反模式是“万能专家”。它让模型同时扮演战略顾问、工程师、产品经理、法务、运营和审计。回答可能很丰富，但职责不清。模型不知道该优先优化什么，也不知道遇到冲突时听谁的。更稳的方式是选择主角色，把其他要求转成明确约束或评审标准。
第二种反模式是“无限详细”。很多人以为越详细越好，于是要求模型覆盖所有方面、列出全部可能、不要遗漏任何细节。结果往往是回答冗长、重点不清、成本升高，而且关键结论被淹没。生产Prompt应指定信息密度：先结论，后依据；先用户要做的事，后背景；只展开影响决策的细节。
第三种反模式是“只许成功”。比如“你必须完成任务，不要说做不到”。这会鼓励模型在证据不足、权限不足、工具失败时编造完成。真正可靠的Prompt要允许安全失败：说明缺什么、已经验证什么、不能判断什么、下一步需要什么。能诚实停下来的系统，比永远给完整答案的系统更可信。
第四种反模式是“格式和内容混在一起”。Prompt一边要求严格JSON，一边要求解释思路、补充建议和自然语言总结，最后输出难以解析。更好的做法是分离机器可读输出和人类可读输出，或者明确字段中哪些是正文、哪些是说明。结构化输出要让解析器稳定工作，不能靠模型临场排版。
第五种反模式是“示例污染”。示例中包含了不希望复用的事实、夸张语气、错误字段或过长解释，模型会照着学。团队常常只检查示例答案是否看起来好，却不检查示例是否携带错误偏好。示例进入模式库前，应该像测试用例一样审查。
第六种反模式是“自评即验收”。让模型回答后再说“我已经检查，没有问题”，并不能证明结果可靠。自评只有结合评分标准、外部证据和可执行检查才有意义。否则模型很容易给自己放行。生产系统要把验收从模型自信中拿出来，交给工具、评分器、测试或人工。
第七种反模式是“工具万能”。接了搜索、浏览器、数据库和代码执行工具，不代表Agent就能完成任务。工具描述不清、错误不可恢复、权限不隔离、结果不校验时，工具越多越乱。工具协议应该先覆盖高价值动作，再逐步扩展，而不是把所有API一次性丢给模型。
第八种反模式是“把内部过程展示给用户”。用户需要答案、依据、限制和下一步，不需要看到系统提示词、工具参数、模型名称、调试日志或内部角色争论。Prompt要把最终输出面向用户设计。内部信息可以用于审计和排错，但不应该进入正常界面和正式内容。
记录反模式的价值，是让团队形成共同语言。当一次输出失败时，大家可以说“这是角色冲突”“这是示例污染”“这是自评代替验收”，而不是笼统地说“模型又幻觉了”。这种共同语言会让Prompt迭代更快，也让AI功能更接近可维护的软件工程。
参考资料
- OpenAI API Docs: Prompting, https://developers.openai.com/api/docs/guides/prompting
- OpenAI API Docs: Function Calling, https://developers.openai.com/api/docs/guides/function-calling
- OpenAI: Introducing Structured Outputs in the API, https://openai.com/index/introducing-structured-outputs-in-the-api/
- OpenAI Evals GitHub, https://github.com/openai/evals
- Anthropic Claude Docs: Prompt Engineering Overview, https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview
- Anthropic Claude Docs: Tool Use with Claude, https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- Google AI for Developers: Prompt Design Strategies, https://ai.google.dev/gemini-api/docs/prompting-strategies
- Microsoft Learn: Prompt Engineering Techniques, https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/prompt-engineering
- Jules White et al.: A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, https://arxiv.org/abs/2302.11382
- Jason Wei et al.: Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, https://arxiv.org/abs/2201.11903
- Xuezhi Wang et al.: Self-Consistency Improves Chain of Thought Reasoning in Language Models, https://arxiv.org/abs/2203.11171
- Shunyu Yao et al.: ReAct: Synergizing Reasoning and Acting in Language Models, https://arxiv.org/abs/2210.03629
- Timo Schick et al.: Toolformer: Language Models Can Teach Themselves to Use Tools, https://arxiv.org/abs/2302.04761
- Noah Shinn et al.: Reflexion: Language Agents with Verbal Reinforcement Learning, https://arxiv.org/abs/2303.11366
- Lianmin Zheng et al.: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, https://arxiv.org/abs/2306.05685