AI 应用上线前怎么验：一套可复用的验收方法论

📖 摘要：上一篇立了标准——交付方靠不靠谱，看它的用例质量：用例是长出来的，不是写出来的。这篇从根上讲起：AI 应用是「模型 + harness」两层系统、用例是长出来的，再给出一套可复用的验收方法论——六个评估面 + 节点级取证 + 概率采样 + 用例冻结 + 归因三分 + 版本锚定，每个模块给做法、给实测证据、给踩过的坑。想认真验收但不知道从哪下手的，可以直接照做。

上一篇《AI 应用交付靠不靠谱，看它的用例质量》立了一个判断标准。这篇回答随之而来的问题——就算对方把用例交出来，你（或者你自己作为交付方）到底怎么验？验什么、怎么算过、怎么防止「验了等于没验」？

先说一个常见误区：认真验收不是「多测几遍」，而是「换一套方法」。我跑了多个批次的 AI 应用验收，把这套方法从根上理了一遍——先讲为什么这么验，再拆七个实操模块，每个都踩过坑。

先看这套方法的全流程：

一、验证的根：AI 应用是两层系统

先讲为什么这套方法长这样——因为 AI 应用是两层系统，不是一层。

第一层是模型：大语言模型本身，负责「理解问题、生成回答」。第二层是 harness（工程框架，环绕模型的那套系统）：提示词怎么组织、检索怎么召回、工具怎么调用、上下文怎么管理、输出怎么处理、错误怎么降级、过程怎么观测——模型之外的一切工程都算。

这两层的缺陷长得完全不一样：

客户报问题，第一反应常是「这是模型的问题」——这是 AI 应用交付里最普遍的误解。我们多批次验收的实证恰恰相反：检索召回不全、降级链断裂、静默失败、访问控制形同虚设、脱敏失效……大多数真实缺陷在 harness 层，而且流程照常成功、不抛异常，黑盒点测永远发现不了。

这个根决定了后面每个模块的设计——下面七个模块，每一个都会回到这个根：六个评估面，评估的是 harness 的六个方面；节点级取证，查的是 harness 各层的中间状态；概率采样，对付的是模型层的随机性；归因三分，先分清问题出在哪一层。这套方法不是技巧堆砌，是从「两层系统」推导出来的——底子还是软件测试那套用例与缺陷方法论，只是针对 AI 应用的概率性和双层结构做了改造；在我们自己的交付流程里，它是收尾的那道闸。

二、用例从哪来：长出来的，不是设计出来的

这套方法的用例，不是设计出来的，是长出来的。

开工前对齐的「什么算成功」是种子，一套用例设计方法（六个评估面、路径覆盖、T1-T7 模式库）是土壤，真实环境里遇到过什么问题，用例就长出什么：每次跑通、每个真实缺陷、每个意外形态，都长进用例集。我们独立验收的用例，就是站在交付方用例（已在它的实践中长过一轮）之上，吸取它长成的样子，再按评估面补全边界——覆盖的不是凭空设计出来的场景，是交付方实践过的场景，加上我们补的边界。拿不到交付方用例时，就从应用结构逆向设计（读拓扑、契约预检、路径枚举）——生长的路径一样：补边界、补契约、回执行检验。

土壤凭什么给种子养分？三个机制：

• 缺陷模式库：真实缺陷形态沉淀成清单（思考污染、检索召回不全、降级链断裂、静默失败、访问控制形同虚设、脱敏失效……），设计用例从「想测什么」变成「这类缺陷怎么测」——按已知缺陷形态反推，覆盖不靠灵感，靠清单；
• 生长规则：每个用例有完整契约（输入/预期/判定词/断言/取证方式），六要素齐了才算一个用例——保证长出来的用例可执行、可断言、可取证；
• 沉淀闭环：每批验收结束，新缺陷形态、新坑自动回填进模式库与方法论——土壤越用越肥，下一批直接用更新后的土壤。

用例生成的速度和质量，靠 AI 工具做技术保障：用例草稿由 AI 基于应用结构和缺陷模式库自动起草，人审校确认；执行器从用例集数据驱动生成（不手写，执行前一致性校验——我们栽过：手写执行器与用例集产生过 26 条断言差异）；执行、取证、概率采样由 AI 跑；FAIL 后 AI 先归因初筛，人复核定性；每批结束 AI 自动沉淀回填。人机分工一句话：AI 提供速度，人提供判断——快是 AI 给的（起草、执行、沉淀全自动化），对是人守的（审校、定性、收录）。要说明白的是：AI 生成的是草稿，不是最终用例——最终用例经人审校、确认、冻结成基线后才生效（见第六节「用例冻结」）。

用例是认识，也要回到执行里被检验：归因三分会把用例缺陷也抓出来——我们有一批 77 条基线用例，18 条失败里 14 条是用例本身设计错了（输入枚举没用对、判定词写得太严、断言字段名对不上）。用例长歪了，修用例，不是修应用。这就是实践论：用例在实践中长出来，也在实践中被检验。

三、六个评估面：先回答「验什么」

AI 应用验收不是「测功能点」，是评估能不能上线。六个评估面，本质是 harness 的六个风险面——模型层只有一个 LLM，真正复杂多变、值得逐项评估的，是模型之外那套系统。用大白话说：

一个教训：最容易漏的是「压力」和「异常」——因为主流程测通了很容易觉得「差不多了」。我们的用例设计强制要求这两个维度必须有量化用例（并发几条、故障怎么注入），否则不算设计完成。

四、节点级取证：结论必须有证据

