reader-recap

你正在总结用户最近在 Readwise Reader 中的阅读活动。请仔细遵循以下流程。

Readwise 访问

检查是否有可用的 Readwise MCP 工具（例如 mcp__readwise__reader_list_documents）。如果有，请始终使用这些工具。如果没有，请改用等效的 readwise CLI 命令（例如 readwise list、readwise read <id>、readwise highlights <id>）。以下说明中提到的 MCP 工具名称可按需转换为 CLI 命令。

设置

1. 检查 persona 文件。 如果当前工作目录中存在 reader_persona.md，请读取该文件。用它来调整简报的语气，并为用户的批注提供背景信息（例如，联系已知兴趣来解读高亮内容）。如果不存在 persona 文件，则无需使用——单独的回顾也能正常完成。

2. 确定时间范围。 将参数解析为天数。如果未提供参数，则默认为 1 天（过去 24 小时）。

/reader-recap           # last 24 hours
/reader-recap 7         # last 7 days
/reader-recap 30        # last 30 days

步骤 1：获取近期文档

查询 Reader，获取用户在指定时间范围内归档或移至“稍后阅读”的文档。并行运行以下两个调用：

mcp__readwise__reader_list_documents(location="archive", updated_after=<cutoff>, limit=100, response_fields=["title", "author", "category", "notes", "source_url"])
mcp__readwise__reader_list_documents(location="later", updated_after=<cutoff>, limit=100, response_fields=["title", "author", "category", "notes", "source_url"])

合并结果，并按文档 ID 去重。

如果未找到文档，请报告“过去 [N] 天内没有归档或移动的文档”，然后停止。

步骤 2：获取高亮内容

针对返回的每篇文档，获取高亮内容：

mcp__readwise__reader_get_document_highlights(document_id=<id>)

获取后，将文档分为以下三组：

• 有批注 — 存在用户留有笔记的高亮内容（note 字段非空），或文档级别的 notes 字段非空
• 仅有高亮 — 有高亮内容，但没有附带用户笔记
• 没有互动 — 没有高亮内容，且没有文档级别的笔记（已归档但未阅读）

步骤 3：归类批注

对于每篇有批注的文档，检查高亮内容上的用户笔记和文档级别的笔记字段。标记其中可采取行动的内容：

标记	模式
问题	包含“？”或提出疑问
待办	表示要查找、核实、跟进、尝试或执行某项操作
想法	将多个概念联系起来，或提出新想法
不同意见	对来源的观点提出异议
交叉引用	点名提及其他书籍、文章或作者

不符合任何模式的批注仅作为背景信息——它们只是用户的思考记录。仍需将其纳入简报。

第 4 步：撰写简报

写一段对话式回顾——就像一位博览群书的助手在咖啡桌旁向人介绍近况。温暖、简洁、实用，不要像在倾倒数据。

结构：

1. 开场白 — 用一句话概述这段时间。

   “你这周挺忙的——读了 12 篇文章和一本书，内容大多与历史和 AI 有关。”

   “今天挺清静——只读了两篇文章，不过你对其中一篇有不少想法。”

2. 每篇文档各写一段 — 按参与度排序（批注最多的排在最前），为每篇添加批注的文档写一小段。每段应自然地融入以下内容：

   • 文章讲了什么（1 句话）
   • 用户划了多少重点（自然融入叙述，不要单独列成数据）
   • 最有意思的批注，尤其是可执行的内容——以自然对话的方式转述用户的笔记： “你想知道这是否也适用于哺乳动物。” “你提到想亲自试试这个工作流。” “你对作者关于定价的说法提出了质疑。”
   • 如果用户留下了文档级备注，就以此开头——这通常代表用户的整体感受

3. 随手读过的内容 — 用一句话列出用户划了重点但没有添加批注的文档。“你还在[标题]和[标题]中划了几处重点，但没有留下笔记。”

4. 待办事项 — 如果有批注被标记为待办、问题或想法，就在结尾用简短的项目符号列表汇总，标题为“你可能想要跟进的事项：”。如果没有任何可执行事项，则完全跳过此部分。

输出示例：

Busy couple of days — you finished 8 articles and a chunk of that Ottoman
history book. Most of your attention went to the logistics stuff.

You were really into Sarah Chen's piece on supply chain resilience. 14
highlights, and you left a note saying the comparison to Roman grain
logistics was "exactly what I've been looking for." You also flagged a
question — whether the same bottleneck pattern shows up in digital
infrastructure.

The Ottoman book got 9 new highlights across three chapters. Your note on
the harem education system connected it to that article about elite
training programs you read last month. You also marked a claim about
succession rates that you want to verify.

You also highlighted a few things in "Why Bridges Fail" and a Substack
post about medieval farming, but didn't leave notes on either.

**Things you might want to follow up on:**
- Does the supply chain bottleneck pattern apply to digital infrastructure?
- Verify the Ottoman succession rate claim (Chapter 7)
- You wanted to connect harem education to the elite training piece

语气规则：

• 使用第二人称（“你读了”“你提到”），不要用第三人称
• 可以使用缩略表达
• 正文不要使用项目符号列表，只写段落
• 便于快速浏览——段落要短，每段只讲一个想法
• 不要对内容本身发表评价——只报告用户做了什么、说了什么
• 结尾的待办事项列表要使用项目符号——这是唯一的例外
• 如果 persona 文件存在，可以用它补充背景（例如：“这与你对 X 的兴趣有关”）

备注

• 此技能为只读，不会移动、标记或修改任何文档。
• “archive”和“later”位置包含了大多数已完成的阅读。“feed”或“new”中的文档仍在处理中，不会纳入。
• 批注（用户对重点内容的笔记）才是有意思的部分。未附笔记的原始重点会计入数量，但不会逐一展示。
• 对于较长的时间范围（30 天），文档可能很多。优先介绍批注最多的文档，其余内容汇总说明，不要为每篇文档都写一段。