上个月，我们聊过了《使用 Dify 和 AWS Bedrock 玩转 Anthropic Claude 3[1]》，里面介绍了如何使用交互体验较好的 Prompt IDE，来帮助我们方便的调试 AI 应用中的 Prompt，以及快速搭建一个 AI 应用。
半个月前，Dify 团队推出了包含 AI Workflow 新功能的 v0.6.0[2]，这个功能虽然从去年年底就在做了，但是因为功能复杂，代码变更量巨大，直至今天 v0.6.4[3] 正式发布，才算进入一个相对稳定期，所以适合写一篇新的文章来聊聊啦。
感受下 Dify 团队在过去两周的发布动作：
•v0.6.0[4] （带有 AI Workflow 功能和一大堆更新，1241 个文件变动）•v0.6.0-fix[5] （紧急修正：Agent 应用的添加功能）•v0.6.1[6] （修复了 23 项内容）•v0.6.2[7]（支持了新的模型、新的图片 Agent，并且修复了 17 项内容）•v0.6.3[8]（增加一堆新功能，比较有意思的是 PgVector，Workflow 支持快捷键操作，Prompt 中引用的变量可以自动改名字，修复了 14 项内容）•v0.6.4[9]（支持了代码解释器、月之暗面模型的 FuncCall、SD3，修复了 20 项内容）
小步快跑，干的漂亮。
而获取 API Key 难度很低的 MoonShot，则在最近悄悄上线了 “Tool Use[10]” 功能。在开源社区里，我们一般称这个功能为 Function Call，借助特殊构造的请求结构和提示词，来让模型自动的调用用户预定义的远程函数，实现智能的 RPA 调用。
能够调用“外部工具”的模型功能
我计划将工作流相关的事情拆分为两篇来聊，过程中不太想切换模型，所以就选择了支持 “Function Call” 的它。下篇相关的文章，我们展开聊聊，如何利用这个功能，结合“Workflow”来做一些有趣的自动化。本篇文章是基础篇，我们就先用它的基础功能就好，难度大概是 “有手就行”。
我将本文用到的 Dify 和 WordPress 的 Docker “一键启动”配置相关文件开源在了 soulteary/dify-with-wordpress[11]，如果你感兴趣一些使用和配置上不同于官方的小的优化、维护技巧，可以翻阅下文的“维护优化”小节。
我们先从基础实战开始。
想顺滑的完成实践，我推荐你安装 Docker，不论你的设备是否有显卡，都可以根据自己的操作系统喜好，参考这两篇来完成基础环境的配置《基于 Docker 的深度学习环境：Windows 篇[12]》、《基于 Docker 的深度学习环境：入门篇[13]》。当然，使用 Docker 之后，你还可以做很多事情，比如：之前几十篇有关 Docker 的实践[14]，在此就不赘述啦。
在之前的两三篇文章《把 WordPress 变成 BaaS 服务：API 调用指南[15]》、《WordPress 告别 MySQL：Docker SQLite WordPress[16]》、《WordPress SQLite Docker 镜像封装细节[17]》中，我介绍过轻量化的、能够在本地快速运行的 WordPress，以及能够提供 API 交互的 WordPress 方案。感兴趣可以自行翻阅，这里就不展开具体细节啦。
为了能够更简单的折腾本文的内容，我封装了一个开箱即用的、轻量化的、能够提供 API 交互的 WordPress Docker 镜像，项目开源在了 soulteary/docker-wp-api[18]，使用方法非常简单：
使用上面的命令完成 Docker 镜像的下载，然后使用类似下面的配置，可以快速启动这个镜像中的 WordPress：
当然，为了更简单一些，我将文章相关的代码和配置都开源到了 soulteary/dify-with-wordpress[19]，你可以在项目中获取所有的代码。项目中的配置将 Dify 和它相关的依赖、WordPress 都打包到了一起：
当我们获取项目代码后，执行 docker-compose up -d 之后，稍等片刻，我们就可以在浏览器中分别访问：
一路 “Next” 快速初始化 Dify
一路 “Next” 快速初始化 WordPress
当两个应用都初始化完毕后，我们就完成了所有的准备工作。
那么，我们就先来实现一个简单的功能，让 WordPress 能够在我们写好内容的时候，根据内容自动生成一个合适的标题。你可以举一反三，来让其他的“内容生成、优化”也都 AI 化。
点击界面右上角的用户头像，在下拉菜单中点击“设置”，在弹出窗口中选择左侧的“模型供应商”菜单，能够看到 Dify 支持配置使用的所有模型类型。
在 Dify 模型配置中设置模型的 API Token
在列表中往下拉，找到“月之暗面”，然后把我们的模型 API Token 配置到 Dify 中。
设置默认的系统推理模型
配置完毕之后，在这个弹出窗口的顶端选择“系统模型设置”，将“系统推理模型”设置为反应最快、成本最低的 8K 模型。
在 Dify 中配置好的模型
当两个配置都设置完毕后，这个弹出窗中展示的模型在 Dify 中就完全可用啦。
创建一个文本生成应用
关闭上面的弹出窗口，我们创建一个新的文本生成应用，你可以根据你的喜好来填写应用的标题和描述。
编写我们的提示词内容
根据我们的设想，我们的模型应用应该能够根据我们提供的内容，来自动生成一个合适的标题，为了让模型干活符合预期，我们可以在 Dify 的 IDE 中完成 Prompt 的调试和编写工作。
这里建议使用相对有层次的 Markdown 语法来给模型“立一些规矩”，效果会相对好一些，这里假设模型是“机器之心”的记者，擅长挖掘内容和编写标题：
在上面的提示词中，我们设置了一个名为 “content” 的变量，在随后的真实模型调用中，我们可以在 API 的请求参数中动态的调整这个数据内容，来让它解决不同的文章的标题生成任务。
设置模型的具体参数
选择一篇测试内容
既然我们的 Prompt 提示词都选择的人设都用了“机器之心”，那么验证测试的文章也选择机器之心的报道好啦，比如，这里我选择的是 “Linus 喷 AI 炒作的一篇报道[20]”。
调试模型输出结果
将测试内容粘贴到调试对话框中，点击“运行”，我们就能够验证模型在这个 Prompt 和调用参数下的表现了，你乐意的话，可以打开好几家不同的模型进行调试比较。
这里可以看到，在之前的 Prompt 要求下，虽然没有生成出“机器之心”感觉的标题（模型生成的标题相比有些无聊），但是确实按照要求生成了一条符合字面要求的标题，满足继续往下折腾的要求。如果你有更高的要求，可以耐心调整上面的 Prompt 提示词。
那么，我们开始在 WordPress 中的折腾。
访问 Dify 应用 API
在 Dify 配置的 AI 应用页面中，我们点击“发布”按钮，在下拉菜单中选择“访问 API”，我们就能得到如何通过 API 访问配置好的 AI 应用的文档说明了。
向模型应用发送请求
我们只需要调用 /completion-messages 接口，将刚刚 Prompt 中设置的 content 传入接口即可。
获取当前应用的 API Key
在调用 Dify API 的时候，我们需要进行身份验证，在这个页面的右上角，点击“API 密钥” 按钮，创建一个 API 密钥即可。
创建好 Dify AI 应用的 API Key 后，我们可以将上面文档中的调用写成一个简单的 PHP 模型调用函数。这个函数接收一个参数（文章内容），并将文章内容传入 Dify 的调用结构体中，当 Dify 调用 Moonshot 模型后，我们解析调用结果，取出返回内容中的 answer 字段，就得到了模型生成的标题内容。
而让 WordPress 能够在我们的文章有内容，没有标题的时候，调用上面的函数，就更简单了（借助 WordPress 定制能力中的 hooks/the_post[21]）：
启用 WordPress AI 插件
在 WordPress 中创建新的内容
点击发布，AI 将迅速的生成标题
当我们点击“发布”按钮后，WordPress 会调用上文中我们配置好的 Dify AI 应用，将我们的文章内容发送给 Dify，构建出一个新的（完整的）提示词，然后向 Moonshot 的模型进行请求，并将模型生成结果填充到标题区域。
因为我们的 Prompt 提示词和模型调用参数是维护在 Dify 中的，所以我们如果想完善模型的生成规则、风格、生成数量，我们只需要更新上文中 Dify IDE 中的 Prompt 提示词内容，而不需要修改程序，这是不是非常方便呢？
Dify 项目的默认配置目前有比较大的优化空间，可以让配置更简单、更易于长期使用的维护管理。
官方很贴心的在项目中提供了一键启动的配置文件[24]，不过如果你认真浏览，你会发现官方尽可能给出了丰富的选项。
•你能够调整前端服务、后端 API 服务、实际干活的 Worker、代码执行沙盒环境的一些配置。后端服务和实际干活的 Worker 还是一个镜像，省却了一些下载的功夫。•你能够设置或替换 Postgres 数据库、Redis 缓存、Weaviate（默认使用）和 Qdrant （支持全文索引）向量数据库，甚至还有网关程序 Nginx 的细节。
所以，我们可以通过 Compose File 的 env file[25] 功能，来对官方的配置文件进行抽象和整理，让骨干配置文件更清晰和简洁，比如我们可以将原本 230 多行的配置简化为下面更简洁漂亮的格式：
我们可以用一个简洁的表达方式来完成相同的诉求，甚至让配置变的更加适合 “扩容”，抽象需要分发流量的 “前端” 和 “后端”，在必要的时候，只需要扩展 “服务数量即可”：
关于本文中埋的一些未展开的伏笔，其实有很多有趣的玩法，比如可以将 WordPress 变成一个低成本的、简单的 RAG 知识库、带有版本管理的 CMS、搭配模型使用的带版本管理的图床。