1. 二十个 skill 散在三台电脑，这件事到底难在哪
先说清楚这个场景。我手头有三台机器：一台主力台式机放在家里，一台笔记本随身带着跑客户现场，还有一台放在公司工位的开发机。三台机器上各自装了一堆 AI 编程助手的 skill——有的是自己写的，有的是从社区扒下来改的，有的是同事分享的。加起来二十个出头，散得到处都是。
这个状态持续了大半年，直到某天我在笔记本上想用一个明明在台式机上写好的 skill，翻遍目录才发现根本没同步过来。那一刻我意识到，问题不是"skill 不够用"，而是"skill 管不住"。
所谓 skill，在 AI 编程助手（比如 Claude Code、Codex 这类工具）的语境里，本质就是一份结构化的指令文件，通常是一个带元信息的 Markdown 文件，放在特定目录下，AI 在需要的时候会读取它、按它的描述去执行任务。它可以是"帮我把这段代码转成单元测试"，也可以是"按我们团队的规范生成 commit message"，甚至可以是"读取飞书多维表格的数据然后生成周报"。一个 skill 就是一个可复用的能力单元。
问题在于，这些能力单元天生是"本地化"的。它们躺在某台机器的某个目录里，换台机器就找不到。而 AI 助手本身又不会主动帮你跨机器搬运——它只认当前工作目录和用户配置目录下的东西。
所以这个项目的核心命题就一句话：能不能让 AI 自己把散落在多台机器上的 skill 收集起来、装到该装的地方，全程我只说一句话。
答案是能，而且做下来比想象中简单。但中间有几个坑，不踩一遍是想不到的。
2. 为什么"让 AI 自己装"比写个同步脚本更划算
大多数人遇到这个问题的第一反应是：写个 rsync 脚本或者丢到 Git 仓库里定时拉取不就行了？我一开始也是这么想的，试了两周之后放弃了，原因有三个。
2.1 同步脚本解决不了"装到哪"的问题
skill 的存放位置在不同工具、不同操作系统下是不一样的。Claude Code 在 macOS 和 Linux 下通常读~/.claude/skills/或者项目根目录的.claude/skills/，Windows 下路径又不一样。Codex 这类工具的 skill 目录约定又是另一套。你写个 rsync 把文件同步过去，文件是到了，但放错目录等于没装。
而 AI 助手自己知道它该从哪里读 skill——你只要告诉它"把这个 skill 装到你能识别的位置"，它会自己去判断当前环境下的正确路径。这是脚本做不到的，因为脚本是死的，AI 是活的。
2.2 skill 之间有依赖和冲突，需要判断
我有个 skill 叫"生成周报"，它依赖另一个 skill"读取飞书多维表格"。如果只同步单个文件，依赖关系就断了。还有些 skill 名字重复但内容不同——台式机上那个"代码审查"是我自己改过的版本，笔记本上那个是原始版本。同步脚本只会无脑覆盖，AI 则会先比对再决定。
2.3 一句话触发才是真正的省事
写脚本意味着我还要记得去跑它、记得处理报错、记得在不同机器上维护脚本本身。而"让 AI 自己装"的体验是：我在任何一台机器上打开 AI 助手，说一句"把我其他机器上的 skill 都同步过来装上"，它就去干了。这个体验差异是质的。
提示：这里说的"其他机器"指的是你能通过网络访问到的机器，比如同一局域网内的设备、你有 SSH 权限的服务器，或者通过云盘/代码仓库中转的路径。具体怎么连是你的环境问题，本文只讲 AI 侧怎么把这件事做对。
3. 让 AI 接管安装，需要先给它铺好哪几条路
AI 再聪明，也得有路可走。在让它"自己装"之前，我做了三件准备工作，这三件事决定了后面能不能一句话跑通。
3.1 把 skill 集中到一个"中转站"
散在三台机器上，AI 没法同时看到。我的做法是选一个所有机器都能访问的位置作为中转站。可以是：
- 一个 Git 仓库（私有仓库即可），每台机器把本地 skill 推上去
- 一个云盘同步目录（比如各家网盘的文件同步文件夹）
- 一台常开的机器上的共享目录，其他机器通过局域网访问
我选的是 Git 仓库，因为版本管理天然适合 skill 这种会不断迭代的东西，而且 AI 助手对 Git 操作非常熟练，git pull、git diff这些它闭着眼都能做。
中转站的目录结构我整理成这样：
skills-repo/ ├── claude/ │ ├── weekly-report/ │ │ └── SKILL.md │ ├── code-review/ │ │ └── SKILL.md │ └── feishu-table-reader/ │ └── SKILL.md ├── codex/ │ └── ... └── shared/ └── ...按工具分目录，是因为不同工具的 skill 格式和元信息字段不完全一样，混在一起容易出问题。
3.2 给每个 skill 写清楚元信息
这是最容易被忽略但最关键的一步。一个 skill 文件如果没有清晰的元信息（名称、描述、适用场景、依赖项），AI 装的时候不知道它是干嘛的，用的时候也不知道什么时候该调用它。
我的每个 SKILL.md 头部都长这样：
--- name: weekly-report description: 读取飞书多维表格中的任务数据，按团队模板生成周报草稿 trigger: 当用户提到"周报""本周总结""生成报告"时使用 dependencies: - feishu-table-reader version: 1.3 ---description和trigger这两栏是给 AI 看的，写得越具体，它判断"该不该用这个 skill"就越准。我踩过的坑是早期描述写得太模糊，比如只写"生成报告"，结果 AI 在我让它"生成测试报告"的时候也去调这个周报 skill，闹了笑话。
3.3 在中转站放一份"清单文件"
AI 要装 skill，得先知道有哪些 skill 可装。我在仓库根目录放了一个manifest.json：
{ "skills": [ {"name": "weekly-report", "path": "claude/weekly-report", "tool": "claude"}, {"name": "code-review", "path": "claude/code-review", "tool": "claude"}, {"name": "feishu-table-reader", "path": "shared/feishu-table-reader", "tool": "shared"} ], "updated": "2025-01-15" }有了这份清单，AI 读一遍就知道全貌，不用去遍历目录猜。这个文件我让 AI 自己维护——每次新增或删除 skill，让它顺手更新清单。
4. 那句"一句话"到底该怎么说
准备工作做完，真正触发安装的那句话其实很朴素。我在 AI 助手里输入的是：
把 skills-repo 仓库里所有适用于当前工具的 skill 同步到本地并安装好，装完告诉我装了哪些、跳过了哪些、为什么。
这句话里有四个关键信息，缺一不可：
- 来源：skills-repo 仓库，明确告诉它去哪拿
- 范围：适用于当前工具的，避免把 Codex 的 skill 装到 Claude Code 里
- 动作：同步并安装，两个动作都要
- 反馈要求：装完报告结果和原因
很多人只说了前两个，结果 AI 装完一声不吭，你也不知道它到底干了啥。加上第四点之后，它会给你一份清晰的清单，比如"安装了 8 个，跳过 3 个（其中 2 个已存在且版本相同，1 个依赖缺失）"。
4.1 AI 实际执行时的内部步骤
虽然我只说了一句话，但 AI 背后做的事情是有章法的。观察下来它大致走了这几步：
- 读取
manifest.json，拿到 skill 清单 - 检测当前环境（操作系统、AI 工具类型、skill 目录位置）
- 逐个比对本地已安装的 skill 和清单里的版本
- 对需要安装的，从仓库拉取文件、放到正确目录
- 检查依赖关系，缺依赖的要么补装要么标记跳过
- 汇总结果并汇报
这个流程它自己会规划，我不需要教它。但如果你的 skill 结构特别复杂，可以在仓库里放一个INSTALL.md说明安装规则，AI 会读。
4.2 一个真实的执行输出
我第一次跑通的时候，AI 给我的反馈是这样的：
同步完成，结果如下： 已安装（6个）： - weekly-report v1.3 → ~/.claude/skills/weekly-report/ - code-review v2.1 → ~/.claude/skills/code-review/ - feishu-table-reader v1.0 → ~/.claude/skills/feishu-table-reader/ ... 已跳过（2个）： - test-generator：本地版本 v1.5 高于仓库 v1.4，保留本地 - doc-writer：依赖 missing-helper，该依赖未在仓库中找到 警告（1个）： - commit-helper：元信息缺少 trigger 字段，可能影响自动调用这份输出比我预期的还有用，尤其是"警告"那一条，直接帮我发现了一个写漏字段的 skill。
5. 跨机器场景下最容易翻车的几个点
前面讲的是顺利路径，但真实环境里坑不少。这一节把我踩过的坑和排查过程完整写出来，你大概率也会遇到。
5.1 路径分隔符和家目录差异
Windows 用反斜杠，macOS 和 Linux 用正斜杠，这个 AI 一般能处理。真正坑的是家目录：Windows 是C:\Users\用户名，macOS 是/Users/用户名，Linux 是/home/用户名。如果你的 skill 文件里硬编码了绝对路径（比如某个 skill 要读取一个固定的数据文件），换台机器就废了。
我的解决办法是：skill 里一律用相对路径或者环境变量，绝对路径只在元信息里作为"默认值"出现，并且注明"如路径不存在请询问用户"。
5.2 换行符问题导致 skill 解析失败
这个坑我排查了整整一个下午。从 Windows 推上去的 skill 文件带 CRLF 换行符，拉到 macOS 上之后，某些 AI 工具解析元信息时会因为多出来的\r而识别失败，表现是"skill 装了但 AI 说找不到"。
排查过程是这样的：先确认文件确实在目录里（在），再确认文件名拼写（没错），然后让 AI 打印它读取到的元信息内容——发现name字段的值末尾多了个不可见字符。这才定位到换行符。
修复方式是在仓库里加一个.gitattributes：
* text=auto eol=lf强制所有文本文件用 LF 换行。加完之后再没出过这个问题。
5.3 同名 skill 的版本冲突
三台机器各自改过同一个 skill，推上来的时候版本号还一样，AI 就懵了——它不知道该用哪个。我后来的规矩是：任何 skill 的修改都必须递增版本号，哪怕只改了一个字。版本号放在元信息里，AI 比对时以版本号为准，高的覆盖低的。
如果版本号相同但内容不同，AI 会报告冲突让你决定。这种情况我一般会手动看一眼 diff，合并成一个新版本。
5.4 依赖 skill 没跟着一起装
前面提到的weekly-report依赖feishu-table-reader，如果只装前者，用的时候会报错。AI 在安装阶段会检查依赖，但前提是你在元信息里写清楚了dependencies字段。没写的话它不知道，装完就是个半残废。
注意：依赖检查只在安装时做一次。如果之后你手动删了某个被依赖的 skill，不会自动报警。建议定期让 AI 跑一次"体检"，检查所有已装 skill 的依赖完整性。
6. 装完之后怎么验证 skill 真的能用
装完不等于能用。我养成了一个习惯：每次同步完，让 AI 做一次冒烟测试。
6.1 让 AI 自检
我会追加一句："装完之后，逐个确认每个 skill 的元信息能被正确读取，依赖都满足。"
AI 会去读每个 skill 文件、解析元信息、检查依赖，然后给你一份健康报告。这比你自己一个个点开看快得多。
6.2 实际调用一次
更靠谱的验证是真的用一次。比如装完weekly-report，我就直接说"帮我生成本周周报"，看它能不能正确触发、能不能读到飞书多维表格的数据、能不能按模板输出。跑通一次，这个 skill 才算真的装好了。
这里有个细节：如果 skill 的trigger字段写得不好，AI 可能不会自动调用它。这时候你可以显式点名："用 weekly-report 这个 skill 帮我生成周报。" 能跑通说明 skill 本身没问题，是触发词需要优化。
6.3 建立一份"已装清单"
我让 AI 在每次同步后，把当前机器上已装的 skill 列表写到一个本地文件里，比如~/.claude/installed-skills.md。这样下次同步时它可以先读这个文件，快速判断哪些需要更新，不用每次全量扫描。
这份清单也方便我自己随时查看——不用去翻目录，打开一个文件就看到全部。
7. 把这套流程固化成习惯之后的日常
现在我的日常是这样的：在任何一台机器上，只要我改了某个 skill 或者新写了一个，就让 AI 帮我推到中转仓库并更新清单。换到另一台机器，一句话同步下来。整个过程我不碰命令行，不记路径，不管依赖。
有几点经验值得单独拎出来说：
第一，skill 的元信息质量决定一切。描述写得清楚，AI 装得准、用得对；描述含糊，后面全是麻烦。我现在的标准是：一个陌生人只看元信息，就能判断这个 skill 是干嘛的、什么时候该用。
第二，中转仓库要定期清理。用久了会积累一堆废弃的 skill，清单越来越长，同步越来越慢。我每个月让 AI 帮我分析一次：哪些 skill 超过三个月没被调用过，列出来让我决定是否删除。
第三，别追求全自动。版本冲突、依赖缺失这些情况，让 AI 报告给你、你来拍板，比让它自作主张安全得多。我试过让它"自动解决所有冲突"，结果它把一个我精心改过的 skill 覆盖成了旧版本，血的教训。
第四，跨工具的场景要留神。Claude Code 的 skill 和 Codex 的 skill 格式不完全一样，我一开始想用一套格式通吃，结果两边都出问题。后来老老实实按工具分目录，各写各的，反而清爽。
这套东西跑顺之后，最大的感受是：AI 编程助手的 skill 机制，真正的价值不在于单个 skill 多厉害，而在于你能不能把一堆 skill 管起来、让它们在任何地方都能用。散着的 skill 是零钱，管起来的 skill 才是资产。而让 AI 自己管自己，是这件事最省力的解法。
