AI 应用上线前怎么验一套可复用的验收方法论AI 应用交付 · 独立篇 | 基于 Hermes Agent v0.20.5 Dify 1.16.x 实测2026-08deepseek 摘要上一篇立了标准——交付方靠不靠谱看它的用例质量用例是长出来的不是写出来的。这篇从根上讲起AI 应用是「模型 harness」两层系统、用例是长出来的再给出一套可复用的验收方法论——六个评估面 节点级取证 概率采样 用例冻结 归因三分 版本锚定每个模块给做法、给实测证据、给踩过的坑。想认真验收但不知道从哪下手的可以直接照做。上一篇《AI 应用交付靠不靠谱看它的用例质量》立了一个判断标准。这篇回答随之而来的问题——就算对方把用例交出来你或者你自己作为交付方到底怎么验验什么、怎么算过、怎么防止「验了等于没验」先说一个常见误区认真验收不是「多测几遍」而是「换一套方法」。我跑了多个批次的 AI 应用验收把这套方法从根上理了一遍——先讲为什么这么验再拆七个实操模块每个都踩过坑。先看这套方法的全流程用例设计读应用结构按模式库起草用例冻结确认基线不中途放宽执行取证节点级中间态概率采样归因三分应用缺陷 / 用例缺陷 / 环境问题验收报告结论三态快照锚定上线后回归指纹比对定回归范围一、验证的根AI 应用是两层系统先讲为什么这套方法长这样——因为 AI 应用是两层系统不是一层。第一层是模型大语言模型本身负责「理解问题、生成回答」。第二层是 harness工程框架环绕模型的那套系统提示词怎么组织、检索怎么召回、工具怎么调用、上下文怎么管理、输出怎么处理、错误怎么降级、过程怎么观测——模型之外的一切工程都算。这两层的缺陷长得完全不一样层缺陷形态例子模型层能力边界、幻觉库外问题编造答案、推理不足harness 层不报错的系统行为错误库有数据却答「未找到」检索没召回、多轮丢上下文、推送节点与工单状态矛盾、敏感信息未脱敏客户报问题第一反应常是「这是模型的问题」——这是 AI 应用交付里最普遍的误解。我们多批次验收的实证恰恰相反检索召回不全、降级链断裂、静默失败、访问控制形同虚设、脱敏失效……大多数真实缺陷在 harness 层而且流程照常成功、不抛异常黑盒点测永远发现不了。这个根决定了后面每个模块的设计——下面七个模块每一个都会回到这个根六个评估面评估的是 harness 的六个方面节点级取证查的是 harness 各层的中间状态概率采样对付的是模型层的随机性归因三分先分清问题出在哪一层。这套方法不是技巧堆砌是从「两层系统」推导出来的——底子还是软件测试那套用例与缺陷方法论只是针对 AI 应用的概率性和双层结构做了改造在我们自己的交付流程里它是收尾的那道闸。二、用例从哪来长出来的不是设计出来的这套方法的用例不是设计出来的是长出来的。开工前对齐的「什么算成功」是种子一套用例设计方法六个评估面、路径覆盖、T1-T7 模式库是土壤真实环境里遇到过什么问题用例就长出什么每次跑通、每个真实缺陷、每个意外形态都长进用例集。我们独立验收的用例就是站在交付方用例已在它的实践中长过一轮之上吸取它长成的样子再按评估面补全边界——覆盖的不是凭空设计出来的场景是交付方实践过的场景加上我们补的边界。拿不到交付方用例时就从应用结构逆向设计读拓扑、契约预检、路径枚举——生长的路径一样补边界、补契约、回执行检验。土壤凭什么给种子养分三个机制缺陷模式库真实缺陷形态沉淀成清单思考污染、检索召回不全、降级链断裂、静默失败、访问控制形同虚设、脱敏失效……设计用例从「想测什么」变成「这类缺陷怎么测」——按已知缺陷形态反推覆盖不靠灵感靠清单生长规则每个用例有完整契约输入/预期/判定词/断言/取证方式六要素齐了才算一个用例——保证长出来的用例可执行、可断言、可取证沉淀闭环每批验收结束新缺陷形态、新坑自动回填进模式库与方法论——土壤越用越肥下一批直接用更新后的土壤。用例生成的速度和质量靠 AI 工具做技术保障用例草稿由 AI 基于应用结构和缺陷模式库自动起草人审校确认执行器从用例集数据驱动生成不手写执行前一致性校验——我们栽过手写执行器与用例集产生过 26 条断言差异执行、取证、概率采样由 AI 跑FAIL 后 AI 先归因初筛人复核定性每批结束 AI 自动沉淀回填。人机分工一句话AI 提供速度人提供判断——快是 AI 给的起草、执行、沉淀全自动化对是人守的审校、定性、收录。要说明白的是AI 生成的是草稿不是最终用例——最终用例经人审校、确认、冻结成基线后才生效见第六节「用例冻结」。用例是认识也要回到执行里被检验归因三分会把用例缺陷也抓出来——我们有一批 77 条基线用例18 条失败里 14 条是用例本身设计错了输入枚举没用对、判定词写得太严、断言字段名对不上。用例长歪了修用例不是修应用。这就是实践论用例在实践中长出来也在实践中被检验。三、六个评估面先回答「验什么」AI 应用验收不是「测功能点」是评估能不能上线。六个评估面本质是 harness 的六个风险面——模型层只有一个 LLM真正复杂多变、值得逐项评估的是模型之外那套系统。用大白话说评估面看什么典型问题功能该办的事办不办得成主流程、分支、拒答场景逐条走通性能快不快、贵不贵响应时间、token 成本多次采样安全会不会泄密、被攻击越权访问、提示注入、敏感信息脱敏可靠性会不会乱说、前后不一致同一问题多次回答一致性、多轮对话稳定性压力扛不扛得住并发、重复提交异常出错了怎么办乱码/超长输入、上游故障时的降级表现一个教训最容易漏的是「压力」和「异常」——因为主流程测通了很容易觉得「差不多了」。我们的用例设计强制要求这两个维度必须有量化用例并发几条、故障怎么注入否则不算设计完成。四、节点级取证结论必须有证据这是整套方法的地基。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 层缺陷靠证据钉死。通过全部达标有条件通过存在一般缺陷附修复计划后上线不通过存在阻断/严重缺陷数据泄露、越权、核心功能不可用必须修复后重新验收付费客户花钱买的是「发现问题」不是「听一句没问题」。我们出的结论从「通过」到「不通过」都有——报告该说什么说什么这是独立验收的立身之本。实测数据批次结果23 应用批量验收真实缺陷 6 个含严重 3 个历史缺陷回归 5/5双视角交叉验证同一批次开发方视角 52/56、独立视角 45/45两轮结论完全一致真实客户应用H3C 故障诊断助手独立验收 16/16 全通过收尾这套方法的每一层都对应一个「反脆弱」设计先从根上想清楚「为什么这么验」六个评估面防「不知道测什么」节点取证防「结论没证据」概率采样防「点几下就下结论」用例冻结防「边测边放水」归因三分防「修错了对象」版本锚定防「结论过期」三态结论防「报告变装饰品」。AI 应用的价值在模型风险也在模型——但验收真正要盯住的是模型之外那整套 harness。用例在实践中长出来也在实践中被检验——这是这套方法能一直用下去的原因。AI 应用的验收没有捷径但有方法。方法比勤奋重要——这可能是做 AI 应用交付这一年多我学到最实在的一条。 你验收 AI 应用遇到过「边测边放水」或「修错对象」的情况吗评论区聊聊你的经历。 更多实战记录见我的博客鱼日先生本文基于 Hermes Agent v0.20.5 Dify 1.16.x 实测配置命令在不同版本间可能变化使用前请确认版本。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。
AI应用上线前怎么验-一套可复用的验收方法论
AI 应用上线前怎么验一套可复用的验收方法论AI 应用交付 · 独立篇 | 基于 Hermes Agent v0.20.5 Dify 1.16.x 实测2026-08deepseek 摘要上一篇立了标准——交付方靠不靠谱看它的用例质量用例是长出来的不是写出来的。这篇从根上讲起AI 应用是「模型 harness」两层系统、用例是长出来的再给出一套可复用的验收方法论——六个评估面 节点级取证 概率采样 用例冻结 归因三分 版本锚定每个模块给做法、给实测证据、给踩过的坑。想认真验收但不知道从哪下手的可以直接照做。上一篇《AI 应用交付靠不靠谱看它的用例质量》立了一个判断标准。这篇回答随之而来的问题——就算对方把用例交出来你或者你自己作为交付方到底怎么验验什么、怎么算过、怎么防止「验了等于没验」先说一个常见误区认真验收不是「多测几遍」而是「换一套方法」。我跑了多个批次的 AI 应用验收把这套方法从根上理了一遍——先讲为什么这么验再拆七个实操模块每个都踩过坑。先看这套方法的全流程用例设计读应用结构按模式库起草用例冻结确认基线不中途放宽执行取证节点级中间态概率采样归因三分应用缺陷 / 用例缺陷 / 环境问题验收报告结论三态快照锚定上线后回归指纹比对定回归范围一、验证的根AI 应用是两层系统先讲为什么这套方法长这样——因为 AI 应用是两层系统不是一层。第一层是模型大语言模型本身负责「理解问题、生成回答」。第二层是 harness工程框架环绕模型的那套系统提示词怎么组织、检索怎么召回、工具怎么调用、上下文怎么管理、输出怎么处理、错误怎么降级、过程怎么观测——模型之外的一切工程都算。这两层的缺陷长得完全不一样层缺陷形态例子模型层能力边界、幻觉库外问题编造答案、推理不足harness 层不报错的系统行为错误库有数据却答「未找到」检索没召回、多轮丢上下文、推送节点与工单状态矛盾、敏感信息未脱敏客户报问题第一反应常是「这是模型的问题」——这是 AI 应用交付里最普遍的误解。我们多批次验收的实证恰恰相反检索召回不全、降级链断裂、静默失败、访问控制形同虚设、脱敏失效……大多数真实缺陷在 harness 层而且流程照常成功、不抛异常黑盒点测永远发现不了。这个根决定了后面每个模块的设计——下面七个模块每一个都会回到这个根六个评估面评估的是 harness 的六个方面节点级取证查的是 harness 各层的中间状态概率采样对付的是模型层的随机性归因三分先分清问题出在哪一层。这套方法不是技巧堆砌是从「两层系统」推导出来的——底子还是软件测试那套用例与缺陷方法论只是针对 AI 应用的概率性和双层结构做了改造在我们自己的交付流程里它是收尾的那道闸。二、用例从哪来长出来的不是设计出来的这套方法的用例不是设计出来的是长出来的。开工前对齐的「什么算成功」是种子一套用例设计方法六个评估面、路径覆盖、T1-T7 模式库是土壤真实环境里遇到过什么问题用例就长出什么每次跑通、每个真实缺陷、每个意外形态都长进用例集。我们独立验收的用例就是站在交付方用例已在它的实践中长过一轮之上吸取它长成的样子再按评估面补全边界——覆盖的不是凭空设计出来的场景是交付方实践过的场景加上我们补的边界。拿不到交付方用例时就从应用结构逆向设计读拓扑、契约预检、路径枚举——生长的路径一样补边界、补契约、回执行检验。土壤凭什么给种子养分三个机制缺陷模式库真实缺陷形态沉淀成清单思考污染、检索召回不全、降级链断裂、静默失败、访问控制形同虚设、脱敏失效……设计用例从「想测什么」变成「这类缺陷怎么测」——按已知缺陷形态反推覆盖不靠灵感靠清单生长规则每个用例有完整契约输入/预期/判定词/断言/取证方式六要素齐了才算一个用例——保证长出来的用例可执行、可断言、可取证沉淀闭环每批验收结束新缺陷形态、新坑自动回填进模式库与方法论——土壤越用越肥下一批直接用更新后的土壤。用例生成的速度和质量靠 AI 工具做技术保障用例草稿由 AI 基于应用结构和缺陷模式库自动起草人审校确认执行器从用例集数据驱动生成不手写执行前一致性校验——我们栽过手写执行器与用例集产生过 26 条断言差异执行、取证、概率采样由 AI 跑FAIL 后 AI 先归因初筛人复核定性每批结束 AI 自动沉淀回填。人机分工一句话AI 提供速度人提供判断——快是 AI 给的起草、执行、沉淀全自动化对是人守的审校、定性、收录。要说明白的是AI 生成的是草稿不是最终用例——最终用例经人审校、确认、冻结成基线后才生效见第六节「用例冻结」。用例是认识也要回到执行里被检验归因三分会把用例缺陷也抓出来——我们有一批 77 条基线用例18 条失败里 14 条是用例本身设计错了输入枚举没用对、判定词写得太严、断言字段名对不上。用例长歪了修用例不是修应用。这就是实践论用例在实践中长出来也在实践中被检验。三、六个评估面先回答「验什么」AI 应用验收不是「测功能点」是评估能不能上线。六个评估面本质是 harness 的六个风险面——模型层只有一个 LLM真正复杂多变、值得逐项评估的是模型之外那套系统。用大白话说评估面看什么典型问题功能该办的事办不办得成主流程、分支、拒答场景逐条走通性能快不快、贵不贵响应时间、token 成本多次采样安全会不会泄密、被攻击越权访问、提示注入、敏感信息脱敏可靠性会不会乱说、前后不一致同一问题多次回答一致性、多轮对话稳定性压力扛不扛得住并发、重复提交异常出错了怎么办乱码/超长输入、上游故障时的降级表现一个教训最容易漏的是「压力」和「异常」——因为主流程测通了很容易觉得「差不多了」。我们的用例设计强制要求这两个维度必须有量化用例并发几条、故障怎么注入否则不算设计完成。四、节点级取证结论必须有证据这是整套方法的地基。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 层缺陷靠证据钉死。通过全部达标有条件通过存在一般缺陷附修复计划后上线不通过存在阻断/严重缺陷数据泄露、越权、核心功能不可用必须修复后重新验收付费客户花钱买的是「发现问题」不是「听一句没问题」。我们出的结论从「通过」到「不通过」都有——报告该说什么说什么这是独立验收的立身之本。实测数据批次结果23 应用批量验收真实缺陷 6 个含严重 3 个历史缺陷回归 5/5双视角交叉验证同一批次开发方视角 52/56、独立视角 45/45两轮结论完全一致真实客户应用H3C 故障诊断助手独立验收 16/16 全通过收尾这套方法的每一层都对应一个「反脆弱」设计先从根上想清楚「为什么这么验」六个评估面防「不知道测什么」节点取证防「结论没证据」概率采样防「点几下就下结论」用例冻结防「边测边放水」归因三分防「修错了对象」版本锚定防「结论过期」三态结论防「报告变装饰品」。AI 应用的价值在模型风险也在模型——但验收真正要盯住的是模型之外那整套 harness。用例在实践中长出来也在实践中被检验——这是这套方法能一直用下去的原因。AI 应用的验收没有捷径但有方法。方法比勤奋重要——这可能是做 AI 应用交付这一年多我学到最实在的一条。 你验收 AI 应用遇到过「边测边放水」或「修错对象」的情况吗评论区聊聊你的经历。 更多实战记录见我的博客鱼日先生本文基于 Hermes Agent v0.20.5 Dify 1.16.x 实测配置命令在不同版本间可能变化使用前请确认版本。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。
