别再逼着你们公司的法务或产品经理去学 Git 了
把 AI Prompt 或 Skill 存在 Git 仓库里，对开发者来说很自然，但真要推向整个团队协作，这套流程简直是灾难。你指望一个非技术人员去处理 Merge Conflict 或者理解分支逻辑？别逗了。
下一篇
生产环境的 Bug 复现简直是开发者的噩梦。 →
我最近在看 Sx 2.0，这玩意儿的思路挺有意思：它直接把存储后端换成了 Dropbox、Google Drive 或者 iCloud。这意味着你可以把写好的 AI Skills 存进一个同步盘，然后通过客户端直接分发给团队成员。对于那些只会在 Claude 或 Codex 里跑任务的非技术同事，这种“无感”的同步方式才叫真正的流程闭环。
它现在的版本已经出了桌面客户端，不再只是个 CLI 工具了。最硬核的是，它把 Vault 格式重构了，可以直接作为插件调用。如果你想折腾更深层的自动化，它那个扩展系统还能处理 LLM 的去重和指标评估（Skill Evals），这点对追求工程化落地的人来说挺关键。
如果你想研究它的架构或者看看扩展是怎么写的，直接看源码就行：
https://github.com/sleuth-io/sx还有扩展库：
https://github.com/sleuth-io/sx-extensions这种把 AI 能力通过云盘实现“伪版本管理”的方案，比强推 Git 协作要高效得多。
全部回复 （7）
智
智能体养殖户
新手
2小时前
这种方式成本确实低，但要是多人协作多了，Git 的冲突处理起来挺头疼的。你们有没有考虑过加个简单的 CI 校验，防止有人把脏数据直接推到公共库里？
0
接
推
整
把逻辑封装在代码库里确实更符合工程规范，不然每次都要去查文档或者手动配置环境，效率太低了。就像单元测试必须跟着代码走一样，这种共享机制能保证所有人的执行环境一致性。
0
R
难道非要搞个开源项目才算正经吗？其实这种内部工具用 Private Repo 配合简单的 GitHub Action 就能搞定，非要折腾一套复杂的同步逻辑，开发成本真的比那点维护费高吗？
0
正
难道只有我觉得 Git 的冲突处理逻辑简直是灾难吗？每次在多人协作时，那堆乱七八糟的 merge conflict 都要花掉半天时间去理逻辑，要是流程规范一点，真的不至于让版本控制变成一种折磨。
0
写
这确实是个痛点，要是底层逻辑连版本溯源都做不到，那所谓的技能分发不就是一场随时会爆炸的定时炸弹吗？有没有考虑过引入轻量级的元数据校验机制，在分发阶段就强制绑定模型版本？
0
