上个月我在整理手机相册的时候发现，自己拍的美食图少说也有两三百张，真正发成小红书笔记的却不到十分之一。不是不想发，是每次做手账都太折磨人。打开设计工具、挑模板、调字体、费劲想文案、再一张张手动排版，快的时候二十多分钟出一张，遇到灵感卡壳，一个晚上都耗在上面。后来我搭了一条用 n8n 和 Claude Skills 驱动的自动化流水线，把“选图、写文案、排版、出图”整条链路串在一起，现在点一下触发按钮，三分钟之内就能拿到一张可以直接发的小红书热门美食手账图，而且整个过程不需要写太多代码，小白照着配也能跑起来。

这篇文章就完整拆解一下我做这件事的思路、工具选型的理由、每一步怎么落地，以及跑了一段时间之后踩到的坑。如果你也在做美食类内容，或者运营小红书账号被日更逼得头大，这套流程可以直接参考或复刻。

1. 先想清楚再动手：把一份手账拆成可自动化的小环节

1.1 一份美食手账到底包含哪些元素

很多人一听“自动化做手账”就觉得不靠谱，觉得手账这东西靠的是审美和创意，机器怎么做得出来。但其实拆开看，一张美食手账的组成元素是非常固定的，尤其在小红书这个平台上，受欢迎的手账基本都有相似的骨架。

我平时发的内容一般包含五个部分：封面图、标题文案、正文要点、标签列表和统一的版面风格。封面图是美食照片加上文字叠加，负责第一眼的吸引力；标题文案要能勾起人对“好吃”“好做”“好看”的欲望；正文要点通常是食材清单、步骤简述、口感评价；标签则是给自己导流的入口，像美食教程、探店打卡、一人食这类；版面风格则是把字体、配色、边框、贴纸固定成一套视觉模板。

这五个元素里，真正需要“人”去判断和发挥创意的，其实只有文案调性和风格审美。剩下的选图、套模板、生成标签、调整排版，都是高度重复的体力活。既然有重复，就有自动化的空间。我的思路就是不跟自己的审美较劲，把体力活的环节全部交给工具，把创意环节保留给人工。

1.2 哪些环节值得自动化、哪些需要人把关

我做自动化之前先列了一个表，把流程细分到不能再细，然后逐项判断是“值得自动化”还是“需要人看”。

我先说值得自动化的部分。第一是图片整理和预选，这个特别适合写规则，比如按菜品分类、按拍摄日期归档，再按文件名里的关键词去匹配对应主题。第二是文案初稿生成，这个就是大模型最擅长的活儿，给它提供图片、食材信息和风格参考，它能产出好几个版本的标题和正文。第三是标签推荐，这个也适合让AI来做，它会结合当前的热门词汇和内容主题去生成一批备选标签。最后是版面渲染，一旦确定了HTML模板或者设计模板，把文案填进去、生成图片，这一步可以完全自动化。

需要人把关的部分，我说实话，只有最终审核。AI生成的文案有时候会说出“入口即化”这种万金油表达，但偶尔也会脑洞开得太大，弄出不符合实际的描述。图片排版也可能出现文字压脸、底色调性不搭的情况。所以我保留了“人审”这一步，流程跑完、图片输出之后，我只看一眼，能用就发，不能用就重跑一次，代价很低。

1.3 整套流程的运转蓝图

从流程图上看，这套系统不复杂。触发方式我做了两个入口：一个是定时触发，适合每天固定时间批量出图；另一个是手动触发，用Webhook就可以，我人在外面用手机也能远程跑一次。触发之后，工作流先根据预设的规则从素材库里选图，再把图片和素材信息一起丢给Claude接口，让AI生成文案和标签。拿到结构化结果后，工作流把文案填进提前写好的HTML模板里，调用无头浏览器截图，渲染成品图，最后落到本地文件夹或者网盘。

整个链路里，n8n负责的是“编排”和“跑腿”，它把各个节点串起来，处理数据流转和异常重试；Claude Skills负责的是“动脑”，理解图片内容、生成有网感的文案、给出合适的标签。这两者分工明确，各干各的，就不容易出现“一个工具什么都干但什么都干不精”的问题。

