最近好几个朋友跟我聊AI Agent学习发现一个特别普遍的现象代码能跑通平台也会配但Agent一旦接入真实业务输出就开始“放飞自我”——要么答非所问要么格式乱七八糟要么干脆把流程跑崩。聊到最后基本都会落到同一个问题上提示词工程Prompt Engineering没过关。很多人以为提示词工程就是“把话说得礼貌一点”或者“多写几句要求”这恰恰误解了它。在AI Agent开发里提示词不是写给搜索引擎看的指令而是给Agent的“岗位说明书操作手册质量标准”。模型能力再强、工具链再完善提示词写不透整个Agent就是一只无头苍蝇。这篇文章我就从实操角度把提示词工程最核心的“三板斧”拆开讲第一板斧是角色与边界设定第二板斧是上下文塑造与示例驱动第三板斧是输出控制与思维引导。每一板斧我都会给模板、举例和踩坑记录适合AI Agent入门者、被Prompt坑过的开发者以及想用n8n、Dify、Coze这些平台做自动化但不知道怎么把提示词写稳的人。1. 为什么学AI Agent绕不开提示词工程1.1 AI Agent到底在做什么提示词扮演什么角色先对齐一个基本认知。AI Agent并不是“一个更聪明的聊天机器人”它本质上是一个能自主完成任务的系统拿到一个目标自己决定先做什么、后做什么调用工具、读取文件、访问数据库最后产出一个结果。这个系统的核心驱动是大语言模型而提示词工程就是人类和这个“模型大脑”之间唯一的、最直接的沟通通道。可以把Agent类比成一个刚入职的实习生。实习生脑子很聪明但你对他说“把项目跟一下”他大概率不知道先干什么。你说“下午3点前把竞品的定价和功能整理成一份表格重点标注和我们产品的差异格式用markdown遇到不清楚的信息标注为待确认”他就能按图索骥。提示词工程干的正是这件事把一个模糊目标翻译成模型能理解、能执行、能稳定产出结果的精确指令。在很多AI Agent框架里Prompt会同时出现在多个位置系统提示词里定义人设和全局规则用户输入里描述当前任务工具调用节点里有给模型的工具说明工作流节点之间还要传递上下文。每一处都涉及提示词设计任何一处写得不清楚最后输出的质量都会打折。这也是为什么我常说AI Agent开发的门槛看起来在代码实际上真正的分水岭在提示词。1.2 提示词工程的本质从“让模型回答”到“让Agent干活”我的一个很深的体会是提示词工程的目标不是“让模型说一句正确的话”而是“让模型稳定地完成一个任务”。这俩差别非常大。如果你只是偶尔用一次ChatGPT写文案那提示词随便点无所谓因为生成结果的好坏你一眼就能判断不满意再生成一次就行。但AI Agent场景不一样Agent是自动化系统的一部分它可能每天要处理几百上千个请求不可能有人在旁边逐条检查。这时候你要求的是同样的提示词今天跑和明天跑结果质量必须稳定换一种表达方式输入Agent也不能崩溃输出格式必须能被下游程序解析。这套稳定性要求正是提示词工程存在的意义。另一个关键是“让Agent干活”意味着提示词要承担流程控制的角色。举个例子你要Agent从一份PDF里提取客户信息并写入CRM系统那提示词里至少得包含文档从哪里读、提取哪些字段、字段格式是什么、遇到缺失值怎么处理、要不要做数据清洗。这些内容不是“提示”而是“业务规则”。写提示词的人必须把业务规则翻译成模型能遵循的语言这就是工程化的核心。1.3 为什么是“三板斧”而不是“十八般武艺”市面上讲提示词技巧的文章非常多什么角色扮演、Few-shot、思维链、ReAct、Self-Consistency、ToT、结构化输出、格式限定……几十种名词混在一起新手很容易看晕。我自己带过很多新人发现一个规律如果你不是做前沿研究的绝大多数花哨技巧在真实Agent项目里根本用不上或者用上了也感知不到明显提升。真正决定Agent好不好用的就三件事第一Agent知不知道自己是干什么的、边界在哪里——这是角色与边界设定第二Agent有没有足够多、足够清晰的参考信息——这是上下文塑造与示例驱动第三Agent的输出能不能被稳定解析、推理过程是否可控——这是输出控制与思维引导。这三件事我称为“三板斧”是因为它们环环相扣而且覆盖了Prompt从设计、填充到交付的完整链路。把这三板斧练扎实比收集一百条技巧都管用。后面几节我就逐个展开。2. 第一板斧角色与边界设定2.1 把“人设”写清楚角色、能力、限制条件第一板斧的关键词是“定位”。一个Agent上线之前你必须想清楚它的岗位职责是什么。很多新手写System Prompt上来就是一句“你是一个AI助手”这句话等于没写。它没有给模型任何有效约束。我推荐用“角色能力限制”的三明治结构来写人设。角色是“你是谁”能力是“你能干什么、擅长干什么”限制是“你不能干什么、什么情况下要拒绝”。三部分缺一不可。举个我在项目里用过的例子一个售后客服Agent的System Prompt片段你是一名资深的售后客服专员熟悉电子产品退换货流程。你的职责是解答客户的退换货政策问题、协助客户提交售后工单、安抚情绪激动的客户。你没有权限处理退款金额超过500元的申请遇到这类问题请引导客户联系人工客服你不了解物流配送的具体节点遇到物流问题请统一回复“我们已为您记录将在1个工作日内由专员跟进”。这个提示词里角色客服专员、能力退换货解答、工单协助、情绪安抚、限制退款金额超限转人工、物流问题不瞎答全都表达清楚了。模型看到这样的提示词行为边界就很明确。2.2 目标拆解把任务边界写进Prompt人设之外边界设定还有个容易被忽略的层次任务边界。也就是说对于手头这个任务Agent要做到什么程度、不做哪些事、输出给谁看。这些最好在Prompt里说死尤其当Agent被嵌入到工作流中时。我见过一个翻车案例某团队用Agent做销售线索筛选提示词只写了“帮我把所有线索按意向程度排序”。结果Agent把几万条线索全部排了序还生成一篇分析报告任务跑了40分钟费用烧掉一大截。后来他们改成了“只处理今天新增的线索单条超过500字的长文本先做摘要再判断输出前100条高意向线索每次最多调用3次数据库查询”整个流程立刻变得可控。这就是任务边界的作用告诉模型什么范围内活动、资源消耗上限在哪、最终输出形态是什么。千万不要觉得这些细节多余Agent不会“聪明地”自动优化这些事你不说它就按自己理解来。2.3 实操案例一个客服Agent的System Prompt把上面两点整合起来我分享一个可以直接套用的客服Agent System Prompt模板读者可以根据自己业务替换中括号里的内容角色定义你是一个[某某品牌]的[售前咨询顾问]服务于[目标用户群体]。核心目标帮用户[完成某个目标例如挑选合适商品、解答使用疑问、处理售后问题]。知识边界你只能使用“商品知识库”和“常见问题文档”里的信息作答不要引用外部知识。行为准则回答简洁、不超过[200]字语气友好如果用户提到[敏感词/高风险诉求]必须回复[固定话术]。处理不了的情况明确告知用户“已为你转接人工”不要尝试编造答案。输出要求如果用户要求表格对比请用Markdown表格输出其他情况用纯文本。这套模板的本质是把业务方关心的约束全部显式写出来。写完之后建议让同事扮演各种刁钻用户测试一遍重点看“拒绝场景”是否真的按预期执行比如用户问价格、问竞品、问政策细节时Agent能不能守住边界。2.4 常见误区人设太虚、边界太模糊第一板斧有三个高频误区我单拎出来说。误区一人设写成“你是无所不能的AI”。这会诱导模型过度自信业务里就是灾难。做客服就写客服做分析就写分析别什么都掺和。误区二只有“做什么”没有“不做什么”。模型是生成式的你给了正面指令它可能还会顺带发挥。一定要在提示词里预留“限制清单”明确哪些动作不能做、哪些说法不能说。误区三把边界写在Prompt末尾。大模型对指令的遵循并不是均匀的一般来说靠前的内容影响力更强。角色、边界这种“全局规则”应该放在System Prompt开头任务描述放在后面不要倒过来。3. 第二板斧上下文塑造与示例驱动3.1 Few-shot示例为什么好用第二板斧解决的是“模型不知道你要什么质量的结果”的问题。有时你描述得再清楚模型理解得还是“差不多”。这时候最有效的办法是直接给它看几个例子同样类型的输入输出应该长什么样。这就是Few-shot示例。Few-shot好用的底层原因很简单大语言模型本质上是模式识别器给它2到5个高质量示例它就能模仿出你想要的结果形态和风格。这比用几十句话描述“你要输出得很专业”有效得多因为“专业”是抽象概念而示例是具体标准。举一个我最常用的例子让Agent做“客户留言分类”输入客户留言你们这个app怎么一直闪退刚打开就没了气死我了 输出{category: 崩溃闪退, sentiment: 负面, urgency: 高, suggestion: 先安抚情绪再引导用户反馈手机型号与系统版本}输入客户留言想知道你们有没有教育优惠我是学生能便宜多少 输出{category: 价格优惠, sentiment: 中性, urgency: 中, suggestion: 告知教育优惠政策引导提供学生认证信息}只给一个例子和给两个例子效果可能还没那么明显但如果你给三个涵盖不同场景的例子模型基本就摸清了你想要的字段结构、情感标注方式和建议写法。这也是我在所有Agent项目里都会大量使用Few-shot的原因。3.2 上下文塑造给Agent“临时记忆”Agent和普通聊天机器人还有一个重要区别普通聊天只需要回答当前问题Agent却要结合历史状态、工具返回结果、外部文档等信息做出决策。这些信息统称为上下文怎么把这些上下文高效地组织进Prompt里就是上下文塑造。我的经验是上下文塑造要遵循三条原则相关性优先、去噪、明确来源。先说相关性优先。Agent可用的信息往往很多比如用户历史订单、聊天记录、知识库内容你不能全部塞进去一是塞不下二是信息太多反而干扰模型判断。好的做法是在进入模型前先做一轮筛选只保留和当前任务相关的片段。再说去噪。工具返回的数据经常包含大量冗余字段比如第三方API返回的几百个JSON字段里只有五六个有用。写Agent时最好在工具节点里做一次字段裁剪把纯净数据再扔给模型。最后是明确来源。在Prompt里告诉模型“以下是用户的知识库片段来源于公司内部文档仅作为参考不要直接复制”模型就知道怎么用这些信息而不是盲目照搬。3.3 工具调用与多模态场景下的上下文设计第二板斧在真实Agent项目里经常要在工具调用和多模态场景中应用。工具调用场景下模型需要在“回答问题”和“调用工具”之间做决策。提示词里如果能把每个工具说得足够清楚决策准确率会高很多。我给每个工具都写一段话作为上下文工具作用是做什么、接收什么输入参数、返回什么输出、什么时候该用、什么时候不该用。比如一个搜索工具可以写“仅当用户询问实时信息或知识库中没有的内容时才调用搜索前把问题翻译成简洁的中文关键词”。多模态场景又多了图片、音频、视频等输入。比如你用视觉模型识别一张票据提示词可以是“这是一张发票图片请提取发票号码、开票日期、金额、购买方名称输出JSON格式无法识别的字段填null”。这里同样可以用Few-shot给一张示例票据图片和对应的JSON输出模型会学得更快。3.4 实操案例JSON/表单自动填写Agent的Few-shot设计之前做一个表单自动填写Agent目标是从用户自然语言描述中提取字段填写到内部系统。我一开始只用自然语言描述字段规则准确率只有七成左右。后来我加了五个Few-shot示例覆盖了完整填、部分缺失、口语化表达、多条件同时出现、否定表达等边界情况准确率直接提升到九成以上。这里的关键是示例的质量。很多人的Few-shot凑数严重五个例子长得一模一样覆盖的全是理想场景。真正有效的Few-shot要刻意覆盖“难例”和“负例”你把难例都给了模型模型见过世面了真实数据过来才不会慌。还要提醒一句Few-shot不是越多越好。示例超过一定数量收益会递减还可能让模型过度模仿示例里的具体内容比如示例里有个“客户地址北京”用户的输入明明是上海模型也可能因为惯性输出北京。这种现象叫“示例污染”解决方法是每次从示例库里随机挑选并且确保示例里的占位值足够多样。4. 第三板斧输出控制与思维引导4.1 强制结构化输出JSON、Markdown、代码块第三板斧的关键词是“可控”。Agent的输出要被下游系统解析格式必须稳定。我最推荐的做法是强制结构化输出最常见的就是JSON其次是Markdown表格、代码块、XML标签。写JSON约束时我习惯在Prompt后面附上JSON Schema示例。比如请提取用户留言中的关键信息严格按照以下JSON结构输出 {category: 字符串取值只能是[售后,售前,建议,投诉], sentiment: 字符串只能是[正面,中性,负面], summary: 字符串不超过50个字} 只输出JSON不要输出任何解释文字。这段Prompt里“只输出JSON不要输出任何解释文字”这行特别重要。不加这行模型经常会在JSON前面加一句“好的提取结果如下”你解析时还得做清理。如果你用的模型支持函数调用或工具调用比如Claude、GPT-4o系列也建议优先用平台提供的结构化输出能力配合JSON Schema校验能进一步降低格式错误率。4.2 思维链让Agent“先说思路再下手”复杂任务里模型直接给答案容易出错。我对复杂任务的建议是在Prompt里明确要求模型“先展示思考过程再输出最终结果”。这就是思维链Chain-of-Thought技巧。思维链在Agent场景里尤其重要因为Agent经常需要先判断“该不该调工具”“先调哪个工具”“拿到结果后怎么用”。如果你不让模型把决策过程摊开它很可能一步跳到错误结论。比如让Agent分析销售数据Prompt可以写请按以下步骤处理 第1步列出本月销售额Top3的产品附上具体数字。 第2步对比上月数据计算环比增长率。 第3步只选择增长率低于10%的产品给出原因分析。 第4步输出最终结论格式为Markdown列表。步骤拆得越细模型执行越稳。这个操作的本质是把你的业务逻辑写进Prompt让模型沿着你的思路走而不是让它自由发挥。不过要注意思维链输出会消耗更多token成本也会相应增加。在实际项目里我通常只在复杂任务上启用完整思维链简单任务直接输出最后结果就好没必要事事都让模型长篇大论。4.3 自检查与反思机制让Agent学会自我纠错第三板斧里还有个容易被忽视的武器让模型对自己的输出进行复查。这在多数提示词教程里叫“Self-Consistency”或“Critic”中文语境下叫“自反思、自查”。做法也很简单就是在Prompt里加一句“在输出最终结果前请先检查上一版答案是否有明显遗漏、逻辑矛盾或格式错误如有问题请修改后再输出”。举个例子Agent生成一段SQL之前我要求它先执行“伪代码编写→SQL编写→自我检查→最终输出”四步。很多情况下模型在自检阶段确实能发现自己写错了表名、忘了加条件过滤。这一招成本极低收益却很高。更进一步的玩法是在Agent工作流里设置“双模型互检”一个模型负责生成另一个模型专门负责找茬。这在一些高可靠场景比如自动发邮件、自动改代码里很好用缺点是耗时翻倍适合低频高价值任务。4.4 实操案例让Agent写代码前先列计划我自己的AI编程工作流里最常用的是让代码Agent先做计划再动手。Prompt大概是你是一名资深Python工程师。现在要完成以下需求[需求说明]。 请先输出“实现计划”包括使用的第三方库、文件结构、核心函数签名。 计划通过后再编写完整代码。 代码编写完成后请自查三点1语法是否正确2是否处理了边界输入3是否添加了必要的注释。为什么要分三步因为在AI编程场景里模型一步到位生成的代码往往结构混乱。先列计划相当于让它先搭框架框架对了后面填充代码才不容易跑偏。这比直接让模型甩出一大段代码要实用得多。配合这套提示词我还会把温度参数调低一些一般设置在0到0.3之间。温度越低模型越保守越适合代码和逻辑任务写文案、头脑风暴才需要调高温度。5. 三板斧综合实战从零搭一个可用的AI Agent5.1 一个实际需求竞品资料整理Agent前面三板斧分开讲了这一节把它们串起来做一个完整项目一个竞品资料整理Agent。需求背景我每周要从各个渠道收集竞品动态包括官网公告、新闻稿、社交媒体帖子然后整理成一张表格标出“产品更新”“市场活动”“人员变动”三个类别并给每一条动态写一句话点评。如果用纯人工每周大概要花两小时。用Agent怎么做呢整体设计思路是输入一堆原始文本→Agent清洗分类→按固定格式输出→写入表格。这里的难点是输入来源杂、格式乱必须靠提示词把“分类标准和输出格式”固定住。5.2 三段式Prompt结构我会把整个Prompt设计成三个部分正好对应三板斧。第一段是System Prompt写角色和边界你是一名商业分析师擅长竞品信息收集与整理。你只能根据输入的原始内容作答不要补充自己知道的信息。如果原始内容里没有明确信息统一标记为“未知”。第二段是Few-shot示例给两个典型样例让模型知道“产品更新”和“市场活动”怎么区分、点评写到什么颗粒度。第三段是用户输入和输出约束以下是本周收集到的竞品原始信息请按以下要求整理分类必须从【产品更新、市场活动、人员变动】中选择。输出JSON数组每个元素包含date、category、title、source、comment。comment一句话点评风格客观不超过30个字。如果某条信息无法判断分类category填“待确认”。 原始信息如下 [输入文本]这个三段式结构里第一段定身份第二段给标准第三段锁格式和任务每板斧都用上了。5.3 在NoCode平台落地n8n、Dify、Coze里的配置思路很多读者不是纯代码开发而是在n8n、Dify、Coze这类平台里搭Agent。这里我结合经验说几个配置要点。在n8n里搭Agent通常会有“Agent节点”和“LLM节点”。提示词一般放在节点的System Message、Human Message里。我的经验是System Message放角色边界Human Message放当前任务Few-shot示例LLM节点的输出解析用“JSON方式”并打开“指定输出字段”开关这样模型输出后能直接变成结构化字段。在Dify里应用编排支持“上下文”窗口可以把知识库检索结果自动注入。这里特别提醒知识库返回的段落往往很长一定要在检索设置里限制片段长度和数量否则上下文太杂会干扰Agent判断。Dify的“变量”也可以动态拼进Prompt但注意变量内容要预先清洗。Coze这类产品更偏对话式Agent提示词里可以配合“插件描述”一起用。插件能力描述要写清楚“什么时候调用、传什么参数”这本身也是一种提示词工程别忽略。不管哪个平台底层逻辑都一样角色、示例、输出格式这三件事写到位了换平台只是改配置位置。5.4 Agent工作流中的提示词调优记录最后分享一个真实调优记录。这个竞品整理Agent第一版运行后出现两类问题一是有些动态被错误分类二是comment写得太长不像一句话点评。第一轮修改我在Few-shot里增加了一个“人员变动”的示例并特别标注“CEO离职属于人员变动不算产品更新”。准确率立刻上来一些。第二轮修改我把输出约束从“comment不超过30个字”改成了“comment必须是一句话不超过30个字直接给事实判断比如‘新版支持离线模式瞄准高铁场景’”并补了一个负面示例展示一条写了三个分句的超长comment标注“这是错误示范”。第二轮之后效果已经能满足我日常使用了。再往后我又做了第三轮优化这次的问题出在原始信息太脏很多帖子包含营销话术和无关内容。我在第一段System Prompt里加了一条“如果原始信息属于推广软文且不包含有效竞品动态请在category填‘跳过’”配合下游过滤整个流程就顺了。这个案例想说明的是Prompt调优不是一次性的而是一个持续迭代的过程。我的习惯是给每个Prompt建立版本记录写下每一版改了哪里、为什么改、效果如何下次回看时能少走很多弯路。6. 常见问题与排查技巧实录6.1 Agent“答非所问”怎么排查在实际使用中Agent答非所问是最常见的现象。我的排查顺序固定为三步先看System Prompt是否写清角色和边界再看Few-shot示例是否覆盖了当前输入类型最后看输入的任务描述是否够具体。举个例子有次我的Agent在处理“请帮我查一下昨天上海门店的销售额”时回答了一堆和销售额无关的建议。排查后发现System Prompt里写的是“你是一位门店运营助手可以给出门店运营建议”完全没提“查询数据”的职责。改成了“你可以查询门店销售数据并给出解读”问题立刻解决。如果三步排查都没发现问题建议把提示词里的大段内容精简后重新测试。有时候是信息冗余导致模型抓不住重点删掉一些无关历史信息反而更准。6.2 输出格式老是不稳定怎么破格式不稳定是Agent自动化的头号杀手。我见过不少项目卡在这一步模型99%的情况下输出正常但1%的情况下JSON里多了一个逗号程序直接崩了。解决办法分三个层次。第一层是提示词层面把输出格式写清楚并强调“只输出JSON不要解释”。第二层是解析层面不要用简单字符串正则硬解析用支持容错的JSON解析器或者先把模型输出包裹在Markdown代码块里再提取能防住大多数小错误。第三层是模型能力层面尽量选择对结构化输出支持更好的模型或者开启平台的JSON模式、函数调用能力。这一条尤其重要Agent不是发完消息就不管了程序的健壮性要靠“提示词约束解析容错异常兜底”三层来保证缺一不可。6.3 上下文太长或太短怎么办Agent在长对话或多次工具调用中很容易把上下文窗口撑爆。这时候别硬塞我的做法是先做裁剪再做摘要最后才考虑换更大上下文的模型。裁剪比较好理解就是把没用的历史记录和工具返回数据扔掉。摘要则是我更推荐的方案让模型定期把前面的对话压缩成一个结构化的“状态记忆”短文本例如“用户偏好需要价格敏感的产品当前进度已完成需求确认下一步等待审批结果”。这样对话再长Agent也能快速恢复状态。上下文太短的问题则往往是因为Prompt里该给的背景没给够。判断标准很简单把自己当成第一次读到这个任务的陌生人如果发现“用户为什么要提这个问题”完全不清楚那就需要补充上下文。6.4 多模型、多平台切换时的提示词陷阱同一个Prompt在OpenAI模型上表现很好换到Claude或国内开源模型上可能就崩了。这不是模型“变笨了”而是不同模型的指令遵循能力、格式敏感度、上下文理解风格都有差异。我踩过的一个坑是在某个模型上写“严格按JSON输出”很管用换一个模型它还是会多输出一段解释性文字。解决办法是在Prompt里同时用“只输出JSON”和“将结果放在代码块内”双重约束通用性会好很多。另一个坑是某个模型对英文指令遵循度更高直接用中文写“不要解释”效果打折这时可以在关键约束后面补一句英文“Output only JSON, no explanations.”。别觉得这是崇洋媚外工程场景里怎么有效怎么来。如果你在同一个Agent里串了多个模型比如一个负责理解、一个负责生成那还要注意提示词风格的一致性。别让前一个模型输出格式和后一个模型要求不一致否则报错会很难查。6.5 提示词问题排查速查表下面这个表格是我在实际项目里整理的排查清单按照“看哪里、怎么改”来写比较适合当工作手册用。症状可能原因排查与解法Agent答非所问角色/边界缺失检查System Prompt补全角色、能力、限制输出格式不稳定约束不够强加“只输出JSON”、配合代码块、开启JSON模式结果太啰嗦输出长度约束缺失在Prompt里加字数上限并给一个简短示例分类结果不准示例太少或太偏补充难例、负例覆盖真实边界场景上下文太长报错历史/工具数据过多裁剪字段、定期摘要记忆、限制检索片段数量不一致结果温度过高降低temperature逻辑任务建议0~0.3换模型后崩指令风格不兼容增加中英双语强约束用平台结构化输出能力工具调用乱选工具描述不清给每个工具写明白作用、参数、何时调用6.6 我的三个放之四海而皆准的调试技巧最后再送三个我每次调试提示词都会用的小技巧。第一个技巧把提示词当成代码来管理。每次修改都保存一个版本甚至用Git管理。很多次我改来改去最后发现还是第一个版本最好用没有版本控制就只能靠拍脑袋回想。第二个技巧准备一个“测试用例集”。找10条有代表性的输入每次改完Prompt跑一遍全套用例对比输出是否变好。这比东测一条西测一条靠谱得多。第三个技巧多写“负面约束”。人类指令往往只写“要什么”很少写“不要什么”。但模型恰恰最需要知道“不要什么”。我每次写Prompt都会刻意加一节“禁止事项”比如“不要编造数据”“不要输出与问题无关的建议”“不要使用夸张的宣传语气”。这一节写好Agent会立刻变得专业起来。我个人在实际操作中的一个体会是提示词工程不是“写一次就完事”的艺术品它更像是一块需要不断打磨的零件。AI Agent的项目里模型选型决定了能力上限而提示词工程决定了你能发挥出这个上限的多少成。三板斧看着简单每板斧都练到位你的Agent就从“偶尔聪明”变成“稳定好用”。这中间的差距就是普通跑通和真正能上线交付之间的距离。最后再分享一个小技巧不要只盯着公开的提示词模板抄一定要把你自己业务里的真实数据贴进去测试。模板给的是框架业务给的是灵魂。把这三板斧和你的数据不断碰撞、调整你会很快找到适合自己Agent的那套稳定提示词。
