Content

一篇核心文章变 12 条平台原生帖:我用 Make + Claude 跑了 9 个月的真实场景蓝图

一篇核心文章变 12 条平台原生帖:我用 Make + Claude 跑了 9 个月的真实场景蓝图
目录

我那个 Make 自动化场景每周二早上 6:47 启动。到 7:03,Airtable 里已经有 12 条平台原生的草稿,按状态色块排好。它们的"原料"是我前一晚扔进 Google Doc 的一篇 2100 字的核心长文(pillar post,指内容矩阵里的支柱性长文)。整条管线每月成本大约 4.2 美元。我已经 9 个月没有手动把 pillar 段落粘进 Claude 提示词里了,产出的质量比我以前周日晚上 11 点手写时还要好。

这篇文章是我那个场景的完整蓝图——一个模块一个模块讲清楚,带提示词模板、成本算账、还有三个高频会坏掉的环节我是怎么加防御的。如果你手上有 Make.com(就是改名前的 Integromat)的付费账号和一个 Claude API key,一个下午就能复刻出来。我不卖模板,只把骨架讲清楚,让你按自己情况改。

这个场景到底干什么

输入:一篇 pillar 长文。输出:12 条针对各平台特性原生写的内容。

  • 3 条 LinkedIn——一条长文 post、一条 10 张幻灯片的 carousel(轮播)脚本、一条文档附件的预告 post
  • 3 条 X(Twitter)——一条独立 hook 帖、一条 5 条推文的 thread(推文串)、一条引用回复体(quote-reply)
  • 2 条 Instagram——一条 carousel 文案、一条 15-30 秒 Reel 脚本
  • 2 条 YouTube——一条 60 秒以内的 Shorts 脚本、一条 Community Post 投票
  • 1 条 newsletter——120 字以内的预告 blurb 加一个"阅读全文"CTA
  • 1 条 Reddit——给相关 subreddit 的评论体 hook(不带链接,不算 spam)

数字"12"不是什么玄学。它是用来逼模型跨格式思考的——少了就会变成"同一个论点换三种说法",多了开始出废话。12 条够填一周半的发布日历,且不会重复同一个开头。

每条输出都进 Airtable 一行,与 pillar 行关联,字段包括 platform、intent、draft text、status(draft / approved / scheduled / live)和一个"human-touched?"勾选框。没有任何内容自动发出去。 场景在草稿阶段就停了——我不相信无人值守地往自己的受众账号上发东西。

开搭之前你要有什么

组件 为什么需要
Make.com Core 或 Pro 套餐 免费版每月 1000 操作数,搭到第 4 篇 pillar 就用光了。Core(10.59 美元/月,1 万操作)够跑大约 30 篇 pillar
Anthropic API key 用 workspace key 并加月度预算上限。默认模型是 Claude Sonnet 4.5
Google Drive 文件夹 作为新 pillar 草稿的触发源
Airtable base 两张表:Pillars 和 Variants(一对多)
一次性大约 3 小时 第一版搭完之后,后面调一调都是 10 分钟的事

你不需要 Buffer、Hootsuite 或任何排程工具。排程是下游另一个场景,不是这次的重点。

场景的整体形状

从上到下,这个 Make 场景一共 9 个模块:

  1. Google Drive — Watch Files(监听文件夹 /pillars/inbox/,工作时段每 15 分钟轮询一次)
  2. Google Docs — Get a Document's Content(把文档内容拉成 markdown 文本)
  3. Anthropic Claude — Create a Message("结构抽取"提示词——返回 JSON)
  4. JSON — Parse JSON(解析结构输出)
  5. Iterator(对 12 条 variant 数组做迭代,数组定义在前面的一个 Set Multiple Variables 模块里)
  6. Anthropic Claude — Create a Message("变体生成"提示词——每次迭代调用一次)
  7. Text Parser — Match Pattern(把正文、intent、"why this format fits"理由分别提取出来)
  8. Airtable — Create a Record(在 Variants 表里建一行,关联到 pillar)
  9. Google Drive — Move a File(把文件从 /pillars/inbox/ 移到 /pillars/processed/)

