一个应用在预览窗口里回答正确，并不代表它已经可以长期使用。真实用户会提供更混乱的输入，外部接口会失败，知识会过期，模型和提示词也会变化。Dify 的发布只是起点，后续需要用运行记录和测试集形成改进循环。

发布前建立基线

为应用准备一组固定样本，覆盖最常见问题、高风险边界和已知失败案例。每个样本至少记录输入、期望要点以及不可出现的内容。修改提示词、模型、知识库或工作流后，都重新运行这组样本。

对于 Workflow，要检查每条分支和每个输出；对于知识问答，要同时检查检索片段与最终答案；对于 Agent，要查看工具选择、参数和停止条件。只比较最终文字，会漏掉许多隐藏问题。

选择发布方式

Dify 应用可以发布为可分享的 Web App，也可以通过 API 接入现有产品。发布更新后，应在真实发布环境再跑一次端到端测试，因为草稿态和已发布版本可能不同。若应用面向外部用户，还要配置访问控制、频率限制、隐私说明和人工支持渠道。

不要把测试环境的宽松权限直接带到生产环境。生产凭据应独立配置，工具权限从最小集合开始，涉及写操作的功能分阶段开放。

从日志里提出具体问题

运行日志适合回答这些问题：用户最常问什么，哪一步最容易失败，知识检索是否命中，模型调用耗时和成本如何，Agent 是否重复调用工具。查看问题时要定位到具体节点，而不是只给整个应用贴上“效果不好”的标签。

日志和对话内容可能包含个人信息，应限制访问和保存期限。用于改进的样本先脱敏，再进入长期测试集。

一次只改变一个关键因素

如果同时更换模型、重写提示词、调整分段和新增工具，即使结果变好，也很难知道原因。较稳妥的节奏是：从日志选出一个高频问题，补充可复现样本，只修改一个主要因素，运行回归测试，再决定是否发布。

可以持续记录四类指标：任务完成率、关键事实正确率、拒答或转人工是否合适、单次运行的时间与成本。指标不必复杂，但定义必须稳定。

建立最小运营循环

收集失败样本 → 判断发生在哪个节点 → 修改一个关键因素
       ↑                                  ↓
   观察发布结果 ← 小范围发布 ← 固定样本回归测试

每次改进都应留下简短记录：为什么改、改了什么、哪些样本变好、是否出现退化。这样，Dify 应用才会从一次性的演示变成可以解释、可以回滚、也可以继续生长的服务。

学完这八个应用后，你不必立刻掌握所有节点。更重要的是形成一种设计顺序：先定义任务和边界，再画出最短链路；让数据和权限受控，让失败能够被看见；最后才用模型能力提升体验。