1. 为什么你的提示词总是不好用很多人第一次接触大模型脑子里想的都是“我问什么它答什么”结果上手一用发现完全不是那么回事。你问它“帮我写个方案”它给你来一篇四平八稳的八股文你让它“优化一下代码”它把变量名改了一遍就还给你了你问它“这个数据说明什么”它洋洋洒洒写了一大段仔细一看全是正确的废话。于是你开始怀疑是不是模型不行是不是我用的版本太低了我刚开始折腾 AI Agent 的时候也这么想过。后来踩了足够多的坑才明白问题十有八九出在提示词上。大模型就像一个能力极强但完全不懂你心思的新人你不把话说清楚它就只能靠猜。而提示工程要解决的核心问题就一个怎么把你脑子里的意图无损地翻译成模型能精确执行的指令。这件事听起来简单做起来全是细节。同样一个任务提示词差几个字输出质量可能天差地别。我见过太多人花大价钱调 API、换模型、加算力结果提示词还是“帮我写个xxx”这种水平然后抱怨模型不好用。这就像你请了个米其林大厨然后跟他说“随便做点吃的”最后嫌人家做的不是你想要的。这篇文章是 AI Agent 学习之路系列的第二篇专门聊提示词和提示工程。我会从底层逻辑讲起把提示词为什么有效、怎么设计、怎么迭代、怎么避坑全部拆开揉碎讲清楚。不管你是刚入门的新手还是已经写过一些提示词但效果不稳定的朋友都能从里面找到可以直接用的方法和思路。2. 提示工程的底层逻辑模型到底在做什么2.1 大模型不是搜索引擎它是概率接龙高手要理解提示工程首先得搞清楚大模型到底在干什么。很多人下意识地把大模型当成一个更聪明的搜索引擎觉得输入关键词就能得到答案。这个理解偏差是很多提示词写不好的根源。大模型的本质是一个自回归语言模型。说人话就是它根据你给的前文一个词一个词地预测下一个最可能出现的词。你输入“今天天气”它预测下一个词可能是“真”再下一个可能是“好”连起来就是“今天天气真好”。它不是在“查询”什么而是在“续写”什么。这个认知非常关键。因为这意味着你输入的每一个字都在为模型设定“接下来应该写什么”的概率分布。你写“帮我写个方案”模型看到的是“方案”这个词后面通常跟着什么内容——大概率是那种格式工整、面面俱到但没什么针对性的通用文档。但如果你写“帮我写一个面向三线城市社区超市老板的促销活动方案预算五千块目标是清掉一批临期饮料”模型看到的就完全不同了它会激活训练数据中与“社区超市”“促销”“临期清仓”相关的模式输出的内容自然就更贴近你的需求。所以提示工程的第一性原理就是你给的上下文越具体、越有指向性模型预测出的内容就越接近你想要的。这不是玄学是概率。2.2 提示词的四个核心功能层我习惯把提示词拆成四个功能层来看这样设计的时候不容易漏东西角色层告诉模型“你是谁”。比如“你是一个有十年经验的 Python 后端工程师”。这一层的作用是激活模型训练数据中与这个角色相关的语言模式和知识领域。你不指定角色模型就会用一个“平均人”的口吻来回答什么都知道一点但什么都不深。任务层告诉模型“你要做什么”。这是最核心的部分必须具体、可执行、有边界。比如“审查以下代码中的安全漏洞”就比“看看这段代码”好得多。约束层告诉模型“你不能做什么”和“你必须满足什么条件”。比如“不要使用第三方库”“输出必须控制在 200 字以内”“如果信息不足直接说不知道不要编造”。约束层是区分新手和老手的关键新手往往只写任务层老手会把约束写得明明白白。格式层告诉模型“输出长什么样”。比如“用 Markdown 表格输出”“每段不超过三句话”“先给结论再给理由”。格式层直接影响输出的可用性尤其是在做 AI Agent 的时候格式不对后面根本没法解析。这四个层不是必须全部出现但你在设计提示词的时候脑子里过一遍这四层就能快速发现哪里没说到位。2.3 为什么“鹈鹕骑自行车”成了经典测试你可能在热搜里看到过“鹈鹕骑自行车提示词”这个词。这其实是一个在 AI 圈子里流传很广的测试用例用来检验模型的空间推理和指令遵循能力。经典的版本大概是这样的让模型生成一个 SVG 图像画一只鹈鹕骑自行车。这个测试之所以经典是因为它同时考察了多个维度模型是否理解“鹈鹕”和“自行车”这两个物体的结构关系是否能正确处理“骑”这个动作带来的空间位置约束是否能在 SVG 代码中把这些关系表达出来。很多模型生成的鹈鹕要么飘在自行车上方要么腿长在奇怪的位置要么自行车轮子变成了方形。这个案例给我们的启示是提示词中的空间关系、动作关系、逻辑关系是模型最容易出错的地方。你在写提示词的时候如果涉及这类关系一定要额外花心思去描述清楚。比如不要只说“画一只鹈鹕骑自行车”而要说“鹈鹕坐在自行车座垫上两只翅膀向前伸抓住车把两只脚踩在脚踏板上自行车有两个圆形轮子”。多出来的这些描述就是在帮模型缩小概率搜索空间。3. 提示词设计的核心方法论3.1 从“说清楚”到“说得让模型能执行”很多人觉得自己已经把需求说清楚了但模型就是听不懂。问题往往在于人类语言天然带有大量隐含信息而模型不会自动补全这些隐含信息。举个例子。你说“帮我分析一下这个季度的销售数据”你觉得说清楚了。但模型不知道数据在哪什么格式分析什么维度同比还是环比要图表还是文字给谁看这些你脑子里默认的东西模型一概不知。所以提示词设计的第一条铁律是把你脑子里默认的、觉得“不用说也知道”的东西全部写出来。写出来之后你会发现原来自己以为的“说清楚了”其实只说了十分之一。我常用的一个检查方法是把提示词发给一个完全不了解背景的同事看他能不能准确理解你要什么。如果他有疑问模型大概率也有。3.2 结构化提示词的黄金公式经过大量实践我总结了一个比较通用的结构化提示词公式适合大多数任务场景角色 背景 任务 约束 输出格式 示例这个公式不是死的但作为一个检查清单非常好用。我逐项说一下角色要具体到领域和经验级别。“你是一个数据分析师”不如“你是一个有五年电商行业经验的数据分析师擅长从销售数据中发现异常和机会”。背景要提供任务相关的上下文。比如“我们是一个主打性价比的国货美妆品牌主要用户是 18-25 岁女性本季度销售额环比下降了 12%”。任务要用动词开头明确可执行。“分析销售数据”不如“找出销售额下降的主要原因并给出三个可执行的改进建议”。约束要写清楚边界。“不要给出需要额外预算的建议”“所有建议必须基于现有团队能力”“如果数据不足以支撑结论明确说明”。输出格式要具体。“用表格输出”不如“用 Markdown 表格输出三列分别是问题、原因、建议每行不超过 50 字”。示例是最容易被忽略但效果最猛的部分。给一个输入输出的例子模型就能瞬间理解你要的风格和粒度。这在做批量任务的时候尤其重要。3.3 少样本提示给例子比讲道理管用在提示工程里有一个被反复验证的结论给模型看例子比跟模型讲道理有效得多。这就是少样本提示的核心思想。比如你要让模型把用户反馈分类成“功能建议”“Bug 反馈”“投诉”“咨询”四类。你写一大堆分类标准模型可能还是分不准。但如果你给几个例子“希望增加夜间模式” → 功能建议“点击保存按钮没反应” → Bug 反馈“你们这个收费太不合理了” → 投诉“怎么修改绑定的手机号” → 咨询模型立刻就能抓住分类的粒度。一般来说每个类别给 2-3 个例子就够了太多反而会占用上下文窗口增加成本。少样本提示还有一个进阶用法给模型看“坏例子”和“好例子”的对比。比如在文案生成任务中你可以先给一个“太笼统”的版本再给一个“具体生动”的版本模型就能理解你想要的风格方向。3.4 思维链让模型把思考过程写出来思维链是提示工程里另一个非常重要的技术。核心思想很简单让模型在给出最终答案之前先把推理过程写出来。为什么这招管用因为大模型是逐词生成的如果它直接输出答案那答案是在没有中间推理步骤的情况下“猜”出来的。但如果它先写推理过程那答案就是基于前面写出来的推理“推导”出来的。后者显然更可靠。触发思维链最简单的方式就是在提示词里加一句“请一步一步思考”或者“先分析再给结论”。对于复杂任务你还可以指定思考的步骤比如“第一步提取关键信息第二步分析可能的原因第三步给出建议”。不过要注意思维链会增加输出长度和 token 消耗。对于简单任务没必要强行加思维链。另外有些模型在输出思维链之后最终答案反而变得啰嗦这时候可以在提示词里加一句“推理过程用简洁的语言最终答案单独用一段给出”。4. 提示工程在 AI Agent 中的实战应用4.1 Agent 的提示词和普通对话有什么不同普通对话的提示词目标是“让模型给出一个好回答”。但 AI Agent 的提示词目标是“让模型在正确的时间做出正确的决策并输出可被程序解析的结果”。这个区别非常大。Agent 通常需要模型做这些事情理解用户意图、决定调用哪个工具、生成工具调用参数、解析工具返回结果、决定下一步动作、最终生成回复。每一个环节都需要提示词来引导而且每个环节的输出格式都必须严格可控。我踩过的一个典型坑是在工具调用环节提示词没有严格约束输出格式模型有时候输出 JSON有时候输出自然语言描述有时候在 JSON 外面加一段解释。结果就是程序解析经常失败Agent 动不动就卡住。后来我在提示词里加了非常明确的格式约束并且给了正反两个例子才把这个问题解决。4.2 系统提示词的设计要点系统提示词是 Agent 的“宪法”它定义了 Agent 的身份、能力边界、行为准则和输出规范。我一般会把系统提示词分成几个模块来写身份模块明确 Agent 是谁、服务谁、核心目标是什么。比如“你是一个电商客服助手服务对象是购买了我们产品的用户核心目标是准确解答问题并引导用户完成售后流程”。能力模块列出 Agent 可以调用的工具和各自的使用场景。比如“你可以调用订单查询工具当用户询问订单状态时使用你可以调用退款申请工具当用户明确要求退款且符合条件时使用”。约束模块写清楚什么能做、什么不能做。比如“不要承诺任何未经确认的赔付”“不要讨论与产品无关的话题”“如果用户情绪激动先安抚再解决问题”。流程模块定义标准处理流程。比如“先确认用户身份再查询订单再根据问题类型选择处理方式”。格式模块规定输出格式。比如“所有工具调用必须输出 JSON 格式包含 tool_name 和 parameters 两个字段”。系统提示词写得好不好直接决定了 Agent 的上限。我见过很多 Agent 项目模型选得很好工具也齐全但系统提示词写得太随意导致 Agent 行为不稳定时而聪明时而犯傻。4.3 上下文工程比提示词更大的局最近“上下文工程”这个词越来越热它其实是提示工程的超集。提示工程关注的是“怎么写指令”上下文工程关注的是“在模型的上下文窗口里放什么信息”。一个 Agent 在运行过程中上下文窗口里可能有系统提示词、历史对话、工具调用记录、工具返回结果、用户上传的文档、检索到的知识库片段等等。这些东西怎么组织、怎么排序、怎么压缩直接影响到模型的表现。我总结的几个上下文工程原则相关性优先把最相关的信息放在离当前任务最近的位置。模型对上下文开头和结尾的信息注意力最强中间部分容易被忽略。信息密度优先同样长度的上下文信息密度越高越好。不要把原始文档整段塞进去先做摘要或提取关键段落。格式一致性上下文中的信息格式要统一不要一会儿 JSON 一会儿自然语言一会儿表格模型处理起来容易混乱。及时清理历史对话太长的时候要做摘要或截断不要让无关信息占用宝贵的上下文空间。5. 提示词迭代与优化的实操方法5.1 建立你的提示词版本管理习惯我刚开始写提示词的时候改来改去都是在一个文本框里直接编辑改完就忘了之前是什么样。结果有一次改坏了想回退都回不去。后来我养成了一个习惯每个提示词都存成独立文件用版本号管理每次修改都记录改了什么、为什么改、效果如何。这个习惯看起来麻烦但实际非常省时间。因为提示词优化是一个反复试错的过程你经常需要对比不同版本的效果。有了版本记录你就能清楚地看到哪个改动带来了提升哪个改动其实是在退步。我一般用这样的格式记录版本v1.3 修改内容在约束层增加了“如果用户问题涉及退款必须先确认订单状态” 修改原因之前有用户未收货就申请退款Agent 直接同意了导致流程错误 效果退款流程错误率从 15% 降到 3%5.2 用测试集来评估提示词效果凭感觉判断提示词好不好非常不靠谱。你今天觉得这个版本好明天可能又觉得那个版本好。解决办法是建一个小型测试集每次修改提示词后跑一遍用数据说话。测试集不需要很大20-50 条就够。关键是覆盖各种典型场景和边界情况。比如做客服 Agent测试集里要有正常咨询、情绪激动的投诉、信息不完整的询问、超出范围的问题、恶意输入等等。评估指标根据任务来定。分类任务看准确率生成任务可以看人工评分或关键信息覆盖率Agent 任务可以看任务完成率和平均交互轮数。我自己的经验是测试集建好之后提示词优化的效率至少提升一倍。因为你能快速排除那些“感觉变好了其实没变好”的改动把精力集中在真正有效的方向上。5.3 常见提示词反模式在大量实践中我总结了一些反复出现的提示词反模式避开它们能少走很多弯路反模式一指令堆砌。把一堆要求全部塞进一段话里没有层次。模型处理这种提示词时容易顾此失彼。解决办法是分模块、分段落写。反模式二否定式指令。比如“不要写得太长”“不要用专业术语”。模型对否定指令的处理能力比较弱你说“不要想大象”它脑子里反而全是大象。更好的方式是正面描述“控制在 200 字以内”“用初中生能听懂的语言”。反模式三模糊量词。比如“写详细一点”“稍微正式一些”。“详细”是多详细“正式”是什么程度模型只能猜。换成“每个步骤至少包含三个操作细节”“使用商务邮件风格的措辞”。反模式四缺少失败处理。只告诉模型“怎么做对”没告诉它“做不对怎么办”。结果模型遇到不确定的情况就硬编。加上“如果信息不足明确说明缺少什么信息不要编造”能大幅降低幻觉。反模式五一次性给太多任务。一个提示词里让模型同时做总结、翻译、分类、生成回复。模型可能每样都做一点但每样都做不好。拆成多个步骤每个步骤一个提示词效果通常更好。6. 常见问题与排查技巧实录6.1 模型不按格式输出怎么办这是最高频的问题之一。你明明要求输出 JSON它偏要在前面加一段“好的以下是 JSON 格式的输出”或者在 JSON 里用单引号或者多一个尾逗号。我的排查思路是这样的首先检查格式约束是否足够明确。不要只说“输出 JSON”要说“输出一个合法的 JSON 对象不要包含任何 JSON 之外的文字字符串使用双引号不要有尾逗号”。把常见的格式错误都提前堵住。其次给一个格式示例。模型对示例的遵循度远高于对规则描述的遵循度。给一个完整的输入输出示例比写十条规则都管用。第三如果还是不行考虑用结构化输出功能。现在很多模型 API 都支持 JSON mode 或 function calling能从底层保证输出格式。能用底层能力解决的不要靠提示词硬掰。第四在程序侧做容错。解析失败的时候尝试提取 JSON 部分、修复常见格式错误、或者重试一次。不要假设模型永远输出完美格式。6.2 提示词效果不稳定怎么排查同一个提示词有时候效果好有时候效果差这种问题最让人头疼。我的排查清单是这样的先看输入是否稳定。如果输入本身变化很大输出不稳定是正常的。检查是不是某些特殊输入触发了模型的异常行为。再看上下文是否干净。历史对话里有没有无关信息、错误信息、矛盾信息这些都会干扰模型判断。然后看温度参数。温度越高输出随机性越大。如果任务需要稳定输出把温度调低甚至调到 0。还要看模型版本。有些模型 API 会静默更新版本导致行为变化。如果突然效果变差检查一下模型版本有没有变。最后看提示词本身有没有歧义。同一个提示词不同人理解可能不同模型也一样。找几个同事读一遍看他们理解是否一致。6.3 提示词被标记违规怎么处理有时候你会遇到“invalid prompt: your prompt was flagged as potentially violating our usage”这样的报错。这通常是因为提示词中包含了某些被安全策略拦截的内容。处理这类问题的原则是先检查提示词本身是否有不当内容如果有就修改如果没有尝试换一种表达方式。很多时候是某些词汇组合触发了误判换个说法就能通过。另外不同平台的安全策略严格程度不同。如果你在某个平台上反复遇到误判可以考虑调整提示词的表述方式或者联系平台确认具体原因。但无论如何确保你的提示词内容本身是合规的这是底线。6.4 提示词太长导致效果下降怎么办上下文窗口是有限的提示词太长会挤占其他信息的空间也会增加成本和延迟。当提示词超过一定长度后模型对中间部分的注意力会下降效果反而变差。我的处理方法是分层管理把提示词分成“必须每次携带”和“按需加载”两部分。系统提示词、核心约束这些每次都要但具体的示例、详细的背景信息可以按需注入。压缩表达同样的意思用更少的字说清楚。删掉客套话、重复强调、无关背景。动态组装根据当前任务类型从提示词库中选取相关的模块组装。不要把所有场景的提示词都塞在一起。定期审查每隔一段时间回顾提示词删掉那些“加了但从来没起作用”的部分。7. 从提示词到 Agent 的进阶思路7.1 提示词工程和微调怎么选很多人会纠结到底是把提示词写好还是直接微调模型我的判断标准很简单如果任务规则明确、可以通过文字描述清楚、且不需要模型学习新的知识或风格优先用提示词工程。提示词工程成本低、迭代快、可解释性强。如果任务需要模型掌握特定的输出风格、领域术语、或者提示词怎么写都达不到效果再考虑微调。微调成本高、周期长但一旦调好稳定性和效果上限更高。实际项目中我通常先用提示词工程把效果推到瓶颈再评估是否值得微调。很多时候提示词优化到位了根本不需要微调。7.2 多 Agent 协作中的提示词设计当系统从单 Agent 进化到多 Agent 协作时提示词设计会变得更复杂。每个 Agent 有自己的角色和职责它们之间需要通信和协调。我的经验是每个 Agent 的系统提示词要明确它的“职责边界”和“协作接口”。职责边界是说清楚它负责什么、不负责什么避免多个 Agent 抢活或者互相推诿。协作接口是定义它接收什么格式的输入、输出什么格式的结果保证 Agent 之间能顺畅对接。另外多 Agent 系统中要有一个“协调者”角色负责拆解任务、分配工作、汇总结果。协调者的提示词要特别强调任务分解和结果整合的能力。7.3 提示词工程的未来方向提示词工程这个领域变化很快。从最早的简单指令到少样本提示、思维链再到现在的上下文工程、Agent 编排每隔一段时间就有新东西出来。我个人比较关注几个方向一是自动化提示词优化用模型来优化提示词减少人工试错二是提示词和工具调用的深度融合让模型更自然地使用外部能力三是多模态提示词不只是文字还包括图像、音频、视频的提示设计。但不管技术怎么变核心逻辑是不变的理解模型的运作机制把意图翻译成模型能精确执行的形式用数据验证效果并持续迭代。把这个基本功练扎实新工具新方法出来的时候上手会快很多。8. 我踩过的那些坑和总结的经验说几个我实际踩过的坑都是真金白银换来的教训。第一个坑提示词写得太“聪明”。我一开始喜欢用很精炼的语言写提示词觉得模型应该能理解。结果发现模型不是人它不会“意会”。你觉得精炼它觉得信息不足。后来我改成“啰嗦但明确”的风格效果反而好很多。提示词不是写诗不需要含蓄。第二个坑忽略负面示例。我只告诉模型“要输出什么”没告诉它“不要输出什么”。结果模型经常输出一些格式正确但内容跑偏的东西。后来我在提示词里加了“不要输出以下内容”的负面示例效果立竿见影。第三个坑一次改太多。优化提示词的时候我同时改了角色描述、任务描述和格式约束结果效果变差了但不知道是哪个改动导致的。后来我改成每次只改一个地方改完跑测试集确认有效再改下一个。慢是慢了点但方向清晰。第四个坑不记录不复盘。早期改提示词全靠记忆改着改着就乱了。后来开始做版本管理和效果记录才发现很多“优化”其实是在原地打转甚至是在退步。记录本身就是一种优化。第五个坑忽视 token 成本。提示词越写越长效果确实好了一点但 token 消耗翻了好几倍。后来我开始有意识地压缩提示词删掉冗余表达在效果和成本之间找平衡。毕竟 Agent 是要跑量的单次成本差一点规模化之后差距就大了。最后分享一个我觉得最有用的习惯每次遇到效果不好的情况先别急着改提示词先问自己“模型看到的信息够不够做出正确判断”。大多数时候问题不是模型笨而是你给的信息不够。把信息补全问题往往就解决了。