Collect Stone Lab

Wisereads → 墨家-张良周报：实现方案

把 Readwise 的 Wisereads 做成适合墨家-张良群阅读的判断型周报，并确保结论基于原始内容阅读证据。

作者：墨子 · 更新于 2026-03-17 · 这是一份阅读版实现方案，适合完整浏览，不是群消息压缩稿。

Wisereads → 墨家-张良周报：实现方案

先说结论

这件事不该做成“把 Readwise 周刊翻译后转发到群里”，而应该做成一条 有原文阅读证据的判断型周报流水线。

输入是每周一期 Wisereads。 输出不是链接合集，而是：

  1. 一份完整研究稿
  2. 一份适合 Telegram 群阅读的短版周报
  3. 一个可长期查看的 HTML 页面

其中最关键的一条规则是：没有读到原始内容，就不能进入核心判断区。

为什么不能直接改写 Wisereads

Wisereads 本身的定位更像：

  • 内容发现
  • 编辑品味展示
  • 引导加入 Readwise Reader

它的结构是稳定的：文章、视频、线程、PDF、书、RSS 各来一条或几条。

这套结构对“收藏”有用，对“理解”不够好。

主要问题有三个：

1. 它按媒体类型分组，不按主题分组

文章放一起，视频放一起，线程放一起。 对编辑方便，对读者不方便。

读者真正想知道的是：

  • 这期到底在讲什么
  • 哪几条是一组
  • 哪些最值得先看
  • 读完该形成什么判断

2. 它给选择，不给足够强的判断

它会告诉你“这周值得看什么”，但不会帮你把这些内容收束成一个清晰主线。

3. 它默认你之后会自己去读

但墨家-张良群里的阅读场景不是这样。 群里更需要：

  • 快速吸收
  • 明确主次
  • 能带走判断
  • 有原始链接可追溯

所以如果要给群里做周报，必须从“链接周刊”改成“判断周报”。

目标产物

建议固定成双层产物。

产物 A：完整研究稿

作用：

  • 留证据
  • 可复查
  • 可继续加工
  • 可作为每周归档

建议目录：


reports/wisereads/2026-03-17-vol-134.md

产物 B：群内短版周报

作用：

  • 适合 Telegram 群阅读
  • 长度可控
  • 快速获取重点

建议结构：

  1. 本周一句话
  2. 3 个核心判断
  3. 值得深读 3 条
  4. 快读补充
  5. 原始链接

产物 C：Lab HTML 页面

作用：

  • 适合完整阅读
  • 比 Telegram 长消息更舒服
  • 可长期分享和回看

也就是说，最终不是只发一条群消息，而是：

研究稿 → HTML 页面 → 群消息压缩版

最重要的规则：原文分级

为了保证“真的读过原始内容”，每个条目都要有读取状态。

full

已获取原始正文、完整线程、完整 transcript 或可提取 PDF 正文。

这类内容可以进入：

  • 核心判断
  • 值得深读
  • 本期结论

partial

拿到的是预览、节选、片段、部分正文。

这类内容只能进入：

  • 延伸阅读
  • 辅助判断

不能假装成完整阅读。

meta

只读到 issue 页面简介。

这类内容默认：

  • 不进入正文核心区
  • 或必须显式标注“未完整获取原文”

一句话：

核心 3 条，必须尽量来自 full。

整体流程

建议拆成 4 层。

第 1 层：发现最新一期

任务：

  • 定位最新 Wisereads issue
  • 提取本期所有条目
  • 输出结构化清单

示意：


[
  {
    "type": "article",
    "title": "The Self-Help Trap",
    "url": "https://tim.blog/...",
    "status": "pending"
  }
]

通常每期会有：

  • 3 篇文章
  • 1 个 YouTube 视频
  • 1 个 X 线程
  • 1 个 PDF
  • 1 本书或预览
  • 1 个 RSS 推荐

第 2 层：抓原始内容并落盘

这是整个系统最重要的一层。

建议目录：


data/wisereads/vol-134/
  manifest.json
  raw/
  notes/

manifest.json 要记录什么

每个条目至少包含：

  • title
  • type
  • original_url
  • source_site
  • fetch_status: full / partial / meta / failed
  • content_path
  • fetched_at
  • word_count
  • note_path

raw/ 存什么

按来源类型抓取：

  • 文章：正文 markdown/text
  • YouTube：transcript
  • X：完整 thread 文本
  • PDF：提取后的正文文本
  • Book preview：可拿到多少算多少，但要标记 full/partial
  • RSS：保存 issue 引用的具体文章，而不是整个 feed

notes/ 存什么

每条内容都生成一份简短笔记，固定四段：

  1. 这篇讲了什么
  2. 最关键的观点是什么
  3. 它和本期主题是什么关系
  4. 对墨家-张良群有什么价值

这一步非常关键，因为它是从“抓内容”进入“做判断”的桥。

第 3 层：生成完整研究稿

完整研究稿是后面所有产物的母稿。

建议结构：

本期主命题

一句话定义这一期真正讲什么。

条目级笔记

逐条整理，每条都标明读取状态。

综合判断

收束成：

  • 本周 3 个核心判断
  • 值得深读 3 条
  • 快读补充若干
  • 对群内读者的行动建议或提醒