总共 9 个模块,但 Iterator 把模块 6、7、8 各乘以 12 次。所以每篇 pillar 消耗 9 + (3 × 12) = 45 个操作数。在 Core 套餐 1 万操作里,够跑 222 篇 pillar/月——远远超过任何人实际能写出来的量。

Step 1:结构抽取那一步

在你扇出 12 个变体调用之前,先做一次便宜的调用,拿到 pillar 的骨架。这是让后面 12 次变体调用又短又一致的关键。模块 3 的系统提示词:

You are a content strategist. Given a pillar blog post,
extract its skeleton as JSON. Return ONLY valid JSON:

{
  "thesis": "one sentence — the single claim of the post",
  "key_points": ["3 to 5 supporting points, each one sentence"],
  "best_quote": "the single most quotable line, verbatim",
  "counter_argument": "the strongest objection the post addresses",
  "primary_audience": "one phrase",
  "tone_words": ["3 adjectives that describe the voice"]
}

Pillar post:
<<<
{{2.content}}
>>>

这一步返回大约 250 token 的结构化信号。Sonnet 4.5 上的成本:每篇 pillar 约 0.004 美元。为什么要拆这一步——是为了杠杆效应。如果你直接让 Claude "读 pillar,然后写一条 LinkedIn"重复 12 次(等于把整篇 pillar 重读 12 遍),变体调用就要吞 12 遍输入 token。先抽骨架,后面 12 次变体调用每次只吃 ~400 token 的输入,而不是 ~3500。成本压缩主要就来自这里。

Step 2:12 变体矩阵

那个 12 条变体数组,是写死在一个 Set Multiple Variables 模块里的静态 JSON。每一项指定 platform、intent 和格式约束。删减版:

json[
  { "platform": "LinkedIn", "format": "long-form post",
    "intent": "contrarian hook", "constraints": "1300 chars max, no hashtags, one line break per beat" },
  { "platform": "LinkedIn", "format": "carousel script (10 slides)",
    "intent": "teach the framework", "constraints": "slide 1 is the hook, slide 10 is the CTA" },
  { "platform": "X", "format": "single tweet",
    "intent": "save-bait", "constraints": "under 280 chars, no link, one specific number" },
  { "platform": "X", "format": "5-tweet thread",
    "intent": "story-led", "constraints": "tweet 1 is the hook, tweet 5 is the takeaway" }
]

Iterator 就是逐项吃这个 JSON。把它做成一个配置 blob 的好处:想"多发点 thread、少发点 Reel",改这一个模块就够,不动场景剩下的部分。

Step 3:每个变体的 Claude 提示词

模块 6 每条 variant 跑一次。提示词模板:

You are writing one social post derived from a pillar article.

PILLAR SKELETON:
{{4.structure}}

THIS VARIANT:
- Platform: {{5.platform}}
- Format: {{5.format}}
- Intent: {{5.intent}}
- Constraints: {{5.constraints}}

Write the post natively for this platform. Do not announce
that it is a repurposing. Do not include the words "in this post"
or "as I wrote about". Write as if this is the first time you
are making the argument on this surface.

Then on a new line write:
INTENT_CHECK: 
WHY_THIS_FORMAT_FITS: 

If you cannot make the variant work for this platform
(e.g. the thesis does not suit a Reel), return:
SKIP:

那条 SKIP 子句很重要。没有它,Claude 会乖乖把一个长论证硬塞进 15 秒 Reel 脚本里,结果根本读不通。允许模型拒绝一个不合适的格式——这一个改动,把我平均草稿质量翻了一倍。被跳过的变体在 Airtable 里返回空内容,加一个黄色 flag,我自己决定要么接受跳过、要么手写那一条。

Step 4:解析和入库

Make 的 Text Parser — Match Pattern 模块用一段带 3 个命名捕获组的正则,把每次响应里的 3 段(正文、INTENT_CHECK、WHY_THIS_FORMAT_FITS)分开抽取。各自进 Airtable 的不同字段。Variants 表大致长这样:

