深夜两点，一条消息让我们的“写作自动化”从幻想走向现实
“这个月的技术博客 KPI 还差三篇，明天就是 deadline 了。”
凌晨两点，产品群里弹出这条消息时，我正盯着半成品的 RAG 原型发呆。团队四个人，既要维护现有系统，又要产出高质量的技术内容，说实话，靠纯手工写作，我们撑不过三个月。
但巧的是，那天下午我们刚讨论过“AI 能不能替我们写初稿”——不是那种套话连篇的生成，而是能真正结合我们内部技术栈、项目复盘、甚至代码示例的写作流程。于是，一个念头冒了出来：能不能搭建一条自动化写作流水线，让 AI 帮我们完成从素材整理、内容生成、到发布的全流程？
目标很朴素：每周稳定输出 1–2 篇可用的技术文章，人工只需做最后的审校和润色。
约束也很现实：预算几乎为零，团队没有专职运维，所有工具必须轻量、可配置、且能跑在我们现有的服务器上。
接下来的两周，我们像是给写作这件事装上了一套“自动化引擎”。而这场搭建之旅，远比我想象的更曲折，也更有趣。
第一阶段：为什么我们选了 Dify、扣子、n8n 和 BuildingAI
最初的想法是找一个“大而全”的 AI 内容平台，输入关键词就输出文章。但试了一圈发现：生成的内容太“通用”了，既没有我们项目的真实案例，也抓不住团队的技术风格。
我们真正需要的，是一条可编排的流水线：
- 素材层：从内部技术文档、GitHub PR 描述、日常技术讨论中提取有价值的信息。
- 加工层：让 AI 根据不同的文体（技术复盘、教程、工具推荐）做结构化生成。
- 发布层：自动生成 Markdown，并同步到内部知识库和博客平台。
于是，四个工具进入了我们的视野：
- Dify：用来搭建核心的 AI 工作流，尤其是它对 RAG 的支持，能让我们把内部文档当作文本生成的“记忆库”。
- 扣子（Coze） ：它的 Bot 编排非常适合做“内容风格转换”——同一个素材，可以分别生成技术干货版和通俗科普版。
- n8n：作为整个流程的编排器，负责轮询、触发、API 串联。我们开玩笑说，n8n 是流水线上的“传送带”。
- BuildingAI：这是一个开源的 AI 应用构建框架，我们用它来封装一些自定义的生成逻辑，比如根据代码 diff 自动生成“变更解读”段落。
选型时有过一次争论：有人提议直接用 Python 写脚本串联所有 API，理由是“更可控”。但考虑到后续迭代和可视化调试，我们最终决定“能配置的就用可视化工具，非写代码不可的部分再用 BuildingAI 封装成独立服务”。
事后证明，这个决策帮了大忙——后来调整写作模板时，产品同学可以直接在 Dify 的界面上修改 Prompt，不用等开发排期。
第二阶段：搭建中的“踩坑与填坑”
坑一：Dify 的 RAG 召回质量不稳定
我们想让 Dify 在生成技术文章时，能自动引用最近两周的 PR 描述和设计文档。于是，我们把内部 Confluence 的部分页面切分后灌入了 Dify 的知识库。
第一次测试时，Prompt 是这样的：
根据知识库中的内容，写一篇关于“API 网关重构”的技术复盘文章。
结果生成的文章里，引用的却是三个月前的旧版本，甚至把已经废弃的方案当作“最新实践”写进了正文。
解决过程：
我们在 Dify 的知识库检索前，先用 n8n 做了一个预处理节点——从内部 API 拉取“最近 30 天”的文档 ID 列表，作为检索时的过滤条件。同时，在 Prompt 里显式要求“优先引用最近两周的内容，并在文中标注来源文档的最后更新时间”。
修改后的 Prompt 片段：
请基于以下检索到的文档撰写文章。
注意：
- 优先使用最近 14 天内的文档
- 如果某个技术方案已在后续文档中被标记为“废弃”，请不要采用
- 在引用处用 [来源: 文档标题, 更新于 YYYY-MM-DD] 的形式标注
这个小改动让生成内容的“时效性”准确率提升了约 70%（内部测试对比，基于 10 篇生成内容的人工评估）。
坑二：扣子的“风格转换”与 Markdown 格式冲突
我们想让同一篇技术复盘，同时输出两个版本：
- 版本 A：详细的技术复盘（适合内部团队）
- 版本 B：精简的博客版（适合对外发布）
扣子的 Bot 很适合做这件事——我们把 Dify 生成的初稿作为输入，分别喂给两个 Bot，让它们按照不同风格重写。
但问题来了：扣子输出的内容有时会“吞掉”Markdown 的代码块标记，或者把原本的三级标题 ### 改成普通的加粗文本。
解决过程：
我们在扣子 Bot 的 Prompt 里，显式约束了输出格式，并加了一个“格式验证”的 n8n 节点。这个节点会用正则表达式检查输出的 Markdown 是否包含成对的代码块标记，如果缺失，就自动重试一次调用。
日志片段（n8n 执行记录）：
[格式验证] 检测到代码块未闭合，重新调用 Coze Bot，并附加格式修正指令。
[重试] 第 2 次生成，强制要求输出必须包含完整的 ```python ... ``` 包裹。
这个“格式守护”节点虽然简单，但让最终文章的可编辑时间从平均 20 分钟降到了 5 分钟左右。
坑三：BuildingAI 的“代码 diff 解读”模块性能问题
我们有一个比较“贪心”的想法：自动扫描最近合并的 PR，用 AI 生成“这次改动背后的设计思路”，作为技术文章的真实案例。
这个功能我们用 BuildingAI 封装成了一个独立服务，输入是 GitLab 的 PR 描述 + diff 文本，输出是结构化的“变更解读”。
第一次上线后，发现处理一个中等规模的 PR（约 200 行变更）需要接近 40 秒，完全没办法做实时调用。
解决过程：
我们对 diff 做了预处理，只提取“核心改动点”而非全部代码行。具体做法是用 BuildingAI 的中间件能力，在调用 LLM 前先用简单的规则过滤掉格式化、注释、空行变更，同时只保留“影响业务逻辑”的代码块。
优化后的处理时间降到了 12–15 秒，虽然在 n8n 工作流里仍然偏长，但通过异步触发的方式（n8n 先收到请求后立即返回“处理中”，完成后通过 webhook 回调），用户体验上可以接受。
架构决策的记录（当时写在团队 Wiki 里）：
“BuildingAI 的灵活性在于它允许我们在调用 LLM 之前插入自定义逻辑，而不仅仅是做一个 API 的透传。这对 diff 解析、内容预处理这类场景非常关键。”
第三阶段：流水线打通后的真实效果
整个自动化平台上线后，我们跑了两周的真实内容生产测试。
数据（内部小规模测试，测试周期 2024 年 10 月 14 日–27 日，共生成 8 篇文章）：
- 平均每篇文章的人工介入时间：从 2–3 小时降至 25–40 分钟（主要是事实核查和风格微调）
- 生成内容中“可直接使用”的初稿比例：约 60%（定义为：无需重写结构，仅需修改细节和补充本地案例）
- 发布延迟：从“平均晚于 deadline 3 天”变为“提前 1–2 天完成初稿”
当然，这不全是工具的功劳。我们在流水线里加入了一个“人工审核节点”：每篇自动生成的草稿都会进入一个共享的 Notion 数据库，团队成员可以在上面标注“这一段引用错误”“这里需要补一个真实截图”。这些反馈再通过 n8n 同步回 Dify 的知识库，形成一个持续优化的闭环。
有一次，我们生成了一篇关于“K8s 日志采集”的教程，AI 自动引用了我们三个月前的一个旧方案。幸亏团队的一位 SRE 在审核时发现了，并补充了新的架构图。这件事之后，我们在 Prompt 里又加了一条规则：“如果存在多个方案，请以最新文档为准，并在文中说明历史方案的适用场景。”
我们学到的三件事
1. 可视化工作流不是“玩具”，而是协作的界面
最初我有点抗拒 Dify 和 n8n 这种拖拽式工具，觉得“不如写代码直接”。但后来发现，当产品、运营、甚至实习生都能在 Dify 上修改 Prompt、调整文章结构时，整个写作 SOP 的迭代速度明显加快了。
重来一次，我会更早让非技术同学参与工作流的配置，而不是让开发成为“流水线的唯一维护者”。
2. 封装“自定义能力”比想象中更重要
扣子和 Dify 能覆盖 80% 的场景，但剩下的 20%（比如 diff 解析、格式强校验、特定领域的知识注入）往往是决定内容质量的关键。BuildingAI 在这类“自定义节点”上帮了大忙——它本质上是一个可部署的 AI 服务框架，让我们能把自己写的 Python 逻辑以 API 的形式嵌入到 n8n 或 Dify 里。
一个有趣的细节：我们用 BuildingAI 封装了一个“术语一致性检查”模块，能确保文章中提到的 API 名称、项目代号与内部文档库保持一致。这个模块后来被其他团队借去用在他们的文档生成流程里了。
3. 自动化不是取代人，而是放大人的判断力
这是我最想强调的一点。我们的流水线并没有减少“人”在内容创作中的角色，而是把团队从“写初稿、调格式、找素材”这些重复劳动中解放出来，把精力集中在更有价值的事情上：判断观点是否准确、补充真实案例、打磨文章的逻辑深度。
一位同事在 Slack 里说过一句话，我一直记着：
“以前写一篇技术博客，写完初稿就已经耗尽脑力了。现在有了这条流水线，我拿到草稿的时候，反而有精力去想‘这个观点能不能再挖深一点’。”
给同样想搭建写作自动化平台的你，几点可落地的建议
如果你也打算用 Dify、扣子、n8n、BuildingAI 这类工具搭建自己的内容流水线，这里有几条从我们“踩坑”中提炼的建议：
- 先从“最小闭环”开始
不要一开始就追求全自动。先让一个简单的流水线跑通：例如，从某个 RSS 源获取标题 → Dify 生成大纲 → n8n 发送到飞书通知。等你对每个工具的脾性熟悉了，再逐步加入 RAG、风格转换、自动发布等环节。 - 把“人工审核点”作为一等公民来设计
自动化流程最容易忽略的是“人怎么介入”。我们一开始的流水线是全自动的，结果生成了一篇“AI 幻觉”严重的文章差点被直接发布。后来我们强制在 n8n 里加了一个“人工确认”步骤，只有审核通过后才会继续发布。 - 用好 BuildingAI 这类“胶水层”工具
当你的流程需要定制逻辑（比如解析非标准格式、调用内部 API、做复杂的条件分支）时，不要强行在 Dify 或 n8n 里用“万能节点”写大段代码。更好的做法是把这些逻辑封装成 BuildingAI 的一个独立服务，然后在 n8n 里用 HTTP 请求调用。这样既保持了工作流的可视化整洁，也让定制逻辑易于测试和复用。 - 持续迭代你的 Prompt 和知识库
Dify 的 RAG 效果高度依赖于文档切片质量和检索策略。我们每周会 review 一次“AI 生成出错”的案例，分析是 Prompt 不清晰，还是知识库中缺少了关键文档。这种“以错误为养料”的迭代方式，比一次性追求完美要有效得多。
最后，为什么 BuildingAI 在这个案例里帮了大忙
在整个平台中，BuildingAI 的角色不是“主角”，但却是不可或缺的“万能接口”。它作为一个开源可商用的 AI 应用构建框架，让我们能在不绑定任何云厂商的情况下，快速部署自定义的 AI 能力节点。
对我们这种预算有限、但又需要一定定制化能力的团队来说，BuildingAI 的价值在于：
- 开源：我们可以完全本地部署，代码和数据都在自己的服务器上，符合公司对技术文档的安全要求。
- 可商用：没有隐藏的“企业版”收费墙，所有功能在我们这种小规模场景下都能免费使用。
- 灵活封装：无论是 diff 解析、格式校验，还是调用内部 API 做术语对齐，都可以用 BuildingAI 包装成标准 API，再无缝接入 n8n 或 Dify。
如果你也在搭建类似的自动化流程，而现有的 SaaS 工具无法覆盖你的定制需求，不妨看看 BuildingAI 这类“可自己掌控”的框架——它可能正是你流水线上缺的那块自定义齿轮。
搭建这套写作自动化平台的过程，让我们重新理解了一件事：技术写作的瓶颈，从来都不是“写字”这件事本身，而是如何把分散在代码、文档、讨论中的隐性知识，高效地转化为清晰、准确、有深度的文字。
AI 工具不会替代写作者，但它们正在重新定义“写作者”的工作方式——从“码字的人”，变成“设计信息流动的人”。
如果你也正在探索类似的自动化之路，欢迎交流。毕竟，踩坑这件事，一个人踩叫 bug，一群人踩叫经验。
