能跑不等于能上线：把 Dify Demo 变成可运营的生产应用

前八集已经把 Dify 的主要构建能力走了一遍。到这里最危险的误区是：预览成功、发布按钮点亮，就把应用交给真实用户。

生产化不是再加一个节点，而是补齐一套运行纪律：版本可追踪、输入输出可审计、质量可评估、成本可约束、故障可回滚、敏感数据有边界。

验证边界：本文基于 2026-09-10 Dify 官方当前文档与本系列已有云版操作经验整理。官方截图均注明来源；套餐能力会变化，实施前请在你的工作空间再次核对。本文不是某个生产环境的上线验收报告。

先定义“上线”，再谈发布

一个最低限度的上线清单应同时回答：谁能用、用什么版本、失败谁知道、日志留多久、敏感数据在哪、成本上限多少、出现错误如何回退。

如果这些问题没有答案，应用只是“公开可访问”，不是“可以运营”。

Dify 对 Chatflow 和 Workflow 区分三种状态：当前草稿是开发中的工作版本，对用户不可见；最新版本是用户正在使用的版本；历史版本是过去发布过的快照。

发布时不要写“修了一点 Prompt”。采用可检索的命名：2026-09-10-rag-threshold-0.72，发布说明记录变更、影响、验证样本和回滚条件。

官方当前说明中，恢复旧版本到草稿、导出指定版本 DSL、通过 Service API 运行指定已发布版本需要付费套餐；Sandbox 始终运行最新发布版本。因此免费套餐不能把“存在历史记录”等同于“随时一键回滚”。

DSL 适合进入 Git：可以审查流程结构、Prompt 和变量变更，也方便跨环境导入。但它通常不应包含可用密钥，知识库内容、插件凭证、第三方账户权限和运行日志也不能假定随 DSL 一起迁移。

每次重要发布建议保留：DSL、版本名、提交 SHA、环境变量清单（只有变量名）、依赖的模型与插件版本、测试报告、回滚步骤。Secret 只记录保管位置，绝不写入仓库。

Dify 官方文档明确：Chatflow 和 Workflow 编辑器中的“预览/测试运行”不会出现在发布后的日志页。预览通过只能证明当前草稿在测试入口运行过，不能证明真实用户流量正常。

运行排障按这个顺序：先看总体状态和耗时，再找第一个失败或异常变慢的节点，然后核对该节点输入、输出、模型、工具参数和 token。不要只盯最终回复，因为上游可能已返回空值，最后节点只是忠实地输出了错误结果。

日志可能包含用户问题、上传文件、模型提示词、工具参数和业务结果。官方当前文档说明 Sandbox 各类日志保留 30 天，更早记录永久删除；删除对话或清理过期日志时，其中上传文件不会自动一并删除。

因此必须单独制定：数据告知与同意、访问角色、脱敏规则、保留期限、文件清理、导出权限和安全事件处理。不要把“平台会过期删除日志”误当成完整的数据生命周期治理。

仪表盘中的请求量、活跃用户、交互次数和 token 使用适合看趋势，但生产监控还要补充业务指标：

平均值会掩盖长尾，延迟至少看 P95；总 token 也不够，最好计算每次成功任务成本。给模型、工具和知识检索分别设预算，才能知道钱花在哪里。

标注系统为特定问题维护经过人工确认的答案。用户问题与标注语义匹配时，系统可直接返回策划好的回复，适合政策口径、售后规则和高频标准问答。

但阈值过低会误命中，阈值过高又覆盖不足。上线后要看命中次数、相似度、未命中案例和用户反馈；政策变化时及时更新。标注是生成式回答的补充，不是“导入一次就永远正确”的知识库。

建议发布门槛写成数字，例如“关键用例 30/30 通过，P95 < 8 秒，失败率 < 1%，单次平均成本不高于 0.08 元”。数字可因业务调整，但不能没有门槛。

工作空间所有者、管理员、编辑者和普通使用者应按职责分开。模型 Key、MCP URL、数据库凭证只给运行服务；编辑者不应因为能改 Prompt 就自动拿到生产密钥。

外部 API 必须有超时、重试上限、熔断和降级文案。涉及写入时增加幂等键与人工确认。模型供应商异常时，可降级到较小模型或只返回检索证据，但要让用户知道能力已降级。

发布按钮只是一次状态变更；生产能力来自持续观察和可恢复性。

下一篇也是系列收官：把 Dify 部署到自己的服务器，并把配置、Secret、域名、存储、升级与迁移讲清楚。