你用过 Claude Code 的 .claude/ 目录吗？或者 Cursor 的自定义指令？
这些 AI 编码助手的"技能"——比如"用这个模板生成 API 文档"、"按照这个规范写代码审查"——目前是散落各地的。
你在 Claude Code 里配好的技能，Cursor 用不了。你团队里每个人都重复配一遍。没有人做版本管理。没有发现机制。没有依赖关系处理。
这就像 2010 年的 JavaScript 生态——每个项目手动下载 .js 文件，没有 npm。
sx 想做 AI 技能世界的 npm。
sx 是什么
sx 是 sleuth-io 开发的开源包管理器，专门管理 AI 编码助手的技能模块。
它支持三种类型的包：
- Skills：AI Agent 的技能定义（提示词模板 + 工具绑定）
- MCPs：Model Context Protocol 服务
- Commands：CLI 命令
用 Go 编写，463 次 commits，支持自卸载。
安装方式简单：sx install <package>，就像 npm install 一样。
为什么需要专门的包管理器
你可能会说：不就是个文件目录吗？cp -r 不行吗？
问题在于 AI 技能包有几个特殊需求：
依赖管理。一个技能可能依赖另一个技能。比如"Python 代码审查"技能依赖"Python 语法分析"技能。没有包管理器，你手动管理依赖关系——很快就乱成一团。
版本控制。技能会更新。新版本可能不兼容旧版本的 Agent 配置。需要语义化版本和锁定文件——这和 npm 的 package-lock.json 是同一个问题。
发现和分发。你写了一个好用的技能，怎么分享给团队？发邮件？放共享盘？sx 提供了注册表和发布机制，技能可以被搜索、安装、更新。
权限和安全。AI 技能本质上是一段代码（提示词 + 工具调用指令），它可以做很多事情。包管理器可以在安装前做安全审查、签名验证。
和现有方案的对比
Claude Plugin 系统：Claude Code 有自己的 .claude-plugin/ 目录，但它是封闭的——只能在 Claude Code 里用。sx 是跨平台的，目标是支持所有 AI 编码助手。
Cursor 自定义指令：Cursor 的技能配置锁在 Cursor 生态里。同样的问题。
Open Skills 协议：社区提出的开放标准，但缺乏工具支持。sx 是第一个把这个标准落地的包管理器。
手动复制：目前大多数人的做法。有效但不扩展。
sx 的定位和 npm 当年的定位很像：不是第一个尝试做包管理的人，但是第一个做得足够好用、让大家愿意迁移的。
当前状态
178 星，9 个 fork。这是一个早期项目。
但它有几个值得关注的信号：
来自 sleuth-io。sleuth-io 是一家专注于 AI 工具链的公司，不是个人项目。这意味着背后有商业驱动和持续投入。
463 次 commits。对于一个 178 星的项目来说，commits 数量相当多。说明团队在密集开发，功能迭代很快。
Go 语言编写。选择 Go 而不是 Node.js/Python，说明团队看重的是跨平台分发和二进制部署的便利性。sx 的目标是安装一次，到处运行。
自卸载命令。项目最近添加了 sx uninstall sx 命令，这说明团队在认真打磨用户体验——连"怎么干净地卸载自己"都考虑了。
潜在挑战
生态冷启动。包管理器的价值取决于生态里的包数量。npm 之所以成功，是因为有海量的 JavaScript 包。sx 目前生态很小，这是所有新品类包管理器面临的第一道坎。
标准化。AI 技能还没有统一的标准格式。不同的 Agent 框架（Claude Code、Cursor、Copilot）的技能格式不同。sx 需要兼容这些格式，或者推动一个统一标准。
安全问题。AI 技能包可以包含任意工具调用指令。恶意技能包可以窃取代码、发送数据到外部服务器。sx 需要完善的安全机制——签名、沙箱、权限控制。
我的看法
178 星的项目通常不值得写文章。但 sx 不同。
它定义了一个新品类：AI 技能包管理器。这个品类现在看很小，但如果 AI 编码助手继续普及，技能共享会成为刚需。到时候谁先定义了标准，谁就占住了位置。
npm 在 2010 年也只有几百星。
主要来源：
- sleuth-io/sx on GitHub — 178 stars, 9 forks, 463 commits
- 项目文档和代码结构分析
- Show HN 讨论（49 points）