独立验收发布于 2026-08-30

AI 应用交付靠不靠谱，看它的用例质量——用例是长出来的，不是写出来的

📖 摘要：AI 应用交付行业普遍「自测自证」，客户验收凭感觉——但 AI 应用是概率系统，幻觉编造、检索召回不全、多轮上下文丢失这类缺陷，点几下根本测不出来。本文立一个判断标准：交付方靠不靠谱，不看它敢不敢承诺，看它的用例质量——用例是长出来的，不是写出来的，用例里藏着交付方的实践史；独立验收是把用例质量亮出来的方式（只报告不修改、结论敢写不通过、证据可复现），并用多个批次独立验收的实战记录说明这个标准怎么做、为什么可信。

一、一个常见的交付现场

客户问：「应用做好了？」

交付方答：「我们测过了，没问题。」

客户打开页面，点了几下，觉得回答还行，签字确认。上线两周后：回答开始胡说、引用错文档、多轮对话丢上下文、报告生成卡在加载。客户找回去，交付方说：「这是模型的问题，我们也没办法。」

整个过程没人说谎，但结论是错的——错在「测过了」这个动作本身不成立。

判断交付方靠不靠谱，不用听他怎么说，看一件东西：他拿什么验——用例。

我做过软件测试，转做 AI 应用交付之后，越来越确认一件事：传统软件那套「测过了」的默契，在 AI 应用这里不适用了。

二、为什么 AI 应用「自测自证」天然不可信

三个原因，一个比一个麻烦。

第一，利益绑定。 交付方自己测自己，测出问题影响回款周期、影响交付口碑，报告天然倾向「过」。这跟考试时自己给自己阅卷一样，不是态度问题，是结构问题。

第二，AI 应用是概率系统。 同一个输入，这次对，下次可能错。我们实测过：同一问题 3 次采样，污染回答出现 2 次；间歇性跑偏 50% 概率，采样 10 次才确认修复曲线。客户点几下「看着没问题」= 采样不足，结论是假阳性——全过，上线炸。

第三，缺陷不报错。 AI 应用的典型缺陷根本不抛异常：幻觉编造（库外问题答出库内没有的信息）、检索召回不全（知识库里明明有数据，回答却是「未找到」）、多轮对话丢上下文、思考污染（回答里混入 <think> 推理块）。这些缺陷流程照常成功、状态照常显示完成，黑盒点测永远发现不了。

所以客户报问题时，交付方最常说「这是模型的问题」——但到底是模型不行还是系统不行，没人验证过。这个问题的答案，就是 AI 应用交付信任危机的根源。

三、靠谱的标准：看它的用例质量

判断一个 AI 应用交付方靠不靠谱，不用听他说什么，要一件东西：他的用例。

用例是交付方对「系统应该怎么验」的完整物化——需求把握得清不清楚、系统理解得深不深、实践中踩过多少坑，全写在用例里。敢不敢承诺是姿态，用例是实物，实物不会说谎。

怎么看用例质量？先看用例是怎么来的：

真正高质量的用例，是长出来的，不是设计出来的。 开工时对齐的「什么算成功」是种子，一套用例设计方法（评估面、路径覆盖）是土壤，真实环境里遇到过什么问题，用例就长出什么——每次跑通、每个真实缺陷、每个意外形态，都长进用例集。所以模板抄来的用例，每条都泛泛而谈（「验证基本功能」）；从实践里长出来的用例，带着真实场景、具体数据、真实边界（「供应商报价单第七种格式，字段串位」）。用例里，藏着交付方的实践史。

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

缺陷模式库：把真实缺陷形态沉淀成清单（思考污染、检索召回不全、降级链断裂、静默失败、访问控制形同虚设……），设计用例从「想测什么」变成「这类缺陷怎么测」；
生长规则：每个用例都有完整契约（输入、预期、判定、取证方式），保证长出来的用例可执行、可断言、可取证，不是写个「测一下」；
沉淀闭环：每批验收的坑自动回填进模式库，土壤越用越肥。

而且这一切由 AI 工具执行：用例草稿由 AI 基于应用结构和缺陷模式库自动起草，人审校确认；执行、取证、归因初筛、沉淀回填，都是 AI 在做——人负责判断，AI 负责速度。所以用例生成快，不是手快，是这套人机机制快。

那我们的验收用例是怎么长出来的？——长在交付方用例之上：

交付方在它的实践里长出了第一轮用例；独立验收时，我们把这份用例拿过来作为种子，吸取它长成的样子——它覆盖了哪些真实场景、踩过哪些坑，全在用例里。然后我们做三件事：按评估面补边界（它没覆盖的异常路径、概率行为、安全维度）、按六要素补契约（输入/预期/判定/取证逐条补齐，不让一条用例是「测一下」）、按缺陷模式库补形态（思考污染、检索召回不全这类真实缺陷怎么测）。生成的验收用例还要回到执行里被检验——归因三分会把用例自己的问题揪出来（我们有一批 77 条基线用例，18 条失败里 14 条是用例本身设计错了），修掉用例缺陷，才冻结成最终的 TR4 用例。

