每天都在用 AI 干活的人，多半都有过这个时刻：同一个问题，这周问了 Claude Code，下周换了 Trae、Qwen、CodeBuddy，又要从头解释一遍「我的服务器怎么连」「日报怎么生成」「公司这台机器上有什么服务」。解释完还会想——这段话我上次也打了一遍，怎么就没存下来？
最近各种赛博菩萨狂发赛博鸡蛋，让这个现象更明显。今天workbuddy发免费模型，明天trae发免费积分，qoder、qwen也不甘示弱，导致我电脑上的agent越来越多，这个现象也就更明显。
对于这个问题，有一个大家都知道的处理思路，就是把流程抽成skill。但说起来简单，做起来难，在多agent的情况下， skill 该怎么管，同样是个问题。
各种skill散落在各个agent里，某个agent里是不是缺了哪个记不清，更新了skill哪些agent里还在用老的更搞不明白。我折腾了很久，最后走了一条「抄个人知识管理作业」的路。
一、用久了 AI，总会沉淀出一些自己的流程
刚开始用 AI 编码工具，问的都是通用问题：写个脚本、改个 bug、解释一段代码。这类问题不需要准备任何东西，模型自己就会。
用得久了，会出现另一类问题。它们有三个特征：
一是有固定的流程。 比如我在自己的 Oracle 云服务器上搭后端服务，每次都是同一套动作：选 Go + SQLite、按 model → store → httpapi → config 分层、先定接口契约、再套模板写 handler、systemd 常驻、只监听回环、靠 Cloudflare Tunnel 对外。哪一步做错都有固定的坑——比如发给 ARM 架构的机器忘了交叉编译，上去就是 Exec format error。
二是强个人化。 我的服务器 IP、密钥放在哪、哪台是主力哪台是备用、防火墙放过哪些端口——这些东西只对我成立。换个同事来，他的机器、他的端口、他的部署习惯全都不同。
三是它不会自己变好。 踩过的坑，下次不问还是会踩；总结出来的约定，这次没写下来，下次就让 AI 重新发明一遍分层和鉴权方式，而且发明得和上次不一样。
于是就很自然地想把它们写成 skill。我仓库里躺着的那 25 个技能，大致都是这么来的：
| Skill | 它固化了什么 |
|---|---|
oracle-e2-server |
两台云实例的 IP、架构、密钥路径、连通性诊断，以及「连不上时先核对公网 IP」的排查顺序 |
oracle-backend-dev |
在那台服务器上做后端的七步流程：选型、分层、接口契约、模板、前端、部署、自检 |
notion-task-report |
从 Notion Task Tracker 读数据生成日报/周报，并同步回 Notion 日记和 Obsidian |
这类 skill 有个共同点：普适性不强。我的 Oracle 实例密码和端口，对别人毫无参考。我想按某种方式组织我的日记，但别人可能喜欢完全另一种方式。所以它们基本找不到别人做好的现成实现——网上能找到的是「怎么写 skill」的通用教程，不是「怎么连我那台机器」的具体答案。
做好了也不太有对外分享的价值。我自己用得很顺，可别人拿去，IP 不对、库不存在、平台打不开，第一反应是「这什么玩意儿」。它们的价值完全绑定在我自己的环境和工作流上。
二、可这些 skill 很快就开始「到处乱跑」
第一年我只有两三个 skill，散在各处也无所谓：~/.claude/skills 放一个，某个项目的 .claude/skills 放一个，用到哪个算哪个。
后来 Agent 越装越多，问题就显出来了：
同一个技能存在好几份。 我在 Claude Code 里写好 oracle-e2-server，Trae 里也想用，就复制一份过去。过两周在 Trae 里改了 IP，Claude Code 那份还是旧的。下次在 Claude 里问「连不上服务器怎么办」，它按旧 IP 去连，我还以为机器挂了。
不知道哪份是最新的。 复制来复制去之后，磁盘上躺着四五个同名目录，哪个改过、哪个是原点，全靠记忆。有一次排查一个问题找了半小时，最后发现我改的是一个副本，本体在另一个目录里从来没动过——那一刻真的会恍惚：这数据还是我的吗？
换个工具就得重来一遍。 今天这个 Agent 送免费额度，明天那个发积分，不用白不用。可切过去才发现：人家的 skill 目录不读 ~/.claude/skills，我的技能它一个都看不到。只能手动再复制一遍、再建一遍软链。更麻烦的是，很多安装工具只管「从市场装公共技能」，我自己写的这些，它根本纳管不了——切换的负担全落在我身上。
还有一笔看不见的账。几乎所有主流 Agent 都会把每个已安装技能的名称和描述注入系统提示词，让模型自己判断要不要调用。一个技能按 50～100 token 算，装了两百个技能，就是每次对话固定一两万 token 的固定开销，再乘上一个任务几十个来回，账单相当可观。开销还在其次，更要命的是检索效率：候选列表越长、无关条目越多，模型选错技能、或者干脆漏掉该用的那个技能的概率就越高——就像在塞满了别人工具的工具箱里找自己那把扳手。
到这一步，「怎么管理我自己的 skill」就不再是随口一问了。而这个问题，我在个人笔记上已经遇到过一遍。
三、这个题，个人知识管理已经解过一遍了
先说结论：我是参考 Obsidian 管理个人知识库的方式，来解决 skill 管理的。
倒回去看，我在笔记软件上的迁移路径大概是这样的：很早用印象笔记，后来试 OneNote，再后来用 Notion，中间还零星试过别的。每次换，都不是因为旧的不能用了，而是新的某个功能更吸引我——OneNote 的自由排版、Notion 的数据库视图。可每次换，真正折磨我的都不是「学新软件」，是搬数据：导出、转换格式、丢附件、丢内部链接、图片错位，一顿操作之后看着新旧两份不完全一样的库，只能叹气。
那时候我朦朦胧胧有个念头，但说不清楚：这数据到底是不是我的？ 我写的东西，存在别人的服务器上、别人的私有格式里、别人的账号下。我想带走的时候，它让我带吗？
Obsidian 是把这件事说明白了的那个。它的核心理念是本地优先、强调数据主权：内容存在你自己的磁盘上，用的是开放的 Markdown 文件，有没有 Obsidian 这个软件，数据都原样在那儿、都能被别的工具打开。换个比喻：笔记是资产，软件只是查看资产的其中一种方式。再加上通用的格式和开放的生态，Obsidian 把「知识」和「工具」解了绑。
想清楚这一层之后再看 skill，我发现它是同一个题的又一次出现：
现在市面上的 skill 管理工具并不少，各自做得也挺好用。但看下来会发现一个共性的问题——和工具绑定太紧：skill 存在它自己的私有存储或私有目录约定里，跟着它的账号走，换一套生态就得重新搬一遍。今天帮你把技能装进 20 个 Agent，明天你换了个它不认识的 Agent，或者它自己不更新了，你攒的那一堆技能就被锁在原地。
我不想再搬一次数据。所以我把 Obsidian 的那套解法原样搬到了技能管理上。
四、于是有了 Flint：Obsidian 收藏知识，Flint 点燃技能
Flint（flint.lichuanyang.top/zh ）就是照这个思路做的：一个本地优先的个人 AI Skills 资产理器。核心原则只有三条：
- Skill 只以普通文件存在于你的本地磁盘。 没有云端、没有账号、没有上报。技能本体就是磁盘上一个普普通通的目录，里面一个
SKILL.md加若干配套文件——你随时可以用任何编辑器打开、编辑、diff、用 git 提交。Flint 被卸载、被替换、或者干脆没在运行，对你的技能没有任何影响。 - 格式与路径约定完全采用开源生态的标准做法。 标签这类元数据，优先写在
SKILL.mdfrontmatter 的顶层——这是 Claude Code、agentskills.io 等几十个工具原生读取的位置，随 skill 目录一起被 git 版本化，而不是塞进某个只有它认识的私有数据库。 - 数据主权完全归你。 换工具、换生态，这份资产零成本带走、照常使用。
名字上也留了这条线索：黑曜石（Obsidian）收藏知识，燧石（Flint）点燃技能。 远古人类把黑曜石打制成刀刃；Flint 是与它并肩的另一块「工具之石」，只是把打磨的对象从知识换成了技能——打制（把散落各处的 skill 收拢、去重、打标签）与取火（把技能投放到各个 Agent 与项目目录，让它们真正被点燃、开始干活）。
具体用起来，最小的一条路只要四步：
- 建一个目录作为技能仓库。 这个仓库本身就是个普通目录，你可以用 git、网盘或任何你习惯的方式管它。
- 把 skill 放进去。 也支持从你现有的各个 Agent 目录、各个项目里把散落的 skill「归集」进来，同名自动去重，由你决定保留哪一版。
- 新建预设。 预设就是一份技能套餐，比如「写代码用这套」「写日报用那套」。
- 把预设应用到 Agent。 一次性把套餐里的技能部署进某个 Agent 的目录，默认走软链——磁盘上只有一份本体，改一处、处处生效，再也不会有「四份副本不知道哪份最新」的问题。
在此之上还有几个我觉得很实用的设计：
- 项目级 skill 用真实副本。 项目里的技能本体复制到
<项目>/.agents/skills/，可以提交进 git 给团队共享；其他 Agent 的项目目录再软链到这份本体上，一套本体、多 Agent 共用。在项目里改好了，还能一键「回写仓库」。 - 第三方来源只读关联。 别人的技能仓库可以登记进来，纳入搜索和发现，但不拷贝、不改写它的文件——那是上游的东西，得尊重。
- 诊断页做体检。 同名多来源、失效软链、缺
description的技能、配置异常，集中在一个页面看清并就地修复。 - 没有自动同步。 所有投放都是显式操作：添加、应用预设、删除，都是你点的，落盘即生效。我见过太多「贴心」的同步把用户手改的东西悄悄覆盖掉——那比不同步更糟。
我自己的库现在长这样：一个 ~/local-skills 仓库，25 个自有技能外加三个只读的第三方来源；~/.claude/skills、~/.trae-cn/skills、~/.codebuddy/skills、~/.agents/skills 等目录里，凡是我在用的技能，全部是指向仓库的软链。改技能只改仓库那一处，所有 Agent 立刻看到最新版；无论是否用 Flint 这个工具，这些软链都可以正常工作，我的技能一个不少、照常干活。
五、一点经验总结
回头看，管理个人 skill 这件事，真正的门槛从来不是「工具好不好用」，而是你想清楚没有：这些技能到底是我的资产，还是某个软件的附属品。
如果是附属品，那迁移成本、格式锁定、账号绑定就都是你应该预期的代价；如果是资产，那就得反过来要求工具：文件是我的、格式是开放的、主权是我的。
我选了后者，也照这个思路做了 Flint。如果你也攒了一堆只对自己有效的技能，也在几个 Agent 之间来回搬过同样的目录，大概能理解这种执念。
- 官网：flint.lichuanyang.top/zh
- GitHub：github.com/lcy362/flint
- npm：
npm install -g flint-skills-hub，然后flint
Obsidian collects knowledge; Flint sparks skills.
