1. 同时维护五套技能文件之后我决定做个统一入口1.1 让我烦到失眠的日常同一份技能写四遍我去年底统计了一下自己电脑上装过的 AI 编程工具有点吓人——Cursor、Trae、GitHub Copilot、Claude Code、Aider、Continue、Cline光常用的就有八九个。每个工具都宣称支持技能Skills也就是让 Agent 记住你团队的代码规范、检索资料的路径、自动执行的检查动作。听起来很美好实际用起来却是一场灾难每家的技能格式都不一样我在 Cursor 里面写好的规则换到 Trae 就完全不认在 Claude Code 里调试好的 Skill隔壁同事用 Copilot 也装不上。最崩溃的一个场景是这样的我们团队有一条铁律——所有 PR 必须附带变更影响范围说明缺失就自动阻止合入。这条规则本身很简单文字描述不超过两百字。但我得分别在 Cursor 的规则文件、Trae 的规则目录、GitHub Copilot 的指令文件、Claude Code 的 SKILL.md、还有 Cline 的插件目录里各写一遍。写四遍还不算完等规则改了一版比如新增涉及数据库迁移必须附加脚本回滚方案时我得打开五个工具逐一同步修改。漏改一个就会看到某个工具里的 Agent 还在用旧规则给出完全不符合当前要求的建议。这才是真正让我决定动手做点什么的那一刻不是某个工具不好用而是工具生态割裂带来的重复劳动已经超过了工具本身带来的效率提升。我需要的不是一个新 AI 编程工具而是一个能把这些工具的 Agent 技能统一收进来管理的跨平台桌面中枢。1.2 Skills Manager 到底做什么一句话说清Skills Manager 这个项目最终做出来的东西是一个跑在本地桌面的应用。它能做三件事第一把分散在各 AI 编程工具配置目录里的技能文件统一收集到一个技能总仓库里第二当你在总仓库里新增或修改一个技能时它按目标工具的格式要求自动生成对应的配置文件并部署到正确位置第三当某个工具自己手工新增了技能它也能反向发现、提示导入避免你完全绕开总仓库操作导致数据不一致。为什么要强调桌面中枢而不是搞一个网页端因为 AI 编程工具的这些技能文件本质上都是本地文件。Cursor 的规则在.cursor/rules目录下Trae 的在trae/rules下Claude Code 的在用户目录的.claude/skills下GitHub Copilot 的指令可能躺在仓库根目录的.github/copilot-instructions.md里。它们没有一个统一的云端入口也没有统一的 SDK 去操作。桌面应用在这种场景下有着天然的贴近性——直接读文件系统、监听文件变化、调用 shell 跟各工具的 CLI 交互这些在浏览器里做起来极其别扭。从实际使用场景来说谁是目标用户两类人。第一类是像我这样装了多个 AI 编程工具的重度用户每天在 Cursor 和 Trae 之间来回切换需要让两边行为一致第二类是团队里的技术基建负责人可能公司统一选了三个工具让大家用需要批量下发团队规范技能而不是让每个开发自己手动去各工具里配一遍。1.3 不做云端的核心原因技能文件的本地文件本质我在规划阶段曾经认真考虑过做成一个 SaaS 平台用户上传技能平台做转换生成针对各工具的一键导入配置。但我很快放弃了这条路原因很实际技能文件里的内容往往涉及公司内部规范、私有文档路径、内网 API 地址这些东西明文放到云端对绝大多数团队来说是不可接受的。即便不考虑合规问题还有一个更技术的麻烦——各工具的文件格式迭代很快云端平台要去适配、测试、回归兼容性响应速度永远追不上工具更新的节奏。反过来把转换逻辑全部放在本地问题就简单多了。工具改版了用户更新一下本地适配器的规则就行私有内容也不用出本机。所以我最终定的原则很明确数据全部留本地转换逻辑也全部在本地Skills Manager 只是一个帮你管理这些本地文件的中枢工具。2. 一横一纵整体架构与跨平台选型思考2.1 技术栈选型Tauri 2.0 Vue 3以及为什么放弃 Electron定下本地桌面应用的大方向之后技术栈的选择来得比想象中快。我试过的方案不少最早随手用 Electron 搭了个原型跑起来内存直接吃掉 400MB这还啥都没干呢。我机器上一般同时开着浏览器、JetBrains、Docker再塞一个 Electron 应用进去风扇直接就起飞了。后来换成 Tauri 2.0内存占用直接降到 80MB 左右。Tauri 的外观思路是界面用前端框架我用的是 Vue 3但底层调用通过 Rust 后端来做。它在 macOS、Windows、Linux 三端都有完整的构建链打包出来体积也小很多——我这边最终产物是 12MB 的安装包Electron 版本基本都在 80MB 往上。但选 Tauri 最核心的理由倒不是省内存而是文件系统操作能力。Skills Manager 的一个基础功能是递归扫描各工具的技能目录、监听文件变化、读写多种格式的配置文件。这些操作如果用 Node.js 写也不是不行但 Tauri 的 Rust 后端用notify库做文件监听性能好且稳定。另外一个实际原因是后续要适配的工具越来越多我预计需要写大量文本解析和格式转换逻辑Rust 在这块的健壮性明显好于 JavaScript。这里给个建议如果你的工具类应用核心逻辑不是处理文件系统而是偏 UI 交互那 Electron 依然是不错的选择但如果像我这个项目一样有一堆系统级文件操作要做试试 Tauri 基本不会后悔。2.2 三段式架构技能总仓库、适配器、部署器Skills Manager 的整体结构可以拆成三个清晰的层次我管它叫一横一纵。横是指它可以横跨多个 AI 编程工具纵是指每个工具内的技能生命周期管理从收集到转换再到部署和回滚。第一层是技能总仓库。它本质上是磁盘上的一个统一目录里面每一个子目录对应一个技能。这里存放的不是某个工具专用的格式而是一套自定义的统一 Schema后面我会专门讲这套 Schema 怎么设计。所有跨工具共用的、希望在所有 AI 编程工具里生效技能都先在这里编辑和版本管理。第二层是适配器。每个支持的工具对应一个适配器职责是理解该工具的技能文件格式以及它规定的部署路径。适配器需要知道Cursor 的技能文件应该放在.cursor/rules/xxx.mdcTrae 的应该放在trae/rules/xxx.mdClaude Code 的应该放在~/.claude/skills/xxx/SKILL.mdGitHub Copilot 的全局指令放在特定位置的文档里等等。适配器的输入是统一 Schema输出是目标工具期望的文件内容。第三层是部署器。当适配器生成了目标格式的内容之后部署器负责把它写到正确位置记录版本信息并且支持回滚。部署器还必须做一件事——对目标目录做监听一旦发现用户直接在工具里改了技能文件绕过了 Skills Manager就触发提示问是否把这个变更同步回总仓库。这三层之间尽量保持接口简单。适配器的接口只有一个输入技能 Schema输出文件内容。这样做的好处是我每新增一个工具的适配不需要改动总仓库的逻辑只需要写一个新的适配器。2.3 目录监控与进程通信双向同步的落地方式双向同步是 Skills Manager 最容易做砸、也最需要细心处理的地方。我的设计是给每个工具的技能目录加一个文件系统监听器用 Rust 的notifycrate监听事件包括文件新增、修改、删除。一旦发生变化监听器解析变更文件的内容判断它是哪个技能然后把变更内容转录回总仓库保持总仓库与各工具目录的状态一致。这里有一个重要的工程决策监听器不直接修改总仓库而是先写一条待确认变更记录。为什么要这样因为有些工具在生成技能文件时会自己附加一段工具特有的 frontmatter 或注释。如果无脑同步回总仓库总仓库里会混入大量工具私有的内容久了就变成一锅粥。待确认机制让用户决定是把工具的私有注释保留在技能文件里还是清理掉只同步核心指令部分。进程通信这块我用了 Tauri 自带的Command和Event机制。前端界面通过 Command 调用 Rust 后端的方法比如读取技能列表、部署技能后端在做完文件操作后通过 Event 向前端推送刷新消息。有读者可能关心如果 Rust 后端崩溃了怎么办我的兜底方案是设置一个每 5 秒一次的心跳检测前端收到不到心跳就自动标记文件监听已停止提示用户重启应用。这在日常使用中出现的概率很低但团队里有同事遇到过 macOS 文件系统事件丢失的情况有这个检测机制至少能及时发现。3. 技能模型设计用一套 Schema 兼容 54 种工具的实践3.1 工具的技能到底有几种形态在动手设计 Schema 之前我花了一个多月时间把市面上能接触到的 AI 编程工具都摸了一遍最后整理出的适配清单一共覆盖 54 个工具。这里面有意思的是它们对技能这个东西的称呼五花八门有的叫 Rules有的叫 Skills有的叫 Instructions有的叫 Plugins还有的叫 Custom Commands。但剥开外壳之后底层格式实际上可以分成四类。格式类别代表工具配置文件特征加载机制单文件指令GitHub Copilot、Windsurf一个 Markdown 文件全局或仓库根目录放置每次会话自动加载全文目录规则集Cursor、Trae目录下多个互相独立的 .md/.mdc 文件按文件名遍历匹配则注入上下文Frontmatter 技能包Claude Code、Cline一个目录包含 SKILL.md 和附属资源按描述信息判断何时激活结构化 JSONContinue、CodexJSON 里嵌套自然语言指令调 API 时作为参数附加上下文不需要理解每个工具的实现细节只需要抓住一个关键点不管外部形态怎么变一份技能的核心内容无非是三部分——触发条件、指令正文、辅助资源引用。触发条件解决的是什么时候让 Agent 用这个技能指令正文解决的是Agent 遵守什么规则或按什么步骤操作辅助资源引用解决的是需要参考哪些文档、脚本或样例代码。这个认知直接简化了 Schema 设计。我不需要为 54 个工具各建一套数据结构只需要设计一套能完整表达触发条件 指令正文 辅助资源的 Schema再写适配器把它转换成各工具的格式。3.2 统一 Schema一个技能文件长什么样我最终确定的统一 Schema 是一个带 JSON frontmatter 的 Markdown 文件原因很简单让技能文件本身保持人类可读。纯 JSON 虽然解析方便但技能的核心毕竟是一大段给人和 AI 看的指令文字塞在 JSON 字符串里既难写又难审。看看一个具体例子我团队里常用的数据库变更审阅技能--- schema: skills-manager/skillv1 name: db-change-review version: 1.3.2 description: 审阅数据库变更脚本检查索引、回滚方案和影响评估 triggers: - 数据库变更 - db change - 迁移脚本 platforms: [cursor, trae, claude-code, copilot, continue] references: - docs/db-checklist.md config: priority: high auto_load: false --- 审阅数据库变更脚本时必须按以下顺序执行检查 1. 是否包含回滚脚本没有则标记 Block 2. 对新增索引确认是否在高峰期执行若是则标记 Warning 3. 检查变更涉及的列是否存在 NOT NULL 约束新增若有则要求提供数据填充方案 4. 对超过 500 行的大迁移要求拆分为批量执行脚本 所有检查结果用 通过 / Warning / Block 三档标注并附具体原因。frontmatter 里的每个字段都有讲究。triggers对应的是触发条件适配到 Cursor 里会变成 Rule 的描述适配到 Claude Code 里对应 SKILL.md 里description字段——因为 Claude 系工具靠描述来判断技能何时激活。platforms字段声明这个技能要部署到哪些工具这是批量部署时的筛选依据。references指向总仓库内的相对路径部署时适配器会把这些附件一起拷贝到目标工具的技能目录里。Markdown 正文部分就是技能的实际指令不加特殊标记因为大部分工具本身就接受纯 Markdown 指令。只有在适配到某些需要额外元信息的格式时比如 Cursor 的.mdc文件需要写alwaysApply之类的配置适配器才会在生成的文件头上补一段对应格式的 frontmatter。3.3 从统一 Schema 到各工具格式的映射规则这里我列几个最典型的映射逻辑展示不同工具之间的翻译差异有多大。先看 Cursor。Cursor 的规则文件在.cursor/rules/目录下每个文件是一个.mdc格式头部有一个 YAML 区支持description、globs、alwaysApply字段。我的适配器把技能 Schema 转换成.mdc时规则是name转成文件名如db-change-review.mdcdescription转成 YAML 里的描述triggers则根据关键词去生成globs或者转成描述的一部分取决于用户偏好如果config.auto_load为 true则设置alwaysApply: true再看 GitHub Copilot。它读取的指令是单个 Markdown 文件且没有精细化控制的能力就是每次会话自动加载全部内容。适配器做法很简单直接把技能正文拼接进一个总文件。但这里有个问题如果 20 个技能都要往 Copilot 里塞指令会变成一大坨。我的做法是在拼接时给每个段落加一个 H2 标题让 Copilot 能相对清晰地区分不同规则块。Claude Code 的 SKILL.md 又不一样它的前端是一个包含name和description的 YAML而这个 description 是全小写的自然语言。适配器需要把triggers里的关键词全部转成一句描述性的英文句子因为 Claude 系工具依赖描述匹配来决定是否加载技能。这话说起来简单做起来很微妙关键词不能是生硬的列表得是happens when的句式。我调试了很久才发现这一点。至于 Continue 这类结构化 JSON 工具适配器就是纯写 JSON 格式把 Markdown 正文塞进字符串字段里。这里的坑主要是转义——Markdown 里的引号、反斜杠、换行符在 JSON 序列化时必须正确处理否则工具加载配置时直接报错。4. 适配层没有想象中简单各工具格式的转换实录4.1 一个通用的转换流水线前人踩过的坑我就不重复了直接说我最终打磨出的适配器流水线它把技能 Schema 转目标格式这件事拆成了四个阶段解析阶段读取技能 Markdown 的 frontmatter 和正文转成内存中的技能对象。模板阶段根据目标工具的格式选择对应的输出模板。有的工具模板很简单比如 Copilot 就是追加进总文件有的复杂比如 Claude Code 要生成一个目录里面放 SKILL.md 和额外资源。渲染阶段把技能对象填充进模板生成目标文件内容。落盘阶段由部署器负责写到正确路径并更新版本记录。这个流水线里最值得注意的设计是模板与逻辑分离。适配器的业务逻辑只做把技能对象的某个字段映射到模板的某个变量具体工具想要什么格式用模板描述就好。这样后续工具改版了多数情况下只需要改模板不用动引擎代码。4.2 转换示例把同一个技能部署成三种工具格式拿上面数据库变更审阅那个技能举例看一下它部署到三个工具时生成的不同文件内容。部署到 Cursor 时会生成.cursor/rules/db-change-review.mdc--- description: 审阅数据库变更脚本检查索引、回滚方案和影响评估。当收到数据库变更、迁移脚本相关请求时使用。 globs: - **/*.sql - **/migrations/** alwaysApply: false --- 审阅数据库变更脚本时必须按以下顺序执行检查 1. 是否包含回滚脚本没有则标记 Block ...部署到 Trae 时生成trae/rules/db-change-review.md。Trae 的规则文件跟 Cursor 非常像但它的头部不支持globs字段所以我这边给 Trae 适配器的模板直接忽略globs把关键词并进了描述里。部署到 Claude Code 时生成~/.claude/skills/db-change-review/SKILL.md--- name: db-change-review description: Use when reviewing database migration scripts, checking rollback plans, index safety, and impact assessment --- 审阅数据库变更脚本时必须按以下顺序执行检查 ...有没有注意到描述语言不同为了让你看的例子更直观我特意保留了这一点。Cursor 体系里 description 是给人类看的标签怎么写都行Claude 体系里 description 是给模型判断何时触发用的必须写成自然语言描述。如果你在两个工具里换着写会怎样在 Cursor 里写英文自然语言还行但在 Claude 工具里写一堆中文碎片化关键词模型触发精确度会明显下降。4.3 转换中真正会踩到的坑顺序、转义、文件权限转换逻辑本身不复杂复杂的是各种边角情况。我踩过的坑里下面这三个最值得拿出来说。第一个坑是文件顺序敏感。GitHub Copilot 的指令文件在加载时是顺序注入的如果后面一个技能说要忽略所有测试而前面一个技能说必须补充测试后加载的会把前面的覆盖掉。所以我在给 Copilot 生成拼接文件时默认按技能的config.priority字段排序高优先级放后面并提示用户不要把相互冲突的技能同时部署到 Copilot。第二个坑是转义问题。Continue 这类 JSON 化工具技能正文里的反引号、美元符号、换行符一旦序列化出错整个配置文件就废了。我的适配器在落盘之前会跑一遍 JSON 语法校验解析失败就拒绝部署并给出具体错误位置。这个校验逻辑虽然只花了我半小时写但至少在真实场景里救了我四次。第三个坑是文件权限。在 Linux 环境下Claude Code 的技能目录要求文件对所有用户可读否则 Agent 可能因权限不足而无法读取技能。我遇到过明明文件存在但模型一直表现异常的情况排查到最后发现是 chmod 权限问题。所以现在部署器在写完文件后会自动检查权限不是 644 就自动修正。5. 真正好用的地方批量部署、版本回溯与团队共享5.1 批量安装与一键回滚如果一个技能只用一个工具那上面说的所有功能其实都不太必要你手工复制粘贴也就几秒钟的事。Skills Manager 真正的价值在批量场景下才体现出来。批量部署的核心是platforms字段。我可以在界面里勾选把 db-change-review 这个技能部署到所有打上勾的工具然后一次生成所有目标格式的文件分别写到各工具的正确目录里。这背后其实就是遍历平台列表调对应适配器走一遍流水线。部署完成后界面里会展示一份成功/失败清单。失败的情况通常是某个工具的目录不存在或者文件被占用我可以快速定位并人工处理。版本回溯是我后来加的功能起因是团队里一个同事在改技能时不小心把一条检查规则删了而且没注意就部署到了全部工具等发现时已经有好几个 Agent 按错误规则在跑。现在部署器每次部署前都会把当前版本的文件快照存下来。一旦发现某次部署有问题我可以在界面里选择任意历史版本一键还原。5.2 技能包的集中管理与团队共享个人使用场景里管理的是自己常用的一套技能。但 Skills Manager 对团队协作场景同样友好。技能总仓库本身就是一个普通的目录我可以把它丢到 GitLab 的仓库里用 Git 做版本管理。团队成员拉下来后Skills Manager 直接加载这个目录作为总仓库。新增、修改技能后用 Git 提 MR走正常的 review 流程确认后合并大家再在应用里点一下拉取更新新技能就自动部署到各自的本机工具里了。技能包这个词在团队语境下很有用。一个技能包其实就是一组技能文件的集合按场景划分比如前端项目规则包包含代码风格、目录组织、样式规范而后端服务规则包包含接口设计、异常处理、数据库变更。我团队的实践是按项目类型建技能包新项目启动时导入对应的包所有 AI 参与的代码产出就会自动遵守同一套规范。5.3 大模型选型与技能的关系选哪个模型需要什么技能包用 Skills Manager 的过程中我越来越明确一个判断Agent 技能与所用的模型能力是强相关的技能包不是通用的。选哪个大模型直接决定了你该给它配什么技能。给一个直观的划分如果你用的工具默认接的是 Claude 系模型它的长指令遵循能力很强技能描述可以写得详细、步骤可以很复杂适合用深度审查、多层校验这类技能。如果你在某个工具里用的是一个轻量型模型比如某些工具的免费档模型那技能就得写得短、明确、直白因为模型上下文容量有限长技能可能直接被截断或忽略。我在项目里给每个技能加了一个字段model_profile标注这个技能在什么能力层级的模型上经过了验证。部署时如果发现当前模型能力与技能标注不匹配会给出警告。这个话题往深了说能聊很久但核心就一句话技能包应该围绕你要解决的特定问题 模型能力边界来组织不要试图用一个万能包覆盖所有场景。6. 实测数据与踩坑清单哪些工具改版后会断掉6.1 一张表格看完 54 个工具的兼容性现状收尾之前我把目前已适配工具的实测兼容情况整理成一张表方便同样在做类似事情的朋友参考。工具分类典型工具技能格式稳定性技能目录位置适配难点独立 CLIClaude Code较稳定~/.claude/skills描述触发词必须英文描述编辑器插件Cursor中版本间差异大.cursor/rules.mdc 格式随版本演进编辑器插件Trae中国内版本差异多trae/rules规则文件命名有版本差异IDE 扩展Continue稳定config.json 内嵌JSON 转义容易出现IDE 扩展Cline较稳定用户目录下 skills 目录触发描述与 Claude 类似云 IDEReplit / CodeSandbox较稳定项目级 .replit 等跨项目同步困难原生助手GitHub Copilot稳定.github/copilot-instructions.md全文拼接规则容易变长表格里的适配难点这一列基本代表我在适配各工具时花时间最多的地方。整体来看凡是把技能定义为独立目录独立文件的工具适配起来都相对顺利凡是把技能定义为单文件全文拼接的维护成本就高一些——因为工具本身不支持隔离你在部署时就得考虑不同技能在同一文件里的相互关系。6.2 工具升级导致的破坏性变更我遇到的三次这半年里我至少有三次被工具版本更新打得措手不及。第一次是 Cursor 从 0.45 升到 0.46规则文件的扩展名和头部格式有变化老格式的.md规则虽然能读但新的alwaysApply字段不管用了。我当时的适配器还在按旧格式输出结果部署新技能后规则根本没生效。这种事只有实际部署后跑一下任务才能发现纯静态检查根本看不出来。后来我在适配器里加了一个冒烟测试入口部署完成后用一个种子问题调用该工具的接口确认技能确实注入了才算部署成功。第二次是某工具更新后把技能目录从项目级改成全局配置覆盖项目级语义完全反过来了。原来项目下放一个规则文件就能生效新版必须全局放一份项目级的反而被忽略。那次我在公司内部推广这个工具的技能包结果全部失效排查了一下午才发现是语义翻转。好在 Skills Manager 的适配器改一下模板就能应对但这也说明了一个现实工具生态变化速度远快于任何单一工具的适配速度。第三次是 Trae 的规则模块调整它一度想兼容 Cursor 的.mdc格式后来又改回了自有的方式。那段时间我的适配器没法同时满足两种情况只能做一个双模式检测先探测目标 Trae 版本对应的规则目录结构再决定输出旧格式还是新格式。这三次经历让我彻底明白了做工具适配永远不要假设今天能用明天也能用。你必须在架构里预埋快速响应变化的能力。6.3 给同样想入坑的人几条真心话Skills Manager 开发到现在差不多半年日常使用完全没问题但我也很清楚它的边界在哪里。写这篇文章的时候适配列表是 54 个工具但实际稳定性判断是只有约 30 个工具的适配经过了长时间验证其余处于能用但不保证遇到更新会抖一下的状态。如果你也想做类似的工具中枢我的建议是先在能力范围内维护 1015 个常用工具的适配比贪多更实在。最后分享一个我在实际使用中的体会做这种统一管理工具最核心的价值反而不是省掉重复劳动而是它强迫你把散落各处的 Agent 技能当成一份可版本化的资产来经营。在这之前我的技能是依附在某一个工具里的工具一换技能就没了。现在有了技能总仓库技能本身变成了独立于任何工具的资产。你可以随时从 A 工具搬到 B 工具不用重新教一遍 Agent 你的规矩这种自由度带来的安心感比省下的那点时间更值钱。