1. 为什么“一套提示词打天下”是个伪命题先把结论摆在前面不存在一套战无不胜攻无不克的提示词。我做了三年多提示词工程和智能体开发从最早的 GPT-3.5 时代一路踩坑到现在见过太多人拿着一份所谓的“万能提示词模板”到处套结果换个模型、换个任务就翻车。这不是提示词写得不好而是提示词的本质是任务约束不是魔法咒语。你手里那套“战无不胜”的提示词大概率是在某个特定场景下调出来的——比如让模型做结构化输出、或者做角色扮演、或者做代码生成。它在那个场景下表现好是因为它恰好把那个场景的关键约束都覆盖到了。但一旦任务类型变了约束条件变了模型变了它就不灵了。我举个真实的例子。去年有个朋友兴冲冲地跟我说他搞了一套“万能销售话术提示词”在某个国产大模型上跑得特别好客户回复率很高。结果他把同一套提示词搬到另一个模型上输出质量直接崩了——因为不同模型对指令的敏感度、对格式的遵循能力、对上下文长度的处理方式都不一样。提示词工程的核心不是写一份模板而是理解任务、理解模型、理解约束条件然后动态调整。所以这篇文章不是要给你一份“万能提示词”而是要拆解一套可复用的提示词设计方法论。你学会了这套方法就能针对任何任务快速写出高质量的提示词而不是到处找模板。1.1 提示词工程的本质是什么很多人把提示词工程理解成“跟 AI 说话的艺术”这个理解太浅了。提示词工程的本质是用自然语言做编程。你写的每一句话都是在给模型下达指令、设定约束、提供上下文、定义输出格式。这跟写代码没有本质区别只不过你的“编程语言”是自然语言。既然是编程那就有几个核心要素输入定义你要模型处理什么信息这些信息以什么形式给它处理逻辑你要模型怎么处理这些信息分几步每步做什么输出约束你要模型输出什么格式长度多少风格怎样边界条件什么情况下模型应该拒绝回答什么情况下应该追问你手里那套“战无不胜”的提示词如果在这四个维度上都做得很好那它确实在特定场景下很强。但问题是不同任务的这四个维度差异巨大。让模型写代码和让模型写营销文案输入定义、处理逻辑、输出约束完全不同。你不可能用同一套约束覆盖所有场景。1.2 为什么大多数人写的提示词效果不好我观察下来大多数人写提示词效果不好根本原因就三个第一指令太模糊。“帮我写一篇好文章”——什么叫好多长什么风格给谁看模型只能猜猜出来的结果大概率不是你想要的。第二缺少示例。你告诉模型“按这个风格写”但你没给它看过“这个风格”到底是什么样。模型只能根据它训练数据里的理解来猜猜对了是运气猜错了是常态。第三没有输出格式约束。你让模型输出 JSON但你没告诉它字段名是什么、类型是什么、嵌套结构怎样。结果它给你输出一段看起来像 JSON 但实际解析不了的东西。这三个问题对应的是提示词设计的三个核心技巧明确指令、少样本示例、结构化输出。后面我会逐一展开讲。1.3 这套方法论适合谁如果你只是偶尔用 AI 聊聊天、查查资料那这篇文章可能对你有点重。但如果你符合以下任何一种情况这套方法论会帮你省下大量试错时间你在做智能体开发需要让 AI 稳定执行特定任务你在做 AI 编程辅助需要模型按你的规范生成代码你在做内容生产需要模型稳定输出符合品牌调性的文案你在做数据分析需要模型从非结构化文本里提取结构化信息你在做销售、客服、运营等场景的 AI 助手需要模型按话术规范回复这些场景的共同点是你需要的是稳定、可复现、可规模化的输出而不是一次性的创意灵感。这套方法论就是为这种需求设计的。2. 提示词框架的核心模块拆解一套完整的提示词框架应该包含六个核心模块。这六个模块不是必须全部出现但当你发现输出效果不稳定时大概率是某个模块缺失了。2.1 角色定义模块角色定义是提示词的第一句话也是最容易被忽视的一句话。很多人写提示词直接从任务开始“帮我写一段 Python 代码”。但更好的写法是“你是一位有十年经验的 Python 后端工程师擅长写高并发、可维护的服务端代码。现在请帮我……”为什么角色定义重要因为角色定义会激活模型训练数据中与该角色相关的知识分布。当你告诉模型“你是一位资深律师”模型在生成回复时会倾向于调用法律相关的术语、逻辑和表达方式。当你告诉模型“你是一位幼儿园老师”模型会倾向于用简单、亲切、鼓励性的语言。但角色定义不是越长越好。我见过有人写了两百字的角色定义把模型夸得天花乱坠结果模型光顾着“扮演角色”了正事没干。角色定义的核心是精准不是华丽。一个好的角色定义应该包含三个要素专业身份模型应该以什么身份来回答核心能力这个身份最擅长的技能是什么行为准则这个身份在回答时应该遵循什么原则举个例子你是一位资深数据分析师擅长从杂乱的数据中提取关键洞察并用通俗易懂的语言向非技术背景的决策者汇报。你在分析时始终遵循“数据支撑结论”的原则不做没有数据依据的推测。这个角色定义只有三句话但把身份、能力、准则都说清楚了。2.2 任务描述模块任务描述是提示词的核心。很多人写任务描述的问题是太笼统。比如“帮我分析一下这份数据”模型不知道你要分析什么维度、用什么方法、输出什么结果。好的任务描述应该像一份工作说明书包含任务目标最终要产出什么输入说明给模型的信息是什么怎么理解这些信息处理步骤如果需要多步处理每一步做什么输出要求输出格式、长度、风格我通常会用这样的结构来写任务描述## 任务 你的任务是从以下用户评论中提取产品改进建议。 ## 输入 用户评论是一段中文文本可能包含多条评论每条评论以换行分隔。 ## 处理步骤 1. 逐条阅读评论判断每条评论是否包含具体的产品改进建议 2. 如果包含提取建议的核心内容归类到以下类别之一功能需求、体验优化、性能问题、界面设计、其他 3. 如果评论只是情绪表达而没有具体建议标记为“无具体建议” ## 输出格式 以 JSON 数组输出每个元素包含以下字段 - comment: 原始评论内容 - category: 建议类别 - suggestion: 提取的建议内容 - has_suggestion: 是否包含具体建议true/false这种结构化的任务描述模型理解起来几乎没有歧义。2.3 上下文与约束模块上下文是给模型提供背景信息的部分。比如你在做客服智能体你需要告诉模型当前用户的历史订单信息、会员等级、之前的沟通记录等。这些信息不是任务本身但会影响模型的处理方式。约束模块则是告诉模型什么不能做。比如不要编造不存在的信息不要输出与任务无关的内容不要使用过于专业的术语确保初中生能看懂如果信息不足不要猜测直接说明需要更多信息约束模块是保证输出质量的关键。我见过太多模型“自作聪明”的例子——你让它总结一篇文章它给你加了一堆原文没有的“延伸思考”。你让它提取数据它给你补全了缺失的值。这些行为在创意场景下可能是加分项但在需要精确执行的场景下就是灾难。2.4 少样本示例模块少样本示例是提升输出稳定性的最有效手段没有之一。你给模型看两三个“输入-输出”的示例它就能理解你要的格式、风格、粒度。但示例不是随便给的。我总结了几条经验第一示例要覆盖边界情况。如果你只给“正常情况”的示例模型遇到异常输入时就不知道怎么办。比如你做情感分类除了给“正面”“负面”的示例还要给“中性”“混合”的示例。第二示例要一致。如果你给的三个示例格式都不一样模型会困惑到底该学哪个。所有示例的输入格式、输出格式、标注粒度必须统一。第三示例数量不是越多越好。对于大多数任务2-5 个示例就够了。示例太多会占用大量上下文窗口而且边际收益递减。我通常的做法是先给 2 个示例如果效果不稳定再加到 5 个。第四示例要放在任务描述之后、实际输入之前。这个顺序很重要。模型需要先理解任务再看示例最后处理实际输入。如果你把示例放在任务描述之前模型可能还没理解任务就开始看示例效果会打折扣。2.5 输出格式控制模块输出格式控制是提示词工程里最“工程化”的部分。如果你需要模型输出结构化数据JSON、XML、YAML、CSV你必须精确地定义格式。我见过太多人写“请以 JSON 格式输出”然后模型输出的 JSON 解析不了。原因通常是没有指定字段名没有指定字段类型没有指定嵌套结构没有指定是否允许额外字段没有指定空值怎么表示一个完整的输出格式定义应该长这样以 JSON 格式输出结构如下 { summary: string, 不超过 100 字的摘要, keywords: [string, 3-5 个关键词], sentiment: string, 取值范围positive/negative/neutral, confidence: number, 0-1 之间的浮点数表示分析置信度, details: { reason: string, 判断理由, evidence: [string, 原文中的支撑语句] } }如果模型输出的 JSON 经常有问题还有一个技巧在提示词末尾加一句“只输出 JSON不要输出任何其他文字”。这能防止模型在 JSON 前后加解释性文字。2.6 迭代优化模块提示词不是一次写好的是迭代出来的。我通常的迭代流程是写初版按上述五个模块写一版提示词小样本测试用 5-10 个典型输入测试分析失败案例看哪些输入输出不符合预期定位问题模块是角色定义不够精准还是任务描述有歧义还是缺少示例修改提示词针对性地调整回归测试用之前的测试集重新测试确保修改没有引入新问题这个流程听起来很工程化但实际操作起来很快。我通常迭代 3-5 轮就能让提示词在测试集上达到 90% 以上的准确率。3. 从零搭建一套可复用的提示词框架前面讲了理论这一章我带你从零搭建一套完整的提示词框架。我会用一个实际场景来演示从用户反馈中提取产品改进建议并分类。这个场景足够通用你可以把它迁移到自己的任务上。3.1 场景分析与需求拆解在写提示词之前先要搞清楚任务到底是什么。我通常会问自己几个问题输入是什么用户反馈文本可能是一条也可能是多条输出是什么结构化的改进建议列表每条包含建议内容、类别、优先级难点在哪里用户反馈可能很模糊、可能包含多条建议、可能只是情绪发泄怎么判断输出好坏提取的建议是否准确、分类是否合理、是否遗漏了重要信息把这些想清楚之后再开始写提示词。3.2 第一版提示词快速验证第一版不需要完美目标是快速验证方向对不对。我通常会写一个最简版本你是一位产品经理擅长从用户反馈中提取改进建议。 请从以下用户反馈中提取产品改进建议并分类到功能需求、体验优化、性能问题、界面设计、其他。 用户反馈 {{feedback}} 输出格式 - 建议内容 | 类别这个版本很简单但已经包含了角色定义、任务描述、输出格式三个核心模块。用它跑几条测试数据看看模型能不能理解任务。3.3 第二版提示词增加约束和示例第一版跑下来你可能会发现一些问题模型有时候会把情绪表达也当成建议、有时候分类不准确、有时候输出格式不统一。这时候就需要增加约束和示例。你是一位资深产品经理有 8 年 B 端产品设计经验擅长从用户反馈中提取可落地的产品改进建议。 ## 任务 从以下用户反馈中提取产品改进建议并分类。 ## 分类标准 - 功能需求用户希望增加新功能或修改现有功能 - 体验优化用户希望操作更顺畅、更符合习惯 - 性能问题涉及加载速度、响应时间、稳定性 - 界面设计涉及视觉、布局、交互设计 - 其他不属于以上类别的建议 ## 约束 - 只提取具体的、可执行的建议不要提取纯情绪表达 - 如果一条反馈包含多个建议拆分成多条 - 如果反馈中没有具体建议输出“无具体建议” - 不要编造反馈中没有提到的内容 ## 示例 输入这个页面加载太慢了每次都要等好几秒能不能优化一下 输出建议内容优化页面加载速度 | 类别性能问题 输入我希望能够批量导出数据现在一条一条导出太麻烦了。 输出建议内容增加批量导出功能 | 类别功能需求 输入这个按钮的颜色太浅了我根本看不清。 输出建议内容加深按钮颜色提高对比度 | 类别界面设计 ## 实际输入 {{feedback}} ## 输出格式 以 JSON 数组输出 [ { suggestion: 建议内容, category: 类别, original_text: 对应的原文片段 } ]这一版增加了分类标准、约束条件、少样本示例和结构化输出格式。跑下来效果会明显好很多。3.4 第三版提示词处理边界情况第二版在大多数情况下表现不错但遇到一些边界情况还是会出问题。比如反馈是英文的怎么办反馈包含多个建议但混在一起怎么办反馈是讽刺或反话怎么办针对这些问题再增加一轮约束## 边界情况处理 - 如果反馈是英文先翻译成中文再处理 - 如果一条反馈包含多个建议拆分成多条输出 - 如果反馈包含讽刺或反话按字面意思理解不要过度解读 - 如果反馈涉及多个类别选择最相关的一个类别 - 如果反馈信息不足在 suggestion 中注明“信息不足需要进一步了解”3.5 提示词模板的模块化封装当你写了多个场景的提示词之后你会发现很多模块是通用的。比如角色定义、约束条件、输出格式控制这些在不同任务中结构类似。这时候就可以做模块化封装。我的做法是维护一个“提示词组件库”包含角色定义组件不同身份的角色定义模板约束组件常见的约束条件如“不要编造信息”“如果信息不足请说明”输出格式组件JSON、XML、Markdown 表格等格式的模板示例组件不同任务的少样本示例模板当你需要写一个新提示词时从组件库里挑选合适的模块组合起来再针对具体任务调整。这样效率会高很多。3.6 不同模型的适配策略不同模型对提示词的敏感度不同。我实测下来的一些经验模型类型特点提示词策略GPT-4 系列理解能力强对模糊指令容忍度高可以适当精简重点放在输出格式控制Claude 系列对格式要求严格喜欢结构化输入用 XML 标签分隔不同模块效果更好国产大模型对中文指令理解好但格式遵循能力参差输出格式要非常明确最好给示例开源模型指令遵循能力较弱需要更多示例约束要更硬这个表格不是绝对的但可以作为起点。你拿到一个新模型先用同一套提示词跑一遍看输出质量再针对性调整。4. 提示词工程在智能体开发中的实战应用提示词工程在智能体开发中尤为重要因为智能体需要稳定、可靠、可预测的行为。一个聊天机器人偶尔说错话没关系但一个自动处理订单的智能体如果理解错了指令后果可能很严重。4.1 智能体中的提示词分层架构在智能体开发中我通常会把提示词分成三层第一层系统提示词System Prompt这是智能体的“人格”和“行为准则”在整个会话过程中保持不变。它定义了智能体的身份、能力边界、回复风格、安全约束等。第二层任务提示词Task Prompt这是针对具体任务的指令每次任务不同。比如用户让智能体查订单任务提示词就是“查询订单状态”的相关指令。第三层上下文提示词Context Prompt这是动态注入的上下文信息比如用户的历史订单、当前时间、之前的对话记录等。这三层提示词组合在一起形成最终发给模型的完整提示词。分层的好处是可维护性——系统提示词改一次所有任务都生效任务提示词只影响特定任务上下文提示词动态生成不污染前两层。4.2 工具调用中的提示词设计智能体通常需要调用外部工具查数据库、调 API、发邮件等。工具调用的提示词设计有几个关键点第一工具描述要精确。你要告诉模型这个工具是干什么的、需要什么参数、返回什么结果。描述越精确模型调用越准确。第二参数格式要明确。如果工具需要 JSON 参数你要在提示词里给出参数结构示例。第三调用条件要清晰。什么情况下应该调用这个工具什么情况下不应该这个边界要划清楚。我通常会用这样的格式来描述工具## 可用工具 ### 查询订单 - 功能根据订单号查询订单状态 - 参数 - order_id: string, 订单号格式为 ORD-XXXXXXXX - 返回订单状态、下单时间、预计送达时间 - 调用条件当用户询问订单状态且提供了订单号时调用 - 不调用条件用户没有提供订单号时先追问订单号4.3 多轮对话中的提示词管理多轮对话是智能体开发中最容易出问题的地方。因为上下文会越来越长模型可能会“忘记”之前的指令或者被后面的对话带偏。我的做法是第一每轮对话都重新注入系统提示词。不要假设模型记得上一轮的系统提示词。每轮都把系统提示词放在最前面。第二控制上下文长度。如果对话历史太长只保留最近 N 轮或者对历史对话做摘要。第三关键约束重复强调。如果某个约束特别重要比如“不要泄露用户隐私”在每轮对话的末尾再强调一次。第四用状态变量管理对话状态。不要依赖模型记住对话状态而是用外部变量记录当前状态每轮把状态注入提示词。4.4 提示词版本管理与 A/B 测试当你的智能体上线之后提示词的修改需要谨慎。我通常的做法是版本管理每次修改提示词都记录版本号、修改内容、修改原因A/B 测试新版本提示词先在小流量上测试对比关键指标任务完成率、用户满意度、平均对话轮数回滚机制如果新版本指标下降能快速回滚到旧版本灰度发布逐步扩大新版本的流量比例观察指标变化这些做法听起来很“工程”但实际做起来并不复杂。关键是要有记录、有对比、有回滚。5. 常见问题与排查技巧实录这一章我整理了一些在实际操作中经常遇到的问题和解决方法。这些问题大多是我自己踩过的坑或者帮别人排查时遇到的。5.1 模型不按格式输出怎么办这是最常见的问题。你明明写了“以 JSON 格式输出”模型却给你输出一段带解释的文字。解决方法第一检查格式定义是否完整。你有没有给出完整的 JSON 结构字段名、类型、嵌套关系都写清楚了吗第二在提示词末尾加一句“只输出 JSON不要输出任何其他文字”。这句话很管用。第三给一个输出示例。模型看到示例之后遵循格式的概率会大幅提升。第四如果还是不行用“预填充”技巧。在提示词末尾加上{让模型从{开始续写。这样模型就只能输出 JSON 了。5.2 模型输出太长或太短怎么办长度控制是另一个常见问题。解决方法明确指定字数范围“输出 100-150 字”指定段落数“输出 3 个段落”指定要点数“列出 5 个要点”给示例给一个长度合适的示例模型会模仿如果模型总是输出太长还有一个技巧在提示词里加一句“简洁回答不要展开解释”。如果总是太短加一句“详细说明每个要点至少 50 字”。5.3 模型“幻觉”怎么处理幻觉是指模型编造不存在的信息。在需要精确执行的场景下幻觉是致命的。处理方法第一明确约束“只使用提供的材料不要编造任何信息”。第二要求引用来源“每个结论都必须引用原文中的具体语句”。第三信息不足时要求说明“如果信息不足直接说明需要更多信息不要猜测”。第四用少样本示例展示“不知道”的情况给一个“信息不足”的示例让模型知道这种情况应该怎么处理。5.4 提示词效果不稳定的排查思路有时候同一套提示词有时候效果好有时候效果差。排查思路可能原因排查方法解决方法输入格式不一致检查输入数据是否有格式差异统一输入格式或在提示词中处理多种格式上下文长度超限检查输入是否过长截断或摘要输入模型版本变化确认模型是否更新重新测试必要时调整提示词温度参数设置检查 temperature 设置需要稳定输出时设为 0 或 0.1提示词有歧义让不同人读提示词看理解是否一致消除歧义增加示例5.5 提示词优化的常见误区最后说几个我见过的常见误区误区一提示词越长越好。不是。提示词太长会占用上下文窗口而且可能让模型“迷失”在细节里。关键是精准不是长度。误区二一套提示词走天下。不同任务、不同模型、不同场景提示词都需要调整。没有万能模板。误区三只调提示词不调参数。temperature、top_p、max_tokens 这些参数对输出影响很大。需要稳定输出时temperature 设低需要创意时temperature 设高。误区四不测试就上线。提示词必须经过充分测试才能上线。我通常至少用 20-30 个测试用例验证覆盖正常情况和边界情况。误区五忽略负面示例。除了告诉模型“应该怎么做”还要告诉它“不应该怎么做”。负面示例能有效减少错误输出。6. 提示词工程的进阶方向如果你已经掌握了前面的内容想进一步提升可以关注这几个方向。6.1 自动提示词优化手动调提示词效率有限。现在有一些工具和方法可以自动优化提示词比如用另一个模型来生成和评估提示词变体然后选择效果最好的。这个方向适合有工程能力的团队。6.2 提示词与微调的配合提示词工程和模型微调不是互斥的。对于高频、固定的任务微调可能比提示词更稳定、更高效。对于低频、多变的任务提示词更灵活。实际项目中通常是两者结合用微调让模型掌握基础能力用提示词处理具体任务。6.3 多智能体协作中的提示词设计在多智能体系统中每个智能体有自己的角色和提示词智能体之间需要协作。这时候提示词设计要考虑智能体之间怎么通信、任务怎么分配、冲突怎么解决。这是一个更复杂的领域但核心原则是一样的明确角色、明确任务、明确约束、明确输出格式。6.4 提示词安全与对抗提示词注入是一个真实存在的安全问题。用户可能在输入中嵌入恶意指令试图让智能体执行非预期操作。防御方法包括输入过滤、指令隔离、输出审查等。这个方向在智能体上线后尤其重要。我个人在实际操作中的体会是提示词工程没有捷径就是理解任务、理解模型、持续迭代。你看到的那些“战无不胜”的提示词背后都是大量测试和调整的结果。与其到处找模板不如踏踏实实掌握方法论针对自己的场景写出真正好用的提示词。