Dify 韧性验证实验（07）：六模块综合验收——AI 应用上线前如何做六维度验收？
1. 业务场景
先讲一个我们实际遇到的场景。
一家企业交付了一套客服工单 SaaS（门户对话 + 工单 + 排障），准备上线。客户（数字化负责人）不放心：「你们说能用，凭什么？」于是委托第三方独立验收——只报告不修改，验收报告用于评估「能不能上线」。这不是内部自测，是客户要拿去拍板的正式报告：边界声明、系统行为覆盖维度、判定三分法、缺陷清单、上线后回归指引，一个都不能少。
我们第一次接这类需求时，第一反应是「验收不就是把用例跑一遍嘛」。真正动手才发现——跑用例只是最表层的一环：判定要三分（输入问题/mock 设计/真实缺陷）、平台能力问题要单列、报告要写成客户看得懂的语言。把「跑完了」当成「验完了」，报告交出去是要被客户打回来的。
这不是个例。任何「交付 → 验收 → 上线」的项目都是这个模式：独立验收的价值在于第三方视角——「只报告不修改」，验收报告直接回答客户「能不能上线」。
2. 场景痛点
这个流程的痛点，在交付验收时体现得最直接：
- 自测结论客户不信：开发团队说「测过了没问题」——客户要的是独立第三方的正式报告，不是口头承诺。
- 验收维度不全：只测功能 happy path，错误路径、边界、安全、上下文工程、循环控制没人管——上线后炸的全是没测过的维度。
- 缺陷说不清：判定不三分，输入问题、mock 设计、真实缺陷混在一起，平台能力问题也往缺陷清单里记——报告没法用。
- 报告客户看不懂：满篇技术术语，客户数字化负责人没法拿去做决策——报告写出来就失效了。
本质上，验收的产出不是「跑完了」，而是「客户看得懂、边界说得清、缺陷可追溯」的正式报告。
3. 方案：为什么是六模块综合验收
对最复杂的门户对话应用，跑一次完整六模块验收，产出客户语言版正式验收报告——这是独立验收服务的完整演示。
选它的理由：
- 六模块全覆盖：循环控制/工具层/上下文工程/边界安全/事件通道/可观测性——前 6 篇是六块积木，本篇把它们拼成一次完整验收；
- 判定三分法：初判失败先三分（输入问题/mock 设计/真实缺陷），只有真实缺陷计入清单，LLM 概率性波动多次采样 + 重跑确认；
- 客户语言版报告：边界声明 + 系统行为覆盖维度 + 缺陷清单 + 上线后回归指引——配套简化 TR 链作为验收基准（业务价值侧）。
这篇文章我们就用它给门户对话应用跑一次完整六模块验收：读简化 TR 链 → 导出 DSL → 读知识库 → 建验收 Key → 跑用例 → 取证 → 判定 → 出报告。
4. 整体架构
| 模块 | 重点用例（Happy/Error/Edge） | 判定锚点 |
|---|---|---|
| 循环控制 | 多出口终止性/降级链可达 end/迭代收敛 | 出口存在；partial 且出口空=P1 |
| 工具层 | 参数提取/工具调用/结果消费一致性/枚举校验 | 检索→回答矛盾=P2 |
| 上下文工程 | 多轮持久性/会话隔离/LLM 变量注入 | 占位符原文输出=静默失败 P1 |
| 边界安全 | 注入/越权/敏感信息（用 105-04 对抗样本库） | 注入成功=P1 |
| 事件通道 | 幂等/枚举/断线补偿 | 重复副作用=P1 |
| 可观测性 | trace 完整/指标真实/诊断演练 | 无 trace 不可验收 |
流程很清晰：读简化 TR 链 → 导出 DSL → 读知识库 → 建验收 Key → 跑用例（六模块 × Happy/Error/Edge）→ 取证 → 三分法判定 → 平台边界核对 → 客户语言版报告。关键设计是「只报告不修改」的第三方视角贯穿始终，每个判定都有 node-executions 证据支撑。
5. 模块设计
5.1 验收设计原则（对应用例 Excel Sheet1）
- 基于真实内容：用例输入基于应用实际知识库内容（7 个分段：平台概述/标准版/旗舰版/服务承诺/开通流程），库内 + 库外问题对照，不编造
- 痛点驱动：客户四条使用痛点（答非所问/多轮忘上文/响应慢/工单不透明）各转至少 1 条用例，结论直接回应
- 行为验证：记忆保持用行为验证（第 3 轮问折扣按 VIP 答），不是问「你记得吗」
- 中间态断言：关键用例查节点级执行（记忆更新链 3 个 assigner、检索命中），防「答对了但链路是错的」
5.2 判定纪律（三分法 + 多次采样 + 重跑确认）
初判失败先三分：输入问题（如 400=校验生效）/ mock 设计（演示行为）/ 真实缺陷——只有第三类计入缺陷清单。LLM 概率性波动要多次采样 + 重跑确认。
5.3 平台边界核对
平台能力问题（消息通道/认证机制/沙箱执行环境/形态级限制）不计缺陷——平台边界声明写进报告，风险由平台方承担。
5.4 执行要点
- advanced-chat 用 console
/advanced-chat/workflows/draft/run触发（workflow 的 /draft/run 404） - 多轮固定 user + 当轮 conversation_id；node-executions 取证（console 触发）
- 性能：20 次采样 P95 对比阈值（10s）
6. 运行验证
| 用例维度 | 用例数 | 通过 | 失败 | 通过率 |
|---|---|---|---|---|
| 功能 | 4 | 4 | 0 | 100% |
| 错误路径 | 1 | 1 | 0 | 100% |
| 性能 | 1 | 1 | 0 | 100% |
| 安全 | 3 | 3 | 0 | 100% |
| 边界/异常 | 2 | 2 | 0 | 100% |
| 工具层 | 2 | 2 | 0 | 100% |
| 上下文工程 | 6 | 6 | 0 | 100% |
| 循环控制 | 2 | 2 | 0 | 100% |
| 可观测性 | 2 | 2 | 0 | 100% |
| 合计 | 23 | 23 | 0 | 100% |
关键结果（实测）：23 用例 100% 通过，0 个 P1/P2 缺陷；结论「通过——可直接上线」；node-executions 9 节点全 succeeded；客户痛点 P-01~P-04（答非所问/多轮忘上文/响应慢 P95=5.6s/工单不透明）四条全部「不成立」（实测未复现）；判定排除项 1 条（EC-01 空消息 400=校验生效）。
7. 实战坑
| 坑 | 现象 | 修复 |
|---|---|---|
| 枚举输入不读 options | 400=校验生效误报 FAIL | 枚举输入先读 options 合法值，非法值 400 判通过（实测，三批 10+ 次） |
| 多轮换 user | 404 误判应用缺陷 | 固定 user + 当轮 conversation_id（实测，103） |
| 判定不三分 | 输入问题/mock 设计被当缺陷 | 三分法判定，只有真实缺陷计入清单（实测，三批 6 次） |
| 平台能力当缺陷 | 平台故障/形态限制计入缺陷清单 | 平台边界核对，平台能力问题不计缺陷（方法论，105 前补） |
8. 实验文档及源码获取
- 实验文档（完整操作步骤）：DIFY-105-07：六模块综合验收.md
- 验收对象源码（可直接导入）：dify105_03_门户对话.yml
- 关联应用源码：
- 全部实验文档目录：dify-105/experiments
- 全部源码目录：dify-105/dsl
文章聚焦核心配置与采坑点；实验的完整分步操作（节点搭建/参数表/调试指引）见实验文档原文。
- Dify 韧性验证实验（01）：故障注入与降级链——如何用故障注入验证 AI 应用的降级链？
- Dify 韧性验证实验（02）：契约与消费一致性——多应用协作时契约变了如何第一时间发现？
- Dify 韧性验证实验（03）：多轮记忆边界——对话记忆在哪些场景会失效？
- Dify 韧性验证实验（04）：安全对抗——如何给 AI 应用做安全对抗测试？
- Dify 韧性验证实验（05）：并发与可靠性——高并发下 AI 应用如何保证可靠？
- Dify 韧性验证实验（06）：全链路追踪——一次请求如何在 Dify 中被完整追踪？
- Dify 韧性验证实验（07）：六模块综合验收——AI 应用上线前如何做六维度验收？
- Dify 韧性验证实验（08）：上线后回归——应用上线后如何持续回归验证？
