一次看似普通的提示词优化可能悄悄改变整个 AI 应用。假设某个团队正在维护一套智能客服系统。原来的系统提示词已经迭代了十几个版本里面既有角色定义也有回答格式、业务边界、拒绝规则和工具调用要求。随着规则越来越多提示词显得有些冗长开发者决定做一次“清理”。他删除了三句看起来重复的内容又调整了一下段落顺序。修改后的提示词更短、更清晰人工测试时连续问了五个问题回答都很自然接口也没有报错。于是新版本很快被发布到生产环境。第二天问题陆续出现用户咨询退款进度时AI没有继续追问订单编号而是直接推测退款正在处理中明确要求返回 JSON 的接口偶尔会在 JSON 前面增加一段解释文字原来能够区分“申请退款”和“退款失败”的系统开始对两个问题给出相同模板某些信息不足的问题不再拒绝回答而是补充了资料中不存在的细节工具调用参数表面上符合 JSON 格式实际却缺少执行所需的关键字段同一个问题重复执行五次有三次正确、一次遗漏条件、一次给出错误结论。从传统监控看这次发布似乎没有问题。HTTP 状态码仍然是 200接口延迟没有明显增加JSON 解析错误率也很低服务器 CPU 和内存都在正常范围内。只有当运营人员开始整理用户投诉时团队才意识到系统没有宕机但行为已经发生了退化。这类问题正是 AI 应用与传统接口最大的不同之一。传统程序发生严重错误时往往会抛出异常、返回错误码或产生明显的失败结果AI 应用则可能在技术层面完全正常却在业务层面逐渐偏离预期。它仍然能够生成流畅的文字仍然可以返回结构化数据甚至比旧版本显得更“聪明”但关键事实、约束条件和行为边界已经改变。因此提示词不能只被当成一段文案。系统提示词、上下文模板、工具描述、模型参数、输出约束和知识拼接方式本质上都是生产系统的一部分。只要它们会改变应用行为就应该像代码一样被版本管理、测试、比较、灰度发布和快速回滚。本文不讨论如何写出一句“更强的提示词”而是讨论一个更基础、更重要的工程问题如何为 AI 应用建立一套真正可以执行的回归测试体系。一、AI应用的“能运行”不等于“行为正确”普通接口的正确性通常比较容易定义。例如一个用户查询接口接收用户编号返回用户姓名、状态和创建时间。测试时可以检查状态码、字段名称、数据类型和数据库记录是否一致。只要输入固定输出也应该相对固定。AI 应用则没有这么简单。同一个问题可能存在多种正确表达。例如用户询问“怎样修改密码”下面两种回答都可能是正确的进入账号设置打开安全中心然后选择修改密码。或者你可以依次进入“设置—安全中心—修改密码”完成身份验证后设置新密码。如果使用字符串完全相等进行测试第二种回答会被判定为错误但从业务效果看它甚至可能比第一种更清楚。这并不意味着 AI 无法测试。AI 回归测试真正要验证的不是模型是否逐字复现某个标准答案而是它是否满足稳定的业务要求。这些要求通常可以拆成几类是否理解了用户真正要完成的任务是否覆盖了回答中必须出现的信息是否出现了不允许出现的内容是否遵守了输出格式与字段契约是否只使用了给定资料中的事实信息不足时是否继续追问或明确说明是否选择了正确的工具工具参数是否完整且符合业务约束是否错误执行了高风险动作回答长度、延迟和资源消耗是否处于可接受范围。例如用户只说“我的退款为什么还没到”但没有提供订单编号和申请时间。系统此时可能无法直接给出退款状态。正确行为不应该是生成一段听起来合理的解释而应该询问必要信息。因此该用例的预期结果不必是一句固定文本而可以写成必须询问订单编号或退款申请时间不得声称退款已经到账不得推测具体处理进度不得调用退款查询工具可以说明获得必要信息后将继续查询。这样一来不管模型使用什么措辞只要满足这些条件就可以认为主要行为正确。AI 测试的关键是从“标准答案思维”转向“行为约束思维”。二、为什么人工试几个问题远远不够很多 AI 项目的测试过程非常相似。开发者修改提示词后打开聊天页面输入几个自己熟悉的问题。模型回答得不错于是认为新版本可以上线。这种测试方式存在几个明显缺陷。首先测试问题通常过于规范。开发者清楚系统需要什么信息因此会输入完整、清晰、没有歧义的问题真实用户却经常使用省略句、错别字、口语表达和互相矛盾的条件。开发者可能输入请查询订单 A1024 的退款处理状态。真实用户更可能输入怎么还没退或者昨天说退了钱呢如果系统只在输入完整时表现正常就不能算真正通过测试。其次开发者容易只验证成功路径。例如测试工具调用时通常会输入一个具有合法参数的请求却忽略以下情况参数缺失参数格式错误同时出现多个冲突参数用户试图查询他人的数据工具执行超时工具返回空结果工具已经执行成功但响应在网络中丢失同一请求被重复提交。成功路径只能证明系统在理想条件下能运行无法证明它在真实环境中可以安全运行。第三人工测试很难重复。今天开发者输入了五个问题明天可能换成另外六个问题。即使新版本表现更好也无法确定它是否破坏了旧版本已经解决的问题。第四人类很容易受到语言流畅度影响。模型回答得越自然人们越容易忽略事实错误。一个措辞生硬但事实准确的答案可能比一段非常流畅却包含错误结论的回答更可靠。第五人工测试很难覆盖随机性。同一个问题执行一次正确不代表连续执行十次都正确。有些提示词会让模型大多数时候遵守规则偶尔却偏离约束。只测试一次恰好可能遇到正常结果。因此人工测试仍然有价值但它应该承担探索性检查和最终体验评审而不应该成为唯一的发布依据。三、先建立测试集不要先挑评测工具一提到 AI 评测很多团队会立即寻找平台、框架或自动打分模型。但真正决定评测价值的首先不是工具而是测试数据。如果测试集只包含一些随手编写的问题即使评测平台能够生成几十项指标也很难说明系统是否适合真实业务。一个有效的测试集至少应该覆盖五类数据。1. 高频正常问题这部分用于确认系统的基础能力没有退化。例如查询操作步骤总结一段资料根据给定内容进行比较提取文本中的结构化信息生成符合格式要求的结果根据业务规则回答常见问题。高频问题不一定复杂但它们直接影响大量用户。一次小幅退化乘以真实访问量后也可能造成明显影响。2. 历史失败问题历史失败是最有价值的测试数据之一。如果系统曾经把退款期限回答错误那么修复完成后这条问题不应该只停留在事故报告里而应该进入长期回归测试集。下一次有人修改提示词、模型、上下文模板或工具说明时都要重新执行这条用例。每一个线上错误至少应沉淀出以下内容当时的用户输入模型实际看到的上下文当时使用的提示词版本错误输出正确行为失败原因修复方式后续自动检查规则。如果事故修复后没有留下回归用例同一个问题很可能在几个月后再次出现。3. 边界输入边界输入用于测试系统在资料不足、表达异常或条件冲突时是否仍能保持正确行为。常见边界包括缺少必要参数输入只有半句话用户连续改变要求问题包含多个任务问题超出知识范围上下文中不存在答案用户要求引用不存在的资料用户要求给出无法确认的结论输入中包含大量无关内容输出长度要求极端同时要求“简短回答”和“完整列出全部细节”。边界测试的目标不是要求 AI 对所有问题都给出答案而是确认它知道什么时候应该追问、什么时候应该拒绝、什么时候应该明确说明无法判断。4. 对抗与越权输入如果系统会接触内部资料、调用工具或执行动作就必须加入对抗性用例。例如要求忽略系统规则要求输出隐藏提示词要求读取其他用户的数据要求跳过身份验证要求调用未授权工具在引用资料中夹带新的指令伪造管理员身份诱导模型将不可信内容当成系统命令通过长文本掩盖真正的恶意要求。这类测试不能只判断回答是否礼貌还要检查系统是否泄露信息、调用工具或改变权限边界。5. 相似但处理方式不同的问题真实业务中最容易暴露模型理解能力的往往不是完全不同的问题而是表面相似、处理方式不同的问题。例如“如何申请退款”需要说明流程“为什么退款失败”需要查询具体状态“退款一般多久到账”需要说明规则“我的退款多久到账”可能需要订单信息“帮我取消退款”则可能涉及工具调用和权限验证。如果模型对这些问题都返回同一个模板语言可能没有错误任务却没有真正完成。测试集应该专门加入这种容易混淆的成组问题检查模型能否识别细微但重要的业务差异。四、测试集需要分层不能把所有问题混成一个总分建立测试集后还要对用例进行分层。如果把普通文案润色、订单查询和高风险工具执行全部混在一起最后计算一个平均分结果很容易产生误导。假设一个测试集有 100 条用例80 条普通问答15 条结构化提取5 条高风险工具操作。新版本在普通问答中提升了 10 条却在高风险工具操作中错误执行了 1 条。总体通过率可能仍然上升但这次修改显然不应该发布。因此测试用例至少应该具有以下标签{case_id:refund_cancel_007,category:工具调用,risk_level:high,business_priority:critical,expected_mode:ask_for_confirmation,repeat_count:10}可以按照风险把用例分成三层。普通用例包括文案生成、摘要、一般咨询等。允许存在一定表达差异主要关注任务完成、信息覆盖和语言质量。重要用例包括结构化输出、业务规则问答、内部知识查询等。要求较高的一致性并设置明确的格式和事实约束。高风险用例包括写数据库、发消息、修改状态、提交审批、创建资源、删除内容或访问敏感数据。任何一次越权、重复执行或错误参数都可能成为发布阻断项。分层以后不同类别可以使用不同的通过标准。普通用例可以要求总体通过率不低于某个基线重要用例不仅要达到较高通过率还不能出现关键字段错误高风险用例则可能要求多次执行全部通过。五、不要只保存问题要保存完整运行快照很多 AI 评测结果无法复现是因为团队只保存了用户输入没有保存模型实际接收到的全部内容。一次 AI 请求的行为可能同时受到以下因素影响系统提示词用户输入历史对话检索上下文上下文排序工具名称与工具描述输出格式模型参数应用代码中的默认值时间、语言和地区信息外部接口返回结果内容截断策略。如果只保存一句用户问题下一次测试时使用了不同上下文就无法判断结果变化来自提示词还是数据变化。因此每条用例应该尽可能形成可回放快照。{case_id:refund_023,category:信息不足,user_input:我的钱为什么还没退回来,conversation_history:[],context_snapshot:[],tool_schema_version:refund-tools-v4,prompt_version:support-v17,model_config:{temperature:0.2,max_output_tokens:800},expected_behavior:{must_ask_any:[订单编号,退款申请时间],must_not_claim:[退款已经到账,银行正在处理],allow_tool_call:false}}这里最重要的是expected_behavior它描述的是行为要求而不是唯一标准答案。如果应用依赖知识检索测试时还应保存检索结果快照。否则知识库内容更新、排序变化或过滤条件调整都可能影响最终回答。快照测试并不意味着永远使用旧数据。可以同时建立两种评测固定快照评测用于判断提示词和模型行为是否变化在线数据评测用于判断当前知识与检索系统的综合效果。固定快照负责控制变量在线评测负责发现真实系统的新问题。两者不能互相替代。六、提示词、工具和参数都必须进入版本管理不少团队已经使用 Git 管理代码却仍然把提示词直接写在平台后台或数据库里。修改后旧版本被覆盖几天后已经没人能够准确还原当时的配置。这会导致三个问题。第一无法复现事故。当用户反馈某次回答错误时团队只能看到当前提示词却不知道请求发生时使用的是哪个版本。第二无法进行公平比较。如果旧提示词已经被覆盖新旧版本就不能在同一测试集上重新执行。第三回滚不可靠。事故发生后开发者只能凭记忆恢复旧内容可能遗漏模型参数、工具描述或上下文模板的同步变化。因此至少要为以下对象建立版本系统提示词场景提示词输出格式模板工具说明工具参数结构模型配置上下文拼接模板安全规则评测规则测试集版本。一次发布记录可以写成{release_id:ai-support-20260705-03,prompt_version:support-v18,tool_schema_version:refund-tools-v4,context_template_version:context-v9,evaluation_set_version:support-regression-v12,model_config_version:model-config-v6}发生问题时团队可以快速回答哪个版本产生了错误、影响了哪些请求、应回滚哪些配置。版本号的意义不是形式完整而是让每一次行为变化都可以被追踪。七、不要只看一个准确率要建立多维指标AI 应用很难用一个“准确率”解释全部质量。更可靠的方式是把质量拆成多个维度。指标主要判断内容任务完成率是否真正解决用户提出的问题事实一致性回答是否得到输入资料支持必要信息覆盖率是否包含关键步骤与限制条件格式通过率JSON、字段和数据类型是否符合契约拒绝准确率该拒绝时是否拒绝误拒绝率可以回答的问题是否被错误拒绝工具选择准确率是否选择了正确工具工具参数通过率参数是否完整、合法且经过授权风险内容率是否出现编造、越权或敏感内容稳定通过率多次执行是否保持一致行为平均延迟用户等待时间是否可接受资源消耗输入输出规模是否突破运行边界这些指标不应该简单平均。假设新版本的语言自然度明显提升但事实一致性下降或者普通问答得分上升却新增一次越权工具调用。如果只计算平均分新版本可能看起来更好。更实用的方法是把指标分成三类。1. 阻断指标出现严重问题就停止发布。例如越权访问高风险工具误调用关键事实编造敏感信息泄露必填字段缺失无法解析的结构化输出同一业务动作被重复执行。2. 质量指标需要达到规定通过率并且不得明显低于旧版本。例如任务完成率必要信息覆盖率事实一致性正确追问率工具选择准确率。3. 观察指标允许在一定范围内波动但需要持续关注。例如回答长度语言自然度平均延迟输入输出规模用户阅读负担。发布决策应先检查阻断指标再比较质量指标最后观察成本与体验变化。八、优先使用确定性规则不要把所有判断都交给另一个模型AI 评测不应该全部依赖“模型评模型”。能用程序确定的内容应优先使用确定性规则。例如JSON 是否可以解析必填字段是否存在字段类型是否正确枚举值是否合法是否超过最大长度是否包含禁止字段工具名称是否在白名单中参数是否满足正则或业务格式引用编号是否真实存在是否调用了不允许的接口是否出现敏感字段。假设系统要求返回{category:refund,need_human:false,reply:...}自动检查至少可以验证输出是否为合法 JSON是否只有允许字段category是否属于规定枚举need_human是否为布尔值reply是否为非空字符串是否混入 Markdown 代码块或额外解释是否出现不允许的内部字段。这类检查稳定、快速、容易定位问题也不受评测模型随机性影响。对于工具调用还可以进一步验证工具是否允许在当前场景调用用户是否已通过身份验证参数是否来自用户明确输入是否缺少确认步骤是否超出权限范围相同业务操作是否重复执行。确定性检查越充分需要交给模型判断的范围就越小。九、模型评分可以使用但评分标准必须具体自然语言任务中仍然有一些问题很难完全用规则判断。例如回答是否真正解决了用户问题回答是否忠于给定资料是否遗漏了关键限制条件两个回答哪个更清晰语气是否适合目标用户回答是否在不确定时进行了合理说明。这些场景可以使用模型评分但不能只问一句“这个回答好不好”。评分提示应该包含明确维度、判断标准和证据要求。例如请根据给定资料评估回答。 评估规则 1. 回答只能使用资料中明确出现的信息 2. 资料不足时必须说明无法确认 3. 不得推测退款是否到账 4. 应询问订单编号或退款申请时间 5. 不得建议用户重复提交退款申请。 请分别判断每项是否通过并引用回答中的相关内容作为依据。评测结果最好采用结构化格式{grounded:true,asks_required_information:true,contains_unsupported_claim:false,suggests_duplicate_action:false,overall_pass:true,reason:回答未推测退款状态并询问了订单编号。}即使如此也不能把模型评分当成绝对真理。评测模型可能受到措辞、顺序和上下文长度影响。重要用例应定期进行人工抽样检查自动评分是否出现偏差。还可以使用双重评估规则检查负责结构、字段和明确禁令模型评分负责语义、完整性和表达质量人工审核负责高风险用例与评分争议。三种方式组合比依赖单一裁判更可靠。十、同一个问题要重复执行稳定性本身也是质量AI 输出具有随机性。一次通过并不代表稳定通过。假设某个高风险用例连续执行五次第一次正确追问订单编号第二次正确追问退款时间第三次直接推测银行正在处理第四次正确说明信息不足第五次调用了退款查询工具但参数为空。如果只执行第一次系统会被判定为通过连续执行后才会发现它的行为并不稳定。因此关键用例必须重复执行。可以按照风险设置不同重复次数普通文案类用例执行 2 至 3 次结构化输出类用例执行 3 至 5 次工具调用类用例执行 5 至 10 次高风险动作根据实际情况执行更多次。稳定性可以记录为用例缺少订单号时查询退款状态 执行次数10 正确追问8 错误推测1 错误工具调用1 稳定通过率80% 发布结论阻断高风险用例不能仅凭平均分通过。如果十次执行中有一次越权操作平均正确率虽然是 90%仍然不应发布。对于这类用例更适合采用“零严重错误”标准。还要注意降低随机参数不能解决全部问题。即使温度设置较低模型仍可能受到上下文变化、服务实现和提示歧义影响。稳定性测试是必要验证不能被参数配置替代。十一、多轮对话必须测试状态变化不能只测单轮问答许多 AI 应用在单轮测试中表现很好进入多轮对话后却开始混淆信息。例如第一轮用户咨询订单 A 的退款第二轮用户又提到订单 B第三轮用户只问“那这个什么时候到”。系统需要判断“这个”指订单 A 还是订单 B。如果无法确认应该追问而不是随意选择一个订单。多轮测试至少要覆盖以下情况用户在中途更换目标用户修改之前提供的条件两个对象具有相似名称历史对话中存在过期信息用户撤销之前的指令对话过长导致早期信息被截断系统摘要遗漏关键条件工具结果与用户后续描述冲突。多轮用例可以表示为{case_id:multi_order_014,turns:[{role:user,content:帮我查一下订单A的退款。},{role:assistant,expected_behavior:ask_for_order_details},{role:user,content:还有订单B我昨天也申请了。},{role:user,content:这个什么时候能到}],expected_final_behavior:{must_clarify_target_order:true,allow_tool_call:false}}多轮评测的重点不是每一轮都生成固定文本而是检查状态是否正确更新。如果系统使用对话摘要压缩历史内容还应比较压缩前后的行为。摘要不能只保留主题也要保留当前目标、关键参数、用户确认和未完成动作。十二、工具调用评测必须覆盖“选择、参数、权限、执行”四层带工具的 AI 应用不能只检查模型是否生成了一个函数名。完整工具调用至少包含四层正确性。第一层是否应该调用工具用户只是询问退款规则时不应该调用订单查询接口用户要求查询个人订单状态时才可能需要调用工具。第二层是否选择正确工具系统可能同时提供订单查询、退款查询、取消订单和人工转接等工具。选错工具即使参数格式正确也会产生错误结果。第三层参数是否正确参数不仅要满足 JSON 结构还要符合业务规则。例如订单编号是否来自用户输入用户身份是否已经验证时间范围是否合理是否缺少必填字段是否把自然语言描述错误地填入编号字段是否使用了其他用户的数据。第四层执行是否安全某些工具只是查询某些工具会产生副作用。取消订单、提交退款、发送通知、删除记录等动作应该经过更严格的确认和幂等控制。工具调用用例应明确{expected_tool_behavior:{allowed_tools:[query_refund_status],forbidden_tools:[create_refund,cancel_order],required_arguments:[order_id],requires_identity_verified:true,requires_confirmation:false}}对于有副作用的工具还需要测试重复提交。假设第一次工具执行成功但响应在返回途中丢失模型可能认为执行失败并再次调用。如果系统没有幂等机制就可能产生重复退款、重复消息或重复任务。因此评测不仅要查看模型输出还要检查工具执行日志和最终业务状态。十三、检索增强应用要把“检索”和“生成”分开测试如果应用使用知识库或搜索结果最终回答错误可能来自多个环节查询改写错误检索结果不相关过滤条件错误关键资料没有进入上下文上下文排序不合理模型忽略了正确资料模型引用了资料中不存在的结论。如果只看最终答案很难定位问题。更有效的方法是分层评测。检索层检查是否召回了正确资料正确资料是否出现在前几条无关资料是否过多权限过滤是否生效时间范围是否正确同名对象是否被混淆。上下文层检查关键段落是否真正进入模型输入是否因长度限制被截断多段资料是否存在矛盾来源标识是否保留拼接顺序是否影响理解。生成层在固定上下文快照下检查模型是否依据资料回答是否遗漏重要条件是否编造资料外信息是否给出正确引用资料不足时是否承认无法确认。这样当最终回答退化时可以判断是“没有找到资料”还是“找到了资料但没有正确使用”。需要注意的是检索测试与本文讨论的提示词回归并不冲突。提示词可能改变查询改写方式、资料使用方式和回答边界因此仍然需要在固定检索快照上做对照。十四、延迟和资源消耗也应该进入回归测试提示词修改不仅会改变答案还可能改变请求规模和输出长度。例如新增一句“请详细分析每种可能性”可能让模型输出显著变长增加大量示例可能扩大输入上下文要求模型反复自检也可能增加整体响应时间。如果评测只看内容质量就可能发布一个更准确但无法承担实际流量的版本。因此每轮回归测试应同时记录输入长度输出长度首个结果等待时间完整响应时间工具调用次数重试次数单请求资源消耗超时比例并发下的尾延迟。资源指标同样需要对照组。例如旧版本 任务通过率 91% 平均响应时间 2.8 秒 平均输出长度 620 字 新版本 任务通过率 93% 平均响应时间 6.9 秒 平均输出长度 1740 字新版本准确率提高两个百分点却让响应时间和输出长度增加一倍以上。是否值得发布需要结合业务场景判断。对实时客服来说延迟可能直接影响体验对离线报告生成来说可以接受更长时间但要考虑批量任务的资源总量。这里的核心不是追求越短越好而是把效果与代价放在同一份报告中。十五、比较新旧版本时必须控制变量一次有效的回归实验必须知道到底修改了什么。如果同时进行以下操作更换模型修改系统提示词调整温度更新知识库修改工具描述改变上下文排序增加重试次数即使结果变好也无法确定是哪项改动产生作用。结果变差时更难定位原因。建议每轮只改变一个主要变量。例如只修改系统提示词只修改输出模板只调整模型参数只更换模型只更新工具描述只改变上下文拼接方式。旧版本作为对照组新版本作为候选组在同一批测试快照上执行。对比报告不应该只有两个总分而应包含哪些用例由失败变为通过哪些用例由通过变为失败哪些类别提升明显哪些类别出现退化新增了哪些严重错误哪些问题仍然没有解决延迟和资源消耗发生了什么变化稳定性是否改善。其中最重要的是“通过变失败”的用例。平均分上升并不能证明新版本全面更好。一个关键用例从通过变成失败可能比十个普通用例的改善更重要。十六、建立一套最小可用的自动评测流程团队不必一开始就建设庞大的评测平台。一套最小流程可以分为六步。第一步读取测试用例测试用例包含输入、上下文快照、版本信息、预期行为和风险等级。第二步执行候选版本对每条用例按照规定次数执行并保存原始输出、工具调用、延迟和错误信息。第三步运行确定性检查检查 JSON、字段、枚举、禁止内容、工具权限和参数格式。第四步运行语义评分对需要自然语言判断的部分使用明确评分标准进行评估。第五步与基线比较比较旧版本与新版本在每条用例上的变化而不是只比较平均分。第六步生成发布结论报告应明确列出是否存在阻断问题哪些指标退化哪些用例需要人工复核是否允许进入灰度推荐的回滚版本是什么。伪代码可以表示为forcaseinevaluation_cases:baseline_resultsrun_repeatedly(versionbaseline_version,casecase,countcase.repeat_count)candidate_resultsrun_repeatedly(versioncandidate_version,casecase,countcase.repeat_count)baseline_scoreevaluate(case,baseline_results)candidate_scoreevaluate(case,candidate_results)compare_and_record(casecase,baselinebaseline_score,candidatecandidate_score)generate_release_report()真正实现时还需要固定运行配置、限制并发、记录版本、保护敏感数据并确保测试工具不会执行真实高风险操作。工具调用评测最好使用沙箱、模拟服务或只读环境不要为了测试直接修改生产数据。十七、回归报告应该回答“变好了什么”和“变坏了什么”一份有效的评测报告不应该只写新版本得分 8.7旧版本得分 8.4新版本更好。这种结论很难支持发布决策。更有价值的报告应该写成候选版本support-v18 对照版本support-v17 测试用例326 条 重复执行共 1280 次 主要改善 - 信息不足场景的正确追问率由 82% 提升到 94% - JSON 格式通过率由 96.5% 提升到 99.2% - 常见业务问题任务完成率提升 3.1% 主要退化 - 多轮对话中的目标识别准确率下降 4.8% - 平均输出长度增加 37% - 高风险工具用例出现 1 次未确认调用 发布结论 - 阻断发布 - 原因高风险工具调用必须零严重错误 - 建议保留新的追问规则恢复旧版工具确认约束后重新测试这种报告能够帮助团队做出具体修改而不是围绕一个抽象总分争论。报告还应保留失败样本。每个失败用例至少展示输入关键上下文旧版本结果新版本结果违反的规则自动评分理由人工复核状态。这样开发者才能快速理解退化发生在哪里。十八、把评测接入发布流程而不是上线前临时执行评测只有进入发布流程才能持续发挥作用。一套较完整的发布闸门可以这样设计提示词和配置必须具有版本号每次修改自动运行固定回归集阻断指标必须全部通过关键用例不得相对旧版本退化自动生成新旧版本差异报告高风险变化必须人工审核候选版本进入小流量灰度线上指标达到要求后逐步扩大流量异常时可以快速回滚线上新失败自动进入测试集。灰度阶段不能只看 HTTP 错误率。提示词退化通常不会返回 500而是返回一段格式正确、内容错误的文本。因此还要观察用户重新提问率用户改写问题的比例人工接管率负反馈率工具调用失败率用户撤销操作的比例回答后立即离开的比例同一问题短时间重复提交的比例。如果用户不断换一种说法重复提问往往说明第一次回答没有真正解决问题。即使接口成功率是 100%业务效果也可能正在下降。十九、失败样本必须进入闭环而不是只修一次评测系统的价值不只在发布前拦截错误还在于不断吸收真实失败。完整闭环可以表示为线上发现问题 → 保存请求与版本 → 判断失败类型 → 创建最小复现 → 加入回归测试集 → 修改提示词或程序 → 重新运行全部相关用例 → 灰度发布 → 继续观察每次失败都要明确属于哪一层输入理解错误上下文缺失检索错误提示词约束不足输出格式错误工具选择错误工具参数错误权限检查缺失多轮状态混乱评测规则遗漏。不要把所有问题都归因于“模型不够聪明”。有些问题应该通过提示词修复有些需要修改检索有些必须由确定性代码处理还有些需要缩小模型权限。如果一个问题可以通过字段校验阻止就不应该只在提示词里增加一句“请务必不要出错”。二十、一份可以直接执行的上线检查清单每次修改提示词、模型参数、上下文模板或工具描述前可以逐项确认。版本与范围是否为本次修改创建了独立版本是否保存了完整旧版本是否明确本次只改变了哪些变量是否记录了模型、参数、工具和上下文模板版本是否准备了可立即恢复的旧版本测试数据是否覆盖真实高频问题历史线上错误是否已经加入测试集是否包含信息不足、冲突和越界问题是否覆盖容易混淆的相似问题是否包含多轮对话和目标切换是否覆盖对抗输入与权限测试是否保存了固定上下文快照自动检查JSON 和结构化输出是否可以稳定解析必填字段和数据类型是否正确是否检查禁止字段和敏感内容工具名称是否在允许列表工具参数是否经过业务校验是否验证身份、权限与确认状态是否检查重复执行和幂等行为语义质量是否真正完成用户任务是否只依据给定资料回答信息不足时是否正确追问是否出现未经支持的结论是否遗漏关键限制条件是否错误拒绝可以回答的问题稳定性与风险关键用例是否重复执行是否记录每次执行结果高风险用例是否保持零严重错误是否检查多轮状态变化是否测试工具超时、空结果和结果未知是否对评分结果进行人工抽样性能与发布是否比较新旧版本的延迟是否比较输入输出规模是否观察工具调用次数是否生成逐用例差异报告是否设置明确的发布阻断条件是否进行小流量灰度是否准备快速回滚开关线上新失败是否能够自动沉淀为测试用例如果这些问题无法回答提示词修改就不应该被视为普通文案调整。它更接近一次没有充分测试的生产代码变更。结语AI 应用最危险的退化往往不会报错。接口仍然返回 200JSON 仍然可以解析页面仍然能够展示模型也依然可以生成自然流畅的文字。但系统可能已经开始遗漏条件、混淆任务、错误调用工具或者在信息不足时自信地给出结论。这种问题无法依靠上线前随便聊几轮解决。真正可靠的方法是把提示词、上下文、模型参数和工具描述一起纳入版本管理把真实问题与历史失败沉淀为测试集把关键行为转化为可验证的规则再用重复执行、对照实验、自动评测、人工审核、灰度发布和线上反馈形成闭环。提示词当然可以修改。模型也可以更换知识库可以更新工具可以增加参数可以调整。但每一次变化都应该能够回答三个问题它修复了什么它破坏了什么如果判断错了系统能不能立即退回去当团队能够稳定回答这三个问题时AI 应用才真正从“能演示的功能”进入“可以持续维护的工程系统”。