这是整套方法的地基。AI 应用（以 Dify 工作流为例）每个节点都是一次函数：检索、分类、生成、推送……为什么查节点中间态？因为 harness 每一层（检索、上下文、工具、输出）都可能是缺陷藏身处，端到端输出把中间状态全掩盖了——这正是根里说的「不报错的系统行为错误」。验收不能只看最终回答，要看每个节点的中间输出。

为什么？因为我们实际抓到过一个应用：推送节点显示「已推送给审批人」，但工单节点状态是「已驳回待复核」——两个节点状态互相矛盾。只看最终回答永远发现不了。

所以我们的铁律是：没有 trace 的结论是猜测。每个结论必须带节点级中间态证据，PASS 也要存实际输出全文。

五、概率采样：AI 是概率系统，不能「点几下」

传统软件测三次都是对的，基本可以认为没问题。AI 应用不是——同一个输入，这次对下次可能错。模型层是概率缺陷的唯一来源：harness 层问题能稳定复现，模型层问题只能靠采样定性。

我们实测过：同一问题 3 次采样，污染回答出现 2 次；一个间歇性跑偏问题，概率约 50%，采样 10 次才确认修复曲线。所以：

• 一致性判定：同一问题至少 3 次采样，概率性出现 = 质量不稳定证据
• 性能/成本判定：多次采样取中位数，单次波动不判定
• 间歇性缺陷：采样到收敛（比如连续 10 次确认从 50% 降到 0%）才算修复

点几下「看着没问题」= 采样不足，结论是假阳性——全过，上线炸。

六、用例冻结：先定用例，再执行

验收最容易翻车的不是不会测，是「边测边改」：遇到 FAIL 就现场放宽用例，最后报告里全是「通过」。这属于 harness 的另一种缺陷——验收者自己漂移：验收流程本身也是 harness 的一部分，它一放宽，结论就不可信，和应用缺陷同样致命。

我们的做法是基线化：用例先完整输出，确认、冻结成基线，执行时不允许中途放宽。遇 FAIL 先记录、取证据，全部跑完统一归因。

为什么这么较真？因为执行器与用例必须逐字一致——「语义等价」的近似执行会产生漂移，跑完的结果根本说不清是应用的问题还是执行偏差。我们自己就栽过：手写执行器与用例集产生过 26 条断言差异，被追问「你是严格按照用例跑的吗」。之后所有批量验收强制执行器从用例集数据驱动生成，执行前做一致性校验。

七、归因三分：先分清「谁错了」，再动手修

执行完遇到 FAIL，第一反应不是修应用，是归因。归因三分是根的直接落地：先分清缺陷在模型层还是 harness 层还是验收环境——修错对象，是验收里最贵的浪费。失败到底是三类中的哪一类：

最典型的场景是修复后的重跑：应用缺陷修好了，错误路径的行为形态也变了（从流程失败变成返回明确的错误提示），重跑时按旧判定标准会大面积显示失败——这时候直接判「应用又坏了」就错了，归因后其实是「判定标准需要适配」的用例问题，应用行为已经符合修复目标。

反过来也一样危险：把用例缺陷当应用缺陷去修，是验收最常见的自欺——修了半天应用，其实用例是错的；或者更糟，把应用缺陷归因为用例问题，放过了真问题。归因三分就是防止这两种错误。

八、版本锚定：结论只对快照版本有效

AI 应用一直在变：工作流改一下、知识库更新一下、提示词调一下，旧结论就失效了。快照锚定的是 harness 的版本——工作流、提示词、知识库全是 harness 的组成部分，任何一层变了，结论就要重新验。所以每次验收生成「验证快照」：

• DSL 快照（应用完整定义，可重新导入）
• 提示词哈希（检测 prompt 漂移）
• 知识库指纹（文档清单哈希）

回归时重新生成快照比对：指纹相同 = 知识库没变，只回归工作流改动相关用例；指纹不同 = 知识库变了，检索类用例必须全回归。结论可复现、可追溯，不靠回忆。

九、结论三态：敢写「不通过」

验收结论只有三态：通过 / 有条件通过 / 不通过——回答的就是根的问题：这套 harness 能不能交给用户。每态都带依据和上线建议：模型层风险靠采样兜底，harness 层缺陷靠证据钉死。

• 通过：全部达标
• 有条件通过：存在一般缺陷，附修复计划后上线
• 不通过：存在阻断/严重缺陷（数据泄露、越权、核心功能不可用），必须修复后重新验收

付费客户花钱买的是「发现问题」，不是「听一句没问题」。我们出的结论从「通过」到「不通过」都有——报告该说什么说什么，这是独立验收的立身之本。

实测数据

收尾

这套方法的每一层都对应一个「反脆弱」设计：先从根上想清楚「为什么这么验」，六个评估面防「不知道测什么」，节点取证防「结论没证据」，概率采样防「点几下就下结论」，用例冻结防「边测边放水」，归因三分防「修错了对象」，版本锚定防「结论过期」，三态结论防「报告变装饰品」。

AI 应用的价值在模型，风险也在模型——但验收真正要盯住的，是模型之外那整套 harness。

用例在实践中长出来，也在实践中被检验——这是这套方法能一直用下去的原因。AI 应用的验收没有捷径，但有方法。方法比勤奋重要——这可能是做 AI 应用交付这半年，我学到最实在的一条。

相关文章：AI 应用交付靠不靠谱，看它的用例质量——用例是长出来的，不是写出来的（用例质量是验收的入口）｜AI 项目交付，为什么必须在您的环境里完成？——方法要经真实环境检验，才能成为适合您的方法（真实环境验证）

本文基于 Hermes Agent v0.20.5 + Dify 1.16.x 实测，配置命令在不同版本间可能变化，使用前请确认版本。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。