Show HN: Sx 2.0 —— 通过 Dropbox 文件夹与团队共享 AI 技能

# 你的 Dropbox 现在是一个技能服务器 来源：https://sleuth-io.github.io/sx/2026/07/10/your-dropbox-is-now-a-skill-server.html **sx 2.0 已发布：一款面向 Mac、Windows 和 Linux 的原生应用，让每个人都能与团队共享 AI 技能，无需 Git，无需终端。** 几个月前我曾写道，AI 工具链中缺少一个类似 npm 的环节（https://sleuth-io.github.io/2026/06/05/a-package-manager-for-ai-assets.html）。那些最擅长使用 AI 的用户会构建技能、MCP 配置和各种命令来成倍提升产出，但这些知识被困在他们的机器上，因为没有干净的分发方式。我们构建了 sx——一款开源的 AI 资产包管理器——来填补这个空缺。它奏效了。开发者用它来在 Git 仓库中管理技能版本，并通过锁文件和确定性安装，将这些技能部署到 Claude Code、Cursor、Copilot、Codex、Gemini、Cline 和 Kiro 中。 然后我犯了一个本应预料到的错误——因为我亲眼目睹 Atlassian 犯过两次同样的错误——我为开发者构建了共享层，并假设其他人最终会和我们一样使用命令行。但他们不会。在我们今年进行的约六十次深度访谈中，那些从技能中获益最多的人越来越多地来自市场、法务、销售和运营部门。他们写得出一流的技能。但他们没有 Git，没有终端，也没有兴趣去学习这些东西。让一个市场团队去执行 `sx init --type git`，就等于让他们别共享技能了。 sx 2.0 就是解决方案。它是一款真正的桌面应用，其依赖的分发模型是每个团队都已经拥有的：一个共享文件夹。 以下是面向非技术团队的工作流程：打开应用，将你的技能库指向 Dropbox、Google Drive、OneDrive 或 iCloud 中的一个文件夹，然后把你的技能拖进去。Markdown 文件放进去，技能就生成了。你的队友将应用指向同一个文件夹，你发布的所有内容都会出现在他们那里。没有服务器，没有账户。你公司已经付费的文件同步产品负责复制。 这个方案之所以可行，得益于 2.0 版本的另一项重大变更：v2 仓库格式。现在，所有资产的最新版本直接以纯文本、可读的 Markdown 形式存在于磁盘上的 `assets/<asset-id>/` 目录下。版本历史则存放在相邻的 `.sx/versions/` 目录中。你可以用 grep 搜索这个仓库。你可以在 Obsidian 中打开它。你可以直接把 `.claude/skills` 指向它，一切正常运行，因为不需要解包。 一个明显的类比正是 Obsidian 的配置方式——一个放置在同步文件夹中的 Markdown 仓库——现在很多团队也确实在用这种方式管理技能。区别在于文件同步之后发生的事情。sx 原生地理解 AI 客户端。当你在应用中点击“同步”时，它会在后台执行 `sx install`：解析出你应该安装哪些内容，将每个资产转换成每个客户端特有的格式（Claude Code 技能、Cursor 规则、Copilot 指令等），然后写入你机器上的正确位置。你的队友在共享文件夹中放入一个技能，你点击一个按钮，它就在你的 AI 客户端中生效了。这个转换层，正是单纯一个装满 Markdown 文件的文件夹无法为你做到的。 开发者并不会失去任何东西。CLI 仍然是同一个 Go 二进制文件，git 和 skills.new 仓库类型仍然有效，而且应用和 CLI 读取的是同样的仓库。2.0 新增了“集合”（collections）功能，它将相关技能分组，并在读取时作为一个整体安装，因此下个月添加到共享集合中的技能会自动到达整个团队，无需任何人重新运行任何操作。 ## 扩展系统：因为你们团队的问题不应该由我的路线图来决定 本次发布的另一半内容是一个适用于该应用的扩展系统。我花了很多年在插件生态圈里（我在 Atlassian 时，我的联合创始人 Don 构建了他们的插件系统），因此我相信，在一个团队工具中，真正有意思的问题总是特定于该团队的，而把每个团队的答案都塞进核心功能，正是产品变得臃肿和缓慢的原因。 所以，现在这个应用是可以扩展的了。一个扩展就是一个包含清单和一个 ES 模块的文件夹，在你有构建需求之前无需任何构建步骤。扩展可以添加仪表盘组件、发布时的检查项、编辑器命令以及全新的视图。附带的一个市场包含十五个扩展，人们最先拿起来用的通常是那些关注团队健康状况的： - **Collection Doctor** 给集合打 0 到 100 分，并指出问题：描述过简、应该淘汰的过期资产、近乎重复的技能、占用上下文的超大技能。每个问题都可以一键跳转到对应的资产。 - **采用率组件** 显示团队中谁正在使用哪些技能，这样你就能知道某人花了一周时间开发的技能是否物有所值。 - **评审轮值** 为每个资产设置一个根据使用频率自适应调整的评审截止日期，并在团队中公平轮换评审任务。 - **集合导出** 将集合编译成 Claude Code、Codex 或 Gemini 插件，或者一个普通的 zip 文件，以便在仓库之外分享。 两个设计决策，如果你在评论区追问，我会捍卫它们。第一，扩展受权限控制：没有文件系统访问、没有 Node、没有网络（除了扩展明确声明的主机之外），启用一个扩展时会以通俗语言列出它能接触到的所有内容，并且每当更新改变该列表时会再次提示。第二，扩展本身也是 sx 资产。它们通过与技能相同的流程发布、版本化、限定在团队内、锁定和审计，这意味着扩展更新永远不会像某些生态系统中插件自动偷偷更新那样绕过审查。组织管理员可以按仓库范围允许或禁用第三方扩展。市场本身也只是一个 sx 仓库，因此将应用指向你自己的仓库，你就拥有了一个私有市场。 ## 未来走向 sx 背后的理念自第一个版本以来从未改变：AI 的增益被困在个人手中，缺失的环节是分发。变的是我对“谁需要它”的认识。2.0 系列押注于下一波技能作者将不再是开发者，而要想迎接他们，就意味着需要一个原生应用、一个他们已经共享的文件夹，以及一个隐藏着包管理器的同步按钮。 所有代码都是 Apache-2.0 许可，托管在 GitHub 上： github.com/sleuth-io/sx (https://github.com/sleuth-io/sx) 该应用的所有三个平台的版本都发布在 release assets (https://github.com/sleuth-io/sx/releases) 中，`brew install sx` 仍然能安装 CLI。 如果你和你的团队尝试了共享文件夹的设置，我很想知道它在哪些地方出了问题。这是本次发布中我最不确定能否经得起真实 Dropbox 延迟考验的部分。