最近一段时间各个技术社群里讨论密度最高的话题已经从“哪个模型更强”变成了“skills”。这个词在Claude Code、Codex、OpenCode这类AI编程工具的用户圈里火得不行前端开发skills、superpower skills、数学建模skills、AI漫剧skills各种玩法都有。如果你现在打开GitHub会发现围绕skills的仓库已经多到需要专门做“awesome list”来整理。一句话解释它是什么skills 就是把“你希望AI按什么流程、什么标准、用什么资源去做一类事”打包成结构化的文件放到AI工具能读取的目录里。装进去之后AI在遇到对应场景时会自动依葫芦画瓢不用你每次重新贴一遍长篇提示词。这篇文章我不想聊空概念直接说实用层面的事——热门的skills库到底哪些值得装、怎么手动把一个GitHub仓库里的skill装进Claude Code、自己怎么写一个靠谱的skill以及装多了之后怎么清理、Claude Code/Codex/OpenCode之间怎么迁移。1. 别把它当插件看Agent Skills到底解决的是什么问题1.1 为什么最近所有AI编程工具都在提skills我以前用一个AI编程助手干项目的时候最烦的一件事是“每次都要把规则重新说一遍”。比如让Claude帮我做代码审查我得先写一大段“你是一个有十年经验的前端架构师请从可维护性、性能、安全性三个角度审查以下代码……”第二天换个会话这段废话又得重来一次。如果团队里还有新人也在用同一个工具他未必知道要加这段规则输出的质量就跟抽奖一样。skills的诞生就是冲着这个痛点去的。它把那段“开场白”固化成一个文件AI启动后会主动读取。你只需要说“帮我看看这段代码”它自己会根据文件里的描述判断“哦这是要我执行代码审查流程”然后按你事先定义好的审查规范去工作。本质上skills是一个可复用的行为包让AI在无人指挥细节的情况下也能自动按照某套标准流程干活。这类需求不是凭空出现的。Claude Code在2025年正式把Agent Skills作为能力推送之后社区跟进特别快。随后Codex、OpenCode这些工具也推出了类似的技能机制。说白了各家都在做同一件事让AI从“会聊天”变成“会按标准作业流程工作”。1.2 一个skill的解剖SKILL.md与它的周边文件随便clone一个社区里的skill仓库你会发现结构并不复杂。核心是一个叫SKILL.md的文件文件名在英语里就是“技能说明书”的意思。这个文件的开头有一段YAML格式的元信息里面最关键的是name和description两个字段。name技能的名字要求简洁、准确。description技能触发的说明描述“什么时候该用这个技能”“它能解决什么问题”。然后正文就是纯Markdown写的操作说明告诉AI具体怎么做。比如一个前端review类的skill正文可能就是先读文件、再按checklist检查、最后输出分级问题报告。除了SKILL.md一个完整的skill通常还有配套文件reference或docs目录存放详细参考资料AI按需读取不会一次性全部塞进上下文。scripts目录存放可以被AI调用的Python、Shell等脚本。templates目录存放输出模板比如论文报告模板、分镜脚本模板。举个例子假设你写了一个“数学建模”skill目录可能是这样math-modeling-skill/ ├── SKILL.md ├── templates/ │ ├── problem_analysis.md │ └── paper_structure.md └── examples/ └── sample_huabei_problem.md这样设计的目的是一个很现实的原因AI的上下文窗口是有限的。如果SKILL.md里塞了整整几万字的规则模型虽然能读但会挤占真正干活时的注意力。正确做法是主文件只写核心流程把细节资料放到外部文件里供AI按需翻阅和人类看说明书是一个思路——先看目录找到相关章节再翻详细页。1.3 skill、提示词、插件三者边界在哪刚接触的人最容易把skills、提示词和插件混为一谈但它们的层级完全不同。提示词prompt一次性输入的一段指令说完就没了下次还得重说。插件plugin真正能执行代码、调用外部系统的东西它能改文件、调API、连数据库。skill技能处于两者之间的层面。它主要是一套“行为规范参考资料”自己不直接执行代码但可以指挥AI去执行代码和调用已有命令/脚本。我用一个生活化类比来解释插件像是工厂里的一台自动焊接机通了电就能干活skills则是一本《焊接标准作业指导书》告诉工人也就是AI步骤是什么、哪个节点要检查、不合格怎么处理。机器和文档都很重要但解决的是不同层面的问题。所以我们在讨论“装skills”时要明确自己到底需要什么。如果只是希望AI在写代码时遵守一套规范流程用skill就够了如果希望AI能自动操作浏览器、读写某个外部服务那你需要的是插件或MCP不是skills。2. 那些刷屏的skills仓库我把热门的都翻了一遍2.1 Superpowers适合想快速建立工作流的入门者GitHub上被讨论最多的skill合集无疑是Superpowers作者是Jesse VincentGitHub账号obra。这套技能包的核心设计哲学很有特点让AI不仅会“解答”还会“管理自己的任务”。里面包含了任务规划、测试驱动开发、调试排查、项目分解、代码审查等一系列技能几乎把一名资深工程师在项目里会做的典型工作流都做了。我实际用下来最有价值的是它的“planning”规划类skill。以前我让Claude改一个老项目的功能它经常上来就动手改代码改到一半发现方案不合理又回滚。装了这个skill之后遇到复杂任务它会先停下来做需求拆解和方案评估确认后再动工。虽然步骤多了但返工率明显降低。Superpowers的安装有两种方式。一是通过marketplace模式安装在当前Claude Code版本里可以直接用claude skill add obra/superpowers-marketplace之类的命令然后按菜单选装哪些子技能。二是我更常用的方式直接把GitHub仓库clone到本地然后从skills/目录里挑自己需要的子目录复制到指定位置。不过要泼一盆冷水千万别整套全装。这套技能包有几十个子技能全装进去后模型每次启动都要扫描一遍它的行为反而会变得“纠结”——经常同时触发了多个相关技能输出的风格会打架。我的经验是挑三到五个跟日常工作最相关的装比如规划、代码审查、TDD就足够了。2.2 Typesafe、Nature风格、Cola等社区源也值得留意Superpowers不是唯一的选择。社区里还有一些更偏向特定工程哲学的仓库。Typesafe ai skills这是Typesafe公司开源的一套skills集合偏生产级工程。它的特点是强调代码质量、架构一致性、可维护性适合用在正规项目而不是一次性玩具脚本上。如果你在GitHub上搜索typesafe/ai-skills或者类似关键词就能找到。这套东西对“代码审查”和“架构决策”类任务的处理非常严谨会逼着AI给出取舍理由而不是直接给答案。Codex生态里的“Nature”风格这个说法在热词里出现了实际是指一种技能设计理念——尽量用自然语言描述期望行为不要过度结构化、不要堆砌Markdown标题和清单。举个例子一份“nature风格”的前端skill里你不会看到大大的## 步骤1、## 步骤2而是像在跟同事交代工作一样说“拿到组件需求后先确认状态管理和副作用边界然后按项目现有风格实现最后补上必要的a11y属性”。这种写法更贴近模型训练时的语料分布有时反而触发更自然。Cola skills名字比较小众属于社区聚合类仓库。这类项目通常是把网络上零散的skill收集起来做了一个合集质量参差不齐。我更推荐把这类合集当“目录”用——在里面找感兴趣的名字然后顺着名字去原仓库看SKILL.md确认内容质量后再决定装不装。还有一类非常实用的资源是“awesome”系列列表。在GitHub上搜awesome-claude-skills或者awesome-agent-skills能找到官方或社区维护的索引页上面按照“编程、写作、数据分析、设计”等分类整理了几百个skill自带描述和仓库地址。这比瞎逛GitHub高效得多。2.3 数学建模、前端、漫剧这类“场景包”值不值得装热词里出现的“数学建模skills”“AI漫剧skills”“前端开发skills”其实代表了skills生态的另一大类——不是通用工程技能而是面向特定场景的“作业流程包”。数学建模类这两年华为杯、国赛里用AI辅助建模已经不算新鲜事了但很多人只是把AI当搜索引擎用让它给个思路就拉倒。建模类skill的价值在于把整个竞赛流程固化下来读题拆解→变量定义→假设说明→模型选择→代码实现→结果检验→论文排版。一个设计良好的建模skill会逼着AI按这个顺序推进而不是直接甩给你一段优化代码就算交差。对于参赛队伍来说它更像是一个“AI助教”随时提醒你流程上还有哪一步没做。前端开发类这类skill通常做得比较细分。有的专注组件生成有的专注样式系统有的专注可访问性。我建议不要装那种大而全的单体skill而是按项目阶段挑选。比如你是在维护一个老React项目就装一个“规范审查型”的如果你是从零搭新项目就装一个“技术选型脚手架”型的。AI漫剧类这类skill算是非程序员用得最多的场景了。它包含分镜脚本生成、角色一致性描述、画面提示词组织、字幕排版等模块。理论上你不用装任何skill靠手写提示词也能让AI做这些事但问题在于你很难每次都想得那么全。漫剧类skill把“分镜该有哪些要素”“角色外貌如何保持跨帧一致”“画面提示词怎么组织才能让出图工具理解”这些经验固化成文件效果稳定得多。总的来说场景包值不值得装取决于你是不是长期做这件事。一次性比赛、一次性活动没必要装如果未来半年你都要跟这个场景打交道装一个并持续把踩坑经验补进去是挺划算的投资。3. 手动安装一个GitHub上的skill完整操作路径3.1 第一步判断这个仓库给你的是什么形态很多人问“Claude Code怎么手动装GitHub上的skills”卡在第一步往往是没搞清仓库里的文件该放哪。所以先花时间看仓库结构因为这决定了你的操作方式。在GitHub上打开任意一个skills仓库先找根目录。一般来说有三种形态单skill仓库根目录下直接有SKILL.md。多skill集合根目录下有skills/子目录里面每个子目录都是一个独立skill。marketplace形态根目录下有marketplace.json或.claude-plugin/目录属于专门提供给客户端批量安装的结构。搞清楚形态之后接下来就是目录选择的问题。3.2 第二步把它放进正确的目录Claude Code读取skills的位置分为项目级和用户级两大类。项目级放在项目的.claude/skills/目录下。比如你的项目叫my-app那就建my-app/.claude/skills/skill-name/SKILL.md。这种方式适合团队共享整个项目的AI行为都被约束在同一套规范下。用户级放在~/.claude/skills/目录下。这样任何项目里都能用属于个人全局配置。适合那些与你个人风格强绑定的技能比如你自己的代码审查标准、写作风格等。手动安装的实际操作可以有几种路径。如果你只是想试水最简单的方式是直接在GitHub仓库页面点“Download ZIP”解压后把里面的skill目录整个复制到.claude/skills/下。这种方式不需要在本地装Git适合只用网页版下载的用户。如果你想长期跟进这个仓库的更新用git clone会更优雅。在终端里执行git clone https://github.com/username/some-skill-repo.git然后手工复制需要的子目录。以Superpowers为例仓库clone下来之后你会看到skills/下面有十几个子目录这时候只需要cd some-skill-repo/skills cp -r code-review ~/.claude/skills/需要注意的一个细节是目录名的规范。skill的目录名最好和SKILL.md里的name字段保持一致用短横线连接的小写字母命名比如code-review、math-modeling。如果目录名是中文或者带空格某些工具加载时可能会出问题。3.3 第三步验证加载、调试描述词装完之后最重要的一步是验证。首先要关闭当前会话并重新打开一个会话因为Claude Code通常在会话启动时扫描skills目录中途塞进去的文件不会被立刻感知。重启后在会话里运行claude skill list如果输出里出现了你新装的那个skill名字说明文件结构和路径没问题。但“能被list”不代表“能被触发”。更实际的验证方式是直接用你在description里设计的场景去测试。比如装的是前端代码审查skill就随便贴一段有问题的代码说“帮我看看这段代码”观察它的行为是否真的按照SKILL.md里定义的流程走。如果发现AI没有触发对应的skill大概率是description写得太笼统模型无法把它和你发的那句话关联起来。这时就要回头改描述。描述里应该包含“用户可能说什么话”“任务属于什么类型”“不该在什么场景使用”这几类信息。改完之后再重启验证直到稳定触发为止。3.4 手动装 vs 市场安装怎么选现在很多编程工具已经支持marketplace技能市场安装命令比手动装省事不少。但我的看法是市场上主流、维护活跃的仓库用市场安装冷门仓库、个人私有需求老老实实手动装。市场安装的好处是能跟着上游版本走更新方便。它的缺点也明显一是要依赖工具的市场解析逻辑遇到非标准结构容易报错二是很多市场会默认把仓库里所有skill登记进去你只想装其中一个但市场命令会“照单全收”。手动安装虽然土但灵活——你可以只复制需要的子目录改名、改描述、增删文件都由你说了算。以我自己的习惯个人项目里用的通用技能比如代码审查、TDD我用市场安装涉及客户特有规范的比如“按某某项目组的编码规范走”百分之百手动装因为这种技能根本不会出现在公开市场里而且需要频繁针对项目情况做微调。4. 自己写一个skill从“想清楚”到“跑起来”4.1 先写SKILL.md还是先写流程我见过不少开发者一上来就建目录开写结果写了半天SKILL.md看起来像一篇说明文AI读了也执行不好。这里第一步不是写文件而是想清楚你要固化的是什么流程。你可以问自己三个问题哪个任务是我每次都要让AI干的频率最高的优先做。这个任务的标准流程是什么尽量拆成3到7个步骤。期望的输出长什么样是一个报告、一段代码还是一组文件举个例子你发现自己每次让Claude写React组件都要反复补充“再写个story”“记得加无障碍属性”“按公司样式规范走”那这就是一个很好的skill候选。把这三条要求提炼成一个固定流程下次只要说“帮我实现一个下拉选择组件”它就会自动补齐那些你认为理所当然的细节。4.2 一份可以直接抄的SKILL.md模板下面这个模板是我自己总结的逻辑上覆盖了元信息、目标、流程、约束、输出和示例六部分。你可以直接套用。--- name: code-review description: 当用户要求审查前端代码或说出“帮我看看代码”“review一下”时使用。适用于React/Vue项目代码检查可维护性、性能、安全性和可访问性。不适合用于回答一般性的语法问题。 --- # 前端代码审查 ## 目标 对用户提供的前端代码进行结构化审查输出分级问题报告。 ## 执行流程 1. 通读代码先总结组件/模块的核心逻辑和状态流转。 2. 按以下顺序检查 - 可维护性命名是否清晰、组件拆分是否合理、是否有明显重复代码。 - 性能不必要的重渲染、大列表未使用虚拟滚动、effect依赖数组缺失。 - 安全性XSS风险点、用户输入未校验、危险API使用。 - 无障碍缺少aria属性、按钮不可键盘操作、颜色对比度不足。 3. 为每个问题标注严重级别P0必须修复、P1应当修复、P2建议改进。 4. 输出格式先给结论摘要再列问题清单最后给出修改示例。 ## 约束 - 不修改用户代码只给出建议。 - 不确定的业务逻辑上下文不可臆断需要在报告中标明“需人工确认”。 ## 示例 见 examples/review_example.md这个模板抓住了写skill的几个关键要素触发条件说清楚、执行流程可操作、输出格式标准化、边界条件明确。其中容易被忽略的是“约束”部分。因为模型没有判断力你如果不告诉它“不确定就不能臆断”它就会在信息不足时强行脑补这在代码审查场景里是很危险的。4.3 触发词设计是成败关键SKILL.md里的description是整个技能是否会被正确调用的命门。写得太宽泛模型会把无关任务也往这个技能上靠写得太窄真实场景又触发不了。我举两个反例和正例对比一下# 反例1太宽泛 description: 用于代码审查。# 反例2太窄 description: 当用户输入请检查我的login.tsx文件的useEffect依赖问题时使用。# 正例覆盖场景、触发短语、边界 description: 当用户说“帮我看看代码”“review这个分支”“检查这段实现”等表达或希望针对React/Vue前端代码进行审查时使用。擅长发现可维护性、性能、安全性和可访问性问题并输出分级报告。不适用于纯语法问答、算法刷题和代码运行报错排查。好的描述本质上是把“人会怎么描述这个需求”转换成“模型能识别的场景语言”。你要站在用户说话习惯的角度去写而不是站在技术名词堆砌的角度。写完描述之后至少要拿十句不同的口语化表达去测试比如“这代码靠谱吗”“这么写有没有坑”“帮我把把关”看能不能触发。4.4 写完后如何测试与迭代skill写完之后它不是一个一次成型的东西而是需要跟着你的实际使用不断迭代的。第一轮测试建议用“旧任务回放”的方式。翻出一段过去你手动写了长篇提示词才做好的任务现在只下一句简单指令看AI能不能自动执行出相近的结果。执行效果差往往不是流程里少写了步骤就是某个表述让模型产生了歧义按差异点去补SKILL.md。第二轮测试是“负面测试”。故意把一些不属于这个skill的任务抛给它比如你写的是代码审查skill却让它“写一个冒泡排序算法”观察它是否错误地启动了review流程。负面测试能有效发现描述过宽的问题。第三轮才是长期监控。在日常使用中留意这样一个信号当AI在某类任务上开始频繁问你要补充信息时意味着这个场景还没有被你的skill覆盖好。这时候回头看流程把容易遗漏的决策默认值写进去。skill的成熟过程实际上就是把你的隐性经验逐步显性化到文件里的过程。5. 场景化改造数学建模、前端开发、AI漫剧的skills长什么样5.1 数学建模华为杯/国赛组合包怎么设计数学建模可能是目前“竞赛型skill”需求最大的领域很多队伍在比赛期间把Claude Code / Codex都用上了但用得好不好差距就在流程控制上。一个实用的建模skill核心是把完整的参赛流程拆成七个阶段而不是让AI“自由发挥”问题分析、变量定义、假设声明、模型选择、代码实现、结果验证、论文撰写。SKILL.md的description可以写成description: 当任务涉及数学建模比赛、数据建模分析、竞赛题目求解时使用。适合处理华为杯、国赛等场景。能够组织完整的建模流程从问题拆解到论文产出。不适用于简单的数学计算题解答。正文流程里可以这样定义拿到题目后先输出一份问题分析卡包含背景、目标、影响因素、数据需求确认后再进入建模阶段要求给出至少两种候选模型并进行对比。这里有个重要的设置——在解题阶段不允许直接跳去写代码必须先让AI给出数学公式或算法描述经用户确认后才动代码。配套资源文件方面可以放一份论文模板到templates/目录里面按国赛论文格式预置了摘要、问题重述、模型假设、符号说明等章节结构。这样AI在最后写论文时能直接套框架不用每次重新解释格式要求。但要非常注意比赛场景的skill是辅助不是外挂。模型给出的模型选择和结果必须人工审查和验证很多赛题的内涵和背景知识是模型接触不到的。把skill当成规范流程的执行工具而不是答案生成器这是底线。5.2 前端开发skill的边界与设计前端领域的skills是数量最多的因为前端任务重复度高、规范差异大特别适合用技能包固化。比较推荐的拆法是把它拆成“组件生成”“样式规范”“代码审查”三个独立技能而不是塞成一个“全能前端”包。以“组件生成”为例name: react-component-generator description: 当需要实现新的React组件、或者把UI原型图描述转换为组件代码时使用。自动按照项目现有技术栈生成带Props类型、Storybook示例和单元测试的完整组件。不适用于修改已有组件的行为逻辑。这里其实就解决了一个以前很烦人的问题。直接说“帮我写个下拉框”AI会默认给你贴一个裸组件没有类型、没有loading状态、没有键盘交互。装了这个skill之后它会自动补齐组件props、aria属性、空态和测试你收到的东西基本可以直接进PR。这背后的逻辑是skill把“项目团队的组件交付标准”写进了执行流程里AI从“能跑的代码”交付升级为“符合团队标准的代码”交付。前端类skill的边界也很重要。它不应该尝试替代构建工具或lint工具比如ESLint能自动检查的规则没必要写进skill里。skill更适合处理的是那些需要判断力的环节组件拆分是否合理、状态存储位置是否恰当、交互方式是否符合用户习惯。这类“软规范”才是用自然语言描述最有价值的部分。5.3 AI漫剧工作流非程序员也能用skillAI漫剧是这两年被短视频带火的内容形态一张张AI生成的画面配上解说和字幕做成连续剧。这类创作者很多不是程序员但同样可以从skills里获益因为AI工具对所有人来说就是对话界面skill只是把对话内容结构化。一个漫剧类skill的目录设计可以是这样manju-production/ ├── SKILL.md ├── templates/ │ ├── character_card.md # 角色设定卡 │ ├── storyboard.md # 分镜表格 │ └── subtitle_style.md # 字幕风格规范 └── examples/ ├── sample_character.md └── sample_storyboard.mdSKILL.md的流程可以定义为五个阶段输入故事梗概→生成角色设定卡包含外貌描述、性格关键词、常用穿搭用于后期跨画幅一致性→拆分为分镜表格镜头编号、画面描述、景别、台词、情绪→为每个镜头写详细的出图提示词注意角色描述重复关键特征词→生成字幕文案和配音脚本。这套流程的核心价值在“角色一致性”。AI出图工具很难保持同一角色在不同画面里长得一样而漫剧skill会把角色关键特征在每一条画面提示词里强制重复一遍这是纯靠手写提示词最容易遗漏的点。对于非程序员用户装这种skill不需要跑命令因为很多工具提供了可视化界面或者直接在对话里就能加载SKILL.md。你只需要把文件放到正确的目录下然后在会话里说“我要做一部漫剧故事大概是这样……”AI就会自动按流程干活。6. skills装多了怎么办清理、管理与多工具迁移经验6.1 为什么会出问题上下文污染与加载过载很多人一开始装skills很兴奋今天装这个明天装那个装到几十个之后突然发现AI的响应变迟钝了、回答变得很“怪”。这不是心理作用而是有实际原因的。首先模型在每次会话开始时都要扫描并理解所有可用skills的描述。当可用技能列表越来越长模型需要把更多注意力放在“判断该用哪个技能”上直接挤占了任务本身的推理空间。就像一个工具箱塞了几百件工具你每次干活光找工具就要花半天。其次多个skill的描述之间会产生冲突。比如你同时装了一个“代码审查”技能和一个“代码重构”技能当用户说“帮我看看这段代码”时模型可能会判断两个都沾边结果输出的内容既有审查报告又有重构建议风格不伦不类。更隐蔽的问题是“触发污染”。某个skill的description写得太宽导致AI在几乎所有对话里都试图套用这个技能。我碰到过最典型的情况是装了一个“任务规划”的skill之后哪怕是问“Python里list和tuple有什么区别”这种小问题它也先给你规划半天任务再回答效率极低。6.2 一套简洁的清理流程参考Tibo等人的方法关于skills清理社区里有不少讨论热词里提到的“tibo关于清理skills的方法”是比较早提出系统清理思路的。它的核心就四个字定期减负。我把这套流程结合实际操作整理成了适合多数人的版本。第一步列清单。在Claude Code会话里运行claude skill list先看看你现在到底装了多少个。如果你从来没有列过大概率会吓一跳实际数量可能比你印象中多不少。第二步做减法。对每一个skill问自己两个问题过去两周用过吗未来一个月明确会用吗两个答案都是否就进入清理流程。清理不是直接删而是先移动到备份目录mkdir -p ~/.claude/skills_backup mv ~/.claude/skills/old-skill ~/.claude/skills_backup/这是从Tibo的分享里学到的关键一步。直接rm虽然快但万一发现某个删掉的skill在下一个项目里又需要了还得重新上网找。备份目录让删除过程可逆成本低了你就敢动手清理了。第三步按照“质量数量”的原则做一次反向安装。清理完一批之后不要急着装新的先体会一下“干净的AI”是什么手感。我自己的体会是保留五到八个高度相关、维护良好的skill体验远好于装了三十个“也许会用”的。另外还有一个小技巧把技能按“使用频率”分为常驻和按需两类。常驻的放在~/.claude/skills/低频的可以放到项目级的.claude/skills/目录只有进入对应项目时才会被激活。这样既不影响日常会话也不至于找不到。6.3 Claude Code / Codex / OpenCode迁移的注意点skills生态目前还在战国时期各家工具都有自己的目录约定和加载规则。热词里同时出现了Claude Code、Codex、OpenCode说明很多人都有一个需求一套skill多处使用。好消息是技能的载体是Markdown文件理论上天然可移植。坏消息是各家的加载目录和触发约定不完全一样。以我目前了解到的情况为例Claude Code主要读.claude/skills/和用户目录下的~/.claude/skills/。Codex的skills生态起步稍晚加载路径和命令词跟Claude Code不完全一致。OpenCode有自己的插件/技能机制目录约定跟.claude也不同。实际迁移时建议按这样的流程操作把skill的核心目录原样复制到目标工具的对应skills目录。打开SKILL.md检查里面有没有写死的工具特定指令。比如一个skill里写了“运行claude --dangerously-skip-permissions打开权限模式”到了另一个工具里这个命令就不存在。要么删掉要么改成通用的“如需执行命令先征得用户同意”。测试触发。不同工具对description的解析有细微差异同一个描述在Claude Code里触发很准在另一个工具里可能毫无反应需要按该工具的实际表现微调表述。注意外部资源路径。skill里引用的脚本、模板如果用了绝对路径或特定环境变量跨工具之后必须改成相对路径。总的来说跨工具迁移是可行的但别指望“零成本复制粘贴”。每个工具都有自己的脾气skill的价值在于流程逻辑和知识沉淀不在于文件本身能到处跑。清理和管理skills这件事我自己的体会是它最大的作用不是让你的工具变快而是让你的AI回到“清晰”的状态。一个模型只有明确知道自己在什么场景下该做什么事才能真正发挥能力。装了一堆互相打架的技能反而会让它陷入选择困难。定期花十几分钟做一次清理比到处找新skill装上要重要得多。