老实说把54个AI编程工具的Agent技能统一到同一套体系里这件事做之前我自己都觉得不太可能。项目叫Skills Manager定位是一个跨平台桌面中枢专门用来管理散落在各款AI编程工具里的Agent技能。起因特别朴素我自己同时在用Cursor、Claude Code、Codex、Windsurf这些工具每个工具都有自己定义技能的方式有的认.rules文件有的依赖CLAUDE.md有的靠AGENTS.md换一个工具就得把所有技能手工重写一遍。忍了一段时间后我决定做一个桌面应用把技能统一用一种格式描述再通过适配层自动翻译成各个工具认识的配置从根源上解决“技能碎片化”的问题。这篇内容就是把项目的设计思路、核心架构、实操步骤和踩坑记录都摊开讲一遍适合那些同时使用多款AI编程工具、手头攒了一批自定义技能但又不知道怎么管理的开发者参考。1. 为什么要做 Skills Manager被技能碎片化逼出来的项目1.1 每个AI工具都有自己的“技能黑话”别管叫法是Skill、Command、Rule还是Custom Instruction本质都是一件事给AI Agent一段可复用的指令模板让它按固定套路干活。可问题在于不同工具为了让这段指令能被模型理解接口和格式五花八门。Cursor喜欢把规则塞进.cursor/rules目录一个技能一个Markdown文件文件名和frontmatter都有讲究Claude Code则倾向于用CLAUDE.md加斜杠命令或者放到.claude/skills目录里每个技能还要单独一个文件夹Codex认的是AGENTS.md最好按仓库层级放GitHub Copilot又把自定义指令藏在自己的配置面板里。这些都还是“改改格式”能解决的事更麻烦的是有些工具支持变量注入有些不支持有些能引用外部上下文文件有些只能把所有内容拼进系统提示词。我在维护自己那套“代码审查”“需求拆分”“接口文档生成”的技能时真切体会到了什么叫“东一块西一块”。今天在Cursor里改了规则明天切到Claude Code发现还是旧的同一个技能在三个工具里有三个版本改起来还得三处同步。这种状态持续了大概两个星期我就意识到不能再靠手工维护了得有一个专门的东西来管这件事。1.2 54工具是怎么筛选出来的项目名字里的“54”不是拍脑袋而是我按自己的使用场景筛出来的一个真实规模。市面上支持Agent能力或自定义技能的AI编程工具其实远不止这么多但很多要么只能云端编辑要么不支持本地文件导入要么数据结构太封闭根本不适合放进统一管理。我筛工具的标准有三条第一支持本地可见的技能/指令/规则文件至少能通过配置文件或目录挂载第二Agent能力是主功能或高频功能不是偶尔附带一个聊天窗口第三有正常维护节奏不是试水项目。按这个标准我对照IDE插件类、命令行工具类、在线IDE类、开源框架类和AI编程平台类这几个大方向筛下来当时符合条件的一共54个。Cursor、Windsurf、Visual Studio Code系的AI插件、JetBrains系的AI助手、Claude Code、Codex CLI、Aider、OpenCode这些是大家最常用的一批再往周边走还有像Continue、Tabby、Mentat这种开源项目以及一些支持Agent技能的独立CLI工具。54这个数字并不重要重要的是它代表了一个趋势AI编程工具越来越多每个工具都在做自己的Agent也都在定义自己的技能格式。没有统一标准之前用户积累的技能就是被绑在一个个孤岛上。Skills Manager想解决的就是在这些孤岛之间架桥。1.3 为什么偏偏做成“跨平台桌面中枢”有人会问技能管理不就是读写配置文件吗写个命令行工具不就行了还真不是。技能这种内容一半是结构化的配置一半是自然语言的指令改起来特别依赖预览和对比。命令行工具处理单文件还行真到了要整理50多个工具的技能依赖、检查版本差异、批量启用禁用的时候交互体验完全是不够用的。桌面中枢的价值就在这它是本地的、可视化的、带完整交互界面的管理入口所有技能都躺在本地仓库里想改哪个改哪个想导出到哪就直接点选。技术栈上我最终选了Tauri而不是Electron。原因是桌面应用如果只是为了管理一堆文本和调用系统API没必要捆一个几百兆的运行时。Tauri用Rust做后端前端跑WebView打包体积小内存占用比Electron低一大截而且Rust在文件系统操作、并发读写、路径处理这些场景下非常稳不容易出幺蛾子。数据存储我用了SQLite技能的本体则直接以文件形式放在仓库目录里数据库只存索引、标签、依赖关系和同步状态。这样设计的好处是技能文件本身是纯文本随便用编辑器改也行放进Git也能正常diff数据库坏了也不至于丢技能内容。中枢这两个字我还想特别解释一下。Skills Manager不是一个Agent运行时它不负责替你执行技能也不抢占各个AI工具的Agent调度权。它的角色更像是一个集散中心上游是“技能作者”也就是你下游是“执行环境”也就是那54个工具。你定义好技能Skills Manager负责把技能翻译成下游工具能识别的格式再放到对应位置工具真正调用技能的时候仍然是走自己的逻辑。这种“管不管执行”的边界划分让工具链里的角色清晰了很多。2. 核心设计统一技能模型与适配器架构2.1 统一技能模型USM从“乱七八糟”到“一块积木”把各种工具的技能格式抽象成一套通用模型是整个项目的基石。我给这套模型起名USM全称是Unified Skill Model一句话概括就是把技能拆成声明、指令、上下文和工具映射四个部分。一个USM技能就是一个带frontmatter的Markdown文件或者也可以写成YAML加正文的结构。frontmatter里是结构化声明包括技能名称、描述、触发词、适用工具、依赖关系、变量定义、允许调用的工具列表正文里就是给AI模型看的指令正文。下面是我一直在用的一个示例name: code-review description: 对指定代码变更执行一次系统性代码审查输出问题清单和修改建议 trigger: - review - code review targets: - cursor - claude-code - codex variables: - path - depth allowed_tools: - terminal - read_file - grep_search version: 1.4.0 depends_on: - conventional-commit-rules --- 你需要扮演一位资深代码审查者。针对变更内容完成以下步骤 1. 使用 read_file 读取目标文件使用 grep_search 确认影响面。 2. 先检查是否符合项目约定的 commit 规范再检查潜在 bug。 3. 按“严重问题 / 建议改进 / 风格建议”三级输出。 4. 每条结论必须给出具体行号和可执行的修改建议。 变量说明 - path要审查的文件或目录路径。 - depth审查深度可选值 summary / normal / full。为什么把上下文单独拆出来因为很多技能不是靠一段话就能干活的它需要引用背景文档、API规范、项目架构说明。统一模型里我加了一个context_files字段允许技能声明依赖的外部文件导出时适配器会把这些文件的内容一起处理该内联的内联该单独放置的单独放置。这个设计解决了长技能在部分工具里“塞不进系统提示词”的问题。2.2 适配器层每个工具一个翻译器统一技能模型只是中间表示真正让它跑起来的是适配器层。我当时的思路很简单54个工具存在54种目标格式但核心逻辑应该是“从USM到目标格式的转换”而不是“每个工具单独做一套管理逻辑”。所以我用Rust的trait定义了一个统一接口每个目标工具实现对应的Adapter。接口大概长这样#[async_trait] pub trait SkillAdapter { fn tool_key(self) - str; fn detect_config_path(self) - ResultPathBuf; fn export(self, skill: UnifiedSkill, options: ExportOptions) - ResultExportReport; fn import(self, source_dir: Path) - ResultVecImportedSkill; fn snapshot(self) - ResultVecFileSnapshot; }每个Adapter只做三件事找到工具的配置目录、把USM技能转换成目标格式、把转换结果写到正确的位置。比如Cursor的Adapter会把USM技能渲染成一个带frontmatter的Markdown文件扔进.cursor/rulesClaude Code的Adapter则会创建一个.claude/skills/code-review/目录里面放SKILL.md和必要的辅助文件Codex的Adapter会把技能内容转成能追加到AGENTS.md的段落同时处理好标题层级。这样设计还有一个额外好处新工具接入的成本变得极低。我只需要给这个工具写一个Adapter复用已有的USM解析、变量注入和模板渲染逻辑基本上几百行Rust代码就能接入一个同类工具。后来项目能轻松覆盖54工具靠的就是这种“翻译器插件化”的架构。2.3 双向同步统一导出的同时还能收编存量技能做技能管理不能只管“从中心往外发”还得把用户已经散落在各工具里的存量技能“收”进来。不然的话一个用了两年Cursor、积累了20个自定义规则的开发者凭什么把家底全搬到新系统里Skills Manager支持双向同步启动任意一个工具的同步任务后适配器会扫描该工具的技能目录把已有文件读取进来识别出哪些匹配USM结构、哪些是纯文本规则然后生成候选导入列表。这个过程我特别处理了覆盖风险。同一个技能可能已经存在目标目录里这时候不能无脑覆盖。我的做法是每份文件都会计算哈希值写入前先对比目标文件哈希如果两边内容不一样就弹出一个差异预览窗口左边是当前版本右边是候选版本让用户自己决定是覆盖、保留还是另存为新技能。对于像Cursor这种规则文件特别多的工区这个机制救了我好多次至少没有出现过“同步一次把我手写规则冲掉”的惨案。双向同步还让“把Skills Manager当作管理事实源”这件事变得可行。你可以手工改某个工具的配置文件再回到Skills Manager点一次“导入”变更就会被收进统一技能库下次再导出到其他工具时所有改动都会随之带上。这种收编能力和分发能力一结合技能流动起来之后工具里的玩法就完全不一样了。2.4 标签、依赖、变量与安全控制把技能变成工程资产技能一旦变多就不能只靠目录和文件名管理了。我在USM模型里加入了标签体系、依赖关系和变量定义让技能像代码一样具备“工程化”能力。标签体系很好理解按“前端/后端/测试/文档”或者“代码审查/重构/架构设计”打标签界面里可以按标签过滤批量操作也有了依据。依赖关系稍微复杂一点一个“重构规划”技能可能会依赖“代码地图生成”技能一个“需求分析”技能可能会依赖“用户故事拆分”技能。我在模型里加了depends_on字段导出时会自动检查依赖链并且把依赖技能的存在性校验放在导出前缺了会给出明确提示而不是等技能跑到一半才发现上下文不够。变量注入解决的是“同一个技能在不同工具里路径不一样”的问题。我的技能模板里经常会写{workspace}、{language}这种占位符导出时适配器会根据目标工具的上下文把占位符替换成实际值。比如Cursor里workspace对应当前工作目录Codex CLI里它对应仓库根目录参数可能还不一样但技能作者只要在USM里声明一次剩下的事情交给适配器处理。安全方面我做了两层第一层是技能本身的安全。模型很容易受到提示词注入攻击如果有人把恶意指令藏在“待审查代码”或“参考文档”里技能执行时就可能被带偏。所以我给技能加了一个allowed_tools白名单导出到支持权限控制的工具时适配器会把白名单转成工具的运行约束技能只能调用当前声明的工具超出范围直接拒绝。第二层是本地文件操作的安全。Skills Manager对技能仓库的读写全部限制在用户明确授权的目录内不会跟着软链接跑到系统目录里去乱动至少不会因为一次误操作把配置目录搞得一团糟。3. 实操从零到一把技能写进54个工具3.1 安装、初始化与技能仓库布局不管Windows、macOS还是Linux安装Skills Manager的思路都是一样的下载对应安装包装好后启动第一次运行时选择技能仓库目录。我建议最好把这个目录纳入Git管理整个目录结构长这样skills-repo/ _shared/ commit-conventions.md architecture-overview.md code-review/ skill.yaml template.md refactoring-plan/ skill.yaml template.md docs-generator/ skill.yaml template.md第一次初始化时Skills Manager会在仓库根目录生成一个.skills-manager/配置目录里面存放索引数据库、同步状态和全局设置。这里有一个很重要的设计原则技能文件永远以人可读的纯文本躺在目录里数据库只是缓存和索引。这样做的好处是哪怕Skills Manager一个月不开你的技能还是那些文件不会因为数据损坏就整体蒸发。初始化完成后主界面分三个区域左侧是技能列表和标签筛选中间是技能内容预览和编辑区右侧是目标工具面板列出所有已检测到的工具及其同步状态。你完全可以把Skills Manager看成“技能版的VS Code”——文件浏览器加编辑器加一堆集成操作。3.2 定义一个“代码审查”技能的真实示例下面我完整走一遍创建一个技能的过程。先点“新建技能”填好名称、描述和触发词然后编辑技能内容。这一步我不推荐在界面里直接写完一整个长指令更好的做法是先用模板搭骨架再逐步细化。Skills Manager内置了几个基础模板“代码审查”“错误排查”“需求拆分”都有可以从模板派生。以代码审查技能为例我的USM内容会包含几个区块。frontmatter里的变量部分要提前定义好因为后面导出到不同工具时变量注入器会依赖这些定义正文部分则不要写得像散文而是写成步骤化、带检查项的清单。AI模型对步骤清单的理解效果远好于一大段自然语言这已经被很多实践验证过了。写好技能后记得在界面右侧点一下“验证”Skills Manager会检查frontmatter字段完整性、依赖是否存在、模板变量是否都有默认值避免导出后再发现语法问题。3.3 一键导出到 Cursor、Claude Code 与 Codex技能创建完接下来就是最有成就感的步骤全选技能打开目标工具面板一键导出。导出不是简单复制文件而是每个适配器按自己的规则渲染目标格式。导出到Cursor时Cursor的Adapter会为每个技能生成一个Markdown文件写入.cursor/rules目录文件名与技能名保持一致同时为了兼容Cursor对规则的描述字段要求frontmatter里的description会被转成规则说明。导出到Claude Code时Claude Code的Adapter会创建一个技能目录把技能正文写入SKILL.md如果有辅助文件就放到同一目录下并在技能头的YAML区域写入name和descriptionClaude Code的新版技能格式更接近ANSI标准需要额外处理一下名称和版本字段。导出到Codex时Codex的Adapter会把技能转成适合追加进AGENTS.md的Markdown块还会自动生成一层标题锚点避免多个技能混排时找不到边界。执行导出的过程中右下角有一个任务队列每导出成功一个工具状态栏就会点亮一个。我第一次全量导出到54个工具时看着状态栏整整齐齐亮了一片那种爽快感很难描述以前要折腾半天的事情现在几秒钟就做完了。3.4 批量同步、软链接与排除规则导出做多了之后你会希望它更加自动化于是批量同步就显得特别有价值。Skills Manager支持两种模式手动模式和计划模式。手动模式就是你点一下“同步全部”系统跑一遍所有已安装工具的导出计划模式则是每15分钟检查一次技能仓库有没有变化有变化就自动同步到配置里启用的工具。关键设置是“软链接模式”。对于支持目录引用的工具我不建议直接把文件复制过去而是让Skills Manager在目标目录建立软链接指向技能仓库里的源文件。这样改技能仓库的文件等于直接改工具的配置文件避免了“同一份副本散落多处每次改完都要重新同步”的囧境。不是所有工具都支持软链接有的工具会扫描真实文件路径有的安装包更新时会清理目录碰到这类工具就乖乖用复制模式同时把备份开起来。排除规则是批量操作里特别容易忽略的一环。有的技能只适合CLI工具不适合IDE插件有的技能依赖Windows专属脚本在macOS上跑不了。这些情况都要在技能声明里用targets字段写清楚同步时才会自动跳过。我整理了一个常见的目标限制矩阵方便大家参考技能类型适合的典型工具限制说明终端命令辅助Codex CLI、Claude Code、Aider需要在终端类工具里运行不适合纯IDE规则代码库全局规则Cursor、Windsurf、Continue适合按工作区加载的规则不建议在CLI工具里重复注入跨仓库模板Claude Code、Copilot建议使用相对路径和模板变量避免写死绝对路径生成测试用例所有支持上下文加载的工具需要目标工具能读目录树最小化工具的依赖这个表只是示例实际配置可以根据自己的工具链扩展。4. 真实工作流里的 Agent 技能联动与避坑4.1 多个 Agent 共用一套技能时状态怎么隔离当我同时开着Cursor和Codex让它们用同一套代码审查技能处理同一个仓库时遇到过不少莫名其妙的问题。最大的一次是两个工具几乎同时触发了同一个技能双方都试图写一个临时文件结果把文件写成了互相覆盖的状态。后来我在技能模板里给每个工具预留了不同的临时目录变量比如Cursor用{temp_dir_cursor}Codex用{temp_dir_codex}这样它们即使并发执行同一个技能也不会在磁盘上打架。技能里还有一个很隐蔽的坑如果你在指令里写死了“当前分支”或“当前工作目录”换个工具执行时上下文就全错了。统一技能模型里的变量注入器解决的就是这个——所有和环境相关的信息全部声明成变量由适配器在导出时根据目标工具的实际环境填充技能正文里只保留抽象的逻辑不保留具体的路径。这个习惯养成了之后同一套技能在54个工具里跑行为一致性高了很多。多个Agent同时使用同一技能的并发问题其实Skill Manager不是直接处理方它能做的是让技能本身变得“无状态”。把临时状态和中间结果交给外部存储或工具自己的上下文系统技能就只是一份可重入的指令模板不会因为同时被多个Agent加载就出事。这个认识对我后面设计其他Agent框架系统也很有帮助。4.2 把技能仓库纳入Git版本化是最好的后悔药技能这东西和代码一样会持续演进。很多时候我今天觉得一个技能写得很妙过两周一看发现指令啰嗦、变量混乱改完之后又觉得旧版思路也有可取之处。如果技能只是散落在各工具的配置目录里这种迭代根本没法做但纳入Git之后一切都变得可控了。Skills Manager天然支持Git仓库型的技能目录。我可以在每次大规模调整前提交一个commit改崩了就回滚改好了就继续。而且因为适配器生成的是文本文件Git能清晰看出每次同步到底改了什么路径、哪些技能受影响。我的习惯是上午改技能下午切到各工具实际跑一轮晚上统一做一次提交commit message写“refine code-review skill: add dependency check”。一个月下来看日志整个技能演进路线清清楚楚。技能仓库建议使用Git默认的main分支不要太花哨如果你跟我一样喜欢在多个机器之间同步也可以把仓库推到私有远程在另一台电脑上clone下来让Skills Manager直接读取本地路径。只要文件结构一致跨机器迁移就是一条命令的事。4.3 我踩过的坑覆盖、上下文爆炸、路径冲突坑一覆盖面最大的就是“同步覆盖”。早期版本我为了省事同步时采用“存在即覆盖”策略结果有一次把我手写在Cursor规则文件里的一段实验性配置冲掉了。从那以后我改成了哈希比对加差异预览宁可多看两步弹窗也不愿意在无感知的情况下丢内容。坑二上下文爆炸。有些技能写得特别长动辄几千字导出到Claude Code时虽然没有问题但实际运行时每次触发都会把整块内容塞进模型上下文token消耗肉眼可见地涨。解决办法是给技能分模块常用指令保持在800字以内详细背景、代码规范、参考案例全部放到context_files里按需加载。在支持上下文引用的工具里这种拆分能把token消耗降下来一大截。坑三路径冲突。同一套技能仓库被多个工具通过软链接引用之后经常出现工具A把目录清掉重建工具B的软链接因此失效的情况。应对办法是把软链接模式只用在“不会清目录”的工具上其他工具一律走复制模式再配合计划任务定期同步。这个坑我排查了整整一个下午最后才从文件inode对比里发现原因现在写进项目文档里当成经典教学案例。5. 下一步从“管理器”到“技能编排中枢”5.1 技能模板市场把好东西分享出去既然技能格式已经统一了人和人之间共享技能的门槛也就跟着降了下来。我在项目里规划了一个模板市场用户可以把自己的USM技能打包成“技能包”放到公共仓库或私有仓库里其他人拉下来导入到本地就能用。一个技能包就是一个目录里面有skill.yaml、模板文件和依赖说明别人导入时Skills Manager会检查依赖并自动补齐缺失部分。这件事的价值在于很多技能本身具有通用性比如“新项目初始化”“依赖升级评估”“错误日志排查”这些每个开发者都会用到。与其每个人都从零开始写不如让好的技能被复用起来。当然共享技能一定要留意安全问题别随便执行别人技能包里带的脚本至少要先读一遍指令正文再决定要不要导入。5.2 本地开放API让Agent框架直接复用用了一段时间后我发现桌面中枢的价值不止于“给工具写配置文件”。越来越多的Agent框架比如LangChain、CrewAI这类允许开发者以MCP Server或工具函数的形式挂载自定义能力。我干脆在Skills Manager里内置了一个本地HTTP服务把当前技能仓库变成一套只读APIAgent框架可以直接通过API查询技能、获取技能内容和依赖信息不再需要关心技能文件到底存在哪个目录。API服务默认只监听127.0.0.1端口随机分配每次启动都会生成一个访问令牌配合技能作用域做权限控制。这样搞的好处是我的技能体系不再绑定任何特定工具它变成了一组可编程调用的“能力资产”。IDE插件可以用文件同步的方式调用技能自主开发的Agent可以直接走API前后端技能开发者只需要维护USM这一份定义。5.3 一句实在话技能资产化别过度工程化做到这里其实我特别想泼一盆冷水技能管理系统再强大也代替不了你真正去思考“什么技能值得沉淀”。我见过不少人一口气建了上百个技能结果大部分是重复内容最后连自己都找不到该用哪个。我的经验是从手头最高频的3个场景开始比如代码审查、需求拆分、接口排查先把这几个技能打磨到能稳定使用再慢慢扩展。把技能当成代码资产来经营而不是当成收藏品去囤积这才是Skills Manager这类工具真正能帮上忙的地方。最后再分享一个小细节我现在每天收工前都会把当天改过的技能提交一次Gitcommit message里明确写清楚生效了哪些工具。这已经成了我使用AI编程工具链里最值得的一个习惯因为技能这个东西短期看是一段文字长期看就是你的一套方法论。把方法论管好了工具再多也不会乱。