以前，我总是花大把时间把一篇博客文章改写成不同的格式，发到 Twitter、LinkedIn 和公司内部通讯上。每周，我都得手动把同样的核心内容重写个三四遍，针对每个平台调整语气和长度。这活儿不仅枯燥、容易出错，说实话，简直是白白浪费一整个下午。
我也试过用简单的 ChatGPT 提示词来做这事，但效果时好时坏。有时候它会瞎编细节，有时候又完全无视我贴进去的品牌语调规范。我需要一种更结构化的方式——一个可重复的流程：把原始内容丢进去，套用特定规则，然后直接输出排版好的内容，根本不需要我一直在旁边盯着调提示词。
这就是为什么我开始用 Dify。我想要一种可视化的方式，把多个步骤——提取关键点、调整语调、针对特定平台排版——串成一条靠谱的单行流水线。下面是我搞定它的全过程，包括踩过的坑。
搭建工作区
首先：打开 cloud.dify.ai 注册账号。你默认会进入 Sandbox 计划，系统会送你 200 个 AI Credits，可以用来调用 OpenAI、Anthropic 和 Gemini 等厂商的模型。这些额度足够你折腾体验一下了，但要注意，这是一次性发放的，不会按月续期。
如果你想把所有东西都跑在本地，Dify 是开源的，你可以用 Docker 自己部署。不过这篇教程里我用的是云版本，因为我想图个快。
登录之后，你需要配置模型提供商。进入 Integrations > Model Provider，安装 OpenAI。我搭建时选了 gpt-4o-mini，因为对于内容转换这种任务来说，它既快又便宜。这里有个坑把我卡住了：哪怕你用的是系统送的 AI Credits（不需要自己填 API key），你也必须显式地去安装那个提供商。我当时傻坐了五分钟，纳闷为什么下拉菜单里一个模型都刷不出来。
安装好提供商后，点击 Model Provider 页面右上角的 Default Models，设置你的系统推理模型。这会把你选的模型设为所有工作流节点的默认模型，省得你每次都得手动去选。
选对应用类型
Dify 提供了好几种应用类型，选错了会让你事倍功半。要是一开始有人给我讲下面这个总结就好了：
- Chatbot（聊天机器人）：简单的你来我往式问答。适合做客服或 FAQ 机器人。
- Agent（智能体）：能自主解决问题的选手，还能调用网页搜索或 API 等外部工具。当你需要 AI 自己做决定并采取行动时，选它就对了。
- Text Generator（文本生成器）：通过填表单来输出结构化内容。你可以把它想成一个“冷邮件写手”，用户填几个字段，就能得到一篇完整的草稿。
- Workflow（工作流）：多步骤的后台自动化。这正是我需要的——接收输入，经过几个处理步骤，输出排版好的内容。
- Chatflow（聊天工作流）：跟 Workflow 差不多，但是对话式的，有记忆功能，还能走分支逻辑。
对于我这种内容二次分发的需求，Workflow 显然是最佳选择。流程是线性的：输入内容 → 提取关键点 → 套用语调 → 为各平台排版 → 输出。完全不需要对话。
搭建多平台内容生成器
在工作室（Studio）里，选择 Create from Blank > Workflow。起个一目了然的名字，比如“Multi-platform content generator”，然后点击 Create。你会进入工作流画布——一个可以把节点连起来的可视化编辑器。
第一步：配置用户输入
点击 Start 节点（也就是你的用户输入节点）。你可以在这里定义工作流运行需要哪些信息。我加了这些输入字段：
content（段落类型）——原始的博客文章或文本tone（下拉选择类型）——选项：Professional, Casual, Witty, Authoritativeplatforms（下拉选择类型）——选项：Twitter, LinkedIn, Newsletter, Alllanguage（下拉选择类型）——选项：English, Spanish, French, German
下拉选择字段非常重要。它们能限制用户的输入，防止出现那种在文本框里填“写得酷一点”结果导致输出完全不可控的混乱局面。
第二步：添加 LLM 节点来提取关键点
点击 Start 节点后面的 + 按钮，添加一个 LLM 节点。这是真正进行大语言模型处理的地方。我的配置如下：
System prompt:
You are a content analyst. Extract the 3-5 most important key points from the provided content. Focus on actionable insights and unique arguments. Output as a numbered list.
User prompt:
Extract key points from this content:
{{#Start.content#}}
{{#Start.content#}} 这种语法是用来引用上游节点变量的。我找了一会儿才发现这个——你只要在提示词输入框里点一下，就会弹出一个变量选择器，显示上游节点所有可用的输出。
第三步：添加 LLM 节点来调整语调
再添加一个 LLM 节点，连到提取关键点的节点后面。这个节点负责把提取出来的要点按照选定的语调重写一遍。
System prompt:
You are a brand voice specialist. Rewrite the following key points in the specified tone. Maintain the core meaning but adjust vocabulary, sentence structure, and personality to match.
Tone: {{#Start.tone#}}
User prompt:
Rewrite these key points in the specified tone:
{{#Step2.text#}}
注意，这里我引用的是 Step2.text——也就是上一个 LLM 节点的输出。Dify 会自动给你的节点命名（LLM, LLM_1, LLM_2），这样很快就会乱套。我强烈建议点击节点标题给它们重命名。我把我的节点分别改成了“Extract Key Points”和“Apply Tone”。
第四步：添加 LLM 节点进行平台排版
见证奇迹的时刻到了。添加第三个 LLM 节点，把调整好语调的内容拿过来，针对目标平台进行排版。
System prompt:
You are a social media formatter. Format the provided content for the specified platform following these rules:
- Twitter: Maximum 280 characters, include 2-3 relevant hashtags, punchy and direct
- LinkedIn: Professional but conversational, 150-300 words, include a question to drive engagement
- Newsletter: Extended format, 200-400 words, include a subject line and call-to-action
Platform: {{#Start.platforms#}}
Language: {{#Start.language#}}
User prompt:
Format this content for {{#Start.platforms#}}:
{{#Apply Tone.text#}}
第五步：添加结束节点
把最后一个 LLM 节点连到 End 节点上。这定义了整个工作流最终输出什么。我把输出变量设为了排版节点的文本输出。
测试与迭代
这时候我遇到了第一个真正的麻烦。我拿一篇 2000 字的博客文章跑了下工作流，结果……很平庸。语调调整太微弱了，几乎看不出来，而且 Twitter 的输出远远超过了 280 个字符。
问题出在提示词上，而不是平台。我把系统提示词改得更具体，加了硬性限制：
For Twitter: Your output MUST be under 280 characters. Count carefully. This is a hard requirement, not a suggestion.
我也意识到，我想在一个排版节点里干太多事了。当我选择“All”平台时，模型试图在一条回复里输出所有内容，结果哪个都没干好。最后，我用了 Dify 的 IF/ELSE 节点，根据选择的平台走不同的分支，分别路由到各自独立的排版节点。这意味着画布上的节点变多了，但每个节点只干好一件事。
我学到的与诚实的局限性
用了这个工作流几周后，这是我的真实评价：
好用的地方：
- 可视化画布让复杂的流水线一目了然。我能清楚地看到内容是怎么流动的，瓶颈在哪。
- 一旦搞懂了语法，节点之间的变量传递非常丝滑。
- 可以单独测试某个节点（只点那个节点的“Run”），这省了海量的调试时间。
- 工作流可以当模板复用，我现在已经为不同品牌语调的客户建了不同的变体。
需要注意的局限性：
- 200 个 Sandbox 额度在你不断迭代时烧得特别快。我测试了两天就全用光了。如果你真打算好好搭建，备好自己的 API key。
- 节点的默认命名太坑了。一定要马上重命名，否则你会在一片“LLM_3”的海洋里迷失自我。
- 报错信息有时很模糊。节点运行失败时，调试输出有时只抛出一个“error”，根本不解释哪里出错了。我只能逐字去拆解我的提示词来找问题。
- 工作流处理超长文档不太行。现在如果超过 3000 字，我都会先把它切片预处理。
实用建议：
- 从小处着手。先搭个单步骤的工作流，测通了再加复杂度。
- 提示词要极其明确。模糊的指令只会产出模糊的结果，可视化界面有时会给你一种错觉，让你觉得光靠结构就能保证输出质量。
- 尽量用下拉选择输入。限制用户的选项能避免 80% 的边缘情况翻车。
- 单独建个文档记录你提示词的迭代版本。你需要经常调提示词，而画布上可看不到提示词的修改历史。
Dify 并不是什么魔法——它只是一种结构化的方式，通过规范的变量处理和可视化界面，把多个 LLM 调用串联起来而已。但这恰恰是我那种“把所有东西贴进 ChatGPT”的搞法里最缺失的。现在，我的内容二次分发工作流跑一趟大概只要 30 秒，再也不用花 30 分钟手动重写了，而且输出足够稳定，发布前只需稍微改改就行。