最近在带几个朋友入门AI Agent发现一个特别有意思的现象大家选的模型一样、用的框架一样最后做出来的Agent效果却天差地别。有人一句话就让大模型给出高质量结果有人反复对话半小时AI还在自顾自地跑偏。差别不在模型而在提示词——怎么把你脑子里的需求准确地翻译成大模型能执行的指令。这个系列的第一篇我聊了Agent的整体概念和基础架构这一篇想把提示词与提示工程彻底掰开揉碎讲清楚。标题写的是让大模型真正听懂你说话其实是两个层面的意思表面是让模型理解你的自然语言深层是让你理解模型的听力机制。搞懂了后者前者基本就是水到渠成的事。这篇文章适合两类人一是正在学AI Agent、准备用提示词做System Prompt的朋友二是平时用ChatGPT、DeepSeek这类产品但总觉得AI不够聪明的用户。整篇不会堆砌太多术语更多是我自己从写能跑通的demo到能上线的Agent过程中总结出来的实操方法和踩坑经验。1. 大模型的听力到底是怎么工作的先看懂token和上下文窗口1.1 你说的每句话先被打碎再重组很多人在写提示词时有个误区把大模型当成一个人觉得说人话就够了。但大模型不是逐字阅读你的整句话它读的是token序列。token是模型处理文本的最小单位。一个token可以是几个字符、半个词、一个汉字或者一个标点。不同模型的分词器切法不完全一样英文大致是一个单词对应1到1.3个token中文一个汉字往往占1到2个token。模型收到你的提示词后会先把整段文字切成token再做向量化然后通过注意力机制建立词与词之间的关系。注意这里的关键点在于模型并没有语义理解这个人类意义上的动作它做的其实是根据已有的token预测下一个token最可能是什么。当你提供了足够清晰的上下文时token之间的关联强度更高每一步预测都更稳当你的提示含糊模型只能靠训练数据里的平均概率去猜输出自然飘。理解这一点会改变你对提示词的看法。提示词不是给模型看的一段话而是给模型的一组锚点。信息密度越高、结构越清楚每个锚点才能稳稳拉住后续的生成方向。1.2 上下文窗口就是大模型的工作台面积上下文窗口指的是模型在一次对话中可以记住的最大token数量。你可以把它理解成一张工作台的面积台面越大你能同时铺开的资料越多模型能够参考的素材也就越多。现在的模型动辄32K、128K甚至更大的上下文窗口看起来空间非常充裕但实际可用的有效上下文并没有那么大。一个被反复验证过的现象是当相关信息埋在长文本中间时模型的利用效果会明显变差遗忘概率高于开头和结尾。业界讨论很多思路基本一致注意力在长序列里会逐渐分散中间段信息容易被忽略。这对写提示词有非常直接的指导意义。关键指令、核心约束、任务目标要么放在提示词开头让模型从一开始就明确方向要么放在离生成位置最近的地方让模型在开口之前最后看到。千万别把最重要的要求埋在长段落中间——模型真的会视而不见。1.3 理解这一步之后你就知道为什么提示词重要了当你意识到大模型是在做概率预测而不是阅读理解时很多困惑就有了解释。为什么帮我写个方案这种话输出总是宽泛得像废话因为模型在你的话里找不到任何约束条件它只能按照训练数据里方案的平均样式去生成输出的概率分布摊得非常平什么行业都能套、什么场景都不精准。为什么帮我写一份智能家居产品的推广方案面向25到35岁城市白领预算10万两周内上线需要包含渠道选择、排期表和预算分配表输出质量会明显高一个档次因为你的每一个限定词都成了筛选条件模型在每一步生成时候选范围都被压缩到一小块区域真正相关的内容自然更容易被选中。提示词的本质就是压缩大模型输出的概率空间让更合理的答案落在概率最高的位置。你给的上下文越清晰、约束越具体模型的选择范围就越小输出的一致性和质量就越稳定。这个认知是整个提示工程的地基。2. 把提示词当成一份岗位说明书来写四段式结构拆解2.1 角色设定告诉AI你是谁你现在干什么角色设定大概是流传最广的提示词技巧但很多人用的方式不对。单纯写你是一位专家几乎没用因为专家这个词在训练语料里出现得太频繁模型无法从中获得足够的约束信息。有效的方式是职级专业方向风格偏好。比如你是一位有7年跨境电商运营经验的推广专家擅长亚马逊Listing优化与站内广告投放。你偏好用数据说话结论先行善用表格汇总对比结果。这个角色描述里面包含了好几层信息行业背景跨境电商、具体能力Listing和广告投放、输出习惯数据支撑、结论先行、表格。模型在生成时会更多地调用这个领域相关的术语、案例和分析方式不会再说出那种放之四海而皆准的废话。但我也要说句公道话角色设定不是万能的。如果你需要模型做数学计算、查事实、写JSON角色加成并不明显甚至可能让模型变得更爱铺垫。角色设定的核心作用是引导表达风格和分析视角并不能直接提高事实准确性。想要事实准确靠的是上下文资料而不是人设。2.2 任务描述写清目标、输入、验收标准角色解决谁来做任务描述解决做什么、做到什么程度算完成。很多新手只给一句帮我处理一下这份数据模型根本不知道你想怎么处理是总结、提取、清洗还是转格式好的任务描述应该包含四个要素任务目标你最终想要什么产物是分析报告、代码、建议清单还是一封邮件输入数据给模型的东西是什么是否需要说明格式或来源处理要求对输入做什么操作是总结、改写、转换还是多选一验收标准什么样的输出算合格有没有字数限制、条数要求、特定视角验收标准是最容易被漏掉的一项但恰恰最值钱。输出不超过800字、必须包含至少3个备选方案、每个建议后附一条风险提示——这些可量化的验收标准能极大压缩模型的自由发挥空间。模型其实非常擅长挤字数和回避重点你给了验收标准它才会奔着那个点去。2.3 约束条件与输出格式少让AI自由发挥约束条件可以分成两类内容约束和格式约束。内容约束负责防幻觉不许编造数据、不评价特定品牌、遇到不确定的信息明确说不知道。这些都是在显式地给模型的生成空间画边界。格式约束负责防混乱用JSON返回、用Markdown表格展示、分三个小节、先给结论再给理由。格式约束的价值不只是让人看着舒服更是让下游程序能够稳定解析。尤其是Agent场景模型输出格式一乱解析代码就要多写一堆防御逻辑。一个非常实用的细节当你需要模型输出JSON时最好直接在提示词里给一个最小示例。比如返回格式示例 {title: 标题, summary: 摘要, keywords: [关键词1, 关键词2]}只写请返回JSON是不够的。模型有时会把JSON包在Markdown代码块里有时会在JSON前后加上一行以下是结果这些都会直接破坏程序解析。给一个具体模板等于提前把坑填平。2.4 实战对比同一个需求两版提示词的效果差为了说明问题我拿同一个需求做过对比测试。第一版 帮我把这个产品的卖点写一下。第二版 你是一位电商产品文案面向25到35岁女性用户。下面是我提供的产品资料请提炼出5个核心卖点每个卖点用一句话概括并附一句对应的用户痛点说明。不要编造资料中没有的数据输出为Markdown无序列表。同一个模型第一版得到的基本是产品质量好、价格优惠、服务贴心这类没有任何信息量的空话第二版则会围绕产品资料里的具体特性展开比如材质、工艺、使用场景拆出实实在在的卖点。两版的差距根本原因就是提示词提供了多少锚点。第一版除了卖点两个字什么都没有模型只能调用大众化的文案模板第二版给了角色、受众、数量、结构、数据边界模型每一步生成都有据可依。到这里可以看清一个事实提示工程不是玄学而是信息密度的管理。你写的每一条约束本质上都是在帮模型降低猜测成本。下面是差版与好版的对照总结维度差版提示词好版提示词角色无资深电商文案明确受众任务写卖点提炼5个核心卖点并附痛点约束无不编造数据不可超范围格式无Markdown无序列表验收无每条一句话附说明3. 当提示词遇上AI Agent从对话提示升级成系统指令3.1 普通问答与Agent调用的本质区别前面聊的方法本质上还停留在人机对话场景。但做AI Agent时情况变化很大——我们面对的不是一次性问答而是带状态、带工具、带目标的多次调用。提示词的作用也随之质变。区别主要有三点。第一输出不是给人看而是给程序用。Agent场景下模型的输出常常直接对接函数调用、结构化解析和流程分支所以格式稳定性比内容文采更重要。一个JSON格式不稳定的Agent比一个措辞平庸的Agent更难维护。第二对话不是一次而是一串。Agent要连续处理多轮对话每一轮都要保持上下文和主题一致。提示词里必须写清楚什么时候继续推进任务什么时候主动让用户补充信息什么时候结束当前任务。第三模型有了手。Agent会调用搜索、计算、数据库等外部工具提示词需要告诉模型工具有哪些、各自用途是什么、什么条件下用哪个、调用失败怎么办。这是普通提示词完全不需要考虑的内容。3.2 System Prompt的整体框架角色、能力边界、工作流在Agent架构里真正承担底层宪法角色的是System Prompt系统提示词。无论用户说什么这条系统提示词都固定在上下文窗口前端约束每轮生成行为。写不好System PromptAgent几乎必然表现飘忽。我写过的Agent不算少系统提示词基本包含五块内容模块要解决的问题示例写法身份定义Agent是谁、服务对象是谁你是企业知识库助手面向公司内部员工能力边界哪些事能做、哪些不做你只回答知识库范围内的问题不做代码编写与法律咨询工作流程先做什么、再做什么先确认需求再检索知识库最后给出结论信息不足时主动提问输出规范人看的和程序看的格式要求面向用户的回答不超过200字内部操作返回JSON结束条件什么时候任务算完成用户明确表示不需要进一步帮助时结束任务并给出总结这里特别强调能力边界。很多Agent翻车不是因为能力不够而是因为不知道自己不该做什么。用户提了一个越界请求模型觉得硬着头皮也得回答于是开始编。系统提示词里明确如果你无法回答直接告知用户局限性比在几十条用户提示词里反复强调都管用。写系统提示词的心态也要调整它不是写作文而是写制度。稳定、可重复、结构清晰比任何花哨的表达都重要。3.3 工具调用场景的提示词让模型学会先查后答Agent一定会调工具。工具调用相关的提示词要回答模型的几个核心问题有哪些工具可用每个工具的职责是什么什么时候必须用、什么时候不能用调用失败怎么办我在一个知识库问答Agent里写过这样一段系统提示你有且仅有以下三个工具 1. search_docs检索知识库文档返回摘要。当用户问题涉及事实信息时必须优先调用该工具不得凭记忆作答。 2. calc执行数学计算。任何涉及计算的场景都必须调用calc不得心算。 3. get_weather查询天气。非当天日期的问题必须先向用户确认城市和时间再调用工具。 当你无法获取所需信息时直接回复我暂时无法回答这个问题并说明缺少哪些关键信息。这段提示词的要点是把工具的决策逻辑写成规则。模型本身不具备什么时候该查资料的直觉只有规则足够清晰它才会稳定触发正确的工具。还有一个容易忽略的细节工具调用的结果也需要设计使用规则。比如search_docs返回了摘要要在提示词里引导模型根据摘要优先作答并标注信息来源不要扩展摘要之外的信息。否则Agent很可能拿到检索结果后继续自由发挥看似回答了实际上还是幻觉。3.4 调试提示词的三种方法迭代、对比、加断点写Agent提示词很少有一步到位的调试是必然环节。我个人常用的方法有三个。迭代法最基础先写个粗糙版本跑一个用例看输出哪里不对再回头修改提示词中对应的句子。整个流程就是跑用例、找差距、改提示、再跑。这里改的不是某一个形容词而是补齐约束条件。对比法适合判断是提示的问题还是模型的问题把同一段提示词放到不同模型上测试。同一个System Prompt在不同模型上的表现差异可能相当大尤其风格偏好、JSON稳定性和指令跟随能力。对比能帮你找出哪个部分是各家模型通用的写法后续换模型时的迁移成本会低很多。加断点法是我觉得最被低估的把Agent每一轮工具调用之后的完整上下文打印出来完整看一遍。你会发现很多问题的根源根本不是提示词写得不细而是多轮对话中上下文被污染了——一次工具返回混入一大段噪音数据后续几轮模型就分不清主次。这时候继续堆提示词完全没用正确操作是清洗上下文、缩短历史长度、把关键约束重新注入。4. 提示工程的上游上下文注入与动态提示模板4.1 上下文工程给模型的信息环境比指令更决定成败最近圈子里都在讲一个趋势提示词工程正在向上下文工程演进。这个概念并不复杂——提示词不仅仅是指令文字还包括你喂给模型的所有上下文资料。很多时候输出质量的天花板是由上下文质量决定的而不是指令措辞。举个很常见的例子。让Agent写新能源汽车行业分析一个版本只传了你是一位分析师请写一份行业分析另一个版本先检索了最近三个月的行业新闻、三篇头部券商报告摘要再让模型基于这些资料写。后者写出来的内容明显更扎实、更有依据因为模型不是凭空生成而是有素材可依。所以在开发Agent时不要只盯着提示词模板优化还要想清楚哪些信息必须在模型看到问题之前就主动注入哪些信息让模型自己检索注入的顺序是什么资料太长时怎么压缩提取这一整套设计就是上下文工程。掌握了它很多提示词怎么写都不对的问题会迎刃而解。4.2 动态模板用变量组织提示词而不是硬编码在代码层面很多初学者容易把提示词硬编码成一整段字符串。这在小规模验证时没问题一旦进入真实项目维护成本会迅速失控。更合理的做法是设计提示词模板把经常变化的部分抽成变量。我常用的模板是这个样子system_prompt f 你是{role}负责解决{task_area}领域的问题。 用户画像{user_profile} 本次任务目标{task_goal} 已知资料{data_context} 约束条件{constraints} 输出格式{output_format} 请严格按照以上要求执行不要编造未知信息。 用变量动态注入的好处有三个一是方便复用换一个业务只需要替换对应变量二是方便调试哪天输出质量下降能快速定位是哪一块上下文出了问题三是方便协作非技术人员也能维护资料区约束区这些内容不必改动代码逻辑。我建议变量里的内容尽量来自结构化数据而不是把大段原始文本直接拼进去。原始文本太长会稀释关键信息模型容易捡了芝麻丢了西瓜。先做提取、摘要、去重再注入模板效果会稳定得多。4.3 Few-shot示例给模型参考答案比讲道理更管用模型对抽象规则的跟随能力是有限的但对具体示例的学习能力非常强。这就是few-shot少样本示例的价值来源。我在做意图识别Agent时一开始在系统提示词里写你是意图识别专家请判断用户意图属于查询、操作还是闲聊效果时好时坏边界情况经常出错。后来我改成在提示词里放三个示例示例1 用户我想把API的请求超时时间改成5秒 意图操作 示例2 用户你们系统支持Webhook吗 意图查询 示例3 用户今天天气不错 意图闲聊识别准确率立刻有了可感知的提升。原因很简单示例相当于给了模型一把标尺模型不需要抽象推理什么算操作、什么算查询只需要把输入和示例做模式匹配。人对模糊规则的理解靠领悟模型对模糊规则的理解靠参考没有参考就容易漂。选示例也有一些讲究贴近真实场景、覆盖最容易出错的边界情况、示例之间差异明显。数量上3到5个精选的就够了堆10个雷同示例反而会让模型困惑。对于Agent场景few-shot还能帮助模型理解状态切换规则比如用户对结果不满意时Agent应当主动追问细节而不是直接重做这种过程性的示例往往比抽象描述管用得多。5. 我在实际项目中踩过的坑以及一份自查清单5.1 三个最容易翻车的提示词误区第一个误区把提示词写成没有逻辑的短句列表。你是一个专家。请参考以下资料。输出要专业。不要胡说。请使用中文。这种拼凑式写法模型很难建立整体理解往往只抓住了列表开头和结尾的几条中间的约束全部漂移。我的习惯是把提示词写成有逻辑的短文角色、任务、约束、输出格式分段清晰每一段之间有承接关系。第二个误区提示词里写满禁止却没有任何替代方案。模型对否定指令的执行能力天然偏弱你写不要输出JSON以外的格式不如写请严格输出JSON格式结构如下前者给的是禁止项后者给的是明确的目标形态。指令工程里有个朴素原则在提示词层面说清楚要什么永远比反复强调不要什么更有效。第三个误区只顾着堆System Prompt不管上下文是否污染。我调试过不少表现不稳定的Agent最后发现根源不是初始提示写得不细而是跑了几轮之后历史对话和工具返回值把初始指令冲淡了。系统提示词再长窗口里堆积的无关内容一多它也会慢慢失去约束力。这时候需要定期清洗上下文、压缩历史记录、把关键约束重新注入有些项目甚至要在每轮结束后重建精简版的上下文。5.2 一个可复制的Prompt自查清单写完一段提示词之后我会逐条做下面这些检查任何一条不满足就回头改角色定义是否具体到什么专业背景什么风格偏好任务描述是否包含目标、输入、处理要求、验收标准四项约束条件是不是以正面引导为主而不是满屏的不要输出格式是否给过具体示例模板关键信息是否放在提示词开头或结尾而不是埋在中间注入的上下文资料是否已经清洗、摘要、去重而不是原样堆入工具调用的触发条件、失败处理、结果利用规则是否写明是否给了3到5个精选few-shot示例来固定输出纪律同一份提示词换一个模型跑表现是否依然可靠这张清单基本就是我写Agent提示词的最终质检流程。很多次我觉得这提示词已经完美了跑一遍用例也正常结果一查清单才发现漏了输出格式的示例或者能力边界没有写清。把清单固化成习惯之后排查问题的效率提升非常明显。最后说一点个人体会。学了这么久我最大的感触是提示工程不是玄学它是一门把需求表达得足够精确的手艺。大模型的听力一直在变强但听懂的前提永远是你先把话说清楚。在我看过的绝大多数AI不行的案例里提示词本身往往至少有三个可以改进的地方。如果你手里正有一个表现不稳定的Agent先别急着换模型也别急着加更多工具把它的提示词按上面的框架重写一遍多半会有意外收获。