1. 为什么明明用了大模型结果还是像在“猜”你要什么我第一次上手做 AI Agent 的时候最大的挫败感不是模型能力不够而是我压根说不明白话。我问它“帮我分析一下这个需求”它给我写了两千字的代码架构我说“写得简单点”它又给我改成了十条 bullet point。反复拉锯几轮之后我意识到问题不在模型而在提示词本身——提示词不是“问问题”而是“描述你想要的完整工作方式”。很多刚接触大模型的朋友会有个直觉AI 不是跟人聊天吗那我像跟同事说话一样说需求不就行了这个直觉一半对一半错。对的是它确实能听懂自然语言错的是大模型对模糊容忍度极低。你给了它一个模糊目标它就会用概率最高的方式瞎猜——而概率最高的方式往往是“最平庸的泛化回答”不是你要的那个具体结果。1.1 先理解提示词进入模型后发生了什么从技术底子上看大模型本质上是一个“基于上下文的概率预测器”。当你把一串提示词输进去它做的事情是把文字切分成 token然后逐个预测下一个 token 最可能是什么。这个过程跟人理解语言完全是两回事——人理解的是“意图”模型计算的是“统计上的延续”。这就解释了为什么同一个提示词在不同模型上结果天差地别因为不同模型的训练数据、参数规模和指令遵循能力不一样。强一点的模型比如 Claude、GPT 系列的中高端版本对“少写废话”这种相对抽象的指令执行得比较好弱一点的模型就需要你把规则掰开揉碎写清楚“降低输出长度每节不超过 100 字不要使用列表”这种颗粒度。有个曾经很火的梗叫“鹈鹕骑自行车”——是一张测试多模态模型的图片很多模型看不出鹈鹕是怎么骑的。这种“看不见”和“听不懂”是一个道理它没有建立“把图片里每个对象和动词关联起来”的指令链条所以只能凭常见组合猜。提示词工程在文本场景里要做的事情也类似用足够精确的表述把模型的猜测空间压到最小。1.2 常见的“听不懂”场景背后是同一个原因我在实际项目里总结过模型“听不懂”基本逃不开四类情况目标含糊只说“帮我处理一下数据”没说处理成什么样、按照什么维度、产出什么格式。背景缺失没交代这个结果给谁用、用在什么场景、有没有历史约束模型只能按通用方式处理。约束遗漏没说不许用什么技术栈、不需要什么内容、避开哪些坑它就会给你填一堆它觉得“加分”的料。格式没约定没说输出 JSON 还是表格还是纯文本它就按心情混合输出下游解析直接炸掉。这四类问题跟模型参数规模其实关系不大纯粹是提示词没有给到足够的信息密度。就好比你让实习生去整理一份行业报告只丢给他一句“整理一下”他肯定交回来一份你不想看的东西——不是他笨是任务描述根本没达到“可执行”的标准。所以“让大模型真正听懂你说话”这个系列的主题不是教你怎么“把话说的更好听”而是教你怎么把一个模糊需求翻译成一个精确的任务规格说明。这个翻译能力就是提示工程的核心能力。2. 把提示词拆开看六要素写出不翻车的提示词我早期写提示词非常随缘想到什么写什么。后来被现实教育了几次比如让 AI 生成的代码直接带 bug 进生产、让 AI 写的文案被合规打回三次才开始认真整理一套结构化的写法。现在我基本会把一条正式提示词拆成六个要素角色、任务、上下文、约束、示例、输出格式。这套东西说起来很简单但真正每条都用上、用好效果完全是两个量级。下面逐个拆开说。2.1 角色、任务、上下文先把“人设”立住角色Role不是花活。“你现在是一个资深 Python 后端工程师”这句话最大的作用不是让模型“代入”而是激活它在训练数据里学到的相关领域知识分布。它学过海量的 Python 代码和架构讨论但你不提角色它可能按“通用写作助手”的模式来组织语言。一个简单测试同样的技术问题用不用角色后缀输出的术语颗粒度完全不同。任务Task是整条提示词的心脏。这里最容易犯的错是把任务写成“目标”而不是“动作”。比如失败写法“分析这段代码”成功写法“指出这段代码中所有可能导致并发问题的地方按严重程度排序并针对每一项给出具体修改建议”区别在哪里后者有明确的检查方向并发问题、有排序要求严重程度、有产出物修改建议。模型不需要猜你要什么只需要照着做。上下文Context是很多人忽略但最能拉开效果差距的。一个项目里你要告诉模型这个代码服务的业务是电商订单还是算法训练数据量级是多少服务于内部还是外部用户。同样一句“查询超时怎么优化”有上下文时它会往索引、连接池、缓存方向写没上下文时它可能从硬件配置开始讲起对你来说全是废话。2.2 输出格式、约束与示例把验收标准说清楚输出格式Format这件事在 AI Agent 场景里尤其重要——因为 Agent 的下游往往不是人而是代码。如果模型输出 Markdown 而你的解析器只认 JSON那后面全部白搭。所以我在所有工程化提示词里都会写一条“你必须输出 JSON不要包含任何解释性文字”之类的话并且用代码块或示例来锁定结构。约束Constraint是提示词的“红线”。比如“不要调用外部 API”“不解释代码只给出修改后的完整函数”“不要使用第三方依赖库”。约束放得越具体模型越不容易在边界上来回试探。但它有个副作用——约束多了会挤占上下文空间也可能会让模型变得过度保守。所以约束要有优先级一条提示词里最好不超过五条强约束其余用示例来暗示。示例Example是最强的约束。一切抽象描述都不如一个具体的输入输出对照模板。想让模型按格式输出你给一个“输入…输出…”的例子比写一百字“请严格遵循以下格式”都管用。很多成熟的 prompt 模版就是靠 two-shot / three-shot给两到三个示例来稳定模型输出的。2.3 一个对比案例要素全乎和要素缺位的差距我拿自己实际调过的场景做一个对照。当时要做的是一个工单分类 Agent输入是用户提交的文本工单输出是分类结果、紧急程度和处理建议。第一版提示词是这样请分析下面的工单并给出处理建议 {工单内容}这种提示词不是不能用而是输出质量极不稳定分类类别它自己定紧急程度有时候高有时候低处理建议有时候给三行有时候给三页而且偶尔会夹带私货“这道工单可转人工处理”这种流程话。后来我按六要素重写角色你是电商平台的工单分类专员熟悉退换货、物流、支付、账号安全四类业务。 任务判断工单所属类别、紧急程度高/中/低并给出不超过50字的处理建议。如果信息不足输出需补充信息。 上下文工单来自C端用户分类结果会进入自动响应系统紧急程度高的工单会触发人工介入。 约束 - 只输出JSON不要输出任何其他文字 - 分类只能是退换货/物流/支付/账号安全/其他 - 紧急程度判断标准涉及资金安全或无法登录为高涉及时效承诺为中其余为低 输出格式 {category: ..., urgency: ..., suggestion: ...} 示例 输入我上周买的手机到现在没发货客服也没回应 输出{category: 物流, urgency: 中, suggestion: 核查发货超时原因优先发送物流异常通知并承诺处理时限}改动之后效果立竿见影解析成功率从大概七成涨到接近满分而且模型基本不会再冒出来格式外的内容。这段对比也是我在文章里最想传递的一个观点——提示词不是写给人看的是写给模型看的“需求规格说明书”你把每个环节讲得多细它就执行得有多准。3. 提示工程进阶让模型“想清楚”再回答六要素解决的是“说得清楚”的问题但很多时候需求说清楚了模型给出的结果还是浮于表面。比如你让它“写一个用户登录接口”它确实写了个接口但没有异常处理、没有日志、没有防刷——它是在“直接给答案”而不是“先想一遍再给答案”。这时候需要用一些进阶技巧让模型输出的深度从“表面正确”走向“真正可用”。3.1 思维链不玄乎就是把做题过程写出来思维链Chain-of-ThoughtCoT在论文里的定义很学术但在实操中就是一句话在要求模型给最终结果之前先让它把思考过程和中间步骤写出来。这个原理也不复杂——模型在生成最终答案前会先走一段“思维过程”如果你允许它显式地写出来它的每一步推理会更有依据而不是直接跳到结论。比如做 count 类题目你直接问“下面这句话里有几个 a”模型经常数错。但你让它“先列出每个单词再逐个检查字母”正确率会有明显提升。Agent 场景里更典型的是“规划型任务”“用户想买一台性价比高的游戏本预算6000”。如果直接给答案它可能推荐热门机型如果让它“先拆解用户需求再筛参数再对比竞品最后给推荐”答案的层次完全不同。实操上CoT 有两种注入方式。一种是在提示词里显式写“请一步一步思考并在最终答案前输出你的推理过程”另一种是用 few-shot 示例在示例里展示“步骤1、步骤2、结论”的结构。后者更隐蔽但稳定性更好尤其当你用的模型比较弱、显式要求容易触发额外瞎编的时候。注意CoT 不是所有场景都必须上。如果任务是“翻译一句话”“做文本分类”你让它多想几步反而会拖慢速度、浪费 token甚至因为“多想”而偏离标准答案。把 CoT 用在逻辑推理、方案设计、代码生成这类复杂任务上收益才最大。3.2 Few-shot 示例比“你要专业一点”有效得多很多人调提示词喜欢加形容词“请专业地回答”“请详细一些”“请严谨一点”。这些词不是没用但作用非常有限——它只是改变了模型的“语气分布”没有改变模型对任务结构的理解。相比之下给样例few-shot的效果要扎实得多。因为你实际上是在做“隐式约束”模型会模仿你给的例子的结构、详略程度、语气、甚至格式。我见过一个很夸张的例子有人让 LLM 写英文邮件加了五个正式商务邮件样例后模型的输出措辞直接从中性偏文本风格变成了地道的商务风比写“use formal tone”管用太多了。Few-shot 的使用也有技巧示例数量不是越多越好。两到三个高质量样例通常就够了太多会占用上下文且增加成本。示例要覆盖“边界情况”不要全给“典型示例”。比如分类任务中给一个模棱两可的例子和它的处理方式比给三个明显类别的例子更能提升判断稳定性。示例的格式必须跟期望输出的格式完全一致不然模型会按示例里的隐含格式输出反而破坏了你设定的 JSON 结构。3.3 温度、top_p、top_k、max_tokens参数跟提示词是搭档有一段时间我只盯提示词完全忽略推理参数。后来才发现参数和提示词是配套的——同一个提示词把温度从 0.7 调到 0.2输出的稳定性和可预测性完全不一样。我把几个关键参数按 Agent 开发视角整理成了一张速查表参数作用Agent 场景推荐值说明temperature控制随机性越高越发散0~0.3需要稳定输出的工具调用、分类、提取越低调越好top_p核采样替代或配合 temperature0.8~0.9跟 temperature 不要同时大改二选一调节即可max_tokens限制输出最大长度按需设置建议设长一点防止长结果被截断成本可控stop停止符按输出格式设置输出 JSON 时可设结束标记方便解析这里最容易踩的坑是为了“更有创造性”把温度拉很高结果 Agent 开始不听指令甚至会自己编字段名、编错误格式。Agent 的核心诉求是“稳定执行”不是“妙语连珠”。所以除非你在做文案生成、创意类任务否则温度控制得越低越好。我还养成了一个习惯改提示词和改参数两条路分开调。如果输出风格不对先改参数如果输出内容不对先改提示词。混着改最致命——出了问题根本定位不到是哪个变量导致的。4. 面向 AI Agent 的提示词设计这事比单轮对话更讲究单独写一条好提示词和给 AI Agent 写提示词完全不是一个量级的问题。Agent 场景里模型要自主做决定、调用工具、承担多轮上下文还要从错误里恢复。这就提示词工程提出了更高要求——每一轮对话里的提示词都像给一个“带工具的实习生”下指令说得不到位它会拿斧头削铅笔。这个系列叫“AI Agent 学习之路”所以这篇要重点把 Agent 相关提示词设计的特殊之处拆清楚。4.1 系统提示词与任务提示词的分工很多人一开始写 Agent 会把所有内容塞进一条 system prompt包括“你是谁”“你要做什么”“工具怎么用”“输出什么格式”“遇到错误怎么办”全堆在一块。这样做不是不行但效果通常不好——因为上下文一长模型的注意力就会被稀释越靠后的内容越容易被淡忘。我更推荐的做法是三层分工系统提示词System Prompt负责“身份 规则 工具定义”这一层是长期稳定的告诉模型它是谁、有哪些工具可用、行为边界是什么。任务提示词Task Prompt负责“本轮目标”每一轮的具体任务描述比如“用户想查询订单状态请先调用 get_order_info 工具”。上下文管理Context负责“历史信息与状态”把之前的对话摘要、当前状态、中间结果喂给模型让它能接上上下文。这样分开之后的好处是改任务需求不用动系统提示词改工具调用规则不用动每轮的 prompt整个 Agent 更好维护。而且大部分 Agent 框架LangChain、LangGraph、Spring AI 等都支持分开设置 system 和 user 消息拦的不是技术是思路。4.2 工具调用把“动作”描述成模型能理解的结构Agent 比单轮对话多出来的核心是工具调用。这时候提示词设计的一个关键问题是怎么让模型知道“什么时候该调用哪个工具参数怎么填”。如果你只是把函数的说明贴在提示词里让模型“看着用”它大概率会在不该调的时候调、该调的时候不调。更稳定的做法是显式的工具描述结构。我在 LangChain 这类框架里写工具时除了 function name / description / parameters 之外还会在 description 里补上“触发条件”和“忌讳调用条件”。比如tool def get_order_status(order_id: str) - str: 查询订单当前物流状态。仅当用户明确询问订单/物流/发货进度时调用。 触发条件 - 用户提供了订单号或询问“我的订单到哪了” - 用户提到“发货”“物流”“配送”关键词 不要使用此工具的场景 - 用户只是问“怎么退货”应调用 return_policy 工具 - 用户没有提供订单号先询问订单号 ...这种描述的效果是模型会先做“意图匹配”再决定调不调用而不是看到关键词就去调。这大幅减少了“错误工具调用”这种 Agent 场景里最常见的翻车点。4.3 上下文工程Agent 对话里最容易被忽略的坑提示词不是只有你写的那几行字——对模型来说每一轮对话累积的历史消息、工具返回的结果、系统预设全都是“隐式提示词”。这就是为什么很多人发现 Agent 在对话中间开始“失忆”或者输出偏差不是模型坏了是上下文污染了。我在实际开发中最常遇到的三类问题历史消息过长导致注意力漂移对话进行到二三十轮早期信息早就被“稀释”光了模型只能记住最后几条消息。解决方案是定期做摘要压缩把历史对话浓缩成几条关键事实再塞回去。工具返回的原始数据污染指令遵循工具返回一大段 JSON 之后模型的注意力会被这些结构化数据带走反而忽略了“下一步应该做什么”。解决方案是在工具返回前或返回后添加一段“基于以上结果你需要做什么”的指令性文本。用户的随意表达带偏 Agent 方向用户中途插一句“其实我就是想看看”就可能让 Agent 偏离原任务。这时候 system prompt 里要有“任务边界声明”无论用户怎么说你的目标是 X如果用户请求偏离目标请婉拒并重新引导。这就是圈子里经常讨论的“提示词工程与上下文工程”的差异——提示词工程解决“怎么说清楚”上下文工程解决“怎么让模型持续保持对目标的聚焦”。做 Agent 光有前者远远不够。4.4 系统提示词与 Skill/Agent 的区别别在提示词里塞代码我之前看到很多人困惑“系统提示词工程和 Skill 机制有什么区别”。简单说系统提示词是给模型读的“说明书”Skill在很多 Agent 框架里指可复用的能力模块是一段可以动态插入提示词里的“专家级文本模块”。这两者核心区别在于静态与动态。系统提示词是常驻的不管用户问什么模型都要看到它——适合放身份、安全规则、核心约束。Skill 类能力模块则不是常驻的而是按需加载的用户一问到“帮我写 Python 代码”框架才把“Python 专家 Skill”的提示词动态注入到当前上下文里。这样做的好处是省 token、不干扰无关任务、也不容易让模型“角色混乱”。所以我的建议是不要把什么都塞进 system prompt尽量把领域知识拆成可按需调用的 Skill 模块。这在 Agent 框架里对应的是 prompt selector / skill loader 这类机制。你越早建立这种模块化思维后面打量产级 Agent 越轻松。5. 调试提示词的实战过程从“答不对”到“稳定可用”提示词看起来是个创作工作实际上是一个工程调试过程。我见过很多人写提示词一遍过然后跑一次不行就开始全盘推翻重写最后越调越乱。我自己早期也这样后来摸索出一套相对可控的调试方法分享给大家。5.1 先定位是理解错、执行错还是格式错当模型输出不满足预期时第一步不是改提示词而是判断错在哪一层。我把问题分成三类理解错模型压根没搞懂任务输出内容答非所问或者方向偏了。执行错模型懂了任务但步骤执行得不对比如漏掉了某个条件、没用上上下文信息。格式错内容对但输出格式与下游不兼容比如没按 JSON 输出、多了解释文字。定位方法很简单把模型输出和你期望输出放在一起逐条对照看偏差是出现在“该做什么”还是“该怎么做”还是“该输出成什么样”。定位之后再做针对性修改不要一条提示词从头改到尾。5.2 拆变量一次只改一个条件提示词调试最大的坑是“变量混动”。比如你同时改了任务描述、加了示例、又换了温度参数结果输出变好了——你根本不知道是哪个改动起了作用。下次遇到类似问题你无法复现成功经验。正确做法是像做实验一样一次只改一个条件其他全部锁定。比如先保持提示词不变只把 temperature 从 0.7 调到 0.1观察稳定性变化再保持参数不变加一个示例观察格式遵循度。每一步都有明确变量才能形成可复现的调优结论。我实际做的时候还会保留一个提示词版本管理表记录每次改动的版本号、改动内容、测试结果。Agent 项目跑久了你会感谢这个习惯——否则三个月后你根本想不起来现在这版提示词是怎么演化来的。5.3 回归测试提示词的“用例”意识提示词也值得写测试用例。我在 Agent 项目里会维护一组固定的评测输入每组输入配上期望输出断言可以是解析结果的检查规则也可以人工判断标准每次调整提示词后都拿这组用例跑一遍回归。这个习惯救过我很多次——有时候改动会让 A 场景变好却悄悄破坏了 B 场景的稳定性。用例的覆盖要比你想的更全面至少包括常规情况正常需求期望模型按标准流程处理。边界情况用户输入极端简短、信息不全、类型混乱。禁忌情况用户试图让 Agent 偏离任务目标、跨边界操作。工具异常工具返回错误或空数据模型能否合理处理。5.4 常见问题速查表我把实际开发中最常遇到的几种提示词问题整理成一个速查表方便大家直接对照问题现象最可能原因建议手段模型输出格式飘忽不定未锁格式或示例缺失在提示词末尾追加“只输出 JSON”并按示例锁结构模型不调用工具工具描述里没有触发条件在工具 description 里写触发条件和不调用的场景多轮对话后失忆上下文太长、信息稀释定期做对话摘要压缩关键事实前置模型过度发挥、编造事实CoT 引导过度或约束不足加“只基于提供上下文回答”的强约束调低温度输出内容泛化成套话角色和上下文缺失补充角色设定和具体业务背景解析失败率高输出里夹带解释字符用 stop 参数、强制格式、few-shot 模板固化输出这套速查表不替代调试流程但能帮你快速定位问题的大方向省掉很多盲目试错。6. 当提示词撑不住的时候把工程升级成流程提示词不是万能的。我见过太多项目在提示词上死磕到最后一地鸡毛——为了一个稳定的输出结果反复堆提示词内容、堆示例、堆约束最后提示词长得像一篇论文成本高、维护难还经常因为一个小改动引发连锁反应。做 Agent 到这个阶段需要换个思路把提示词的一部分职责“卸载”到工程框架里。6.1 识别提示词的边界哪些问题适合靠提示词解决哪些该用代码解决我的划分标准很简单内容层面的事情语气、角度、详略、信息组织交给提示词。流程层面的事情分支判断、状态管理、重试机制、数据校验交给代码而不是试图用提示词“说服”模型永远不犯错。举个例子Agent 的工具调用返回一个 JSON里面有个字段可能缺失。你可以在提示词里写“如果字段缺失请这样处理”来碰运气但更稳妥的做法是在代码层做字段校验——缺失就触发重试或走兜底逻辑。提示词负责“生成”,代码负责“兜底”这个分工应该是 Agent 架构设计的基础认知。6.2 标准化的下一步提示词模板 工作流当你的 Agent 从“一个好玩的东西”变成“一个要稳定上线的服务”时我特别推荐把核心提示词做成模板和版本化管理。具体操作上把提示词中容易变化的部分比如用户输入、工具返回结果替换成模板变量再用一个统一的渲染函数来生成实际请求。这样提示词的改动不再散落在代码里而是集中在专门的 prompt 目录下做 diff、回滚、审查都方便。再进一步如果你用的框架支持 LangGraph 这类图状编排可以把复杂 Agent 拆成“流程节点 节点内提示词”的结构。比如“意图识别节点 → 信息收集节点 → 方案生成节点 → 复核节点”每个节点一个专职提示词比一个全能的巨型提示词要可靠得多。这就是为什么现在圈子里都在聊“从提示词工程到 Agent 工程”的升级——单一的提示词只是 Agent 的一块砖流程编排能力才是承重墙。6.3 给 AI Agent 学习之路的衔接建议这是 AI Agent 学习之路系列的第二篇如果你想继续深入我的个人建议是把提示词掌握到“能稳定解决单点任务”的程度后赶紧往三个方向进阶——一是理解 Agent 框架内部是怎么把提示词、工具、记忆组合起来的二是学会用 LangGraph 这类编排工具做一个需要多步骤决策的真实 Agent三是开始关注上下文工程和评估体系这才是 Agent 能不能落地到业务里的分水岭。不要沉迷于“调一个超神提示词”的体验那会让你误以为提示词就是 Agent 的一切。等你看过真实业务中那些复杂的用户输入、混乱的工具返回、以及模型时不时的不确定性你会明白提示词是对模型的“第一层约束”工程架构是“第二层约束”两者配合才能做出真正耐用的 Agent。我在实践中最大的体会是好提示词不是写出来的是“改出来的”。没有任何人第一版就能写出完美的提示词但你只要建立结构化的写法、有方法地调试、敢把不稳定的部分交给工程兜底这条路其实比大多数人想象得更快。下一篇我会继续往 Agent 框架走把 LangChain 和 LangGraph 里提示词如何与工具、记忆、流程真正串起来这件事讲透——到时候你会发现提示词工程积累下的这套“写清楚、拆变量、做回归”的习惯几乎是后面所有 Agent 开发动作的地基。