Newsletter 作者的一周工作流
一只阿木木约 20 分钟Newsletter 作者的一周工作流
——用 claude-obsidian 做选题 → 研究 → 写作 → 复盘
作者：一只阿木木 我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统。
先说我做 Newsletter 第一年是怎么死的
我的 Newsletter 叫什么不重要。
重要的是，它在第 23 期的时候，差点死掉。
不是因为没有读者。那时候已经有 2000 多个订阅者，开信率 42%，算是一个小但健康的受众群。
死掉的原因，是我精疲力竭了。
每周一期的 Newsletter，我的工作时间分布大概是这样的：
text
周一（选题）：2–3 小时
不断打开各种 RSS、推特、公众号
脑子里转了 50 个想法，全部模糊
最终靠直觉选一个，底气不足周二至周四（研究 + 写作）：8–12 小时
找资料、读文章、做笔记、写草稿、改稿
每次都感觉在"从零开始"
上期 Newsletter 里写过的相关内容，
根本不记得在哪里了
周五（发布 + 复盘）：1–2 小时
发出去，松口气
复盘大多是形式性的，
没有真正回答"下期应该做什么"
合计：每周 11–17 小时
17 小时，写一篇 2000 字的 Newsletter。
这不正常。
我做过计算：如果一直保持这个节奏，我需要每年投入 800–900 小时写 Newsletter。这是一份第二职业的工作量，但它的收入还远不是第二职业的水平。
第 23 期之后，我认真思考了一件事：这 17 小时里，哪些是真正需要我的，哪些是纯粹的信息处理？
答案是：70% 是信息处理，30% 才是真正需要我的判断和声音。
信息处理的部分，可以交出去。
今天这篇文章，是我重建工作流之后的完整实录。以一周为单位，把每一天、每一个动作都写出来，可以直接照抄。
先看结论：重建后的时间分布
text
周一（选题）：30 分钟（从 2–3 小时压缩到 30 分钟）
周二（研究）：1.5 小时（从 4–5 小时压缩到 1.5 小时）
周三（深研究 + 提纲）：1 小时（新增，从无到有）
周四（写作）：2.5 小时（从 4–6 小时压缩到 2.5 小时）
周五（发布 + 复盘）：45 分钟（从 1–2 小时压缩到 45 分钟）合计：约 6–7 小时（从 11–17 小时压缩到 6–7 小时）
减少了约 60%
更重要的是：这 6–7 小时里，几乎所有时间都花在了真正需要我的事上——判断选题方向、打磨核心观点、写出有个人声音的段落、从读者反馈里提炼洞察。
机械重复的信息处理，全部外包出去了。
系统架构：Newsletter 专用 vault 的设计
在讲每天的流程之前，先说清楚整个系统的结构。
Newsletter 的知识系统，和普通的笔记库有两个核心差异：
差异 1：它是输出导向的 每一条进来的信息，最终都服务于"这一期写什么"。不服务于任何期次的信息，进来也是噪音。
差异 2：它需要跨期积累 每一期 Newsletter 都不是孤立的，它和上期有关系，和三个月前那期有关系，和你整个创作风格有关系。这种跨期积累，是 Newsletter 最核心的竞争力来源。
基于这两个差异，我设计了这样的 vault 结构：
text
newsletter-brain/
│
├── .raw/ # 每周的信息输入
│ ├── this-week/ # 本周收集的所有来源
│ │ ├── articles/ # 文章
│ │ ├── data/ # 数据和研究
│ │ ├── observations/ # 我自己的观察和碎碎念
│ │ └── reader-replies/ # 读者回复（极其重要）
│ └── archive/ # 往期 .raw/ 归档
│ ├── 2026-W20/
│ ├── 2026-W21/
│ └── ...
│
├── wiki/ # Claude 维护的知识库
│ ├── topics/ # 话题知识图谱（跨期积累）
│ │ ├── [话题A]/
│ │ ├── [话题B]/
│ │ └── topic-index.md # 话题总索引 + 选题状态
│ ├── entities/ # 人物、机构、产品
│ ├── concepts/ # 核心概念
│ ├── data-points/ # 有用的数据（带来源和日期）
│ ├── synthesis/ # 跨期综合分析
│ ├── reader-insights/ # 读者反馈的规律性发现
│ ├── editions/ # 每期 Newsletter 的归档页
│ │ ├── edition-001.md
│ │ ├── edition-002.md
│ │ └── ...
│ ├── topic-index.md # 选题系统的核心文件
│ ├── index.md
│ ├── log.md
│ └── hot.md
│
├── output/ # 产出区
│ ├── drafts/ # 草稿
│ ├── published/ # 已发布存档
│ └── templates/ # 写作模板
│
└── CLAUDE.md # Newsletter 的完整定义
CLAUDE.md：把你的 Newsletter 定义告诉 AI
这是整个系统最重要的文件。把它写好，等于给 Claude 请了一个真正理解你 Newsletter 的编辑助理。
Markdown
# Newsletter 知识库配置## 这是什么 Newsletter
名称：[你的 Newsletter 名称]
定位：[一句话描述：面向谁，关于什么，有什么独特视角]
发布频率：每周[X]
平台：[邮件列表平台，如 Substack、竹白、Beehiiv 等]
## 我的读者是谁
核心读者群：[精确描述，越具体越好]
他们最关心的问题：
1. [问题一]
2. [问题二]
3. [问题三]
他们不想看到的：[什么类型的内容会让他们退订]
## 我的 Newsletter 风格
语言特点：[例：口语化但有深度；严肃但不枯燥；有数据支撑的观点]
内容比例：[例：70% 深度分析 + 20% 工具推荐 + 10% 读者互动]
一期的典型结构：
1. [开头钩子：通常是一个问题或反常识的发现]
2. [主体内容：核心论点 + 支撑论据]
3. [结尾行动：给读者一个可以立刻做的事]
## 核心话题领域
我持续追踪和写作的话题：
1. [话题一]（覆盖的子话题：...）
2. [话题二]
3. [话题三]
话题的权重：
- [话题一]：约占 X% 的内容
- [话题二]：约占 X% 的内容
## 选题判断标准
一个好选题需要满足的条件（至少满足 3 条）：
- [ ] 和我的核心话题直接相关
- [ ] 有具体的数据、案例或研究支持
- [ ] 对读者有"啊，原来如此"的启发感
- [ ] 我自己有独特的视角或亲身经历
- [ ] 这个时机比较对（正在发生的事、刚发布的研究等）
- [ ] 至少有一个反直觉的切入点
## 已写过的选题（避免重复）
维护在：wiki/topic-index.md 的"已发布"区域
规则：相同话题可以写，但角度必须明显不同
## 读者互动规律
维护在：wiki/reader-insights/
每期发出后，把读者的高质量回复 ingest 进去
这些回复是最好的选题来源
## Wiki 组织约定
- 数据有效期：wiki/data-points/ 里的数据，超过 6 个月的标注"需核实"
- 话题索引：每次 ingest 后更新 wiki/topic-index.md
- 版次归档：每期发布后，生成一个 wiki/editions/edition-XXX.md
周一：选题日（30 分钟）
周一是整周最关键的 30 分钟。选题选对了，后面四天顺风顺水；选题选错了，四天的努力都打了折扣。
9:00–9:15（15 分钟）：信息消化
周一早上，先把过去一周零散收集的内容批量 ingest：
Bash
cd newsletter-brain
claudebatch ingest .raw/this-week/
Claude 会处理这周所有扔进 .raw/this-week/ 的文章、数据、观察记录，更新 wiki 的知识图谱。
等待期间（通常 10–20 分钟）去倒杯咖啡。
9:15–9:30（15 分钟）：选题决策
Ingest 完成后，执行"选题三问"：
第一问：什么话题正在积累？
text
what topics have been mentioned in 3 or more sources
in the wiki but not yet covered in a recent edition?
这个 query 会扫描 wiki，找出那些被多个来源反复触及、但你还没有正式写过的话题。
这些是你的信息摄入在告诉你：这件事值得深挖了。
第二问：有没有新的有力数据？
text
what new data points were added to the wiki this week
that are surprising or counterintuitive?
一个好的数据点，往往比一个好的观点更容易撬动选题。
数据的力量在于：它是读者没见过的，它能让你的文章有"哦原来如此"的瞬间，它给你提供了一个反直觉的切入点。
第三问：读者最近在关心什么？
text
what patterns appear in our reader-insights wiki
from the last 3 editions?
这是最容易被忽视、但其实最重要的一问。
读者的回复，是最直接的选题指南。他们追问的问题、他们说"我也有这个困惑"的地方、他们"能不能再写一篇关于 X 的"——这些都是直接的需求信号。
拿到三问的答案之后，做一件事：
在 .raw/this-week/observations/ 里新建一个文件，写下这一期你的选题判断：
Markdown
# 选题决策 - 第 [XX] 期## 备选选题（来自三问）
1. [选题A]
- 来源：被 X 个来源提及
- 数据支撑：[有/无]
- 我的独特视角：[写几句]
- 风险：[什么可能写不好]
2. [选题B]
...
3. [选题C]
...
## 最终选择：[选题X]
**选择理由**：
[不超过 3 句话，说清楚为什么选这个，不选其他的]
**核心论点假设**：
[我现在猜这篇文章的中心论点是什么，研究完之后再验证]
**一个我不确定的地方**：
[这期写作中我最不确定的判断是什么]
把这个文件也 ingest 进去：
text
ingest this-week/observations/edition-XX-topic-decision.md
选题日结束前，更新 topic-index.md
text
update topic-index.md - mark [选题X] as "in progress - edition XX"
这一步很重要。topic-index.md 是你整个 Newsletter 选题历史的索引，让你清楚地知道：哪些话题写过了（什么角度）、哪些话题正在进行、哪些话题还没碰过。
周二：研究日（1.5 小时）
选题确定了，周二开始做针对性研究。
这一天的目标不是"读完所有相关文章"，而是：找到这个选题里最有力的 3 个证据，和最值得呈现的 1 个矛盾。
10:00–10:30（30 分钟）：先问 wiki
在做任何新研究之前，先问 wiki 里已有的内容：
text
what do you know about [选题话题]?
focus on:
1. strongest data points
2. counterintuitive findings
3. contradictions or debates in this area
4. which previous editions touched this topic
这一步经常让我惊喜：wiki 里往往已经有比我记忆中更丰富的内容。
因为过去几十期 Newsletter 的研究积累，都 ingest 进了 wiki。那些我以为"读过就忘"的资料，其实都在那里。
10:30–11:00（30 分钟）：autoresearch 填补盲区
Wiki 里已有的内容打底，接下来用 autoresearch 找新的角度和数据：
text
/autoresearch [选题话题的核心问题]
focus on:
- recent research and data from 2025-2026
- contrarian perspectives
- specific statistics and case studies
- what mainstream coverage is missing
强调"contrarian perspectives"（反主流观点）和"what mainstream coverage is missing"（主流报道漏了什么），是因为：
Newsletter 的竞争力，不在于比别人更快报道同样的事，而在于说出别人没说的角度。
autoresearch 用三轮搜索找这些角度，比你手动搜索效率高很多。
11:00–11:30（30 分钟）：整理本周新收集的来源
这周 .raw/ 里和选题相关的文章，单独再过一遍：
text
what was added to the wiki this week that's relevant to [选题话题]?
highlight any data points or perspectives we didn't have before
有时候周一 batch ingest 的内容里，就有这期最需要的那个素材。
周二结束：执行一次 query 做研究摘要
text
synthesize everything we know about [选题话题] into a research brief:
1. key facts and data (with sources)
2. main perspectives and their proponents
3. core tensions or contradictions
4. what's still unclear or contested
5. the strongest single piece of evidence for and against the main claim
把这个 research brief 保存到 output/drafts/edition-XX-research.md。
这份研究摘要，是周三写作提纲的底稿。
周三：提纲日（1 小时）
研究完成，周三做一件很多 Newsletter 作者跳过的事：认真写提纲。
跳过提纲直接写，是导致"写了 2000 字发现方向不对，全部推倒重来"的最常见原因。
9:00–9:30（30 分钟）：基于 wiki 生成提纲框架
text
based on the research brief for edition XX and our wiki knowledge,
generate a Newsletter outline with:
- a hook (counterintuitive opening, or a question that makes readers think)
- 3 main sections with the key point of each
- the single most important data point for each section
- a closing action (one concrete thing readers can do)my target word count: [1500/2000/2500] words
my readers are: [你的读者描述]
my unique angle is: [你的独特视角]
生成的提纲不是最终版，是你修改的起点。
9:30–10:00（30 分钟）：人工修改提纲——这是最重要的 30 分钟
AI 生成的提纲框架是合理的，但它不知道：
你上期刚写过类似的角度，这期要换 你的读者对某个例子会有特别的共鸣 你最近亲身经历了一件事，可以作为开头 你认为 AI 给的"第二节"其实是整篇最重要的，应该放第一
这 30 分钟，是整周工作流里"你的声音"最密集的地方。
做以下几件事：
调整结构顺序：把你认为最有力的论点放在最前面，不是 AI 认为最重要的 替换开头：把 AI 给的通用开头，换成你自己的亲身体验或观察 标注"只有我能写的部分"：在提纲里用 [ME]标出那些需要你个人经历和判断的段落设定一个"核心赌注"：这期你最想让读者记住的一句话是什么？写在提纲顶部
提纲修改完，存成 output/drafts/edition-XX-outline.md，再 ingest 进去：
text
ingest output/drafts/edition-XX-outline.md
让 Claude 知道你最终确定的方向，为周四的写作做准备。
周四：写作日（2.5 小时）
写作日是整周"最不需要操作 Claude"的一天。
研究已经完成，提纲已经定好，wiki 里的素材已经准备好。周四要做的，是：把这些东西，用你的声音写出来。
9:00–9:10（10 分钟）：写作前的一次 query
不是研究，是调频。在开始写之前，先读一下：
text
what do you know about [选题话题],
specifically looking for the most surprising
or emotionally resonant findings?also: what did our readers respond to most
in previous editions on related topics?
第一个问题，帮你找到写作时最好的素材；第二个问题，帮你记住读者最有共鸣的点是什么。
9:10–11:30（2.5 小时）：写作本体
这是周四的主体时间。我的写作方式：
第一步（20 分钟）：写开头，只写开头
开头是整篇文章最重要的部分，决定了读者是否继续读下去。
不要写"这期我要和大家聊聊……"。
要写让读者在第一行就被钩住的东西：
一个出乎意料的数据："上个月，我花了 14 小时写了一期 Newsletter，结果开信率是我最随便的一期的一半。" 一个读者会认出的困境："你有没有坐在那里盯着草稿，知道方向是对的，但就是写不出来？" 一个反常识的发现："所有研究都说内容要短，但我的 Newsletter 最长的几期，退订率最低。"
第二步（60 分钟）：按提纲写主体
提纲里 [ME] 标注的段落，一定要用你自己的话和经历。
其他段落，可以先用 wiki 的 query 帮你组织论点：
text
give me a concise paragraph on [这一节的核心论点],
citing the strongest evidence from our wiki,
write it as supporting material, not as the final text
注意：Claude 给的是"素材"，不是"成品"。你要把素材改成自己的语言。
第三步（20 分钟）：写结尾
结尾要给读者一个"行动"，不是"总结"。
总结是："今天我们聊了 X、Y、Z。"这让读者感觉文章结束了。
行动是："如果你想从今天开始做一件事，就做这个……"这让读者感觉文章延伸到了他们的生活里。
第四步（30 分钟）：修改
通读一遍，做三件事：
删掉所有废话（每个段落问：这段删了，文章会更差吗？如果不会，删掉） 确认每个论点都有来自 wiki 的具体支撑（不是印象，是具体的数据或案例） 检查开头和结尾是否有"我"的声音（如果听起来像 AI 写的，重写）
11:30–11:40（10 分钟）：写作后的存档
草稿写完，立刻 ingest：
text
ingest output/drafts/edition-XX-draft.md
然后问一个质量检查的问题：
text
based on this draft and our wiki knowledge,
what important points from our research
did the draft miss or underemphasize?
are there any factual claims that should be double-checked?
这不是让 Claude 改你的文章，而是让它做事实核查和遗漏检测。
周五：发布 + 复盘日（45 分钟）
发布前（15 分钟）：最后检查
发布前做三件事：
1. 数据核实
text
list all specific statistics and data points mentioned in edition XX draft,
with their sources from our wiki
逐条核实一遍，特别是那些你觉得"印象里是这样的"数据——这些最容易出错。
2. 标题测试
text
based on the content of edition XX,
generate 5 alternative subject lines that would work for this Newsletter,
focusing on curiosity gap, specific benefit, or counterintuitive angle
不一定要换，但看看有没有比你原来的标题更好的选项。
3. 最后读一遍
发布前一定要自己通读一遍。不是找错别字，是感受"这是我想说的吗？这是我的声音吗？"
发布。
发布后（30 分钟）：复盘
复盘是整周工作流里最容易被忽视的环节。很多 Newsletter 作者发出去就完事了，等到下周一选题时又从零开始。
正确的复盘，是让这期的工作为下期工作提供燃料。
发布 24 小时后，在 .raw/this-week/ 里新建一个复盘文件：
Markdown
# 第 [XX] 期复盘## 数据
发布时间：[日期]
主题：[这期标题]
字数：[X 字]
发布 24 小时数据：
- 发送数：[X]
- 开信率：[X%]（vs 过去 3 期平均：[X%]）
- 点击率：[X%]（如果有链接）
- 退订数：[X]
## 读者反馈（高质量的原话）
[把收到的有价值的读者回复，原文复制进来]
## 我自己的感受
写这期容易/困难的地方是：[X]
最满意的段落是：[X]
最不满意的是：[X]
## 选题反思
这个选题选对了吗？为什么？
如果重来，我会怎么改？
## 下期线索
读者回复里，有哪些值得追的问题？
这期内容延伸出去，下期可以写什么？
然后 ingest：
text
ingest this-week/reviews/edition-XX-review.md
这个复盘文件 ingest 之后，会更新两个关键的 wiki 区域：
1. wiki/editions/edition-XX.md（版次归档页）
自动生成这期 Newsletter 的归档页，包含：核心论点、使用的关键数据、发布数据、读者反馈要点。
2. wiki/reader-insights/（读者洞察）
把读者回复里的规律性反馈整合进去。这是选题系统最重要的数据来源——读者告诉你他们想看什么，比任何选题工具都准确。
复盘后：归档 .raw/
Bash
# 把本周的 .raw/this-week/ 移动到 archive
mv .raw/this-week .raw/archive/2026-W[周次]
mkdir .raw/this-week
mkdir .raw/this-week/articles
mkdir .raw/this-week/data
mkdir .raw/this-week/observations
mkdir .raw/this-week/reader-replies
新的一周的 .raw/ 清空了，重新开始。
一个完整的一周：时间轴总览
text
周一 9:00–9:30（30 分钟）：选题日
9:00 batch ingest 本周收集的内容
9:15 执行"选题三问"
9:25 写选题决策文档并 ingest
9:30 更新 topic-index.md周二 10:00–11:30（1.5 小时）：研究日
10:00 query wiki 已有内容
10:30 /autoresearch 填补盲区
11:00 整理本周新收集的相关来源
11:20 生成 research brief 并保存
周三 9:00–10:00（1 小时）：提纲日
9:00 基于 wiki 生成提纲框架
9:30 人工修改提纲（最重要的 30 分钟）
10:00 ingest 最终提纲
周四 9:00–11:40（2.5 小时 + 10 分钟）：写作日
9:00 写作前调频 query
9:10 写开头（20 分钟）
9:30 按提纲写主体（60 分钟）
10:30 写结尾（20 分钟）
10:50 修改（30 分钟）
11:20 ingest 草稿 + 质量检查 query
周五 发布 + 24 小时后复盘（45 分钟）：
发布前：数据核实 + 标题测试 + 通读（15 分钟）
发布后：复盘文档 + ingest + 归档 .raw/（30 分钟）
关键命令备忘录（Newsletter 专用）
把这个清单截图或打印出来，贴在工作台旁边：
Bash
# === 周一：选题 ===
batch ingest .raw/this-week/what topics have been mentioned in 3 or more sources but not yet covered recently?
what new data points were added this week that are surprising?
what patterns appear in our reader-insights wiki from the last 3 editions?
update topic-index.md - mark [话题] as "in progress - edition XX"
# === 周二：研究 ===
what do you know about [话题]?
focus on strongest data, counterintuitive findings, contradictions
/autoresearch [核心问题]
focus on recent research, contrarian perspectives, what mainstream coverage is missing
synthesize everything we know about [话题] into a research brief
# === 周三：提纲 ===
generate a Newsletter outline for edition XX
target [X] words, readers are [描述], unique angle is [角度]
# === 周四：写作 ===
what do you know about [话题], most surprising findings?
what did our readers respond to most in previous editions on related topics?
give me a paragraph on [论点], citing strongest evidence from our wiki
list all statistics in edition XX draft with their sources
generate 5 alternative subject lines for edition XX
# === 周五：复盘 ===
ingest this-week/reviews/edition-XX-review.md
# 归档 .raw/
mv .raw/this-week .raw/archive/2026-W[XX]
mkdir -p .raw/this-week/{articles,data,observations,reader-replies}
让内容持续进入 .raw/ 的六种方式
工作流能跑起来，前提是 .raw/ 里有持续的内容输入。不然周一 batch ingest 的时候，里面是空的，一切都白搭。
方式 1：浏览器 Web Clipper（最高频）
安装 Obsidian Web Clipper，配置目标文件夹为 .raw/this-week/articles/。
每次在浏览器里看到值得保存的文章，一键 Clip。不需要打开 Obsidian，不需要复制粘贴。
方式 2：读者回复（必须做的）
每期发布后，把高质量的读者回复（邮件、评论、私信）复制进 .raw/this-week/reader-replies/。
这是最多人跳过、但其实最有价值的来源。读者的回复是直接的需求信号，比任何"热门话题分析"都准确。
方式 3：你自己的碎碎念（被低估的来源）
养成一个习惯：每当你在生活中遇到任何让你多想了一秒钟的事，打开备忘录写几句，然后发到 .raw/this-week/observations/。
格式完全不重要，写给自己看就好：
Markdown
# 碎碎念 - 2026-05-28今天在超市排队的时候，
旁边两个人在聊 AI 写 Newsletter 这件事。
一个说"这样的 Newsletter 没意思，都是 AI 写的"，
另一个说"我根本看不出来哪个是 AI 写的哪个不是"。
这个对话让我觉得：也许"是否用了 AI"根本不是读者关心的问题，
"有没有价值"才是。但为什么前一种声音这么响？
可以写：读者真的关心 Newsletter 是否用 AI 写作吗？
这种碎碎念 ingest 之后，可能在三期之后变成一篇文章的开头钩子。
方式 4：数据和研究（保持更新）
每当你看到和你话题相关的新研究、新数据、新报告，存入 .raw/this-week/data/。
数据点的价值在于稀缺性——别人没有引用过的数据，是你文章里最有力的武器。
方式 5：播客和视频（高价值但被低估）
把你在播客或视频里听到的有价值的观点，手打几句话存进来（不需要全文转录）：
Markdown
# 播客摘记 - 某某 Newsletter 作者访谈说了一个很有意思的观点：
Newsletter 的复购率（续订率），比新增订阅者数量更能预测长期成功。
因为续订意味着价值认可，新增可能只是被标题吸引的。
来源：[播客名] [日期]
方式 6：竞品分析（可选但有价值）
偶尔把你在同领域 Newsletter 里看到的特别出色的写法或角度，存进来：
Markdown
# 竞品观察 - [Newsletter 名] [日期]他们这期用了一个我没想到的结构：
先提一个读者问题，然后回答，然后说"但真正的问题不是这个，而是……"
这种"先回答再翻转"的结构，比直接给观点更有悬念感。
可以借鉴：在什么情况下用这个结构？
让工作流真正跑起来的三个习惯
工作流是死的，习惯是活的。光有工作流，没有配套习惯，三周后就会烂尾。
习惯 1：.raw/ 每天进，不要攒着
不要等到周一才把这周的内容一次性整理。每天看到好内容就扔进去，周一 batch ingest 的时候才有东西可以处理。
用 Obsidian Web Clipper，把"发送到 .raw/" 的摩擦降到最低。
习惯 2：复盘文档当天写，不要拖
发布后 24 小时内，趁印象还新鲜，把复盘文档写完 ingest。
拖到下周一，你已经记不清这期写作时的感受了。复盘文档会变成形式文件，没有价值。
习惯 3：周五复盘时写下"三条下期线索"
在复盘文档里，强制自己写下三条下期可能用到的线索：
读者回复里值得追的问题 这期研究里没用完的素材 这期观点延伸出去的方向
这三条线索，是下周一"选题三问"的预热。有了它们，周一的 30 分钟不是"从零想选题"，而是"从已有线索里做选择"。
真实数据：这套工作流跑了 6 个月之后
我用这套工作流做了 6 个月，发布了 24 期 Newsletter。
数据变化：
text
工作时间
调整前：平均 14 小时/期
调整后：平均 6.2 小时/期
减少：56%发布质量（自评）
草稿满意就直接用：从 35% 提升到 71%
需要大改的期数：从 40% 降到 12%
Newsletter 数据（24 期平均）
开信率：从 38% 提升到 47%
回复率：从 2.1% 提升到 4.8%
退订率：从 0.8%/期降到 0.3%/期
Wiki 积累（6 个月后）
总 wiki 页面：1,147 个
版次归档页：24 个（每期一页）
读者洞察页：38 个
话题 synthesis 页：31 个
数据点库：214 条（带日期和来源）
潜在选题清单：29 条（来自 wiki 自动涌现）
最后那个数字最重要：29 条潜在选题。
这不是我手动整理出来的选题清单。这是 wiki 在 6 个月、24 期、1147 个页面的积累之后，自动浮现出来的——那些被多个来源反复触及、但从来没有被正面写过的话题。
这 29 条，是 6 个月知识积累的利息。
给想开始的 Newsletter 作者：最小起点
不用一次性建立完整的系统。
今天做这一件事：
把你上一期 Newsletter 的草稿，或者你准备写这期的一些参考文章，扔进 .raw/，ingest，然后问：
text
what do you know about [你上期写的话题]?
what did we miss or could have gone deeper on?
如果 wiki 里的答案让你觉得"哦，原来还有这个角度，我上期没写到"，那你就已经体验到这套工作流的核心价值了。
下一步，建立 CLAUDE.md，定义你的 Newsletter。
再下一步，下周一试着用"选题三问"做选题决策。
不要追求一次性完美，先让系统开始转起来。
最后
Newsletter 这件事，最怕的不是选题枯竭，不是写作瓶颈，不是读者增长停滞。
最怕的是：你做了很久，感觉没有在进步，每期都像在从零开始。
这种感觉，来自知识没有积累，来自每期的研究都消失在草稿文件夹里，来自读者的反馈没有被真正吸收。
这套工作流解决的，正是这件事。
不是让你写得更快（虽然确实变快了），而是让你写的每一期，都真实地为下一期积累了什么。
每期 Newsletter，都是下一期的地基。
当你的 wiki 里有了一年的积累，你会发现：选题不再是最难的事。因为你的知识图谱已经在告诉你，该写什么了。
那个状态，我现在正在经历。
很值得。
👇 如果你想继续跟着做：
关注「一只阿木木」，我们在 AI 时代一起构建自己的知识系统。
本文所有时间数据、wiki 页面数量和 Newsletter 数据，均来自作者真实使用记录。工作流可直接照抄，CLAUDE.md 模板可直接修改使用。
扫码加入行动营👇获取更多Obsidian + AI数字大脑实践
关注【一只阿木木】。
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
去做，才是真的学。🌊