本地优先 · 不碰你的密码 · 零第三方依赖

一行命令，
把你散在各平台的创作，
收成一个 AI 能读的文件。

你写了十年，AI 却对你一无所知。
微信读书 · QQ 邮箱 · DeepSeek —— 收成一份属于你的个人上下文。

npx selfloom demo

零配置 · 不联网 · 不需要任何凭证 —— 先看到结果，再决定要不要授权

3个平台一次汇总

3600条记录（一次真实运行）

0对账差额

0.6–1.5s日常增量更新

看它跑起来

不用注册，不用授权，先看它跑一遍

下面是一次真实运行的输出回放（不是模拟动画，文字来自实际终端）。看完了再决定要不要接自己的账号。

selfloom — 终端回放

▶

演示视频（待录制） 建议 45–60 秒、16:9、静音循环。分镜：① 桌面只有三个 App（5s）② 粘一条命令回车（8s）③ 终端跑完、打开 timeline.md（15s）④ 往下滚动看三平台内容混排（15s）⑤ 回到终端展示对账"差额 0"（10s）

为什么先做终端回放：它不需要视频文件、不占带宽、离线也能看，而且它展示的是真实输出——比任何手绘 mockup 都更可信。真人视频录好后替换上面的占位框即可。回放中的账号与凭证信息已脱敏。

实例

以前要多久，现在要多久

数字来自一次真实运行：微信读书 249 本书、QQ 邮箱 4257 封邮件、DeepSeek 99 场对话。

手动整理（估算）

≈ 12 小时

仅微信读书一项 · 249 本 × 约 3 分钟

Self-Loom 首次运行

6 分 54 秒

163s + 251s + 0.1s，三个平台全量

之后每次更新

0.6–1.5 秒

只重抓计数变了的对象

这件事	手动	Self-Loom
微信读书 249 本书的想法与书评	逐本打开、复制、粘贴	一次命令
从 4257 封邮件里挑出"我发给自己的"	无法完成	自动筛出 79 封
把 99 场对话导出成可读文件	下载 zip 后仍需手工处理	自动解析
三个平台按时间排在一起	人工对齐时间线	自动混排
确认"有没有漏掉"	只能凭感觉	逐本对账，差额 0

关于"≈ 12 小时"：这是按"手动导出单本书约 3 分钟"估算的（打开网页版 → 进笔记本 → 选书 → 导出/复制 → 粘贴），不是精确测量。我们宁愿标注估算依据，也不想给你一个看起来很准的假数字。首次运行的时间则是三项实测相加。

同一批内容，两个世界

左边是你现在的状态，右边是跑完之后的状态。

😮‍💨 之前：散在三个 App 里

📚

微信读书249 本书的划线、想法、书评

✉️

QQ 邮箱转发给自己的一封封记录

💬

DeepSeek99 场对话，导出后仍是一堆 JSON

三种格式、三套时间、无法一起喂给 AI。

📷 这里放手动整理时的截图（三个 App 各截一张）

✨ 之后：一份文件，一条时间线

# 我的思考时间线

> 覆盖 2015-09-25 ~ 2026-10-13
> 共 1894 条 · 来自 微信读书 / QQ 邮箱 / DeepSeek

### 2026-04-08
**[QQ 邮箱]**
今天的实验：把最清醒的两小时完全锁起来…

**[微信读书 · 事实]**
> 而中间的大多数才是真正在改变世界的力量。
「二元对立」是一种认知上的省力装置…

📷 这里放跑完后的截图（编辑器里打开 timeline.md）

右上的示例内容来自内置的虚构样例数据——你的真实笔记不会出现在这个页面上。

这份文件能拿来做什么

它不是一个"备份工具"。它解决的是：AI 帮不了你，是因为它不知道你是谁。

🧠

给 AI 一份你的上下文

把 timeline.md 丢给任意 AI，它才第一次知道你读过什么、想过什么、卡在哪。不用你再解释一遍背景。

🪞

让 AI 做一份"思考者画像"

1894 条跨越 11 年的记录，足够让 AI 指出你反复回到的主题、你回避的问题、以及你真正的比较优势在哪。

📅

年度复盘不用再翻手机

时间线天然按年/月/日排好。写年终总结时，直接搜那一年你在想什么。