这一层是“编辑工作”最重的地方。

第 4 层：压缩成群内周报

群里版本不能太长。

建议控制在：

  • 总长度 1800-3200 中文字符
  • 核心信息 3-5 个点
  • 每条解释不超过 2 行

推荐结构：

【本周一句话】

一句判断，先定主线。

【3 个核心判断】

每条 1-2 句。

【值得深读 3 条】

每条包含：

  • 标题
  • 为什么值得看
  • 原始链接

【快读补充】

2-4 条就够。

【原文入口】

保留关键原链接，方便继续看。

这里的重点不是覆盖全部内容，而是帮助读者更快抓住重点。

为什么还需要 HTML 页面

因为 Telegram 长消息有几个天然问题：

  • 阅读体验一般
  • 不适合长段分析
  • 不适合回看和长期分享
  • 链接一多会显得杂乱

所以更合理的做法是：

  • 群里发短版摘要
  • 附一个 lab HTML 页面链接

这样群里负责分发，HTML 负责完整阅读。

对你来说，这会更像一份真正的“周报产品”，而不是一条机器人消息。

自动化建议：先半自动，再全自动

不要一上来就完全自动发群。

Phase 1：半自动

自动完成：

  • 抓取 issue
  • 抓原文
  • 生成 manifest
  • 生成研究稿
  • 生成 HTML
  • 生成群消息草稿

然后由你确认后再发送。

这是最稳的起点。

Phase 2：准自动

如果连续跑 3-4 期都稳定，再放宽到：

  • 核心 full 条目达到阈值
  • HTML 成功生成
  • 周报草稿结构完整

满足条件时自动发群；否则只生成待确认稿。

Phase 3：全自动

只有在以下都稳定后才建议：

  • 原文抓取成功率高
  • 输出风格稳定
  • 群里反馈确认有价值
  • 失败降级做得足够清楚

失败降级规则

这部分必须提前定，不然后面容易假装完成。

情况 1：某些原文抓不到

处理方式：

  • 降级为 partial 或 meta
  • 不进入核心判断区
  • 在研究稿里显式标注

情况 2：视频没有 transcript

处理方式：

  • 先尝试字幕
  • 再考虑转录
  • 如果没有可靠文本，不做深度判断

情况 3：X 线程只拿到首条

处理方式：

  • 标记 partial
  • 不把它当作完整线程阅读

情况 4：整期抓取不完整

处理方式：

  • 允许生成“本周草稿版”
  • 不自动发群
  • 需要人工确认

这套规则的目的只有一个：

不要把没读过的东西，写成读过。

对墨家-张良群的内容定位

这份周报不应该只是“互联网内容精选”，而应该始终回答一个隐含问题：

这些内容对 AI builder、产品、工程、自动化、知识工作有什么意义？

也就是说，每条内容最好都不只回答“讲了什么”，还要补一句：

  • 对我们意味着什么
  • 它改变了什么判断
  • 它更像机会、风险，还是方法提醒

这样才是“张良群周报”，而不是任何人都能替代的搬运内容。

推荐的数据流


Wisereads issue
  -> 提取条目
  -> 抓原始内容
  -> manifest + raw files
  -> 条目笔记
  -> 完整研究稿
  -> HTML 页面
  -> 群内短版摘要
  -> Telegram 推送

目录建议


reports/wisereads/
data/wisereads/
collect-stone-lab/pages/

更具体一点：


reports/wisereads/2026-03-17-vol-134.md
data/wisereads/vol-134/manifest.json
data/wisereads/vol-134/raw/*
data/wisereads/vol-134/notes/*
collect-stone-lab/pages/wisereads-vol-134.html

建议的验收标准

先拿 Vol.134 做第一期样稿。

验收 1：证据完整性

  • 每个条目都有 manifest 记录
  • 至少 3 个核心条目是 full
  • 无法完整抓取的条目有清晰标记

验收 2：阅读体验

  • HTML 页面可顺畅阅读
  • 群消息能在 1-2 分钟内读完
  • 原始链接可追溯

验收 3：内容价值

  • 不是简单摘要
  • 有明确主命题
  • 有 3 个以上清晰判断
  • 能看出“这对我们意味着什么”

验收 4：流程可复用

  • 目录结构固定
  • 每周可重复运行
  • 遇到抓取失败有降级路径

我的建议

先不要急着直接上每周自动推送。

更稳的路径是：

第一步

先把 Vol.134 做成一套完整样稿：

  • manifest
  • raw 内容
  • notes
  • 研究稿
  • HTML 页面
  • 群内摘要版

第二步

再把它抽象成固定脚本和 cron。

因为你现在最该验证的不是“能不能发群”，而是：

  • 原文抓取是否稳定
  • 输出是否真有判断价值
  • 这份周报是否形成了你的编辑辨识度

一句话收尾

这件事真正要做成的，不是一条自动推送消息，而是一条：

从 Wisereads 输入，到原文证据，到编辑判断，到 HTML 和群内分发的完整内容生产线。

如果要继续往下走，下一步最值得做的是：先把 Vol.134 真正跑通一遍，验证 manifest、原文抓取、研究稿、HTML 和群内短版是否能形成完整闭环。