聊到AI编程绕不开一个词Skill。很多人以为AI写代码就是复制粘贴提示词但真拿它做项目时你会发现模型不缺语法知识缺的是“项目经验”。它会给你写出一段能跑的demo却不知道你团队用的是什么架构、哪个版本踩过坑、代码规范里藏着什么禁忌。于是社区里冒出了一种解决方案把某个领域的经验打包成一个Skill直接让AI自带“老师傅视角”。现在GitHub和各家AI编程工具的生态里现成的Skill已经被收录到1500个左右从Vue前端规范到FPGA开发、从数学建模到PLC编程都有。这篇文章我把自己的使用经验整理一遍Skill是什么、去哪里找、怎么安装、怎么排错以及怎么把你自己那点经验也变成一个Skill。1. 先搞懂Skill是什么AI编程“经验不足”问题出在哪1.1 为什么AI写demo行写项目就露怯我见过太多人第一次用AI编程时很兴奋因为AI五分钟就把它要的登录页面、接口调用、数据库连接全写出来了。那种“生产力大爆发”的感觉确实真实。但项目一旦进入第二天麻烦就来了让AI继续加功能它不理解你昨天封装的那几个工具函数让它修bug它不知道这个模块里有两个历史遗留的字段不能动让它按你们团队的代码规范重写它反而把规范忘了个干净。这不是模型变笨了而是上下文里缺少“现场经验”。训练数据给了它海量的通用代码但没有给它你们项目独有的约束。它可以靠提示词临时学但普通人不可能每次写一段几百行、包含所有规范的完整提示词。Skill解决的就是这个矛盾把某一类任务中老师傅才知道的经验预先做成结构化文件需要时让AI加载。它相当于给AI装了一个“领域记忆卡”插上就能用。1.2 Skill的运行原理上下文工程的结构化升级要理解Skill先忘掉“模型会背知识”这个错觉。模型更像一个预测机器你给它什么上下文它就顺着什么方向续写。Skill的本质是把高质量的上下文提前封装好让AI在生成前就“看过”该领域的规则、流程、检查清单和正反示例。目前最流行的Skill规范是一个目录里放一个SKILL.md文件文件开头带YAML格式的元信息比如name和description。AI在加载时会先读description判断当前用户请求是不是它该处理的。如果匹配就读取正文把角色设定、工作流、禁止事项这些内容当成临时约定来执行。有些Skill还会带上scripts/目录里面放着辅助脚本让AI不仅“知道怎么做”还能“真的去执行”。这套机制和微调完全不同。微调要改模型权重成本高、周期长。Skill不碰模型纯粹靠上下文组织所以换模型也能用这就是它这两年被大肆推崇的原因。你可以把它理解为“给AI请了一位站在旁边的老师傅随时把经验说给他听”。1.3 Skill和Agent的区别这个热搜词几乎每天都会出现在社区讨论里。我自己的理解是Skill是“脑中的知识”Agent是“手脚的行动”。Skill告诉你该按什么流程做事、什么是好代码、哪些坑别碰Agent则负责拆解任务、调用工具、一步一步完成目标。对比项SkillAgent本质静态经验包知识流程动态执行体计划工具循环回答“是什么”我是XX领域的资深工程师我会分解任务并调用工具回答“怎么做”按这套流程和规范来我来规划、执行、验证是否改变模型不改变只增强上下文不改变但会自主决策生命周期按需加载用完就完持续运行直到目标完成实践中两者经常组合使用。一个Agent壳配上多个Skill作为“专业大脑”是目前我认为效果最稳定的组合。光有Agent没有Skill它很容易在通用话术里打转光有Skill没有Agent它只能动嘴不能动手。2. 去哪里找现成Skill1500个技能包的来源与选择思路2.1 Skill的主要获取渠道现在你搜索“skill安装”会看到大量信息来源我按质量和使用体验排个序工具的官方文档和内置市场。Claude有官方Skills文档Cursor和Trae在持续完善规则与技能市场Codex团队也在示例仓库里放了几个官方Skill。官方渠道最大的好处是格式规范不会被夹带私货。GitHub的社区聚合库。这就是那“1500个现成Skill”的主要来源。各大awesome列表和skills仓库会把社区提交的SKILL.md收录进索引按领域分类支持一键查看描述和目录结构。我建议先看下载量和更新时间更新活跃的才靠谱。博主、课程、付费社区分享。很多AI编程训练营会把“skill包”当作卖点质量参差不齐。有的确实做得专业有的只是把几段提示词换个文件名我一般不优先用。自己写。我放到第四章细讲其实这是性价比最高的方式因为只有你最清楚自己的项目缺什么。1500这个数字看上去唬人实际真正优质、维护中的Skill可能只有两三成。所以“怎么选”比“怎么找”重要得多。2.2 按场景选Skill别光看热门排行热词里出现了一堆看似不搭界的Skill比如AI编程FPGA、AI agent与PLC编程、Unity技能指示器、PPT skill、倪海厦skill、仓颉skill。这其实说明一件事Skill的价值不在统一标准而在解决具体场景的具体问题。场景分类典型Skill例子适合谁前端与代码规范vue-best-practices、skill编码247前端工程师代码审查与调试code-review、python-best-practices研发团队硬件与工业AI编程FPGA、AI agent与PLC编程嵌入式/自动化从业者科研与数学数学建模skill、论文润色skill学生、研究人员办公与内容PPT skill、AI视频skill、绘图skill产品、运营、设计编译器与语言仓颉skill、Rust skill语言学习者选Skill有个原则先看description写得好不好。一个好的description会准确说明触发场景和它能解决的问题比如“当用户提到Vue组件拆分时触发”。如果description写得模棱两可那这个Skill大概率也是半成品。另外看它有没有示例输出、有没有可追溯的来源。一个连“效果是什么”都不展示的Skill装进去也只会让AI变得更啰嗦。2.3 下载安装的通用流程无论你用什么工具大多数Skill安装都逃不开这几步# 以Claude Code / Codex风格的skills目录为例 mkdir -p ~/.claude/skills cd ~/.claude/skills git clone https://github.com/example/some-skill # 换成你要装的仓库地址克隆完成后检查目录里有没有SKILL.md有的话基本就能被识别。有些Skill带辅助脚本或Python依赖先读一遍README再决定要不要装依赖我见过好多人跳过这步结果Skill加载失败还以为是安装路径错了。装完的验证方式也简单新开一个对话直接提一个该Skill覆盖的任务看AI的输出风格是否发生明显变化。如果AI的回答跟没装之前一模一样那大概率是没识别到或者description的触发机制出了问题。3. 实操在Cursor、Claude Code、Codex、Windsurf里装Skill3.1 CursorRules文件与Skill目录的配合Cursor现在最常用的是Rules机制也就是在项目里放.cursor/rules/*.mdc文件。它的特点是“常驻生效”AI每次对话都会把这些规则考虑进去。所以如果你有一个非常大的Skill不建议直接塞进Rules否则上下文会被内容占掉一大块。我的做法是分层把团队必须执行的硬性规范比如“必须使用TypeScript严格模式”“不允许出现any”放进全局Rules让AI每时每刻都记得把一些大而全的领域经验放进项目级的.mdc文件只有进入相关任务时才让AI主动参考。Cursor也支持类似skills的引用方式你可以在Composer里用 语法直接引用一个文档或技能目录。快捷键呼出后输入关键词就能把对应的Skill内容注入对话。这个方法适合临时加载不会长期占用上下文。说白了Cursor的Skill玩法就是“Rule常驻 引用按需”的组合你要根据任务复杂度决定用哪种。3.2 Claude Code、Codex、Windsurf和OpenCode的配置要点Claude Code对Skill的支持比较原生你把Skill目录放到~/.claude/skills下重启会话就能识别。热词里提到的“deepseek harness用skill”和“阿里harness creator skill”也属于这一类Harness负责解释和调度Skill你可以把Harness理解成Skill的运行容器。Codex这边的机制类似但更偏向AGENTS.md作为项目指令文件。如果你一定要在Codex里用社区Skill可以用第三方安装器或者把SKILL.md的内容手工合并进AGENTS.md。注意Codex对目录结构要求比较严格装完记得检查codex --version对应的配置文件路径。Windsurf和Trae的配置逻辑接近Cursor都支持规则文件和上下文引用路径一般是项目下的.windsurf/rules或.trae/rules。而OpenCode这类新工具已经出现了skill插件机制可以直接装第三方仓库的Skill它们的文档会把安装命令写得很清楚。还有一个必须提的点MCP。热词“api mcpserver”说明很多人已经意识到Skill和MCP的搭配价值。Skill负责“怎么想”MCP Server负责“从哪里拿数据”。比如你让AI做数据库调优Skill里写的是调优思路和注意事项MCP Server则负责连数据库、拉慢查询日志。两者配合起来AI才不只是“嘴上专家”。3.3 “Book to Skill”把一本书或一份规范变成技能包热词里的“book to skill”是我最看好的一条路。你不需要等别人写好Skill你自己手头就有大量现成的经验团队规范文档、框架官方手册、你踩过坑之后写的笔记。把它们变成Skill才是真正解决“AI缺经验”的办法。操作思路也不是把整本书塞进去而是抽三层规则层把文档里“必须做什么、禁止做什么”抽出来写成“如果…则…”的形式。流程层把一项任务的执行顺序固定下来比如先审查依赖、再写单元测试、最后跑静态检查。示例层每类关键规则配三个正例、三个反例让模型的预测有据可依。我试过把一个团队的Vue项目规范书转成Skill过程大概半小时先让大模型把规范文档拆成几十条规则我再删掉过时的、补充项目里特有的坑位最后整理成SKILL.md。实测下来AI审查新代码时的表现明显比裸用强了一个档次因为它终于知道你们团队真正在意的是什么了。4. 手写一个自己的Skill结构、指令分层与调试迭代4.1 SKILL.md的基本结构先看一个最简结构我拿Vue组件审查Skill举例--- name: vue-review-expert description: 使用Vue3组合式API最佳实践审查组件代码关注性能、可维护性与类型安全。当用户请求代码审查或提到Vue组件时触发。 --- # Vue组件审查专家 ## 角色 你是一位有10年经验的前端架构师精通Vue3、TypeScript和组合式API。 ## 审查流程 1. 先梳理组件的props与emits边界判断接口是否清晰。 2. 检查组件拆分粒度超过300行或超过5个独立状态建议拆分。 3. 逐个检查性能敏感点不必要的响应式包裹、大列表缺少虚拟滚动、事件监听未销毁。 4. 检查类型安全是否使用defineProps泛型、是否出现any。 ## 检查清单 - 组件是否有明确的单一职责。 - 是否避免在模板中写复杂表达式。 - 是否使用了computed而非watch处理派生状态。 ## 输出格式 按“问题-location-严重程度-修改建议”的四列格式输出严重程度用P0/P1/P2标注。 ## 禁止事项 - 不要为了减少代码行数而牺牲可读性。 - 不要建议引入未使用的新依赖。这个结构里最重要的是description。它是触发机制的核心相当于AI判断“这单活该不该接”的依据。写得太宽比如“审查Vue代码”会让它在任何相关任务里都被激活反而稀释了专注度写得太窄比如极端强调组件细节会让实际任务被忽略。4.2 怎么写“像老手一样”的指令很多人写Skill时的误区是只用“你是专家”来暗示模型然后就没有然后了。“你是专家”这句话对模型几乎不起作用真正起作用的是你描述的工作方式。对比一下弱指令请审查这段Vue代码指出问题。强指令先拆props与emits边界再查组件拆分粒度最后逐个检查性能敏感点输出按“问题-location-严重程度-修改建议”四列格式。强指令本质上是给模型提供了“搜索方向”。模型是概率预测器你给出的专业关键词越多它就越容易联想到那些老手才熟悉的模式比如“不必要的响应式包裹”“模板中的复杂表达式”“派生状态应该用computed”。这些词并不需要多么神秘但它让模型从“泛泛地找问题”变成“按专家清单找问题”。每一条规则最好对应一个真实的经验来源。如果你写过“watch监听对象导致无限循环”那就把它写进禁止事项。这种从自己踩坑经验里提炼的规则才是Skill最值钱的部分。还有一点禁止事项别写太多十条以内刚刚好再多模型就容易顾此失彼把重点全忘了。4.3 调试与迭代别指望第一版就完美我第一次写Skill时一口气写了200行满以为AI会变成领域大神。结果一测试它既没有完全遵守流程还跟我项目里的其他规则打架。后来我才明白Skill需要迭代跟写代码差不多。我的调试步骤是这样的先找三到五组真实任务去跑看AI输出里哪些约束被忽略了被忽略的规则要么换更明确的关键词重写要么把这条规则挪到检查清单的开头再把实际跑出来的优秀输出当成示例写进正文然后重跑测试集看结果是否符合预期。反复两三轮一个Skill才基本可用。还要注意多个Skill同时存在时的优先级问题。如果两个Skill的description覆盖范围重叠模型可能会选错。解决办法是调窄description或者把它们合并成一个综合Skill。我个人的建议是Skill走“小而专”路线一个Skill只解决一个核心问题便于维护也便于排查问题。4.4 用Harness规范管理Skill的运行热词里反复出现“deepseek harness用skill”“阿里harness creator skill”其实就是在说Harness这个“运行时容器”。Harness不只是执行器它还负责给Skill提供上下文沙箱、决定加载顺序、控制允许模型调用的工具范围。如果你只在本机用Harness的意义还不明显一旦你要把Skill发给团队、部署到服务端Harness就会变成必需品。它让你可以声明这个Skill只能在指定目录下运行、只能读取哪些文件、不能执行哪些命令。这正好解决了我后面要讲的“盲装陌生Skill”的安全问题。所以我的建议是从第一次写自己的Skill时就习惯把Harness配置带上哪怕先只声明一个模型名和目录范围养成习惯后受用无穷。5. 安装和使用Skill的常见坑排查思路与安全建议5.1 装完不生效五步排查法我收到过最多的求助是“明明装了SkillAI怎么没反应”。排查顺序我整理成了表表现常见原因排查方式AI完全没提到Skill目录路径不对或文件名不是SKILL.md确认放在对应工具的skills目录检查文件名是否精确为SKILL.md能看到Skill但输出没变化description写得太宽或太窄重新编写描述限定触发场景同一个任务有两个Skill抢description重叠调窄两个Skill的边界或合并加载报错缺少依赖脚本看README安装README里列出的依赖旧会话不生效会话缓存了旧的上下文新开一个会话再测试Skill一般在会话启动时加载有一个我经常犯的错装完Skill后不新开会话直接在当前对话里测试。模型已经在这个对话里进入了一套思维惯性即使新Skill被加载效果也会被打折扣。测试Skill的最好方式永远是开一个全新的空对话。5.2 不要盲装陌生人的Skill这是我想重点提醒的一块。Skill本质上是提示词而提示词是可以“骗”模型的。一个好心的数据可视化Skill可能要求模型“先执行scripts目录下的bash脚本”如果脚本里藏着危险命令你根本防不住。这不是危言耸听社区里已经出现过夹带恶意行为的Skill案例。我的原则是三道检查打开SKILL.md通读一遍看有没有要求模型执行终端命令、读写敏感路径、或访问外部地址的内容。检查scripts/里每个脚本确保自己能看懂每一行在干什么看不懂就不装。看README是否明确说明了Skill的行为边界。宁可自己花半小时重写一个干净版本也不要盲装一个来路不明的Skill。尤其是那些声称“无所不能”的付费Skill一旦它在你的生产环境里闯了祸损失远大于那点“高效”的甜头。5.3 团队协作把Skill当成代码管最后一个建议很多人没想到Skill应该纳入版本管理。把它看成和代码一样放进公司的Git仓库写清楚README规定目录结构加代码审查。新人入职时clone一份skills目录就等于把团队过去几年的踩坑经验直接带在自己身上了。我在实际团队里看到的成功做法是每个Skill对应一位维护者更新必须附带“为什么改这条规则”的提交信息定期根据框架升级调整。Skill一旦沉淀下来团队写代码的质量下限会被抬得很高AI生成的代码也不再需要人工大改才能合并。我现在的习惯是接到新项目先花十分钟搜一下有没有合适的现成Skill如果没有就跑一次book to skill流程把相关框架文档归拢成私有技能包。说实话我踩过最多次的坑不是Skill装不上而是装了一堆真正用到的不到五个。所以最后送你一句实在话别被“1500个”这个数字唬住挑三个解决你眼下最痛问题的再花一晚上把常用场景写进自己的Skill比收藏一百个list都有用。
AI编程Skill实战指南：从安装到自建，让AI自带老师傅经验
聊到AI编程绕不开一个词Skill。很多人以为AI写代码就是复制粘贴提示词但真拿它做项目时你会发现模型不缺语法知识缺的是“项目经验”。它会给你写出一段能跑的demo却不知道你团队用的是什么架构、哪个版本踩过坑、代码规范里藏着什么禁忌。于是社区里冒出了一种解决方案把某个领域的经验打包成一个Skill直接让AI自带“老师傅视角”。现在GitHub和各家AI编程工具的生态里现成的Skill已经被收录到1500个左右从Vue前端规范到FPGA开发、从数学建模到PLC编程都有。这篇文章我把自己的使用经验整理一遍Skill是什么、去哪里找、怎么安装、怎么排错以及怎么把你自己那点经验也变成一个Skill。1. 先搞懂Skill是什么AI编程“经验不足”问题出在哪1.1 为什么AI写demo行写项目就露怯我见过太多人第一次用AI编程时很兴奋因为AI五分钟就把它要的登录页面、接口调用、数据库连接全写出来了。那种“生产力大爆发”的感觉确实真实。但项目一旦进入第二天麻烦就来了让AI继续加功能它不理解你昨天封装的那几个工具函数让它修bug它不知道这个模块里有两个历史遗留的字段不能动让它按你们团队的代码规范重写它反而把规范忘了个干净。这不是模型变笨了而是上下文里缺少“现场经验”。训练数据给了它海量的通用代码但没有给它你们项目独有的约束。它可以靠提示词临时学但普通人不可能每次写一段几百行、包含所有规范的完整提示词。Skill解决的就是这个矛盾把某一类任务中老师傅才知道的经验预先做成结构化文件需要时让AI加载。它相当于给AI装了一个“领域记忆卡”插上就能用。1.2 Skill的运行原理上下文工程的结构化升级要理解Skill先忘掉“模型会背知识”这个错觉。模型更像一个预测机器你给它什么上下文它就顺着什么方向续写。Skill的本质是把高质量的上下文提前封装好让AI在生成前就“看过”该领域的规则、流程、检查清单和正反示例。目前最流行的Skill规范是一个目录里放一个SKILL.md文件文件开头带YAML格式的元信息比如name和description。AI在加载时会先读description判断当前用户请求是不是它该处理的。如果匹配就读取正文把角色设定、工作流、禁止事项这些内容当成临时约定来执行。有些Skill还会带上scripts/目录里面放着辅助脚本让AI不仅“知道怎么做”还能“真的去执行”。这套机制和微调完全不同。微调要改模型权重成本高、周期长。Skill不碰模型纯粹靠上下文组织所以换模型也能用这就是它这两年被大肆推崇的原因。你可以把它理解为“给AI请了一位站在旁边的老师傅随时把经验说给他听”。1.3 Skill和Agent的区别这个热搜词几乎每天都会出现在社区讨论里。我自己的理解是Skill是“脑中的知识”Agent是“手脚的行动”。Skill告诉你该按什么流程做事、什么是好代码、哪些坑别碰Agent则负责拆解任务、调用工具、一步一步完成目标。对比项SkillAgent本质静态经验包知识流程动态执行体计划工具循环回答“是什么”我是XX领域的资深工程师我会分解任务并调用工具回答“怎么做”按这套流程和规范来我来规划、执行、验证是否改变模型不改变只增强上下文不改变但会自主决策生命周期按需加载用完就完持续运行直到目标完成实践中两者经常组合使用。一个Agent壳配上多个Skill作为“专业大脑”是目前我认为效果最稳定的组合。光有Agent没有Skill它很容易在通用话术里打转光有Skill没有Agent它只能动嘴不能动手。2. 去哪里找现成Skill1500个技能包的来源与选择思路2.1 Skill的主要获取渠道现在你搜索“skill安装”会看到大量信息来源我按质量和使用体验排个序工具的官方文档和内置市场。Claude有官方Skills文档Cursor和Trae在持续完善规则与技能市场Codex团队也在示例仓库里放了几个官方Skill。官方渠道最大的好处是格式规范不会被夹带私货。GitHub的社区聚合库。这就是那“1500个现成Skill”的主要来源。各大awesome列表和skills仓库会把社区提交的SKILL.md收录进索引按领域分类支持一键查看描述和目录结构。我建议先看下载量和更新时间更新活跃的才靠谱。博主、课程、付费社区分享。很多AI编程训练营会把“skill包”当作卖点质量参差不齐。有的确实做得专业有的只是把几段提示词换个文件名我一般不优先用。自己写。我放到第四章细讲其实这是性价比最高的方式因为只有你最清楚自己的项目缺什么。1500这个数字看上去唬人实际真正优质、维护中的Skill可能只有两三成。所以“怎么选”比“怎么找”重要得多。2.2 按场景选Skill别光看热门排行热词里出现了一堆看似不搭界的Skill比如AI编程FPGA、AI agent与PLC编程、Unity技能指示器、PPT skill、倪海厦skill、仓颉skill。这其实说明一件事Skill的价值不在统一标准而在解决具体场景的具体问题。场景分类典型Skill例子适合谁前端与代码规范vue-best-practices、skill编码247前端工程师代码审查与调试code-review、python-best-practices研发团队硬件与工业AI编程FPGA、AI agent与PLC编程嵌入式/自动化从业者科研与数学数学建模skill、论文润色skill学生、研究人员办公与内容PPT skill、AI视频skill、绘图skill产品、运营、设计编译器与语言仓颉skill、Rust skill语言学习者选Skill有个原则先看description写得好不好。一个好的description会准确说明触发场景和它能解决的问题比如“当用户提到Vue组件拆分时触发”。如果description写得模棱两可那这个Skill大概率也是半成品。另外看它有没有示例输出、有没有可追溯的来源。一个连“效果是什么”都不展示的Skill装进去也只会让AI变得更啰嗦。2.3 下载安装的通用流程无论你用什么工具大多数Skill安装都逃不开这几步# 以Claude Code / Codex风格的skills目录为例 mkdir -p ~/.claude/skills cd ~/.claude/skills git clone https://github.com/example/some-skill # 换成你要装的仓库地址克隆完成后检查目录里有没有SKILL.md有的话基本就能被识别。有些Skill带辅助脚本或Python依赖先读一遍README再决定要不要装依赖我见过好多人跳过这步结果Skill加载失败还以为是安装路径错了。装完的验证方式也简单新开一个对话直接提一个该Skill覆盖的任务看AI的输出风格是否发生明显变化。如果AI的回答跟没装之前一模一样那大概率是没识别到或者description的触发机制出了问题。3. 实操在Cursor、Claude Code、Codex、Windsurf里装Skill3.1 CursorRules文件与Skill目录的配合Cursor现在最常用的是Rules机制也就是在项目里放.cursor/rules/*.mdc文件。它的特点是“常驻生效”AI每次对话都会把这些规则考虑进去。所以如果你有一个非常大的Skill不建议直接塞进Rules否则上下文会被内容占掉一大块。我的做法是分层把团队必须执行的硬性规范比如“必须使用TypeScript严格模式”“不允许出现any”放进全局Rules让AI每时每刻都记得把一些大而全的领域经验放进项目级的.mdc文件只有进入相关任务时才让AI主动参考。Cursor也支持类似skills的引用方式你可以在Composer里用 语法直接引用一个文档或技能目录。快捷键呼出后输入关键词就能把对应的Skill内容注入对话。这个方法适合临时加载不会长期占用上下文。说白了Cursor的Skill玩法就是“Rule常驻 引用按需”的组合你要根据任务复杂度决定用哪种。3.2 Claude Code、Codex、Windsurf和OpenCode的配置要点Claude Code对Skill的支持比较原生你把Skill目录放到~/.claude/skills下重启会话就能识别。热词里提到的“deepseek harness用skill”和“阿里harness creator skill”也属于这一类Harness负责解释和调度Skill你可以把Harness理解成Skill的运行容器。Codex这边的机制类似但更偏向AGENTS.md作为项目指令文件。如果你一定要在Codex里用社区Skill可以用第三方安装器或者把SKILL.md的内容手工合并进AGENTS.md。注意Codex对目录结构要求比较严格装完记得检查codex --version对应的配置文件路径。Windsurf和Trae的配置逻辑接近Cursor都支持规则文件和上下文引用路径一般是项目下的.windsurf/rules或.trae/rules。而OpenCode这类新工具已经出现了skill插件机制可以直接装第三方仓库的Skill它们的文档会把安装命令写得很清楚。还有一个必须提的点MCP。热词“api mcpserver”说明很多人已经意识到Skill和MCP的搭配价值。Skill负责“怎么想”MCP Server负责“从哪里拿数据”。比如你让AI做数据库调优Skill里写的是调优思路和注意事项MCP Server则负责连数据库、拉慢查询日志。两者配合起来AI才不只是“嘴上专家”。3.3 “Book to Skill”把一本书或一份规范变成技能包热词里的“book to skill”是我最看好的一条路。你不需要等别人写好Skill你自己手头就有大量现成的经验团队规范文档、框架官方手册、你踩过坑之后写的笔记。把它们变成Skill才是真正解决“AI缺经验”的办法。操作思路也不是把整本书塞进去而是抽三层规则层把文档里“必须做什么、禁止做什么”抽出来写成“如果…则…”的形式。流程层把一项任务的执行顺序固定下来比如先审查依赖、再写单元测试、最后跑静态检查。示例层每类关键规则配三个正例、三个反例让模型的预测有据可依。我试过把一个团队的Vue项目规范书转成Skill过程大概半小时先让大模型把规范文档拆成几十条规则我再删掉过时的、补充项目里特有的坑位最后整理成SKILL.md。实测下来AI审查新代码时的表现明显比裸用强了一个档次因为它终于知道你们团队真正在意的是什么了。4. 手写一个自己的Skill结构、指令分层与调试迭代4.1 SKILL.md的基本结构先看一个最简结构我拿Vue组件审查Skill举例--- name: vue-review-expert description: 使用Vue3组合式API最佳实践审查组件代码关注性能、可维护性与类型安全。当用户请求代码审查或提到Vue组件时触发。 --- # Vue组件审查专家 ## 角色 你是一位有10年经验的前端架构师精通Vue3、TypeScript和组合式API。 ## 审查流程 1. 先梳理组件的props与emits边界判断接口是否清晰。 2. 检查组件拆分粒度超过300行或超过5个独立状态建议拆分。 3. 逐个检查性能敏感点不必要的响应式包裹、大列表缺少虚拟滚动、事件监听未销毁。 4. 检查类型安全是否使用defineProps泛型、是否出现any。 ## 检查清单 - 组件是否有明确的单一职责。 - 是否避免在模板中写复杂表达式。 - 是否使用了computed而非watch处理派生状态。 ## 输出格式 按“问题-location-严重程度-修改建议”的四列格式输出严重程度用P0/P1/P2标注。 ## 禁止事项 - 不要为了减少代码行数而牺牲可读性。 - 不要建议引入未使用的新依赖。这个结构里最重要的是description。它是触发机制的核心相当于AI判断“这单活该不该接”的依据。写得太宽比如“审查Vue代码”会让它在任何相关任务里都被激活反而稀释了专注度写得太窄比如极端强调组件细节会让实际任务被忽略。4.2 怎么写“像老手一样”的指令很多人写Skill时的误区是只用“你是专家”来暗示模型然后就没有然后了。“你是专家”这句话对模型几乎不起作用真正起作用的是你描述的工作方式。对比一下弱指令请审查这段Vue代码指出问题。强指令先拆props与emits边界再查组件拆分粒度最后逐个检查性能敏感点输出按“问题-location-严重程度-修改建议”四列格式。强指令本质上是给模型提供了“搜索方向”。模型是概率预测器你给出的专业关键词越多它就越容易联想到那些老手才熟悉的模式比如“不必要的响应式包裹”“模板中的复杂表达式”“派生状态应该用computed”。这些词并不需要多么神秘但它让模型从“泛泛地找问题”变成“按专家清单找问题”。每一条规则最好对应一个真实的经验来源。如果你写过“watch监听对象导致无限循环”那就把它写进禁止事项。这种从自己踩坑经验里提炼的规则才是Skill最值钱的部分。还有一点禁止事项别写太多十条以内刚刚好再多模型就容易顾此失彼把重点全忘了。4.3 调试与迭代别指望第一版就完美我第一次写Skill时一口气写了200行满以为AI会变成领域大神。结果一测试它既没有完全遵守流程还跟我项目里的其他规则打架。后来我才明白Skill需要迭代跟写代码差不多。我的调试步骤是这样的先找三到五组真实任务去跑看AI输出里哪些约束被忽略了被忽略的规则要么换更明确的关键词重写要么把这条规则挪到检查清单的开头再把实际跑出来的优秀输出当成示例写进正文然后重跑测试集看结果是否符合预期。反复两三轮一个Skill才基本可用。还要注意多个Skill同时存在时的优先级问题。如果两个Skill的description覆盖范围重叠模型可能会选错。解决办法是调窄description或者把它们合并成一个综合Skill。我个人的建议是Skill走“小而专”路线一个Skill只解决一个核心问题便于维护也便于排查问题。4.4 用Harness规范管理Skill的运行热词里反复出现“deepseek harness用skill”“阿里harness creator skill”其实就是在说Harness这个“运行时容器”。Harness不只是执行器它还负责给Skill提供上下文沙箱、决定加载顺序、控制允许模型调用的工具范围。如果你只在本机用Harness的意义还不明显一旦你要把Skill发给团队、部署到服务端Harness就会变成必需品。它让你可以声明这个Skill只能在指定目录下运行、只能读取哪些文件、不能执行哪些命令。这正好解决了我后面要讲的“盲装陌生Skill”的安全问题。所以我的建议是从第一次写自己的Skill时就习惯把Harness配置带上哪怕先只声明一个模型名和目录范围养成习惯后受用无穷。5. 安装和使用Skill的常见坑排查思路与安全建议5.1 装完不生效五步排查法我收到过最多的求助是“明明装了SkillAI怎么没反应”。排查顺序我整理成了表表现常见原因排查方式AI完全没提到Skill目录路径不对或文件名不是SKILL.md确认放在对应工具的skills目录检查文件名是否精确为SKILL.md能看到Skill但输出没变化description写得太宽或太窄重新编写描述限定触发场景同一个任务有两个Skill抢description重叠调窄两个Skill的边界或合并加载报错缺少依赖脚本看README安装README里列出的依赖旧会话不生效会话缓存了旧的上下文新开一个会话再测试Skill一般在会话启动时加载有一个我经常犯的错装完Skill后不新开会话直接在当前对话里测试。模型已经在这个对话里进入了一套思维惯性即使新Skill被加载效果也会被打折扣。测试Skill的最好方式永远是开一个全新的空对话。5.2 不要盲装陌生人的Skill这是我想重点提醒的一块。Skill本质上是提示词而提示词是可以“骗”模型的。一个好心的数据可视化Skill可能要求模型“先执行scripts目录下的bash脚本”如果脚本里藏着危险命令你根本防不住。这不是危言耸听社区里已经出现过夹带恶意行为的Skill案例。我的原则是三道检查打开SKILL.md通读一遍看有没有要求模型执行终端命令、读写敏感路径、或访问外部地址的内容。检查scripts/里每个脚本确保自己能看懂每一行在干什么看不懂就不装。看README是否明确说明了Skill的行为边界。宁可自己花半小时重写一个干净版本也不要盲装一个来路不明的Skill。尤其是那些声称“无所不能”的付费Skill一旦它在你的生产环境里闯了祸损失远大于那点“高效”的甜头。5.3 团队协作把Skill当成代码管最后一个建议很多人没想到Skill应该纳入版本管理。把它看成和代码一样放进公司的Git仓库写清楚README规定目录结构加代码审查。新人入职时clone一份skills目录就等于把团队过去几年的踩坑经验直接带在自己身上了。我在实际团队里看到的成功做法是每个Skill对应一位维护者更新必须附带“为什么改这条规则”的提交信息定期根据框架升级调整。Skill一旦沉淀下来团队写代码的质量下限会被抬得很高AI生成的代码也不再需要人工大改才能合并。我现在的习惯是接到新项目先花十分钟搜一下有没有合适的现成Skill如果没有就跑一次book to skill流程把相关框架文档归拢成私有技能包。说实话我踩过最多次的坑不是Skill装不上而是装了一堆真正用到的不到五个。所以最后送你一句实在话别被“1500个”这个数字唬住挑三个解决你眼下最痛问题的再花一晚上把常用场景写进自己的Skill比收藏一百个list都有用。