✍️

写作者的素材库

items.jsonl 一行一条，可检索、可向量化。你过去三年写下的句子，变成可复用的素材。

检测

凭什么说它可靠

三个卖点不是形容词，每一个都有具体的实现方式和可检查的证据。

卖点	靠什么实现	你可以怎么检查
不碰你的密码	只接受只读的一次性凭证：微信读书的 API Key、QQ 邮箱的 IMAP 授权码。凭证存本机 `~/.selfloom/credentials.json`，不进产物、不进日志、不进对话。	代码开源且零第三方依赖，全部可读；`.gitignore` 已排除凭证文件。
有对账，不糊弄	两条硬规则：① 差额必须为 0，且每一笔都要逐项归因；② 来源声明有内容、却一条都没抓到 —— 一律判为失败。	打开 `manifest.json`，每个平台的「声称 / 实抓 / 差额」都在里面。
一份 AI 能读的文件	三层产物：`items.jsonl`（机器层）· `<平台>.md`（保留原生语义）· `timeline.md`（按时间混排）。	纯 Markdown + JSONL，无专有格式，任何编辑器/AI 都能打开。

我是怎么验证它的

下面是开发过程中真实发生过的四次验证——包括我们自己的 bug。把过程摊开，比给一个"已测试"的标签更有说服力。

① 逐本对账微信读书的 249 本书

把接口声明的「划线 + 想法」与实抓记录逐本比对。发现 308 段划线在「划线」和「想法」里被各记了一次，属于 App 的重复计数，已合并。

249 本书逐本差额 = 0

② 篡改计数，验证增量真的会重抓

手动把某一本书的 noteCount 改成 999，再跑一次同步。它精确重抓了那一本，其余 248 本走缓存。

命中缓存 248 · 本次重抓 1 · 用时 2.1 秒

③ 抓到一个"程序不报错、结果却是空的"的 bug

DeepSeek 适配器最初把 99 场对话全部解析成 0 条记录，而程序报告"对账通过"——因为两边都是 0。根因是把"叶子节点"（自己没有子节点）写成了"不在任何子节点里"（即根节点）。

已修，并新增硬规则：声明有数据却抓到 0 条 → 直接判失败

④ 一封 43 MB 附件的邮件，不再被反复下载

有封邮件正文为空、却带 43 MB 附件。原逻辑把它当"解析失败"，于是每次同步都重新下载 43 MB。修正为：「没有可导出的文本」是一个已归因的事实，不是错误——记录、计数、缓存，不再重下。

16 封空正文邮件已归因 · 0 次重复下载

对账数据（一次真实运行）

这三行是这套工具的核心承诺：声明多少、抓到多少、差额去哪了。

平台	来源声称	实际抓到
微信读书	2417 条（划线 + 想法）	2417 条
QQ 邮箱	4257 封中命中 79 封	79 封（66 封有条目 + 13 封空正文）
DeepSeek	文件内 2030 个片段	1128 条 + 547 思考 + 307 工具轨迹 + 48 放弃分支

差额为 0 的含义：每一笔"没导出"的东西都能说清去哪了（官方不提供内容 / 已归因的事实 / 你重新生成过的旧分支），没有一条是"不知道去哪了"。微信读书的 24 条书签属于第一类——官方只给数量、不给内容，我们在产物里如实标注。

产品便利性：时间花在哪

省时间不只是"跑得快"，而是以后每次都不用重来。

场景	手动	Self-Loom
第一次把三个平台全部收进来	≈ 12 小时以上	6 分 54 秒
半个月后想更新（读了几本新书）	再走一遍全部流程	1.5 秒
收到新的转发邮件	手动复制粘贴	0.6 秒
凭证明天过期了	抓取失败很久才发现	`doctor` 直接告诉你哪个失效了

原理

为什么是这么设计的

每一个"不做"，都是想清楚之后才不做的。

1 为什么不要你的账号密码

因为"用密码换自动登录"这条路，技术上就走不通，而且在信任上是负收益。

微信读书的凭证来自微信扫码——微信根本不提供密码登录接口，硬做只能模拟点击，极易触发风控，代价是用户微信被封。QQ 邮箱的 IMAP 授权码生成时必须过短信验证，手机在用户手里，无法自动化。

