AI 写 Substack cluster digest newsletter
用 AI 把一个 vendor cluster(同一周多个 vendor 发相关里程碑)变成一篇 Substack newsletter,做对比、框定编辑 takeaway、把读者转化成忠实订阅者。
这篇文章的目标
你想发一篇 Substack newsletter,总结一个 vendor cluster,给订阅者一个清晰的、他们能行动的 takeaway。Newsletter 比 thread 长 —— 它需要结构、行文、至少一个对比面(表格、并排、图)。这套工作流产出一篇 1500-2500 字的 Substack 文章,框定 cluster、在有意义的轴上对比 vendor、最后落到订阅者会记住的 takeaway。
这篇配 AITopic 上的 weekly digest —— 那个 digest 是编辑综述;这个 task 教你把 cluster 变成一篇独立的 newsletter,搭建你自己的订阅者基础。
推荐工作流
第 1 步:挑 cluster 和编辑框定
Cluster newsletter 失败是因为试图覆盖一切。挑一个 cluster(比如「8/6 agent framework cluster」)和一个编辑框定(比如「开源四角现在 production-ready —— 怎么挑」)。框定是脊柱,其他一切支撑它。
帮我写一篇关于 vendor cluster 的 Substack newsletter。信息:
Cluster 名字:[比如 "August 6 agent framework cluster"]
Cluster 时间窗:[比如 "August 1-7, 2026"]
Vendor 数量:[比如 6]
Vendor 名字:[比如 "LangGraph, LlamaIndex, CrewAI, AutoGen, OpenAI Agents SDK, Anthropic Agent SDK"]
编辑框定:[比如 "开源四角同一周达 1.0 —— 怎么挑" 或 "视频生成收敛在连贯性 + 音频"]
关键 takeaway:[一段,比如 "挑匹配你工作流形状的那个 framework,不是 star 最多的那个。这里给六个 framework 各自的心智模型 lens。"]
字数目标:[1500-2500]
读者:[比如 "Q4 选 framework 的 AI 工程师和技术创始人"]
语气:[比如 "数据驱动、有观点、对话式"]
第 2 步:生成 newsletter 大纲
一篇 1500-2500 字的 newsletter 需要先有结构,再写行文。先锁大纲,再填每节。
Claude
免费替代: Kimi(中文读者 newsletter)
长篇结构、对比表、行文节奏
大纲应对应 5-7 节结构:开场 hook、框定声明、一节一对比轴、对比面(表格或并排)、takeaway、下周看什么。每节给一个字数目标,最终文章落在 1500-2500 区间。
为这个 cluster 生成 newsletter 大纲。结构:
-
开场 hook(150-200 字):一个轶事或具体数字,把 cluster 当新闻落地。不要"我最近在想..."开头。
-
框定声明(200-300 字):显式陈述编辑框定。"这里是让这个 cluster 说得通的 lens。"点明对比轴。
-
Cluster 上下文(200-300 字):为什么这个 cluster 现在重要。引用更大的模式(vendor cluster 速度、围绕这个类别正在形成的买方市场)。
-
并排对比(400-600 字 + 1 张表):一节一个对比轴/对比对,节末给对比表。每行必须包含事实声明(版本、GA 日期、能力)和编辑判断。
-
反向论据或意外(200-300 字):"但大部分对比漏掉了这一点。"引入张力或非显然结论。
-
Takeaway(150-200 字):一段,给每个工作流形状点一个推荐。一句话 CTA 收尾:"回复告诉我你选了哪个,为什么。"
-
下周看什么(100-150 字):一段,指向下一个 cluster 或你正在跟踪的成熟信号。
每节字数目标:[把上面的粘贴]
Cluster 事实:[把 6-10 个 vendor 事实粘贴]
第 3 步:写完整 newsletter(一节一节)
锁了大纲之后,写行文。行文决定 newsletter 读起来像人写的还是生成的。
写第 [N] 节的行文:[从大纲粘贴节标题]。
要求:
- 匹配上面给的字数目标
- 用具体数字或轶事开头,不要"在本节中..."
- 至少引用一个一手源(release notes URL、博客标题、版本号)
- 一致地用对比轴 —— 每句话都应该强化框定
- 每节加 1 个内联表或对比列表
- 语气:对话式但数据驱动;编辑判断用第一人称("我觉得..." 或 "我的判断是...");事实用陈述句
第 4 节(并排),生成 markdown 表,列:
| Vendor | 版本/GA | 关键能力 | 适合谁 | 权衡 |
第 4 步:人工 edit(强制)
Newsletter 订阅者是你最忠实的读者 —— 他们主动 opt-in。Newsletter 上 AI 味是失去他们的最快方式。你必须:
- 发之前朗读一遍。 如果哪句话听起来像 LinkedIn post,改写。Newsletter 读起来像一对一对话,不像新闻稿。
- 对照一手源验证每个数字和版本。 Newsletter 读者会转发数字错的文章。发之前对照 vendor release notes 重核一遍。
- 加 AI 不会知道的东西:你跟踪这个 cluster 的个人轶事、触发这篇 newsletter 的客户问题、你会选哪个 vendor 以及为什么的个人观点。个人角度是护城河。
- 砍掉所有陈词滥调:"在今天快节奏的格局下"、"值得注意的是"、"当我们考虑"、"未来已来"。看到了就删。
- 检查对比表的每行长度一致性。 如果一行 6 个字、下一行 30 个字,表看起来不专业。统一行长。
- 至少加一张图或一张表。 Substack newsletter 每 1000 字至少有一张图,通常比纯文字打开率更好。一张简单对比表就算。
- 标题控制在 60 字符以内。 60 字符以上的标题在移动端会被截。标题必须点 cluster 和 takeaway,不要卖关子("我这周注意到的 AI 5 件事" → "Agent framework 集体达 1.0:怎么挑一个")。
推荐工具组合
| 工具 | 用途 | 是否免费 |
|---|---|---|
| Claude (Sonnet 4.5) | 大纲结构、行文节奏、对比表 | 有限免费层 |
| ChatGPT (GPT-4o) | 备选措辞、hook 生成 | 有限免费层 |
| Substack | 发布、订阅者管理、付费层 | 免费(付费层抽 10%) |
| Grammarly | 行文润色、语气一致性 | 有限免费层 |
| Canva / Figma | 对比图视觉 | 有限免费层 |
平台注意事项
- 1500-2500 字是甜区。 1000 字以下 newsletter 读起来像博客,丢了"信"的框定;3000 字以上完成率随读者放弃长文而下降。目标 1800-2200 字。
- 标题决定打开率。 Substack 在 inbox 预览里显示标题 —— 60 字符以内是移动端安全区。点 cluster 和 takeaway,不要卖关子。"关于 AI 的 5 个想法"输给"Agent framework 集体达 1.0:怎么挑一个"。
- 开头 3 段定调。 Newsletter 读者在前 200 字决定是否继续读。用具体数字或轶事开头,不是关于为什么写的元声明。
- 每个 newsletter 一个对比面。 表、并排或图,挑一个。多个对比面让 newsletter 读起来像报告,不像信。
- CTA 放末尾,不放开头。 前 200 字就要付费订阅的 newsletter 倾向于丢读者 —— 他们还没决定这篇是否值得花时间。先用行文建立信任,最后再问("如果这篇有用,考虑订阅 —— 这是支撑这事继续做下去的方式")。
- 周二或周三,订阅者本地时间 8-10 点发。 B2B newsletter 在工作日上午达峰。周五打开率显著低。
- 同样内容提前 24 小时发到 Substack Notes 作为预告。 Notes 把你的内容展示给非订阅者,驱动订阅转化。
FAQ
Cluster digest newsletter 应该多久发一次?
每周一次,锚定那周最大的 cluster。如果那周有 3 个 cluster(比如 8/1-8/11 这段有 agent framework + video gen + world model),挑匹配你读者决策周期的那一个,发一篇只覆盖那个 cluster 的 newsletter。不要试图在一个 newsletter 里覆盖 3 个 cluster —— 对比变浅、行文显得仓促。
Cluster digest 应该付费墙吗?
至少一开始不要。Cluster digest 是你的 funnel 顶 —— 它们带来新订阅者。把深度教程、个人工作流、年度报告付费墙;cluster digest 留免费。免费 cluster digest 培育的受众会转化成付费的深度内容。
怎么避免 newsletter 读起来像 vendor 目录?
编辑框定是让 newsletter 不退化成目录的关键。如果框定是「开源四角集体达 1.0 —— 怎么挑」,每节强化那个框定(哪个 framework 配哪个工作流形状)。如果框定只是「这是发的东西」,每节变成 vendor 条目,newsletter 就读起来像目录。开头陈述框定,每节显式引用它。
如果 cluster 太大,一篇 newsletter 装不下怎么办?
砍到占主导的 4-5 个 vendor,显式注明你的取舍。"我聚焦这四个开源 framework,因为它们发了最干净的 1.0 里程碑;两个 vendor SDK 值得单独对比。"4 个 vendor 各 600 字比 6 个 vendor 各 200 字强。