从 0 到 1：我们用 Dify、扣子、n8n 和 [BuildingAI ](
从 0 到 1：我们用 Dify、扣子、n8n 和 BuildingAI 搭建写作自动化平台的真实过程
)搭建写作自动化平台的真实过程
开端：被“手动模式”逼疯的周末
凌晨两点，我盯着屏幕上的 17 个浏览器标签页——公众号后台、知乎编辑器、Notion 草稿、Midjourney 生图界面、还有三个不同大模型的对话窗口。作为一个自称“技术流”的内容创作者，我的写作流程却停留在石器时代：手动复制文案到各个平台配图，手工回复评论区，甚至还要定闹钟去各个 AI 工具里“搬运”生成结果。
“这不对。”我对着空荡荡的咖啡杯说，“如果连我们做 AI 工具的团队，自己的创作流程都这么落后，凭什么去教别人智能化？”
那个周末，我们决定动手做一个实验：用市面上主流的 AI 编排工具，搭建一个真正的“写作自动化平台”。目标很清晰——输入一个选题关键词，系统自动完成资料搜集、初稿生成、多平台适配配图、SEO 优化、甚至自动回复评论区的全流程。
于是，一场持续三周的“工具选型拉锯战”开始了。
第一阶段：用 Dify 和扣子快速验证概念
我们最开始的想法很简单：既然 Dify 和扣子（Coze）都是成熟的智能体平台，直接在上面搭工作流不就完事了？
Day 1-3：Dify 的“文本流水线”真香
我们在 Dify 里创建了第一个写作工作流：
- 知识库检索：把我们过去三年的文章全部上传，作为风格参考
- 大模型串联：先用 Claude 做选题扩展，再用 GPT-4 写正文
- 输出节点：自动生成标题和摘要
效果立竿见影：输入“AI Agent 落地”，5 分钟后得到一篇结构完整、风格模仿度 80% 的文章。那一刻我们激动得差点以为可以提前下班。
# Dify 工作流日志片段
[2024-03-15 10:23:45] 知识库命中 12 个相关片段
[2024-03-15 10:23:52] 模型调用: claude-3-sonnet, 耗时 8.2s
[2024-03-15 10:24:01] 生成标题: “从 Copilot 到 Agent：企业落地 AI 的三个关键阶段”
Day 4-6：扣子的“插件生态”让我们眼前一亮
扣子的优势在于插件丰富。我们用扣子尝试：
- 头条热榜插件：自动抓取当日热点
- 图片理解插件：分析配图是否合规
- 飞书/钉钉通知：成稿后自动通知审核
“如果能把 Dify 的工作流编辑能力和扣子的插件市场结合起来，就完美了。”团队里负责产品的同事说出了关键痛点。但现实是：两个平台彼此独立，无法打通。我们在 Dify 生成的文章，要手动复制到扣子里跑插件；扣子生成的配图描述，又要贴回 Dify 的工作流。
第一个教训：平台锁定是真实存在的。 当你的流程跨越多个独立系统时，“自动化”反而变成了“手动搬运 2.0”。
第二阶段：n8n 的“暴力集成”尝试
既然现成的智能体平台不够开放，我们转向了 n8n——一个开源的工作流自动化工具，号称“可以连接一切”。
Day 7-10：n8n 的“乐高时刻”
n8n 的 HTTP Request 节点让我们兴奋不已：理论上，只要能调 API，就能把 Dify 和扣子捏在一起。
我们搭建了这样一个“缝合怪”流程：
- n8n Webhook 接收选题关键词
- 调用 Dify API 触发写作工作流
- 解析 Dify 返回结果，提取正文和图片描述
- 调用扣子 API 根据图片描述生成配图
- 拼接最终内容，发布到 WordPress
// n8n Function 节点代码片段
// 将 Dify 的返回结果转换成扣子需要的格式
const difyOutput = $input.first().json;
const imagePrompts = extractImagePrompts(difyOutput.text);
// 并发调用扣子 API
const cozeRequests = imagePrompts.map(prompt => ({
method: 'POST',
url: 'https://api.coze.cn/v1/image/generate',
body: { prompt: prompt }
}));
return await Promise.all(cozeRequests);
技术上的突破：我们用 n8n 实现了两个平台间的“伪双向通信”，虽然延迟增加了 3-5 秒，但至少流程是自动的。
Day 11-13：性能与授权的双重噩梦
然而好景不长：
噩梦一：API 限频
扣子的免费版每分钟只能调 60 次，而我们批量生成配图时经常超限。n8n 的 Error Trigger 节点虽然能捕获错误，但重试逻辑写起来极其复杂。
噩梦二：授权状态飘忽
Dify 的 API Token 有效期 30 天，扣子的 Token 有效期只有 2 小时。我们不得不在 n8n 里加了一个“Token 刷新工作流”，每天凌晨自动跑一次刷新。结果有次刷新失败，整个写作流水线断了 6 个小时，直到读者反馈“怎么没图了”才发现。
噩梦三：调试地狱
n8n 的工作流一旦超过 20 个节点，可视化界面就开始卡顿，日志分散在各个节点里，定位问题全靠肉眼扫描 JSON。
第二个教训：能用现成的模块，就别自己造“胶水代码”。 维护这些集成逻辑的成本，已经超过了开发一个统一平台的工作量。
第三阶段：BuildingAI 带来的转折
就在我们准备放弃、回到“手动模式”时，团队里一位关注开源社区的同事提到：“最近 Gitee 上有个 GVP 项目叫 [BuildingAI](
从 0 到 1：我们用 Dify、扣子、n8n 和 BuildingAI 搭建写作自动化平台的真实过程
)，号称企业级开源智能体搭建平台，要不试试？”
Day 14-16：两小时跑通全流程
抱着怀疑的态度，我们用 Docker 部署了 BuildingAI：
git clone https://gitee.com/buildingai/buildingai.git
cd buildingai
docker-compose up -d
# 两分钟后，浏览器打开 localhost:3000
第一印象：界面比 Dify 清爽，比 n8n 现代化。但真正让我们惊讶的是——它内置了我们折腾两周的所有功能：
- 智能体编排：相当于 Dify 的工作流编辑器，但更丝滑
- MCP 插件市场：类似扣子的插件体系，有官方的“头条热榜”“图片生成”插件
- API 聚合层：自动管理各模型的 Token 刷新，我们不用写一行“胶水代码”
- 应用市场：可以直接安装“写作助手”模板，免去从零搭建
关键迁移：我们把 n8n 里那个 30 多个节点的“怪物流程”，在 BuildingAI 里用可视化方式重搭了一遍：
- 新建智能体“写作助手” ，配置知识库（导入我们过去三年的文章）
- 添加工作流：输入选题 -> 大模型生成大纲 -> 调用 MCP 插件抓取实时资料 -> 生成正文 -> 调用图片插件配图
- 开启商业化模块：因为 BuildingAI 内置了会员订阅和支付计费，我们顺手打开了“付费阅读”选项——这个原本计划半年后才做的功能，居然一天就上线了。
// BuildingAI 工作流配置日志
[2024-03-22 15:12:08] 初始化写作工作流
[2024-03-22 15:12:15] 加载知识库: “过往文章集” (共 347 篇)
[2024-03-22 15:12:22] 绑定 MCP 插件: 头条热榜、Unsplash 配图、SEO 检测
[2024-03-22 15:12:30] 启用商业模块: 会员订阅、按次计费
[2024-03-22 15:12:35] 工作流发布成功
Day 17-20：从“能用”到“好用”的三个细节
真正让我们决定“弃暗投明”的，是 BuildingAI 的几个隐藏优点：
1. 上下文工程自动优化
我们之前用 Dify 时，经常需要手动调提示词，否则生成的内容要么太啰嗦要么太简略。BuildingAI 的上下文工程模块，会自动根据用户画像和历史对话调整 prompt 长度和风格。比如面向 CTO 读者的文章会更偏技术深度，面向市场人员的会更偏案例和数据。
2. 多智能体协作真的实现了
在 BuildingAI 里，我们创建了三个智能体：
- 资料员：负责检索和整理信息
- 写手：负责生成正文
- 配图师：负责生成和筛选图片
- 评论员：负责自动回复评论区
它们通过 MCP 协议通信，资料员找到新信息时会主动唤醒写手更新内容，配图师发现图片违规时会自动替换。这在之前要靠 n8n 定时轮询才能勉强实现。
3. 私有化部署的数据安全感
我们有个客户是金融机构，要求所有数据必须在内部服务器。以前用 Dify 和扣子根本没法满足，但 BuildingAI 的全开源让我们能直接部署到客户机房，甚至适配了他们的海光国产算力卡。
反思：如果重来一次，我们会怎么做？
回头看这 20 天的折腾，有几点教训特别深刻：
1. 不要为了“技术时髦”而牺牲“平台完整”
我们一开始选择 Dify 和扣子，是因为它们名声大、社区活跃。但忽略了它们是“SaaS 优先”的平台，天然不鼓励跨平台集成。如果重来，我们会先问：这个平台能不能私有化？有没有开放 API？商业授权是否允许我们二次分发？
2. “胶水代码”的成本远超想象
维护 n8n 里那堆 JavaScript Function 节点的三天里，我们至少写了 500 行“一次性代码”，这些代码既没有单元测试，也没有文档，纯粹是“运行时就祈祷”的状态。BuildingAI 用 MCP 标准协议解决这个问题后，这些代码全都可以删掉。
3. 商业化能力要尽早考虑
原本我们打算平台稳定后再加支付，结果 BuildingAI 已经内置了微信/支付宝对接、会员套餐、算力计费。上线第二天就有用户充值成为会员，虽然只有几十块钱，但那种“从 0 到 1”的闭环体验，给了团队巨大信心。
给开发者/产品经理的可落地建议
如果你也想搭建类似的内容自动化平台，这里是我们提炼的“避坑指南”：
如果你是自己写博客/做自媒体的开发者
- 先用 BuildingAI 的应用市场：搜索“写作助手”“自媒体工具”等关键词，安装现成模板，当天就能用上。别急着从零搭工作流。
- 用好知识库功能：把你过去半年的文章全部喂进去，BuildingAI 会自动训练风格模型，后续生成内容的质量会有质变。
- 开启会员订阅：哪怕只定价 1 元，也能帮你筛选出真正的核心用户。
如果你是接项目/做产品的创业者
- 把 BuildingAI 当“底座” ：我们现在的标准交付流程是：用 BuildingAI 部署客户环境 -> 在应用市场安装基础应用 -> 按客户需求定制几个专属 MCP 插件。交付周期从 3 个月缩短到 2 周。
- 关注 MCP 插件生态：BuildingAI 的 MCP 协议正在成为事实标准，我们已经写了 3 个收费插件（SEO 检测、多语言翻译、竞品分析）上架到官方市场，每个月有稳定的被动收入。
- 私有化部署是加分项：很多客户明确要求“数据不出域”，BuildingAI 的全开源让我们能直接承诺这一点，这在竞标时是压倒性优势。
如果你是企业内部 IT 负责人
- BuildingAI 可以作为“AI 中台” ：我们帮一家制造业客户部署了 BuildingAI，各部门可以自行搭建客服助手、文档问答、生产排程等应用，IT 团队只需要维护底层算力和数据库。
- 数据隔离做得很好：企业版的组织管理模块，可以为不同部门分配独立的知识库和模型权限，数据互不可见，符合合规要求。
尾声：开源的价值
最后想说一个细节：我们之所以敢把整个写作平台跑在 BuildingAI 上，是因为它全开源。我们 fork 了代码到自己的 Git 仓库，所有核心依赖都可以审查，出了问题能自己修，不用担心厂商跑路或涨价。
上周，我们在 BuildingAI 的应用市场上线了第一个付费插件“多平台同步发布器”，定价 99 元/月，已经卖出去 7 份。这笔钱不多，但意味着我们从一个“用工具的人”，变成了“做工具的人”——而这一切，始于那个凌晨两点被逼疯的周末，和后来遇到的那个开源项目。
如果你也想试试，可以去 buildingai.cc 免费部署一份。反正开源，不花钱，万一能救你于“手动复制粘贴”的水火呢？
