1. 先搞清楚一件事Skills到底是什么最近大家都在聊skills尤其Claude Code、Codex、OpenCode这些AI编程工具更新之后“skills”这个词基本成了Agent开发圈的新宠。很多人第一次看到这个概念时会觉得——这不就是prompt工程换了个新马甲吗我一开始也是这么想的直到自己动手写了几个skills并在实际项目里跑起来才意识到这套东西和单纯的prompt优化完全不是一个维度。Skills最直白的理解是给AI Agent配备的一套“专业操作手册”。它不是一个空的提示词而是包含目标描述、执行步骤、约束规则、参考示例、甚至配套脚本在内的完整技能包。Agent在拿到任务之后会先去翻这本手册再按照手册里的方法去完成工作。就好比你招了一个实习生他本身聪明、学习能力强但他没有工作经验你不知道他会不会把事情办砸。Skills做的事情就是把“老员工的经验”整理成一本可执行的SOP让这个新人在第一次接到同类任务时就能拿出接近熟手的表现。这套机制的背后动机也很简单。基础大模型的能力再强也不可能提前学会你公司内部的代码规范、你常用的设计稿还原流程、你项目里那套特定领域的数据处理套路。预训练阶段能学到的知识是“通用常识”而实际工作里大量需要的是“领域经验”。Skills刚好填补了这中间的断层——用轻量级的描述文件把领域经验固化下来随用随取成本极低。我从openai、claude和社区开源项目里梳理了一圈发现skills的定义和使用方式正在快速收敛成一个相对统一的标准。基本上你只要理解了这套逻辑在Claude Code里写的skills稍作调整也能在Codex或者OpenCode里用这背后有一个叫Agent Skills的开放规范正在成型。这篇文章我会把我这段时间做skills开发踩过的坑、总结出的经验、以及实际跑通的方案全部写出来。不管你是前端、后端、算法还是搞数学建模、学术研究只要能用到AI编码工具这篇文章应该都能给你一些启发。2. Skills的核心机制与设计逻辑2.1 一个Skills包里到底有什么在动手之前先花点时间把skills的目录结构搞清楚。以目前社区里比较通用的格式为例一个标准的skills包长这样my-skill/ ├── SKILL.md # 技能描述文件Agent首先读取它 ├── scripts/ # 可执行脚本复杂逻辑放这里 │ ├── analyze.py │ └── build_report.py ├── references/ # 参考资料按需加载 │ ├── example_input.json │ └── style_guide.md └── assets/ # 资源文件图片、模板等SKILL.md是这个技能包的核心入口它用Markdown写成包含一段YAML格式的frontmatter和正文说明。frontmatter里至少要写清楚这个技能的名字和描述因为Agent在决定“要不要调用这个技能”的时候就是靠这两个字段来做判断的。一个写得模糊的description很可能让你的skills在关键时刻被Agent直接忽略。SKILL.md的正文部分才是真正体现水平的地方。这里要写清楚技能的触发场景、操作步骤、约束条件和输出格式。写得越具体、越可执行Agent完成任务的稳定性和质量就越高。你给模糊的指令它就给你模糊的结果这一点在Agent身上体现得比人类员工还要明显。2.2 用生活化的方式理解它的工作流程我经常跟朋友打一个比方传统prompt是你在路边随手拦了个出租车告诉司机“去机场”剩下的路线他自己看着办。Skills不同它更像你给一个代驾发了导航路线——从起点到终点每个关键路口怎么转、哪个出口下、收费站大概多少钱全部提前规划好了。代驾可以按这个路线走也可以根据实时路况微调但大方向不会跑偏。具体到Agent的执行环节当用户提出一个任务后Agent会在上下文里搜一遍可用的skills列表。这个搜索过程有点像人脑的记忆检索——看到“帮我把设计稿转成前端页面”这个需求脑子里马上蹦出之前学过的一个叫“design-to-code”的技能包。然后Agent会加载这个技能的SKILL.md按照里面的步骤一步步执行。如果中途需要处理数据文件他会去scripts目录里找对应的脚本如果需要对标参考样式他会翻开references目录里的示例。这个按需加载的机制非常关键。不是说所有skills都一股脑塞进上下文里而是在需要的时候才取出来用这保证了大模型的上下文窗口不会被无关内容撑爆。我记得在早期做Agent应用的时候最头疼的就是上下文窗口不够用每次都要精心裁剪prompt。Skill的按需加载模式相当于把这个问题从根源上缓解了。2.3 Skills和MCP工具的关系一个负责“怎么想”一个负责“怎么干”聊skills必绕不开MCPModel Context Protocol。这两个概念经常被放在一起讨论但它们解决的问题其实完全不同。用一句话来概括Skills解决的是“Agent如何把一件事做好”的问题MCP解决的是“Agent如何调用外部工具拿到数据”的问题。我举个具体的例子。假设你要做一个“从GitHub仓库代码生成架构图”的skill。这个skill里的SKILL.md负责告诉Agent应该按什么流程来分析项目结构、哪些文件需要优先阅读、架构图应该画到什么粒度。但是当Agent真的要拉取仓库内容的时候它得通过MCP调用GitHub API或者借助Codex/Claude Code自带的文件读取能力。Skills定义了“做什么、怎么做”MCP提供了“靠什么来做”。从设计哲学来看Skills更像是“大脑里沉淀的方法论”MCP则是“手脚的延伸”。两者配合起来Agent才真正做到既能想明白、又能办成事。社区里有个说法我非常认同一个成熟的Agent项目八成以上的场景只需要skill只有真正需要动外部数据的时候才上MCP。所以很多人一上来就问“skills怎么调用MCP工具”其实这个问题问反了。更合理的思路是先想清楚这个任务的核心是什么——是判断与决策还是数据的获取与回传。前者用skills解决后者才有必要引入MCP。2.4 社区里那些让人眼前一亮的Skills在GitHub上逛了一圈这个领域已经有相当多高质量的开源skills仓库了。baoyu的skills合集是很多人的入门首选里面整理了覆盖内容创作、代码审查、数据分析各种场景的skill定义非常适合一边看一边学习人家是怎么组织指令的。还有一个叫mattpococks skills的仓库属于典型的高手出品它对AI的命令约束写得非常细细致到“在什么情况下必须停止追问、直接按默认策略执行”这种约束能极大减少人机交互的往返次数。除了这些综合性的仓库很多垂直场景的skills也值得关注。比如学术研究类的skill会教Agent如何按照学术规范去搜索文献、评估文献质量、最后生成带引用的综述数学建模类的skill则会把问题抽象、模型选择、敏感性分析这些步骤全部标准化。这些垂直skills的共同特点是把某个领域的隐性经验显性化让一个完全没有该领域背景的Agent也能产出及格的成果。看完这些案例我自己最大的感受是Skills开发的门槛不高但天花板很高。任何人都能写一个“帮我总结这段文字”的简单skill但要写出一个能稳定处理复杂工程任务的skill需要对任务本身有极深的理解还需要反复迭代。这也是为什么我后面会强调开发skills本身就是一个“人机协同”的过程——你在教AI的同时其实也在逼自己把业务理解得更透彻。3. 从零开发自己的第一个Skills步骤与坑3.1 第一步想清楚边界别指望一个Skill解决所有问题开发Skills最容易犯的错误就是想把一个复杂的业务场景全部塞进一个skill里。我最早写的一个skill就是因为这个原因失败的。当时我想做一个“全能前端分析器”既要做代码审查又要做性能优化建议还想顺便生成补丁。结果Agent每次调用这个skill都会跑偏要么只做了其中一项要么在全能目标之间来回横跳输出质量非常不稳定。后来我把这个“全能”skill拆成了三个小skill一个专门做代码审查、一个专门做性能分析、一个专门生成优化补丁。每个skill的SKILL.md都只有二三十行职责单一、边界清晰效果立刻好了很多。这个经验后来我在很多项目里反复验证过——Skill的粒度宁小勿大单个skill的职责越纯粹模型执行起来就越稳定。所以在动手写之前先花十分钟问自己几个问题这个skill是给谁用的、处理什么类型的输入、产出什么格式的结果、哪些情况应该拒绝执行。把这些想清楚了再动笔比直接打开编辑器写指令要高效得多。3.2 第二步SKILL.md的写作规范与frontmatter细节SKILL.md的写作直接影响Agent对技能的理解程度值得花心思仔细打磨。frontmatter部分我建议至少包含name和description两个字段。name要简短最好能直接体现技能用途description要写清楚“在什么情况下使用这个技能”这里不要惜字如金写得越具体越好因为Agent判断技能匹配度完全靠这个字段。description的写法有个小技巧把触发场景和排除场景都写进去。比如“当用户需要将图片设计稿转换为HTML/CSS代码时使用此技能。如果图片只是普通配图不需要还原成代码则不应使用此技能。”这样定义Agent就能避免在模棱两可的时候误用或漏用。正文部分的结构我习惯按这个顺序来组织简介两到三句话说明技能的用途和输出目标输入要求明确需要用户提供什么信息缺什么就引导用户补充执行步骤用编号列表逐条写清楚每一步做什么输出规范定义最终的交付格式、文件命名、内容结构注意事项列出常见的边界条件、不允许做的事这里有个很重要的细节步骤的描述要具体到“动作级”不能停留在“目标级”。很多新手写的步骤是“分析代码中的性能问题”这个描述其实只说了目标没有说动作。更好的写法是“逐文件检查scripts目录下的所有JavaScript文件列出所有循环内进行的DOM操作估算每条操作的时间复杂度然后给出优化建议”。Agent看到前者可能无从下手看到后者就知道该干什么了。3.3 第三步哪些逻辑放进Prompt哪些逻辑放进脚本这是Skills开发里最考验功力的一道选择题。刚开始写skill的时候我倾向于把所有东西都写进SKILL.md的指令里觉得这样最省事。但随着skill复杂度的增加问题很快暴露出来——步骤一多大模型在长指令下容易“选择性失忆”前面的规则到了后面就不遵守了。现在我的原则是判断逻辑、决策逻辑、质量标准的描述放在SKILL.md里因为这些需要模型的语言理解能力凡是能确定算法步骤的、涉及数据处理和计算的全部写成脚本。举一个实际的例子。我写过一个“代码变更日志生成”的skill它的工作逻辑是读取本次提交涉及的文件列表和diff内容然后按类型分类并生成规范格式的changelog。这个任务里“如何分类”“如何生成条目”看起来像是判断逻辑但本质上是有规律可循的。如果让模型自己判断文件属于“feat”“fix”还是“refactor”每次输出的归类标准可能不一致。我的做法是写了一个Python脚本先做关键词匹配给文件打上类型标签然后由Agent根据这个标签生成对应的changelog条目。这样既保证了分类的稳定性又保留了模型在遣词造句上的灵活性。3.4 目录组织与命名规范细节决定体验Skills开发这件事代码固然重要但目录结构同样影响使用体验。因为Agent在定位技能文件的时候是按照目录结构来检索的。一个乱七八糟的目录结构会让Agent在加载技能时花费多余的理解成本。我目前比较推荐的做法是每个skill独立一个目录目录名用短横线连接的小写单词比如web-design-to-code、code-reviewer、data-visualizer。scripts子目录里放可执行脚本references子目录里放参考文档和示例assets子目录里放静态资源。如果脚本引用了本地的依赖port需在SKILL.md里写清楚Python虚拟环境的激活命令。还有一个细节很容易被忽略脚本的入口函数和参数说明一定要写清楚。我在references目录里放了一个README专门记录每个脚本的输入参数和输出格式方便Agent调用的时候快速查看。一开始我觉得这步多余后来发现自己隔一个礼拜就忘了脚本的参数定义Agent当然更记不住。把这些信息沉淀下来等于给自己后面的工作减负。4. 高频场景实操案例七个可以直接复用的Skills设计思路4.1 前端开发让AI学会“看图写代码”前端是skills应用最活跃的场景之一其中社区里讨论最多的是图片还原设计稿。这类skill的核心目标很明确用户上传一张设计图Agent输出一整套可直接运行的前端代码。实现这个需求的关键不在写代码环节而在“看图”环节。Agent能否准确地从图片里识别出布局结构、间距比例、颜色体系直接决定最终还原度。我的做法是在SKILL.md里要求Agent分三步走第一步分析整体布局确定页面结构是单列、双列还是栅格第二步提取设计规范包括主色、辅助色、字体大小、间距基准第三步按模块拆分写代码每完成一个模块就对照原图检查一次。这里面还有一个非常实用的技巧要求Agent在写CSS时把设计图里的颜色值直接以原始值记录成CSS变量不要自己去“微调”颜色。很多模型在生成代码时会自行“优化”颜色值结果就是还原出的页面总感觉颜色不对劲。把这个约束写在skill里可以从根源上避免这种问题。代码生成部分我要求Agent优先使用TailwindCSS还是less这种具体方案取决于用户自己的偏好。skill里要写明“默认使用XXX框架”之类的设定否则模型会每次猜一次导致风格不统一。4.2 数学建模把竞赛套路沉淀成可复用的流程数学建模场景的skills在高校竞赛圈里需求很大。这类skill的价值在于它能强制Agent在执行任务时遵循一套完整的建模方法论而不是随机应变。我参考多个数学建模skills的设计后整理出了一套公认好用的流程模板任务理解、问题分析、模型假设、模型构建、求解计算、结果分析、模型评价。每个阶段在SKILL.md里都有明确的交付物要求。举个例子在“问题分析”阶段skill要求Agent必须先画出问题的因果关系图再写出变量定义表最后给出建模思路在“模型假设”阶段要求每个假设都必须附带合理性说明。这套流程的妙处在于它可以有效防止Agent一上来就套用某个经典模型“硬解”。有了分阶段要求之后Agent必须先理解问题本身再决定用什么模型。对参加比赛的学生来说这个skill相当于把指导老师的经验前置到了工具里价值非常直接。4.3 学术研究从文献调研到综述生成学术类skills最近热度也很高核心痛点是解决“Agent如何做负责任的学术输出”。这个领域最大的风险在于模型天生倾向于“一本正经地胡说八道”虚构文献、捏造引用都是常有的事。一个设计良好的学术skills首要任务就是约束模型的这些行为。我见过设计得比较完善的academic research skill它给Agent规定了严格的文献处理流程第一步从用户给出的关键词出发列出检索字符串第二步调用学术搜索引擎获取真实的文献列表第三步逐篇阅读摘要和引言评估相关性第四步只基于真实文献的内容进行综述写作。SKILL.md里专门有一段“禁止行为”明确写了“不得生成任何不存在的文献”“不得编造引用页码”甚至在输出格式里要求每条引用后面都附带来源链接。这种把“学术诚信”以规范形式写进skill的做法我觉得是所有内容生成类skill都值得学习的。模型本来没有“伦理”概念你给它一套规则它反而能表现得像那么回事。4.4 安全评估合规授权的渗透测试Skills“渗透测试skills”在热搜里热度不低很多人想借助Agent来做安全测试。这个场景对合规要求极其严格我在开发相关skills的时候用了一条铁律所有安全测试必须基于用户明确授权且有合法目标的场景。一个负责任的安全评估skills它的SKILL.md里应该前置“授权确认”步骤。具体的做法是在技能描述里写明“本技能仅适用于用户对自身系统或已获得书面授权的目标进行安全评估不适用于任何未经授权的系统”。在执行计划上我倾向于把工作流设计成信息收集、端口扫描、漏洞识别、报告生成四个阶段前三个阶段产生的原始数据都保留在本地最后统一生成报告。这里想额外提醒一句安全领域的skills是把双刃剑使用边界必须严格限定在合规场景。写这类skill时务必在核心指令里反复声明授权前提这不只是为了形式合规也是为了防止skill被滥用在不当场景中。4.5 测试用例生成让AI扮演“最挑剔的质检员”测试用例生成的skills核心难点在于如何让Agent生成的用例覆盖足够多的边界条件而不是只写happy path。开发这类skills时我参考了一个比较成熟的设计模式即在SKILL.md里列出测试思维维度清单要求Agent从功能正确性、边界条件、异常处理、性能表现、兼容性这五个维度分别设计用例每个维度至少设计两组测试用例。这套模板对约束模型行为很有效不加约束时模型更倾向于生成常规场景用例但有了维度清单之后模型的覆盖范围明显扩大。我还要求每个用例必须给出前置条件、操作步骤、预期结果三要素这样生成的用例集可以直接导入到测试管理工具里使用。4.6 网页信息检索让Agent学会“先查再说”Claude Code和一些工具本身就支持联网搜索但模型在联网搜索时往往存在一个问题——它倾向于在搜索到部分信息后就开始作答遗漏了完整的信息收集过程。网页检索类的skill就是针对这个问题设计的。我的实现思路是在SKILL.md里要求Agent遵循“搜索-提炼-再搜索-再提炼”的循环流程。第一步基于用户问题拆解出多个子查询条件第二步针对每个子查询分别执行搜索操作第三步把搜索到的网页按照相关度从高到低排列并提取核心观点第四步如果发现信息不足重新生成补充查询并重复前面的步骤第五步整理成结构化摘要在摘要里注明引用了哪些来源。这个流程模拟了人类做调研时的做法能够显著提高最终答案的信息完整度。4.7 前后端联调一款“审代码的艺术”Skills实践前后端联调场景表面上看不像前面几个场景那么“酷炫”但实际开发中非常实用。联调过程中最常见的问题就是接口文档与实现不一致、数据结构定义混乱、异常状态处理缺失。本质上是前端开发者和后端开发者各自持有不同的信息缺少一个统一视角来审视整个调用链路。我设计过一个“API联调检查”的skill它的职责是读取前后端代码对照接口定义找出所有调用不一致的地方。这个skill会要求Agent先梳理出全项目所有的API端点逐个检查后端的返回结构是否与前端的类型定义匹配特别关注字段名的大小写、嵌套层级、null值处理这三类最容易踩坑的问题。运行一次之后产出一份不匹配清单开发者照着清单改就行。这个skill的价值在于它把原本需要“人肉”对比的重复劳动交给了Agent而且模型在对比结构一致性上有天然的优势——标注好规则之后它找差异的准确率相当高。5. 主流AI编程工具的Skills支持情况与选型建议5.1 Claude Code目前对Skills支持最成熟的一档Claude Code的Skills机制是目前社区讨论度最高的也是我自己用得最顺手的。它在工程实现上做得很扎实支持按目录加载多个skills支持在SKILL.md里使用变量模板还支持通过MCP协议调用外部工具。在Claude Code里启用一个skill只需要把skill目录放到配置的路径下即可。它会在启动时扫描这些目录读取所有SKILL.md。一个值得关注的特性是“动态发现”和“按需加载”之间的平衡机制——Claude Code不仅会主动读取目录下的所有skill定义还会根据当前任务的性质去优先匹配相关的skill这就要求我们写的description必须足够精准。如果你在Claude Code里写过一个复杂的skill你会注意到它有一个特点步骤越长模型“走样”的概率越大。解决办法是做“分段验证”也就是在SKILL.md里加入检查点要求——第3步做完之后停下来把中间结果输出给用户确认再继续往下做。这个做法虽然多了一次交互但换来的是整体流程的可控性我认为性价比很高。5.2 Codex云上执行Skills更贴近“自动化流水线”Codex的Skills支持也在快速完善中。与Claude Code不同Codex的运行环境偏云端所以它的skill设计更讲究“流程闭环”和“自动化程度”。如果你希望一个skill从头到尾接管整个任务流程而不需要过多的人工介入那Codex的skills风格会让你感到很顺手。在Codex里技能文件会被同步到云端沙箱环境中执行这意味着你可以在skill里调用外部API、执行数据库操作、读写云端文件。我理解这本质上是Codex延续了“Agent as a Service”的定位——skill更像是云函数而不是内存里的prompt文本。有一类针对Codex优化得很好的skill叫“项目分析型skill”。它的典型流程是指定一个仓库地址Codex按skill里定义的结构化步骤先拉取仓库、初始化环境、运行现有测试再生成分析报告。整套流程一气呵成人工干预降到最低。5.3 Cursor把Skills融入到日常补全与交互体验中Cursor作为AI辅助编辑器在上手体验上做得很平滑。它在skills上的支持更偏向交互式的——你不需要提前规划一个完整的技能包而是在日常开发中发现规律后随手把某类操作沉淀成一个技能。这种轻量级的沉淀方式符合大多数前端开发者“先干活后整理”的习惯。实际上我在Cursor里用skills的方式跟Claude Code不太一样。在Claude Code里我会专门为每个项目写定制skill在Cursor里我更多是保存“个人级的习惯性操作命令”比如“按当前项目的目录结构创建一个标准的新组件”或“对当前文件做一次完整的代码审查并按格式输出结果”。这些高度碎片化的技能如果每个都做成大而全的skill包反而累赘但做成轻量级的skill就刚好合适。5.4 工具选型小建议讲了这么多最后做一个简单的选型总结。如果你日常的工作模式是“对话驱动型任务”希望在自然对话中灵活调用各类技能Claude Code是最稳妥的选择如果你负责的是“自动化流水线型任务”希望尽量减少人工介入Codex的云端执行模型会让你更省心如果你是在日常编辑器里办公希望像记笔记一样随手沉淀技能Cursor的轻量级skills更顺手。整理了一张对比表供参考工具核心优势适合场景注意事项Claude Code对话式交互自然按需加载能力强复杂任务拆解、边对话边执行长步骤易走样需加入检查点Codex云端执行自动化程度高批处理流程、无人值守任务调试本地脚本时需要额外适配Cursor上手简单与编辑器融合好日常编码辅助、零碎技能沉淀轻量级不适合处理超长任务这三个工具我都实际用了相当长时间。坦率说并没有一个完美之选选哪个更多取决于你的工作流习惯。但无论选哪个工具真正决定产出质量的是skill本身的设计水平——工具只是容器skill才是灵魂。6. 常见问题与排查技巧实录6.1 “Agent不调用我的Skills怎么办”这是我在社区里被问到最多的问题。明明skills目录配置好了SKILL.md写得也算详细但Agent就是视而不见。这个问题的根源绝大多数情况下出在description字段的质量上。模型评估“是否需要调用某个技能”的方式就是把这句description和用户当前的需求做语义匹配。如果你写的description是“用于代码分析”而用户说的是“帮我看看这个项目哪里可以优化”这两句话在语义上的关联其实很弱模型就不会主动触发这个skill。解决方法是把description写得像一段“触发条件声明”明确列出什么类型的问题、什么场景下会用到这个技能。比如“当用户要求对现有代码进行质量分析、性能优化建议或技术债务评估时使用此技能。适合在用户提交代码仓库或项目目录后调用。当用户只是询问概念性问题不需要分析特定代码时不应使用此技能。”这样写触发率会明显提升。6.2 Skill用了但效果很差怎么办如果Agent确实调用了skill但执行结果一塌糊涂多半是SKILL.md正文里的指令粒度太粗。这里的排查思路跟调试程序一样也是一步步定位问题所在。先看步骤描述是否足够具体。很多人的skill里写的是“分析项目结构”但没有说清楚“怎么分析”“分析哪些文件”“用什么指标来衡量结构合理性”。这种抽象描述在模型眼里约等于没有约束它只能凭借自己的猜测自由发挥。改成“先读取根目录下的package.json和src目录的文件树识别出模块边界找出循环依赖然后给出重构建议”每一步的指令就清晰了。再看有没有定义输出格式。没有输出格式约束的skill每次产生的结果结构都不一样用起来非常痛苦。我习惯在SKILL.md末尾固定输出模板比如“报告应包含以下章节问题描述、影响范围、修复建议、参考代码”这样不管谁调用结果都是统一结构后续加工处理起来方便得多。6.3 上下文窗口还是不够用即使有了按需加载复杂任务依然有上下文窗口焦虑。三个skill同时被加载再加上代码、日志、用户输入几千个token很快就被吃光了。我的解决办法是控制单个SKILL.md的体量把SKILL.md当作“目录”而不是“全书”。正文里只写精简版流程和最核心的约束条件需要引用的大段内容放到references子目录里的单独文件中。SKILL.md中通过相对路径引用这些文件只有当对应章节需要执行时Agent才会去读取references里的内容。这种设计思路可以大幅压缩常驻上下文的体积。比如一个图片转代码的skill完整版说明可能有一千多行但精简后的SKILL.md只有四五十行剩下的设计规范、示例代码、组件库说明都放在外部文件里按需加载。实际跑下来效果和把全部内容塞进去没有区别却节省了大量上下文空间。6.4 从“能用”到“好用”的迭代技巧最后一个建议可能有点反直觉不要追求一次性把skill写到完美而是先写一个“勉强能用”的版本跑起来然后根据实际输出做迭代优化。Skills优化的过程本质上是不断“喂案例”的过程。每次Agent生成了你不满意的结果先别急着改prompt而是把“正确的结果应该长什么样”以示例形式补充到SKILL.md或references目录里。对大模型来说一个具体的正例胜过十句抽象的规则描述。把“输出应该包含性能得分、瓶颈描述、优化建议”这句抽象描述替换成一段真实的优秀输出示例模型学会这个技能的效率会快非常多。另外记得定期复盘已有skill的使用记录把那些长期没用上的skill果断清理掉保持技能库的精简。我之前一度攒了十几个“看起来有用”的skill实际常态使用的只有五六个剩下的反而干扰了Agent的技能检索和加载。精简之后整体表现反而提升了。从去年年底开始接触skills到现在我最大的体会是这一套机制真正值得推广的原因不是它给大模型增加了几项“技能”而是它改变了我与AI协作的思考方式——从“我告诉AI要做什么”变成了“我教AI怎么做好一件事”。写skill的过程逼着我把模糊的需求整理成明确的流程把经验沉淀成规范把每个人脑子里那套“怎么做才靠谱”的隐性知识变成了别人也能复用的显性资产。如果你还没试过自己动手写一个skill我建议你从最小的场景开始——让AI学会你的代码提交信息规范或者让它学会按你的标准整理会议纪要。用不了半小时你会体验到“教AI一次以后它都会了”的快感。