Dify 插件开发实验（12）：企业级交付验收——插件交付如何做验收？
1. 业务场景
先讲一个我们实际遇到的场景。
客户（企业客服工单 SaaS 运营方）要验收我们的「插件化交付」：这次交付的不是单个插件，而是「插件集 + 配套应用 + 验收报告」的整体方案——客服工单 SaaS 插件化增强包。九个插件（企业对接、事件通道、通知渠道、模型网关、外部知识库、工单编号……）加两个组合应用，客户要在验收会上给出结论：能不能上线？
我们第一次做这种收官时，第一反应也是「把应用跑一遍，没问题就验收通过」。真正动手才发现——插件化交付的验收对象是「插件 + 应用」的组合，不是应用本身：只按纯应用验收，插件层的安装、凭证、升级问题全漏掉，上线一周插件升级失败才知道验收漏了；验收报告写满 provider、plugin_id，客户根本看不懂，验收会变成名词解释会。
这不是个例。任何 ToB 交付的收官环节都是这个模式：方案交付完不是结束，验收才是「能不能投产」的判决——插件层（安装/配置/凭证/升级）和应用层（业务流程）都要被系统性验证，结论要写成客户能看懂的报告。
2. 场景痛点
这个流程的痛点，在验收环节体现得最直接：
- 只验应用不验插件：按纯应用验收，插件层的安装、凭证、升级问题全漏掉——上线一周插件升级失败，才知道验收漏了。
- 报告满篇内部术语：验收报告写满 provider、plugin_id，客户看不懂，验收会变成技术名词解释会。
- 边界不声明：mock 后端验证的结果被当成真实结果——客户以为「已经全量验证过真实系统」，实则没有。
- 问题无跟踪：验收发现的问题不记录、不回填，缺陷清单漂在口头，复验无依据。
本质上，验收的价值不在「跑一遍用例」，而在「用客户能懂的结论证明系统可上线」——对象要覆盖全、语言要客户化、边界要讲清楚。
3. 方案：为什么是六维度验收方法论
选六维度验收方法论，我们实际对比过：
- 双层覆盖：插件层（安装/配置/凭证/升级）+ 应用层（业务流程）一起验——插件化交付的验收对象是「插件 + 应用组合」；
- 六维度用例设计：功能 / 性能 / 安全 / 可靠性 / 压力 / 异常，20 条用例（P1×13 核心必过 + P2×7 抽样），判定三态：通过 / 不通过 / 有条件通过；
- 客户语言报告：报告用「系统行为覆盖维度」表替代内部术语，边界声明写进报告 §1——结论客户看得懂、也经得起追问。
这篇文章我们就用它完成全批收官：把 01-11 的插件能力组合成客户场景解决方案，跑完整验收流程，产出客户语言版正式验收报告——即对外服务包的样板。
4. 整体架构
链路很清晰：组合应用承载业务 → 六维度用例验证 → 三态判定 → 客户语言报告。关键设计是「报告链」——用例 md → 用例 Excel → 报告 md → 报告 Word，每个环节都有交付物，验收结论全程可追溯。
5. 模块设计
5.1 组合应用对插件的依赖声明（dify106_12_工单流程.yml 的 dependencies）
DSL 按 plugin_unique_identifier 精确声明依赖，导入时自动校验插件安装状态（与 106-11 的 plugin_id 匹配升级兼容结论呼应）：
dependencies:
- type: package
value:
plugin_unique_identifier: dify106/dify106_10_ticket_no_tool:0.0.1@922082de7f8dc6cbea32
- type: package
value:
plugin_unique_identifier: dify106/dify106_05_stateful_tool:0.0.1@3c13ed55881253f256e5a
- type: package
value:
plugin_unique_identifier: dify106/dify106_06_notify_tool:0.0.1@c202c02838ee014fd8ad4025.2 六维度用例分布（P1 代表用例）
功能——工单全流程（编号生成→事件接收幂等→通知回执）；性能——组合流程 P95 延迟；安全——凭证不落日志、错误信息无敏感数据；可靠性——KV 故障时工具明确报错不静默；压力——并发工单提交（编号不重复、事件不重复处理）；异常——上游 API 故障/超时的降级路径。
5.3 报告链与客户语言
用例 md → 用例 Excel（3-Sheet）→ 报告 md（7 节）→ 报告 Word。报告用客户能懂的语言——「系统行为覆盖维度」表替代内部术语（provider/plugin_id 仅作注释）；边界声明写进报告 §1：mock 后端验证，真实后端需客户环境复验，不覆盖平台自身功能与网络基础设施。
6. 运行验证
| 验证项 | 场景 | 预期 | 结果 |
|---|---|---|---|
| 方案部署 | 6 插件正式安装 + 2 集成应用导入发布 | 全部可用 | ✅ |
| 用例执行 | 六维度 20 条（P1×13 + P2×7） | P1 全跑、P2 抽样执行 | ✅ 20/20 通过 |
| 组合流程 | 编号生成 → 事件接收（幂等）→ 通知回执 | 编号递增、重复事件返回已处理 | ✅ 连续运行正常，单次约 0.3s（P95<2s） |
| 凭证安全 | 密钥存储/显示/日志 | 加密存储、脱敏显示、日志无明文 | ✅ |
| 升级与回滚 | 插件 0.0.1→0.1.0 后旧应用 | 自动兼容；回滚恢复基线 | ✅ |
| 故障行为 | 外部依赖不可达 | 明确报错（不静默）+ 工作流降级分支 | ✅ |
验收结论：通过（mock 后端范围内）——插件集功能完整、运行稳定、交付链路（安装/升级/回滚）可靠，满足上线使用条件；真实后端对接后按报告 5.3 复验即可正式投产。缺陷清单：未发现 P1/P2 级缺陷；已知边界（非缺陷）3 条——并发编号存在极小竞态窗口（生产建议 Redis 原子计数）、mock 后端结果需真实环境复验、Agent 对话形态思考过程展示为平台级限制。
7. 实战坑
| 坑 | 现象 | 修复 |
|---|---|---|
| 验收对象混淆 | 只按纯应用验收，插件层检查缺失 | 双层覆盖：插件层（安装/凭证/升级——106-11 实测）+ 应用层（组合流程——本实验实测）；六维度用例 20 条 P1 全过 |
| 报告写内部术语 | 报告满篇 provider/plugin_id，客户看不懂 | 报告用「系统行为覆盖维度」表（客户语言）+ 已知边界（非缺陷）表述；内部术语仅作注释 |
| 边界不声明 | mock 后端结果被当成真实结果 | 报告 §1 边界声明：mock 后端验证，真实后端需客户环境复验；不覆盖平台自身功能与网络基础设施 |
| 采坑点未回填 | 实验文档「预期（待实测）」留白 | 全批复盘表：12 实验 81 条采坑点全部回填实测结论，无留白 |
| 意图写直白 | 报告写「可提供服务清单」像推销 | 报告 5.3 用「后续跟进建议」（客观工程建议：复验/回归/监控），不写服务清单 |
8. 实验文档及源码获取
- 实验文档：DIFY-106-12：企业级插件交付验收.md
- 验收报告：dify-106/delivery/验收报告.md
- 全批复盘表：dify-106/delivery/全批复盘表.md
- 批次交付说明：dify-106/delivery/_交付说明.md
- 源码目录：dify-106/dsl | dify-106/plugins | dify-106/delivery
文章聚焦核心配置与采坑点，完整分步操作与六维度验收用例执行记录见实验文档原文。
系列 5「插件开发」12 篇至此全部完结——从首个工具插件到 Agent 策略、从打包分发到企业级验收，插件六类能力全链路实测完毕，「插件化定制」交付能力闭环。
- Dify 插件开发实验（01）：开发环境与首个工具插件——从零开发第一个 Dify 插件需要什么？
- Dify 插件开发实验（02）：参数与凭证体系——插件参数和凭证如何声明、配置与管理？
- Dify 插件开发实验（03）：工具接入工作流与Agent——插件工具如何在工作流和 Agent 中使用？
- Dify 插件开发实验（04）：企业系统对接工具——如何用插件对接企业 ERP/CRM？
- Dify 插件开发实验（05）：有状态与幂等——插件如何安全地保持状态和处理重复调用？
- Dify 插件开发实验（06）：通知渠道插件——如何把 Dify 推送到钉钉/企业微信等渠道？
- Dify 插件开发实验（07）：私有模型网关接入——如何让 Dify 用上私有模型网关？
- Dify 插件开发实验（08）：外部知识库插件——如何把外部检索能力做成插件？
- Dify 插件开发实验（09）：Agent策略插件——如何控制 Agent 的工具使用策略？
- Dify 插件开发实验（10）：自定义节点扩展——不改平台代码，插件如何补节点能力？
- Dify 插件开发实验（11）：打包分发与离线安装——插件如何打包签名、分发与离线安装？
- Dify 插件开发实验（12）：企业级交付验收——插件交付如何做验收？
