【Agent Skills实战】我写了一个从 Claude Code 历史对话里挖 Skill 的 Skill

我是 Claude Code 的重度用户，平时很多文字活 - 写博客、写教程 - 都在它上面做。用久了会发现一件事：有些工作我在反复地做。比如反复指导它调整某一类内容；比如它基于某个 Skill 产出的东西，每次都要做几乎一样的修改。

这种“怎么又来一遍”的感觉，其实是个信号 - 说明这里有个 Skill 可以新建、或者可以改，让下次更顺。可这些信号都散在一场一场过去的对话里，躺在 ~/.claude/projects 下，平时不会有人回头去翻。

这篇文章分享我为这件事做的两个 Skill - 帮我回头看这些对话，判断出哪里值得沉淀成一个 Skill。

两个 Skill，一条流水线

这是两个 Skill，分两层。

claude-session-manager 是导出层，把 Claude Code 那些没法直接看的会话文件，转成整理过的 Markdown。mining-session-skills 是判断层，读这些导出的 Markdown，回答一个问题 - 这次对话里，有没有值得做成 Skill 的东西？

JSONL 会话 → [导出] → 可读的 Markdown → [挖矿] → 提案：新建 / 更新 Skill

为什么要分两层？因为这两件事是不一样的活。导出是数据清洗，挖矿是带判断的分析。拆开，每个 Skill 都小、都专一，第二个还能直接复用第一个的成果。

为什么先导出一遍

原始会话文件就在那，为什么不直接读，非要先导出一道？

直接基于原始 JSONL 来做，其实也不是不行 - 内容都在里面，grep、解析都能跑。只是它又重又杂，处理起来不划算。我用一个真实的会话量过：原始 JSONL 大约一百五十万 token，整篇塞进上下文很吃力；导出之后的正文只有大约九万一千 token，小了差不多十七倍。

	原始 JSONL	导出 Markdown
整篇读进上下文	~1.5M token，超窗口	正文 ~91k token（小约 17 倍）
关键词定位	能搜，但 grep '"type":"user"' 是陷阱（工具结果也算 user）	行文本，匹配更干净
提取真实提问	要解析 JSON + 处理多种内容块结构	导出时已经归一化好

秘诀在于，导出把每一步的工具调用 - 那些又长又重的命令输出、文件内容 - 全甩进一个叫 sidecar 的附属文件。正文只留干净的对话和一个个 <tool_call> 引用，需要看某一步的细节，再去附属文件里翻那一条。

所以导出不是必须的，但很值 - 让人读着清爽，也让 AI 在理解和处理时更省 token。后面的挖矿基于这个干净的底子做，又快又省。

为什么不是“自动生成一堆 Skill”

讲到挖矿，很多人第一反应是 - 找出重复的步骤，自动生成 Skill 不就行了。

我一开始也这么想。但查了一圈高手怎么做，才发现这条路是错的。

Superpowers 的作者 Jesse Vincent 有一句话，大意是 - 如果一件事 Claude 一次就能做好，那给它做成 Skill，价值是零。真正有用的 Skill，是那些过程不显而易见的、需要人的品味和判断的、或者你的做法跟标准做法不一样的。

这就推翻了“自动生成”。一个只会找重复步骤的工具，会造出一大堆垃圾 - 全是 Claude 本来就会的事。

Anthropic 官方的说法也是一个意思 - 写 Skill 之前，先假设 Claude 已经很聪明，只记录它不知道的东西，你的规矩、你的非常规流程。他们甚至直说，你不需要一个“教你写 Skill”的 Skill，因为格式 Claude 天生就会。

这句话点醒了我 - 这个 Skill 的价值，不能是“它懂 Skill 的格式”，得是那套挖矿的方法论本身。它的核心，是一道“值不值得”的门（worth-it gate）：

• 这个流程是不是不显而易见？
• 是不是需要你的品味、你的判断？
• 是不是和标准做法不一样？