所以凭证的获取无法自动化；但凭证的验证、保存、失效提醒完全可以——而那才是真正耗时的部分。这就是 auth（导入即校验）和 doctor（体检）存在的理由。

2 为什么必须有对账

这类工具最危险的失败不是报错，而是静默：程序正常退出、产物看起来完整，但实际上少了一半。

所以我们把两条规则写进产品：差额必须为 0 且逐项归因；来源有内容却抓到 0 条 —— 判失败。第二条在开发第一天就抓到了我们自己的 bug（见上面的检测③）。

3 为什么产物要分三层

因为"给 AI 读"和"给人查"是两种需求，混在一起两个都做不好。

机器层要一行一条、可流式、可检索；平台层要保留原生语义（微信读书按书/章，邮箱按日期）；汇总层要跨平台按时间混排。三者不是冗余，是三种用途。

4 为什么零第三方依赖

一个要接收你凭证的工具，多一个依赖就多一份供应链风险，也少一分可审计性。

所以 IMAP 客户端、MIME 解析、ZIP 读取、HTML 转文本，全部用 Node 内置模块手写。代价是开发慢一些，换来的是你能把全部代码读完，以及 npx 真正零安装。

微信读书 API ─┐ QQ 邮箱 IMAP ─┼─→ 独立适配器（各自负责抓取 + 对账） DeepSeek zip ─┘ │ ▼ ~/.selfloom/raw/<platform>.json ← 原始层，可审计、可重放 │ ▼ ┌───────────┴────────────┐ ▼ ▼ items.jsonl <platform>.md ← 机器层 / 平台层 └───────────┬────────────┘ ▼ timeline.md ← 汇总层：一条属于你的时间线 │ manifest.json ← 对账与来源留档

我们不会假装拿到了没有拿到的东西

工具最该说清楚的不是它能做什么，而是它做不到什么。

微信读书的书签：官方只提供数量、不提供内容。我们在产物里标注为「已归因的缺失」，而不是悄悄少给你。
QQ 邮箱的压缩包与内嵌图片：默认不落盘（有开关）。文档、PDF、PPT 这类会保留。
豆瓣 / 知乎尚未支持。它们没有官方接口，需要浏览器自动化——稳定性和隐私成本都高得多，而且每次改版都可能失效。我们会在核心三平台稳定后再评估，不拿"即将支持"当卖点。
任何平台只要出现「声明有数据、却一条都没抓到」，一律判为失败并报警，不会给你一份看起来成功的空结果。
这是个人数据工具，请只导出你自己的账号数据。

常见问题

它会把我数据传到云端吗？

不会。它在本机运行，抓取结果写到 ~/.selfloom/，不做遥测。除了调用你授权的平台接口，它不与任何第三方通信。

需要科学上网吗？

不需要。它访问的都是国内可直连的接口（腾讯域名、QQ 邮箱 IMAP）。唯一需要梯子的场景是你在 GitHub 上下载源码。

我不会用命令行怎么办？

我们的目标是做成"解压一个文件夹、双击一个文件"。便携包正在做，会晚于命令行版本发布。如果你现在就想用，把 npx selfloom demo 这一行复制到终端回车，不会有任何副作用。

为什么先支持这三个平台？

因为它们都不需要浏览器。这带来三个直接好处：跨平台（Windows/macOS/Linux 通吃）、能无人值守、体积小。反过来，依赖浏览器自动化的平台（豆瓣、知乎）会让包的体积和失效频率都上去——那不该是一个早期产品的重心。

免费吗？

MIT 开源，完全免费，代码全部公开。如果你觉得有用，给个 star 就是最好的支持。

我的数据会不会被写进这个页面？

不会。页面上的示例内容来自内置的虚构样例数据；页面上出现的数字是容量统计（多少本书、多少封邮件），不含任何个人内容。

30 秒看到结果

不用注册、不用授权、不联网。

第 1 步

零配置先看效果npx selfloom demo

第 2 步

接入你自己的平台npx selfloom auth weread

第 3 步

生成你的时间线npx selfloom export

📥 复制一行命令 💻 下载便携包 Windows / macOS · 即将推出 GitHub Gitee

一行命令，把你散在各平台的创作，收成一个 AI 能读 的文件。