2. 工具选型：为什么是 n8n + Claude Skills 这对组合

2.1 n8n：一个能让各种服务“手拉手”的自动化引擎

如果你用过那种智能家居App，把灯泡、摄像头、空调连接起来做场景联动，那你理解n8n就完全没有障碍。n8n就是做自动化工作流的可视化工具，它把一个一个的服务节点拖到画布上，用连线把它们串起来，数据就沿着连线一路往下流。谁先执行、谁后执行、什么条件下执行某个分支，都一目了然。

我选n8n而不是别的工具，有几个实际原因。第一，它是开源并且可以自托管的，这意味着我自己的数据不需要经过第三方平台，素材图片、密钥信息都留在我自己的服务器上。第二，它内置了大量常用服务的节点，像HTTP请求、数据库读写、文件操作、消息通知都有，而且还有一个“代码节点”，允许我在流程中间插入一段JavaScript去做自定义的数据处理，灵活性非常高。第三，它支持定时触发和Webhook触发，既能做到每天自动跑，也能做到随时手动跑。

对我这种有轻度“掌控欲”的人来说，n8n最打动我的一点是，它能让我看到每一个环节的输入和输出。每次执行完，每个节点都会留下详细的数据记录，哪一步出了问题一眼就能定位。这种“可观测性”在做内容生产流水线时太重要了，尤其是AI接口偶尔抽风的时候。

2.2 Claude Skills：把AI能力变成工作流里的一个通用节点

标题里提到了Claude Skills，这里我先说一下我的理解。对于内容创作场景，Skills意味着把Claude的文本生成、图像理解这些能力，封装成一套可以反复调用的技能口径。放在n8n里表达，就是我用一个HTTP请求节点去调用Claude接口，通过固定设计好的系统提示词，让模型稳定输出符合小红书调性的文案。

我之所以选择Claude来接“动脑”这摊活儿，核心原因是它对图片的理解能力比较扎实。我给它一张美食照片，它能看出这是麻辣香锅还是寿司拼盘，也能识别出菜品的主要食材和大致做法，这些信息是生成高质量文案的基础。除了图片理解，它在中文文本表达上的自然度和多样性也让我满意。你让它写标题，它不会每次都写“好吃到哭”，它会根据图片内容去变换表达方式，这一点对减少内容同质化非常重要。

在实际的n8n流程里，这个技能的落法就是一个标准的API调用。我用一个HTTP Request节点，把图片转成base64格式，连同预设的提示词一起发给Claude接口，然后把返回结果解析成结构化数据。整个过程在n8n里架起来只花了一个节点，但在效果上，等于我的工作流里多了一个会看图的文案编辑。

2.3 备选方案和我的取舍思考

在做这套流程之前，我也认真考虑过其他方案。

第一是纯手工用设计工具做。这个方案的优点是审美可控，缺点是时间和精力成本太高，而且一旦素材量大了，重复劳动的厌烦感会直线上升。第二是用现成的图文设计模板App，这类工具的模板确实好看，但样式基本固定，可编程性很差，没法做到按食材自动换文案、按热点换风格。第三是直接用Python写脚本调接口出图，这个方案的自动化程度最高，但需要你有一定的编程基础，而且维护起来不轻松，改一个像素都要翻代码。

我把方案对比做成了一张表，方便你直观参考：

最终我选了n8n加Claude的组合，理由是它在“自动化程度”“学习门槛”“可维护性”三者之间取得了平衡。n8n的可视化编排让我不用从零写代码，HTTP接口的开放性又保留了极大的自由度，Claude提供的内容生成能力则是这个方案的点睛之笔。如果将来我想增加一个新的平台分发，只需要在这个工作流后面再接一个节点，不用推翻重来。

3. 手把手搭建：从空白的n8n到3分钟出图

3.1 准备阶段：环境、素材和必要的密钥

搭这套流程之前，我先把准备工作做足了，不然中途缺东西很容易卡住。

