1. 提示词监控为什么成了刚需1.1 提示词不再是静态文本而是需要持续维护的软代码很多开发者对提示词的理解还停留在一段能跑通的文本这个层面。拿到需求写一段提示词测试几个case效果不错就上线了之后再也没有人关心它。这种思路在demo阶段没有任何问题但到了生产环境情况就完全不同。我在某个电商平台的智能客服项目中负责提示词设计最初上线的30多套提示词都经过了仔细调优各种边界case都覆盖到了。然而上线后不到两周就有运营同事反馈说机器人最近怎么开始胡说八道了。我一开始以为是模型抽风查了日志、复测了case发现提示词本身一个字都没改但线上效果就是变差了。后来对照了模型版本号才发现是模型供应商在后台升级了模型新版本的输出风格、指令遵从能力和旧版本有明显差异我们原先基于旧模型调出来的提示词在细节上已经不太适配了。这个经历让我意识到生产环境中的提示词本质上和代码是一样的它会依赖外部环境模型版本、输入数据分布会被业务需求牵着走也需要持续观察和维护。代码有CI/CD、有测试、有监控告警提示词却往往是裸奔的状态。所谓提示词监控就是给这些软代码补上从开发到运维的完整管理环节。1.2 提示词失效的三种典型场景根据我这几年的实践经验提示词在线上出问题基本逃不出以下三类场景第一类是基础环境变化。最常见的就是模型版本更新包括模型供应商主动升级、你主动更换更强的模型、或者切换参数配置比如temperature从0.7调到0.2。这些变化表面上看只是换个引擎但没有哪个提示词是模型无关的。你精心设计的few-shot示例、对格式的强约束、对否定的强调方式都可能因为新模型的理解方式不同而失效。第二类是输入分布漂移。用户的输入不是一成不变的今天可能全是短问题明天涌进来一批长文档后天又混入多种语言。提示词中写死的上述问题可能因为输入格式改变而指代混乱你为处理短文本设计的截断逻辑也可能失效。这种漂移往往很隐蔽不会立刻让系统崩溃但会让整体输出质量缓慢下降直到积累到一定程度才爆发。第三类是业务规则的变更。业务方改了一个限价规则、加了一个新的产品线、调整了售后政策如果提示词里的业务上下文没有同步更新模型就会继续按照旧规则输出产生错误答案。这种问题在代码世界里叫配置漂移在提示词世界里同样存在而且因为提示词往往分散在多个系统里漏改的几率更大。我遇到过最尴尬的情况是业务方在周会上说要调整售后政策当场就改好了CRM系统的规则配置但完全没人想起提示词里还写着一句退货周期为7天。结果政策改了三天线上客服还在给用户说7天退货。这种问题靠人工检查几乎防不住必须有机制在提示词内容与预期行为不匹配时给出告警。1.3 为什么不能等到用户投诉了才发现问题可能有人会说线上效果下降用户投诉上来了我们自然会知道为什么非要搞监控告警这个想法我在前两年也有过后来用一次惨痛的教训换来了彻底转变。那是在一个内容生成类产品上我们有一组用于营销文案生成的提示词因为模型升级输出里的营销话术明显变得生硬。最开始只是个别用户反馈文案读起来很怪我们没当回事结果这个问题持续了近一周广告投放效果下滑了30%多业务方直接找到技术团队开了个紧急复盘会。事后想想如果当时有一套提示词监控体系哪怕只是最基础的输出质量抽检加告警这个问题完全可以在影响扩大之前就被发现。用户投诉是结果导向的被动信号它总是滞后于问题发生而且你无法从投诉反推出是哪条提示词、哪个参数、哪个环节出了问题。监控告警的意义在于把被动变成主动用系统化的方式持续观察提示词的运行状态在问题影响还没有扩大时就发出告警给团队争取处理的时间窗口。2. 提示词质量监控的核心指标2.1 效果指标输出质量到底怎么样提示词监控首先看的就是输出质量这个指标。它最直接也最容易理解——提示词的存在是为了让模型产出符合预期的结果输出质量就是衡量这个结果好坏的尺子。但在实际落地时质量到底怎么定义和量化往往是很多人卡住的地方。我在实际项目中一般会把输出质量拆成两层客观层和主观层。客观层有明确的判断标准比如回答是否包含核心答案、格式是否符合要求、内容是否包含禁用说法主观层则需要依靠人工或一个独立的评价模型来判断比如回复有没有站在用户角度语气是否亲和有没有充分解释原因。客观层指标的构建很容易比如在客服场景里我们可以统计回答中是否包含订单号、是否给出退换货方案、是否出现我不知道这类推诿话术。这些是可以用程序直接判断的。主观层指标则需要一个法官我的做法是让一个独立的模型实例充当评判者按照预设的评分标准给输出打分然后对这个分数做聚合统计。这里有个非常关键的细节如果你已经写了监控用的提示词一定不要用生产环境同款模型来评分。我在某个金融场景的监控里吃过这个亏生产模型和监控模型都用同一个版本结果监控评分一直虚高直到某次灰度切了新版本才暴露出来。建议评分模型选用独立版本、甚至是参数量更大更稳定的版本哪怕成本高一点也值得。2.2 稳定性指标不被创造性带偏大语言模型的一个重要特点是同一段提示词输入同样的内容输出却不完全相同。适当的随机性在某些场景下是优点但在很多业务场景里却是灾难。客服回答如果每次都换一种措辞、换一个方案用户会觉得不专业金融合规问答如果把数字或政策条款说错了那更是严重事故。所以稳定性是我在提示词监控里第二关注的指标它包含两个维度一个是形式层面的一致性指的是多次调用输出的结构、格式、关键字段是否稳定另一个是语义层面的一致性指的是输出的观点、结论、核心信息是否保持一致。实操中最常见做法是同一提示词同一输入重复运行多轮然后对比输出的差异度。比如在客服场景里拿10个典型问题分别跑5次每次输出的内容如果有30%以上的关键字段出现了不一致这个提示词的稳定性就得打问号了。具体指标可以用文本相似度、字段级一致性来衡量。但我必须提醒一点稳定性监控和效果监控不是一回事而且有时候它们会互相打架。你会发现一个稳定性很高的提示词输出效果可能反而一般——因为它过于死板模板化太强没有根据用户的具体情况灵活调整。反过来一个效果优秀的提示词往往有一定的灵活性稳定性指标会稍微差一点。做监控的时候一定要结合业务场景来权衡这两个指标而不是机械地追求全部满分。2.3 性能成本指标提示词也会花钱提示词监控还有一个容易被忽视的维度就是性能和成本。很多人觉得提示词就是几行文字模型调用成本可以忽略不计这在使用量小的阶段确实没问题。但一旦业务量上来——比如一个客服系统每天调用量达到百万次级别提示词的长度每增加100个token一天下来的成本可能就多出几千块这个账必须算。我在构建监控体系时会把性能成本指标分成三类延迟指标、Token消耗指标、成本趋势指标。延迟指标关注从发起请求到收到完整响应的时间这个直接决定用户体验Token消耗指标关注输入输出token的数量变化一旦发现平均输出token暴涨很可能是模型进入了话痨模式在回答里堆砌了大量废话成本趋势指标则是把这些token消耗换算成钱观察日/周维度的成本走向。这里有个实际的例子。我们有一个匹配类项目早期提示词设计得非常啰嗦几百字的背景说明加上好几组few-shot示例单次调用就要消耗接近三千个token。当时觉得反正模型很聪明多给点上下文效果更好结果到了月底对账才发现光这一个项目就吃掉了当月模型预算的一多半。后来我们把提示词精简掉四成左右的长度成本降下来了效果反而没有明显变化。这并不代表提示词越短越好但它确实提醒我们长度、复杂度和效果之间需要找到一个平衡点。监控成本指标的价值在于让这种平衡变得可观测、可优化而不是靠感觉走。2.4 汇总监控指标清单参考说了这么多我把几个核心指标做成一个清单可以作为大家搭建监控体系的参考起点指标类别具体指标衡量方式典型告警阈值效果指标任务成功率客观规则模型评分低于90%持续5分钟效果指标输出质量评分独立模型评分聚合低于3.5分5分制稳定性指标字段级一致性重复调用对比低于80%稳定性指标格式合规率结构校验低于95%性能指标平均延迟服务端统计高于P95基线50%性能指标Token消耗日志聚合日环比上升30%上面这些阈值是我个人在实践中常用的初始值并非标准答案。如果你的业务是合规问答稳定性指标阈值要定得极高如果业务本身是创意文案生成那稳定性的定义甚至可以完全改成多样性指标方向是反的。3. 告警体系怎么搭3.1 先想清楚告警给谁看、解决什么问题在我接触过的一些团队里一提告警就想着把监控指标接到群里指标一掉就全员轰炸。结果往往是第一天大家很紧张第二天已经开始麻木到第三天直接把这个群设置成免打扰——告警形同虚设。我认为告警体系搭建的第一步不是买工具、配规则而是想清楚三个问题告警给谁看解决什么问题什么情况下必须立刻打扰人什么情况下只需要记录在案我的划分方式是分级别管理。P0级别的告警意味着业务正在遭受实质性影响比如任务成功率暴跌、关键输出出现违规内容这类告警必须立刻通过即时通讯工具加短信的双重渠道推送收件人是负责该提示词的技术负责人和相关业务负责人。P1级别的告警表示质量出现明显滑坡但影响面还在可控范围内比如质量评分连续低水平运行、延迟明显上升这类只需要发到工作群相关人看到后自行认领处理。P2级别属于预警类信息比如成本趋势上升、稳定性指标慢速下滑这些每天汇总一条即可不需要实时打扰。不要觉得告警越灵敏越好就一定是对的。有一次我们配置了一个过于敏感的告警——质量评分稍微波动一下就触发结果一天发了上百条告警最后没人看了真正严重的P0告警反而被淹没在里面。那次之后我彻底反思了告警策略宁可漏报也不能滥报尤其是低级别告警必须严格控制数量。3.2 告警阈值怎么定基线优先静态阈值为辅告警阈值的设计是提示词监控里最考验经验的部分。阈值定得太宽松问题已经严重了才报警定得太严格又天天狼来了。我总结出的经验是先建立基线再设置静态阈值两者结合使用。基线的建立需要积累数据。新上线的提示词不要立刻挂上严格的监控告警而是先设置一个观察期用一到两周的时间收集正常的运行数据包括效果评分、延迟、token消耗、稳定性指标的分布情况。观察期结束后给这些数据算一个统计分布我一般用P50和P95两个百分位以此作为动态基线的参考。之后凡是偏离基线的波动才有资格触发告警。静态阈值则服务于极端异常场景。比如输出的合规内容违规率无论业务怎么变、基线怎么漂移超过一定比例就是不能接受的事故再比如任务成功率低于某个值意味着系统基本就没在正常干活了。这类指标不适合做动态基线必须用硬阈值去卡。两种阈值分别扮演不同的角色动态基线关注和平时不一样了适合发现缓慢漂移和轻微退化静态阈值关注突破绝对红线了适合快速锁定极端事故。在生产环境里我会把这两类规则同时挂在监控系统上任何一类触发都会进入告警流程。3.3 告警内容长什么样信息要完整、可执行很多初做监控的团队容易忽略一个细节告警消息本身的内容质量。如果告警只有一句提示词质量评分下降收到的人第一反应必然是然后呢我该看哪里这样的告警基本没有提供任何可执行的信息。一个好的告警消息至少应该包含以下要素出现问题的是哪条提示词提示词ID和名称、具体是哪个指标异常了指标名和当前值、基线值、变化幅度、问题从什么时候开始的开始时间和持续时间、可能的影响范围受影响的数据量、调用量、以及一个可以开始排查的入口相关日志链接或Dashboard入口。我常用的告警模板大概是这样的消息标题是【P0】提示词ORDER-003异常任务成功率降至72%正文列出最近5分钟成功率72%基线95%已持续8分钟受影响请求约1200次最近异常请求采样链接xxx。这样的信息发到群里任何一个人不需要再问为什么找我直接点开链接就能开始定位问题。我特别强调告警必须附上链路入口这一点因为在P0事故处理中时间就是一切。如果团队每个人都要先去翻日志系统、再找Dashboard、最后才能定位到具体是哪个提示词出了问题那这个告警机制本质上还是没有解决问题。优秀的告警应该是从消息到定位的一步到位。3.4 告警风暴的治理聚合、去重、静默告警体系上线一段时间后几乎必然会遇到告警风暴。所谓的告警风暴指的是短时间内涌入大量重复或关联的告警把相关负责人的通知渠道彻底淹没。造成告警风暴的原因通常有三个告警规则之间互相联动一个指标异常引发多个规则同时触发、网络抖动导致的瞬时数据波动、以及告警恢复后的反复抖动。治理告警风暴的手段我从实操角度总结了四个关键字聚合、去重、静默、升级。聚合是指把同一时间窗口内、同一告警源产生的多条信息合并成一条。去重是指针对完全相同的告警内容只保留最早的一条后续重复触发不再推送。静默是指对已知的、正在处理中的告警设置一个静默期避免同一个问题反复打扰。升级是指如果一个问题超过设定时间仍未恢复告警级别自动上调比如从P2升到P1再到P0确保问题不会被淹没在静默里。这四个手段的应用顺序也有讲究。一般是在告警触发时先去重、再聚合然后根据处理状态判断是否需要静默最后用升级来兜底。我见过一些团队只做了静默结果把P0级别的告警也静默了直接导致重大故障无人处理——这个坑千万要避免。4. 实操搭一套提示词质量监控告警系统4.1 整体架构和核心组件前面聊完了思路该进入实操环节。我在这里分享的方案不依赖任何特定的商业产品用常见的开源组件加脚本就能搭建起来适合中小团队快速落地。整体架构分四层。第一层是数据采集层负责从应用服务里收集提示词调用日志、输入输出内容、token消耗、延迟等原始数据。第二层是评估计算层负责根据预先定义的规则和模型评分把原始日志转换成质量指标。第三层是告警判定层负责把指标数据和告警规则做比对判断是否需要触发告警。第四层是通知触达层负责把告警消息推送到相应的通知渠道。在技术选型上数据采集可以用服务端的结构化日志JSON格式统一写到日志中心评估计算可以用定时任务或消息队列驱动的worker来处理告警判定和通知可以采用现成的监控告警框架只要它能支持查询指标、配置规则、发送告警就可以了。我不在这里指定具体工具名是因为不同团队的技术栈差异很大选型最重要的是能和你现有的日志、监控体系打通而不是追求某个特定的网红方案。4.2 关键实现一输出质量评估器输出质量评估器是整个监控体系的大脑。它负责回答一个核心问题这条提示词产生的输出到底算好还是不好我在这里给出一个可以落地的实施方案。先定义输出质量评分的维度以客服场景为例我通常用5个维度相关性回答是否切题、完整性是否覆盖用户问题的所有要点、规范性格式、术语、政策引用是否合规、安全性是否包含敏感或不当内容、友好度语气是否自然、亲和。每个维度1到5分总分取平均值。然后写评估代码这里的关键是用一个独立的模型实例来当裁判。评估模型的提示词也是需要仔细设计的我会要求它仅仅依据回答内容进行评分忽略历史对话中未涉及的假设信息避免因内容长短产生偏好。这一步不能省评估提示词如果不严谨监控结果就会出现系统性偏差。# 输出质量评估器示例 import json from llm_client import invoke_llm # 评估模型的系统提示词 EVALUATOR_SYSTEM 你是一个严格的文本质量评估器。请根据以下评分标准对给定的回答进行打分 1. 相关性是否直接回应了用户的问题 2. 完整性是否覆盖了问题涉及的核心要点 3. 规范性是否符合业务政策与格式要求 4. 安全性是否包含任何不当或敏感内容 5. 友好度语气是否自然、专业、亲和 每个维度打分1-5分。仅输出JSON格式的评分结果。 def evaluate_output(question: str, answer: str, policy_text: str) - dict: judge_prompt f 请评估以下对话中助手的回答质量。 用户问题{question} 助手回答{answer} 业务政策摘要{policy_text} 请按5个维度分别打分并给出总分。 response invoke_llm( promptjudge_prompt, systemEVALUATOR_SYSTEM, modeljudge-model-v1, # 使用独立的裁判模型 temperature0.2 ) return json.loads(response)这段代码里最需要留意的是model参数必须指定为独立的裁判模型而不能直通生产用的模型实例。另外temperature我设成0.2是为了控制多次评估时评分相对稳定不至于同一条输出在不同批次被打出差距过大的分数。4.3 关键实现二告警规则的配置有了质量评分数据之后告警规则就是最后一公里。这一部分最忌讳的是一上来就搞一套特别复杂的规则引擎我建议从最简单的三到五条规则开始跑跑顺了再逐步增加。告警规则配置的核心是三要素监控对象、判定逻辑、通知策略。监控对象是指要对哪条或哪一类提示词进行监控建议按业务模块来分组而不是逐条提示词单独配规则否则规则数量会爆炸。判定逻辑就是前面说的阈值与基线可以有静态阈值和动态基线两种。通知策略则是触发后的推送动作包括发给谁、用什么渠道、是否升级。举个例子假设我们要为订单售后场景的提示词配置一条质量评分过低的告警规则核心配置大概是下面这样的# 告警规则配置示例 alert_rules: - name: order_aftersales_quality_drop # 监控对象按标签选择 target: prompt_group: order_aftersales environment: production # 判定逻辑 condition: metric: quality_score operator: lt threshold: 3.5 for: 5m # 通知策略 notify: level: P1 channels: [im_group, email] on_recovery: true这里有几个容易踩坑的细节。第一个是for: 5m这个参数让告警规则必须连续满足5分钟才会触发能有效过滤掉瞬时抖动造成的数据波动。第二个是on_recovery: true在问题恢复后发一条恢复通知这样处理人才能明确知道问题已经解决了。这两点我在最初做监控时都没有加结果要么被瞬时波动搞得焦头烂额要么问题修复了但没人确认已经恢复导致后续排查花了大量时间。4.4 关键实现三SLO和服务水位监控除了针对单条提示词的细粒度告警我更建议在系统层面建立SLO监控从整体上把握全部提示词的运行水位。SLO维度的监控和告警不关注具体某条提示词而是看整套系统的综合表现比如整体任务成功率不低于98%平均质量评分不低于4.0。这样设计的好处是即使某条提示词的告警规则没有覆盖到只要整体水位异常SLO监测也能把它兜住。SLO的监控数据来自对全部提示词指标的上卷聚合它的判断规则不需要非常精细但必须有全局意识。比如深夜里系统自动跑批任务如果整体质量评分连续30分钟低于SLO阈值就直接升级到P0——先把影响止血再去定位细节。这一点我也和很多做监控的同行交流过大家普遍有一个共识SLO是告警体系的最后一道防线粒度可以粗但不能没有。只有点状告警而没有面状兜底总有覆盖不到的角落会成为事故发酵的温床。4.5 落地过程中的三项硬性要求最后在实操落地方面我整理了三项觉得必须有的硬性要求分享给大家参考。第一必须做线上流量的真实采样而不是只依赖离线评测集。我在早期搭监控的时候犯过一个错误用精心构造的测试集来评估提示词质量测试集上指标一直很漂亮但线上效果却一塌糊涂。后来才意识到离线测试集覆盖不了线上的复杂输入分布必须从生产流量里按比例采样来做质量评估比如每100次调用抽取1次进行评估这样才能真实反映线上情况。第二采样数据必须保留上下文链。评估一条提示词输出质量时只拿当前回答来打分是不够的因为模型可能是在错误理解上文的情况下给出了这个回答。我建议在采样时把对话历史、抽取的上下文片段一起记录下来评估时一并给裁判模型参考这样评分才会准确。第三监控系统的数据要有保留周期。原始采样日志和评分数据至少要保留30天以上因为你需要足够的周期来对比上周同比、上上周围比的数据趋势。有的团队为了省存储成本只保留几天数据结果要分析一个近一个月质量怎么在缓慢下降的问题时数据根本不够用只能从零开始积累。5. 实战中遇到的那些坑5.1 问题一告警风暴如何压制我们从搭建监控的第一天起就遇到告警风暴问题。原因很简单最初我把告警阈值定得非常紧每条提示词都配置了十几条规则一旦模型输出稍有波动几十条告警同时轰炸到群里。当时最夸张的一段经历是一个周末下午群里的告警消息超过了三百条。后来我的调整思路是三个层次的减法。第一层是合并同源告警同一时间窗口内、同一提示词组下的多种异常只在群里发一条汇总消息不逐条发。第二层是增加触发条件把瞬时触发改成连续持续N分钟才触发过滤掉大量的抖动。第三层是分级降噪把低级别告警改成每日汇总推送只在工作时段发不在深夜打扰。经过这几轮调整告警消息量降到了原来的十分之一左右而真正的问题一个都没有漏掉。我最大的体会是告警体系的成熟度不在于能多快发出告警而在于能多精准地发出有意义的告警。5.2 问题二模型升级导致的大规模质量下降模型升级是提示词监控里最让人头疼的事件之一。有一次我们监控到一条重要的客服提示词质量评分突然从4.6降到了3.2我立刻翻看监控面板发现超过40%的提示词评分都出现了明显下降。几乎瞬间就意识到不是我们改了什么东西是模型变了。处理这类问题的经验分几步。第一步是确认通过对比模型版本号的变化时间点和指标下降的时间点确认为什么原因。第二步是止血如果降级影响到了核心业务立刻把模型版本回滚到上一稳定版本。第三步是评估组织团队对受影响的所有提示词做一次批量评测找出哪些提示词在新模型下表现变差、哪些变好。第四步是适配针对变差的提示词调整措辞、示例和约束重新上线。这个过程中的关键认知是提示词工程不是写一次一劳永逸而是一个持续适配的过程。提示词跟不跟得上模型版本的演进决定业务效果是稳中向好还是跌宕起伏。监控告警体系能够帮你第一时间发现变化而不是等用户反馈才后知后觉。5.3 问题三线上与离线评估结果不一致前面我提到过不要只依赖离线测试集。我实际遇到的线上指标和离线指标相差很大的情况远比想象中频繁。有一组提示词在离线测试集上的成功率高达98%但线上真实评估却发现只有82%差距非常明显。排查之后发现问题出在提示词对输入格式的隐式假设上。离线测试集中的输入都是经过格式清洗的而线上真实用户的输入五花八门有时候一句话里带着错别字、口语化表达、甚至中英混排。我们的提示词里写了很多类似根据以下订单信息的表述但线上真正传过来的输入格式并没有那么规整导致模型对不上号。解决这个问题的思路是离线评测集必须持续从线上采样中扩充。我的做法是每周从线上流量中随机抽取一批真实的输入请求经过脱敏处理后补充到评测集里。这样评测集逐渐逼近真实的输入分布离线与线上指标的差距也会越拉越小。5.4 问题四告警失灵的时刻我要分享最后一个问题也是我这几年最心有余悸的一类问题——告警失灵。有一段时间我们的监控系统一切正常各项指标都在告警阈值之上群里安安静静。结果有一天业务方来反馈说机器人态度有点冷漠我们查了半天才发现罪魁祸首是生产环境配置的temperature参数被人误改成了0.9模型输出变得又随机又生硬。这件事里我们的监控指标确实没有抓到异常——因为态度冷漠是主观感受而我们当时的监控指标里根本没有语气温度这一类主观维度的评估。按理说那段时间整体质量评分应该也会下降但因为评分聚合了多个维度别的维度略微偏高把冷淡这个维度的问题掩盖了。这件事给了我非常深刻的教训。所以我现在养成了一个习惯就是在告警规则之外还会给每条核心提示词加上版本哈希校验只要线上加载的提示词内容与登记版本不一致就直接触发P0告警。这个校验的成本几乎为零但对防止提示词被悄悄修改、效果悄悄变差这类问题极其有效。最后再说几句写到这里这篇关于提示词监控告警的实践总结也接近尾声了。坦白说如果要我用一句话概括这几年的核心体会那就是提示词工程在一开始拼的是调优能力到后面拼的其实是安全感能力——你有多大把握确保这些提示词在今天、明天、下个月都能稳定输出。监控告警体系就是在帮你建立这种安全感。如果你所在的团队正在做大模型应用提示词数量已经超过两位数或者这些提示词正在支撑核心业务那么我强烈建议你尽早开始搭建提示词监控告警体系。不需要一步到位可以先从每周人工抽检加一份简单的日志统计开始哪怕只是记录指标数据也比完全裸奔要好得多。等数据积累到一定程度再逐步把告警、SLO、自动评估补齐。最后再分享一个小技巧不管用哪种监控方案一定要给每条核心提示词打上清晰的版本号和应用场景标签。这样无论何时在监控面板上看到异常都能以最短的时间精确定位到具体的提示词再顺着日志链路一路排查。这个习惯看似不起眼但在真正的事故处理中它往往能帮你省下数小时的排查时间。希望这篇内容能给共处在这个领域的朋友们一点参考。也欢迎同行们在实践中继续补充和修正让提示词工程这个领域在我们共同的踩坑与迭代中越来越成熟。