最近圈子里流传一个很火的测试题让大模型生成一只骑自行车的鹈鹕而且要求给出SVG代码。头一回看到我问号拉满觉得不过是娱乐梗结果真拿几个模型跑了一遍差距一下就出来了——有的模型把自行车画成三个轮子有的让鹈鹕直接站在车把上还有的给你一段华丽文字描述SVG一运行全是报错。这道题能火本质上是戳中了所有用大模型的人最痛的感受需求明明说清楚了它偏偏给你来个答非所问。这背后就是提示词工程Prompt Engineering的活儿。作为 AI Agent 学习之路系列的第二篇这篇不打算堆概念而是从为什么提示词不顶用这个真问题出发把大模型听人话的底层机制、可以直接抄下来的提示词模板、调试迭代的方法论以及从单轮对话走向 Agent 开发时提示词要面对的新挑战一次讲透。正在从0到1搭自己的第一个 Agent 的朋友或者已经被模型输出折磨到想摔键盘的朋友这篇文章应该能帮上忙。1. 鹈鹕骑自行车测试到底在测什么指令遵循能力才是听懂的真本事1.1 一道让不少模型翻车的提示词题先说这道题的原始形态。网上流传的版本通常是这样一句话请用SVG代码画一个骑自行车的鹈鹕要求自行车结构完整鹈鹕坐在车座上脚放在踏板上画面简洁。从字面上看没有任何生僻词语法也通顺可模型的表现往往让人哭笑不得。我拿几个主流模型实测失败模式主要分这么几类只画主体不画道具鹈鹕倒是有了自行车整个消失把关系搞错鹈鹕不是骑自行车而是站在车架上方甚至有人碰到过自行车被画成另一只鸟的离谱输出自行补剧情擅自给鹈鹕加帽子、加围巾还标榜画面更生动格式翻车文字描述头头是道给的SVG代码打开后却是空白或报错。这道题妙就妙在它不是考察模型会不会画——几乎所有模型都在训练语料里见过无数自行车和鹈鹕——而是考察它在同时处理多个约束时能不能一项不落地把要求落进输出里。我第一次跑出翻车结果时第一反应是这模型是不是傻了后来才意识到这是几乎所有大模型的通病只是平时没人拿这种刁钻题目去戳它。1.2 三层约束叠加后听懂就成了遵守拆开看这道题的约束其实叠了三层。第一层是内容理解把鹈鹕自行车骑这些要素识别出来难点不是认得这些词而是把动作关系正确建模第二层是约束保持模型必须记住要有完整自行车鹈鹕要坐在车座上脚要放在踏板上这一堆条件生成过程中不能遗漏任何一个第三层是格式遵守输出必须是可运行的SVG代码而不是一大段看着像样的文字描述。大多数翻车案例问题都出在后两层。也就是说大模型其实听懂了你的话但它没有遵守你的全部要求。这个区别比想象中重要得多——尤其在做 Agent 的时候你给 Agent 的每一条指令最终都会转化为可执行行为模型丢一条约束整个流程可能就偏了。所以提示词工程的第一步不是学什么华丽话术而是接受一个残酷事实模型默认不保证遵守你需要用提示词把遵守这件事显性化。2. 大模型是怎么听懂的提示词有效性的底层逻辑2.1 它其实不是逐条执行而是概率续写要搞清楚提示词为什么有用得先抛开模型是台听话的计算机这个错觉。现役主流的大模型底层都是基于 Transformer 架构的下一个Token预测器你给它一段输入序列它在参数空间里计算每个候选Token出现的概率然后挑一个或按概率采样作为下一个输出再把这个输出接回输入继续预测下一位。这意味着你输入的每一个词、每一个标点都在改变下一个Token的概率分布。提示词的本质就是把模型的概率分布挤压到你想要的区域里。举一个最直观的例子同样问给我一个排序算法和请写一个Python函数输入整数列表返回从小到大排序后的新列表后一句把语言范围Python、任务类型写函数、输入输出列表都钉死了模型可发挥的空间急剧缩小输出自然就往你期望的方向靠。刚开始学提示词的人最容易犯的错就是把大模型当搜索引擎或者当成能读懂潜台词的人。实际上它既不会搜索你脑子里的完整意图也不会自动脑补你没说的背景信息。你以为自己表达清楚了但在模型眼里你的话只是概率空间里的几个坐标点。提示词工程说穿了就是一门用词精准锁定坐标的手艺。2.2 角色扮演为什么真的有效上下文预热很多人觉得你是一个资深Python工程师这种角色扮演是玄学但它背后有合理的机制解释模型在预训练时看过海量的技术问答、代码讨论片段其中资深工程师回答问题的模式反复出现。当你在提示词里明确指定角色等于在开头就给模型设定了一个语境开关引导它沿着与这个角色相关的高概率路径往下生成。这里还有个容易忽略的点角色设定要具体不要泛泛。你说你是工程师模型可能真的就按普通工程师的腔调回话你说你是写过多年爬虫脚本的工程师熟悉反爬和异常处理输出里的技术细节密度立刻不一样。当然角色扮演不是万能的它影响的是表达方式和知识倾向而不是给模型凭空增加知识。如果任务本身需要的信息不在模型的知识范围内角色设定得再深它也编不出来这时需要的是技术选型或者外部检索这在后面讲上下文工程时会展开。2.3 先提示词后微调别一上来就想着改模型和提示词相邻的概念是大模型微调。很多朋友遇到输出不理想第一反应是要不微调一下。微调是修改模型的权重相当于在训练阶段重新塑造它的行为习惯成本高、周期长还容易把模型带偏到某一类风格上。而提示词是在推理阶段动态约束行为零成本、即时生效、随时可改。我自己的判断标准很简单先问运行时能不能解决。能用更好的提示词、更全的上下文、更准的检索解决的问题就不要上微调。实际上绝大多数 Agent 项目里遇到的输出问题都是上下文信息不够、约束不明确、或示例缺失造成的这些恰好都在提示词和上下文工程的射程范围内。等你把提示词压榨到极限依然达不到效果再回头研究微调和更复杂的架构顺序别搞反。3. 一套能直接抄作业的提示词骨架结构化是稳定输出的前提3.1 我常用的五段式结构角色、背景、任务、约束、输出如果你的提示词还停留在帮我写个XXX的原始形态建议立刻换成下面这个结构。我在这几年的项目里反复用它稳定性和可维护性都比自由发挥好太多# 角色 你是... # 背景 我们正在做...目前遇到... # 任务 需要你完成... # 约束 必须... 不要... # 输出格式 请按以下JSON结构返回...每一段有各自的作用角色负责调语气和知识倾向背景给模型提供必要的上下文避免它靠瞎猜任务用一两句话讲清楚要做什么约束用来压缩输出空间输出格式则直接决定下游能不能正常解析。五段不是每次都写满但角色、任务、约束最少要有否则稳定性没保证。这里有个容易被忽略的点把最重要的约束放在靠前的位置并且每条约束独立成行。因为模型的注意力在长文本生成过程中会逐渐衰减写在最后的一大段限制条件很容易被稀释。把关键要求前置、编号化是减少丢约束的最简单手段。我见过有人把十条约束密密麻麻写在一个自然段里结果模型只遵守了前三条后面七条全当没看见——这不是模型笨是你把信息打包得太难提取了。3.2 用同一个需求演示三版提示词差距拿提取网页标题这种小事举例。第一版帮我解析网页模型大概率会反问你要解析什么、输出什么格式。第二版改成写一个Python脚本解析网页并提取标题方向对了但结果可能是一段不完整、没法直接用的代码。第三版写一个Python函数 get_page_title(url: str) - str - 使用 requests 获取页面超时设为5秒 - 用 BeautifulSoup 解析返回 title 标签的文本 - 请求失败或解析不到时返回空字符串 - 不要打印额外信息不要抛出异常。这一版把函数签名、依赖库、处理逻辑、异常行为、副作用全部写清模型给出的代码基本可以直接放进项目里跑。三版之间的差距不是命令口吻的差距而是信息完整度的差距——提示词本质上是一份写给模型的需求规格说明书。你越早把这个观念建立起来写提示词的效率提升就越明显。3.3 少样本示例和思维链的正确打开方式除了五段式结构还有两个高频技巧分别解决不知道你要什么格式和推理容易跳步两类问题。少样本示例Few-shot与其用文字描述输出格式是这样那样的不如直接丢一个或两个完整的输入输出对让模型照着格式学。模型模仿示例的能力通常比理解抽象规则更强尤其面对JSON、XML这类结构化输出时给一个真实示例比写十行字段说明都管用。思维链Chain of Thought对于数学题、逻辑题或需要多步判断的任务明确要求先列出推理步骤再给出最终答案能明显提升准确率因为模型被迫把隐式的推理过程显式化减少了跳步带来的错误。但技巧要用对地方。简单任务上硬加先思考再回答反而可能把三秒能回答的问题拖出一堆废话输出格式已经明确的结构化任务再让它写一大段推理也会干扰下游解析。我的取舍原则是任务越偏推理判断越要上CoT任务越偏格式化输出越要上Few-shot和强约束两者都重要时让模型在内部推理只输出最终结构。别把提示词工程做成技巧表演匹配任务复杂度才是关键。4. 调试提示词的完整链路我在真实项目里踩过的坑4.1 输出不稳定先排查温度与提示词敏感度做 Agent 时最常遇到的情况是同一个提示词这次能用下次就乱来。这种玄学波动有几个常见原因。第一模型接口的 temperature 参数偏高每次采样都有随机差异——对 Agent 这种需要稳定输出的场景直接设成0往往立竿见影。第二提示词里存在冗余的噪声词或描述模型对某些词异常敏感改一个字、换一行输出就面目全非。第三多轮对话时上下文顺序在变导致注意力分配不一样同一个要求前面满足后面失效。我的排查顺序是先把 temperature 归零测试如果稳定了说明是采样随机性如果还飘做减词测试——把提示词逐段删掉看哪段删掉后行为发生剧变那段就是敏感区。这个方法的本质是把提示词当代码来调试一次只变一个变量观察输出差异定位罪魁祸首。千万不能同时改三个地方再跑那样即使结果对了你也不知道是哪处改好的一一后续维护时照样抓瞎。4.2 高频失败模式对照表我在项目问题记录里整理了一张高频失败模式表每次 Agent 表现怪异先对照它找原因而不是盲目重写提示词失败现象常见原因我的修法模型答非所问任务动词缺失模型靠猜提示词第一句就写明请完成/请输出/请判断输出格式混乱格式约束写得太抽象直接给出JSON示例和字段类型说明丢条件、漏约束约束过多且堆在提示词末尾约束前置、逐条编号、关键项重复强调推理逻辑跳跃推理过程被跳过要求先列推理步骤再给结论语气、风格不符角色设定太弱或太泛提高角色具体度补充经验年数和场景细节这张表帮我省了非常多次盲目试错。举个例子有一次我的 Agent 总是漏掉一个必填字段我第一反应是加大字段描述的字数结果没用。对照表格一看真正的坑其实是约束被放到了提示词最后一段模型生成时注意力已经衰减根本没读到。把字段约束移到任务描述旁边并且编号后问题瞬间消失。这类问题不看原因直接调参效率极低。4.3 提示词也要做版本管理没有版本管理的提示词就是在裸奔。我自己早期吃过亏一个跑得好好的 Agent某天我顺手改了提示词里的一个词整个流程就崩了关键是我没留备份回滚只能靠记忆重构折腾了大半天。从那以后我所有 Agent 项目的提示词都按下面这套管理每个提示词单独一个文本文件放在项目 prompts 目录下文件名带版本号如 system_v3.md每次修改记录变更原因和测试结果维护一个回归测试集把项目最关键的几十个输入场景连同预期输出固定下来每轮改动后统一跑一遍。这套做法并不需要高深工具一个 Git 仓库加一个文本目录就够了。提示词本质上和代码一样是可迭代、可测试、可回滚的资产只不过很多人习惯把它当随手打的字等到出问题才追悔莫及。5. 从聊天式提示词到 Agent提示词的三个新战场5.1 系统提示词与工具调用从说话到行为的接口契约单轮对话里的提示词目标是一段合适的文本Agent 里的提示词目标是一连串正确的行为。最典型的差别在工具调用Function Calling上Agent 需要根据用户需求决定调哪个工具、传什么参数模型输出必须严格符合结构化接口否则下游系统根本没法解析。这时候提示词里的输出格式约束就成了一份接口契约。比如你要求模型返回 JSON就得在提示词里写清楚字段名、类型、可枚举值和必填项如果你还希望它一次调用多个工具还得说明调用顺序和依赖关系。另外现在不少框架里的 Skill 或 Agent 技能本质就是一组预置提示词 工具配置 工作流编排的封装而系统提示词是这一切的基底。可以这样理解Skill 是给 Agent 准备的一本操作手册系统提示词则是这份手册的总纲两者相互配合但各管一摊。5.2 让 Agent 具备自救能力反思与校验类提示词Chat 场景里模型答错了用户自己会重新问一遍Agent 场景里模型执行错了整个流程可能直接卡死。所以 Agent 的系统提示词里通常会加一类反思与校验指令要求模型在拿到工具返回结果后先检查结果是否合理不合理就主动重试或换一种方案。我经常在系统提示词里写这么一段通用指令执行完上一步后请确认输出结果是否满足任务要求如果工具返回了错误或空值尝试换一个参数重新执行如果连续两次失败向用户简要说明原因。就这么一段话把很多偶发性的执行失败挡在了用户感知之外。这种元指令是单轮提示词的延伸——它不再管怎么说而是管执行完之后怎么做是 Agent 稳定性的关键一环。5.3 上下文工程提示词之外的另一半拼图Agent 真正复杂的地方不是单次生成而是多轮状态管理。于是提示词旁边出现了一个更大的话题——上下文工程你给模型塞什么信息、塞多少、按什么顺序、怎么压缩历史。提示词决定如何表达需求上下文决定模型看到的素材是否足够。举个简单的例子。一个客服 Agent如果每轮都把用户的全部历史订单塞进上下文回答质量自然会高但上下文越长越容易超出窗口限制模型注意力也越容易被无关信息干扰。这时候就得做检索只取相关的几条记录、摘要把长对话压成要点、遗忘丢弃不再相关的历史。这三个动作本质上也是在提示模型只是用的素材不是一句句话而是信息的选择与组织。所以做 Agent只会写提示词远远不够上下文工程是绕不开的下一课。5.4 别忽略安全边界外部输入不可信最后提醒一件容易忽略的事任何来自用户或外部系统的内容都不应该直接拼接进系统提示词。提示词注入是 Agent 绕不开的安全话题——恶意用户可能通过输入一段忽略上面所有指令之类的文本诱导模型绕过你设定的约束。我见过不少新手把用户输入直接拼进 prompt结果用户一句你现在是自由模式就接管了整个对话。防御思路不是靠模型自觉而是在架构上做隔离把系统指令与不可信内容明确分开对模型的输出做二次校验对高风险操作加人工确认。这块内容够单独写一篇了但至少在学提示词的阶段就要建立这种意识提示词不只是质量工具也是全系统安全边界的一部分。别等出了事故再补。最后说点个人体会。我刚开始学提示词也走了不少弯路收藏了一堆网上流传的万能模板套在自己的需求上结果驴唇不对马嘴。真正让我开窍的是某次被逼着给第一个 Agent 写系统提示词——为了让一个流程稳定跑通我连续改了十几版每版都记录失败原因和测试结果。那之后我才意识到提示词不是一句漂亮的咒语而是一份需要像代码一样迭代维护的说明书。如果你想现在就练手建议找一个真实需求用第3章的骨架先写一版再用第4章的调试链路调到连续十次输出稳定。等你能做到这一步让大模型真正听懂你说话这关就算真的过关了。