字段 备注
Pillar (link) 源 pillar 行
Platform LinkedIn / X / IG / YouTube / Newsletter / Reddit
Format long-form、thread、Reel,等等
Intent hook / teach / story / debate-bait / save-bait
Body 草稿原文
Intent check Claude 的自评,做过滤用
Format fit Claude 的理由,做过滤用
Status draft / approved / edited / scheduled / live
Human touched? 我编辑后亲手勾的勾选框

"Human touched?"那一栏是整个 base 里最重要的字段。没被编辑过的草稿永远不会发布,没有例外。

真实成本算账

按 Sonnet 4.5 的价格(2025 年中:输入 3 美元/百万 token,输出 15 美元/百万 token)老实算:

  • 结构抽取:1 次调用,约 3500 输入 / 250 输出 = 0.014 美元
  • 变体生成:12 次调用 × 约 400 输入 / 600 输出 = 12 × 0.010 = 0.120 美元
  • 每篇 pillar 合计:约 0.13 美元

每月 8 篇 pillar 的话,Claude 花掉 1.04 美元,加上 Make 订阅 10.59 美元,总共 11.63 美元。摊到每篇就是边际成本约 1.45 美元。我第一版用 GPT-4 全程跑,每篇大概 0.40 美元——三倍于现在的成本,而且在同一位编辑做盲评时,语气保真度还略差一点。你的结果可能不一样;每 6 个月重新做一次对比。

三个最容易坏的地方

Google Drive 触发延迟。 Make 是按周期轮询 Drive 的,不是实时的。你把 pillar 丢进文件夹,下一次轮询还有 12 分钟,你就只能等。日常用没问题——但要是你想"现场给客户演示一下",这 12 分钟尴尬。要么演示前预触发,要么换成 Notion 或 Google Apps Script 的 webhook。

长 pillar 触发 Anthropic API 超时。 6000 字以上的 pillar,结构抽取那一步偶尔会撞 Make 默认的 60 秒超时。修法是在 Get Content 之后加一个 Router 模块,按字数分流——超过 5000 字就把 pillar 切两半,各跑一次结构抽取,然后在下游模块里合并 JSON。这个补丁我 9 个月里只用上过两次,都是给 SaaS 写竞品拆解类长文时。

Airtable 行数上限。 免费版 Airtable base 上限 1200 行。12 条变体 × 100 篇 pillar = 1200 行。如果你要批量回填老 pillar,很容易撞上。要么升 Team 套餐(24 美元/席位/月,5 万行),要么把已发布的 variant 归档到另一个 base。我选了归档;2024 年那批已经排程过的 IG carousel 没必要堵在主视图里。

什么时候**不要**用这套自动化

三种情况我会绕开场景、手写:

  • pillar 是有时效性新闻、或绑定外部活动 deadline 的。 12 分钟触发延迟加上人工复核循环,timing 已经丢了。这种情况先写 social,再回头补 pillar。
  • pillar 的论点是你公开场合从来没说过的。 模型是从你过去的声音里做插值。如果这篇是个大转向,变体会把转向那个棱角磨平。先手写几篇,等新立场进了你的"档案",再放回场景。
  • 你每季度只写不到 10 篇 pillar。 搭建时间是真实的。每月才一篇长文的话,直接花一小时手做,你离作品本身也更近。

这三种情况都不沾,那场景就是更优解。它在原始耗时上并不比手做快——从扔文件到全部草稿审完,挂钟时间还是 45 到 60 分钟。它消掉的是上下文切换成本——开 4 个浏览器 tab、记 LinkedIn 字符限制、想起上周 X 上是不是已经用过这个 hook、决定 Reel 切什么角度。这些决策疲劳由场景吸收,你只做编辑——而编辑本来就是你应该做的那部分。

省下的 12 分钟/平台并不是这套东西的价值。真正的价值是:在你累到根本不想写的那一周,工作仍然发生了。