最近 agent 圈子里最热闹的关键词大概就是 skills。你可能已经在各种技术社区刷到过有人晒自己的 skill 包有人整理 skills 下载清单还有人专门做了 agent skill 教程。这个 agent-skills 的玩法其实一点也不玄乎把过去一遍遍复制粘贴到 prompt 里的指令、规则、检查清单连同配套脚本和参考资料打包成一个有统一入口的标准目录结构让 agent 在需要的时候按需读取从而稳定完成某一类任务。说白了这就是给 agent 装技能包。它解决的是一个非常现实的问题模型越来越聪明但每次开新对话你都得把工作流从头教一遍。写周报要重新贴格式要求审代码要重新贴规范清单稍微复杂点的多步骤任务光靠提示词根本锁不住执行质量。skills 把怎么做事整体沉淀下来agent 不再靠临场发挥而是按一套可复用的方法走。如果你正在做 agent 开发、重度使用 Claude 或 Codex 这类带 skills 能力的工具或者只是好奇为什么别人家的 agent 这么能干这篇文章都值得读完。我不会停在概念层会拆开一个真实的 skill 目录从头手搓一个能用的技能包再把触发失败、token 爆炸、跨平台不兼容这些常见坑一个个讲清楚。1. Agent Skills 到底是什么它解决的核心痛点和三个关键概念1.1 提示词工程为什么搞不定复杂任务早期玩 agent大家靠的是提示词工程。你把你是一位资深前端架构师请按以下规则审查代码...写在系统提示词或者每次对话开头然后期待模型老老实实执行。这套思路在 demo 阶段很好使一旦进入真实工作流问题就全暴露出来了。第一个问题是不可复用。同一套审查规则今天用、明天用、换个项目还要用但每次都要复制粘贴。粘贴次数多了总会漏掉某一条——你忘了写不要编造数据这周的报告里就出现了编造的数据。第二个问题是上下文窗口。规则写得越细占用的 token 越多留给真正要处理的业务内容的空间就越小。你可以把规则写得极简但极简的规则又约束不住模型的自由发挥。第三个问题是执行质量不稳定。提示词本质上是一个建议模型读了之后可以照做也可以发挥没有任何机制强制它按步骤走。我自己最直观的体感来自写周报。以前每个周一我都要在对话框里重新描述一遍周报要分几个板块、每个板块要哪些数据、语气要克制、不要编造指标。说真的这种重复性劳动做个三次就会烦。skills 的思路是干脆把生成周报整件事封装成一个带步骤、带模板、带脚本的技能包。agent 不需要理解我的周报习惯它只需要在检测到相关请求时按技能包里的流程走完即可。1.2 Skills、Tools、MCP 的关键区别很多新手一来就问skills 和函数调用、MCP 有什么区别这三个概念确实容易被混淆但它们的定位根本不在一个层级。维度Tool / Function CallingMCPSkill核心单元单个函数标准化工具协议完整工作流 知识包解决什么问题让 agent 调用外部能力让不同应用共享同一套工具生态让 agent 稳定完成多步骤任务状态管理无状态一次调用无状态面向工具发现有步骤编排可引用外部资源是否必须写代码必须必须不一定核心以 Markdown 为主类比一把螺丝刀一种标准接口规格一套完整的维修手册工具调用解决的是这件事 agent 自己干不了得调个函数MCP 解决的是工具多了得有个统一协议不然每个应用都各写一套接口而 skill 解决的是一件复杂事情该按什么流程、用什么方法一步步做完。它们不冲突实践中常常叠加使用skill 的执行步骤里完全可以调用一个 MCP 工具或者调用一个函数。举一个真实例子。我想让 agent 帮我审查前端代码我可以给它一个检查 console.log 残留的工具函数那是 Tool我可以把公司内部的代码规范通过 MCP 暴露给它那是 MCP但真正能让它像一位有经验的前端负责人那样先看改动范围、再按清单逐项检查、最后给出结构化审查报告的是一个 skill。工具负责能调用什么skill 负责该怎么做。1.3 为什么这个概念现在突然火了说实话skills 这种把方法论打包成目录的想法并不是最近才出现的。过去有各种 prompt 模板库、工作流模板本质上都是想解决同样的问题。但为什么偏偏是现在skills 成了 agent 圈子的中心话题我觉得有三个原因叠在一起。第一agent 从 demo 阶段进入生产阶段了。过去大家展示的是你看它自己会写代码现在大家关心的是它能不能稳定地帮我完成每周的代码审查。一旦要稳定就需要把工作流固化下来skills 就是固化的最小单元。第二模型上下文虽然在不断变长但上下文大不等于知道每一步怎么走。长上下文解决的是能装下更多资料但解决不了流程控制。skills 用外部文件的形式把流程从上下文里解放了出来。第三头部厂商开始推统一规范。Claude 有 agent skills 的官方实践Codex 也有 skills 仓库还有一批第三方 agent 工作台把 skills 作为核心能力内置。标准一旦成形社区就像滚雪球一样越来越多的人开始写、开始分享 skills生态就起来了。现在你再看到agent-skills这个标题脑子里应该是一条清晰的链路它不是某个神秘框架而是一套用目录结构和 Markdown 定义 agent 能力的方法论。2. 拆解一个 Skill 的标准结构从 SKILL.md 到配套脚本2.1 最小目录结构长什么样一个 skill 的目录结构并不复杂。以社区里最常见也最通用的形态为例它长这样my-first-skill/ ├── SKILL.md ├── scripts/ │ └── check_frontend.py └── references/ └── coding_standards.mdSKILL.md 是整个技能包的入口相当于主脑。agent 会先读这个文件判断自己该不该使用这个技能、以及怎么使用。scripts 目录放的是配套的可执行脚本用来做一些 Markdown 说不清楚的、需要确定性逻辑的事情比如正则扫描代码、跑测试、处理文件。references 目录放的是参考资料比如团队编码规范、设计规范、行业标准这类不一定每次都用但需要时必须有的知识文件。有些 skill 还会带一个 assets 目录放模板文件、示例输出等。但核心永远只有两个东西一个 SKILL.md和一个或多个脚本。我见过很多质量很差的 skill恰恰是目录结构搭得很花哨相关文件塞了一大堆核心的 SKILL.md 却写得含糊其辞。目录结构是皮SKILL.md 才是灵魂。2.2 SKILL.md 的 frontmatter 和正文怎么设计SKILL.md 最上面通常是 YAML 格式的 frontmatter写一些元信息。下面这一段是我自己项目里一个 skill 的缩略模板你可以直接抄作业--- name: frontend-code-review description: 当用户要求做前端代码审查、检查 PR、质量门禁评审、找出代码里的 debug 残留时使用。 --- # 前端代码质量门禁 ## 适用场景 - 用户要求审查前端代码 - 用户要求检查提交的 PR 是否达标 - 用户希望排查 console.log、debugger、TODO 残留 ## 执行步骤 1. 先读取 references/coding_standards.md了解团队规范 2. 调用 scripts/check_frontend.py 扫描目标目录 3. 按规范中的优先级分类输出问题清单 4. 对高危问题给出修改建议对低危问题只做统计 ## 输入要求 - 目标目录必须是本地存在的路径 - 如果没有明确目录默认认为当前工作目录 ## 输出格式 - Markdown 报告按阻断问题 / 警告 / 建议三级分类 ## 不适用场景 - 后端代码审查请直接说明不要使用本技能 - 如果只是询问代码写得怎么样这种主观评价不需要走完整流程frontmatter 里的 name 和 description 是最关键的。description 是 agent 决定何时激活这个技能的依据。如果 description 写得模棱两可agent 要么该用的时候不用要么不该用的时候瞎用。这里有个很实用的技巧description 应该写成当用户做什么事时使用而不是这是一个用于做某事的工具。前者是触发条件视角后者是自我介绍视角对 agent 的语义匹配来说前者命中率高得多。2.3 为什么用 Markdown 而不是代码来定义技能这是很多从传统软件开发转过来的朋友最容易纠结的问题。有人会问为什么不用 JSON 或者 YAML 把技能定义得结构化一点为什么不能直接写成一个 Python 类原因在于skills 的使用者不是传统程序而是大语言模型。LLM 最擅长解析的格式就是自然语言和 Markdown其次才是 JSON 这类半结构化数据。你用 JSON 定义规则规则一长模型读起来反而费劲而且 JSON 对流程步骤的表达非常别扭。Markdown 的优势在于它既有标题、列表、代码块这样的结构又保留了自然语言的灵活表达模型可以快速抓取标题层级也可以精读细节。更重要的是Markdown 支持一种渐进式披露的用法。SKILL.md 的主文件只写触发条件、执行步骤和注意事项尽量控制在几百行以内深度的参考资料放到 references 目录里只有 agent 走到某一步才去读。这样既不会在对话一开始就吃掉大量 token又能在需要时把细节翻开。这很像前端里的懒加载用不到的资源先不加载真正要用了再拉回来。2.4 不同平台的加载与触发机制目前市面上主流 agent 平台对 skills 的实现细节不完全一致但核心逻辑高度相似启动时扫描一个指定的 skills 目录读取每个 SKILL.md 的 frontmatter把 name 和 description 注册进可用的技能列表当用户请求命中某个 description 时加载对应的 SKILL.md 和相关资源按里面的步骤执行。Claude 的 agent skills、Codex 的 skills 仓库以及一些第三方工作台本质上都是这个套路。差异主要在于配置文件放在哪个目录、frontmatter 里要求的字段名、是否支持多级子目录、脚本运行的基准路径是哪里。所以要提醒你拿到一个新平台的 skill 说明先看文档不要凭印象猜路径。我见过有人把 Claude 的 skill 目录结构直接套到别的框架上结果加载失败,还以为是平台 bug。这里顺带说清楚一件事skill 加载不等于执行。加载只是让 agent知道有这个技能真正触发是运行时的语义匹配。同一个 skill在不同平台上的触达效果可能不一样因为背后模型的判断方式不同。这也是后面第四章要展开的跨平台兼容问题的根源。3. 手把手开发一个可落地的 Skill前端代码质量门禁实战3.1 选题为什么选代码审查作为示例理论知识铺垫完了接下来直接进入实战。我选前端代码质量门禁作为示例有三个原因第一这个任务本身是多步骤的需要先理解规范、再扫描代码、最后输出报告非常适合展示 skill 的组合能力第二它既需要 Markdown 知识团队规范的描述也需要脚本逻辑正则扫描能完整覆盖 skill 的两种编写方式第三前端开发相关 skills 算是目前社区里需求最旺盛的类别之一实操价值高。你可以把这个示例理解成一个最小可用的骨架。真正用到自己的项目里时你完全可以替换成后端 code review测试用例生成发布前检查清单等等结构是一样的。3.2 编写 SKILL.md一个可直接抄作业的模板我在 2.2 里给过缩略模板这里把它扩成一个能直接用的版本。先看完整的 SKILL.md--- name: frontend-code-review description: 当用户要求审查前端代码、检查 PR 或 MR、做代码质量门禁评审、查找 console.log/debugger/TODO 残留或要求按团队规范检查前端代码时使用。 --- # 前端代码质量门禁 ## 背景 这个技能用于对前端代码进行一轮结构化审查目标是发现会导致线上事故的高危问题以及影响可维护性的结构性隐患。 ## 执行步骤 1. 确定审查范围如果用户给了具体文件路径只审查这些路径否则审查当前工作目录下的前端项目。 2. 读取 references/coding_standards.md记住其中列出的禁止项。 3. 运行 python3 scripts/check_frontend.py 目标目录获取机器扫描结果。 4. 根据扫描结果结合 coding_standards.md将问题分为三类 - 阻断问题可能泄露密钥、存在明显安全风险、包含 debugger 语句 - 警告console.log 残留、TODO/FIXME 未清理、明显重复代码 - 建议风格不一致、命名不规范 5. 输出一份 Markdown 报告按上述三级分类每条问题标注文件路径、行号、问题类型和修复建议。 ## 输入要求 - 目标目录必须是本地存在的绝对路径或相对路径 - 用户没有指定路径时使用当前工作目录 ## 输出格式 - 标题为代码审查报告 - 开头先给一个统计摘要总共发现多少问题其中阻断/警告/建议各多少 - 随后按严重程度从高到低列出问题明细 ## 注意事项 - 不要修改任何代码只做审查和报告 - 如果脚本执行失败把错误信息原样附在报告末尾并说明无法完成机器扫描 ## 不适用场景 - 用户要求的是后端、安卓或 iOS 代码审查 - 用户只是询问代码风格意见没有要求完整审查流程这个模板你直接复制就能用。注意最后一段不适用场景这个小节在多数开源 SKILL.md 里都不存在但它非常有用。加了它之后agent 误触发的频率明显下降因为它有了一个反向边界知道什么情况下不要碰这个技能。3.3 配套脚本让 Skill 从讲方法变成能执行光有 SKILL.md 的话审查流程里扫描代码这一步还得靠模型自己读文件、自己找问题。这当然也能做但速度慢、token 消耗大而且容易漏。所以我们要配一个脚本把确定性最强的部分用代码完成。下面是我这个示例里的 check_frontend.py它做的事情很简单扫描目标目录里所有前端文件用正则找出常见的 debug 残留和疑似硬编码密钥输出 JSON 结果。#!/usr/bin/env python3 检查前端代码里的常见 debug 残留和疑似硬编码密钥。 import json import os import re import sys target sys.argv[1] if len(sys.argv) 1 else . issues [] patterns { console.log: re.compile(rconsole\.(log|debug|info)), debugger: re.compile(r\bdebugger\b), todo: re.compile(rTODO|FIXME), hardcoded_key: re.compile(r(sk|api[_-]?key|token)\s*[:]\s*[\][A-Za-z0-9]{16,}), } CODE_EXTENSIONS (.js, .jsx, .ts, .tsx, .vue) for root, dirs, files in os.walk(target): # 跳过依赖目录和版本控制目录 dirs[:] [d for d in dirs if d not in (node_modules, .git, dist, build)] for f in files: if not f.endswith(CODE_EXTENSIONS): continue path os.path.join(root, f) try: with open(path, r, encodingutf-8) as fh: for line_no, line in enumerate(fh, 1): for name, pat in patterns.items(): if pat.search(line): issues.append({ file: path, line: line_no, type: name, text: line.strip()[:120], }) break except Exception as e: issues.append({ file: path, line: 0, type: read_error, text: str(e), }) # 截断到前 50 条避免输出过大 result { issue_count: len(issues), issues: issues[:50], truncated: len(issues) 50, } print(json.dumps(result, ensure_asciiFalse, indent2))脚本的输出做了两个关键设计一是结构化用 JSONagent 解析起来非常省力二是截断最多输出 50 条避免几千条匹配项把上下文灌爆。脚本只负责找出问题至于这个问题严不严重、该怎么改留给 SKILL.md 和模型去判断。这是 skill 脚本设计的一条核心原则机器该做的用代码做判断该做的交给模型做。3.4 测试与迭代把 Skill 装进实际 Agent 里跑一遍写完之后最重要的一步是装进去实测。以多数支持 skills 的平台为例你要做的是把整个目录放到它指定的 skills 路径下。不同平台路径不同一般你在设置界面里能看到或者在启动日志里会打印出来。放好之后用几种不同说法去触发同一个请求帮我 review 一下这个前端项目检查一下 PR 里有没有 console.log 残留按咱们团队的规范过一遍代码质量找找这个项目里的 debugger我在测试时建议开 verbose 或调试日志观察 agent 是否真的读取了 SKILL.md。如果日志里根本没提到这个技能八成是 description 里的触发词和你的说法对不上。我第一次测试的时候就栽过一跤description 里只写了前端代码审查结果我说检查 PR它没反应把PRMR质量门禁debug 残留这些变体全部加进 description 之后命中率才上去。还有一次脚本没有设置退出码即使扫描失败 agent 也把输出当成正常结果拿去做报告了。修复方式很简单在脚本里根据结果设置退出码并在 SKILL.md 的注意事项里写明脚本退出码非零时不要生成报告。这类问题只有真正跑过一轮才会暴露出来。把 skill 跑通之后记得把team standards这类私有知识写进 references你的 skill 才真正属于你自己。4. 常见问题与排查技巧实录4.1 Skill 不生效或未被触发怎么办这是最高频的问题没有之一。百分之八十的情况都出在下面四个地方按顺序排查基本能解决。第一确认 skill 目录被平台识别到了。有些平台需要显式启用某个 skill或者要放在特定子目录里。你看一眼启动日志平台通常会列出它扫描已经加载的 skills 列表。不在列表里那就先解决路径问题。第二检查 frontmatter 格式。frontmatter 是 YAMLYAML 对冒号、引号、缩进的容错率很低少一个引号、多一个空格整个文件可能就被解析成普通正文name 和 description 全失效。第三检查 description 的表达方式。如果你的 description 写的是这是一个代码审查技能agent 在语义匹配时不一定能联想到PR、质量门禁、console.log这些说法。把它改成当用户要求审查代码、检查 PR/MR、做质量门禁或要求查找调试残留时使用这种触发条件句式命中率会立刻改善。第四确认请求里确实传达了要干活的意图。很多不触发案例其实是 agent 判断用户只是想聊天不是要执行任务这时候 skill 不触发反而是正确行为。一个我常用的测试技巧是准备一张触发词矩阵把用户可能发出的十几种说法写下来逐一触发一遍记录哪些命中、哪些没命中。然后把你实际测试中出现的真实说法不断补充进 description。两三轮之后这个 skill 在你日常工作场景里的触发率会稳定在九成以上。4.2 上下文爆炸SKILL.md 太肥怎么瘦身另一个高频问题是上下文爆炸。症状是对话刚开始token 消耗就大得离谱或者 agent 处理正经任务时频繁忘事。原因通常有三个。第一个原因SKILL.md 主文件写得太长。我见过有人把整个团队的完整规范直接塞进 SKILL.md总共两万多字。每次触发都要全文读一遍token 哪能顶得住。对策是主文件只保留必要部分触发条件、执行步骤、输入输出要求、不适用场景。满打满算控制在六百行以内通常两三百行就够用了。第二个原因references 里的资料被一次性全量读取。规范文件、模板文件、行业标准agent 一股脑全灌进来。对策是把 references 按子任务拆成多个小文件并且用更精细的指令让 agent 只有走到某一步时才去读某个文件。第三个原因脚本输出未经截断。脚本把几百个匹配项、几千行日志直接打印出来全部进入上下文。刚才示例脚本里那种只输出前 50 条的做法就是一个标准解法。这里顺带解释一下 token 是什么。token 是模型处理文本的最小计量单位可以粗略理解为模型眼里的一小段字符。中文一个字通常对应一到两个 token英文一个词通常对应一个 token。上下文窗口能容纳的 token 有限所有从 SKILL.md、reference、脚本输出进来的文本都在和用户对话、业务数据抢占这个空间。所以瘦身 skill本质上是把钱token 预算花在刀刃上。4.3 跨平台不兼容一份 Skill 多端跑的适配思路同一个 skill 能不能在 Claude、Codex、自研框架里同时跑答案是能但需要一点适配。不同平台的 frontmatter 字段要求不一样有的要求 name 必须和目录名一致有的不要求有的支持多级子目录有的只扫描一层脚本运行时的工作目录有的在 skill 目录有的在用户当前目录直接会导致脚本里的相对路径失效。最省事的思路是通用核心 平台适配层。SKILL.md 本身用最朴素的 Markdown 写不依赖任何平台的私有语法脚本调用也写成通用的python3 xxx.py形式不做平台特定处理。然后在 skill 目录里放一个 README 或 per-platform 文档记录每个平台的安装路径和需要调整的字段。我自己实践下来这种写法的 skill 迁移成本最低。另外要提防一个隐蔽的坑有些平台会限制 skill 目录里脚本执行时的网络访问有些不会。如果你的 skill 依赖外部命令比如调用 eslint务必在 SKILL.md 的输入要求里写清楚环境依赖否则换个机器就跑不起来。特别是团队共享 skill 的时候一定要约定运行环境不然别人拿到你的 skill 只会两眼一抹黑。4.4 脚本执行与沙箱别让 Skill 乱跑本地命令skill 里的脚本默认是在本机真实环境中执行的这意味着它有真实的文件系统权限甚至可能是当前用户权限。这里有一条红线要讲清楚来自不可信来源的 skill脚本一定不要直接跑。它们的执行步骤可能设计成读取~/.ssh目录、读取环境变量并输出到日志然后在某个环节把这些信息发出去。我自己的习惯是凡是执行完整脚本的 skill都先放进容器里跑一轮或者至少用一个没有敏感权限的独立用户运行。脚本里如果涉及写文件尽量限制在它自己的临时目录避免用绝对路径覆盖项目文件。SKILL.md 里的步骤也会审查一遍有没有要求 agent 读取环境变量“读取 ~/.env”输出到日志这类危险动作。这部分在第五章还会展开讲因为当前 skills 生态里安全风险被严重低估了。5. Skills 生态与安全下载渠道、质量判断与风险防控5.1 现在去哪找现成的 Skills自己做 skill 固然好但社区里已经沉淀了大量现成的技能包直接拿来改比从零开始省力得多。目前获取渠道主要分三类。第一类是官方渠道。Claude 有 agent skills 的官方市场Codex 也有对应的 skills 仓库平台文档里通常直接能搜到。第二类是基于 GitHub 的社区聚合仓库。搜索 awesome agent skills 这类关键词能找到很多人整理的 skill 清单按用途分好类比如代码审查、文案生成、数据分析、视频脚本生成、测试用例生成等等。这些仓库往往附带安装说明质量参差不齐但作为灵感来源非常不错。第三类是第三方 agent 工作台内置的技能库。社区里一些常用的 agent 工具名字里带 Hermes、Superpower 的几个你可能也见过会提供在应用内浏览和安装 skill 的功能相当于把 skill 做成了类似应用商店的形态。不管从哪下载第一步都是把压缩包或仓库里的文件完整看一遍尤其是 SKILL.md 和所有脚本。不要嫌麻烦这一步的重要性会在后面体现。5.2 如何判断一个 Skill 是否值得安装我装过不少 skill也踩过不少坑。现在总结出一套快速判断标准你可以直接拿来用。先看 SKILL.md 本身name 和 description 是否清晰执行步骤是否具体到能执行有没有写出输入要求和输出格式。一份认真写的 SKILL.md 会让你在读完之后立刻知道这个 skill 什么时候用、怎么用、产出什么。再看配套资源有没有示例、有没有测试脚本、有没有维护者的实际使用记录。一个连最基本示例都没有的 skill多半是随手写出来丢上来的。然后看维护状态最近一次更新是什么时候issue 区有没有人在反馈问题维护者有没有回复。三个月不更新不代表一定不行但如果是几个月前发布且没有任何互动记录风险就明显升高。社区里那些万能 skill要特别警惕。一个声称什么都能干的 skill往往什么都干不好。真正高质量的 skill 都是窄而深的解决一个明确的问题解决得特别好。我自己的经验是一个 star 数不高但专注解决单个痛点的小 skill往往比 star 数很高的大而全 skill 好用得多。5.3 恶意 Skill 的常见套路与防护措施2025 年的供应链攻击早已经不局限于 npm 包和 Docker 镜像了skill 正在成为新的攻击面。它的危险之处在于隐蔽一份 SKILL.md 看起来只是文字但它能诱导 agent 去执行一连串动作而这些动作可能远超你的预期。恶意 skill 的套路通常有几类。一类是在执行步骤里塞入读取环境变量读取 ~/.env 文件并作为参考资料然后配套脚本把这些信息拼进正常输出。另一类是让 agent 访问某个外部地址把环境信息作为请求参数发出去。还有一类更隐蔽表面上做正经任务但脚本里内置了删除文件、修改全局配置等破坏性操作只等某个条件满足就触发。防御措施其实不复杂但需要变成习惯。第一只安装可信来源的 skill安装前把 SKILL.md 和每个脚本逐行过一遍重点关注它要求 agent 访问的路径和域名。第二用 git 管理你的 skills 目录每次更新都看 diff别让某个依赖更新了悄悄带进恶意内容。第三给 agent 配置最小权限不要用管理员账号跑 agent脚本执行尽量沙箱化网络访问默认禁止需要时单独放行。第四定期回看 agent 运行日志观察有没有异常的网络请求和文件访问。安全测试类的 skill 有它存在的价值但只应该在明确授权的范围里使用这点没有任何商量余地。5.4 下一步把 Skills 变成个人或团队的能力资产最后一个话题我想聊聊 skills 的上限。很多人把 skill 当成一个高级 prompt 模板装完就完了。但真正用好 skills 的人是把它当成能力资产来经营的。对个人来说skill 可以和 agent 记忆形成互补记忆负责记住你和它的历史,技能负责把重复的工作流固化下来。当你的 skills 库积累到一定量级你会发现启动新任务的速度完全不一样了不用再一遍遍解释背景一句按项目规范出周报就够。对团队来说skills 应该像代码一样被管理放进共享仓库走 review 流程维护语义化版本号更新时写 changelog。我见过有的前端团队把编码规范、发布检查清单、回滚预案全部做成 skill新人入职后直接让 agent 按团队流程带跑一遍效率提升非常明显。再往下走单一 skill 的堆积会逐渐形成技能编排的需求。一个开发任务可能需要依次触发代码审查 skill、测试生成 skill、发布检查 skill它们像流水线一样串联起来。这种组合方式其实已经摸到了多 agent 协作的门槛。从单 skill 到技能组合再到多 agent 编排这条进化路径值得你花时间认真走一遍。我自己现在的习惯是先写 skill再开始干活。一个任务只要重复出现两次我就会琢磨把它沉淀成技能包。因为从第三次开始省下的时间和注意力远超当初写 skill 投入的那点功夫。踩过最深的坑是早期比较迷信社区里那些万能 skill装了一堆之后发现真正稳定有用的反而是自己按业务场景写的三五个。所以我的建议很朴素先动手做自己的第一个 skill再考虑批量试用别人的。最后分享一个小技巧写 SKILL.md 的时候在末尾加一段本技能不适用场景能显著降低误触发概率。就这一句让我的 skill 误触发率降了不少实测下来很值。