weread-digest — 微信读书沉淀

Overview

微信读书里的划线和想法是原料，知识库笔记是复用资产，推文是一次性产物。这个 skill 把三者串成一条固定顺序的流水线：先落笔记，再出推文。

笔记先落盘，是因为推文只用得上一本书里的三五个判断，剩下的读完就丢了。笔记留住全部，下次写别的选题还能取。

两段流水线

第一段（必做）：微信读书 → 20-knowledge/读书/读书笔记/读《书名》小记.md 第二段（按需）：那篇笔记 → 30-outputs/tweets/ 推文草稿

用户只说「整理成笔记」就停在第一段。说「写成推文」也要先跑完第一段——笔记不存在时不许直接从划线写推文，那样这本书的原料只被消费一次。

第一段：落知识库笔记

1. 定位 bookId

• 用户给了书名 → /store/search，取 bookId
• 用户问「哪些书还没写笔记」「最近读了什么没记」→ 走下面的缺口盘点

1b. 缺口盘点（口径别搞窄了）

拉源：/user/notebooks，游标分页——首页只传 count，之后取上一页 books 最后一项的 sort 当 lastSort 再请求，直到 hasMore 为 0。不要传 offset/limit，那两个参数后端不读，会一直返回第一页。

排序：books[].sort 就是最近一次做笔记的时间戳。用户说「最近」时按它倒序，别按书架顺序。

比对时必须扫全四个位置，只扫 读书笔记/ 会产生大量假缺口（实测 269 本「缺口」里有相当一部分是这四类）：

书名匹配要容错，实测踩过的坑：

• 一字之差：微信读书《以日为镜》vs 库里《以日为鉴》。别只做精确/子串匹配，长度 ≥3 的标题要允许 1 个字的差异
• 副标题与后缀：长得好看能当饭吃吗：提升认知的33个经济学常识、（第2版）、（微信读书特别版）、（全六册）、文件名里的 z-library 后缀，比对前全部剥掉
• 拿不准的不要直接判缺口，列进「待人工确认」那一档

盲区（要说出来，不要假装覆盖了）：/user/notebooks 只返回有笔记数据的书。用户读完但一条划线都没划的书，这条路径发现不了，得另走 /shelf/sync 看 finishReading 与 readingProgress。

2. 拉原料（两个接口都要拉）

调用规范（鉴权、参数平铺）见 weread-skills skill，不在这里重复。

**skill_version 不要在本文件里写死。**每次请求都要带，值取 weread-skills/SKILL.md 顶部 frontmatter 的 version 字段，现读现取。回包里出现 upgrade_info 时按它的 message 先完成升级再重跑——这是 weread-skills 的硬规则，不是建议。（本文件下面 Quick Reference 里的版本号只是示例，照抄会过期。）

必须走 gateway 接口，不要用 weread MCP 的 weread_notes 工具。实测那个工具返回的是全书热门划线（items[].userVid 是别人、items[].totalCount 是划线人数），不是本人划线。拿它当个人笔记写出来的note 是别人的阅读痕迹。判别方法：回包里有 userVid 且各不相同的，就是热门划线。

3. 组装

按 chapters[].chapterIdx 顺序把划线归到各章，章节标题即小节标题。保留原书的章节顺序，不要按主题重排。

4. 落盘前必过保密闸

**20-knowledge/ 是 git 跟踪区，会推到公开 GitHub。**而想法字段是用户对着书自言自语写的，里面经常有真实财务数字、公司信息、身份细节。原样落盘 = 把这些推上公网。

落盘前扫一遍想法，命中就处理：

扫描词至少覆盖：税后／到手／月薪／年薪／储蓄率／存款／余额／持仓／绩效／奖金／期权／密码／key。命中后要在交付里明确告诉用户哪几条被脱敏了、原文放在哪，不要静默处理。

实测样本：《软技能》34 条想法里有 1 条写着真实税后月收入和储蓄率，直接落盘就会进公开仓库。

5. 落盘

