夜雨聆风来了来了。
你现在手上同时开着几个 AI 编程工具？我数了一下自己的——Cursor、Claude Code、Codex、Kiro，四个。每个里面都塞了一套 Skill：提交规范、代码风格、项目规则，靠这些东西撑着 AI 输出的质量底线。
问题来了：周三在 Claude Code 里改了一版提交规范，周四打开 Cursor 一看，还是旧的。Codex 那边更离谱，三周前的版本还躺在那。
手动复制？一开始忍忍也行。时间一长你就会发现，根本分不清哪份是最新的、该拿谁覆盖谁。每接一个新工具，这套搬运流程又得重来一遍。
真正累的不是复制文件，是反复确认"到底哪份才对"这件事本身。
场景很具体：早上用 Cursor 写业务代码，下午切到 Claude Code 做重构，晚上让 Codex 跑一轮代码审查。三个工具各有各的 Skill 目录，结构不一样，路径不一样，更新机制也不一样。
这就像三个办公室各放了一份员工手册。你在 A 办公室更新了考勤规则，B 和 C 办公室还在执行旧版。偏偏这三个办公室之间没有内线电话，只能人肉跑腿送纸质通知。
跑几次还行。跑半年？
碎片化的后果不只是"某个工具用了旧 Skill"这么简单。更隐蔽的问题是：当你在 A 工具里调整了一条规则，到 B 工具里却忘了同步——AI 按旧规则干活，输出的代码风格、提交信息全不对，你还得花时间排查"是模型问题还是 Skill 问题"。
排查成本比同步成本还高。
这种混乱在工具越多的时候越明显。而现在的趋势恰恰是：没人只用一个 AI 工具。模型更新快、额度有限制、各家各有强项，"多工具并行"已经是开发者的日常状态。
工具可以随时切。但 Skill 跟不上切换的速度，才是真正的麻烦。
社区早就有人动手了。方案不少，但试一圈下来会发现，每种都解决了一半问题。
Git submodule / Monorepo：把所有 Skill 丢进一个仓库统一管理。逻辑上没毛病。但改个 Prompt 要走 commit → push → pull 全流程，对日常写代码来说太重了。你只是想改一行规则描述，不是在发布 SDK。
通用文件同步工具（Syncthing 之类）：文件层面确实能同步，但它不懂 Skill 语义。两边同时改了同一个文件，覆盖灾难说来就来。而且它同步的是"文件"，不是"Skill 的概念"——你没法知道"这个 Skill 在哪些 Agent 里生效了"。
Prompt 管理平台（LangSmith 等）：这些平台是给 LLM 应用开发设计的，管的是线上 Prompt 版本。本地 Agent 的配置文件？不在它的射程范围内。
还有一些开源工具做了分类索引和跨项目共享，方向对了，但要么只解决"往哪放"，要么只解决"怎么共用"——跨工具的即时联动和版本感知，还是空白。
缺的那一步是什么？改一处，全部 Agent 立刻生效，而且随时能看到谁是最新的。
这步听起来简单。但做到位需要把四件事串成一条链：集中存放、自动联动、状态透明、冲突可控。
既然现有方案都只走了半程，那就需要一个能从头跑到尾的东西。
Nacos Skill Sync 做的事可以用一句话讲完：所有 Skill 先收进一个总站，再从总站按需送到各个工具手里。
所谓中心仓库，跟快递中转站是一回事——所有包裹先到中转站，再从中转站发往各个目的地。你只需要往中转站放一次，下游所有站点都能收到。
具体来说三件事：
只维护一份中心仓库。所有 Skill 的内容和同步状态都在这里，不在各个 Agent 目录里单独维护。
默认通过软链接把各 Agent 的 Skill 目录直接挂到中心仓库上。改一处，全部生效，零延迟。环境不支持软链接的话切到复制模式，CLI 负责把内容搬过去。
同步状态随时可查。远端有没有更新、本地有没有改动、有没有冲突——一眼就知道下一步该干什么。
不是"同步完就不管了"。是每一次查看都能告诉你当前是什么状况，该不该动。
这种设计的好处是：不管你明天换了什么新工具，只要 CLI 支持的 Agent 列表里有它（或者手动加一个路径），它就自动接入这条"总线"。工具来来去去，Skill 始终只有一份。
不是所有人都需要服务端。
有人只想把自己电脑上的 Cursor、Claude Code、Codex 三家的 Skill 统一起来，不需要跨设备、不需要团队协作。也有人手上管着十几个 Skill 要给团队共用，需要版本治理和跨设备同步。
所以它提供了两条路：
Local mode——本机收拢，零部署
不需要连任何服务。在本地建一个中心仓库，用软链接把各 Agent 目录串起来。改一个 Skill，Cursor、Claude Code、Codex、Kiro、Lingma……全部同步。
适合个人开发者先把本机理顺。5 分钟搞定，不折腾。
Registry mode——远端统一，跨设备+团队
接入 Nacos AI Registry。Skill 有可视化管理界面，有版本治理（草稿→审核→发布→回滚），支持跨设备同步，也支持团队共建。
如果你是团队 lead，想把代码规范、提交模板这些 Skill 统一分发给所有人——这个模式就是为这个场景设计的。
两条路共用一套操作习惯。先从 Local mode 用起完全没问题，后面需要升级了再接 Registry，不用重来。
这两种模式的关系，就像本地 Git 和 GitHub 的关系。先在本地 commit，等准备好了再 push 上去。
用起来没什么门槛。
最省事的方式：让 Agent 自己干
把这段话发给你正在用的 AI Agent：
阅读 https://nacos.io/skill-sync/SKILL.md 这个 Skill，用它来同步我本地的 Skill
Agent 会自动读取规范、检查本地环境、执行同步。遇到需要你拍板的地方（比如多个版本选哪个），会停下来问你。
想自己控制的话：CLI 手动来
Local mode 一条命令就行：
# 把某个 Skill 纳入中心仓库统一管理
npx @nacos-group/cli skill-sync add <skill名称>
CLI 会扫描已知的 Agent 目录（Cursor、Claude Code、Codex、Kiro 等），找到同名 Skill，有差异的话让你选以哪份为准，然后建立同步链接。
Registry mode 多一步绑定 profile：
# 绑定远端 Registry
npx @nacos-group/cli profile bind --name my-team --endpoint <地址>
# 从远端拉取 Skill
npx @nacos-group/cli skill-sync pull
不复杂。难的从来不是操作步骤，是知道"该用什么工具"这件事本身。
干说不如看例子。
场景一：周报 Skill，本机多 Agent 共用
你平时用 Codex 改代码、Claude Code 查日志、Cursor 补测试。每个工具做完任务，工作记录散在不同对话里。周五写周报的时候翻聊天记录翻到头秃。
解法：写一个 biweekly-work-report Skill，规定每次任务完成后记什么、周报怎么生成。放在 Local mode 的中心仓库里，三个 Agent 共用。
在任意一个 Agent 里创建好这个 Skill，然后一条命令同步：
npx @nacos-group/cli skill-sync add biweekly-work-report
之后不管你在哪个 Agent 里结束任务，它都会按同一套规则记录工作内容。周五让任意一个 Agent 生成周报，信息是完整的。
后来你觉得周报格式需要调整——改中心仓库那一份就行。三个 Agent 下次读到的都是新版本。
场景二：文档格式 Skill，团队统一下发
团队里五个人，各自用不同的 Agent 写技术方案。标题层级、参数表字段、风险说明格式全不统一。口头约定过，但总有人忘。
解法：整理一个 doc-format Skill，放进 Registry mode。团队成员各自同步到本地 Agent，写文档时 AI 自动按规范来。
规范要更新？维护 Registry 里那一份。所有人的所有设备，同步后自动生效。
这一步省了，后面每次 review 文档格式的时间都在重复浪费。
用起来之后不用天天盯着。有事没事跑一下 status：
npx @nacos-group/cli skill-sync status
输出会告诉你每个 Skill 当前是什么状态：
- Synced
/ Linked：正常，不用管 - Local changes
：你本地改了，需要决定是推上去还是留着 - Conflict
：本地和远端都改了，跑个 resolve 选一边
冲突处理也不慌。默认策略保守——不会擅自替你做选择。你明确指定了以哪一方为准，它才动手。
整个维护成本就一句话：有空看一眼 status，有红的处理一下，没红的不用管。
最后补几个实际用下来的经验：
软链接权限问题：Windows 下创建软链接可能需要开发者模式或管理员权限。如果你用的是 Windows 且遇到权限报错，要么开启开发者模式，要么让 CLI 切到复制模式——功能一样，只是改完需要手动触发一次同步。
已有 Skill 怎么迁移：如果你现在各 Agent 目录里已经散着十几个 Skill，别一个个加。先跑 skill-sync add --all，CLI 会批量扫描，内容一致的直接合并，不一致的停下来让你选。五分钟能搞定大部分情况。
新工具接入：CLI 默认发现 Cursor、Claude Code、Codex、Kiro、Lingma 等主流工具的 Skill 目录。如果你用了个小众工具不在列表里，skill-sync agent add <路径> 手动加就行。加完之后跟其他 Agent 享受同样的同步能力。
Local mode 升 Registry mode：直接绑定 profile 即可，不需要重新整理 Skill。CLI 会把现有中心仓库的内容推到远端，下次另一台电脑 pull 就能拿到。
冲突策略的选择：resolve 命令默认不选边。实际经验是——如果你是一个人用，大部分时候选 local 就行（本地改的是最新的）；团队场景下选 remote 更安全（远端是 review 过的版本）。
真要选，个人开发信 local，团队协作信 remote。
多 Agent 并行开发已经不是少数人的玩法了。工具切换越来越频繁，真正需要管理的不是"用哪个 Agent"，而是这些 Agent 背后共同依赖的 Skill。
让 Skill 有一份可信来源。Agent 可以换，Skill 不应该跟着散。
想试的话，第一步就是跑一下 npx @nacos-group/cli skill-sync add --all，5 分钟把本机收拢起来。
