把 Newsletter 和播客转成书稿：5 步 DIY 工作流

URL to Anyon 24 days ago

你的 Substack 归档里躺着 180 期通讯。或者 96 集播客，录了三年。也许两样都有。读者一直在问：「有书吗？」你一直回答：「以后吧。」问题不是素材。素材你有的是。问题是从「内容归档」到「书稿」之间那道形状不太对的缺口。

这篇教程教你一套 5 步内容复用（content repurposing）工作流，把 newsletter 或播客转成书稿：把所有文章和 transcript 抽成干净 Markdown，用 AI 摘要提炼隐藏的章节结构，再重新排序、缝合成一份真正的初稿。不管你是把 Substack 归档做成 ebook，还是把播客做成 manuscript，步骤一样。我们也对比了 Prosed——2026 年中在 Product Hunt 爆款上线、主打「一键从 newsletter 或播客 feed 到书稿」的工具——并说明各自适合什么场景。

活跃 Substack 作者年发 42 期（Substack 2026 创作者报告中位数）。三年 126 期，每期 800-1200 词，约 13 万词。
每周一集、单集 45 分钟的播客，按 150 WPM 语速换算，单集 transcribe 后约 6800 词。两年 100 集 = 68 万 transcribe 词，砍掉口水后约 12 万词的可用稿。
Substack 和 Beehiiv 都报告：发过 50+ 期的作者里，不到 4% 真的把这些内容做成了一本书。卡点几乎从不是素材，而是结构和重新组织的体力活。

缺口的形状高度一致。你的归档是一条按时间线性排开的 feed：「第 1 期、第 2 期、…」。书是一个 按主题组织 的产物：章节互相支撑，段与段之间有过渡，全书有一条统一的论证主线。下面这个 DIY 工作流，本质上是一种「在已有归档里找出那本已经存在的书」的方法——不是从头再写。

Prosed 在做什么，DIY 什么时候赢

Prosed 是一条托管管线。你把 newsletter RSS 或播客音频 feed 喂给它，选一个书的篇幅，它返回一份书稿初稿——聚类、章节排序、缝合全在后台完成。对不愿意管过程的创作者来说，这是个公平的取舍：花一笔固定费用，省下几周劳力。

DIY 工作流牺牲这种托管简洁度，换四种控制力：

声音控制：托管管线会把你的语调平均向通用非虚构风格靠拢。DIY 默认保留你的原句，只在你主动改写时才动。
来源权重：哪 30 篇做书的脊梁、哪 90 篇砍掉，你说了算。把「全部 120 期」一股脑喂进去的管线，等价权重处理，很少恰好对。
章节设计：你可以按一个自定义论点搭书——比如 7 章「unlearning」结构——而不必接受算法聚类的结果。
大规模成本：200 集播客归档 DIY 成本和 50 期 newsletter 差不多；托管服务一般按输入量计费。

什么时候用 Prosed：下周想拿到草稿、归档本身已经一致、能接受通用结构。什么时候 DIY 赢：你有一个清晰想让书去论证的论点、归档主题跨度大，或者你只是想在外包前先理解自己作品的结构。

两条路也不互斥。很多创作者用 DIY 跑到第 3 步（提炼章节候选），再把结构交给托管编辑或服务完稿。把下面的工作流当作既是独立路径、又是 brief 任何下游工具用的脚手架。

把 newsletter 或播客转成书稿的完整 DIY 工作流，通常占用 15-25 小时聚焦工作，散在 2-3 周内完成，对应一份 6 万字左右的书稿。下面 5 步产出一份可以直接交给文字编辑的初稿。

第 1 步：盘点所有文章和播客集

动 AI 之前，先建一份扁平的 URL 或 transcript 来源清单。目标：一个 sources.txt 文件，一行一个 URL，按时间从旧到新排序。

Newsletter：

