ExtractWisdom

自定义

执行前，请检查以下位置是否存在用户自定义设置： ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/ExtractWisdom/

如果此目录存在，请加载并应用其中找到的任何 PREFERENCES.md、配置或资源。这些内容优先于默认行为。如果此目录不存在，则使用技能默认设置。

ExtractWisdom — 动态内容提取

功能

从视频、播客、访谈和文章中提取精华观点。它会先阅读内容，识别其中实际包含哪些类型的见解，然后根据内容构建自定义章节，而不是每次都套用相同的标题。提供从「即时」到「全面」的五种深度级别。输出始终以一句话总结、「如果你只有 2 分钟」清单和值得关注的参考资料结尾。

问题所在

静态提取模板会强行把每一篇内容塞进相同的框架——IDEAS、QUOTES、HABITS、FACTS——结果就是安全主题演讲和商业播客看起来一模一样，真正的精华也被压缩成泛泛的要点。输出读起来像读书报告，而不像一位聪明的朋友在告诉你哪些内容让他们停下来思考。此技能会根据内容调整章节，并用你实际会说出口的方式来撰写要点，让逆向观点和首次揭示的见解得以保留，而不是被淡化。

工作原理

此技能不会使用静态章节（IDEAS、QUOTES、HABITS……），而是识别内容中实际存在的见解领域，并据此构建自定义章节。

编程访谈会得到「编程哲学」和「开发者工作流技巧」。商业播客会得到「逆向商业观点」和「金钱哲学」。安全主题演讲会得到「威胁模型洞察」和「防御策略」。章节会随内容调整，因为章节由内容决定。

适用场景

• 分析 YouTube 视频、播客、访谈和文章
• 用户说「提取精华」「这里面有什么有意思的」「关键要点」
• 处理任何需要提取精华内容的素材
• 标准提取模式容易遗漏精华时

深度级别

根据需要选择不同的提取深度。未指定级别时，默认为 Full。

级别	章节数	每节要点数	结尾章节	适用场景
Instant	1	8	无	快速获取重点。一个精彩章节。
Fast	3	3	无	30 秒内快速浏览。
Basic	3	5	仅一句话总结	扎实概览，不深入挖掘。
Full	5-12	3-15	全部三个	默认级别。完整提取。
Comprehensive	10-15	8-15	全部三个 + 主题与关联	最大深度。内容不遗漏。

调用方式：「extract wisdom (fast)」、「extract wisdom at comprehensive level」，或仅输入「extract wisdom」使用 Full。

Comprehensive 额外内容：

• 结尾章节 Themes & Connections：识别 3-5 条贯穿多个章节的主线。这些不是摘要，而是演讲者可能都没意识到自己揭示的深层模式。
• 优先保证覆盖广度。每个重要的见解领域都应有自己的章节。
• 不要为了节省篇幅而合并章节。如果内容支持 15 个章节，就使用 15 个。

所有级别都遵循相同的语气、风格规则和质量标准。 唯一变化的是结构。Instant 提取的每条要点也应和 Comprehensive 一样有力。

工作流路由

工作流	触发条件	文件
Extract	“extract wisdom from”、“analyze this”、YouTube URL	Workflows/Extract.md

语气规则（至关重要）

标准语气参考：LIFEOS/USER/PRINCIPAL/WRITINGSTYLE.md——请阅读此文件，了解完整的语气定义。这些要点读起来应该像用户和朋友喝咖啡时聊天。不要写成压缩的信息碎片，也不要写成巧妙的一句话总结。要像真实的口头观察。

三个层次——我们的目标是第 3 层：

第 1 层（糟糕——文档腔）：

• 发言者探讨了在 Agent 式 AI 开发背景下，自我修改软件的重要性
• 有人指出，财务上的成功超过某个门槛后，收益会递减
• 有人强调，“氛围编程”和“Agent 式工程”之间的区别很重要

第 2 层（好一些——但仍然像“聪明的要点”）：

• 他基本上是意外做出了能自我修改的软件——只是让 Agent 了解了自己的源代码
• 钱的边际效用会递减。芝士汉堡就是芝士汉堡，再有钱也一样。
• “氛围编程是个贬义词”——他称自己做的是 Agent 式工程，而且只有凌晨 3 点以后才会氛围编程

第 3 层（对了——这就是我们想要的，口语化，像用户本人的声音）：

• 他原本并没打算做出能自我修改的软件。他只是让 Agent 看到了自己的源代码，然后 Agent 就开始自己修复了。
• 钱到了一定程度就不再重要。芝士汉堡就是芝士汉堡，再有钱也一样。
• 他把氛围编程称作贬义词。他做的是 Agent 式工程。只有凌晨 3 点以后，他才会氛围编程，而且早上醒来就后悔了。

**第 2 层和第 3 层的区别：**第 2 层是用破折号压缩信息。第 3 层则是你真正会说出口的话。句子长短有变化，让一个想法充分展开。别为了显得聪明而刻意雕琢，只要清楚、直接，还带一点个人色彩。

第 3 层的关键特征：

• 大声读出来也自然
• 句子长短有变化，有些短，有些长一些
• 克制，让内容本身承载分量
• 用句号，而不是破折号，让观点自然落下
• 有鲜明观点（“钱到了一定程度就不再重要”），而不只是传递信息
• 读者应该想“我想看看这个”，而不是“我看完摘要了”

要点——语气约定

一句话目标：各部分要紧扣具体内容，要点读起来像口头表达，而不是摘要。上面的三个层次就是标准——每个要点都要达到第 3 层。好的要点具备以下特点：

