需要基于 Readwise Reader…

适用于有 Readwise Reader 数据并希望 triage、quiz 等技能按个人阅读偏好定制输出时，构建 reader_persona.md 读者画像。

适用场景

解决思路

1. 检查是否有 Readwise MCP 工具可用（例如 `mcp__readwise__reader_list_documents`）；若可用，全程使用它们，并将此上下文传给子代理；若不可用，改用等效的 `readwise` CLI 命令（例如 `readwise list`、`readwise read <id>`、`readwise search <query>`、`readwise highlights <query>`），并把后续 MCP 工具名按需翻译为 CLI 等效命令。
2. 开场先展示简短介绍：标题为 **Build Persona** · Readwise Reader，说明会分析保存、高亮和标签，在当前目录构建 `reader_persona.md`，其他技能（triage、quiz）会用它个性化输出；先快速分析（约 1-2 分钟），之后由用户决定是否深度分析。
3. 因为会抓取大量数据，为保持主对话上下文干净，启动一个 **Task 子代理** 承担所有重活。
4. Phase 1 Quick Pass：让子代理做聚焦扫描，快速构建可靠的初始画像。
5. 并行执行所有数据抓取（一批工具调用）：4 个高亮搜索 `mcp__readwise__readwise_search_highlights`，使用 4 个宽泛查询，例如 `"ideas strategy product"`、`"learning technology culture"`、`"writing craft creativity"`、`"business leadership growth"`，每个 `limit=50`；这些是语义/向量搜索，宽泛多词查询效果好；高亮便宜且信号强，尽量广泛撒网。
6. 并行执行 4 个文档列表 `mcp__readwise__reader_list_documents`，分别来自每个非 feed location：`location="new"`、`location="later"`、`location="shortlist"`、`location="archive"`，每个 `limit=100`。
7. 如果合并结果非常稀疏（总文档 < 20），再尝试不带 location 过滤，或用 `location="feed"` 作为 fallback。
8. 文档列表只抓元数据：`response_fields=["title", "author", "category", "tags", "site_name", "summary", "saved_at", "published_date"]`；不要抓全文内容。
9. 调用 `mcp__readwise__reader_list_tags` 了解用户的组织体系。
10. 高效解析结果：不要用 Read 工具读取文档列表的大型 JSON 响应（可能 25k+ tokens，会触达 token 限制并浪费重试）；改为用一次 Bash 调用执行一个 python3 脚本，一次性提取并汇总所有数据。
11. python3 脚本应一起解析所有结果文件并输出：按 category 的文档计数；Top 20 sites、authors 和 tags；按月的保存速度；最近 3 周保存的所有文档（title、category、author、date）；高亮文本的代表性样本及其来源标题/作者。
12. 写入 `reader_persona.md` 到当前工作目录，包含这些章节：身份与角色、核心兴趣、阅读人格、当前痴迷、目标与抱负、品味与感性、反兴趣、Triage 指导。
13. 身份与角色：判断用户可能是什么人（职业、角色、行业）。
14. 核心兴趣：按频率和近期性排序的主题/话题。
15. 阅读人格：他们如何阅读（大量保存但选择性阅读？高亮很多？偏好短内容还是长内容？）。
16. 当前痴迷：过去 2-3 周保存/阅读最多的内容。
17. 目标与抱负：从模式推断他们似乎在努力实现什么。
18. 品味与感性：他们倾向的思想者和风格（反传统？实用？哲学？技术？）。
19. 反兴趣：明显缺失或回避的话题。
20. Triage 指导：给这个人推荐文档的具体指令（例如“先讲实际适用性”“联系他们对 X 的兴趣”“对 AI 内容门槛要高——只有在真正新颖时标记”）。
21. 返回 3-5 句话的画像摘要，以及文件的绝对路径。
22. 子代理速度规则：不要调用 `readwise_list_highlights`——它经常报错，且与 search 冗余。
23. 不要尝试用 Read 读取大型 JSON 工具结果文件——用 Bash 里的 python3 解析。
24. 将所有分析合并到一个 python 脚本中，不要多个顺序脚本。
25. 最大化并行工具调用；步骤 1 的每次 API fetch 都应在单个并行批次中。
26. Phase 2 Deep Pass（可选）：快速 pass 子代理返回后，向用户展示结果，并询问是否要更深入分析。
27. 如果用户同意，启动第二个子代理。
28. 第二个子代理：基于 phase 1 发现，用不同且更具体的查询再抓取 4-6 个高亮搜索（例如画像显示对 AI 工具感兴趣，搜索 `"AI agents workflows automation"`；如果读小说，搜索 `"fiction narrative storytelling"`），每个 `limit=50`。
29. 第二个子代理：使用 phase 1 结果中的 `next_page_cursor`，按 location 分页超过前 100 篇文档——每个 location 再抓取 100-200 篇，构建更大样本。
30. 第二个子代理：读取现有 `reader_persona.md`，用额外数据充实/重写它——更细致的章节、更强证据、更犀利的 Triage 指导。
31. 第二个子代理：返回变更摘要。
32. 每个子代理返回后：展示文件链接。总是告诉用户：`reader_persona.md` 已写入 `{absolute_path}`。显示完整路径，方便打开。
33. 展示画像摘要（使用子代理返回的摘要）。
34. Phase 1 后：询问用户想要 deep pass，还是 quick 版本已足够；也询问是否想调整任何内容。
35. Phase 2 后（如果运行）：展示变更内容，并询问是否想调整任何内容。
36. 如果需要调整，根据反馈直接编辑文件。
37. 确认已保存。告诉用户文件已保存，以及哪些技能现在会使用它（triage、quiz、feed-catchup 等）。

适用边界 · 注意事项

• 没有 Readwise Reader 账号、数据或无法访问 Readwise MCP/CLI 时不适用。
• 阅读库非常稀疏、几乎没有保存/高亮/标签时，难以生成有意义画像。
• 不能启动子代理或无法接受大量数据抓取与 Python 解析流程时，不适合直接使用。