一次 AI PoC 为什么卡在验收前：用交付链路做复盘

这是一篇针对常见失败模式的方法论复盘，不对应也不声称描述任何真实客户。典型情形是：团队已经用 Dify 或其他工具做出可运行演示，提问能够得到答案，流程也能调用接口，但验收会议前突然发现，各方对“完成”的理解不同。业务看结果是否能用，安全看数据与权限，运维看稳定和恢复，项目组却只保留了演示截图。

判断这个场景是否适合

复盘先问 PoC 是否有可验证假设。目标若只是“体验 AI”，很难形成签字结论；应改为具体任务、用户、输入范围、可接受错误和人工接管方式。高风险决策、不可逆写入或缺少责任人的流程，不适合用自动执行作为首个 PoC，可以先验证检索、草拟或辅助判断。

第二问数据是否具有代表性和合法来源。只选整洁文档会高估知识效果，直接复制生产敏感数据又可能越界。应使用经过批准和脱敏的样本，包含旧版本、模糊问题、无答案问题和异常格式。资料所有者要确认用途、权限和退出后的删除方式。

第三问各方是否提前同意验收证据。接口返回成功不能证明业务成功，模型回答流畅也不能证明引用正确。业务、安全、数据和运维人员应分别提出用例并明确决定权。若直到演示结束才讨论身份、权限、审计和回滚，卡在验收前是流程结果，而不是突然增加要求。

实施时怎么拆

首先重建交付链路：用户身份如何进入应用，资料如何入库，Dify 工作流如何检索与调用模型，业务接口接受什么字段，日志如何关联，结果由谁确认。每条接口边界记录认证、权限、超时、重试和错误语义。无法说明的数据流和共享管理员密钥列为阻断项。

第二步把验收表拆成结果、治理和运行三组。结果组检查代表性问题、引用、结构和拒答；治理组检查账号、最小权限、敏感数据、人工确认与审计；运行组检查并发、告警、备份、依赖故障和恢复。每个用例保留版本、输入、预期、实际和负责人，避免只给口头结论。

第三步补做异常测试。模拟模型超时、检索无结果、工具接口失败、重复提交、无权限用户和取消任务。写操作只在沙箱执行，参数经过确定性校验，并由授权人员人工确认。失败任务进入可定位状态，不无限重试；审计通过统一请求标识串联应用、模型、知识与工具。

第四步设定重新验收门槛。不是把所有问题临时修到演示可过，而是确认阻断项有责任人、修复证据和回归结果。若范围变化，重新记录假设，不沿用旧结论。上线建议与 PoC 结论分开，PoC 通过不自动授权连接生产数据或扩大用户。

不要忽略的限制

方法论复盘不能推导某个具体项目必然失败的原因。真实环境还受版本、网络、模型和组织流程影响，Dify 的具体能力应以官方文档和现场验证为准。验收问题也不应被包装成单纯技术缺陷；没有资料负责人、业务审核人或运维接管人，工具调整无法补齐责任。

失败与回滚证据是验收的一部分。保存应用导出、提示与模型配置、知识基线、测试数据和接口模拟状态，确认能恢复到最近可用版本。已经写入外部系统的数据要按请求标识对账，不能通过回退应用假装不存在。若发生越权、错误写入或无法解释的结果，先停用相关入口，保留必要审计证据，修复后由原验收角色复验。未验证恢复，就说明 PoC 尚未完成验收链路。

参考资料

• Dify 官方文档