• **像口头表达，不像摘要。**读起来要像你在告诉朋友自己刚看了什么，而不是新闻稿或压缩版推文。
• **具体胜过模糊。**要包含实际细节、引语或数字——写“芝士汉堡就是芝士汉堡，再有钱也一样”，而不是“他谈了钱”。如果发言者的原话已经很贴切，就用原话。
• 洞见胜过罗列。“他选了一门自己都不喜欢的语言，因为它的生态适合 Agent”，胜过“他用 Go 写 CLI”。矛盾或反转之处才是智慧所在。
• **8 至 16 个词，长度有变化。**长短句搭配；不同想法之间用句号，不用破折号。逐字引用不受此限。
• **人的时刻也很重要。**倦怠、怀疑、打动发言者的事，同样蕴含智慧，即使它们并非“技术内容”。

**必须包含逆向观点。**如果发言者提出了真正尖锐的观点（例如“去他的 MCP”、“X 已经死了”、“Y 被过度吹捧了”），就必须原样保留，不能弱化。尖锐的观点最让人印象深刻，也最值得分享。漏掉任何一个，哪怕是在不同草稿之间漏掉，都说明提取失败。

章节——根据内容调整

章节名称应贴合本篇内容，而不是从固定列表中挑选。编程面试的章节可以叫“编程哲学”；商业播客的章节可以叫“金钱哲学”；安全演讲的章节可以叫“威胁模型洞见”。像杂志编辑一样为章节命名——“80% 的应用都将消亡”，而不是“技术预测”。章节名称应该勾起读者的好奇心。

• 章节数量应遵循深度级别表。
• 每个章节至少需要 3 个有力的要点（Fast 除外：3 个精炼要点本身就是整个章节）。找不到 3 个？那就把它合并到相关章节中。
• 如果内容中有值得引用的精彩时刻，就加入“令人耳目一新的引言”；如果确实有新颖观点，就加入“首次揭示”。
• 不要设置清单式章节——单纯罗列事实毫无洞见。深入探讨这些选择为何重要，或者将其合并到哲学章节中。
• 不要拆散本应放在一起的内容。不要在不同草稿之间丢掉最精彩的内容——早期版本中发现的犀利观点或惊艳时刻，必须保留到最终稿中。

收尾章节

根据深度级别决定要包含哪些收尾章节：

级别	收尾章节
Instant	无
Fast	无
Basic	一句话要点，仅此一项
Full	一句话要点 + 如果你只有 2 分钟 + 参考资料与延伸探索
Comprehensive	上述全部 + 主题与关联

一句话要点——用 15-20 个词概括整篇内容中最重要的一点。

如果你只有 2 分钟——列出 5-7 条绝对必须了解的要点，精选中的精选。

参考资料与延伸探索——列出值得进一步了解的人物、项目、书籍、工具和观点，并简要说明其背景。

主题与关联（仅限 Comprehensive）——列出 3-5 条贯穿多个章节的主线，即演讲者或许尚未意识到自己揭示的深层模式。综合提炼，而非总结。

输出格式

# EXTRACT WISDOM: {Content Title}
> {One-line description of what this is and who's talking}

---

## {Dynamic Section 1 Name}

- {bullet}
- {bullet}
- {bullet}

## {Dynamic Section 2 Name}

- {bullet}
- {bullet}

[... more dynamic sections ...]

---

## One-Sentence Takeaway

{15-20 word sentence}

## If You Only Have 2 Minutes

- {essential point 1}
- {essential point 2}
- {essential point 3}
- {essential point 4}
- {essential point 5}

## References & Rabbit Holes

- **{Name/Project}** — {one-line context of why it's worth looking into}
- **{Name/Project}** — {context}

质量检查

交付前，请确认：

• 章节内容具体贴合本篇，而非泛泛而谈
• 没有任何要点听起来像是委员会写出来的
• 每个要点都包含具体细节、引言或洞见，而不是含糊的总结
• 章节名称自然、吸引人，像新闻标题，而不是分类标签
• 章节数量符合深度级别（Instant=1，Fast/Basic=3，Full=5-12，Comprehensive=10-15）
• 收尾章节符合深度级别（见“收尾章节”表）
• 没有要点以“The speaker”或“It was noted that”开头
• 每个章节中以“He”或演讲者姓名开头的要点不超过 3 条
• 每个要点不超过 25 个词
• 没有清单式章节（只罗列事实、没有洞见）
• “如果你只有 2 分钟”中的每条要点都少于 20 个词
• 读完输出后，读者会想去阅读或观看原内容

注意事项

• 根据内容调整章节，意味着输出结构会因输入类型而异。 不要期待播客和文章采用完全相同的输出格式。
• 提取 YouTube 内容时，应先使用 fabric -y URL 获取文字稿，再提炼其中的洞见。
• 长内容可能需要分块处理。 不要试图一次性从 3 小时的播客文字稿中提炼洞见。

示例

示例 1：提取 YouTube 访谈内容

User: "extract wisdom from this Marcus Hutchins interview"
→ Uses `fabric -y URL` to get transcript
→ Content-adaptive extraction (interview format)
→ Returns: key insights, surprising claims, actionable takeaways
→ ~45 seconds

示例 2：提取文章内容

User: "extract the key insights from this blog post"
→ Fetches content via WebFetch
→ Adapts sections to article format
→ Returns distilled wisdom with source attribution

执行日志

完成任何工作流后，追加一条 JSONL 记录：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"ExtractWisdom","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

将 WORKFLOW_USED 替换为执行的工作流，将 8_WORD_SUMMARY 替换为对输入内容的简短描述，并将 SECONDS 替换为大致耗时（秒）。如果工作流失败，则记录 status: "error"。