Substack：Settings → Exports → Posts（HTML 格式）。导出包里的 index.html 含所有文章 URL。
Beehiiv：Dashboard → Settings → Export，CSV 里有 post_url 列。
ConvertKit / Mailchimp：用公开归档地址（yoursite.com/archive），让转换器爬，或在后台导出 campaigns。
自部署（Ghost、WordPress）：抓 /sitemap-posts.xml，提取 <loc>。

播客：

从 RSS：每个播客平台都暴露 RSS（yourshow.com/feed）。每个 <item> 里的 <link> 指向 show notes 页面，那才是你要的——不是音频 URL。
没有 transcript 的纯音频：用 Whisper、Otter、Descript，或对托管音频 URL 用 URL to Any 的 URL to Text 转换器跑一遍。每集 transcript 存成 episode-NNN.md。

继续之前先剪一刀。砍掉公告类（「我们要休假了」）、纯促销、纯链接合集。一个有用的判据：如果这一期对从没看过你其他内容的读者也读得通，就留；如果只是上下文填充，就砍。多数归档在这一步会缩 20-35%——这是收益，不是损失。

第 2 步：批量把所有 URL 转成干净 Markdown

第二步把 sources.txt 变成一个 Markdown 文件夹——每篇文章或每集一份，剥掉广告、导航、订阅条、播放器组件。Markdown 是合适的中间格式，因为 AI 模型读得高效（比 HTML 省 60-75% token），且标题层级保留，对下一步关键。

把单个 URL 粘到 URL to Any，选 URL to Markdown，每篇约 2 秒。但 120 篇规模下浏览器手动会很乱，跑个批处理：

#!/bin/bash
mkdir -p sources_md
while IFS= read -r url; do
  slug=$(echo "$url" | shasum | cut -c1-10)
  curl -s "https://urltoany.com/api/function/to-markdown?url=${url}" \
    > "sources_md/${slug}.md"
  sleep 1
done < sources.txt

Whisper 或 Descript 给到的播客 transcript，归一化成同样的 Markdown 形状：H1 是集标题，已经分章的 transcript 用 H2 切主话题，否则普通段落即可。这版是给 AI 看的，不用打磨。

抽 10 个文件目检 5 秒。如果看到「立即订阅」重复横幅、代码块断裂、大段导航文字，说明转换器过滤设错了。在继续之前换更严的提取设置重跑。我们见过有人两周后才发现 Markdown 是脏的，整个工作流被迫返工——不要省这一眼。

body_image_1

第 3 步：用 AI Summarizer 提炼主题和章节候选

这是真正在归档里「找到那本书」的一步。目标不是任何单篇的摘要——是覆盖整份归档的结构地图，让自然章节形状浮出来。

对每个 Markdown 文件跑一段结构化提取 prompt。已有 Markdown 直接发给 Claude/ChatGPT，URL 输入用 URL to Any 的 AI Summarizer。Prompt 用这个：

对以下文章，提取：
1. 单句核心论点。
2. 文章属于的最多 3 个主题（1-3 词的 tag）。
3. 文章里最值得引用的 1-2 句。
4. 一个 1-5 的「book-fit」分数：这篇是否适合一本关于[你的主题]的非虚构书。

[在这里粘 Markdown]

把输出汇成 CSV 或 JSON，列：slug, core_argument, themes, quote, fit_score。120 篇跑完，你就有一张整份归档的结构索引表，通常 6-8 小时模型时间，一个周末搞定。

现在聚类。按 themes 排序，看自然涌现的形状。2026 年 4 月我们在 4 份 newsletter 归档上实测：多年 newsletter 的自然主题簇数是 6-10 个，正好对应 6-10 章的书。fit_score 低于 3 的不属于任何簇 = 你的舍弃池，要么砍要么留作未来散文。

Quote 这一列是全表最值钱的：它会成为章节开篇、callout 和封底文案的原料。别跳过。

第 4 步：给书写大纲，把文章重新排进章节

大纲这一步是 AI 替你做不了的人类工作。AI 擅长聚类；不擅长决定你的书到底「在讲什么」。这件事必须你来。