写到 20-knowledge/读书/读书笔记/读《书名》小记.md，格式契约见 note-format.md。已存在同名文件时合并不覆盖：新划线按章节插入，原有的展开段落一个字不动。

两段之间有一道闸：想法密度

笔记落盘后先数一下：/review/list/mine 拿到几条想法。

用 /review/list/mine 的 totalCount，不要用 /user/notebooks 的 reviewCount——后者含书评、书摘、非书籍想法，不等于这本书里的划线想法。

• 想法 ≥ 8 条 → 这本书自带增量判断，直接进第二段
• 想法 1–7 条 → 边界带。看这几条是不是本人的判断/反驳/算账，是就能撑起一篇，不是就当摘录型
• 想法 0 条 → 摘录型笔记。笔记本身合格（原料留住了），但推文写不了，因为转化规范要求每篇必须有增量判断，纯划线组不出来

用绝对数不用比例：比例会误伤长书（93 条划线配 7 条想法的书，比例只有 7.5%，但那 7 条可能条条是判断）。

实测样本：《一如既往》52 条划线、1 条想法，就是摘录型。这种书要出推文只有两条路——问用户对这本书的真实看法，或者把它和用户已有的一手资产配对（真实账户、已发过的实测帖），让增量从那边来。两条路都走不通就先不写，把笔记留着。

这道闸的意义是：划线只证明你读过，想法才证明你想过。推文卖的是后者。

第二段：出推文

笔记落盘之后按你自己的转化规范执行。如果库里有这份规范文件，以它为准，本 skill 不复述；没有的话用下面这套默认值：

• 长度：单篇正文 1300–2300 汉字，硬上限 2600。超了就拆，不许压缩着塞
• 拆系列：一个值得单独成立的判断算一篇。2–3 个判断写 1 篇（做成编号小节），4 个以上拆系列，上限 6 篇
• 系列三条硬约束：一个判断只出现在一篇里；一本书只出一套系列，不许再写「核心观点提炼」这类全书总结版；每篇要能独立成立
• 增量判断（不满足就别发）：纯转述是书摘不是内容。每篇至少要有一种增量——本地化差异、一手实践反驳、改造后的可执行版、跨书对照。自检：把书名和作者名全删掉，这篇还剩什么
• 事实核查：笔记里的数字、回测、研究结论不能凭笔记直接发，正文照写、文末列 > 待核实： 块，发布前查证

Charles 本人的配置：规范在 30-outputs/X 运营/读书笔记转推文-转化规范.md，选题优先级查同目录的 读书笔记转推文-盘点与排期.md，落盘后跑 media-dashboard-gen.py 刷看板。

想法字段是这条流水线里最值钱的东西

/review/list/mine 返回的是本人当时写下的想法，它是这本书唯一不可替代的部分。划线人人都能有，想法只有一份。

处理规则：逐字保留，不润色，不改成通顺的书面语。「这段我不同意」「我试过，没用」「这里可以接上定投那套」这类半句话，正是第二段推文里的增量判断来源。洗成通稿，这本书就退化成了书摘。

想法里出现的自己的数字、经历、反驳，在笔记里用普通段落写在对应要点下面，和划线原文区分开。

Quick Reference

# 搜书拿 bookId
curl -X POST "https://i.weread.qq.com/api/agent/gateway" \
  -H "Authorization: Bearer $WEREAD_API_KEY" -H "Content-Type: application/json" \
  -d '{"api_name":"/store/search","keyword":"纳瓦尔宝典","count":5,"skill_version":"1.0.3"}'

# 拉划线（含章节）
-d '{"api_name":"/book/bookmarklist","bookId":"<bookId>","skill_version":"1.0.3"}'

# 拉本人想法与点评
-d '{"api_name":"/review/list/mine","bookid":"<bookId>","count":100,"skill_version":"1.0.3"}'

# 笔记本概览（找缺口，游标翻页）
-d '{"api_name":"/user/notebooks","count":100,"skill_version":"1.0.3"}'

Common Mistakes