兄弟们最近AI编程圈子里有个词出现频率高得吓人——skills。如果你还在用Claude Code或者Codex跑项目大概率已经遇到过“这个skills怎么装”“那个skills好不好用”的讨论。我自己是从今年年初开始认真玩这东西的从最开始一脸懵到后来能自己写skill、给团队搭了一套代码审查流程中间踩了不少坑也摸出了一些门道。这篇文章我不打算写那种四平八稳的科普就从一个实际用的人的角度把skills到底是什么、为什么2025年突然全都在聊、怎么装怎么用、以及怎么开发自己的skill一次讲透。适合正在用AI编程助手、但对skills概念还比较模糊的人也适合已经装了但不知道怎么深度定制的人。读完你至少能搞清楚这东西和prompt有什么区别为什么说它是Agent能力的“肌肉记忆”以及你自己动手写一个skill需要哪几步。1. skills到底是什么为什么2025年突然火了1.1 从prompts到skills一次能力抽象层的跃迁先说个最直观的场景。以前我用Claude Code干活每次让它分析项目结构都要在对话里贴一遍“请先读取xxx目录下的配置文件然后按照xxx顺序检查依赖关系”这类长指令。麻烦不说换一个项目、换一个模型这套规则又得重新调。后来我意识到真正好用的AI辅助应该是把这类高频、可复用的工作流沉淀成一个个独立的能力模块——这就是skills的核心思路。讲得直白一点prompt是“告诉模型这一次该怎么想”skill是“告诉模型这一类任务该怎么做”。它不是一段对话里的临时指令而是一套有目录结构、有描述文件、有可执行脚本的完整能力包。用健身来类比很贴切prompt像是教练在旁边喊“再来一组”skill则是你自己练出来的肌肉记忆——动作规范、反应快、不需要每次重新学。这个抽象层的价值用的时候才感受得到。我试过在一个大型前端项目里把“规范检查”“单元测试生成”“依赖分析”分别做成skill之后每次开会前的代码走查AI直接按预设流程跑产出的报告结构稳定、维度统一不再像以前那样“这次聊到哪算哪”。这就是我认为agent skills能在2025年集中爆发的原因——大家发现光靠“更长的上下文”和“更好的模型”解决不了流程复用的问题得从工程层面把能力沉淀下来。1.2 skills、prompts和MCP到底有什么不一样这是新手最容易混淆的一组概念。我自己的理解是prompt是对话策略MCP是工具接口skills是工作方法论。三者解决的问题层次完全不同但很多文章把它们混在一起讲导致读者越看越糊涂。先说prompt。它是每次和模型交互时的文本输入解决的问题是“如何引导模型理解当前意图”。优点是灵活缺点是临时——换一个任务、换一个场景这份引导就失效了。再比如MCPModel Context Protocol它解决的是模型和外部系统之间的连通问题比如让Agent能查数据库、调API、读文件系统本质上是把“手”伸出去。但MCP不告诉你“先查什么再查什么”也不负责“判断什么场景该查”。skills恰恰补的是这一层。一个完整的skill往往包含描述文件告诉Agent什么时候该用它、指导文档告诉Agent执行步骤、甚至附带可执行脚本在需要时自动化处理。举个例子我写过一个做前端性能审计的skill它的描述文件里写明“当用户提到页面卡顿、性能分析、Lighthouse评分时触发”指导文档里规定“先检查关键渲染路径→再分析打包体积→最后扫描未优化的图片和请求”脚本部分则自动跑一遍收集数据。这一套下来prompt只负责触发MCP负责拿数据方法论全在skill里。所以选型时的判断标准很清晰如果只是想让某个对话更听话优化prompt够了如果要让Agent能操作外部系统上MCP如果想把一整套专家流程固化下来、让不同模型都能复用那就得好好研究skills。现在GitHub上搜索“coding skills”“claude code skills”这类关键词仓库数量已经多到需要认真筛选热度是实打实的。2. 生态现状哪些平台和仓库值得关注2.1 主流Agent工具的skills实现方式先盘点一下我实际用过、也关注了很久的几个主流工具。OpenAI的codex skills属于起步比较早的它在Codex CLI里直接支持命令加载技能包安装路径清晰社区贡献量也大。Anthropic的claude code skills势头很猛和Claude Code的工作流绑定得深尤其是处理多文件项目时表现稳定。另外还有opencode skills如果你是开源爱好者、喜欢高度定制自己的AI编程环境这家的实现思路值得看。这三个平台的skills机制各有侧重。Codex那边更偏“命令即入口”适合快速调用某个技能Claude Code这边更偏“上下文感知”Agent会自己判断当前任务是否匹配某个skillOpenCode则更极客反正一切都可配置。如果你是刚开始接触我建议别贪多先选一个主用的工具把它的skills机制吃透再横向对比。我在团队内部其实同时跑了Codex和Claude Code两套环境同一个需求类别的skill两个平台上我都装了目的是对比体验。实测下来claude code skills在“复杂指令跟随”上更细腻而codex skills在“工程集成”上更立体各有优势没有绝对的谁取代谁。2.2 高频出现的npx skills add到底是干什么的很多朋友卡在安装这一步看到npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这行命令就蒙了。其实拆开看这条命令的本质是从GitHub仓库拉取一组skills然后通过协议把注册信息写入当前Agent的配置中。npx是执行入口skills是CLI工具名add是子命令后面跟的仓库地址指定了技能包的来源--agent参数告诉工具当前要装给谁用-g代表全局安装即对所有项目生效-y是跳过交互确认全自动执行。这个npx skills工具本身有点像软件包管理器里的npm只不过它管理的是AI的技能包。它为整个skills生态提供了一个公开的安装、分发、注册机制这也是为什么现在推荐一个skill大家会直接甩一条npx skills add命令而不是让你去手动拷贝文件夹。它的好处是显而易见的可追溯版本、可一键升级、可集中管理。尤其当你的机器上同时有Claude Code和Codex时用同一个CLI工具统一管理技能包比手动翻目录高效太多。顺便多说一句安装时如果遇到网络问题别慌。多数情况不是工具的问题而是源地址访问受限。国内用户常见的做法是配置代理或者用镜像源什么“npx skills怎么源码安装”的问题本质上是想在离线环境下手动搞定——后面我专门有章节讲这条路怎么走。3. 实操从零开始装一个skills并用起来3.1 环境准备与前置条件动手之前先自查三件事第一确认你本机的Node.js版本在18以上因为npx skills这个CLI工具依赖较新的运行时第二确认你用的Agent工具Claude Code或Codex版本足够新老版本对skills的原生支持很差第三准备一个干净的测试目录别一上来就在生产项目里折腾。为什么强调这三条因为我在最早踩过一个巨坑项目里装了不少依赖Node版本偏低结果npx skills add跑完看着像是成功了但Agent就是识别不到新加的技能。后来排查半天发现是运行时不兼容skill的注册信息写进去了但加载器解析失败。所以前置环境干净、版本够新能帮你省掉一晚上的排查时间。检查完环境建议先跑一条最简单的命令验证CLI工具本身是否可用npx skills --help如果你能看到命令列表说明工具正常如果报错或者卡住不动优先检查Node版本和网络。3.2 三种安装路径一键、手动与源码编译路径一一键安装最推荐。直接从社区仓库拉取命令格式如下npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这条命令会把整个仓库里的skills复制到本地的全局技能目录并把注册信息写入Claude Code的配置。-g代表全局如果你只想在某个项目里生效去掉它就行。路径二手动拷贝适合网络受限。先找一个网络通畅的机器git clone目标仓库到本地再把仓库里的skills子目录手动复制到你当前Agent的配置目录下。以Claude Code为例技能目录通常位于~/.claude/skills/把整个文件夹丢进去重启会话就能识别。这条路径的弱点是需要自己管理版本更新没有自动升级功能但胜在完全离线可用。路径三源码安装适合二次开发。把项目克隆到本地后先看README确认构建方式多数需要npm install npm run build。构建完成后会生成可发布的技能包目录后续操作和路径二类似但你可以直接修改源码再重新构建适合想自己魔改的同学。我在调试opencode skills时就用的这条路改完立刻跑测试迭代效率很高。3.3 安装后的验证与日常使用姿势装完不是万事大吉一定要验证。我的验证方法是新开一个Agent会话在对话里自然描述一个该skill覆盖的任务观察模型是否会主动加载它。如果模型无动于衷检查两件事一是skill目录的SKILL.md写没写对描述信息这直接决定模型何时触发它二是注册信息有没有真正写入配置文件。日常使用中我习惯把skills分成三类通用型代码风格审查、单元测试生成、项目型针对某个仓库定制的分析流程、个人型自己总结的高频操作。分类管理的意义在于避免一个全局技能库里塞了几十个技能模型每次都要做“技能匹配”响应速度反而变慢。别贪多选精的用。注意如果你发现某个skill在某次会话中没有生效先别急着删。多数情况是因为描述文件里的触发条件写得不够明确模型没能把当前需求与之关联。手动在对话里提一句“请使用xxx技能”往往就能强制唤醒这不算bug是这套机制的固有行为。4. 开发自己的skills从编码审查skill的完整设计讲起4.1 SKILL.md的结构与写法技巧要开发自己的skill最核心的文件就是SKILL.md。它通常包含两部分frontmatterYAML格式的元信息和instructionsMarkdown格式的指导正文。元信息里最关键的是name和description前者标识技能名后者则是给模型看的“触发说明书”。我写前端代码审查skill时description是这么写的Use this skill when the user asks to review frontend code quality, check for common bugs, performance issues, or style violations in JavaScript/TypeScript projects.看到没有里面全是“use when”开头把可能触发它的场景尽可能枚举出来。很多新手把description写得像论文摘要模型根本不知道什么时候该用这个skill就废了一半。目录结构方面一个标准的skills文件夹长这样frontend-review/ ├── SKILL.md ├── scripts/ │ ├── check-deps.js │ └── analyze-bundle.mjs ├── templates/ │ └── review-report-template.md └── reference/ └── style-guides.mdSKILL.md是入口scripts放可执行的自动化脚本templates放输出模板reference放参考资料。这个结构不是强制规定但按照社区公认的方式来组织能确保不同工具的兼容性。4.2 从一次完整的编码审查流程看skill设计逻辑设计一个skill本质是把你脑海里的专家工作流“翻译”给Agent。拿编码审查为例我规定Agents按以下顺序执行收集上下文先读取项目根目录下的package.json、tsconfig.json、AGENTS.md等配置文件理解项目的技术栈和约束条件。扫描改动范围通过git diff获取当前分支与主分支的差异文件只审查有改动的部分避免全量分析浪费时间。分维度执行检查先跑静态检查规则引擎检测再做依赖分析找版本冲突和冗余包最后手工阅读关键文件找逻辑问题。输出结构化报告按模板生成包含问题等级、对应文件行号、修改建议、影响评估四块的报告。这一步设计完成后再考虑哪些部分可以脚本化。我在scripts/里放了一个check-deps.js用来扫依赖树、标记出大体积和重复依赖另一个analyze-bundle.mjs用来模拟打包、输出各模块体积占比。这些脚本全部设计为“无副作用”——只读分析、不修改任何文件避免Agent超权限操作。也许有人觉得这不就是把提示词写得更长了吗当然不是。提示词是一次性的而skill的设计是“可重入”的——同一份指导既可以全程手动对话时触发也可以配合脚本自动执行。更关键的是skill可以被其他项目直接复用和fork这是prompt没有的能力。4.3 命名规范、版本管理与多模型适配给skill起名我的建议是“小且准”。别起code-review这种大而全的名字可以学官方推荐的模式细化成frontend-react-code-review、python-type-check-review这类。名字越具体Agent的匹配准确率越高用户也能一眼看懂它是干什么的。我就干过把一堆技能都归到“analysis”下面的蠢事最后自己都分不清该用哪个。版本管理方面现代skills普遍采用语义化版本号在frontmatter里标注version: 1.2.0。如果改动是向后兼容的优化升minor如果有破坏性变更比如改了触发条件、换了输出格式升major。自己开发的skill建议挂在GitHub上配合npx skills的注册机制团队成员一条命令就能同步最新版本。多模型适配是另一个值得注意的点。同一个skill在Claude Code和Codex上的表现可能天差地别因为不同模型的指令跟随能力、上下文窗口长度、工具调用方式都有差异。我的做法是在主仓库里维护一份SKILL.md另建adapters/目录放不同模型的微调版本。Claude Code那版我会写更多的“推理步骤”因为它的长上下文能力强Codex那版则精简指令优先保证在较短的上下文窗口里也能快速定位核心行为。5. 场景化skills怎么选从通用到专精的匹配策略5.1 前端、安全、数学建模、写作等场景的推荐思路社区里现成的skills数量已经相当可观。如果你做前端开发可以关注frontend-review、ui-ux-analysis这类它们内置了常见的最佳实践规则审查时能自动核对如果打CTF或者做授权的渗透测试penetration-test-recon这类技能包能帮你标准化目录扫描、子域名枚举、漏洞指纹识别等流程但切记只能在授权范围内使用这是底线如果搞数学建模math-modeling-skills这类技能会引导Agent按“问题分析→假设建立→模型选型→求解→敏感性分析”的节奏推进对摘要和论文结构也有规范。还有一批偏内容创作的比如“微信公众号技术文章”相关的技能包它们通常内置了标题分析、受众预设、段落节奏控制等模块对做技术自媒体的人挺友好。我在写这篇稿子之前也试过用这类skill做资料归拢虽然最终文章还是自己写的但整理素材的环节确实省了不少时间。5.2 从通用助手到领域专家的关键一步为什么装了技能之后AI感觉像换了一个人因为skills本质上在做“领域约束”。通用的模型回复是“面面俱到但都不深入”而当它加载了一个专精的skill就相当于戴上了一副“专家眼镜”回复的重心、术语体系、分析框架都被强制收敛到了特定领域。我用一个具体的例子说明。每次跑报表项目时我会让Agent加载> 从prompts到skills：2025年AI编程必备的技能包实战指南
兄弟们最近AI编程圈子里有个词出现频率高得吓人——skills。如果你还在用Claude Code或者Codex跑项目大概率已经遇到过“这个skills怎么装”“那个skills好不好用”的讨论。我自己是从今年年初开始认真玩这东西的从最开始一脸懵到后来能自己写skill、给团队搭了一套代码审查流程中间踩了不少坑也摸出了一些门道。这篇文章我不打算写那种四平八稳的科普就从一个实际用的人的角度把skills到底是什么、为什么2025年突然全都在聊、怎么装怎么用、以及怎么开发自己的skill一次讲透。适合正在用AI编程助手、但对skills概念还比较模糊的人也适合已经装了但不知道怎么深度定制的人。读完你至少能搞清楚这东西和prompt有什么区别为什么说它是Agent能力的“肌肉记忆”以及你自己动手写一个skill需要哪几步。1. skills到底是什么为什么2025年突然火了1.1 从prompts到skills一次能力抽象层的跃迁先说个最直观的场景。以前我用Claude Code干活每次让它分析项目结构都要在对话里贴一遍“请先读取xxx目录下的配置文件然后按照xxx顺序检查依赖关系”这类长指令。麻烦不说换一个项目、换一个模型这套规则又得重新调。后来我意识到真正好用的AI辅助应该是把这类高频、可复用的工作流沉淀成一个个独立的能力模块——这就是skills的核心思路。讲得直白一点prompt是“告诉模型这一次该怎么想”skill是“告诉模型这一类任务该怎么做”。它不是一段对话里的临时指令而是一套有目录结构、有描述文件、有可执行脚本的完整能力包。用健身来类比很贴切prompt像是教练在旁边喊“再来一组”skill则是你自己练出来的肌肉记忆——动作规范、反应快、不需要每次重新学。这个抽象层的价值用的时候才感受得到。我试过在一个大型前端项目里把“规范检查”“单元测试生成”“依赖分析”分别做成skill之后每次开会前的代码走查AI直接按预设流程跑产出的报告结构稳定、维度统一不再像以前那样“这次聊到哪算哪”。这就是我认为agent skills能在2025年集中爆发的原因——大家发现光靠“更长的上下文”和“更好的模型”解决不了流程复用的问题得从工程层面把能力沉淀下来。1.2 skills、prompts和MCP到底有什么不一样这是新手最容易混淆的一组概念。我自己的理解是prompt是对话策略MCP是工具接口skills是工作方法论。三者解决的问题层次完全不同但很多文章把它们混在一起讲导致读者越看越糊涂。先说prompt。它是每次和模型交互时的文本输入解决的问题是“如何引导模型理解当前意图”。优点是灵活缺点是临时——换一个任务、换一个场景这份引导就失效了。再比如MCPModel Context Protocol它解决的是模型和外部系统之间的连通问题比如让Agent能查数据库、调API、读文件系统本质上是把“手”伸出去。但MCP不告诉你“先查什么再查什么”也不负责“判断什么场景该查”。skills恰恰补的是这一层。一个完整的skill往往包含描述文件告诉Agent什么时候该用它、指导文档告诉Agent执行步骤、甚至附带可执行脚本在需要时自动化处理。举个例子我写过一个做前端性能审计的skill它的描述文件里写明“当用户提到页面卡顿、性能分析、Lighthouse评分时触发”指导文档里规定“先检查关键渲染路径→再分析打包体积→最后扫描未优化的图片和请求”脚本部分则自动跑一遍收集数据。这一套下来prompt只负责触发MCP负责拿数据方法论全在skill里。所以选型时的判断标准很清晰如果只是想让某个对话更听话优化prompt够了如果要让Agent能操作外部系统上MCP如果想把一整套专家流程固化下来、让不同模型都能复用那就得好好研究skills。现在GitHub上搜索“coding skills”“claude code skills”这类关键词仓库数量已经多到需要认真筛选热度是实打实的。2. 生态现状哪些平台和仓库值得关注2.1 主流Agent工具的skills实现方式先盘点一下我实际用过、也关注了很久的几个主流工具。OpenAI的codex skills属于起步比较早的它在Codex CLI里直接支持命令加载技能包安装路径清晰社区贡献量也大。Anthropic的claude code skills势头很猛和Claude Code的工作流绑定得深尤其是处理多文件项目时表现稳定。另外还有opencode skills如果你是开源爱好者、喜欢高度定制自己的AI编程环境这家的实现思路值得看。这三个平台的skills机制各有侧重。Codex那边更偏“命令即入口”适合快速调用某个技能Claude Code这边更偏“上下文感知”Agent会自己判断当前任务是否匹配某个skillOpenCode则更极客反正一切都可配置。如果你是刚开始接触我建议别贪多先选一个主用的工具把它的skills机制吃透再横向对比。我在团队内部其实同时跑了Codex和Claude Code两套环境同一个需求类别的skill两个平台上我都装了目的是对比体验。实测下来claude code skills在“复杂指令跟随”上更细腻而codex skills在“工程集成”上更立体各有优势没有绝对的谁取代谁。2.2 高频出现的npx skills add到底是干什么的很多朋友卡在安装这一步看到npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这行命令就蒙了。其实拆开看这条命令的本质是从GitHub仓库拉取一组skills然后通过协议把注册信息写入当前Agent的配置中。npx是执行入口skills是CLI工具名add是子命令后面跟的仓库地址指定了技能包的来源--agent参数告诉工具当前要装给谁用-g代表全局安装即对所有项目生效-y是跳过交互确认全自动执行。这个npx skills工具本身有点像软件包管理器里的npm只不过它管理的是AI的技能包。它为整个skills生态提供了一个公开的安装、分发、注册机制这也是为什么现在推荐一个skill大家会直接甩一条npx skills add命令而不是让你去手动拷贝文件夹。它的好处是显而易见的可追溯版本、可一键升级、可集中管理。尤其当你的机器上同时有Claude Code和Codex时用同一个CLI工具统一管理技能包比手动翻目录高效太多。顺便多说一句安装时如果遇到网络问题别慌。多数情况不是工具的问题而是源地址访问受限。国内用户常见的做法是配置代理或者用镜像源什么“npx skills怎么源码安装”的问题本质上是想在离线环境下手动搞定——后面我专门有章节讲这条路怎么走。3. 实操从零开始装一个skills并用起来3.1 环境准备与前置条件动手之前先自查三件事第一确认你本机的Node.js版本在18以上因为npx skills这个CLI工具依赖较新的运行时第二确认你用的Agent工具Claude Code或Codex版本足够新老版本对skills的原生支持很差第三准备一个干净的测试目录别一上来就在生产项目里折腾。为什么强调这三条因为我在最早踩过一个巨坑项目里装了不少依赖Node版本偏低结果npx skills add跑完看着像是成功了但Agent就是识别不到新加的技能。后来排查半天发现是运行时不兼容skill的注册信息写进去了但加载器解析失败。所以前置环境干净、版本够新能帮你省掉一晚上的排查时间。检查完环境建议先跑一条最简单的命令验证CLI工具本身是否可用npx skills --help如果你能看到命令列表说明工具正常如果报错或者卡住不动优先检查Node版本和网络。3.2 三种安装路径一键、手动与源码编译路径一一键安装最推荐。直接从社区仓库拉取命令格式如下npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这条命令会把整个仓库里的skills复制到本地的全局技能目录并把注册信息写入Claude Code的配置。-g代表全局如果你只想在某个项目里生效去掉它就行。路径二手动拷贝适合网络受限。先找一个网络通畅的机器git clone目标仓库到本地再把仓库里的skills子目录手动复制到你当前Agent的配置目录下。以Claude Code为例技能目录通常位于~/.claude/skills/把整个文件夹丢进去重启会话就能识别。这条路径的弱点是需要自己管理版本更新没有自动升级功能但胜在完全离线可用。路径三源码安装适合二次开发。把项目克隆到本地后先看README确认构建方式多数需要npm install npm run build。构建完成后会生成可发布的技能包目录后续操作和路径二类似但你可以直接修改源码再重新构建适合想自己魔改的同学。我在调试opencode skills时就用的这条路改完立刻跑测试迭代效率很高。3.3 安装后的验证与日常使用姿势装完不是万事大吉一定要验证。我的验证方法是新开一个Agent会话在对话里自然描述一个该skill覆盖的任务观察模型是否会主动加载它。如果模型无动于衷检查两件事一是skill目录的SKILL.md写没写对描述信息这直接决定模型何时触发它二是注册信息有没有真正写入配置文件。日常使用中我习惯把skills分成三类通用型代码风格审查、单元测试生成、项目型针对某个仓库定制的分析流程、个人型自己总结的高频操作。分类管理的意义在于避免一个全局技能库里塞了几十个技能模型每次都要做“技能匹配”响应速度反而变慢。别贪多选精的用。注意如果你发现某个skill在某次会话中没有生效先别急着删。多数情况是因为描述文件里的触发条件写得不够明确模型没能把当前需求与之关联。手动在对话里提一句“请使用xxx技能”往往就能强制唤醒这不算bug是这套机制的固有行为。4. 开发自己的skills从编码审查skill的完整设计讲起4.1 SKILL.md的结构与写法技巧要开发自己的skill最核心的文件就是SKILL.md。它通常包含两部分frontmatterYAML格式的元信息和instructionsMarkdown格式的指导正文。元信息里最关键的是name和description前者标识技能名后者则是给模型看的“触发说明书”。我写前端代码审查skill时description是这么写的Use this skill when the user asks to review frontend code quality, check for common bugs, performance issues, or style violations in JavaScript/TypeScript projects.看到没有里面全是“use when”开头把可能触发它的场景尽可能枚举出来。很多新手把description写得像论文摘要模型根本不知道什么时候该用这个skill就废了一半。目录结构方面一个标准的skills文件夹长这样frontend-review/ ├── SKILL.md ├── scripts/ │ ├── check-deps.js │ └── analyze-bundle.mjs ├── templates/ │ └── review-report-template.md └── reference/ └── style-guides.mdSKILL.md是入口scripts放可执行的自动化脚本templates放输出模板reference放参考资料。这个结构不是强制规定但按照社区公认的方式来组织能确保不同工具的兼容性。4.2 从一次完整的编码审查流程看skill设计逻辑设计一个skill本质是把你脑海里的专家工作流“翻译”给Agent。拿编码审查为例我规定Agents按以下顺序执行收集上下文先读取项目根目录下的package.json、tsconfig.json、AGENTS.md等配置文件理解项目的技术栈和约束条件。扫描改动范围通过git diff获取当前分支与主分支的差异文件只审查有改动的部分避免全量分析浪费时间。分维度执行检查先跑静态检查规则引擎检测再做依赖分析找版本冲突和冗余包最后手工阅读关键文件找逻辑问题。输出结构化报告按模板生成包含问题等级、对应文件行号、修改建议、影响评估四块的报告。这一步设计完成后再考虑哪些部分可以脚本化。我在scripts/里放了一个check-deps.js用来扫依赖树、标记出大体积和重复依赖另一个analyze-bundle.mjs用来模拟打包、输出各模块体积占比。这些脚本全部设计为“无副作用”——只读分析、不修改任何文件避免Agent超权限操作。也许有人觉得这不就是把提示词写得更长了吗当然不是。提示词是一次性的而skill的设计是“可重入”的——同一份指导既可以全程手动对话时触发也可以配合脚本自动执行。更关键的是skill可以被其他项目直接复用和fork这是prompt没有的能力。4.3 命名规范、版本管理与多模型适配给skill起名我的建议是“小且准”。别起code-review这种大而全的名字可以学官方推荐的模式细化成frontend-react-code-review、python-type-check-review这类。名字越具体Agent的匹配准确率越高用户也能一眼看懂它是干什么的。我就干过把一堆技能都归到“analysis”下面的蠢事最后自己都分不清该用哪个。版本管理方面现代skills普遍采用语义化版本号在frontmatter里标注version: 1.2.0。如果改动是向后兼容的优化升minor如果有破坏性变更比如改了触发条件、换了输出格式升major。自己开发的skill建议挂在GitHub上配合npx skills的注册机制团队成员一条命令就能同步最新版本。多模型适配是另一个值得注意的点。同一个skill在Claude Code和Codex上的表现可能天差地别因为不同模型的指令跟随能力、上下文窗口长度、工具调用方式都有差异。我的做法是在主仓库里维护一份SKILL.md另建adapters/目录放不同模型的微调版本。Claude Code那版我会写更多的“推理步骤”因为它的长上下文能力强Codex那版则精简指令优先保证在较短的上下文窗口里也能快速定位核心行为。5. 场景化skills怎么选从通用到专精的匹配策略5.1 前端、安全、数学建模、写作等场景的推荐思路社区里现成的skills数量已经相当可观。如果你做前端开发可以关注frontend-review、ui-ux-analysis这类它们内置了常见的最佳实践规则审查时能自动核对如果打CTF或者做授权的渗透测试penetration-test-recon这类技能包能帮你标准化目录扫描、子域名枚举、漏洞指纹识别等流程但切记只能在授权范围内使用这是底线如果搞数学建模math-modeling-skills这类技能会引导Agent按“问题分析→假设建立→模型选型→求解→敏感性分析”的节奏推进对摘要和论文结构也有规范。还有一批偏内容创作的比如“微信公众号技术文章”相关的技能包它们通常内置了标题分析、受众预设、段落节奏控制等模块对做技术自媒体的人挺友好。我在写这篇稿子之前也试过用这类skill做资料归拢虽然最终文章还是自己写的但整理素材的环节确实省了不少时间。5.2 从通用助手到领域专家的关键一步为什么装了技能之后AI感觉像换了一个人因为skills本质上在做“领域约束”。通用的模型回复是“面面俱到但都不深入”而当它加载了一个专精的skill就相当于戴上了一副“专家眼镜”回复的重心、术语体系、分析框架都被强制收敛到了特定领域。我用一个具体的例子说明。每次跑报表项目时我会让Agent加载>