先用一句话写整本书的论点——你想让读者翻到第 250 页时相信什么。然后给第 3 步出的每个簇写一个章节标题，加 2-3 句的章节前提。各章应该按顺序推进论点；如果推不动，重新排序簇，或拆/合并它们。

再把文章排进章节。打开第 3 步的 CSV，加一列 chapter，把每篇丢进最合适的章节槽。多数能干净分类；有些跨两章，到稿件阶段要么挑一边，要么拆成两节。

一个有用的结构经验：每章想要 5-12 篇源文章。再少，章节太薄撑不起书级论证；再多，会跑题铺张。簇里有 18 篇？大概率该拆两章。只有 2 篇？合并进相邻章。

第 4 步结束你应该有：(a) 一页大纲，含论点、章节标题、章节前提；(b) 一份 CSV，把每篇留下来的文章映射到章节。这一页是整个工作流里最值钱的产物——也就是托管服务（比如 Prosed）会向你收费的那部分，现在它属于你。

body_image_2

第 5 步：缝合、改写过渡、编辑成书稿

最后一步把大纲 + 已标注的素材变成真正的书稿。诱惑是让 AI「按这些文章写一章」。拒绝它。AI 缝合出来的章节读起来就是 AI 缝合的——声音扁平、没有摩擦、没有意外。读者选你是因为你的声音，别把它磨平。

更好的模式是「人为主、AI 辅」的缝合：

每章把源 Markdown 文件按出现顺序粘进一个工作文档。
通读一遍，删重复段落、过期引用（「上周我写过…」）和与章节前提无关的离题段。多数章节在这一步会丢掉原始词数的 25-40%。
在每个源文章之间写新的 过渡段。这是唯一必须新写的内容——每个接缝 80-120 词，用你自己的声音，把上下两段串通。
每章加 200-300 词的 章节开篇 和 100-150 词的 章节收尾。开篇立章节前提，收尾把读者交接给下一章。
把日期化措辞（「这周」「上个月那期」「我在 Twitter 上说过」）换成无时效表达。一年后读者一眼就看出书是按期缝起来的，否则。

这样一章成稿通常 6000-9000 词——5 篇 1000 词的源文 + 1000-2000 词的过渡和框架。7 章的书落在 4.5-6.5 万词，正好 trade book 甜区。

收尾做一次端到端通读。如果某章还像「一摞文章」，是过渡没尽到职责——重写接缝，不要重写源材料。最终稿务必交给真人文字编辑再投稿。

工具对比：DIY vs Prosed vs 代写 vs 手动复制

从「我有归档」到「我有书稿」，现实里有四条路。真实权衡：

路径	擅长场景	不适合	典型成本	出稿时间
手动复制粘到 Google Docs	极小归档（<20 篇）、低野心	任何跨年、跨主题的归档	$0	80-120 小时
代写或开发编辑	有预算、论点模糊	想保留个人声音的独立创作者	$8000-25000	3-6 个月
Prosed（托管管线）	一键出稿、能接受通用结构、时间紧	论点驱动强、主题杂的归档	付费托管服务	1-3 周
DIY：URL to Any + Claude/ChatGPT	声音控制、自定义论点、大归档	不愿做第 4 步大纲的人	<$50 API + AI 订阅	15-25 小时 / 2-3 周

真实看法：手动复制只适合 12 篇精华合辑，100 篇规模下惨不忍睹。代写适合「有预算、没时间、也不放心自己做大纲」——能给你结构完整的书，价格也很结构完整。Prosed 适合这个月就要出稿、能接受通用结构的创作者——对的归档下省时间，错的归档下会被算法局限。DIY 工作流的胜场在你在意声音和结构；更关键的是，它是唯一一条「章节大纲是你的」的路径，而那张大纲恰好决定了书好不好。多数有真实论点的创作者，DIY + 最后过一位真人文字编辑就是甜区。

让内容归档变成真正一本书的 7 条进阶建议

