刚把电脑里所有AI编程工具挨个数了一遍光标停在列表上愣了五秒Cursor、Claude Code、Codex、Cline、Roo Code、Aider、Continue、Windsurf、Tabby再加上国产的通义灵码、CodeGeeZ、文心快码光是叫得上号的Agent类型工具就有快二十个社区整理的完整清单里更是标到了54。它们都能写代码但“怎么教它们干活”这件事上每个工具都有自己的脾气。Cursor只认.cursor/rulesClaude Code只认CLAUDE.mdCopilot盯着copilot-instructions.mdAider则看CONVENTIONS.md。你在一个工具里辛辛苦苦攒下来的规则换个工具就变成一堆废纸。所以“AI编程”这件事很快就从“会不会写提示词”变成“怎么管理Agent技能”。我做了个跨平台桌面中枢取名 Skills Manager思路特别简单把技能从具体工具里抽出来用一套统一格式维护再通过一个桌面应用分发到54工具的规则系统里。这篇文章把完整的设计思路、技能包格式、分发实现和踩坑过程写出来给同样在多个Agent工具之间来回折腾的朋友做个参考。1. 为什么需要Skills Manager当每个Agent都有了自己的“方言”1.1 从“会写代码”到“会指挥Agent”的转变过去两年AI编程工具完成了一次质变。早期Copilot是“自动补全”你写个函数名它帮你补完下一行现在的Cursor、Claude Code、Codex已经变成“自动干活”——你交代任务它自己读代码、跑测试、改文件、提PR。工具形态变了人的角色也跟着变了我们不再是代码的逐行生产者而是任务的下达者和验收者。这个转变带出一个之前没人认真处理的问题你该怎么“稳定地”让Agent按你的标准干活写一句“帮我写单元测试”谁都会但不同模型、不同工具产出的结果天差地别。有的Agent会问你要测试框架有的闷头生成一堆 pytest 但全都不符合项目风格还有的动手改了一堆不该动的文件。问题的根源不是你提示词写得不够多而是缺少一套结构化的、可复用的“技能层”。社区整理的那54款工具本质上是54种不同的“方言”。它们底层调的模型可能都是GPT或Claude但外层壳子各自定义了规则文件格式、上下文注入方式、工具调用协议。这意味着你积累的“如何让Agent写好代码”的经验被死死绑定在某个具体工具里。今天想让Claude Code干同样的活就得从头再调一遍。1.2 “技能”不是提示词是标准作业程序很多人把“技能包”理解成“长一点的提示词”这个理解会走弯路。提示词是“一句话的指令”而技能是“一套完整的标准作业程序”。打个比方新来的寿司师傅你不能只跟他说“捏得好吃一点”你得给他一本SOP告诉他米饭温度、醋的比例、捏的手法、成品重量标准。技能包对Agent来说就是这本SOP。一份合格的Agent技能包至少要包含五个部分触发条件什么场景下才启用这个技能。关键词、手动触发、还是MCP工具调用。指令内容系统级角色设定和用户级任务说明告诉Agent“你是谁、要干什么、按什么步骤来”。上下文策略该读哪些文件、排除哪些目录、最多吃进多少上下文。这一条最容易被忽略也是决定技能成败的关键。工具与规则允许调用哪些工具读文件、跑命令、搜索代码有哪些硬性边界。输出与验收规范输出格式要长什么样、用什么标准判断结果合格。我在做 Skills Manager 之前试过在 Cursor 里写.cursor/rules在 Claude Code 里写CLAUDE.md在 Aider 里写CONVENTIONS.md内容几乎一样但格式各写一遍。更头疼的是同一份技能在不同模型上表现完全不一样Claude 吃长指令GPT 吃结构化清单DeepSeek 得压到极简。这时候你面对的就不是“写提示词”问题而是一个工程问题技能的内容、格式、分发、适配全都需要统一管理。1.3 统一中枢解决的真实痛点做个技能管理器不是跟风追“Agent技能”这个热词而是被真实场景逼出来的。我的日常工作流是Cursor 写前端业务代码Claude Code 负责重构和代码审查Cline 偶尔接手跑批量任务Copilot 在写测试时挂着。没有中枢之前我维护着一份大约4万字的“团队编码规范”散落在六个工具的配置文件里。每次规范更新我都要手动改一遍.cursor/rules、CLAUDE.md、copilot-instructions.md、.clinerules、CONVENTIONS.md改到第三个文件时基本已经疯掉。另一个痛点是模型适配没法做。同一个“代码审查”技能给 Claude 用可以写600字严格清单给 DeepSeek 用就得压到150字加五条铁律给 Gemini 又要换成长上下文自然语言风格。没有统一的中枢层这个适配工作根本做不起来你只能在每个工具里分别调。而如果在团队里采购或搭建 Agent这就更是个标准流程先选大模型再决定配哪些技能包。选哪个模型、装哪个技能需要一个可对比、可分发、可回滚的管理系统。Skills Manager 解决的就是这三件事一处编写、处处分发一份技能、多模型适配一套技能包、团队可复用。它把“怎么教AI干活”这件事从个人备忘录变成了工程资产。2. 核心设计技能包格式、架构分层与跨平台落地2.1 功能架构采集、标准化、分发、反馈四层Skills Manager 的架构设计可以拆成四层每一层职责单一层与层之间只通过标准化技能包交互这样后续加新工具、新模型时不用推倒重来。第一层是采集层。它负责扫描电脑上已安装的 AI 编程工具读取它们现有的规则文件。比如检测到项目根目录有.cursor/rules就把里面已有规则抽取出来检测到CLAUDE.md也解析进去。采集的目的有两个一是迁移把你过去积累的规则无损导入新系统二是映射搞清楚每个工具当前实际生效的配置有哪些避免分发时互相覆盖。第二层是标准化层。这是整个系统的核心。采集来的杂七杂八规则统一转换成内部技能包格式——我用的是带YAML frontmatter的Markdown文件后面会详细讲。这一层做的核心工作是“翻译”把# 代码审查规范这种自然语言标题解析成结构化的name/description/instructions字段把Cursor里的glob规则转成技能包里的sampling.include/exclude。翻译质量直接决定下游分发效果。第三层是分发层。它把标准化技能包按目标工具的格式渲染出来写到正确的位置。分发层维护了一张“工具-路径-渲染模板”映射表Cursor怎么渲染、Claude Code怎么拼接、Cline怎么拆文件都在这层解决。分发时还有一个重要动作模型适配。目标工具实际调用的模型不同渲染出的指令密度、结构风格就要跟着变。第四层是反馈层。Agent跑完一轮任务后工具会输出结果包括token消耗、是否成功、生成内容是否符合验收规范。反馈层把这些数据关联回对应技能包形成一个“技能包-版本-成功率”的观测面板。有了数据你才知道到底是技能写得烂还是模型理解不了还是上下文不够。没有这一层技能管理就只是“文件复制工具”。2.2 技能包格式一份带了触发条件和验收标准的SOP2025年下半年Anthropic开始推Claude Skills用带frontmatter的SKILL.md描述一套可复用能力思路跟我想要的不谋而合。但问题是那套格式当时只有Claude产品线认其他54工具各有各的规矩。所以 Skills Manager 在内部定义了一套超集格式目的就是兼容 Anthropic Skills 的 YAML frontmatter 风格同时扩展出触发、上下文策略、模型适配、输出验收这些字段。我最常用的一个技能包长这样--- name: code-review description: 对当前改动做严格代码审查找bug、安全风险、可维护性问题 version: 1.2.0 author: your-team tags: [code-review, quality] trigger: types: [manual, keyword] keywords: [审查代码, 帮我看看, code review] context: model_hints: claude: { max_tokens: 4000, temperature: 0.2 } gpt: { max_tokens: 3000, temperature: 0.2 } deepseek: { compact: true, max_tokens: 2000 } sampling: include: [**/*.ts, **/*.tsx] exclude: [**/node_modules/**, **/*.lock] max_input_tokens: 24000 instructions: system: | 你是资深代码审查员。你的原则是 1. 只说真问题不说风格喜好 2. 每个问题都要给严重程度、文件、行号、理由 3. 必须区分bug、安全风险、可维护性问题 4. 不能要求作者做破坏性重构 user: | 请审查以下diff或文件改动按输出格式要求报告。 tools: require: [git diff, grep] allowed: [read_file, run_command, search] output: format: | ## 问题列表 - [严重程度/类别] 文件路径:行号 问题描述 | 修复建议 ## 总结 一段话总结本次改动的主要风险点。 validations: - 每个问题都必须标注严重程度 - 不存在的文件不得出现在问题列表中这个格式看着字段不少但每个字段都有明确用处。trigger是关键设计技能包不是一股脑常驻在Agent上下文里的而是按关键词或手动触发这能省下大量token。context.model_hints是为不同模型预留的适配参数分发层渲染时会根据目标模型读取对应配置。sampling和max_input_tokens一起控制Agent能吃多少料防止它一口吞下整个仓库。output.validations是我个人觉得最有价值的部分。它把“什么算做好”写成了机器可检查的语句。分发时Skills Manager 可以把这些validation直接渲染成Agent指令也可以留到反馈层做自动化校验。比如“每个问题都必须标注严重程度”这条如果Agent交上来的内容不符合反馈层直接标记技能执行失败而不是等人工肉眼判断。2.3 跨平台桌面中枢为什么选了Tauri而不是Electron“跨平台桌面中枢”这个定位意味着它得常驻后台、随时响应、还能在系统托盘和全局快捷键里干活。市面上主流的跨平台桌面方案就两个Electron 和 Tauri我最后选了Tauri。方案内存占用安装包体积生态成熟度系统集成能力适合场景Electron100-300MB80-150MB极高Monaco编辑器等现成组件好需要复杂编辑器界面时Tauri v220-60MB5-15MB中等但核心库齐全优秀Rust生态常驻后台工具、面板型应用纯CLI Web0极小自建为主弱实验阶段、极客向选 Tauri 的理由很实在现在大家跑AI编程工具时Cursor、Claude Code、Docker、本地模型服务哪个不吃几百MB内存再来一个Electron常驻16GB内存的机器直接就红了。Tauri 用系统自带WebView渲染界面Rust写后端常驻内存大概只有Electron的六分之一到五分之一。而且全局快捷键、系统托盘、剪贴板监听这些中枢必需能力Rust生态里都有成熟方案实测下来比Electron的插件还要稳定。Tauri唯一的短板是前端生态。如果要用Monaco编辑器写技能包得自己多花点力气集成。但对 Skills Manager 来说前端就是个表单 列表 预览面板用普通Web组件足够完全不需要把编辑器搬进来。所以对我这种“工具型应用”来说Tauri是最优解Electron更适合做“文档型应用”。2.4 分发机制让54种工具都认你写的技能技能包写好之后分发是重头戏。不同工具接纳技能的方式完全不同我总结了四条路第一种是文件渲染覆盖面最广。Skills Manager 内置一张映射表把标准化技能渲染成每种工具的规则文件写进正确目录:工具规则文件位置渲染要点Cursor.cursor/rules/*.mdc需要YAML frontmatterdescription、globs、alwaysApplyClaude CodeCLAUDE.md/~/.claude/CLAUDE.md纯Markdown可以追加技能段落Cline.clinerules/name.md每个规则一个文件职责清晰Copilot.github/copilot-instructions.md支持自定义路径组织级和仓库级两种AiderCONVENTIONS.md简洁规则Agent每次自动读取CodexAGENTS.md官方推荐的Agent规则规范Windsurf.windsurf/rules/*.md支持分层规则覆盖Continue.continue/config.yaml需要把技能转成 rules 配置段第二种是CLI包装。对不支持规则文件、或者临时跑一次的Agent任务Skills Manager 提供一个skills run 技能名 --args命令它把技能包渲染成一条完整指令拼接在目标CLI的参数后面直接执行。比如claude -p $(skills run code-review --input diff.txt)效果和把规则文件写进CLAUDE.md是一样的而且更干净用完就消失不会污染项目目录。第三种是MCP方式这是最灵活也最“现代”的接入方式。Skills Manager 本身可以启动为一个MCP Server暴露skill_search和skill_call两个工具。支持MCP的AgentClaude Code、Cline、Windsurf都支持在会话中随时可以搜索技能包、调用技能包内容像查API一样不需要提前把技能写进任何配置文件。第四种是剪贴板兜底。总有些场景逃不出规则体系和MCP比如网页版Bolt.new、v0这种云端IDE。Skills Manager 提供一键“复制渲染结果”按钮把技能全文拷到剪贴板你直接粘贴到对话框里就完事。实测下来这种土办法对付网页工具反而最可靠。四条路各有适用场景文件渲染适合“沉淀进项目、团队共享”CLI包装适合“临时任务、不留痕迹”MCP适合“动态检索、低侵入”剪贴板适合“最后的备胎”。我在分发层的设计里让这四者并存按工具能力自动选择确保54种工具里能接的尽量都接上。3. 从零搭建从命令行脚手架到多工具同步3.1 初始化先用Node把核心跑通再套Tauri外壳整个项目我分两步走先做核心命令行工具再做桌面壳。核心CLI用Node TypeScript因为生态成熟处理YAML、文件读写、模板渲染都是老本行桌面壳用Tauri包一层负责可视化编辑和系统托盘。我建议你也按这个顺序来先跑通逻辑再美化界面不然界面改来改去核心逻辑都没验证。初始化命令很简单npm create tauri-applatest skills-manager cd skills-manager # 前端用 vanilla-ts 模板够用 npm install npm run tauri dev项目结构我按功能拆skills-manager/ ├── src-tauri/ # Rust 后端托盘、热键、剪贴板 ├── src/ # 前端界面技能列表、编辑器、分发面板 ├── cli/ # CLI入口skills new / sync / run │ ├── commands/ │ ├── renderers/ # 各工具的渲染模板 │ └── skills/ # 技能包仓库Markdown文件 ├── .skills.config.json # 已注册工具列表 └── package.json实际开发时先别碰Rust把cli/里的skills sync跑通再说。桌面壳的后端只负责三件事读取本地技能目录、调用CLI的同步命令、把结果反馈到界面。系统托盘常驻和全局快捷键比如Cmd/CtrlShiftS呼出中枢面板等CLI稳定了再补。3.2 创建一个能用的技能包git提交信息生成脚手架我先写了个skills new命令生成技能包模板然后往里填。这里给一个我日常最高频使用的技能包——生成符合 Conventional Commits 规范的提交信息。这个技能包短小精悍适合用来测试整套流程。skills new conventional-commit生成模板后我填入以下内容--- name: conventional-commit description: 根据git diff生成符合Conventional Commits规范的提交信息 version: 0.3.0 trigger: types: [manual] keywords: [生成commit, 提交信息] context: max_input_tokens: 8000 instructions: system: | 你是git提交信息助手。你的任务是根据diff生成提交信息。 必须遵守Conventional Commits规范。 user: | 基于以下diff生成5条候选提交信息。 要求type只能是feat/fix/docs/style/refactor/test/chore scope用小写subject以动词开头不超72字符body解释“为什么” 而不是“做了什么”。 output: format: | 1. type(scope): subject body validations: - type必须在允许列表中 - subject不超过72字符 - body必须包含为什么这样改注意trigger里的关键词。我把技能包放在项目里后只要在Claude Code里说“生成commit信息”它就能在会话中触发。但想要真正让每个工具都在合适时机调用它还得靠分发层渲染到正确的地方。3.3 分发渲染器一个命令搞定所有工具分发是整个系统最脏最累的活核心渲染器必须写得足够稳。我用一个render.js脚本演示思路// cli/renderers/index.js import fs from node:fs; import yaml from js-yaml; function renderToCursor(skill) { // Cursor的 .mdc 文件需要 frontmatter 描述和触发条件 return --- description: ${skill.description} globs: ${skill.context?.sampling?.include?.join(,) || **/*} alwaysApply: false --- ${skill.instructions.system} ${skill.instructions.user} ; } function renderToMarkdown(skill) { // Claude Code / CLAUDE.md 追加式渲染 return ## ${skill.name}\n\n${skill.description}\n\n${skill.instructions.system}\n\n${skill.instructions.user}\n; } const content fs.readFileSync(skills/conventional-commit.md, utf8); const skill yaml.load(content); fs.writeFileSync(.cursor/rules/conventional-commit.mdc, renderToCursor(skill)); fs.appendFileSync(CLAUDE.md, renderToMarkdown(skill)); fs.mkdirSync(.clinerules, { recursive: true }); fs.writeFileSync(.clinerules/conventional-commit.md, renderToMarkdown(skill));这段代码看着简单实际踩了不少坑。第一个坑是追加写入CLAUDE.md会越加越长同一个技能多次sync之后会重复。解决办法是给每个技能段加一个唯一的HTML注释标记sync 前先把标记区间里的旧内容清掉再写入新内容。第二个坑是 Cursor 的.mdc文件globs如果写错规则永远不生效。我有一次把**/*.ts写成了**/*.ts多了个空格整个规则直接哑火排查了半小时。渲染器跑通之后skills sync命令会做三件事扫描本地技能目录、按已注册工具列表渲染、写入对应路径。写入前还会生成一份“将变更文件列表”让你确认避免误覆盖。第一次在 Cursor 里触发“生成commit”这个词看到技能真的生效时那种“所有工具终于说一种语言”的感觉挺值的。3.4 模型差异适配同一个技能包的三副面孔分发层最难的不是格式转换而是模型适配。同一个“代码审查”技能在Claude面前可以摆出600字严格清单在DeepSeek面前就得压缩到150字加五条铁律太多反而坏事。这是我在好几次实测里总结出来的模型“脾性”模型家族上下文窗口指令风格偏好适配建议Claude (Opus/Sonnet)200K长指令、XML结构、条件逻辑清晰给完整SOP加step by stepGPT-4o / GPT-4.1128K结构化JSON、少而精的bullet压缩冗余分条列出系统提示强调“严格按步骤”Gemini 2.5 Pro1M自然语言长上下文擅长结合大库可以带长上下文但指令要口语化DeepSeek-V364K极简指令、明确边界只给规则和验收标准去掉解释性废话所以我的技能包格式里专门有context.model_hints字段同一个技能可以挂三个不同密度的指令变体。分发时根据“目标工具实际使用的模型”自动选择变体。比如.mdc文件要同时给 Cursor 的 Composer可能用Claude和 Cursor 的 Chat可能用GPT用就得按模型分别渲染出两个规则文件让 Agent 只读与自己匹配的那份。这也是为什么我强调“中枢”而不是“多写几份配置文件”。写配置文件谁都会但在一套技能包上维护三个模型变体、按工具组合自动渲染才是管理54工具的真正价值。对团队搭建Agent时的“选哪个大模型、配哪些技能包”问题这层适配逻辑能直接给出答案模型影响的是渲染密度技能包决定的是能力边界两者正交分开管理。3.5 团队协作技能包进Git版本说话技能管理器另一个重要场景是团队复用。我自己团队的做法是把技能包目录整体放进一个独立的Git仓库每个技能包是独立的Markdown文件。新增技能走PR评审时大家看的是指令内容、触发条件、验收标准而不是“谁在哪个工具里加了什么规则”。版本管理我用语义化版本号skills publish --tag v1.2.0之后其他成员执行skills pull就能拿到最新版。这里有个很管用的设计技能包版本不需要跟着工具走只跟着技能内容走。比如code-review技能升级到1.3.0只影响用到这个技能的渲染结果其他技能不受牵连。团队里常见的问题——两人对“代码审查标准”理解不一致也因为技能包统一了而彻底消失。4. 常见问题与排查技巧实录4.1 技能不生效八成是路径、Markdown标记或模型问题技能不生效我的排查顺序是先查文件路径和命名再查触发条件最后查模型是否“看见”了规则。症状可能原因排查方法完全没反应规则文件路径不对、被.gitignore排除skills doctor检查文件是否存在确认目标工具读取路径偶尔生效关键词触发没命中或globs没匹配文件临时把技能设为alwaysApply: true测试在A工具生效、B工具不生效B不读当前规则文件查分发表确认B的接入方式技能加载了但表现不听话指令太长被模型截断system和user角色区分不清压缩指令把验收标准移到output.validations我最常踩的坑是Claude Code只认CLAUDE.md而完全忽略.cursor/rules。如果用 Cursor 的规则写法去套 Claude Code技能一定不生效。这也是为什么 Skills Manager 坚持做“针对目标工具渲染”而不是直接复制一份规则文件通用。4.2 技能互相打架优先级和冲突怎么办同时启用多个技能包时冲突很常见。比如code-review技能要求“每个问题标严重程度”但另一个quick-review技能说“简洁为主不标严重程度”。两个都渲染进同一个CLAUDE.mdAgent 就懵了。我的办法是给技能包加priority字段默认 100数值越大越优先分发时按优先级排序写入高优先级技能放在低优先级前面。渲染器里再加一个冲突检测两个技能如果对同一个“输出格式字段”给出了不同约束skills sync会直接警告并让你选“保留高优先级”还是“合并两个约束”。实际处理中我更喜欢“合并约束”——比如上面那个冲突合并后变成“简洁为主但每条仍需标注严重程度”人类看起来更合理。4.3 上下文爆炸技能包太大等于没写新手最容易犯的错是把技能包当成“知识库”几千行全塞进去。我见过同事把一个项目的全部架构文档塞进技能包里结果Agent每次干活光读指令就花掉两万token还因为信息过载严重稀释了核心指令。控制上下文有三个有效手段。第一技能包正文控制在500行以内超过就拆分。第二context.sampling里把max_input_tokens设小一点让Agent只能吃到必要的代码片段而不是整个仓库。第三大段背景知识不要写在instructions里而是单独放一个docs/目录技能只告诉Agent“需要了解支付模块时读 docs/payment.md”。这样知识是“按需读取”而不是“常驻加载”实测上下文消耗能下降60%以上。4.4 模型升级之后技能突然变蠢有一段时间我把“代码审查”技能调到完美所有工具表现都稳。结果某个大模型版本更新后同样指令下Agent开始频繁漏掉严重bug行为明显“漂移”。排查半天发现不是技能写得不对而是新版模型对“只说真问题”这个指令的遵循度变了。这件事逼我把技能包里的output.validations用起来每次发版前我先跑一遍内置的示例用例让Agent用真实diff试跑输出结果进自动校验。不符合直接拦截技能包标记为“失败”不参与分发。这个做法相当于给技能包加了回归测试。模型升级不可控但技能包能不能过用例是把控得住的。我把这个字段推荐给所有用 Skills Manager 的人哪怕只是个人项目也建议写两三条验证规则。5. 关于这套桌面中枢设计我的几点总结这套 Skills Manager 用下来最大的感悟是AI编程工具越是百花齐放“统一”就越有价值。与其在十几个工具里各自维护规则不如把技能抽成独立的资产。我见过的人分成两类一类是Writer——每个工具单独写提示词写了半年最后被更新换代打回原形另一类是“Architect”——把规则当工程管理一次建设长期复用。做这个项目的过程中我越来越确信后者才是正道。最后分享一个小经验每次准备分发一个技能包到新的工具前不要先测这个工具而是先测模型。拿同一份技能、同一个diff分别发给Claude和GPT看它们对技能的遵循差异有多大。知道模型差异之后再去调工具的规则文件问题会简单很多。因为工具只是壳真正理解指令的是模型。先摸透模型脾性再配置工具这套技能管理流程才算真正闭环。如果你也在为十几个Agent工具的规则碎片化头疼建议先小步走挑一个你最高频的技能用skills new建包渲染到两个工具里对比效果。跑通两次之后你自然就明白为什么需要一个跨平台桌面中枢了。