第一步是部署n8n。如果你有服务器或者电脑上装了Docker，直接用docker运行镜像就可以，几十秒就能启动。没有服务器的话，在本地跑也能玩，只是没法做到随时远程触发。我自己是买了一台基础配置的云主机部署的，跑这套流程绰绰有余，资源占用并不高。

第二步是准备好API密钥。这里说的API密钥指的是调用Claude接口所需的身份凭证，我在n8n的凭证管理里把它配置好，流程里调用HTTP节点时直接引用，避免把密钥写死在请求里。密钥这东西一定要放在安全的地方，平时不要泄露到公共仓库或聊天群里。

第三步是建立素材库。我把手机里的美食照片全部导出到了服务器的一个目录里，按“菜品种类-拍摄日期-序号”的格式命名。比如“麻辣香锅-20240610-01.jpg”。这个命名规则在后面自动选图的时候非常关键，它等于给图片打了一个简单的标签，让工作流能通过文件名去判断这张图适不适合某个主题。

第四步是准备一个素材信息表。我用的是一张简单的表格文件，里面记录每张图片的文件名、菜品种类、主要食材和一句简短的口味描述。这个表的作用是给Claude提供上下文，让AI生成文案时不是对着空气瞎写，而是真的知道这张图里是什么菜、用了哪些材料。我试过不填充这个表单直接生成，效果明显要散很多。

3.2 搭建触发节点和素材读取

准备工作做完，就正式进入n8n画布。我先放两个触发节点：一个Schedule Trigger用来定时跑，一个Webhook用来手动跑。这两个节点我做了并联处理，谁的信号先到，流程就先启动。

接下来是素材读取节点。我用的是一个读取文件夹内容的节点，让它去扫描我素材库的目录，拿到符合条件的图片文件名列表。为了让流程只处理我想要的图片，我加了一个IF节点，根据文件名里的菜品种类关键词做过滤。比如我今天想做一篇“甜品”主题的手账，我就在手动触发时传入一个“甜品”参数，工作流只挑文件名里包含“甜品”的图片。

这一步在理解上有点绕的地方是：n8n默认会把文件夹里的每一条数据作为独立的条目往下游传，后面每个节点会针对每一条数据分别处理。这其实就是批量处理的来源，它天然适合一次给多张图片生成多张手账的场景。我一开始没意识到这一点，导致有段时间总是只处理第一张图，后来看了执行日志才明白，问题出在数据串联方式上，调整之后就好了。

3.3 接入Claude生成手账文案

这是整套流程里最核心的环节。我用一个HTTP Request节点，向Claude的接口发送请求，请求体重包含图片的base64编码和系统提示词。

先看系统提示词的设计。这个提示词我迭代了非常多版，最初写得很啰嗦，比如“你是一个资深的社交媒体运营专家，请根据图片内容生成一篇符合小红书风格的美食手账文案，要求语言生动有趣，并且要适当使用表情符号”。跑出来的效果非常“AI味”，全是套话。后来我改成了更具体的表述：

你是小红书美食手账编辑。请根据图片和素材信息输出JSON，格式如下： {"title":"不超过15字的吸引眼球的标题","content":"60到100字的正文，包含食材、口感、简单做法，语气真实自然","tags":["标签1","标签2","标签3","标签4"]} 要求：不要使用“绝绝子”“yyds”这类烂大街表达，尽量基于图片中真实可见的菜品特征去写。

我总结下来，提示词要明确给出输出格式，这是最关键的一点。让AI返回结构化JSON，后续处理起来会非常方便。另外要求里明确“不要使用什么”往往比“要求使用什么”效果更好，因为AI对禁止性描述的遵循度相当高。

接下来是请求体里图片的部分。在n8n里，图片数据需要先转换成base64字符串，这个用代码节点就可以完成。然后我把图片的媒体类型、base64数据和素材信息一起放进请求中。实际请求体大致是这样：

{ "model": "claude-sonnet", "max_tokens": 900, "temperature": 0.8, "system": "你是小红书美食手账编辑……", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "菜品：麻辣香锅，主要食材：午餐肉、虾、藕片、土豆片……" }, { "type": "image", "source": { "type": "base64", "media_type": "image/jpeg", "data": "此处为base64数据" } } ] } ] }

