Dify 从试用走到生产：JOTO 交付时先检查的十个问题
本文根据 JOTO 于 2026 年 6 月形成的资料重新整理，2026 年 7 月 16 日更新公开。试用成功只说明某个演示路径可以运行，生产交付却要求团队解释：谁对答案负责、故障时谁接手、数据流向哪里、旧版本如何恢复。上线评审不应只看一次效果展示，而应把十个问题写成可签字的检查表：业务目标是否可量化，输入范围是否清...
本文根据 JOTO 于 2026 年 6 月形成的资料重新整理，2026 年 7 月 16 日更新公开。
试用成功只说明某个演示路径可以运行，生产交付却要求团队解释：谁对答案负责、故障时谁接手、数据流向哪里、旧版本如何恢复。上线评审不应只看一次效果展示，而应把十个问题写成可签字的检查表：业务目标是否可量化，输入范围是否清楚，模型与插件是否可用，知识来源是否受控，身份与权限是否对应完整，敏感信息是否被处理，日志是否足够定位，容量是否经过验证，人工接管是否可执行，回滚包是否已经演练。
判断这个场景是否适合
先问任务能否定义成功与失败。若使用者连正确答案的边界都无法描述，模型评测也只能停留在主观印象。第二问是错误后果能否承受。内部资料检索允许提示不确定并转人工，自动发送合同、改写生产数据或直接决定付款则需要更严格的审批，不能因为流程在 Dify 里跑通就默认可放行。第三问是输入与知识是否稳定。来源频繁变化但无人维护、扫描质量很差、权限随组织调整的场景，要先解决资料治理。
第四问是调用链是否有可替代项。模型、向量库、对象存储、邮件或业务接口中的任何一个都可能不可用；如果业务只能依赖单一外部能力且没有降级路径，应把它标为高风险。第五问是使用规模与时段是否可估算。人数并不是单一指标，长文档解析、并发工作流和工具调用可能造成突发负载。第六问是答案能否被抽样复核。没有问题集、引用证据和业务审核人的应用，很难证明版本变化没有破坏原有能力。
实施时怎么拆
交付可拆成四条并行但有门禁的工作线。业务线维护场景说明、禁止事项和人工确认点；应用线固定 DSL、提示词、变量、模型参数与依赖版本；平台线准备域名、证书、数据库、存储、备份、监控和容量；治理线建立账号、角色、数据分级、审计保留期及离职回收。四条线在测试环境会合，用同一批基准问题做功能、权限、异常和恢复测试。
第七问对应可观测性：每次请求要能关联应用版本、模型、耗时、错误、消耗与工具结果，但日志不能原样长期保存敏感正文。第八问对应容量：用接近真实长度的输入做并发测试，并分别记录入口、队列、模型和外部工具的等待。第九问对应人工接管：界面要明确告诉使用者哪些结果待确认，失败任务进入可重放队列，客服或运营能看到必要上下文。第十问对应回滚：保留上一版应用导出、配置清单、数据库备份和部署脚本，发布前验证恢复时间，而不是临时寻找旧文件。
上线当天采用小范围开放，观察错误类型而非只看请求总数。负责人逐项确认域名与证书、账号登录、知识检索、模型降级、工具超时、告警通知、备份结果和回滚命令。发现引用错位、权限穿透或业务写入异常时立即停止扩量；涉及数据正确性的版本优先回退，不能边运行边猜测原因。
不要忽略的限制
检查表不是免责任证明。模型输出有随机性，第三方服务条款与配额会变化，知识库中的旧内容也可能看似合理却已经失效。团队需要明确内容负责人和复核周期，并在高风险动作前保留人工批准。生产密钥不得写入应用导出或仓库，测试账号不能沿用到生产，日志脱敏也要验证嵌套字段和附件。
另一个常见误区是把备份等同于回滚。数据库备份能恢复数据，却未必包含应用定义、环境变量、插件文件和外部接口状态；反向迁移还可能不受支持。因此每次发布都应记录变更边界，先在副本验证恢复，再决定回退数据库还是仅回退应用。十个问题中只要有一项没有责任人、证据或处置动作，结论就应是有条件上线或暂缓，而不是勾选通过。