要说明白：这个链条的前提是交付方拿得出完整用例——拿不出时，我们从应用结构逆向设计（读 DSL 拓扑、契约预检、路径枚举），补边界、补契约、回执行检验的路径一样走完。

所以验收用例的生长链是：交付方实践中长出的用例 → 我们吸取 + 补充 → 执行检验 → 定型。覆盖的不是凭空设计的场景，是交付方实践过的场景加上我们补的边界——这就是为什么我们的验收能抓到真实缺陷：验收用例是站在交付方实践史之上长出来的，不是拍脑袋设计的。

那独立验收在这套标准里是什么位置？——它不是判断标准，是把用例质量亮出来的方式。三个底线：

1. 用例敢不敢拿出来给独立验收跑？ 独立验收 = 只报告、不修改：验收方拿着应用 Key 和只读权限进场，一个配置都不碰，验完凭据吊销。用例一跑，深浅立现；改了再测，报告就不再独立——这条线是独立性的生命线。

2. 报告敢不敢写「不通过」？ 验收结论只有三态：通过 / 有条件通过 / 不通过。敢如实写「不通过」的报告才有价值；永远「通过」的报告是装饰品。

3. 证据能不能复现？ 验收结论必须锚定版本：DSL 快照 + 提示词哈希 + 知识库指纹，结论只对快照版本有效。应用改过、知识库换过之后，旧结论自动失效，要回归重验。一句话——没有证据链的结论是猜测，没有版本锚定的结论是一次性的。

这三条做到，用例质量才被真正亮出来。缺任何一条，所谓的「验收」只是在走流程。

四、我们怎么做：多批次独立验收的实战

我们自己的独立验收服务，已经跑了多个批次——验的正是上面这套标准。说几个关键做法和真实结果。

节点级取证，不看表面。 Dify（开源 AI 应用编排平台）工作流里每个节点都是一次函数，端到端输出看不出问题，中间态交叉核对才能暴露。我们曾发现一个应用：推送节点显示「已推送给审批人」，但工单节点状态是「已驳回待复核」——两个节点状态互相矛盾，只看最终回答永远发现不了。「没有 trace 的结论是猜测」，是我们验收的第一条铁律。

基线化纪律，执行器与用例逐字一致。 用例先输出、确认、冻结成基线，执行时不允许中途放宽；执行器与用例逐字一致，遇 FAIL 不现场改，跑完统一归因三分：应用缺陷 / 用例缺陷 / 环境问题。

归因三分的价值，一次实测最有说服力。 有一批 77 条基线用例，严格执行后 59 条通过、18 条失败。统一归因后的结论出乎意料：18 条失败里，只有 4 条是应用真实缺陷，另外 14 条是用例本身设计错了——输入枚举没用对、判定词写得太严、断言的字段名对不上。这个结果证明了一件事：连验收用例自己都会错——用例是长出来的，也会长歪，所以用例本身也要被验收，这正是归因三分和基线化存在的意义。如果执行中现场放宽用例，这 14 个用例设计问题会被永久掩盖，下一批还会重犯。

结论三态如实写。 从「通过」到「不通过」，我们出过的验收结论都有，报告该说什么说什么。付费客户花钱买的是「发现问题」，不是「听一句没问题」。

双视角交叉验证。 同一批次，开发方视角（TR4 全流程）和独立视角（只报告不修改）各测一遍，两轮独立设计用例、独立执行，最后结论完全一致——两个视角互相印证，比单一视角可信。

五、拿到验收报告，看三处

上文说的是判断标准；如果你已经拿到一份验收报告，别只看结论页，翻三处：

看结论形态——报告结论是不是三态（通过 / 有条件通过 / 不通过）如实呈现？永远只出现「通过」的报告，信息量为零。
看证据在哪——结论背后有没有节点级中间态证据（哪一步、什么输出、哪里不对）？没有证据链的结论是猜测。
看版本锚定——报告有没有绑定应用和知识库的版本快照、能不能回归复验？一次性的结论，应用一改就作废。

另外，客户自己验收也别凭感觉点几下：AI 应用是概率系统，同样的输入这次对下次可能错，验收要的是足够次数的采样和可复现的证据，不是「看起来可以」。

六、收尾

AI 应用的靠谱，是一系列正确动作串联起来的：需求理解对不对、设计合不合理、实践走没走对、每一步验没验、经验沉没沉淀——验收只是其中重要的一环。但它是最容易被跳过的一环：前面的动作做得再对，少了一道「验」，风险就在上线后爆发。用例是实践长出来的，质量藏得住；独立验收把它亮出来——这一环补上，整条链才闭环。 它不性感，但它是信任的地基。

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

这套方法，如何应用到您的项目？看看方案与服务 →

本系列 · 独立验收