提示工程这件事很多人以为就是把话说清楚但真上手做 AI Agent 项目之后你会发现同样一个模型、同样一个任务提示词写得对不对输出质量能差出三倍以上。我在搭建第一个 Agent 工作流的时候花了整整两天调一个意图识别环节最后发现问题根本不在代码逻辑而是提示词里少了一句约束条件。从那以后我就养成了一个习惯任何 Agent 项目提示词必须当作核心代码来管理而不是随手写一段话丢进去。这篇内容围绕 AI Agent 学习之路的第二站——提示词与提示工程展开。不管你是刚接触大模型应用开发的新手还是已经能跑通简单 Agent 流程但效果不稳定的开发者这里面的思路和实操细节都能直接拿去用。我会从提示词为什么在大模型里管用讲起一路拆到结构化提示词的设计方法、Agent 场景下的特殊技巧、常见翻车案例的排查链路以及怎么把提示词当成工程资产来维护。1. 提示词为什么能指挥大模型1.1 从补全机制理解提示词的本质要搞明白提示词为什么有效得先理解大模型到底在做什么。本质上大语言模型是一个下一个 token 预测器——你给它一段文本它根据训练时学到的统计规律预测接下来最可能出现的 token 序列。这个机制听起来简单但它意味着一个关键事实你输入的每一个字都在改变模型对接下来该输出什么的概率分布。打个比方模型像是一个阅遍了海量文本的超级模仿者。你给它一个开头它会顺着这个开头的风格、语气、逻辑往下接。你写请用三句话总结以下内容它就进入总结模式你写你是一位资深律师请分析以下合同条款的风险点它就切换到法律分析模式。提示词的作用就是通过精心构造的输入文本把模型引导到你需要的那种输出分布上。这也解释了为什么同一个问题换个问法答案质量天差地别。不是模型听懂了而是你的提示词改变了它预测下一个 token 的概率分布让它更可能生成你想要的输出。1.2 上下文窗口提示词的物理边界每个大模型都有上下文窗口限制也就是一次能处理的 token 总量。这个窗口里要装下你的系统提示词、用户输入、历史对话、工具调用结果以及模型即将生成的输出。很多人写提示词时忽略了这个约束系统提示词写了三千字用户再输入一大段历史对话又堆了一堆结果模型能用来思考的空间被严重压缩输出质量断崖式下降。我在实际项目里的经验是系统提示词控制在 500 到 1500 字之间比较合理核心指令放前面示例和边界情况放后面。如果确实需要大量规则考虑拆分成多个 Agent 节点每个节点只负责一小块任务而不是把所有规则塞进一个提示词里。注意不同模型的 token 计算方式不同。中文大致是 1 个汉字对应 1 到 2 个 token英文大致是 1 个单词对应 1 到 1.5 个 token。写提示词时心里要有个大概的数别等到报错了才想起来查。1.3 温度参数与提示词的配合关系温度参数控制模型输出的随机性。温度越低输出越确定、越保守温度越高输出越发散、越有创造性。这个参数和提示词是配合使用的不是独立的。做 Agent 里的意图分类、信息抽取、格式转换这类任务时温度建议设到 0 到 0.3同时提示词里要给出明确的输出格式约束。做创意文案、头脑风暴这类任务时温度可以调到 0.7 到 1.0提示词里则要鼓励模型给出多种可能性。我见过不少人调了半天提示词效果不好最后发现是温度设成了默认的 0.7 去跑结构化抽取任务。这种问题不是提示词能救的参数和提示词必须一起调。2. 结构化提示词的四个核心组件2.1 角色设定给模型一个身份锚点角色设定是提示词里最容易被低估的部分。很多人觉得你是一个助手这种话是废话但实际上角色设定给模型提供了一个身份锚点让它知道该从哪个知识领域、哪种语气、哪个专业水平来回答问题。有效的角色设定要具体。对比一下弱设定你是一个编程助手强设定你是一位有十年经验的 Python 后端工程师擅长 FastAPI 和数据库优化回答时优先给出可运行的代码示例并标注常见的性能陷阱强设定不仅告诉模型你是谁还隐含了你该怎么回答。这在 Agent 场景里尤其重要因为 Agent 往往需要模型扮演特定职能角色比如客服意图分类器代码审查员数据分析师。2.2 任务指令把做什么拆到不能再拆任务指令是提示词的核心。我踩过最大的坑就是指令写得太笼统。比如帮我分析这段代码的问题模型可能给你返回一堆泛泛而谈的建议。但如果你写成请检查以下 Python 代码中的三类问题第一是否存在未处理的异常第二是否有 SQL 注入风险第三变量命名是否清晰。按类别逐条列出每条给出修改建议输出质量立刻不一样。拆解任务指令有个实用方法问自己如果我把这个任务交给一个新人他需要知道哪些具体信息才能做好。把这些信息全部写进指令里基本就到位了。2.3 输出格式约束让结果可被程序消费在 Agent 工作流里模型的输出往往要传给下一个节点处理所以格式约束不是锦上添花而是必须项。常见的格式约束方式有几种格式类型适用场景示例写法JSON结构化数据抽取、工具调用参数以 JSON 格式输出包含 name、type、confidence 三个字段Markdown 表格对比分析、清单整理用 Markdown 表格输出列为问题、严重程度、建议分隔符分隔简单列表、批量处理每条结果用 --- 分隔不要添加额外说明固定标签分类结果、枚举值只输出以下之一正面、负面、中性格式约束要配合反面约束使用。比如你要求 JSON 输出最好加一句不要输出任何 JSON 以外的解释文字。模型有时候会好心地加一段以下是我的分析结果这在前端解析时就是灾难。2.4 示例注入少样本学习的威力给模型几个输入输出示例效果往往比写一大段规则描述还好。这叫少样本提示Few-shot Prompting。原理很简单模型通过示例直接看到了你想要的输入输出映射关系不需要从抽象规则里去推理。示例的选择有讲究示例要覆盖典型情况和边界情况不能只给正常的例子示例的格式必须和真实输入完全一致包括标点、换行、字段名示例数量控制在 2 到 5 个太少不够说明问题太多浪费上下文窗口示例的顺序有影响把最重要的示例放在最后模型对靠近输出的内容更敏感我在做信息抽取 Agent 时通常会给三个示例一个标准情况、一个字段缺失的情况、一个包含干扰信息的情况。这样模型遇到各种输入都能稳住。3. Agent 场景下提示词的特殊打法3.1 系统提示词与用户提示词的分工在 Agent 架构里提示词通常分两层系统提示词System Prompt和用户提示词User Prompt。系统提示词定义 Agent 的人格和行为准则用户提示词是每次调用时传入的具体任务。分工原则是这样的不变的规则放系统提示词变化的输入放用户提示词。比如一个客服 Agent系统提示词里写你是一个电商客服助手回答要简洁友好不承诺无法兑现的售后政策遇到退款问题引导用户提供订单号用户提示词里则是具体的用户问题。这样设计的好处是系统提示词可以复用不用每次调用都重新构造。但要注意有些模型对系统提示词的遵循度不如用户提示词高关键约束可以在用户提示词里再强调一遍。3.2 工具调用场景下的提示词设计Agent 和普通聊天机器人最大的区别是能调用工具。工具调用的提示词设计有几个关键点第一工具描述要精确。每个工具的用途、参数、返回值都要写清楚模型才能正确选择。工具描述写得含糊模型就会乱调或者不调。第二要在提示词里明确什么时候该调工具什么时候不该调。比如如果用户询问实时天气调用天气查询工具如果用户只是闲聊直接回答不要调用任何工具。第三要处理工具调用失败的情况。提示词里加一句如果工具返回错误向用户说明情况并建议替代方案不要编造数据能避免很多幻觉问题。3.3 多轮对话中的提示词状态管理Agent 往往需要多轮交互这就涉及对话历史的管理。把所有历史都塞进上下文很快就会超出窗口限制但丢太多历史模型又会失忆。我的做法是分层管理最近 3 到 5 轮对话保留完整内容更早的对话压缩成摘要。摘要的生成也可以用模型来做提示词写成请用一句话总结以下对话的核心信息和已确认的事实。另外在多轮对话里要定期重申关键约束。比如一个订票 Agent系统提示词里写了确认订单前必须复述所有信息让用户确认但在长对话中模型可能忘记。可以在每轮用户输入前用系统消息再提醒一次关键规则。4. 提示词翻车的典型场景与排查链路4.1 输出格式不稳定从解析失败反推提示词问题这是最常见的翻车场景。你要求 JSON 输出模型有时候给纯 JSON有时候加一段解释有时候字段名拼错。排查链路是这样的第一步检查提示词里有没有明确的格式约束和反面约束。如果只写了输出 JSON而没有不要输出其他内容模型加解释是正常的。第二步检查示例。如果你给了示例示例本身是不是严格的 JSON模型会模仿示例的格式示例不规范输出就不规范。第三步检查温度参数。温度太高格式稳定性会下降。结构化输出任务建议温度设到 0.2 以下。第四步考虑用模型提供的结构化输出功能。现在很多模型 API 支持 JSON Mode 或 Function Calling能从底层保证格式比纯靠提示词约束可靠得多。4.2 指令遵循度低模型选择性失明怎么办有时候提示词里写了五六条规则模型只遵循了前两三条。这不是模型不听话而是有几个可能的原因原因一规则太多超出了模型的注意力分配。解决方案是把规则按优先级排序最重要的放最前面或者拆分成多次调用。原因二规则之间有冲突。比如你既要求回答要详细又要求回答不超过三句话模型只能二选一。写提示词时要自查规则之间是否矛盾。原因三规则表述有歧义。中文的歧义性比英文高写提示词时要尽量用明确的、无歧义的表述。比如适当简化就不如删除所有形容词和副词明确。4.3 幻觉问题提示词能做什么、不能做什么幻觉是大模型的固有问题提示词能缓解但不能根治。有效的缓解手段包括明确告诉模型如果不确定说不知道不要编造提供参考资料让模型基于资料回答而不是靠记忆要求模型给出信息来源或推理过程在 Agent 场景里用工具调用来获取事实性信息而不是让模型回忆但要清醒认识到这些手段只是降低幻觉概率不能消除。关键业务场景必须有后置校验环节。5. 把提示词当代码来管理5.1 版本控制与 A/B 测试提示词改了之后效果变好还是变坏不能靠感觉判断。我的做法是给每个提示词建版本号每次修改记录改动内容和原因然后用一组固定的测试用例跑对比。测试用例要覆盖正常输入、边界输入、异常输入。每次改提示词跑一遍测试集看通过率有没有下降。这套流程听起来麻烦但比线上出问题再回滚要省事得多。5.2 提示词模板化与参数注入在实际项目里提示词往往不是写死的而是带参数的模板。比如请分析以下{language}代码的{aspect}问题调用时填入具体值。模板化要注意两点一是参数注入的位置要明确避免歧义二是要对参数做转义处理防止用户输入的内容越狱提示词结构。比如用户输入里如果包含忽略以上指令这类文本要有防护措施。5.3 提示词长度与成本的平衡提示词越长消耗的 token 越多成本越高而且过长的提示词反而会降低模型对关键信息的注意力。我的一般原则是能一句话说清楚就不写一段能用一个示例说明就不写三条规则。定期审查提示词删掉那些写了但从来没起作用的内容。我每隔一段时间就会把线上提示词拿出来逐条问自己这条规则最近有没有实际影响过输出没有的话就考虑删掉。6. 从提示词到提示工程建立系统化方法论6.1 迭代式提示词开发流程提示词不是一次写好的是迭代出来的。我的开发流程大致是第一轮写一个最小可用的提示词能跑通基本流程就行。第二轮用真实数据测试收集失败案例。第三轮针对失败案例修改提示词补充约束或示例。第四轮回归测试确认修改没有引入新问题。循环二到四直到通过率达到可接受水平。这个流程的关键是用数据驱动修改而不是凭感觉调。每次修改都要有明确的失败案例作为依据。6.2 不同模型的提示词适配同一个提示词在不同模型上的效果可能差异很大。有的模型对系统提示词遵循度高有的模型更依赖用户提示词有的模型对格式约束敏感有的模型需要更多示例。做多模型适配时建议把提示词拆成通用部分和模型特定部分。通用部分是任务描述和核心约束模型特定部分是格式调整、示例数量、特殊标记等。这样切换模型时只需要改特定部分。6.3 提示词工程的边界什么时候该考虑微调提示词工程有它的边界。当你发现无论怎么调提示词效果都达不到要求时可能就该考虑微调了。判断标准大致是任务非常垂直通用模型缺乏领域知识对输出格式和风格有极其严格的要求提示词已经长到接近上下文窗口限制有足够的标注数据用于微调但微调不是万能的它需要数据、算力和维护成本。大多数场景下好的提示词工程加上合理的 Agent 架构已经能解决百分之八十的问题。7. 实操中积累的几个关键心得7.1 提示词里的负面指令要慎用不要做什么这类负面指令模型遵循起来比正面指令差。心理学上有个说法叫白熊效应——你越说不要想白熊越会想白熊。模型也有类似问题你写不要输出 Markdown 格式它反而可能因为看到了Markdown这个词而输出 Markdown。更好的做法是用正面指令替代负面指令。不说不要输出解释而说只输出结果本身。不说不要编造数据而说只使用提供的资料中的信息。7.2 分隔符是提示词的标点符号在提示词里用清晰的分隔符把不同部分隔开能显著提升模型的理解准确度。常用的分隔符有三引号、XML 标签、Markdown 标题等。比如### 任务 分析用户评论的情感倾向 ### 输入 用户评论内容放在这里 ### 输出格式 只输出正面 / 负面 / 中性这种结构让模型一眼就能看出哪部分是任务、哪部分是输入、哪部分是格式要求比一大段连续文本清晰得多。7.3 测试用例要刁钻一点很多人写测试用例只写正常情况结果上线后遇到边界情况就翻车。我的经验是测试用例里至少要有三成是刁钻的空输入、超长输入、包含特殊字符的输入、语义模糊的输入、和任务无关的输入。这些刁钻用例能帮你发现提示词的脆弱点。比如空输入时模型会不会崩溃超长输入时会不会截断关键信息特殊字符会不会破坏格式约束。7.4 记录提示词决策日志这是个容易被忽略但很有用的习惯。每次修改提示词记录三件事改了什么、为什么改、改后效果如何。过一段时间回头看你会发现很多当时觉得很重要的修改其实没起作用而一些随手加的小改动反而效果显著。这份日志在团队协作时尤其有价值能让其他人理解提示词里每条规则背后的意图避免误删关键约束。7.5 别忽视提示词的可读性提示词是给人维护的不是只给模型看的。写得乱七八糟的提示词过两周自己都看不懂。建议用统一的格式规范任务描述用一段话约束条件用列表示例用代码块各部分之间用分隔符隔开。可读性好的提示词修改起来快交接给同事也容易。这在长期项目里能省下大量沟通成本。8. 一个完整的提示词设计实例拆解8.1 需求场景描述假设我们要做一个代码审查 Agent输入是一段 Python 代码输出是结构化的审查意见。这个 Agent 需要识别代码中的潜在问题按严重程度分类并给出修改建议。8.2 提示词初稿与问题分析初稿可能是这样的请审查以下 Python 代码指出问题并给出建议。这个提示词的问题很明显没有角色设定没有输出格式约束没有严重程度分类标准没有示例。跑出来的结果大概率是一堆泛泛而谈的建议格式还不统一。8.3 结构化改造后的提示词改造后的版本### 角色 你是一位有十年经验的 Python 代码审查专家熟悉 PEP8 规范、常见安全漏洞和性能优化技巧。 ### 任务 审查以下 Python 代码识别问题并按严重程度分类。 ### 审查维度 1. 安全性SQL 注入、命令注入、敏感信息硬编码 2. 健壮性异常处理、边界条件、空值处理 3. 性能循环效率、数据库查询、内存使用 4. 可读性命名规范、注释、函数长度 ### 输出格式 以 JSON 数组输出每个元素包含 - severity: high / medium / low - category: 问题类别 - line: 行号如无法确定写 null - issue: 问题描述 - suggestion: 修改建议 不要输出 JSON 以外的任何内容。 ### 示例 输入 def get_user(id): return db.query(SELECT * FROM users WHERE id id) 输出 [ { severity: high, category: 安全性, line: 2, issue: SQL 语句通过字符串拼接构造存在 SQL 注入风险, suggestion: 使用参数化查询db.query(SELECT * FROM users WHERE id ?, [id]) } ] ### 待审查代码 {code} 8.4 改造前后的效果对比改造前输出是自由文本格式不统一问题分类模糊经常漏掉安全问题。改造后输出是标准 JSON可以直接被程序解析严重程度分类明确安全问题基本不会漏。这个例子的核心思路是把模糊的需求转化为明确的维度、格式和示例。提示词工程的大部分工作其实就是这个翻译过程——把人类脑子里的隐性要求翻译成模型能明确执行的显性指令。9. 提示词工程的持续精进路径提示词工程不是学一次就够的技能它随着模型能力的变化、业务场景的演进而不断更新。我自己的精进路径大致是三个阶段。第一阶段是能用就行重点是跑通流程理解提示词的基本结构。这个阶段多试多错积累直觉。第二阶段是稳定可靠重点是建立测试用例、版本管理、格式约束这些工程化手段。这个阶段的关键词是可复现。第三阶段是系统优化重点是从单个提示词上升到 Agent 架构层面思考——什么时候该拆节点什么时候该加工具什么时候该上微调。这个阶段需要的是系统思维而不是单点技巧。回到 AI Agent 学习这条线提示词和提示工程是绕不过去的基本功。Agent 的规划能力、工具调用能力、记忆管理能力底层都依赖模型对提示词的理解和执行。把这一环打扎实后面搭复杂 Agent 工作流的时候会顺畅很多。我在实际项目里最深的体会是与其花时间追新框架不如先把提示词写明白——框架会过时但把需求清晰地表达给模型这个能力会一直有用。