每一个候选都要先过这道门，过不了的直接拒。如果整场对话挖完一个都没过，它就告诉你“这次没什么值得做的” - 这是一个合法的、有价值的答案，不是失败。

它实际怎么跑

用法很自然 - 你不用记会话 ID，用大白话描述就行，比如“上次我修个人网站那个连接重置的 bug，那次对话能挖出什么 Skill”。

流程是这样的：

• 定位 - 按关键词搜，给一个排好序的候选清单，你确认是哪一场；没导出的先导出。
• 读 - 读那份干净的 Markdown，再跑一个 extract_session_signals.py 小脚本，把你真正说过的话筛出来。这里有个坑 - 工具返回的结果在底层也标成“用户”，天真地按“用户”抓会抓出一大堆假的。同一场对话，天真抓是四百多条，脚本筛完是二十几条真的。
• 切段 + 挖 - 一场对话可能横跨好几天、好几个任务，先切成话题段，每段单独挖摩擦信号 - 你纠正它的地方、反复的手动步骤、走过的死路、你补充的领域知识。
• 过门 + 决策 - 活下来的候选跟你这次加载的 Skill 比一比，给出三种结论之一：新建、更新、或者“这个已经有了，别重复造”。
• 提案 - 它停下来，先给一份报告（候选、动作、为什么、证据、建议的名字和触发描述），不碰任何文件。你点头了才起草，起草前还会反过来采访你，问那些对话里看不出来的取舍。

整个过程是对话式的、带闸门的，不是一键搞定。两个确认点 - 确认是哪场对话、批准提案 - 始终把方向盘留在你手里。

我是怎么造出它的

这部分可能比 Skill 本身更有意思。因为我没有手写它，而是用 Claude 自己的一套方法论造出来的。

一开始我没急着写代码。先用 brainstorming 厘清到底要做什么 - 中间还推翻了自己最早的想法。然后上网研究高手的经验。

接下来这一步最关键 - 在写任何代码之前，我先用手把这套方法论跑了一遍，拿自己的真实会话当靶子，我管它叫 drill，演练。

这场演练当场就有收获。它从一场“把推文翻译成博客”的旧对话里，挖出了一个真实可做的新 Skill - 怎么把推文翻成中文博客，还带上我那些非常规的编辑习惯（比如去翻原推回复区找勘误）。更妙的是，它还顺手挖出了第一个 Skill 自己的一个 bug - 导出格式和文档对不上。

这个画面值得品一下 - 这个还没被写出来的 Skill，在演练阶段就挖出了一个真 Skill，还挖出了喂给它数据的那个工具自己的毛病。它自己验证了自己。

确认方法论真的管用之后，我才写设计文档、写实现计划，然后用 subagent 配合 TDD 一个任务一个任务地实现、评审、合并。

怎么用，以及一点收获

有一个前提 - 它判断该新建、更新、还是直接复用，靠的是你当前这个会话里加载了哪些 Skill。逻辑很直接：一个候选如果落在某个已加载 Skill 的范围里，就建议更新那个；如果那个 Skill 是装好的插件、改不了，就提示你直接复用；只有没有任何已加载 Skill 覆盖它，才建议新建。所以相关 Skill 没加载，它就看不见 - 可能把本该更新或复用的，误判成新建。这不是判断准不准，而是它能比对的范围，只有已经加载的那些。

触发用大白话就行 - “帮我看看上次那场对话能挖出什么 Skill”，然后它照那条流水线走，最后停在提案这一步等你点头。

两个 Skill 合起来 - claude-session-manager 把没法读的会话导成能挖的 Markdown，mining-session-skills 在上面判断有没有值得沉淀的 Skill。让你和 AI 的协作，越用越快。

关键不在于自动产出一堆 Skill，而在于那道“值不值得”的门 - 这也是我自己做完这件事最大的收获。