用n8n自动将博客文章转为X推文与领英帖子

为什么要让博客内容自动「一稿多发」

内容创作者和营销团队常面临同一个痛点：写完一篇博客后，还要手动把它改写成适合 X（原 Twitter）的推文串、领英的职业化帖子，重复劳动既耗时又容易拖延分发节奏。借助自动化工具 n8n，可以把「抓取文章 → 调用大模型改写 → 生成多平台文案」这条链路串起来，让每一篇博客自动产出配套的社交媒体内容。

这段来自 YouTube 的教程演示了其中的核心环节：如何在 n8n 中配置一个 HTTP 请求节点，把文章正文发送给 Gemini API，并让模型按照不同平台的调性写出帖子。

核心节点：Write the Posts

整个流程的关键节点被命名为 Write the Posts。它本质上是一个 HTTP 请求节点，职责很明确——把前序节点提取出的文章文本发送给 Gemini API，并下达「帮我写社交媒体帖子」的指令。

配置时的第一步是重命名节点。清晰的节点命名在 n8n 这类可视化工作流中非常重要，当流程变长、节点变多时，一个描述性的名字能让你一眼看懂每一步在做什么，也便于后期维护和排错。

关键配置：HTTP 方法与请求端点

在 Write the Posts 节点的参数里，有两个设置决定了请求能否成功。

HTTP 方法设为 POST

因为你是在向 Gemini API 发送数据（也就是文章正文），所以 HTTP 方法必须设为 POST，而不是用于读取的 GET。这是 REST API 调用的基本规则：提交内容用 POST。

REST API 中，HTTP 方法的选择遵循语义约定：GET 用于从服务器读取资源，不携带请求体；POST 用于向服务器提交数据，数据放在请求体（request body）中传输。调用大语言模型 API 时，你需要把文章文本、系统提示词（system prompt）、模型名称等参数打包进 JSON 请求体一起发送，这天然属于「提交数据」的语义，因此必须用 POST。如果误用 GET，请求体会被忽略，API 将无法接收到文章内容，调用会失败或返回空结果。

使用 OpenAI 兼容端点

请求 URL 需要填 Gemini 提供的 OpenAI 兼容的 chat completions 端点。这是教程中一个值得关注的技术细节：Gemini 对外暴露了一个与 OpenAI 格式兼容的接口，意味着同样的请求结构（request shape）可以直接套用到其他 OpenAI 兼容的服务商上。

这种兼容性带来的实际价值在于灵活切换：你今天用 Gemini，明天想换成其他兼容 OpenAI 协议的模型，只需改动端点 URL 和密钥，而不必重写整个节点的请求体。对于希望降低供应商锁定风险、或想对比不同模型输出效果的用户来说，这是一个相当实用的设计。

所谓「OpenAI 兼容端点」，指的是第三方 AI 服务商按照 OpenAI 的 Chat Completions API 规范（即 /v1/chat/completions 路径与对应的 JSON 请求/响应结构）对外提供接口。OpenAI 的这套接口格式事实上已成为行业标准：请求体包含 model、messages 等字段，响应体则在 choices[0].message.content 中返回生成文本。Google Gemini、Groq、Together AI、Mistral 等服务商均提供了兼容这一格式的端点，目的是让已有 OpenAI 集成代码的用户可以零改造或极低成本地切换底层模型。在 n8n 这类工作流工具里，这意味着你只需维护一套 HTTP 节点配置模板，通过替换 base_url 和 API Key 即可在不同模型供应商之间自由切换，大幅降低了迁移成本和供应商锁定风险。

这套思路能延伸到哪里

虽然这段素材聚焦在单个节点的配置，但它背后反映的是一类通用的自动化模式：抓取 → 处理 → 分发。只要掌握了「用 HTTP 节点调用大模型」这一招，你可以把它套用到大量场景——比如把播客文字稿改写成邮件简报、把产品更新日志转成多语言公告、或者给电商商品描述批量生成不同风格的营销文案。

搭建这类工作流时，有几点经验值得记住：节点命名要清晰；明确区分 POST（提交）和 GET（读取）；优先选用 OpenAI 兼容端点以保留切换空间。把这些基础打好，剩下的无非是针对不同平台调整提示词（Prompt），让 X 的推文更简短抓眼球、领英的帖子更专业有条理。

小结

这段教程展示的只是完整工作流的一个片段，但它点出了用 n8n 做内容自动化的几个要害：以 HTTP 请求节点为桥梁对接大模型、正确设置请求方法、善用 OpenAI 兼容端点。对于想减少重复内容搬运、提升分发效率的创作者而言，这是一条值得动手实践的路径。