Skills Manager：跨平台统一管理AI编程工具技能资产

近几年AI编程工具爆发式增长Cursor、Claude Code、Codex CLI、Cline、Windsurf这些名字大家已经耳熟能详。但用多了之后我发现一个极度别扭的问题每个工具都有自己的Agent技能体系写一份代码审查规范要在Cursor里配一套Rules在Claude Code里装一个Skill在Cline里再导一份规则文件改一处逻辑就得同步改好几份稍微不同步行为就漂移。这个项目的想法很简单做一个叫Skills Manager的跨平台桌面中枢把散落在54 AI编程工具里的Agent技能统一收编、统一管理、统一分发。项目标题里的几个字——统一、54、跨平台、桌面中枢基本就是它的全部内核。这篇文章我尽量把设计思路、核心细节、实操过程、踩坑实录都讲透给你一份能直接参考的复盘。1. 项目概述我为什么非要搞这么个文件夹管家1.1 54工具背后的技能碎片化困局先说个数字。目前市面上主流的AI编程工具从闭源的Cursor、GitHub Copilot、Windsurf、Trae到开源的Cline、Continue、OS-Copilot再到各大厂自研的Codex CLI、Gemini CLI、Qwen Code稍微数一数活跃度尚可的至少几十款。它们几乎每一款都定义了自己的技能机制Claude Code 有SKILL.md和~/.claude/skills/目录Cursor 有.cursor/rules/和.mdc规则文件Cline 有 Memory Bank 和自定义指令模板Continue 有~/.continue/下的配置和 Agent 规则Windsurf 有.windsurf/rules/GitHub Copilot 有.github/copilot-instructions.md和自定义指令Codex CLI 支持AGENTS.md和自定义提示词这些工具各自的技能机制本质上都是在做同一件事给模型附加一套领域规则、工作流模板和工具调用约束。但它们的文件格式不一样、目录位置不一样、语法不一样连技能这个概念本身都不统一。我以前用Cursor写前端项目基于Shopify的Headless架构沉淀了一套代码审查技能迁移到Claude Code时几乎重写了一遍迁移到Codex CLI时又改了一版提示词。碎片化带来三个直接后果维护成本翻倍一个技能改三个地方改一处忘一处模型行为越来越不可控。团队协作困难成员用不同的AI工具沉淀的资产无法共享知识库被锁死在单个工具里。迁移成本极高换工具等于重新积累这对团队来说是个很重的隐性成本。Skills Manager的出现就是冲着这三个痛点去的。它把技能从某个工具的私有配置抽象成一份中立、可分发、可版本化的独立资产然后再根据目标工具的语法规则自动渲染成它需要的格式放进它认得到的目录里。1.2 这个项目到底解决了什么问题我习惯把Skills Manager定位成一个技能全生命周期管理工具写入支持从零创建技能也支持从Markdown、YAML、既有规则文件导入存储内部统一用标准Schema存储技能元数据不跟任何单一工具绑定渲染针对不同AI工具的规则语法渲染出对应的配置文件分发把渲染好的技能文件写入对应工具的规则目录或技能目录同步借助Git仓库或本地增量同步让多台设备的技能保持一致治理做冲突检测、优先级排序、启停控制避免规则互相打架说白了它就是把过去手写一堆规则文件、塞进不同目录、每次手动同步的低效流程收敛成打开桌面应用选技能选工具一键安装。这个思路和近几年前端圈流行的Monorepo统一管理多包很像——用一套中心化的编排治理散落在各处的碎片化资产。适合谁参考这篇复盘如果你是重度AI编程用户本地已经有几十个规则文件、技能目录乱成一团或者你在团队里负责维护统一的编码规范、代码审查规范、重构流程规范希望让所有成员的不同工具都吃到同一套规则那这个项目的思路大概率能给你不少启发。2. 整体设计思路统一Schema 双向分发2.1 摸底54工具的技能格式任何中心化方案第一步都是摸清底细。我花了不少时间逐个阅读主流AI编程工具的官方文档把它们的技能/规则机制做了个盘点。这里放一张我调研后的格式对照表工具名称技能目录/规则文件位置主要格式是否支持多文件技能Claude Code~/.claude/skills/SKILL.md 脚本/资源支持文件夹即技能Cursor.cursor/rules/*.mdc带Frontmatter单文件为主Cline插件/自定义指令Markdown JSON有限支持Continue~/.continue/config.yaml Markdown规则内嵌Windsurf.windsurf/rules/*.md单文件GitHub Copilot.github/copilot-instructions.mdMarkdown单文件Codex CLIAGENTS.mdMarkdown单文件Trae.trae/rules/*.md单文件Zed.zed/目录*.md单文件Gemini CLI~/.gemini/Markdown有限有些工具支持文件夹级技能比如Claude Code的一个技能可以是一个文件夹里面除了SKILL.md还有配套脚本和资源文件有些工具只支持单文件规则比如GitHub Copilot只能塞一个copilot-instructions.md。底层机制差异很大但描述层的结构高度相似几乎都是名称、描述、触发条件、正文步骤、补充资源这几个要素。这一步的价值在于它直接决定上层Schema怎么设计。如果只服务Cursor和Claude CodeSchema可以很轻但要覆盖54工具就必须把描述、触发、正文、资源、元信息彻底拆开才可能兼容两种完全不同的技能形态。2.2 为什么选择统一收益 渲染分发而不是直接兼容调研完之后有两条路可选方案A让Skills Manager直接读写各种工具的原生格式。比如读.cursor/rules/的时候解析.mdc读Claude Code的时候解析SKILL.md。这个方案的优点是所见即所得不引入中间层缺点是适配代码爆炸每新增一个工具就要写一套解析器而且两个工具的规则互相引用时根本无法统一表达。方案B定义一套中立Schema所有技能在Schema层维护向工具分发时再渲染成对应格式。这个方案的开发成本前置但后续每适配一个新工具只需要写一个渲染器不需要动已有的技能资产。最终我选了方案B。这背后有个很简单的逻辑技能是长期资产工具是短期偏好。今天我用Cursor明天可能切到Windsurf但我的代码审查流程、重构规范、测试约定这些沉淀不应该因为切换工具而被抛弃。一套中立Schema就是给这些资产提供了一个 免于平台绑架的存放地。实体一点说它就像一个技能仓库而各个AI编码工具都是从这个仓库拉取渲染成自己格式的商品。2.3 技术选型Tauri SQLite TypeScript桌面中枢的选型我最终确定了三个核心依赖Tauri作为桌面壳SQLite作为存储TypeScript作为业务层语言。选Tauri而不是Electron原因很实在Skills Manager本质是本地工具它要频繁读取文件系统、遍历目录、调用Git命令这些场景下Tauri的Rust后端与系统交互更干净而且内存占用远低于Electron。实测下来Tauri壳的内存占用在80MB左右Electron同类应用普遍在300MB往上。对一款常驻后台做技能监听的桌面工具来说这个差距体感很明显。选SQLite是为了技能索引。技能库规模大了以后需要按工具、按标签、按状态过滤每次打开应用都全量扫描一遍54个工具的目录太慢不如在SQLite里建索引后台增量扫描界面秒出。索引字段包括技能ID、名称、标签、目标工具集合、最后分发时间、冲突状态等。业务层用TypeScript主要考虑是生态和难度。渲染器逻辑本质是对象到字符串模板的映射这种活TypeScript写起来最顺手而且市场上大量AI工具的配置格式文档都是JSON/Markdown/YAMLTypeScript处理这三样有天然优势。3. 核心细节解析与实操要点3.1 一套Schema如何装下所有技能形态前面提到的中立Schema我是这么设计的。核心是一个技能对象包含{ id: code-review-rules, name: Code Review, version: 1.2.0, description: 发起代码审查时自动应用的多维检查规则, tags: [code-review, quality], triggers: [code review, 审查, pull request], tools: [cursor, claude-code, codex, cline, windsurf], context: { allowedFiles: [src/**/*], excludedFiles: [dist/**/*] }, body: [ { type: instruction, content: 对PR进行逐文件审查优先级安全性 性能 可读性。 }, { type: script, ref: scripts/check-security.py, runtime: python } ], resources: [templates/review-report.md] }这个结构把技能的描述层与实现层剥开了description、triggers、context是描述层用于工具判断什么时候启用这个技能body里的指令和脚本引用是实现层用于指导模型具体怎么做。这样拆分之后渲染成Cursor的.mdc时把description映射到Frontmatter的description字段把triggers映射到globs或alwaysApply把body逐条渲染成正文Markdown渲染成Claude Code的SKILL.md时则把name和description放进YAML头把body渲染成正文脚本直接原样复制到技能目录下。3.2 技能脚本与LLM指令分离的设计最初我犯过一个错误想把脚本内容直接以Base64形式内嵌到JSON里这样技能文件自包含分发时不用管依赖。后来发现这个设计很蠢——脚本体积稍微大一点JSON就变成一坨你完全不想维护的东西更麻烦的是不同工具的技能目录对脚本的可执行权限要求不一样内嵌方案反而让权限控制变得鬼畜。最终改成了指令脚本引用分离指令LLM要执行的动作描述放在body里分发给所有工具脚本具体要跑的代码放在resources或scripts目录分发给支持文件夹级技能的工具对于不支持脚本的纯单文件工具比如Copilot渲染器自动把脚本名作为需要人工执行的提示写进正文例如一个用于扫描代码中的硬编码密钥的技能在Claude Code分发时脚本scan-secrets.py会被复制到技能目录下SKILL.md里写运行python scan-secrets.py并将结果按模板输出在Cursor分发时scan-secrets.py根本无法放进.cursor/rules/渲染器就把正文改成若当前代理支持脚本调用请运行扫描脚本否则仅执行人工检查步骤。这个细节很关键。技能的统一管理不只是格式的统一更重要的是能力边界的路由同一份资产要能自动适配目标工具的能力上限而不是一刀切地要求在哪儿都能跑脚本。3.3 分发时的冲突检测与优先级规则技能装上容易装多了就会打架。最典型的场景Cursor的Rules目录里有一条规则 始终使用 pnpm 安装依赖 另一条规则 包管理器统一使用 yarn两条规则同时存在时模型会非常困惑。Skills Manager做了一个三层冲突检测机制触发词冲突检测两个技能定义了相同或近似的triggers应用启动扫描时会在界面上给出警告提示这两个技能可能互相干扰。规则正文语义检测对分发给同一工具的同类型技能如果正文中存在明显的互斥指令比如同时出现禁止和必须作用于同一行为记录为潜在冲突。上下文覆盖检测如果用户给技能设置了context比如allowedFiles、excludedFiles系统会检测重叠路径下是否有冲突的技能。检测到冲突后Skills Manager不会自作主张删技能而是把冲突展示在治理面板里让用户决定优先级。优先级高的技能在有冲突时会排在目标文件的更前面或者在渲染时自动追加一句本规则优先级高于其他冲突规则的说明。实践证明这种展示路由的模式比强制自动解决更适合技能管理——LLM能不能遵守规则很大程度上取决于规则之间是否逻辑自洽这个判断不该完全交给机器。3.4 用Git同步实现跨设备技能一致跨平台只是说它能跑在Windows、macOS、Linux上真正让技能跨设备保持一致的是Git同步机制。Skills Manager内置了一个可选的能力把整个技能库目录初始化为一个Git仓库。每创建一个技能或做一次分发都会自动生成一次带语义化message的commit例如feat(skill): 新增Code Review技能 chore(dispatch): 分发code-review到cursor fix(conflict): 解决code-review与scan-secrets的触发词冲突这个设计的好处是技能变更的历史可以被追踪误改可以随时回滚多台设备的技能库可以通过Git远端做同步而且Git本身就有跨平台的文件权限处理和冲突合并能力比自研同步靠谱得多。实际使用中我在公司的Windows主力机、macOS个人本和一台Linux开发机上共用同一套技能库通过远程仓库同步体验和代码库协同几乎一致。4. 实操过程从零到一把梭的完整演示4.1 安装与首次初始化我以当前最新的Skills Manager桌面版为例。安装包从项目Release页面下载Windows是.msimacOS是.dmgLinux是.AppImage。安装完成后首次启动会引导设置两个东西技能库的存放位置和需要纳入管理的工具集合。技能库目录我建议放在用户目录下独立文件夹比如~/skills-repo而不是塞进某个工具的配置目录。这样后续切换工具、重置工具配置时技能资产不会跟着丢。工具集合的选择界面长这样勾选你正在用的工具即可[ x ] Cursor [ x ] Claude Code [ x ] Codex CLI [ ] Cline [ x ] Windsurf [ ] GitHub Copilot [ ] Trae [ ] Zed这里注意一个操作技巧尽量在“工具集合”中只勾选你真正在用的工具。全选也不是不行但Skills Manager会为每个勾选的工具创建对应的分发目录如果你的机器上没有装这个工具目录里会被塞进一堆无人认领的文件后续清理很麻烦。初次使用宁可少勾等需要时再通过设置面板增量添加。初始化完成后应用会做一次全量扫描读取你勾选工具的所有技能/规则目录把已存在的技能文件全部导入到中立Schema层。这一步完成后你的所有旧资产并非被删除而是入库了。Skills Manager默认只是导入并建立索引在用户明确确认以托管模式接管之前不会动原始文件。4.2 用GUI创建第一个技能点击新建技能表单会分几个区域基本信息、触发条件、工具适配、正文内容。我以一个实战技能Rust代码审查为例基本信息名称rust-code-review描述对Rust代码进行所有权、错误处理、并发安全三个维度的审查标签rust、code-review、quality触发条件triggers: - rust代码 - cargo clippy - ownership - unsafe工具适配tools: - cursor - claude-code - codex正文内容我填了核心审查指令1. 检查所有权与借用重点查看是否存在不必要的 clone、长时间持有的 MutexGuard。 2. 检查错误处理禁止使用 unwrap/expect 处理可恢复错误必须返回 Result 并向上传播。 3. 检查并发安全关注共享状态是否使用 Arc/RwLock写明存在 data race 风险的代码位置。 4. 输出格式按问题位置-问题类型-修改建议-参考示例四段式输出。填完之后点击保存。此时技能还没有被分发到任何工具它只是在中立Schema层被创建了。4.3 一键分发到Cursor和Claude Code在技能列表里选中这个技能右侧弹出分发面板勾选需要分发的目标工具点击应用。后端主要做了两件事。对Cursor渲染器把技能转成.cursor/rules/rust-code-review.mdc。我打开生成的文件看效果--- description: 对Rust代码进行所有权、错误处理、并发安全三个维度的审查。当用户请求审查Rust代码时自动应用。 globs: [**/*.rs] alwaysApply: false --- 对Rust代码进行审查核心维度 1. 检查所有权与借用重点查看是否存在不必要的 clone、长时间持有的 MutexGuard。 2. 检查错误处理禁止使用 unwrap/expect 处理可恢复错误必须返回 Result 并向上传播。 3. 检查并发安全关注共享状态是否使用 Arc/RwLock写明存在 data race 风险的代码位置。 4. 输出格式按问题位置-问题类型-修改建议-参考示例四段式输出。注意description被映射成了Cursor需要的描述字段globs被映射成了**/*.rstriggers被转换成了当用户请求审查Rust代码时的语义描述。这些映射关系都在渲染器里配置用户不需要手动处理。对Claude Code渲染器在~/.claude/skills/rust-code-review/下生成SKILL.md--- name: rust-code-review description: 对Rust代码进行所有权、错误处理、并发安全三个维度的审查。当用户要求审查Rust代码、分析unsafe代码块或评估并发设计时使用此技能。 version: 1.0.0 --- # Rust代码审查技能 ## 审查步骤 1. 检查所有权与借用重点查看是否存在不必要的 clone、长时间持有的 MutexGuard。 2. 检查错误处理禁止使用 unwrap/expect 处理可恢复错误必须返回 Result 并向上传播。 3. 检查并发安全关注共享状态是否使用 Arc/RwLock写明存在 data race 风险的代码位置。 ## 输出要求 - 所有问题按问题位置-问题类型-修改建议-参考示例四段式输出。同样的技能内容在不同工具里被渲染成了各自习惯的语法。这套渲染逻辑就是整个项目里最值得反复打磨的部分。4.4 在IDE里验证分发效果分发完成后实际打开Cursor新建一个带明显Rust问题的文件fn read_config(path: str) - String { let content std::fs::read_to_string(path).unwrap(); content }然后在对话里问一句帮我审查这段代码。Cursor根据.cursor/rules/中的技能规则会明确指出unwrap在不具备可恢复错误处理上下文时被使用并给出修改建议——用ResultString, io::Error替代。在Claude Code里执行同样的操作效果一致。这个场景就是整个项目最有说服力的演示过去你需要在两个工具里维护两套规则现在维护技能库里的Style Schema一份两个工具同步生效。5. 常见问题与排查技巧实录5.1 工具识别不到技能文件这是最常遇到的问题。装好了规则但工具就是好像没读到。排查路径我按概率排序路径是否精确正确。用户目录的路径在不同系统上差异很大macOS是~/.cursorWindows上是C:\Users\用户名\.cursor。Skills Manager在初始化时做了路径探测但如果你的工具是便携版、绿色版它的配置目录可能不在默认路径需要手动指定。规则文件的扩展名是否符合工具要求。Cursor的规则文件是.mdc如果你分发出来一个.md文件Cursor大概率不会自动加载。这是最容易忽略的。工具的配置热加载机制。Claude Code在会话启动时加载技能列表中途新增的文件不会立刻生效需要重启会话或使用/reload重新加载技能。代码仓库里添加.cursor/rules时Cursor有时需要重新加载窗口。权限问题。在Linux上如果技能目录的owner是root而当前用户是普通用户工具可能因权限不足跳过该目录。检查一下~/.claude等目录的权限是否正常。5.2 跨工具附加上下文不一致分发到不同工具后同样一个技能在不同工具里触发的上下文可能不一样。最典型的差异是Cursor的.mdc支持globs路径匹配可以精确指定只在.rs文件下生效而Claude Code的SKILL.md只有description里的语义描述没有路径级限定。所以同一个技能在Cursor上可能表现为打开Rust文件时自动可用在Claude Code里却表现为每次会话都加载。聊天时Claude Code的上下文会被多余技能塞满Token消耗明显变大。解决办法在创建技能时对Claude Code这类工具渲染时把alwaysApply相关配置项设为false或者在description里明确写仅在用户请求Rust代码审查时使用。不要指望渲染器自动做完美裁剪还是要靠人肉调一下分发参数。5.3 技能更新后没有生效原因是工具侧基本都会维护一份缓存的技能索引。你修改了.cursor/rules/xxx.mdcCursor可能还在用内存里旧版本Claude Code也有类似的缓存机制。两个技巧技能里带上明确的版本号并在正文开头写一句本技能版本x.y.z。AI工具加载规则时模型能看到版本变化至少能提醒你当前加载的是旧版。分发完成后触发一次工具的重载。Cursor可以重启窗口Claude Code在对话中执行/reloadCodex CLI重启交互会话。这个问题的本质在于文件即配置模式的滞后性AI编程工具对规则文件的变更感知基本还停留在启动时扫描阶段实时监听做得好的不多。5.4 冲突覆盖导致行为崩溃我在实测阶段遇到过最头疼的一个问题同时安装了代码风格强制pnpm和包管理器统一yarn两条技能后模型的回答时而说pnpm时而说yarn完全没有一致预期。排查后发现两个技能的triggers都包含了安装依赖package manager这类词模型在触发阶段无法确定该用哪个技能于是同时加载两个从规则层面自相矛盾。处理方式分两步在Skills Manager里把两个技能的triggers尽量差异化比如一个专注安装依赖时的命令选择另一个专注依赖声明文件的管理。在冲突面板明确设置优先级低优先级技能在渲染时会自动追加当与其他包管理规则冲突时以优先级更高者为准的说明。这个坑也说明了一个道理技能管理最难的从来不是文件搬运而是语义层的秩序。工具越多技能越重叠规则打架的概率就越高。6. 一些实测心得与后续扩展思路真刀真枪用了两三周之后我对这个项目的体感是它未必让单个AI工具变聪明多少但让多个AI工具协作这件事变得清爽了非常多。对我来说最有价值的一点是我终于不用在每次切换工具时把几十条规则翻出来重写一遍了。技能资产沉淀在了中立层用什么工具由它替你翻译。有几个经验可以分享技能命名要带领域前缀。我用lang:前缀和domain:前缀两层比如lang:rust、domain:code-review后续做标签筛选和冲突检测都方便。不要把一次性提示词和技能混为一谈。一次对话里临时让模型按某个步骤操作那叫提示词不需要入库只有你反复使用、希望多个工具统一步调的才值得做技能。入库的门槛太低库很快就会变成垃圾场。版本号和变更记录一定要留。AI模型对规则文件里的版本描述很敏感写上版本号后至少能在模型怀疑规则冲突时追溯到具体是哪个版本引入的。分发前先小范围验证。先在Cursor或者Claude Code单测一个技能确认行为符合预期后再分发到其他工具。一上来就全量分发遇到问题会很被动。这个项目的后续方向我个人最看好两个一是引入技能套件的概念把一组相关技能打包成一个Profile比如前端项目初始化套件、Python数据工程套件一键分发到所有工具二是做技能网络——在Schema里显式声明技能之间的依赖关系当两个技能存在冲突时根据依赖图自动推断应该禁用哪个。第一版全靠人肉治理随着技能规模上去一定会需要机器辅助的秩序维护。如果你也在被多工具技能同步搞到头大不妨自己动手搭一个类似的中心化抽屉把散落在各个AI工具里的技能杂物重新收纳起来。