需要把 Readwise Reader…

适用于已有 Readwise Reader 高亮和阅读库，想写一篇不只是摘要、而能结合跨书连接形成原创长篇书评的场景。

适用场景

解决思路

1. 检查 Readwise MCP 工具是否可用，例如 `mcp__readwise__reader_list_documents`；若可用，全程使用 MCP 工具。
2. 若 MCP 不可用，改用等价的 `readwise` CLI 命令，例如 `readwise list`、`readwise read <id>`、`readwise highlights <id>`、`readwise search <query>`；把下文 MCP 工具名翻译为 CLI 等价命令。
3. Setup：检查当前工作目录是否存在 `reader_persona.md`；若存在则读取，用它理解用户兴趣、阅读目标和语气，以决定书评框架、优先连接和用户关心点。
4. 若不存在 persona 文件，则跳过并继续；如果从高亮中看不出用户读这本书的目的，询问用户。
5. 将输入参数解析为书名或搜索词，例如 `/book-review Merchant Kings`、`/book-review 7 Powers`。
6. Phase 1.1：在 Reader 中搜索目标书：`mcp__readwise__reader_search_documents(query='[book title]', category_in=['epub', 'pdf'])`。
7. 如果无结果，扩大到所有类别；如果有多个匹配，列出并让用户选择。
8. Phase 1.2：获取该书高亮：`mcp__readwise__reader_get_document_highlights(document_id='[book_id]')`。
9. 阅读每一条高亮并计数；如果少于 10 条，警告用户可能没有足够材料写有深度的书评，并询问是继续还是等待。
10. Phase 1.3：获取完整文档详情：`mcp__readwise__reader_get_document_details(document_id='[book_id]')`。
11. 从文档详情中拉取标题、作者、摘要、封面图，供最终输出使用。
12. Phase 2：将每一条高亮处理成原子主张（atomic claim），把『我高亮了一段』变成结构化、可搜索的研究材料。
13. 对每条高亮：阅读高亮文本和用户的笔记/标注。
14. 对每条高亮：写一个现在时陈述句主张，尽量控制在 10 个词以内。
15. 对每条高亮：如果用户留了笔记，让主张偏向笔记关注的内容。
16. 主张质量标准：好主张是具体、可搜索的事实或断言，例如 `chimney sweeps died of scrotal cancer from coal soot`、`Ottoman harem trained slave girls as elite bureaucrats`、`monsoon winds enabled global maritime trade`。
17. 主张质量标准：坏主张是模糊或泛泛的，例如 `coal mining had health consequences`、`the author discusses Ottoman succession`、`interesting point about slavery`。
18. 处理完所有高亮后，复查完整主张列表；拒绝并重写：泛泛/无聊的，例如 `author discusses X`。
19. 拒绝并重写：重复的，两条主张换个说法说同一件事时合并。
20. 拒绝并重写：模糊的，不读原高亮就无法独立成立的主张。
21. 将主张按主题分组，作为工作列表；这将成为大纲。
22. Phase 3：对 Phase 2 的每个主要主题簇，在用户完整 Reader 库中搜索相关内容。
23. Phase 3.1：对每个主题簇（目标 3-6 个主题）做主题搜索：`mcp__readwise__reader_search_documents(query='[theme keywords]', limit=20)`。
24. 从热门命中中拉取高亮：`mcp__readwise__reader_get_document_highlights(document_id='[related_doc_id]')`。
25. 搜索时寻找：来自其他来源、能强化某个主张的支持证据。
26. 搜索时寻找：能让该书论点复杂化的矛盾材料。
27. 搜索时寻找：来自不同领域的平行案例，例如用户在生物学读到 X、书中对经济学说了同样的事。
28. 搜索时寻找：用户在相关文档的笔记/标注中体现出的既有思考。
29. Phase 3.2：作者搜索：`mcp__readwise__reader_search_documents(query='[book author name]')`。
30. 检查用户是否读过同一作者的其他作品；先前语境能丰富书评。
31. Phase 3.3：对相关文档中的每条相关高亮，按 Phase 2 同样方式提取主张。
32. 给相关主张打上来源文档标签，以便正确引用。
33. 阶段结果应包含：该书主张（Phase 2）按主题分组；来自更广阅读库的相关主张（Phase 3）映射到同一主题；以及对用户阅读支持、复杂化或延伸该书论点的判断。
34. Phase 4：用网络研究补充用户阅读库未覆盖的空白；保持聚焦——阅读库研究是核心，网络研究是补充。
35. 搜索学术来源、作者访谈、其他书评。
36. 寻找覆盖同一主题的 Substack 作者或博主。
37. Phase 5：写书评；优秀书评包含三要素：Summary（总结）——展示书讲什么、为什么有趣；没有它读者会困惑。
38. Critique（批评）——给出实际的质量与同意度判断；没有它就不是书评。
39. Original ideas（原创想法）——把书与用户阅读中的更大模式连接；没有它没人会特别印象深刻。
40. 原创想法来自 Phase 3——用户阅读库中的相关高亮；这是该技能的全部重点。
41. 按结构写：开头说明书是什么、为什么重要——用具体事实或场景，不用模糊钩子；如果文档笔记中没有上下文，留 `%% TODO %%` 让用户补充怎么发现这本书、为什么读它。
42. 按结构写主题章节 1：`## [Thematic section 1 — informative header, not clever]`。
43. 在主题章节中：总结书在该主题上的论点；使用书中高亮的块引用。
44. 在主题章节中：然后扩展——引入用户其他阅读中的相关材料；这是书评超越摘要的地方，即综合。
45. 引用格式：`> 'Block quote from the book' — Author, *Book Title*`。
46. 如果用户也在 `[Related Document]` 中高亮了支持/复杂化本书的内容，自然地织入；引用来源时链接到原始来源 URL，而不是 Reader 链接。
47. 主题章节 2 用同样模式：书的论点 → 用户的相关阅读 → 综合；每个章节都应推进一个论证，而不只是罗列事实。
48. 主题章节 3+ 继续；按主题组织，不按章节组织；每个章节至少要与书外某物有一个连接。
49. 写 `## What the Book Gets Wrong (or Misses)`：诚实批评；在用户其他阅读与书矛盾或使之复杂化时，用其作为证据；这是相关文档研究回报最大的地方。
50. 写 `## Further Reading`：用 `[embedded link](url)` 列出值得探索但未在上文链接、且与书评核心主题相关的来源，并附描述。
51. 语气规则：你是为用户起草，不是扮演用户。
52. 不要制造情绪——不要写 `I was struck by`、`I was fascinated to learn`；陈述事实，用户自己加反应。
53. 不要制造个人细节——不要写 `this reminded me of my childhood`；如果用户在高亮笔记中写了什么，就引用它；否则留 `%% TODO %%`。
54. 留出明确空白——用 `%% TODO: [what the user should add] %%` 标记个人钩子；这些提示用户需要填入自己的经验。
55. 对空白诚实——`I don't know` 比含糊其辞好；如果不确定，就说出来或留 TODO。
56. 用第一人称——你写的是用户将编辑的草稿，不是关于用户的报告。
57. 如果 persona 文件存在，用它决定优先哪些连接、哪种框架对用户自然；但仍要为不确定的个人细节留 TODO。
58. 长度：偏长。对一本有分量的书，2,000-10,000 词；ACX 比赛数据表明更长且含真实洞见的书评表现更好；深度 > 简短，只要每段都值得存在。
59. 如果用户高亮稀疏，10-20 条，目标改为 1,000-2,000 词。
60. 链接与来源：目标书首次提及时使用 Bookshop.org 链接。
61. 只用真实 URL——绝不留 `(url)` 或 `(link)` 这类占位链接。
62. 引用用户 Reader 库中的相关文档时，链接到原始来源 URL（来自文档详情），不是 Reader URL。
63. 偏向无需付费墙即可全文阅读的网页来源，如 Substack 或开放获取 PDF；不要引用需要购买书才能读的来源。
64. Phase 6 质量门：单独一遍，不要跳过，不要与 Phase 5 合并。
65. 重读完整草稿并修复每一处禁用词汇：Additionally → `Also` 或重组；Crucial / Pivotal / Key (adj) → 具体说明为什么重要；Delve / Delve into → `examine`、`look at`，或直接开始；Enhance / Fostering → 具体说明什么改进了；Landscape (abstract) → 说出实际领域；Tapestry (figurative) → 说出实际模式；Underscore / Highlight (verb) → 直接陈述要点；Showcase → `shows`、`demonstrates`；Vibrant / Rich (figurative) → 具体化；Testament / Enduring → 直接陈述事实；Groundbreaking / Renowned → 具体说明哪里值得注意；Garner → `get`、`earn`、`attract`；Intricate / Intricacies → `complex` 或描述实际复杂性；Interplay → `relationship`、`tension`，或描述它；Serves as / Stands as → 用 `is`；Nestled / In the heart of → 直接命名地点。
66. 禁用结构：`Not just X, it's Y` / `Not A, but B` → 直接陈述 Y；Rule of three，如 `innovation, inspiration, and insights` → 使用内容实际需要的项数；`-ing` 分析，如 `highlighting the importance of...` → 直接陈述重要性；`From X to Y` 虚假范围 → 列出实际项目；同义词轮换，如 protagonist/hero/central figure → 选一个词，重复使用；`Despite challenges, the future looks bright` → 陈述实际情况；`Exciting times lie ahead` → 用具体事实结尾；`X wasn't Y. It was Z.` 戏剧性揭示 → 合并成单个正面陈述；`The detail that stopped me in my tracks` → 从事实开始；`genuinely revolutionary` → 使用具体描述词；任何为了听起来深刻而写的夸张单句 → 删除；`I'd forgotten I knew` → 删除，绝不要把知识框架成重新发现。
67. 6a：在草稿中 grep 上述所有禁用词/模式并修复每一处匹配。
68. 6b：检查链接——每个来源都有真实 URL；没有占位符。
69. 6c：检查破折号密度——每节最多 2-3 个 em dash；多余的改成逗号、冒号、句号。
70. 6d：检查词语重复——任何词在单个段落出现 3 次以上；替换或减少。
71. 6e：读开头段——听起来像人还是像 AI 在总结书？如果是后者，重写。
72. 6f：验证每个章节都连接到书外材料；如果某节只是纯总结没有综合，加入相关阅读库连接或删掉。
73. Phase 7：发布到 Reader：使用 `mcp__readwise__reader_create_document` 创建新文档。
74. 发布参数：`url='https://reader-review.internal/[slug]-[ISO-timestamp]'`。
75. 发布参数：`title='[book title] — Review Draft'`。
76. 发布参数：`author='Ghostreader'`。
77. 发布参数：`category='article'`。
78. 发布参数：`summary='Review draft based on [N] highlights from [Book Title] and [M] related documents'`。
79. 发布参数：`html='[converted HTML of the review]'`。
80. 发布参数：`notes='DRAFT for editing. Based on highlights from: [list source document titles]'`。
81. 返回文档 URL 给用户。
82. 为什么不同于摘要：Phase 3 库搜索的全部意义是书评应包含书作者从未有过的想法；用户的阅读历史是独特透镜。
83. 示例：用户读了关于罗马后勤的书和供应链管理的书 → 书评以两本书单独都做不到的方式连接它们。
84. 示例：用户在不同来源高亮了矛盾主张 → 书评用用户已经觉得有说服力的证据挑战该书。
85. 示例：用户在无关文章的高亮上留了笔记，结果相关 → 书评浮现出用户可能未自觉建立的联系。
86. 这是获得『原创想法』的方式——区分合格书评和令人印象深刻书评的第三要素；用户的阅读库就是原创思考。
87. 错误处理：书中在 Reader 找不到 → 报告尝试过的搜索词，询问正确标题或文档 ID。
88. 错误处理：少于 10 条高亮 → 警告可能不够；询问是否继续。
89. 错误处理：找不到相关文档 → 继续做仅基于本书的书评，但警告会更偏摘要；更依赖网络研究。
90. 错误处理：Reader 创建失败 → 草稿文本已经生成；以 markdown 输出，让用户手动保存。
91. 错误处理：任何意外失败 → 说明什么失败、已经完成了什么、部分输出在哪里。

适用边界 · 注意事项

• 没有 Readwise Reader 访问权限，或无法使用 Readwise MCP 工具/CLI 命令时。
• 目标书少于 10 条高亮且没有足够补充材料时，可能不值得继续写长评。
• 只想写纯摘要或不需要结合个人阅读库做原创连接时。