聚类前先剪：跳过第 1 步的剪枝，后面每一步都更乱。第一刀目标砍 20-35% 归档——结果是更紧凑、更快的下游工作流。
论点先于大纲：别让 AI 簇告诉你这本书是什么。先写一句话论点，再只挑能支撑它的簇。剩下的簇是下一本书或一组后续文章。
缝合完每章读一遍出声：读出来像你，缝合就成功了；读出来像陌生人或新闻稿，过渡还要再过一轮。
章节顺序最后再定：大纲时觉得顺的顺序，端到端读下来往往不是最好读的。整稿出来后再调 1-2 章位置，几乎总会更好。
保留一份 cuts.md：第 5 步删掉的段落全进这里。其中约 30% 会变成未来的 newsletter 或短文。这本书会回报你两次。

常见问题

大归档工作流不变，时间会涨：200 期需要 25-40 小时聚焦工作，而不是 15-25。线性扩张的两步是第 2 步（批量 Markdown，可脚本）和第 3 步（AI 提取，每篇 3-5 分钟模型时间）。第 4、5 步不太扩张——它们停在章节层面，而不是文章层面。这种规模下最大收益是把第 1 步剪得狠：200 篇归档常常最终留 60-80 篇，书反而更好。

Prosed 和自定义 DIY 工作流相比怎么样？

Prosed 端到端更快（1-3 周 vs DIY 的 2-3 周）、动手更少，但聚类和章节结构是算法决定的——同一份归档喂 Prosed 出来的书会很像。DIY 工作流让你在第 4 步亲手写论点、亲手挑簇，这往往是「能卖的书」和「评论里被吐槽『像博客合集』的书」之间的差距。归档本身论点高度一致（单主题、单受众），Prosed 接近 DIY 质量；归档跨度大，DIY 在质量上赢。

Kindle Direct Publishing 上 newsletter 转电子书的甜区是 3.5-5 万词——两次坐下能读完，又长到像本书。Leanpub 或按需印刷的纸本，目标 5-7.5 万词。Newsletter 源材料超过 8 万词通常是在塞本该删的章节；信任第 3 步的 fit_score。

能用这个工作流转别人的内容吗？

不能，除非有授权。工作流默认源内容归你（你自己的 newsletter、你自己的播客）。把别人的写作做成书出版是版权侵权；把节目里嘉宾访谈片段做进书，需要嘉宾的 release。出版前务必核对嘉宾授权。

3 周项目期间工作文件怎么放？

一个项目文件夹三个子目录就够：sources_md/ 放第 2 步 Markdown 输出，extraction.csv 是第 3 步结构索引，chapters/ 放第 5 步章节稿。outline.md 和 thesis.md 放根目录。用 git 或同步云盘版本化——AI 跑了 8 小时的提取表丢了是糟糕的一天。AI 摘要本身怎么组织，我们在稍后阅读 AI 摘要工作流里的做法也适用：一份源一个 Markdown，一个 prompt 一份输出，结果汇成表。

结语

内容归档和书之间的缺口，不是写作缺口，是结构缺口。文你已经写完了。上面 5 步 DIY 工作流是一种「找出归档里那本已经存在的书」的方法：把所有文章抽成干净 Markdown，让 AI 浮出主题结构，自己写论点，再用你自己的声音把选定的文章缝成章节。

Prosed 和类似托管管线是想要通用初稿时的合理捷径。DIY 在你想要一本「论证某件具体事、用你的声音、章节是你定的」的书时赢。成本差是一两个周末；质量差可能是「被引用的书」和「被退款的书」的差距。

从小处开始。这个周末用第 1 步和第 2 步处理你最先的 30 篇。如果干净 Markdown 堆起来已经开始自己暗示结构，那剩下的工作流大概率能跑通——你书架上的下一本书，就会是你自己的。

最后更新：2026-05-23

准备好把 newsletter 或播客归档做成一本书？免费试用 URL to Any →——批量把 URL 转成干净 Markdown，几秒一篇，直接喂给 Claude 或 ChatGPT 做结构提取。10+ 转换器，包括 URL to Markdown、AI Summarizer、URL to Text。免注册。