用 Notion 管 AI 技能,就像用 App Store 管应用

"你花 20 分钟在 GitHub 上翻到一个完美的 Skill，复制粘贴到项目里，三天后作者更新了版本，你完全不知道。"

如果你用 Claude Code、Cursor 或 Gemini CLI 写过代码，这段场景一定不陌生。

Skills（AI 的技能包，类似游戏的 DLC）已经成了 AI 编码工具的核心玩法。但管理这些技能的方式，却还停留在"复制粘贴 Markdown"的原始时代——直到 Notion 产品设计师 Brian Lovin 扔出了一个新方案：notion-skills。

一个把 Notion 数据库变成 AI Skills "App Store" 的工具。

● ● ●

一、notion-skills 是什么？一句话：Notion 当货架，本地当仓库

Brian Lovin 是谁？Notion 现任产品设计师，之前创办了 Campsite（被 Notion 收购），GitHub 上有 3363 个 follower。他不是那种"周末随便写个脚本"的爱好者，而是正经做产品的人。

他做的 notion-skills 干了一件很朴素的事：

让 Notion 数据库成为 AI Skills 的中央货架，本地文件系统成为仓库，两者双向同步。

具体来说，它有 5 个核心命令：

1. install — 从 Notion 数据库把 Skill 装到本地

2. publish — 把本地 Skill 发布到 Notion 数据库

3. add — 直接从 GitHub 社区安装 Skill

4. feed — 查看 Skill 的编辑时间线

5. migrate — 批量迁移旧配置

听起来简单？但这里藏着一个产品洞察：Brian 自己之前就做过一个 Git 版本的方案（agent-config，311 stars），现在他却转向了 Notion。

为什么？

● ● ●

二、为什么不用 Git？因为 AI Skills 管理的"最后一公里"不是版本控制，是协作

Git 是程序员的母语。但 AI Skills 的使用者，早就不仅仅是程序员了。

产品经理在 Cursor 里调 Prompt，设计师用 Claude Code 生成组件，运营同学让 Gemini CLI 写文案——他们都需要 Skills，但让他们去 fork 一个仓库、提个 PR、解决 merge conflict？

这就像要求所有人都会修车才能开车。

Brian 在 notion-skills 的 README 里写得很坦诚：Notion 的编辑体验更好，计划/文档/技能可以集中在一处，非技术团队成员也能直接参与编辑和讨论。

换句话说，Git 解决了开发者之间的协作，但把非技术团队成员排斥在外。而 AI Skills 的协作，恰恰需要这些人参与——毕竟，最懂业务规则的往往是他们。

💡 核心论点：AI Skills 管理的"最后一公里"不是版本控制，是跨角色协作。Git 是工程师的协作协议，Notion 是全团队的协作界面。

● ● ●

三、Notion 作为"生活上下文层"：当你的计划、文档、技能都在一个地方

这里有一个更深层次的产品观察。

Brian 选择 Notion，不只是因为"非技术人员也能用"。而是因为 Notion 正在成为很多人的"生活上下文层"——你的项目计划、会议记录、产品文档、个人知识库，全都在里面。

当你的 AI Skills 也在这个上下文层里，认知负担是最低的。

想象一下这个场景：

● 早上在 Notion 里写今日计划

● 发现需要一个新的代码审查 Skill

● 直接在同一个数据库里浏览、安装、试用

● 下午把优化后的 Skill 发布回去，团队成员立刻能看到

不需要切到 GitHub，不需要打开终端，不需要理解什么是 symlink（"快捷方式"，一种指向另一个文件的特殊文件）。

上下文切换的成本，往往比操作本身的成本更高。

当然，这不是说 Git 不好。对于需要严格版本控制、代码审查、CI/CD 的场景，Git 仍然是不可替代的。notion-skills 自己也支持从 GitHub 安装 Skill（`add` 命令）。

但 Brian 的赌注是：对于大多数团队来说，"够用且顺手"比"完美但复杂"更有价值。

● ● ●

四、从"配置文件"到"可安装应用"：Skills 正在进化成一个生态

让我们把视角拉远一点。

早期的 AI Skills 是什么？基本上就是一段 Markdown，里面写着系统提示词和工具定义。你要用的时候，复制粘贴到项目里。

这像极了智能手机出现之前的应用分发方式——你去论坛下载一个 `.jar` 文件，通过数据线传到手机里，手动安装。

现在呢？

维度	早期 Skills	现在的趋势
分发方式	复制粘贴 Markdown	通过工具安装/卸载
版本管理	无，或靠手动备份	自动同步 + 编辑历史
协作	单人使用	团队共享 + 评论讨论
发现	GitHub 搜索	集中化注册表/数据库
安装命令	无	`install` / `add` / `publish`

notion-skills 的出现，标志着 Skills 正在从"配置文件"进化为"可安装应用"。

这个趋势不是孤立的：

● MCP（Model Context Protocol，AI 和工具之间的 USB 接口）让 AI 能标准化地连接外部工具

● npx skills 和社区注册表正在建立命令行层面的分发标准

● Notion Skills Registry 试图成为官方市场

💡 核心论点：Skills 的进化路径，和移动应用从"手动安装 APK"到"App Store 一键下载"几乎一模一样。notion-skills 是这个进化中的一个重要实验。

● ● ●

五、风险与局限：理想很丰满，现实有骨感

当然， notion-skills 不是银弹。

Brian 自己在项目里列了几个风险：

1. 版本冲突 — 多人同时编辑同一个 Skill，Notion 的冲突解决不如 Git 精细

2. 配置坟场 — 数据库里的 Skill 越来越多，容易变成"装了就忘"的垃圾堆

3. 多文件技能体验不够流畅 — 复杂 Skill 可能包含多个文件，Notion 数据库的单页模型对此支持有限

另外，这个项目本身还非常早期：GitHub 只有 36 stars，0 forks，1 个贡献者。虽然 3 天就发了 42 个版本（迭代速度堪称疯狂），但能否持续维护、社区能否壮大，都是未知数。

支持的客户端倒是挺全：Claude Code、Codex、OpenCode、Cursor、Gemini CLI 都能用。

● ● ●

六、总结：一个值得关注的信号

notion-skills 本身可能成功，也可能失败。但它代表了一个明确的信号：

AI Skills 的管理方式，正在从"开发者工具"走向"团队协作工具"。

这个转变里藏着几个启发：

✅ 协作半径决定工具选择* — 如果你的 Skill 只有你自己用，Git 够了；如果要跨团队协作，需要更友好的界面

✅ 上下文集中降低认知负担* — 计划、文档、技能在一个地方，比分散在多个工具里更高效

✅ Skills 正在应用化* — 从配置文件到可安装、可更新、可卸载的应用生态，这个趋势不可逆

✅ Notion 的野心不止于文档* — 它正在成为更多开发者工作流的"默认界面"

"最好的工具不是功能最多的，而是让你忘记它存在的。"

如果 notion-skills 能让团队管理 AI Skills 像管理 Notion 页面一样自然，那它可能就摸到了那个"忘记存在"的门槛。

● ● ●

本文数据来自 GitHub/npm 实时查询：notion-skills 36 stars / 42 releases / v0.17.2；agent-config 311 stars。