Sx 2.0发布：通过Dropbox文件夹与团队共享AI技能

背景

AI 工具链正快速从开发者专属走向全员参与。过去一年，越来越多非技术角色——市场、法务、销售、运营——开始编写 AI skills（技能），并以 MCP 配置、命令等形式提升团队产出。但这些最佳实践往往困在个人机器上，缺乏一个干净的分享与分发渠道。开发者可以用 Git 管理 skills，或在终端中使用包管理器，但大多数团队成员没有 Git、没有终端，也不打算接触它们。

Sx 最初是一个面向 AI 资产的开放源码包管理器，旨在填补 AI 工具栈中“类似 npm 的空白”。开发者通过它能在 Git 仓库中对 skills 做版本管理，并在 Claude Code、Cursor、Copilot、Codex、Gemini、Cline、Kiro 等客户端间安装。然而，Sx 的创建者意识到自己犯了 Atlassian 曾犯过两次的错误——只构建了面向开发者的分享层，假定其他人最终会学会命令行。现实是，不会。

核心内容

Sx 2.0 发布了一个原生的桌面应用（支持 Mac、Windows、Linux），并采用了一种每个团队都已拥有的分发模式：共享文件夹。

共享文件夹即后端
非技术团队的工作流如下：用户打开 Sx 应用，将库指向 Dropbox、Google Drive、OneDrive 或 iCloud 中的一个文件夹，然后拖入 skills。Markdown 文件进去，skills 就产生了。团队成员将应用指向同一文件夹，所有已发布的 skills 会自动出现。无需服务器，无需账号。公司已付费的文件同步产品负责复制。

这得益于 2.0 的另一项重大变化：vault 格式 v2。每个资产的最新版本直接以纯文本、可读的 Markdown 形式存放在 assets/<name>/ 路径下。版本历史位于旁边的 .sx/versions/ 中。你可以用 grep 搜索 vault，可以在 Obsidian 中打开它，也可以直接让 .claude/skills 指向它——无需解包即可工作。

与仅使用同步文件夹中的 Obsidian 仓库方案相比，区别在于文件同步之后发生的事情。Sx 原生地知晓 AI 客户端。当用户在应用中点击“Sync”时，Sx 会在后台运行 sx install：解析应为用户安装的内容，将每个资产转换为每个客户端的格式（Claude Code skills、Cursor rules、Copilot instructions 等），并写入机器上的正确位置。团队成员把 skill 放入共享文件夹，其他人点击一个按钮，该 skill 就立即出现在其 AI 客户端中。这个转换层是一个纯 Markdown 文件夹无法提供的价值。

开发者不受任何损失。CLI 仍是同一个 Go 二进制文件，Git 和 skills.new vault 类型依然有效，应用和 CLI 读取相同的 vault。2.0 新增了“集合”（Collections）功能，将相关 skills 分组，并在读取时作为单元安装。如果下个月有人将新 skill 添加到共享集合，整个团队会自动获取更新，无需任何人重新执行任何操作。

扩展系统：团队的问题不是我的路线图
Sx 2.0 的另一半是应用的扩展系统。创始人在插件生态领域有多年的经验（在 Atlassian 工作时亲眼见证联合创始人 Don 构建了他们的插件系统），他认为团队工具中的有趣问题总是团队特有的，将所有答案塞进核心会使产品臃肿且变慢。

现在应用是可插拔的。一个扩展就是一个包含清单和一个 ES 模块的文件夹，在需要之前无需构建步骤。扩展可以添加仪表盘控件、发布时检查、编辑器命令以及全新的视图。内置市场提供了 15 个扩展，最先被使用的大多是团队健康类：

• Collection Doctor：为集合打分（0-100 分），指出问题：描述过薄、应淘汰的陈旧资产、近似重复的 skills、占用上下文过大的 skills。每个发现都可一键跳转到对应资产。
• Adoption Widgets：显示团队中谁实际在使用哪些 skills，从而判断某个花了一周时间的 skill 是否值得。
• Review Rota：为每个资产自动设置审核截止日期（根据使用频率动态调整），并在团队中公平轮转审核任务。
• Collection Export：将集合编译成 Claude Code、Codex 或 Gemini 插件，或纯 zip 格式，用于在 vault 之外分享。

