1. 从“skills”这个标题说起它到底指什么第一次看到“skills”这个标题很多人会以为是某个泛泛而谈的能力清单或者一份简历上的技能罗列。但结合热搜词里反复出现的 Agent Skills、Google Cloud、npx、AI agents、codex skills、claude agent skills 这些词基本可以确定这里说的 skills 不是人类的能力而是给 AI Agent 挂载的“技能包”——一套可安装、可调用、可复用的能力模块。打个比方AI Agent 本身像一台刚装好系统的电脑能开机、能对话、能推理但它不知道你公司的报销流程、不会按你的规范写周报、也不懂你项目里那套特定的代码风格。skills 就是给这台电脑装的一个个“软件”装一个“周报生成 skill”它就按你的模板写装一个“代码审查 skill”它就按你的规则查装一个“分镜脚本 skill”它就按你的格式输出。每个 skill 通常包含一段说明告诉 Agent 什么时候用、怎么用、若干工具定义、以及可选的脚本或资源文件。这件事为什么值得单独拿出来讲因为它是当前 AI Agent 从“能聊天”走向“能干活”的关键一环。模型再强没有领域知识和固定流程的约束输出就是飘的。skills 把“飘”的部分固定下来让 Agent 在特定任务上稳定复现。热搜里“今天学会了skills打开新世界”“skills推荐”“codex好用的skills”这类词反映的就是这种从玩具到工具的转变。这篇文章适合三类人看一是刚接触 Agent Skills、想搞明白它是什么和怎么装的新手二是已经在用 codex、claude 这类工具、想自己写 skill 提效的开发者三是团队里负责把 AI 能力沉淀成标准流程的人。我会从整体设计思路讲到具体实操再到踩坑排查尽量把每一步的“为什么”说清楚让你看完能自己动手做一个能用的 skill。2. 整体设计与思路拆解skills 为什么长这样2.1 核心思路把“提示词”升级成“可安装的能力单元”早期大家用 AI靠的是在对话框里敲一大段提示词比如“你是一个资深前端请按以下规范审查代码……”。这套做法的问题很明显提示词散落在各个聊天窗口里换个人、换个会话就丢了没法版本管理也没法复用。skills 的核心思路就是把这坨提示词结构化、文件化、可安装化。一个 skill 本质上是一个目录里面至少有一个描述文件常见的是 Markdown 格式带元信息头说明这个 skill 叫什么、什么时候触发、需要哪些工具、执行步骤是什么。Agent 在运行时读取这些描述判断当前任务该不该调用它。这就把“人记提示词”变成了“系统加载技能”从一次性消耗变成了可积累的资产。这个设计背后的考量是关注点分离模型负责推理和生成skill 负责领域知识和流程约束。模型升级了skill 不用改业务流程变了只改 skill不用重新训练模型。这种解耦让整套系统更可控也更适合团队协作——一个人写好 skill全组都能装。2.2 方案选型为什么是文件目录而不是插件二进制热搜里出现 npx、npx playwright install 失败、skills安装包下载这些词说明 skills 的分发和安装是绕不开的环节。目前主流的做法是用文件目录 包管理器的方式分发而不是编译成二进制插件。原因有几个。第一skill 的内容主要是自然语言描述加少量脚本本质是文本用文件目录最自然改起来也方便改完直接生效不用重新编译。第二跨平台兼容性好一个目录在 Windows、macOS、Linux 上都能读不依赖特定运行时。第三便于审查文本文件可以直接看内容团队里谁都能 review二进制插件就难说了。第四和现有生态贴合npm、npx 这类工具本来就是管文件和依赖的拿来分发 skill 顺理成章。当然这套方案也有代价依赖管理容易出问题比如 npx playwright install 失败就是典型的环境依赖坑不同工具对 skill 目录结构的约定不完全一致迁移时要做适配。这些后面会专门讲。2.3 适用边界什么任务适合做成 skill不是所有事都值得做成 skill。我的经验是满足以下条件的任务适合高频重复、流程固定、有明确输入输出、需要领域知识。比如代码审查、周报生成、分镜脚本、论文格式检查、自动挖洞安全测试里的漏洞扫描流程这类都是典型场景。反过来一次性的、高度依赖临场判断的、没有固定流程的任务做成 skill 反而累赘。比如“帮我想个创意”这种没有标准流程的事硬套 skill 只会限制模型发挥。判断标准很简单如果这个任务你每次都要跟新人解释一遍怎么做那它就适合做成 skill。3. 核心细节解析与实操要点一个 skill 里到底有什么3.1 描述文件的结构元信息头加正文一个 skill 的描述文件通常分两部分顶部的元信息头frontmatter和下面的正文。元信息头用键值对写明 name、description、以及可选的 tools、version 等字段。正文则是给 Agent 看的操作说明用自然语言写清楚“什么时候用这个 skill”“用的时候按什么步骤”“注意什么”。这里有个关键点description 字段决定了 skill 会不会被触发。Agent 在决定调用哪个 skill 时主要看 description 和当前任务是否匹配。所以 description 要写得既准确又有区分度不能太泛“处理各种任务”这种等于没写也不能太窄稍微变个说法就匹配不上。我的做法是description 里同时包含“做什么”和“什么时候用”比如“审查前端代码当用户提交 React 组件代码并请求审查时使用”。正文部分我习惯按“目标—步骤—输出格式—注意事项”四段来写。目标一句话说清这个 skill 要达成什么步骤用有序列表写清每一步做什么输出格式明确结果长什么样方便下游处理注意事项写清边界和禁忌。这样写下来Agent 执行时不容易跑偏。3.2 工具定义skill 能调用什么skill 光有说明还不够很多时候需要调用外部工具比如读文件、跑命令、查数据库。工具定义就是告诉 Agent“你可以用这些工具每个工具干什么、参数是什么”。这部分通常用结构化的格式写比如 JSON Schema 描述参数。这里要特别注意权限最小化。一个只读代码的 skill就不要给它写文件的权限一个只查数据的 skill就不要给它删数据的权限。我见过有人图省事给 skill 开了全权限结果 Agent 误操作把文件删了。工具定义里把参数类型、必填项、取值范围写清楚能挡掉很多意外。3.3 资源文件脚本和模板怎么放复杂一点的 skill 会带资源文件比如一段 Python 脚本、一个模板文件、一份参考数据。这些文件放在 skill 目录下的子目录里正文里用相对路径引用。这样做的好处是 skill 自包含拷到哪都能用不依赖外部路径。脚本文件要注意两点一是幂等性同一个脚本跑两次结果应该一样避免重复执行出问题二是错误处理脚本里要有基本的异常捕获和日志出错了能看出是哪一步挂的。模板文件则要写清占位符的含义方便 Agent 填充。提示资源文件尽量用纯文本格式.md、.txt、.json、.csv少用二进制格式。纯文本便于版本管理和 diff出问题也好排查。3.4 命名与组织目录结构怎么规划skill 多了之后组织方式就重要了。我一般按“领域/功能”两级来分比如frontend/code-review、writing/weekly-report、security/vuln-scan。每个 skill 一个目录目录名用短横线连接的小写英文和元信息头里的 name 保持一致。这样做的好处是找 skill 的时候按领域一翻就找到装的时候也能按领域批量装。热搜里“skills大全”“skills推荐”这类需求本质上就是想要一个组织良好的 skill 库能按需挑选。目录结构清晰这个库才好维护。4. 实操过程与核心环节实现从零做一个能用的 skill4.1 环境准备先把工具链装好动手之前先把环境弄干净。以常见的 Node 生态为例先确认 Node 和 npm 版本建议 Node 18 以上。然后确认你要挂载 skill 的 Agent 工具已经装好并能正常跑。如果 skill 里要用到浏览器自动化会涉及 playwright这时候 npx playwright install 失败是高频问题后面排查章节会专门讲。环境准备阶段我习惯先跑一个最小验证随便写一个最简单的 skill只包含一个 description 和一句“输出 hello”装上去看能不能被触发。这一步能提前暴露安装路径、权限、加载顺序的问题比写完复杂 skill 再调试省事得多。4.2 写第一个 skill以“代码审查”为例假设我们要做一个前端代码审查 skill。先建目录frontend/code-review然后在里面建SKILL.md。元信息头写--- name: frontend-code-review description: 审查前端代码当用户提交 React 或 Vue 组件代码并请求审查时使用 version: 1.0.0 tools: - read_file - run_lint ---正文部分按四段写。目标对提交的前端代码做规范、性能、可维护性三方面审查输出问题清单和修改建议。步骤第一步读代码第二步跑 lint第三步按检查项逐条核对第四步汇总输出。输出格式用表格列出问题位置、严重程度、问题描述、修改建议。注意事项只审查不修改遇到不确定的规范问题标注出来让人确认。写完这个文件一个最小可用的 skill 就成了。装到 Agent 的 skill 目录下重启或刷新然后用一段有问题的代码测试看它会不会触发、输出是否符合格式。4.3 参数计算与选择以“分镜脚本”skill 为例热搜里有“分镜skills下载”说明这类创作型 skill 有需求。做分镜 skill 时一个关键参数是镜头时长。假设一个 30 秒的短片要分几个镜头这取决于节奏。快节奏的片子平均每个镜头 1.5 到 2 秒30 秒大概 15 到 20 个镜头慢节奏的 3 到 5 秒一个大概 6 到 10 个镜头。这个计算要写进 skill 的正文里让 Agent 根据用户给的时长和节奏自动算镜头数。具体做法是在 skill 里定义节奏档位快/中/慢对应的平均镜头时长然后让 Agent 用总时长除以平均时长得出镜头数再按叙事结构分配每个镜头的内容。这样输出的分镜表数量合理不会出现 30 秒分 50 个镜头这种离谱结果。4.4 安装与加载skill 怎么被 Agent 发现skill 写好后要放到 Agent 能读到的目录里。不同工具约定不同常见的是放在项目根目录下的.skills/或用户主目录下的配置目录里。放好后Agent 启动时会扫描这个目录读取每个 skill 的元信息头建立索引。运行时根据任务匹配 description命中就加载对应 skill 的正文和资源。这里有个实操细节加载顺序和优先级。如果两个 skill 的 description 都能匹配当前任务Agent 怎么选一般按匹配度排序匹配度相同按加载顺序。所以写 description 时要避免和已有 skill 高度重叠否则会出现“该触发的没触发不该触发的乱触发”。我习惯在写完新 skill 后拿几个典型任务测一遍看触发是否符合预期。4.5 调试与迭代怎么知道 skill 生效了调试 skill 最直接的办法是看日志。大多数 Agent 工具会记录“本次任务匹配了哪些 skill、调用了哪些工具、执行了哪些步骤”。如果发现 skill 没被触发先看 description 是不是没匹配上如果触发了但结果不对看正文步骤是不是有歧义如果工具调用报错看工具定义和实际环境是否一致。迭代时我建议小步改一次只改一个地方改完立刻测。比如先改 description 看触发率再改正文看输出质量再改工具定义看调用成功率。一次改太多出问题都不知道是哪处引起的。5. 常见问题与排查技巧实录5.1 npx playwright install 失败怎么办这是热搜里明确出现的问题也是实操中最高频的坑之一。playwright 安装失败通常有几个原因网络问题导致下载中断、系统缺少依赖库、权限不足、磁盘空间不够。排查顺序建议这样先看报错信息里卡在哪一步如果是下载阶段多半是网络如果是解压或安装阶段多半是权限或依赖。针对依赖缺失Linux 上常见的是缺字体库和图形库可以按 playwright 官方文档列出的依赖清单逐个装。权限问题则检查安装目录是否可写必要时换到用户目录下装。磁盘空间用df -h看一眼别装到一半满了。我的经验是先把报错原文完整读一遍八成问题报错里已经写清楚了只是很多人不看。5.2 skill 不触发或乱触发不触发的原因description 写得太窄任务换个说法就匹配不上或者 skill 没放到正确目录Agent 根本没扫到或者元信息头格式写错解析失败被跳过。乱触发的原因description 写得太泛和别的 skill 重叠或者正文里提到了太多不相关的关键词干扰了匹配。解决办法description 里用“做什么 什么时候用”的格式既具体又有区分度写完拿典型任务和边界任务各测几个看触发是否符合预期定期清理不再用的 skill减少干扰。5.3 工具调用报参数错误工具调用报参数错误通常是工具定义和实际调用对不上。比如定义里说参数是字符串Agent 传了个数组或者定义里说必填Agent 没传。排查时先看工具定义的 schema 是否准确再看 Agent 生成的调用参数是否符合 schema。如果 schema 没问题但 Agent 老传错可能是正文里对工具用法的说明不够清楚补一段示例调用能改善。5.4 输出格式不稳定同一个 skill有时输出表格有时输出段落格式飘忽。这多半是正文里输出格式说明不够硬。解决办法是把输出格式写成模板明确每个字段的名称和顺序甚至给一个填充好的示例。Agent 照着模板填格式就稳了。另外输出格式里避免用“可以”“建议”这类软词用“必须”“按以下格式”这类硬词。5.5 常见问题速查表问题现象可能原因排查方向解决思路skill 不触发description 太窄或目录不对看日志是否扫描到该 skill放宽 description确认目录路径skill 乱触发description 太泛或重叠看匹配了哪些 skill收窄 description清理冗余 skill工具调用报错schema 与实际不符对比定义和调用参数修正 schema补用法示例输出格式飘格式说明不够硬看多次输出差异写死模板给填充示例安装依赖失败网络/权限/依赖缺失读完整报错定位阶段按阶段分别处理脚本执行超时逻辑死循环或资源不足看脚本日志加超时和异常捕获注意排查时优先看日志别凭猜。日志里通常有匹配了哪个 skill、调用了哪个工具、哪一步失败顺着日志走比瞎试快得多。5.6 独家避坑经验第一条skill 要小而专。一个 skill 只干一件事别把代码审查和文档生成塞进同一个 skill。小而专的 skill 触发准、维护易、复用高。第二条description 是命门花在 description 上的时间应该比正文还多因为它决定了 skill 能不能被用上。第三条先跑通再优化别一上来就追求完美先做个能触发的粗糙版本跑通了再逐步加细节。第四条版本管理别省skill 也是代码用 git 管起来改坏了能回滚。6. 进阶玩法把 skills 用出复利6.1 skill 组合让多个 skill 协同单个 skill 能力有限但多个 skill 可以组合。比如一个“需求分析 skill”输出结构化需求接着“代码生成 skill”按需求写代码再“代码审查 skill”检查代码最后“测试生成 skill”补测试。这一串下来就是一个自动化的开发流水线。组合的关键是接口对齐前一个 skill 的输出格式要正好是后一个 skill 的输入格式。所以写 skill 时输出格式要按下游能直接用的格式来设计别只顾自己好看。我习惯在 skill 正文里写明“本 skill 的输出可直接作为 XX skill 的输入”方便组合时对齐。6.2 skill 复用跨项目跨团队共享skill 写好后最省事的复用方式是把 skill 目录抽出来做成独立的仓库用包管理器分发。团队里谁需要就装装了就能用。这样一个人踩过的坑、总结的流程全组都能受益不用每个人重新摸索。共享时要注意依赖声明skill 依赖哪些工具、哪些库、哪个版本都要写清楚。别人装的时候照着装避免“在我这能跑在你那报错”。热搜里“skills下载平台有哪些”“skills安装包下载”反映的就是这种共享需求把 skill 打包好、声明清楚依赖是共享的前提。6.3 持续迭代让 skill 越用越好skill 不是写完就完了要在用中迭代。每次用出问题就记下来改 skill。用久了skill 会越来越贴合实际需求。我建议给每个 skill 建一个“问题记录”记下每次触发失败、输出不对、工具报错的情况定期回顾把高频问题固化到 skill 里。另外模型升级后要重新测一遍 skill。新模型可能对 description 的理解变了或者对工具调用的格式要求变了测一遍能提前发现不兼容。这个习惯能避免“模型升级了skill 反而不好用了”的尴尬。6.4 安全与边界skill 能做什么不能做什么最后说个容易被忽略的点skill 的权限边界。skill 能调用工具就意味着它能对系统做操作。一个设计不当的 skill可能误删文件、误发请求、误改数据。所以每个 skill 都要明确“能做什么、不能做什么”工具权限按最小化给危险操作加确认步骤。我的做法是涉及写操作、删除操作、外部请求的 skill正文里必须写明“执行前需用户确认”工具定义里也只给必要的权限。这样即使 Agent 判断失误也有个兜底。skill 是提效工具但前提是安全可控这条底线不能松。我个人在实际操作中的体会是skills 这套东西的价值不在单个 skill 多厉害而在于它把零散的经验沉淀成了可复用的资产。你今天写的一个代码审查 skill明天团队里五个人都在用后天新人入职直接装上就能按规范干活。这种复利效应才是 skills 真正值得投入的地方。 
长河君 · 2026/10/7 21:13:57 · 阅读 1.2k AI Agent Skills 实战指南：从原理到安装与避坑
1. 从“skills”这个标题说起它到底指什么第一次看到“skills”这个标题很多人会以为是某个泛泛而谈的能力清单或者一份简历上的技能罗列。但结合热搜词里反复出现的 Agent Skills、Google Cloud、npx、AI agents、codex skills、claude agent skills 这些词基本可以确定这里说的 skills 不是人类的能力而是给 AI Agent 挂载的“技能包”——一套可安装、可调用、可复用的能力模块。打个比方AI Agent 本身像一台刚装好系统的电脑能开机、能对话、能推理但它不知道你公司的报销流程、不会按你的规范写周报、也不懂你项目里那套特定的代码风格。skills 就是给这台电脑装的一个个“软件”装一个“周报生成 skill”它就按你的模板写装一个“代码审查 skill”它就按你的规则查装一个“分镜脚本 skill”它就按你的格式输出。每个 skill 通常包含一段说明告诉 Agent 什么时候用、怎么用、若干工具定义、以及可选的脚本或资源文件。这件事为什么值得单独拿出来讲因为它是当前 AI Agent 从“能聊天”走向“能干活”的关键一环。模型再强没有领域知识和固定流程的约束输出就是飘的。skills 把“飘”的部分固定下来让 Agent 在特定任务上稳定复现。热搜里“今天学会了skills打开新世界”“skills推荐”“codex好用的skills”这类词反映的就是这种从玩具到工具的转变。这篇文章适合三类人看一是刚接触 Agent Skills、想搞明白它是什么和怎么装的新手二是已经在用 codex、claude 这类工具、想自己写 skill 提效的开发者三是团队里负责把 AI 能力沉淀成标准流程的人。我会从整体设计思路讲到具体实操再到踩坑排查尽量把每一步的“为什么”说清楚让你看完能自己动手做一个能用的 skill。2. 整体设计与思路拆解skills 为什么长这样2.1 核心思路把“提示词”升级成“可安装的能力单元”早期大家用 AI靠的是在对话框里敲一大段提示词比如“你是一个资深前端请按以下规范审查代码……”。这套做法的问题很明显提示词散落在各个聊天窗口里换个人、换个会话就丢了没法版本管理也没法复用。skills 的核心思路就是把这坨提示词结构化、文件化、可安装化。一个 skill 本质上是一个目录里面至少有一个描述文件常见的是 Markdown 格式带元信息头说明这个 skill 叫什么、什么时候触发、需要哪些工具、执行步骤是什么。Agent 在运行时读取这些描述判断当前任务该不该调用它。这就把“人记提示词”变成了“系统加载技能”从一次性消耗变成了可积累的资产。这个设计背后的考量是关注点分离模型负责推理和生成skill 负责领域知识和流程约束。模型升级了skill 不用改业务流程变了只改 skill不用重新训练模型。这种解耦让整套系统更可控也更适合团队协作——一个人写好 skill全组都能装。2.2 方案选型为什么是文件目录而不是插件二进制热搜里出现 npx、npx playwright install 失败、skills安装包下载这些词说明 skills 的分发和安装是绕不开的环节。目前主流的做法是用文件目录 包管理器的方式分发而不是编译成二进制插件。原因有几个。第一skill 的内容主要是自然语言描述加少量脚本本质是文本用文件目录最自然改起来也方便改完直接生效不用重新编译。第二跨平台兼容性好一个目录在 Windows、macOS、Linux 上都能读不依赖特定运行时。第三便于审查文本文件可以直接看内容团队里谁都能 review二进制插件就难说了。第四和现有生态贴合npm、npx 这类工具本来就是管文件和依赖的拿来分发 skill 顺理成章。当然这套方案也有代价依赖管理容易出问题比如 npx playwright install 失败就是典型的环境依赖坑不同工具对 skill 目录结构的约定不完全一致迁移时要做适配。这些后面会专门讲。2.3 适用边界什么任务适合做成 skill不是所有事都值得做成 skill。我的经验是满足以下条件的任务适合高频重复、流程固定、有明确输入输出、需要领域知识。比如代码审查、周报生成、分镜脚本、论文格式检查、自动挖洞安全测试里的漏洞扫描流程这类都是典型场景。反过来一次性的、高度依赖临场判断的、没有固定流程的任务做成 skill 反而累赘。比如“帮我想个创意”这种没有标准流程的事硬套 skill 只会限制模型发挥。判断标准很简单如果这个任务你每次都要跟新人解释一遍怎么做那它就适合做成 skill。3. 核心细节解析与实操要点一个 skill 里到底有什么3.1 描述文件的结构元信息头加正文一个 skill 的描述文件通常分两部分顶部的元信息头frontmatter和下面的正文。元信息头用键值对写明 name、description、以及可选的 tools、version 等字段。正文则是给 Agent 看的操作说明用自然语言写清楚“什么时候用这个 skill”“用的时候按什么步骤”“注意什么”。这里有个关键点description 字段决定了 skill 会不会被触发。Agent 在决定调用哪个 skill 时主要看 description 和当前任务是否匹配。所以 description 要写得既准确又有区分度不能太泛“处理各种任务”这种等于没写也不能太窄稍微变个说法就匹配不上。我的做法是description 里同时包含“做什么”和“什么时候用”比如“审查前端代码当用户提交 React 组件代码并请求审查时使用”。正文部分我习惯按“目标—步骤—输出格式—注意事项”四段来写。目标一句话说清这个 skill 要达成什么步骤用有序列表写清每一步做什么输出格式明确结果长什么样方便下游处理注意事项写清边界和禁忌。这样写下来Agent 执行时不容易跑偏。3.2 工具定义skill 能调用什么skill 光有说明还不够很多时候需要调用外部工具比如读文件、跑命令、查数据库。工具定义就是告诉 Agent“你可以用这些工具每个工具干什么、参数是什么”。这部分通常用结构化的格式写比如 JSON Schema 描述参数。这里要特别注意权限最小化。一个只读代码的 skill就不要给它写文件的权限一个只查数据的 skill就不要给它删数据的权限。我见过有人图省事给 skill 开了全权限结果 Agent 误操作把文件删了。工具定义里把参数类型、必填项、取值范围写清楚能挡掉很多意外。3.3 资源文件脚本和模板怎么放复杂一点的 skill 会带资源文件比如一段 Python 脚本、一个模板文件、一份参考数据。这些文件放在 skill 目录下的子目录里正文里用相对路径引用。这样做的好处是 skill 自包含拷到哪都能用不依赖外部路径。脚本文件要注意两点一是幂等性同一个脚本跑两次结果应该一样避免重复执行出问题二是错误处理脚本里要有基本的异常捕获和日志出错了能看出是哪一步挂的。模板文件则要写清占位符的含义方便 Agent 填充。提示资源文件尽量用纯文本格式.md、.txt、.json、.csv少用二进制格式。纯文本便于版本管理和 diff出问题也好排查。3.4 命名与组织目录结构怎么规划skill 多了之后组织方式就重要了。我一般按“领域/功能”两级来分比如frontend/code-review、writing/weekly-report、security/vuln-scan。每个 skill 一个目录目录名用短横线连接的小写英文和元信息头里的 name 保持一致。这样做的好处是找 skill 的时候按领域一翻就找到装的时候也能按领域批量装。热搜里“skills大全”“skills推荐”这类需求本质上就是想要一个组织良好的 skill 库能按需挑选。目录结构清晰这个库才好维护。4. 实操过程与核心环节实现从零做一个能用的 skill4.1 环境准备先把工具链装好动手之前先把环境弄干净。以常见的 Node 生态为例先确认 Node 和 npm 版本建议 Node 18 以上。然后确认你要挂载 skill 的 Agent 工具已经装好并能正常跑。如果 skill 里要用到浏览器自动化会涉及 playwright这时候 npx playwright install 失败是高频问题后面排查章节会专门讲。环境准备阶段我习惯先跑一个最小验证随便写一个最简单的 skill只包含一个 description 和一句“输出 hello”装上去看能不能被触发。这一步能提前暴露安装路径、权限、加载顺序的问题比写完复杂 skill 再调试省事得多。4.2 写第一个 skill以“代码审查”为例假设我们要做一个前端代码审查 skill。先建目录frontend/code-review然后在里面建SKILL.md。元信息头写--- name: frontend-code-review description: 审查前端代码当用户提交 React 或 Vue 组件代码并请求审查时使用 version: 1.0.0 tools: - read_file - run_lint ---正文部分按四段写。目标对提交的前端代码做规范、性能、可维护性三方面审查输出问题清单和修改建议。步骤第一步读代码第二步跑 lint第三步按检查项逐条核对第四步汇总输出。输出格式用表格列出问题位置、严重程度、问题描述、修改建议。注意事项只审查不修改遇到不确定的规范问题标注出来让人确认。写完这个文件一个最小可用的 skill 就成了。装到 Agent 的 skill 目录下重启或刷新然后用一段有问题的代码测试看它会不会触发、输出是否符合格式。4.3 参数计算与选择以“分镜脚本”skill 为例热搜里有“分镜skills下载”说明这类创作型 skill 有需求。做分镜 skill 时一个关键参数是镜头时长。假设一个 30 秒的短片要分几个镜头这取决于节奏。快节奏的片子平均每个镜头 1.5 到 2 秒30 秒大概 15 到 20 个镜头慢节奏的 3 到 5 秒一个大概 6 到 10 个镜头。这个计算要写进 skill 的正文里让 Agent 根据用户给的时长和节奏自动算镜头数。具体做法是在 skill 里定义节奏档位快/中/慢对应的平均镜头时长然后让 Agent 用总时长除以平均时长得出镜头数再按叙事结构分配每个镜头的内容。这样输出的分镜表数量合理不会出现 30 秒分 50 个镜头这种离谱结果。4.4 安装与加载skill 怎么被 Agent 发现skill 写好后要放到 Agent 能读到的目录里。不同工具约定不同常见的是放在项目根目录下的.skills/或用户主目录下的配置目录里。放好后Agent 启动时会扫描这个目录读取每个 skill 的元信息头建立索引。运行时根据任务匹配 description命中就加载对应 skill 的正文和资源。这里有个实操细节加载顺序和优先级。如果两个 skill 的 description 都能匹配当前任务Agent 怎么选一般按匹配度排序匹配度相同按加载顺序。所以写 description 时要避免和已有 skill 高度重叠否则会出现“该触发的没触发不该触发的乱触发”。我习惯在写完新 skill 后拿几个典型任务测一遍看触发是否符合预期。4.5 调试与迭代怎么知道 skill 生效了调试 skill 最直接的办法是看日志。大多数 Agent 工具会记录“本次任务匹配了哪些 skill、调用了哪些工具、执行了哪些步骤”。如果发现 skill 没被触发先看 description 是不是没匹配上如果触发了但结果不对看正文步骤是不是有歧义如果工具调用报错看工具定义和实际环境是否一致。迭代时我建议小步改一次只改一个地方改完立刻测。比如先改 description 看触发率再改正文看输出质量再改工具定义看调用成功率。一次改太多出问题都不知道是哪处引起的。5. 常见问题与排查技巧实录5.1 npx playwright install 失败怎么办这是热搜里明确出现的问题也是实操中最高频的坑之一。playwright 安装失败通常有几个原因网络问题导致下载中断、系统缺少依赖库、权限不足、磁盘空间不够。排查顺序建议这样先看报错信息里卡在哪一步如果是下载阶段多半是网络如果是解压或安装阶段多半是权限或依赖。针对依赖缺失Linux 上常见的是缺字体库和图形库可以按 playwright 官方文档列出的依赖清单逐个装。权限问题则检查安装目录是否可写必要时换到用户目录下装。磁盘空间用df -h看一眼别装到一半满了。我的经验是先把报错原文完整读一遍八成问题报错里已经写清楚了只是很多人不看。5.2 skill 不触发或乱触发不触发的原因description 写得太窄任务换个说法就匹配不上或者 skill 没放到正确目录Agent 根本没扫到或者元信息头格式写错解析失败被跳过。乱触发的原因description 写得太泛和别的 skill 重叠或者正文里提到了太多不相关的关键词干扰了匹配。解决办法description 里用“做什么 什么时候用”的格式既具体又有区分度写完拿典型任务和边界任务各测几个看触发是否符合预期定期清理不再用的 skill减少干扰。5.3 工具调用报参数错误工具调用报参数错误通常是工具定义和实际调用对不上。比如定义里说参数是字符串Agent 传了个数组或者定义里说必填Agent 没传。排查时先看工具定义的 schema 是否准确再看 Agent 生成的调用参数是否符合 schema。如果 schema 没问题但 Agent 老传错可能是正文里对工具用法的说明不够清楚补一段示例调用能改善。5.4 输出格式不稳定同一个 skill有时输出表格有时输出段落格式飘忽。这多半是正文里输出格式说明不够硬。解决办法是把输出格式写成模板明确每个字段的名称和顺序甚至给一个填充好的示例。Agent 照着模板填格式就稳了。另外输出格式里避免用“可以”“建议”这类软词用“必须”“按以下格式”这类硬词。5.5 常见问题速查表问题现象可能原因排查方向解决思路skill 不触发description 太窄或目录不对看日志是否扫描到该 skill放宽 description确认目录路径skill 乱触发description 太泛或重叠看匹配了哪些 skill收窄 description清理冗余 skill工具调用报错schema 与实际不符对比定义和调用参数修正 schema补用法示例输出格式飘格式说明不够硬看多次输出差异写死模板给填充示例安装依赖失败网络/权限/依赖缺失读完整报错定位阶段按阶段分别处理脚本执行超时逻辑死循环或资源不足看脚本日志加超时和异常捕获注意排查时优先看日志别凭猜。日志里通常有匹配了哪个 skill、调用了哪个工具、哪一步失败顺着日志走比瞎试快得多。5.6 独家避坑经验第一条skill 要小而专。一个 skill 只干一件事别把代码审查和文档生成塞进同一个 skill。小而专的 skill 触发准、维护易、复用高。第二条description 是命门花在 description 上的时间应该比正文还多因为它决定了 skill 能不能被用上。第三条先跑通再优化别一上来就追求完美先做个能触发的粗糙版本跑通了再逐步加细节。第四条版本管理别省skill 也是代码用 git 管起来改坏了能回滚。6. 进阶玩法把 skills 用出复利6.1 skill 组合让多个 skill 协同单个 skill 能力有限但多个 skill 可以组合。比如一个“需求分析 skill”输出结构化需求接着“代码生成 skill”按需求写代码再“代码审查 skill”检查代码最后“测试生成 skill”补测试。这一串下来就是一个自动化的开发流水线。组合的关键是接口对齐前一个 skill 的输出格式要正好是后一个 skill 的输入格式。所以写 skill 时输出格式要按下游能直接用的格式来设计别只顾自己好看。我习惯在 skill 正文里写明“本 skill 的输出可直接作为 XX skill 的输入”方便组合时对齐。6.2 skill 复用跨项目跨团队共享skill 写好后最省事的复用方式是把 skill 目录抽出来做成独立的仓库用包管理器分发。团队里谁需要就装装了就能用。这样一个人踩过的坑、总结的流程全组都能受益不用每个人重新摸索。共享时要注意依赖声明skill 依赖哪些工具、哪些库、哪个版本都要写清楚。别人装的时候照着装避免“在我这能跑在你那报错”。热搜里“skills下载平台有哪些”“skills安装包下载”反映的就是这种共享需求把 skill 打包好、声明清楚依赖是共享的前提。6.3 持续迭代让 skill 越用越好skill 不是写完就完了要在用中迭代。每次用出问题就记下来改 skill。用久了skill 会越来越贴合实际需求。我建议给每个 skill 建一个“问题记录”记下每次触发失败、输出不对、工具报错的情况定期回顾把高频问题固化到 skill 里。另外模型升级后要重新测一遍 skill。新模型可能对 description 的理解变了或者对工具调用的格式要求变了测一遍能提前发现不兼容。这个习惯能避免“模型升级了skill 反而不好用了”的尴尬。6.4 安全与边界skill 能做什么不能做什么最后说个容易被忽略的点skill 的权限边界。skill 能调用工具就意味着它能对系统做操作。一个设计不当的 skill可能误删文件、误发请求、误改数据。所以每个 skill 都要明确“能做什么、不能做什么”工具权限按最小化给危险操作加确认步骤。我的做法是涉及写操作、删除操作、外部请求的 skill正文里必须写明“执行前需用户确认”工具定义里也只给必要的权限。这样即使 Agent 判断失误也有个兜底。skill 是提效工具但前提是安全可控这条底线不能松。我个人在实际操作中的体会是skills 这套东西的价值不在单个 skill 多厉害而在于它把零散的经验沉淀成了可复用的资产。你今天写的一个代码审查 skill明天团队里五个人都在用后天新人入职直接装上就能按规范干活。这种复利效应才是 skills 真正值得投入的地方。