在参数选择上，max_tokens我设置在800到900之间，避免文案生成长度不够；temperature设置在0.8，这个值会让文案保持一定创造性的同时不至于跑偏。跑完之后，我在返回结果里用代码节点解析出JSON，把标题、正文、标签分别提取出来，传给下游的渲染环节。

3.4 排版渲染与出图

文案有了，图片是不是就已经算“做好”了？还差最后一步：把文案和图片拼成一张完整的手账图。这里我采用的是“HTML模板 + 无头浏览器截图”的思路。

所谓HTML模板，就是提前把一张手账的版式用HTML和CSS写死，把需要变化的文字部分用占位符预留出来。n8n流程跑到渲染这一步时，会把Claude生成的标题、正文、标签填入模板，再把模板转换成图片。

我这里给你看一个简化版的模板样例：

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <style> body { width: 1242px; height: 1656px; margin: 0; font-family: "Noto Serif SC", serif; } .cover { position: relative; width: 100%; height: 100%; } .cover img { width: 100%; height: 100%; object-fit: cover; } .mask { position: absolute; bottom: 0; width: 100%; background: linear-gradient(transparent, rgba(0,0,0,0.6)); padding: 100px 60px 60px; box-sizing: border-box; } .title { color: #fff; font-size: 72px; font-weight: bold; margin-bottom: 24px; } .content { color: #fff; font-size: 34px; line-height: 1.6; } .tags { margin-top: 30px; color: #f7e3b2; font-size: 28px; } </style> </head> <body> <div class="cover"> <img src="{图片地址}" alt=""> <div class="mask"> <div class="title">{标题}</div> <div class="content">{正文}</div> <div class="tags">{标签列表}</div> </div> </div> </body> </html>

选1242×1656这个尺寸，是因为小红书笔记封面主图比例是3:4，这个分辨率发布出来清晰度够高。文字字号我特意放大，因为手机端刷小红书时，图片会被压缩得很小，字号小了根本看不清。

模板写好之后，在n8n里用一个代码节点或者专用的截图节点去渲染。把HTML字符串和图片地址传进去，等待截图服务返回一张PNG图片，最后用文件输出节点把图片保存到指定目录，这一步就完成了。

3.5 串联全流程并做一次完整验证

所有节点都搭好之后，我先不急着批量跑，而是每次只处理一张图，做单条链路验证。我从素材库里挑了一张甜品照片，手动触发流程，盯着n8n的执行界面一步一步往下看：触发节点正常、素材读取正常、Claude接口返回了JSON、渲染节点生成了图片、文件保存成功。

第一次跑通的时候，流程花了差不多七分钟，主要耗在等待接口返回上。但那是第一次，之后我把涉及图片base64转换和模板生成的代码节点都做了优化，同时对整个流程做了预热，后续再跑，单张图基本稳定在3分钟以内。如果是定时批量跑十张图，时间会长一些，但全程不需要人盯着，跑完直接去文件夹收图就行。

4. 运行一段时间后，我踩过的坑和优化思路

4.1 API调用不稳定：超时、限流、返回格式变化

这套流程上线之后，我遇到的第一大类问题集中在接口调用上。最典型的是超时，有时候碰上接口响应慢，HTTP节点默认等待时间不够，流程直接报错中断。解决办法是给HTTP节点设置更长的超时时间，同时开启重试机制，遇到网络抖动或临时的服务繁忙，让它自动重试两三次。

第二是返回格式不稳定。虽然提示词里明确要求输出JSON，但偶尔Claude返回的内容里还是带了一些额外的解释文字，比如“好的，根据您的请求，我生成如下内容”。这会导致JSON解析失败。我的解决方案是在代码节点里做一层清洗，先用正则把返回内容中类似JSON的部分截取出来，再尝试解析，解析失败就发一条消息通知我，把原始返回记录下来。这相当于给流程加了一层保护，不让一次异常影响整批任务的执行。

第三是并发限流。我一开始图省事，手动触发时一次传了几十张图给接口，结果触发了限流规则，大量请求失败。后来我把流程改成逐条处理，也就是每次请求只处理一张图片，并且在上一条请求完成后稍作等待再发起下一条，从此再没出过问题。

4.2 图片排版变形和文字溢出

文案生成和图片渲染是两套系统，这就带来了一个天然问题：AI生成的文案长度不可控，而排版版式的空间是固定的。

我遇到过几次比较尴尬的情况。第一次是正文内容超出模板预留区域，文字直接跑到了图片下方，被截断了。第二次是标题过长，四十多个字挤在七十二号字体里，直接换行了，整个手账的视觉重心完全垮掉。第三次是遇到的图片本身是竖构图，但模板默认居中裁剪，导致菜品主体被切掉了一半。

针对这些问题，我做了几项调整。第一，在提示词里增加更明确的字数约束，比如标题不超过15个字、正文控制在60到100字之间，从源头上控制长度。第二，在渲染代码里加入长度判断，如果标题或正文太长，自动缩小字号。第三，在模板里给图片设置object-fit: cover并允许调整裁切位置，避免主体被切出画面。

4.3 内容风格太单一，缺少爆款感

自动化跑久了会遇到一个很隐蔽的问题：内容越来越“平”。不是因为哪一步配置错了，而是因为模板固定、提示词固定，AI生成的文案和版式风格也会逐渐趋同。用户刷到你的手账，第一眼觉得好看，第二眼觉得“怎么和昨天那张差不多”，关注欲望就会下降。

我的对策是给流程加入“不确定性”。提示词里我会随机切换到几种不同的写作视角：有时是探店式文案，突出“我在哪吃到、点什么不踩雷”；有时是教程式文案，强调“三步搞定、厨房小白也能做”；有时是情绪式文案，聚焦“下班后来一碗的满足感”。在模板方面，我也准备了三套风格不同的版式，按照日期奇偶轮换，或者按菜品种类匹配，避免用户审美疲劳。

还有一个小心得是，千万不要只依赖AI生成的初稿。我会定期从生成结果里挑出效果好的，把它们的标题清新度和正文结构记录下来，再补充到提示词里作为风格参考。这等于你自己变成了AI的“审美教练”，它越了解你喜欢什么，就越容易产出你想要的东西。

4.4 我把这套流程升级到了什么程度

基础版跑顺之后，我又做了一个比较大的升级：把“生成手账”这件事从单张处理变成了一个完整的“内容生产线”。

我在流程前端加了一个数据表管理，记录每张图片的使用状态、计划发布日期、发布渠道。每次流程运行前，先读取数据表，筛出“待处理”的图片，处理成功后自动把状态改成“已生成”，并写入生成时间和文件地址。这样一来，我每天只需要看一眼表格，就知道哪些内容已经在生产队列里了。

另外，我也接了一个定时发布任务的节点，把生成好的图片和文案按计划推送到内容发布接口。不过这里我建议你不要完全放权给机器发帖，尤其是涉及账号权重和粉丝互动的内容平台，人工看一眼再发布永远比自动发布稳妥。我目前的习惯是：机器负责把内容生产好、存好、提醒我，发布动作保留人工点击，这样既高效又省心。

如果还想进一步扩展，这套流程可以很方便地加上多平台分发逻辑。只要在n8n工作流后面再接几个节点，把生成好的文案和图片适配成不同平台的尺寸，再配上对应的标签规则，就能把一条内容同时分发到几个渠道。内容底层的图文数据是同一份，改的只是渲染模板和发布节点而已。

跑通这套流程之后，我最大的体会是：工具能帮你省掉那些重复劳动，但前提是你自己先想清楚流程中哪一步是体力活、哪一步是脑力活。n8n和Claude Skills的组合，就像一条小型自动化流水线上配了一个实习文案编辑，它把最耗时间的部分替你扛了下来，而你需要做的，只是站在流水线末尾做质检。如果你也在做美食内容，试着先抓一张图、一个模板、一句提示词，从最小闭环跑起来，你会发现三分钟出图这件事真的不难。