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_COOKIEfalse \ -e GENERIC_TIMEZONEAsia/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 这类工具的报错信息有时候比较笼统同样一个报错可能是好几种原因有了自己的坑库下次遇到类似问题能秒定位。这个习惯我坚持了很久受益无穷。
