1. 为什么我最终选了 n8n 而不是纯代码脚本
做内容运营的朋友大概率都动过一个念头：能不能让公众号发文这件事彻底自动化。选题、写稿、排版、群发，这一套流程走下来，熟练的人也要花上大半个小时，赶上多账号矩阵运营，一天光复制粘贴就能把人耗干。我最早是用 Python 脚本硬怼的，调接口、拼 HTML、处理素材上传，写是能写，但每次公众号后台改一点规则、或者想调整一下发布逻辑，就得回去翻代码，改完还要重新测一遍，维护成本高得离谱。后来接触到 n8n 这类可视化工作流工具，才算是找到了一个平衡点——既能灵活编排逻辑，又不用每次都跟代码死磕。
这篇内容就是把我从零搭这套「大模型生成内容 + n8n 编排 + 公众号自动发布」工作流的完整过程拆开讲。核心目标很明确：你给一个选题方向，工作流自动调用大模型写出文章、生成摘要、配好封面图，最后推到公众号草稿箱甚至直接群发。适合谁看？一是有一定动手能力、想把自己从重复劳动里解放出来的内容运营；二是对自动化工作流感兴趣、想找个真实场景练手的开发者；三是手里管着好几个号、想批量做内容分发的团队。哪怕你之前没碰过 n8n，跟着走也能搭起来。
先说清楚一个前提：公众号的发布能力，官方是通过接口开放给认证过的账号的，个人订阅号在权限上会有一些限制，这个在动手前要先确认自己账号的接口权限范围，别搭到一半发现调不通。另外，所有涉及自动发布的内容，最终建议都保留一道人工审核的关口，尤其是大模型生成的东西，直接无审核群发风险太大，这一点后面我会专门讲。
2. 动手前必须理清的三个底层概念
2.1 n8n 到底是个什么东西，和普通脚本差在哪
很多人第一次听说 n8n，会把它当成「另一个自动化工具」，跟那些定时任务、爬虫框架混为一谈。其实它的定位更接近「可视化编程环境」。你可以把每一个节点理解成一段功能代码，节点之间用连线传递数据，整条链路就是一个完整程序。它的数据流模型是基于 JSON 的，上一个节点吐出来的数据结构，下一个节点直接拿来用，中间还能插入条件判断、循环、错误处理。
和纯脚本比，它最大的优势在于「改逻辑不用改代码」。比如你原本是「大模型写完直接发」，后来想加一步「先过一遍敏感词检测」，在脚本里你得插函数、调顺序、重新测；在 n8n 里就是拖一个节点进来，连上线，完事。这种灵活性在需求频繁变动的场景下特别值钱。当然它也不是万能的，复杂的数据清洗、特殊的加密签名，还是得写代码节点来兜底，n8n 支持在流程里嵌入自定义代码，这点很关键。
2.2 大模型在这个工作流里承担哪几件事
别把大模型想成只是「写文章的」。在这套流程里，它其实身兼数职。第一是选题扩展，你给一个模糊的方向，让它生成几个具体的标题和切入角度；第二是正文生成，按你设定的风格、字数、结构把文章写出来；第三是摘要提炼，公众号发文需要一段摘要，让模型从正文里压缩出百来字；第四是格式转换，把模型输出的 Markdown 转成公众号能识别的富文本结构。
这里有个坑要提前说：大模型输出的格式是不稳定的。你让它输出 Markdown，它有时候给你加一堆没用的符号，有时候标题层级乱套。所以工作流里必须有一道「格式规整」的处理，不能指望模型每次都听话。我的做法是在提示词里把输出格式约束死，再在 n8n 里加一个代码节点做二次清洗，双保险。
2.3 公众号接口的调用门槛与限制
公众号的接口调用不是随便就能通的。你需要有认证的服务号或者订阅号，拿到对应的接口凭证，而且接口调用有频率限制，素材上传、草稿创建、群发这些操作各有各的配额。更关键的是，群发接口的调用次数非常有限，一旦用超，当天就没法再发。所以工作流设计上，我强烈建议默认只推到「草稿箱」，把群发这一步做成手动触发或者单独的低频流程。
还有一个容易被忽略的点：公众号对图文内容的格式要求比较特殊，它不认标准的 Markdown，需要转成特定的 HTML 结构，图片还得先上传到素材库拿到媒体 ID 再引用。这些转换工作，如果全靠手工，那自动化就失去意义了，所以工作流里必须把「Markdown 转公众号 HTML」和「图片上传换 ID」这两步做进去。
3. 环境搭建：从零把 n8n 跑起来
3.1 部署方式的选择与取舍
n8n 的部署方式有好几种，我挨个试过，说说各自的适用场景。最省事的是用官方的云服务，注册就能用，但数据都在别人服务器上，而且免费额度有限，跑量大了要付费。第二种是用容器方式自己部署，一条命令拉起来，数据在自己手里，适合对数据敏感或者想长期跑的人。第三种是直接装在一台常开的机器上，用进程管理工具守着。
我最后选的是容器部署，原因很简单：迁移方便、环境隔离干净、升级也就是换个镜像的事。下面是我实际用的启动命令，你可以直接抄：
docker run -d \ --name n8n \ --restart unless-stopped \ -p 5678:5678 \ -v n8n_data:/home/node/.n8n \ -e N8N_SECURE_COOKIE=false \ -e GENERIC_TIMEZONE="Asia/Shanghai" \ n8nio/n8n这里有几个参数值得说道。--restart unless-stopped保证机器重启后容器自动起来，不然你辛辛苦苦搭的流程一断电就没了。-v n8n_data:/home/node/.n8n是把数据卷挂出来，工作流配置、凭证都存这里，升级镜像不会丢。时区一定要设对，不然你按「每天早上八点发」设的定时任务，可能实际在下午才跑，这个坑我踩过。
3.2 首次进入后的基础配置
容器跑起来后，浏览器访问对应端口就能进 n8n 的界面。第一次进去会让你设置管理员账号，这个账号密码记牢，后面所有凭证管理都靠它。进去之后先别急着搭流程，有两件事要先做。
第一件是配置凭证。n8n 把敏感信息统一放在「Credentials」里管理，工作流节点引用凭证而不是直接写密钥。你需要提前准备好大模型服务的接口密钥和公众号的接口凭证，分别建好对应的凭证条目。这样做的好处是，工作流可以导出分享，但凭证不会跟着泄露。
第二件是熟悉节点面板。n8n 的节点分几大类：触发器类（定时、Webhook、手动）、数据处理类（编辑字段、合并、拆分）、应用集成类（各种第三方服务）、代码类（自定义脚本）。你不需要记住所有节点，但要知道去哪找。我建议先手动拖几个节点连一连，感受一下数据是怎么在节点之间流动的，点开每个节点的输入输出面板看看 JSON 长什么样，这个直觉建立起来之后，后面搭流程会快很多。
3.3 大模型接口的接入准备
大模型这块，n8n 内置了一些常见服务的节点，但如果你用的服务没有现成节点，用通用的 HTTP 请求节点也能调。核心就是三样东西：接口地址、认证方式、请求体格式。认证一般是在请求头里带一个密钥，请求体里放模型名称、消息内容、温度这些参数。
我建议单独建一个「测试工作流」，就放一个手动触发节点加一个 HTTP 请求节点，先把大模型调通，确认能拿到正常返回，再去搭主流程。这样出问题的时候好定位，是接口的问题还是流程逻辑的问题，一目了然。测试的时候把返回的完整 JSON 打印出来看，重点看正文内容在哪个字段里，后面提取的时候要用到。
4. 工作流核心链路拆解：从选题到草稿箱
4.1 触发方式的设计：手动、定时还是 Webhook
触发方式决定了整个工作流的「启动姿势」。我实际用下来，三种方式各有用途，最好是都留着，按场景切换。
手动触发适合调试和临时发文，点一下就跑，方便你盯着每一步的输出看。定时触发适合规律性内容，比如每天固定时间生成一篇行业资讯汇总。Webhook 触发适合跟其他系统联动，比如你在表格里填一个选题，表格那边一提交就触发工作流。我自己的主力流程用的是手动触发加一个表单触发，表单里填选题方向和风格要求，提交后自动跑。
这里有个设计上的小心思：把「选题」作为输入参数传进来，而不是写死在流程里。这样同一条工作流可以反复用，今天写科技、明天写生活，只要改输入就行，不用动流程结构。
4.2 用大模型生成正文的提示词工程
这一步是整个工作流的灵魂，提示词写得好不好，直接决定产出能不能用。我踩了无数坑之后，总结出一个相对稳定的提示词结构，分四块：角色设定、任务描述、格式约束、示例参考。
角色设定是告诉模型「你是谁」，比如「你是一名有十年经验的内容编辑，擅长写通俗易懂的科普文章」。任务描述说清楚要写什么、给谁看、大概多长。格式约束是最关键的，要明确要求输出 Markdown，标题用几级、段落怎么分、要不要小标题，都写死。示例参考是给一小段你满意的文风样例，让模型模仿。
我实际用的提示词大概长这样：
你是一名资深内容编辑，请根据以下选题写一篇公众号文章。 选题方向：{{ $json.topic }} 目标读者：对科技感兴趣的普通上班族 文章长度：1500字左右 写作风格：口语化、有干货、避免空话套话 格式要求： 1. 使用 Markdown 格式 2. 一级标题用 ##，二级标题用 ### 3. 每段不超过 5 行 4. 结尾不要写总结性套话 请直接输出文章正文，不要有任何额外说明。注意最后那句「不要有任何额外说明」，不加这句，模型经常会在正文前后加一段「好的，以下是我为您写的文章」之类的废话，处理起来很烦。
4.3 摘要与封面的自动生成
正文出来之后，摘要和封面也得跟上。摘要相对简单，把正文再喂给模型一次，让它压缩成一百字以内的概述。提示词里要强调「提炼核心观点，不要简单截取开头」。
封面稍微麻烦点。如果你的大模型服务支持图像生成，可以直接调；如果不支持，有两个替代方案：一是用固定的模板图加文字叠加，二是从无版权图库里按关键词搜一张。我常用的是模板图方案，因为风格统一，而且不依赖额外的图像生成服务。具体做法是准备一张底图，用图像处理节点把标题文字叠上去，生成一张新图。n8n 里有图像处理的节点，或者用代码节点调图像库也行。
封面图的尺寸要注意，公众号首图推荐的比例是特定的，做之前查一下当前的要求，别做出来被裁得乱七八糟。
4.4 Markdown 转公众号可识别格式的处理
这是最容易被低估的一步。公众号后台的编辑器不认 Markdown，你直接把 Markdown 文本贴进去，它就是一坨带符号的纯文本。所以必须转成 HTML，而且是有特定样式要求的 HTML。
转换的思路是：把 Markdown 的语法元素逐个映射成带内联样式的 HTML 标签。标题映射成带字号和加粗的段落，列表映射成带缩进的段落，加粗映射成 strong 标签。为什么要用内联样式而不是 class？因为公众号会过滤掉大部分外部样式表，只有写在标签上的内联样式才生效。
我是在代码节点里用一个 Markdown 解析库做转换，然后手动补上内联样式。转换完的 HTML 先别急着推，在本地浏览器里打开看一眼渲染效果，确认没问题再往下走。这一步多花五分钟，能省掉后面反复调试的半小时。
5. 公众号接口对接的实操细节
5.1 接口凭证的获取与刷新机制
公众号接口调用需要一个有时效性的访问凭证，这个凭证不是永久有效的，过期了要重新获取。所以工作流里必须有一个「获取凭证」的步骤，而且要考虑缓存，不能每次调用都去重新获取，那样既慢又容易触发频率限制。
我的做法是在流程开头先检查缓存里有没有有效的凭证，有就直接用，没有就去获取并写入缓存，同时记录过期时间。n8n 里可以用工作流的静态数据或者外部的存储节点来做这个缓存。凭证的获取接口本身也有频率限制，所以缓存策略很重要，一般凭证有效期是两小时，我设置成提前十分钟刷新，避免边界情况。
5.2 素材上传与媒体 ID 的替换逻辑
公众号文章里的图片，不能直接用外部链接，必须先把图片上传到公众号的素材库，拿到一个媒体 ID，然后在 HTML 里用这个 ID 来引用。所以工作流里要加一步：把封面图和正文里的图片逐个上传，拿到 ID 后替换掉 HTML 里的原始图片地址。
这里有个细节：正文里的图片如果是大模型生成的或者从图库拿的，得先确保图片格式和大小符合要求，太大的图上传会失败。我一般会在上传前加一道压缩处理，把图片控制在合理范围内。上传接口返回的媒体 ID 要仔细对应，别张冠李戴，尤其是正文里有多张图的时候，替换错了就闹笑话了。
5.3 创建草稿与群发的区别对待
前面反复强调过，默认只创建草稿，不直接群发。创建草稿的接口调用相对宽松，失败了重试也没太大代价。群发接口就不一样了，调用次数极其有限，而且一旦发出就收不回来。
我的工作流设计是：主流程跑到「创建草稿」就结束，然后给我发一个通知，告诉我草稿已经准备好了。我人工去后台看一眼，确认没问题，再手动点群发。如果确实想自动化群发，那就单独做一条低频的流程，比如每天只跑一次，而且加一个「内容审核通过」的前置条件，审核没过就不发。
提示：群发接口的调用配额是按账号算的，多账号运营的时候要分别统计，别用一个账号的配额去估算所有账号。
6. 实测中踩过的坑与排查思路
6.1 大模型输出格式飘忽不定怎么治
这是最高频的问题。同样的提示词，今天输出规规矩矩，明天就给你加一堆乱七八糟的符号。根本原因是模型本身有随机性，温度参数越高越明显。治理办法分三层：第一层是把温度调低，牺牲一点创造性换稳定性；第二层是在提示词里把格式要求写到极致，甚至给出正反例；第三层是在流程里加一道格式校验，不符合要求的直接打回重生成。
我实际用的是「低温度 + 严格提示词 + 代码节点清洗」的组合。代码节点里用正则把多余的符号去掉，把不规范的标题层级修正过来。这一步不能省，省了后面转换 HTML 的时候全是错。
6.2 接口调用频率超限的应对
频率超限的报错通常很明确，会告诉你哪个接口超了。遇到这种情况，第一反应不应该是加大重试，而是检查是不是有重复调用。我遇到过因为流程里有两个节点都在获取凭证，导致凭证接口被调爆的情况。排查方法是在每个接口调用节点后面加日志，把调用时间戳打出来，一看就知道是不是有并发或者重复。
如果确实是正常调用量就超了，那就得做限流。n8n 里可以用等待节点在调用之间插入延迟，或者用队列的方式把请求排开。别硬刚频率限制，账号被限了得不偿失。
6.3 图片上传失败的几种典型原因
图片上传失败，八成是这三个原因：格式不对、体积超标、网络超时。格式方面，公众号支持的图片类型是有限的，转换的时候要确保输出的是支持的格式。体积方面，超过限制的图要先压缩。网络超时的话，加个重试机制，但重试次数别太多，三次够了。
排查的时候，先把失败的图片单独拿出来，手动上传试试，能传上去说明是流程问题，传不上去说明是图片本身的问题。这个二分法能快速缩小范围。
6.4 中文编码与特殊字符的乱码问题
中文乱码这个坑很隐蔽，有时候流程跑通了，但发出来的文章里中文变成问号或者方块。根源通常是编码没统一。从大模型返回的数据、到代码节点处理、再到接口请求，每一环都要确保用 UTF-8。尤其是在构造请求体的时候，要显式声明编码，别依赖默认值。
特殊字符也容易出问题，比如引号、破折号这些，在 JSON 里需要转义。我的做法是在代码节点里统一做一次转义处理，把所有可能引起问题的字符处理掉，再往下传。
7. 让工作流更耐用的几个进阶思路
7.1 把提示词和配置外置成变量
流程搭好之后，你会发现提示词经常要调，风格要改，字数要变。如果每次都进节点里改，很麻烦，而且容易改错。更好的做法是把这些可变的部分抽出来，做成工作流级别的变量或者存在外部配置里。n8n 支持设置环境变量，也可以用一个配置节点统一管理。这样调整的时候只动一处，所有引用它的地方自动生效。
7.2 加一层内容质量的自检
大模型生成的内容，质量是波动的。与其每次都人工从头审，不如让工作流先做一轮自检。自检可以包括：字数是否达标、有没有明显的重复段落、敏感词检测、标题和正文是否匹配。自检不过的，要么打回重生成，要么标记出来重点提示。这一层能挡掉大部分明显不合格的产出，减轻人工审核的负担。
7.3 错误处理与通知机制
工作流跑起来之后，最怕的是它悄悄失败了你还不知道。所以错误处理必须做。n8n 有专门的错误触发节点，可以捕获流程中的异常，然后通过邮件、消息等方式通知你。通知内容里要带上失败的是哪一步、错误信息是什么、当时的输入数据是什么，这样你排查的时候不用去翻日志。
我还会在流程正常结束的时候也发一个通知，告诉我草稿已经生成好了，附上草稿的标识。这样不管成功失败，我都心里有数。
7.4 多账号矩阵的扩展方式
如果你管着多个公众号，不需要为每个号复制一套工作流。把账号相关的信息（凭证、账号标识）做成参数，工作流里根据参数去取对应的凭证，就能一套流程服务多个账号。触发的时候指定是哪个号，流程自动走对应的凭证和配置。这样维护成本大大降低，加一个新号也就是加一条配置的事。
不过要注意，多账号的接口配额是分开算的，别让一个号把配额用完了影响其他号。可以在流程里加一个配额检查，快超限的时候提前告警。
8. 关于自动化发布这件事我的一点真实体会
搭这套工作流前后折腾了大概两周，中间推翻重来了好几次。最大的感受是，自动化不是目的，把人从重复劳动里解放出来、把精力放到真正需要判断的地方，才是目的。大模型能帮你把初稿写出来，但选题的判断、内容的把关、时机的选择，这些还是得人来。我现在的用法是，工作流负责把 80% 的机械工作干掉，我负责那 20% 的关键决策，整体效率比纯手工高了不止一倍。
还有一个体会是，别追求一步到位。我一开始想做一个全自动、无人值守的流程，结果处处是坑，反而卡住了。后来改成「半自动」，工作流跑到草稿箱，人工确认后再发，一下子就顺了。等这套跑稳了，再逐步把一些环节自动化，比如自检、通知、多账号分发。循序渐进比一步登天靠谱得多。
最后分享一个小技巧：把你调试过程中遇到的每一个报错和解决办法都记下来，形成一个自己的「坑库」。n8n 这类工具的报错信息有时候比较笼统，同样一个报错可能是好几种原因，有了自己的坑库，下次遇到类似问题能秒定位。这个习惯我坚持了很久，受益无穷。
