Dify 韧性验证实验07六模块综合验收——AI 应用上线前如何做六维度验收Dify 实验系列 · 韧性验证 07/8 | 实验编号DIFY-105-07基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家企业交付了一套客服工单 SaaS门户对话 工单 排障准备上线。客户数字化负责人不放心「你们说能用凭什么」于是委托第三方独立验收——只报告不修改验收报告用于评估「能不能上线」。这不是内部自测是客户要拿去拍板的正式报告边界声明、系统行为覆盖维度、判定三分法、缺陷清单、上线后回归指引一个都不能少。我们第一次接这类需求时第一反应是「验收不就是把用例跑一遍嘛」。真正动手才发现——跑用例只是最表层的一环判定要三分输入问题/mock 设计/真实缺陷、平台能力问题要单列、报告要写成客户看得懂的语言。把「跑完了」当成「验完了」报告交出去是要被客户打回来的。这不是个例。任何「交付 → 验收 → 上线」的项目都是这个模式独立验收的价值在于第三方视角——「只报告不修改」验收报告直接回答客户「能不能上线」。2. 场景痛点这个流程的痛点在交付验收时体现得最直接自测结论客户不信开发团队说「测过了没问题」——客户要的是独立第三方的正式报告不是口头承诺。验收维度不全只测功能 happy path错误路径、边界、安全、上下文工程、循环控制没人管——上线后炸的全是没测过的维度。缺陷说不清判定不三分输入问题、mock 设计、真实缺陷混在一起平台能力问题也往缺陷清单里记——报告没法用。报告客户看不懂满篇技术术语客户数字化负责人没法拿去做决策——报告写出来就失效了。本质上验收的产出不是「跑完了」而是「客户看得懂、边界说得清、缺陷可追溯」的正式报告。3. 方案为什么是六模块综合验收对最复杂的门户对话应用跑一次完整六模块验收产出客户语言版正式验收报告——这是独立验收服务的完整演示。选它的理由六模块全覆盖循环控制/工具层/上下文工程/边界安全/事件通道/可观测性——前 6 篇是六块积木本篇把它们拼成一次完整验收判定三分法初判失败先三分输入问题/mock 设计/真实缺陷只有真实缺陷计入清单LLM 概率性波动多次采样 重跑确认客户语言版报告边界声明 系统行为覆盖维度 缺陷清单 上线后回归指引——配套简化 TR 链作为验收基准业务价值侧。这篇文章我们就用它给门户对话应用跑一次完整六模块验收读简化 TR 链 → 导出 DSL → 读知识库 → 建验收 Key → 跑用例 → 取证 → 判定 → 出报告。4. 整体架构读简化 TR 链业务价值基准导出应用 DSL结构分析读知识库 segments库内/库外对照素材建验收 Key跑用例六模块 × Happy/Error/Edgenode-executions 取证run_id 用 data.id判定三分法输入问题/mock 设计/真实缺陷→ P1/P2 分级平台边界核对平台能力问题不计缺陷客户语言版验收报告模块重点用例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_idnode-executions 取证console 触发性能20 次采样 P95 对比阈值10s6. 运行验证用例维度用例数通过失败通过率功能440100%错误路径110100%性能110100%安全330100%边界/异常220100%工具层220100%上下文工程660100%循环控制220100%可观测性220100%合计23230100%关键结果实测23 用例 100% 通过0 个 P1/P2 缺陷结论「通过——可直接上线」node-executions 9 节点全 succeeded客户痛点 P-01~P-04答非所问/多轮忘上文/响应慢 P955.6s/工单不透明四条全部「不成立」实测未复现判定排除项 1 条EC-01 空消息 400校验生效。7. 实战坑坑现象修复枚举输入不读 options400校验生效误报 FAIL枚举输入先读 options 合法值非法值 400 判通过实测三批 10 次多轮换 user404 误判应用缺陷固定 user 当轮 conversation_id实测103判定不三分输入问题/mock 设计被当缺陷三分法判定只有真实缺陷计入清单实测三批 6 次平台能力当缺陷平台故障/形态限制计入缺陷清单平台边界核对平台能力问题不计缺陷方法论105 前补8. 实验文档及源码获取实验文档完整操作步骤DIFY-105-07六模块综合验收.md验收对象源码可直接导入dify105_03_门户对话.yml关联应用源码dify105_01_工单流程.ymldify105_02_排障助手.yml全部实验文档目录dify-105/experiments全部源码目录dify-105/dsl文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 韧性验证实验08上线后回归——应用上线后如何持续回归验证 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。