两个关键的设计决策：

1. 扩展的权限是受限的：扩展不能访问文件系统、Node 或网络（除非显式声明允许的主机）。启用扩展时会用通俗语言显示它能接触的内容，且每当更新改变权限列表时，会重新提示用户。
2. 扩展本身也是 Sx 资产：通过与 skill 相同的管道进行发布、版本管理、团队范围限定、固定版本和审计。这意味着扩展更新不能像某些生态中插件自动静默更新那样绕过审查。组织管理员可以在整个 vault 级别允许或禁用第三方扩展。市场本身也只是一个 Sx vault，因此将应用指向自己的仓库即可获得私有市场。

未来方向
Sx 的前提自首次发布以来未变：AI 能力被锁在个人身上，缺失的是分发层。变化的是对“谁需要它”的认知。2.0 版本的赌注是：下一波 skill 作者不会是开发者。要迎接他们，需要原生应用、他们已在使用共享文件夹，以及一个隐藏在包管理器下面的同步按钮。

所有代码以 Apache-2.0 许可证开源，托管于 GitHub：github.com/sleuth-io/sx。应用已提供三个平台的 release 资产，brew install sx 仍可获取 CLI。作者希望用户尝试共享文件夹方案，并反馈在哪些地方遇到了问题（特别是真实 Dropbox 延迟下的表现）。

关键要点

• Sx 2.0 是一个原生桌面应用（Mac/Windows/Linux），允许团队通过 Dropbox、Google Drive、OneDrive 或 iCloud 等共享文件夹分发 AI skills，无需 Git 或终端。
• 核心技术升级：vault 格式 v2 将每个技能的最新版本以纯文本 Markdown 直接存储在 assets/<name>/，版本历史存放在 .sx/versions/，支持 grep、Obsidian 打开。
• 同步后，Sx 自动执行后台 sx install：将技能转换为各 AI 客户端的格式（Claude Code、Cursor、Copilot、Codex、Gemini、Cline、Kiro 等）并写入正确位置，点击一个按钮即可生效。
• 2.0 新增“集合”功能：分组技能并作为单元安装，添加新技能到共享集合后，团队自动获取更新无需再手动操作。
• 扩展系统让应用可插拔：扩展是文件夹 + 清单 + ES 模块，无需构建。内置市场提供 15 个扩展，包括集合健康评分（Collection Doctor）、使用率统计（Adoption Widgets）、自动审核轮转（Review Rota）和导出（Collection Export）。
• 扩展权限严格：无文件系统/Node/未声明主机的网络访问，启用时展示通俗语言权限说明，更新时重新提示。
• 扩展本身也是 Sx 资产，使用相同的发布/版本/审计管线，不能绕过审核。组织管理员可全局允许或禁用第三方扩展。
• 所有代码 Apache-2.0 开源，CLI 仍可通过 brew install sx 获取，应用已提供各平台 release。

意义与影响

Sx 2.0 的发布标志着 AI 工具分发从开发者中心转向全员友好的重要一步。它直接解决了“AI 能力困在个人机器上，无法在团队中规模化传播”的核心痛点，而采用共享文件夹这一朴素但普遍存在的机制，大大降低了非技术成员参与的门槛。

对比传统方案：纯 Markdown 文件夹虽能被同步，但无法自动转换为不同 AI 客户端的格式；而 Sx 提供了一键同步的翻译层，使得“写一个 Markdown 技能”这一最简单动作就能立即在各类 AI 工具中生效。同时，扩展系统使得团队可以按需定制健康检查、使用量统计等管理功能，且这些功能本身也通过 Sx 的资产管线管理，延续了一致的安全与审计模型。

这一举措可能推动 AI 协作模式从“开发者写脚本、非技术人被动使用”转变为“全员共创、共享技能”的协作形态。对于希望加速 AI 采纳的公司来说，Sx 2.0 提供了一个低成本、低摩擦的切入点