从提示词到个人资产，我如何用 Git 跨设备管理私有 Skill
最近我在折腾一件小事：把自己散落在不同 Agent 里的 Skill 管起来。一开始我也觉得这事没那么重要，无非就是几个 SKILL.md，里面写一些说明、流程和工具调用方式。可用得多了以后，我越来越觉得，Skill 不应该只被当成「提示词文件」看，它更像是一种个人资产，尤其是私有 Skill。
公开 Skill 当然有价值。比如处理 PDF、读写表格、调用浏览器、做部署检查，这些都是很多人都会遇到的问题。社区把这些能力做成 Skill，大家拿来即用，这是生态的价值。
但我自己的判断是：真正更值得长期维护的，往往是私有 Skill。
原因也很简单。公开 Skill 解决的是「大家都会遇到的问题」，私有 Skill 解决的是「我反复遇到的问题」。前者是通用能力，后者是我的工作方式、判断标准和认知习惯。
换句话说，公开 Skill 更像工具箱里的通用工具，私有 Skill 更像我自己的工作流说明书。
这篇文章想分享的，就是我现在用的一套轻量方案：不用部署服务器，只用 Git 加本地 CLI。上行用我自己写的 skills-sync，把本地 Skill 同步到 Git 仓库。下行用成熟的 npx skills add，从 Git 仓库安装 Skill。中间用 Git 做版本管理和权限控制。这样一来，Skill 就可以跨设备、跨 Agent、跨项目流转。
不过先说清楚，这篇文章不是安装教程，我也不打算把具体命令展开得很细。进入 Agent 时代以后，我越来越倾向于把这类细节交给 Agent 自己研究。把仓库 URL 发给它，让它先读 README。必要时先安装仓库里的 Skill，再根据 Skill 的指导完成后续操作。人的注意力应该留给判断和验收，而不是记一堆命令参数。
什么是值得管理的私有 Skill？
我这里说的私有 Skill，不是指「不能公开的神秘能力」，而是指那些和个人、团队、项目强相关的能力模块。
它可以很小。比如：
- 我做代码审查时关注哪些风险。
- 我写文章时如何组织结构和语气。
- 我发布博客前要跑哪些检查。
- 我让 Agent 做完任务后，必须给出哪些验证证据。
它也可以更大。比如一套论文检索流程、一套团队项目交付规范、一套内容创作工作流，甚至是一套长期形成的研究方法。
这些东西有一个共同点：它们未必适合公开，也未必对所有人有用，但对我自己非常有用。因此，私有 Skill 本质上不是「写给模型的一段提示词」。它更像是把自己的经验和偏好，用一种 Agent 能理解、能调用的方式封装起来。
这也是我认为私有 Skill 比公开 Skill 更值得认真管理的原因。公开 Skill 用来补齐通用能力，私有 Skill 用来沉淀个人能力。前者让 Agent 更会做事，后者让 Agent 更像是在按照「我的方法」做事。
Skill 是模型之外的知识增量
现在底座模型变化很快，Agent 产品也变化很快。今天用 Claude Code，明天可能用 Codex，后天又换成 OpenClaw、Cursor 或 OpenCode。如果所有经验都只沉淀在某一个产品的对话里，其实很脆弱。产品一换、设备一换、上下文一清空，很多东西就没了。
Skill 的好处在于，它把一部分经验从具体模型和具体 Agent 里抽了出来。
一个好的 Skill 不需要写得很玄。它只要把适用场景、执行路径、可用工具和验收方式说清楚，Agent 就能在不同模型和产品之间复用这套流程。
从这个角度看，Skill 可以理解为一种「模型之外的知识增量」。底座模型提供通用智能，Skill 在这个智能之上，补充具体的领域知识、个人偏好和执行路径。
这一点很宝贵。
因为模型会越来越强，但模型不可能天然知道「我怎么做事」。它可以知道一般意义上的论文检索、代码审查、文章润色，但不知道我自己的判断标准。私有 Skill 正好补的是这一层。
真正麻烦的不是写 Skill，而是管理 Skill
当 Skill 只有两三个的时候，管理问题不明显。放在某个目录里，用的时候能找到就行。但只要你稍微重度使用 Agent，很快就会遇到几个问题。
第一个问题是分散。不同 Agent 有不同的 Skill 目录，Codex 有自己的全局目录，Claude Code 有自己的目录。OpenClaw、OpenCode、Cursor 也各有各的习惯。还有一些 Skill 是项目级的，只放在某个仓库里。
第二个问题是迁移。
换电脑的时候，你可能知道要同步代码、同步配置、同步 SSH Key，但未必记得自己有哪些 Skill 散落在各处。等真正用到的时候，才发现新机器上没有。
第三个问题是迭代。
比如我在本机改了一个 Skill，过几天又在 VPS 上用它。结果 VPS 上还是旧版本。到底哪个版本是新的？上次改了什么？有没有改坏？这些问题如果靠手动复制，很快就会乱。
第四个问题是共享。
如果是小团队，大家可能都有一些共同工作流。比如项目发布、文档检查、代码审查、日报整理。这个时候最麻烦的不是写一份说明，而是如何让每个人的 Agent 都能稳定拿到同一份说明，并且之后还能更新。
这些问题放在一起，其实就是一句话：
当 Skill 从几个零散文件，变成一套长期维护的能力库以后，它就应该像代码一样被版本管理。
这也是我最后选择 Git 的原因。
我的方案：Git 做仓库，CLI 做上下行
我的方案很简单：
上行用 skills-sync，下行用 npx skills add，中间用 Git 做 Skill 仓库。
这里的关键不是技术有多复杂，恰恰相反，关键是不要把事情做重。Skill 本质上就是一组文件。Git 已经解决了版本历史、分支、回滚、权限、协作这些问题。GitHub、GitLab 这类平台也已经解决了私有仓库访问控制。对于个人和小团队来说，如果 Git 加本地 CLI 已经能解决问题，就没有必要一开始就部署一个服务器。
这套方案的分工也比较清楚。skills-sync 负责上行，扫描本地各个 Agent 的 Skill 目录。它把你选中的 Skill 放进目标 Git 仓库，并提交推送。npx skills add 负责下行，从 Git 仓库里读取 Skill，然后安装到本机对应的 Agent 环境里。对于私有仓库，我的做法是直接复用本地 Git 认证，比如 SSH Key。
这样一来，Skill 的生命周期就比较完整了：
- 在本地某个 Agent 里产生。
- 通过
skills-sync同步到 Git。 - 在 Git 里获得版本历史。
- 在其他设备上通过
npx skills add安装。 - 后续继续迭代，再同步，再更新。
skills-sync 解决的是上行问题
我写 skills-sync 的初衷，是因为我发现已有工具更多解决的是「安装 Skill」。但我还需要一个反方向的工具：把我本地已经写好的 Skill 收集起来，推到自己的仓库里。
它现在做的事情大致包括：
- 扫描主流 Agent 的全局 Skill 目录和项目级 Skill 目录。
- 展示当前发现了哪些 Skill。
- 对比目标仓库里的版本，判断是新增、相同、修改还是无效。
- 支持交互式选择，也支持非交互式同步。
- 把选中的 Skill 复制到 Git 仓库的规范目录。
- 写入同步 manifest，默认 commit 并 push。
但我不建议读者在这里死记具体命令。更符合 Agent 时代的用法，是把 skills-sync 的仓库地址直接发给你正在使用的 Agent。然后让它自己读 README。
比如可以这样说：
这是
skills-sync的仓库：https://github.com/shiquda/skills-sync。请你先阅读 README，理解它如何同步本地 Agent Skill 到 Git 仓库，并按照说明安装配套的 Skill，然后帮我检查当前环境，给出下一步同步方案。
这比自己手动查参数更节省注意力。因为真正需要人判断的，不是某个参数怎么写，而是我要同步哪些 Skill、同步到哪个仓库、哪些内容不应该上传。
我自己的本地环境里，skills-sync scan 能扫到多个来源的 Skill，比如 Codex、Claude Code、general。目标仓库配置成我自己的 Skill 仓库。
这里有一个细节我觉得挺重要：skills-sync 不试图替代 Git。它只是把 Skill 放进 Git 仓库，然后让 Git 继续做它擅长的事情。历史、回滚、审查、冲突处理，这些都交给 Git。这比重新做一套 Skill 平台要轻很多。
下行也可以交给 Agent
下行我没有重新造轮子，而是直接使用成熟的 npx skills add。它可以从一个 source 添加 Skill，也可以列出仓库里的 Skill。另外，它还可以指定安装某个 Skill、指定全局或项目级安装，以及指定目标 Agent。
但这部分同样不需要读者自己记命令。
更自然的方式是告诉 Agent：
这是我的私有 Skill 仓库地址。
请你先确认当前机器的 Git 认证是否能访问它。
然后使用
npx skills add查看里面有哪些 Skill，再把我指定的 Skill 安装到当前 Agent 可用的位置。执行前先说明你准备做什么。
如果是团队私有仓库，只要本机 Git 认证配置好了，Agent 就可以通过 SSH URL 或其他 Git URL 访问。这样就不需要给 skills-sync 或安装流程额外设计一套账号系统。
这也是我喜欢这套方案的地方：它没有把问题复杂化。skills-sync 只管把本地资产上传到仓库，npx skills add 只管从仓库安装到本地。Git 负责中间的版本和权限，Agent 负责阅读说明、选择命令和执行流程。每一层都比较克制。
一个真实例子：找论文 Skill 从本机流转到 VPS
举一个我自己的例子：我有一个找论文的 Skill，最早是在本机 Claude Code 里用的。它不是简单告诉 Agent「帮我找几篇论文」，而是沉淀了我的检索习惯。比如优先看哪些来源、怎么判断相关性、怎么过滤质量不够的材料、最后按什么结构整理结果。
后来我希望 VPS 上的 OpenClaw 也能用这个 Skill。传统做法是手动找目录、复制文件、传到 VPS、再确认 OpenClaw 的 Skill 目录。能做，但很烦，而且后续更新还要再来一遍。现在就简单很多。我让本机 Claude Code 根据 skills-sync 的说明，把这个 Skill 上传到 Git 仓库。到了 VPS，再把仓库 URL 给 OpenClaw，让它读 README，并用 npx skills add 安装。
整个过程里，我不需要手动复制文件，也不需要自己查命令参数。我的动作更像是给 Agent 下达意图，然后让 Agent 根据 Skill 的指导自己完成同步。这件事让我更确定一件事：私有 Skill 的价值，不只是插件迁移，而是把自己的研究方法迁移到不同设备和 Agent 里。
这套方案适合谁？
这套方案并不适合所有人。如果你只偶尔用 Agent，也没有写自己的 Skill，那暂时不需要管这些，直接用公开 Skill 就够了。
它更适合下面几类人：
- 同时使用多个 Agent。
- 有多台设备，比如本机、笔记本、VPS。
- 已经开始写自己的 Skill。
- 想把工作流沉淀下来，但不想维护服务器。
- 小团队希望共享一套 Agent 工作方式。
反过来，如果你需要很复杂的后台权限、审计、审批流程，或者希望所有东西都通过 GUI 管理，那这套方案可能太轻了。
它的定位很明确：给个人和小团队一个低成本的 Skill 资产管理方式。它不是一个完整平台，更像是一条打通的链路。
Skill 管理的本质，是个人能力的版本管理
回到最开始的问题：为什么要认真管理私有 Skill？我的理解是，Agent 时代有一类新资产正在出现：可执行的认知资产。
过去我们管理代码，因为代码是可执行资产。后来我们管理文档，因为文档是知识资产。现在，Skill 介于两者之间。它既有知识，也能指导 Agent 调用工具执行任务。这就让 Skill 变得很特殊。
一个好的私有 Skill，里面可能有你的写作风格、研究路径、工程习惯、审查标准、团队约定。它不是模型参数的一部分，但它能实实在在影响 Agent 的行为。换句话说，它是在底座模型之上，给你自己加了一层知识增量。
这层增量越稳定、越可复用，就越应该被版本管理。否则它只会散落在某次对话、某个目录、某台机器里，很难长期积累。
我现在越来越觉得，未来很多人的核心资产，可能不只是代码、文章、笔记，还包括一套不断迭代的私有 Skill。它们小到一个命令，大到一套方法论。它们以可插拔模块的方式存在，可以跨模型、跨 Agent、跨设备流转。这就是它有价值的地方。
从一个 Skill 仓库开始
如果你也想试，我建议不用一上来就整理全部 Skill。先挑三类最常用的：写作或内容处理、研究或搜索、工程或发布。
然后建一个私有 Git 仓库，把 skills-sync 的仓库 URL 和目标仓库 URL 一起给 Agent，让它先读 README，再给你一个执行计划。在另一台设备上，也把目标 Skill 仓库 URL 给 Agent。让它确认 Git 认证、阅读仓库结构，再用合适的方式安装指定 Skill。
只要这个闭环跑通，你就已经有了一个最小可用的私有 Skill 管理系统。重点不在于记住多少命令，而是把「研究命令、检查环境、执行同步」这些注意力开销交给 Agent。
最后也说一个边界：skills-sync 目前主要还是我个人在用，是从自己的真实工作流里长出来的轻量 CLI。所以它的用例覆盖肯定有限，很多问题只有放到更多人的环境里，才会暴露出来。
如果你对这个方向感兴趣，欢迎体验，也欢迎给仓库 Star。更欢迎提 issue 和 pr，或者直接说说你的使用场景和问题。我会很感谢，因为这类工具只有在更多真实用例里跑过，才知道哪些地方是真的有用，哪些地方只是我自己的习惯。
最后还是回到那句话：
Skill 的真正价值，不在于它看起来多复杂，而在于它能不能把你反复消耗注意力的工作，变成稳定、可复用、可迁移的能力。
参考资料
skills-sync项目：https://github.com/shiquda/skills-sync- Vercel Labs
skillsCLI：https://github.com/vercel-labs/skills - Skills CLI 文档：https://www.skills.sh/docs/cli
- Vercel Agent Skills 文档：https://vercel.com/docs/agent-resources/skills