这个系列写到第14篇，我聊点真正能提效的东西——大模型Skills应用。之前几篇要么在讲模型能力边界，要么在讲上下文工程，这次把视角落到一个具体场景：在Trae这款AI原生IDE里，怎么把Skill从"听说过"变成"天天用"。Skill这个概念最近在大模型应用层很火，本质上它就是把一段精心设计的提示词、一套固定的工作流程、若干配套参考文件打包成一个可复用的"能力单元"。你可以把它理解成给大模型装上一个岗位SOP，让它不用你每次重复交代，就能按规范把活干完。这篇文章适合正在用AI辅助编程、想沉淀个人工作流、或者打算在团队里统一AI协作方式的开发者。我会从Skill的底层逻辑、目录结构、编写规范讲到完整实操和踩坑记录。1. 先想清楚：Skill到底在解决什么问题1.1 一个Skill的本质：把提示词变成可复用的技能很多人第一次听说Skill，会觉得它不过是一个"高级提示词模板"。这个理解没错，但只说对了一半。普通提示词模板是静态文本，你发给大模型，它读完就完了；Skill则是一个有结构、有依赖、可触发、可复用的完整工作包。它不光告诉大模型"你要做什么"，还规定了"先看哪些文件、按什么顺序判断、输出什么格式、哪些事情绝对不能做"。我打个比方。你让一个实习生帮你做代码审查，如果他只听过一句"帮我看下代码"，大概率会走神，一会儿看逻辑、一会儿挑格式、一会儿又去纠结变量命名。但如果你给他一份《代码审查SOP手册》，里面写清楚了审查范围、检查清单、输出模板、必须引用哪些文档，他的产出质量就会稳定得多。Skill就是这份SOP手册，而且大模型比实习生更听话——只要指令写得足够明确，它会严格照做。这里有三个关键技术点值得注意。第一，Skill以Markdown文件为载体。这个选择不是随意的，大模型的训练语料里Markdown格式占据绝对主导，模型对标题、列表、引用、代码块的语义结构理解成本最低。你用README风格写指令，模型执行起来最顺手，比喂它一堆JSON配置要自然得多。第二，Skill内部可以附带多个关联文件，比如参考文档、示例代码、历史模板。这些文件通过相对路径被主指令文件引用，相当于给模型提供了"补充阅读材料"。正因为有了外部引用能力，Skill处理的复杂度远高于单段提示词。第三，Skill有元信息区，用来声明自己的名字、用途、触发场景。这就像给函数写了一个清晰的函数签名，IDE和模型可以根据你的自然语言描述，自动判断该调用哪个Skill。1.2 为什么选Trae这个载体来做Skill应用Skill这个概念并不局限于Trae，很多工具链都在做类似的事情。但Trae作为一款面向AI编程场景的IDE，它的天然优势在于拥有完整的代码上下文感知能力——它能获取你当前打开的文件、选中代码区域、项目目录结构、编辑器的运行状态。这意味着Skill指令里可以写"读取当前活动文件的函数列表"、"分析选中代码段的时间复杂度"，模型真的能做到，因为它有IDE层面传来的实时上下文。举个例子。你写一个"数据库迁移脚本生成"的Skill，在通用聊天助手里面，你得手动把表结构、现有迁移文件的历史记录全部粘贴进去。而在Trae里，Skill可以引用项目目录下的schema文件、迁移目录下的历史脚本，模型自己会去读。这种上下文接近能力，让Skill从"玩具"变成了"生产力工具"。另外，Trae把Skill入口放在IDE工作区内，和代码编辑、版本管理、终端命令在同一个界面上，使用链条很短。对我来说，注意力可以始终保持在编码上下文里，不用切换到另一个对话框去复制粘贴。对于一个研发团队，后续把Skill目录纳入版本管理、跟随项目仓库分发，也是顺理成章的事。所以选Trae不是因为它Skill功能发明得早，而是因为在"编码场景下做技能化封装"这件事上，它给到的工作流最完整。1.3 哪些场景值得优先做成SkillSkill不是万能的，也不是所有任务都值得做成Skill。我从自己试过的场景里梳理出了一个判断标准：使用频率高、流程稳定、步骤可穷举、输出格式统一。满足这四个条件的任务，做成Skill回报率最高。拿日常开发来举几类典型场景。代码审查是最合适的入门场景。审查流程相对固定：先读变更文件、检查逻辑正确性、检查边界条件、关注异常处理、最后按约定格式输出发现的问题列表。这些步骤完全可以固化下来。测试用例生成也很适合。有了明确的函数或模块，Skill可以规定必须覆盖正常分支、异常分支、边界值，并且要求输出可直接运行的测试框架代码。技术方案设计是进阶用法。可以做一个"技术方案写作助手"，强制模型先分析现状、再列候选方案、做对比表格、写推荐理由，最后输出一份结构完整的设计文档。这个场景的价值不只是省时间，更在于让团队的方案文档格式趋于统一。还有一类是团队规范类Skill，比如提交信息规范、代码风格检查、接口设计规范。这类Skill本质上是把团队的约定变成模型的行为约束，比在Review时人工盯效率高太多了。2. Skill的工作方式与关键细节2.1 一个Skill在文件系统里长什么样写Skill先要理解它在磁盘上的组织方式。以Trae的实现为例，每个Skill通常是一个独立目录，目录名就是Skill的标识。目录内部至少有一个核心指令文件，文件名一般是SKILL.md。除了这个主文件，还可以按需附带其他资源，比如references文件夹放参考资料、snippets文件夹放代码片段、scripts文件夹放辅助执行的脚本。SKILL.md是整个Skill的心脏，模型执行Skill时主要就是读取这个文件。它内部又分成两块区域：最顶部的元信息区，和下方的指令正文区。元信息区采用YAML格式，用三个短横线包裹，用来声明Skill的名称、描述、作者、版本等关键属性。指令区则直接使用Markdown书写。我在第一次上手的时候犯过一个错：把Skill目录设计得太臃肿，什么东西都往里面塞。后来发现，skill目录的最佳组织策略是"主文件完整覆盖流程，子目录只放必须的资源"。如果参考资料太多，模型读取时会分散注意力，反而降低指令遵循度。一个干净、聚焦的SKILL.md，效果远胜于一大堆花哨但冗余的辅助文件。2.2 SKILL.md的元信息：决定Skill会不会被正确触发元信息区虽然只有短短几行，但它决定了Skill能否被正确唤起。我最看重的是name和description两个字段。name要短、要唯一、要有辨识度。它相当于触发命令的名字，比如"review-code"、"gen-test"、"write-tdd-plan"。description则玄机更深。这里的核心经验是：描述内容要写"触发信号"，而不是写"功能简介"。什么意思呢？如果你想做一个前端代码审查Skill，不要笼统地写"用于代码审查"，而要写"当用户请求审查React/Vue组件代码、或者提到代码质量与潜在Bug时使用"。这样描述里面蕴含了具体的触发词和场景上下文，模型在做意图匹配时更容易选中它。还有一点容易踩坑：如果多个Skill的description描述范围过于接近，会出现模型拿不定主意调用哪一个的情况。我的做法是给每个Skill写清楚的边界条件，比如"本Skill只处理Python后端代码，前端代码请交给frontend-review-skill"，在description和指令正文里都要写。2.3 指令正文的写法：从"能跑"到"好用"写完元信息区，真正吃功夫的是指令正文。这部分直接决定Skill执行的质量。我从多次迭代中总结了一套稳定高效的写法，分享给你参考。第一步，设定清晰的角色。不必写花哨的"你是世界级专家"，但同时要定义一个明确的专业立场。比如"你是一位有十年经验的Java后端工程师，习惯面向接口编程，重视代码可读性和边界条件处理"。角色设定是为了让模型自动带入合适的知识背景和判断倾向。第二步，交代背景信息。告诉模型它手里有哪些材料可用，比如"项目位于src目录，Skill的参考文件在references子目录下，已有接口定义文档是api-spec.md"。背景信息不要写太细，否则会抢占模型的注意力。第三步，拆解执行步骤。这是我最看重的部分。Skill流程控制力强不强，就看这一步做得好不好。要像写操作手册一样，把任务拆成一个个可执行的子步骤。每个步骤一句话讲清楚，步骤之间用数字编号，最好还能标注条件分支，比如"如果修改涉及数据库表结构，则必须先执行步骤4生成迁移脚本"。这里模型的指令遵循能力非常强，只要你敢写，它会认真按步骤执行。第四步，明确输出格式。这是最容易被忽略但价值最大的一步。模型如果不约束输出格式，会给你吐一大堆散文。Skill指令里应当直接给出输出模板，用Markdown代码块包裹，明确要求严格按模板输出。比如代码审查的输出模板可以设计成：问题清单表格、严重级别、涉及文件、修改建议、验证结果。第五步，划定负面清单。即明确哪些事情禁止做。比如"禁止修改函数签名"、"禁止在测试代码中使用print调试"、"禁止引入新的第三方依赖"。负面清单可以大幅压低模型的错误倾向。2.4 触发机制：自动识别和手动调用的边界Skill的调用方式，我把它归纳成两种：被动触发和主动调用。被动触发指的是模型在理解你的自然语言请求后，自己判断该调用哪个Skill。这个过程对用户来说是无感的，你只是正常向AI提问，AI内部根据语义匹配度，自动加载对应的SKILL.md并执行。它依赖的核心就是元信息区里description写得好不好。主动调用指的是在对话输入框里用斜杠命令直接指定Skill，比如输入"/review-code"，模型就会明确知道要使用哪个Skill。主动调用的好处是确定性高，省去AI判断环节，但要求你得知道有哪些Skill可用。我个人的使用心得是：在项目初期，多用手动调用，准确可控；在Skill描述经过充分打磨后，再依赖自动触发，体验更顺畅。两种方式要搭配使用，没有绝对的优劣。3. 实操：从零开始让一个Skill跑起来3.1 先跑通一个现成Skill，建立手感我不建议一上来就写自己的Skill。先找到一个现成可用的Skill跑一遍，感受一下完整链条，再动手设计自己的，会少走很多弯路。在Trae里，你可以先找一下IDE自带的技能库或者示例Skill入口。不同版本的入口位置可能有些差异，常见的路径是侧边栏的技能管理面板，或者直接向对话框里的AI助手提问"你们有哪些示例Skill可以导入"——这个提问本身就会被IDE理解并响应。拉取一个自带技能到当前工作区后，你会看到它对应的目录结构和SKILL.md内容，这时候不要急着读完就跑，建议对照着把它逐行读一遍。看它的元信息怎么写、执行步骤怎么拆、输出格式怎么约束，这些都是下一步写Skill的活教材。我首次尝试时导入的是一个"单元测试生成"示例Skill，操作完的最大感受是：AI生成的测试更规范了，它会主动补边界用例，还会按项目已用的测试框架语法输出。这个"按项目已有框架"的行文细节，其实正是Skill中"背景信息"这一段起的作用。3.2 手写第一个自定义Skill：代码审查助手跑通示例后，就开始动手写自己的Skill。我从零写一个代码审查助手，你可以照着一步步来。第一步，创建工作目录。在Skill存放目录下建一个名为review-frontend-code的文件夹，并在里面新建SKILL.md。第二步，编写元信息区。参考格式如下：--- name: review-frontend-code description: 当用户要求审查前端Vue/React组件代码、希望检查代码质量与潜在Bug、或提到代码优化建议时使用。本Skill不适用于Python、Go等后端代码审查。 version: 1.0.0 ---第三步，编写指令正文。这一部分我直接给你一个可用的初版框架。# 角色 你是一位有五年以上经验的前端工程师，熟悉Vue 3和React 18，关注组件设计的可维护性、渲染性能与边界状态处理。 # 背景 - 当前项目目录内包含src目录，组件代码位于src/components下。 - 用户可能在对话中直接粘贴组件代码，也可能选中编辑器中的某段代码。 - 如果存在同名属性或依赖，以用户当前粘贴/选中的代码为准。 # 执行步骤 1. 确定被审查代码范围。如果用户给出了文件路径，先读取该文件；如果用户粘贴了代码，直接使用粘贴内容。 2. 分析组件逻辑，重点检查三方面：状态更新是否有意外副作用、事件监听是否清理干净、计算属性/派生状态是否与UI渲染耦合过深。 3. 检查渲染优化，判断是否存在不必要的重渲染隐患，是否存在可直接用函数式更新替代的复杂状态。 4. 检查代码风格与一致性，对照项目内已有组件的写法，识别命名、导入顺序、样式管理方式不一致之处。 5. 输出审查结论。 # 输出格式 严格按照以下模板输出，不要额外添加废话： ## 审查结论 - 整体评价：一行话给出组件可维护性和可靠性的总体判断 - 严重问题数：x / 一般问题数：x / 建议项数：x ## 严重问题 | 编号 | 位置 | 问题描述 | 修改建议 | |------|------|----------|----------| ## 一般问题 | 编号 | 位置 | 问题描述 | 修改建议 | |------|------|----------|----------| ## 优化建议 - 列出可选但非必须的改进方向，按性价比排序 # 禁止事项 - 禁止修改业务逻辑相关代码行为，只输出建议不改写用户源码 - 禁止建议引入未在项目中出现过的新依赖 - 禁止报告样式类低级问题，除非它会导致功能异常第四步，把这个Skill保存，回到对话框，用斜杠命令或自然语言触发它，粘贴一段前端组件代码，观察输出。这里有个经验：首次运行大概率不够完美，不要急着推翻重写，先检查是哪一步写得不够明确。如果是审查点没有覆盖到你关心的内容，就往相应步骤里补充具体检查项。Skill是迭代出来的，不是一次写出来的。3.3 Skill怎么和项目上下文配合Skill真正的生产力爆发点，在于它能感知项目上下文，而不是只处理对话里的信息。我还以代码审查Skill为例说明。比如项目src/components/date-picker.vue这个文件最近被修改过，你想让Skill审查它。你在Trae里选中这个文件，然后调用Skill，指令背景里不需要做任何特殊标注，因为IDE会把当前打开的上下文信息传给模型。Skill只需要写"如果用户未明确指定文件，优先读取编辑器当前打开的文件"，这条指令就能自动利用IDE的上下文能力。还有一种是引用项目内参考文档。假设项目里有一份component-style-guide.md，约定了组件代码的命名规范和样式方案。你把这个文件放进Skill目录的references文件夹下，在SKILL.md的背景信息中写"组件规范文档位于references/component-style-guide.md，执行风格审查时须对照该文档"，模型就会自行读取参照。这种"动态读取项目文件"的模式，把Skill从固定模板升级成了能感知具体项目状态的智能代理。这也是我推荐在IDE场景里做Skill应用的核心原因——上下文是这个场景的杀手锏。4. 踩坑记录与排查思路4.1 Skill静默失效：搞清触发条件我碰到过的第一个问题，是精心写好的Skill怎么都不被AI理会。明明描述里写得很清楚，结果AI回答的时候直接无视，按照普通对话模式给了个泛泛的答案。排查后发现，最常见的原因是描述里没有覆盖用户的实际表达方式。Skill的description写的是"审查前端组件"，用户说的是"帮我看下这个页面怎么这么卡"。两者语义距离太远，模型没有识别出来。解决办法是拓宽描述里的触发场景：把"页面性能问题"、"组件运行很慢"、"渲染卡顿"这类自然表达也加进去。第二个常见原因是当前Skill和其他已有Skill的边界重叠。如果同时存在多个Skill的description都覆盖了"代码优化建议"，模型会纠结甚至随机选择。我的处理方式是给每个Skill都加一句明确不适用于什么场景，把边界圈出来。4.2 大模型不听话：指令约束的优化方法有时候模型会破坏规则，比如指令里说了"禁止修改代码"，它还是输出了一整段修改后的代码。这不是模型笨，而是指令表达本身存在歧义。经典的解决方法是做指令的"正向约束"和"反向排除"。正向约束把期望的行为写具体，比如"你的输出只能包含问题描述与建议，不要包含修改后的代码片段"；反向排除把不希望看到的东西点名，比如"如果确实需要给出代码示意，用伪代码描述，不要输出完整实现类代码"。还有一种情况是模型"中间态逃逸"，即它没有严格按照步骤顺序执行，而是跳过某些步骤直接给结论。对此我习惯在指令末尾加一条质量管理规则，比如"执行完毕后，对照前面步骤逐一检查输出是否遗漏，如果遗漏请补充后重新完整输出"。相当于让模型在输出前做一次自我复核。4.3 多人协作时Skill怎么沉淀Skill做出来后，怎么在团队里推广和维护，是另一个高频问题。我建议把Skill目录放到项目仓库里，纳入版本管理。这样团队成员拉取仓库后就能获得相同的一套Skill，随时使用和反馈。迭代模式也要约定好。我见过比较稳妥的做法是：谁提出修改谁负责更新SKILL.md并在description里加上版本说明；重大变更要通过团队评审合入主干。Skill本身是代码和数据，也应当像代码一样走变更评审流程。还需要给Skill写配套的使用文档。不是每个团队成员都有耐心去读SKILL.md源码，有了一份几百字的说明文档，写清楚"什么场景用哪个Skill、触发词是什么、常见输出什么样"，团队上手成本会大幅降低。4.4 常见问题速查表现象可能原因解决办法Skill完全没有被触发description里的触发词与实际问法不匹配收集用户常用表达，扩充触发场景描述触发了但执行混乱指令步骤顺序不明确拆步骤，给编号，明确条件分支输出格式乱七八糟未给出输出模板或模板约束力不足在指令中用代码块给出必守模板模型跳过某些步骤步骤之间存在语义跳转或指令优先级不明增加"依次执行以下步骤，不得跳跃"引用的参考文件没生效背景信息里未写明引用路径在背景中明确"参考文件位于xx路径，必须读取"多个Skill误触发多个Skill描述边界重叠给各Skill增加不适用边界说明结尾：最后想说的几句经验实操到目前这个阶段，我最大的体会是Skill的价值不在于某个神奇指令，而在于帮你把重复劳动结构化。花一个下午把团队日常开发里最高频的三五个场景做成Skill，之后每一次调用都是在吃这半天投入的红利。我建议你先从最痛的一个场景开始，比如代码审查或测试用例生成，写出初版后用真实任务去砸它，记录模型每次跑偏的地方，然后回头改指令里的步骤和约束。迭代三五次之后，你会明显感到AI产出质量的提升。这个内容后续还可以继续扩展的方向很多：把Skill做成团队内部的能力市场、给Skill加多级校验流程、甚至用Skill去编排多个AI代理协同完成复杂任务。但所有扩展之前，先把基本功打扎实——写出一个稳定好用的SKILL.md。
这个系列写到第14篇，我聊点真正能提效的东西——大模型Skills应用。之前几篇要么在讲模型能力边界，要么在讲上下文工程，这次把视角落到一个具体场景：在Trae这款AI原生IDE里，怎么把Skill从"听说过"变成"天天用"。Skill这个概念最近在大模型应用层很火，本质上它就是把一段精心设计的提示词、一套固定的工作流程、若干配套参考文件打包成一个可复用的"能力单元"。你可以把它理解成给大模型装上一个岗位SOP，让它不用你每次重复交代，就能按规范把活干完。这篇文章适合正在用AI辅助编程、想沉淀个人工作流、或者打算在团队里统一AI协作方式的开发者。我会从Skill的底层逻辑、目录结构、编写规范讲到完整实操和踩坑记录。1. 先想清楚：Skill到底在解决什么问题1.1 一个Skill的本质：把提示词变成可复用的技能很多人第一次听说Skill，会觉得它不过是一个"高级提示词模板"。这个理解没错，但只说对了一半。普通提示词模板是静态文本，你发给大模型，它读完就完了；Skill则是一个有结构、有依赖、可触发、可复用的完整工作包。它不光告诉大模型"你要做什么"，还规定了"先看哪些文件、按什么顺序判断、输出什么格式、哪些事情绝对不能做"。我打个比方。你让一个实习生帮你做代码审查，如果他只听过一句"帮我看下代码"，大概率会走神，一会儿看逻辑、一会儿挑格式、一会儿又去纠结变量命名。但如果你给他一份《代码审查SOP手册》，里面写清楚了审查范围、检查清单、输出模板、必须引用哪些文档，他的产出质量就会稳定得多。Skill就是这份SOP手册，而且大模型比实习生更听话——只要指令写得足够明确，它会严格照做。这里有三个关键技术点值得注意。第一，Skill以Markdown文件为载体。这个选择不是随意的，大模型的训练语料里Markdown格式占据绝对主导，模型对标题、列表、引用、代码块的语义结构理解成本最低。你用README风格写指令，模型执行起来最顺手，比喂它一堆JSON配置要自然得多。第二，Skill内部可以附带多个关联文件，比如参考文档、示例代码、历史模板。这些文件通过相对路径被主指令文件引用，相当于给模型提供了"补充阅读材料"。正因为有了外部引用能力，Skill处理的复杂度远高于单段提示词。第三，Skill有元信息区，用来声明自己的名字、用途、触发场景。这就像给函数写了一个清晰的函数签名，IDE和模型可以根据你的自然语言描述，自动判断该调用哪个Skill。1.2 为什么选Trae这个载体来做Skill应用Skill这个概念并不局限于Trae，很多工具链都在做类似的事情。但Trae作为一款面向AI编程场景的IDE，它的天然优势在于拥有完整的代码上下文感知能力——它能获取你当前打开的文件、选中代码区域、项目目录结构、编辑器的运行状态。这意味着Skill指令里可以写"读取当前活动文件的函数列表"、"分析选中代码段的时间复杂度"，模型真的能做到，因为它有IDE层面传来的实时上下文。举个例子。你写一个"数据库迁移脚本生成"的Skill，在通用聊天助手里面，你得手动把表结构、现有迁移文件的历史记录全部粘贴进去。而在Trae里，Skill可以引用项目目录下的schema文件、迁移目录下的历史脚本，模型自己会去读。这种上下文接近能力，让Skill从"玩具"变成了"生产力工具"。另外，Trae把Skill入口放在IDE工作区内，和代码编辑、版本管理、终端命令在同一个界面上，使用链条很短。对我来说，注意力可以始终保持在编码上下文里，不用切换到另一个对话框去复制粘贴。对于一个研发团队，后续把Skill目录纳入版本管理、跟随项目仓库分发，也是顺理成章的事。所以选Trae不是因为它Skill功能发明得早，而是因为在"编码场景下做技能化封装"这件事上，它给到的工作流最完整。1.3 哪些场景值得优先做成SkillSkill不是万能的，也不是所有任务都值得做成Skill。我从自己试过的场景里梳理出了一个判断标准：使用频率高、流程稳定、步骤可穷举、输出格式统一。满足这四个条件的任务，做成Skill回报率最高。拿日常开发来举几类典型场景。代码审查是最合适的入门场景。审查流程相对固定：先读变更文件、检查逻辑正确性、检查边界条件、关注异常处理、最后按约定格式输出发现的问题列表。这些步骤完全可以固化下来。测试用例生成也很适合。有了明确的函数或模块，Skill可以规定必须覆盖正常分支、异常分支、边界值，并且要求输出可直接运行的测试框架代码。技术方案设计是进阶用法。可以做一个"技术方案写作助手"，强制模型先分析现状、再列候选方案、做对比表格、写推荐理由，最后输出一份结构完整的设计文档。这个场景的价值不只是省时间，更在于让团队的方案文档格式趋于统一。还有一类是团队规范类Skill，比如提交信息规范、代码风格检查、接口设计规范。这类Skill本质上是把团队的约定变成模型的行为约束，比在Review时人工盯效率高太多了。2. Skill的工作方式与关键细节2.1 一个Skill在文件系统里长什么样写Skill先要理解它在磁盘上的组织方式。以Trae的实现为例，每个Skill通常是一个独立目录，目录名就是Skill的标识。目录内部至少有一个核心指令文件，文件名一般是SKILL.md。除了这个主文件，还可以按需附带其他资源，比如references文件夹放参考资料、snippets文件夹放代码片段、scripts文件夹放辅助执行的脚本。SKILL.md是整个Skill的心脏，模型执行Skill时主要就是读取这个文件。它内部又分成两块区域：最顶部的元信息区，和下方的指令正文区。元信息区采用YAML格式，用三个短横线包裹，用来声明Skill的名称、描述、作者、版本等关键属性。指令区则直接使用Markdown书写。我在第一次上手的时候犯过一个错：把Skill目录设计得太臃肿，什么东西都往里面塞。后来发现，skill目录的最佳组织策略是"主文件完整覆盖流程，子目录只放必须的资源"。如果参考资料太多，模型读取时会分散注意力，反而降低指令遵循度。一个干净、聚焦的SKILL.md，效果远胜于一大堆花哨但冗余的辅助文件。2.2 SKILL.md的元信息：决定Skill会不会被正确触发元信息区虽然只有短短几行，但它决定了Skill能否被正确唤起。我最看重的是name和description两个字段。name要短、要唯一、要有辨识度。它相当于触发命令的名字，比如"review-code"、"gen-test"、"write-tdd-plan"。description则玄机更深。这里的核心经验是：描述内容要写"触发信号"，而不是写"功能简介"。什么意思呢？如果你想做一个前端代码审查Skill，不要笼统地写"用于代码审查"，而要写"当用户请求审查React/Vue组件代码、或者提到代码质量与潜在Bug时使用"。这样描述里面蕴含了具体的触发词和场景上下文，模型在做意图匹配时更容易选中它。还有一点容易踩坑：如果多个Skill的description描述范围过于接近，会出现模型拿不定主意调用哪一个的情况。我的做法是给每个Skill写清楚的边界条件，比如"本Skill只处理Python后端代码，前端代码请交给frontend-review-skill"，在description和指令正文里都要写。2.3 指令正文的写法：从"能跑"到"好用"写完元信息区，真正吃功夫的是指令正文。这部分直接决定Skill执行的质量。我从多次迭代中总结了一套稳定高效的写法，分享给你参考。第一步，设定清晰的角色。不必写花哨的"你是世界级专家"，但同时要定义一个明确的专业立场。比如"你是一位有十年经验的Java后端工程师，习惯面向接口编程，重视代码可读性和边界条件处理"。角色设定是为了让模型自动带入合适的知识背景和判断倾向。第二步，交代背景信息。告诉模型它手里有哪些材料可用，比如"项目位于src目录，Skill的参考文件在references子目录下，已有接口定义文档是api-spec.md"。背景信息不要写太细，否则会抢占模型的注意力。第三步，拆解执行步骤。这是我最看重的部分。Skill流程控制力强不强，就看这一步做得好不好。要像写操作手册一样，把任务拆成一个个可执行的子步骤。每个步骤一句话讲清楚，步骤之间用数字编号，最好还能标注条件分支，比如"如果修改涉及数据库表结构，则必须先执行步骤4生成迁移脚本"。这里模型的指令遵循能力非常强，只要你敢写，它会认真按步骤执行。第四步，明确输出格式。这是最容易被忽略但价值最大的一步。模型如果不约束输出格式，会给你吐一大堆散文。Skill指令里应当直接给出输出模板，用Markdown代码块包裹，明确要求严格按模板输出。比如代码审查的输出模板可以设计成：问题清单表格、严重级别、涉及文件、修改建议、验证结果。第五步，划定负面清单。即明确哪些事情禁止做。比如"禁止修改函数签名"、"禁止在测试代码中使用print调试"、"禁止引入新的第三方依赖"。负面清单可以大幅压低模型的错误倾向。2.4 触发机制：自动识别和手动调用的边界Skill的调用方式，我把它归纳成两种：被动触发和主动调用。被动触发指的是模型在理解你的自然语言请求后，自己判断该调用哪个Skill。这个过程对用户来说是无感的，你只是正常向AI提问，AI内部根据语义匹配度，自动加载对应的SKILL.md并执行。它依赖的核心就是元信息区里description写得好不好。主动调用指的是在对话输入框里用斜杠命令直接指定Skill，比如输入"/review-code"，模型就会明确知道要使用哪个Skill。主动调用的好处是确定性高，省去AI判断环节，但要求你得知道有哪些Skill可用。我个人的使用心得是：在项目初期，多用手动调用，准确可控；在Skill描述经过充分打磨后，再依赖自动触发，体验更顺畅。两种方式要搭配使用，没有绝对的优劣。3. 实操：从零开始让一个Skill跑起来3.1 先跑通一个现成Skill，建立手感我不建议一上来就写自己的Skill。先找到一个现成可用的Skill跑一遍，感受一下完整链条，再动手设计自己的，会少走很多弯路。在Trae里，你可以先找一下IDE自带的技能库或者示例Skill入口。不同版本的入口位置可能有些差异，常见的路径是侧边栏的技能管理面板，或者直接向对话框里的AI助手提问"你们有哪些示例Skill可以导入"——这个提问本身就会被IDE理解并响应。拉取一个自带技能到当前工作区后，你会看到它对应的目录结构和SKILL.md内容，这时候不要急着读完就跑，建议对照着把它逐行读一遍。看它的元信息怎么写、执行步骤怎么拆、输出格式怎么约束，这些都是下一步写Skill的活教材。我首次尝试时导入的是一个"单元测试生成"示例Skill，操作完的最大感受是：AI生成的测试更规范了，它会主动补边界用例，还会按项目已用的测试框架语法输出。这个"按项目已有框架"的行文细节，其实正是Skill中"背景信息"这一段起的作用。3.2 手写第一个自定义Skill：代码审查助手跑通示例后，就开始动手写自己的Skill。我从零写一个代码审查助手，你可以照着一步步来。第一步，创建工作目录。在Skill存放目录下建一个名为review-frontend-code的文件夹，并在里面新建SKILL.md。第二步，编写元信息区。参考格式如下：--- name: review-frontend-code description: 当用户要求审查前端Vue/React组件代码、希望检查代码质量与潜在Bug、或提到代码优化建议时使用。本Skill不适用于Python、Go等后端代码审查。 version: 1.0.0 ---第三步，编写指令正文。这一部分我直接给你一个可用的初版框架。# 角色 你是一位有五年以上经验的前端工程师，熟悉Vue 3和React 18，关注组件设计的可维护性、渲染性能与边界状态处理。 # 背景 - 当前项目目录内包含src目录，组件代码位于src/components下。 - 用户可能在对话中直接粘贴组件代码，也可能选中编辑器中的某段代码。 - 如果存在同名属性或依赖，以用户当前粘贴/选中的代码为准。 # 执行步骤 1. 确定被审查代码范围。如果用户给出了文件路径，先读取该文件；如果用户粘贴了代码，直接使用粘贴内容。 2. 分析组件逻辑，重点检查三方面：状态更新是否有意外副作用、事件监听是否清理干净、计算属性/派生状态是否与UI渲染耦合过深。 3. 检查渲染优化，判断是否存在不必要的重渲染隐患，是否存在可直接用函数式更新替代的复杂状态。 4. 检查代码风格与一致性，对照项目内已有组件的写法，识别命名、导入顺序、样式管理方式不一致之处。 5. 输出审查结论。 # 输出格式 严格按照以下模板输出，不要额外添加废话： ## 审查结论 - 整体评价：一行话给出组件可维护性和可靠性的总体判断 - 严重问题数：x / 一般问题数：x / 建议项数：x ## 严重问题 | 编号 | 位置 | 问题描述 | 修改建议 | |------|------|----------|----------| ## 一般问题 | 编号 | 位置 | 问题描述 | 修改建议 | |------|------|----------|----------| ## 优化建议 - 列出可选但非必须的改进方向，按性价比排序 # 禁止事项 - 禁止修改业务逻辑相关代码行为，只输出建议不改写用户源码 - 禁止建议引入未在项目中出现过的新依赖 - 禁止报告样式类低级问题，除非它会导致功能异常第四步，把这个Skill保存，回到对话框，用斜杠命令或自然语言触发它，粘贴一段前端组件代码，观察输出。这里有个经验：首次运行大概率不够完美，不要急着推翻重写，先检查是哪一步写得不够明确。如果是审查点没有覆盖到你关心的内容，就往相应步骤里补充具体检查项。Skill是迭代出来的，不是一次写出来的。3.3 Skill怎么和项目上下文配合Skill真正的生产力爆发点，在于它能感知项目上下文，而不是只处理对话里的信息。我还以代码审查Skill为例说明。比如项目src/components/date-picker.vue这个文件最近被修改过，你想让Skill审查它。你在Trae里选中这个文件，然后调用Skill，指令背景里不需要做任何特殊标注，因为IDE会把当前打开的上下文信息传给模型。Skill只需要写"如果用户未明确指定文件，优先读取编辑器当前打开的文件"，这条指令就能自动利用IDE的上下文能力。还有一种是引用项目内参考文档。假设项目里有一份component-style-guide.md，约定了组件代码的命名规范和样式方案。你把这个文件放进Skill目录的references文件夹下，在SKILL.md的背景信息中写"组件规范文档位于references/component-style-guide.md，执行风格审查时须对照该文档"，模型就会自行读取参照。这种"动态读取项目文件"的模式，把Skill从固定模板升级成了能感知具体项目状态的智能代理。这也是我推荐在IDE场景里做Skill应用的核心原因——上下文是这个场景的杀手锏。4. 踩坑记录与排查思路4.1 Skill静默失效：搞清触发条件我碰到过的第一个问题，是精心写好的Skill怎么都不被AI理会。明明描述里写得很清楚，结果AI回答的时候直接无视，按照普通对话模式给了个泛泛的答案。排查后发现，最常见的原因是描述里没有覆盖用户的实际表达方式。Skill的description写的是"审查前端组件"，用户说的是"帮我看下这个页面怎么这么卡"。两者语义距离太远，模型没有识别出来。解决办法是拓宽描述里的触发场景：把"页面性能问题"、"组件运行很慢"、"渲染卡顿"这类自然表达也加进去。第二个常见原因是当前Skill和其他已有Skill的边界重叠。如果同时存在多个Skill的description都覆盖了"代码优化建议"，模型会纠结甚至随机选择。我的处理方式是给每个Skill都加一句明确不适用于什么场景，把边界圈出来。4.2 大模型不听话：指令约束的优化方法有时候模型会破坏规则，比如指令里说了"禁止修改代码"，它还是输出了一整段修改后的代码。这不是模型笨，而是指令表达本身存在歧义。经典的解决方法是做指令的"正向约束"和"反向排除"。正向约束把期望的行为写具体，比如"你的输出只能包含问题描述与建议，不要包含修改后的代码片段"；反向排除把不希望看到的东西点名，比如"如果确实需要给出代码示意，用伪代码描述，不要输出完整实现类代码"。还有一种情况是模型"中间态逃逸"，即它没有严格按照步骤顺序执行，而是跳过某些步骤直接给结论。对此我习惯在指令末尾加一条质量管理规则，比如"执行完毕后，对照前面步骤逐一检查输出是否遗漏，如果遗漏请补充后重新完整输出"。相当于让模型在输出前做一次自我复核。4.3 多人协作时Skill怎么沉淀Skill做出来后，怎么在团队里推广和维护，是另一个高频问题。我建议把Skill目录放到项目仓库里，纳入版本管理。这样团队成员拉取仓库后就能获得相同的一套Skill，随时使用和反馈。迭代模式也要约定好。我见过比较稳妥的做法是：谁提出修改谁负责更新SKILL.md并在description里加上版本说明；重大变更要通过团队评审合入主干。Skill本身是代码和数据，也应当像代码一样走变更评审流程。还需要给Skill写配套的使用文档。不是每个团队成员都有耐心去读SKILL.md源码，有了一份几百字的说明文档，写清楚"什么场景用哪个Skill、触发词是什么、常见输出什么样"，团队上手成本会大幅降低。4.4 常见问题速查表现象可能原因解决办法Skill完全没有被触发description里的触发词与实际问法不匹配收集用户常用表达，扩充触发场景描述触发了但执行混乱指令步骤顺序不明确拆步骤，给编号，明确条件分支输出格式乱七八糟未给出输出模板或模板约束力不足在指令中用代码块给出必守模板模型跳过某些步骤步骤之间存在语义跳转或指令优先级不明增加"依次执行以下步骤，不得跳跃"引用的参考文件没生效背景信息里未写明引用路径在背景中明确"参考文件位于xx路径，必须读取"多个Skill误触发多个Skill描述边界重叠给各Skill增加不适用边界说明结尾：最后想说的几句经验实操到目前这个阶段，我最大的体会是Skill的价值不在于某个神奇指令，而在于帮你把重复劳动结构化。花一个下午把团队日常开发里最高频的三五个场景做成Skill，之后每一次调用都是在吃这半天投入的红利。我建议你先从最痛的一个场景开始，比如代码审查或测试用例生成，写出初版后用真实任务去砸它，记录模型每次跑偏的地方，然后回头改指令里的步骤和约束。迭代三五次之后，你会明显感到AI产出质量的提升。这个内容后续还可以继续扩展的方向很多：把Skill做成团队内部的能力市场、给Skill加多级校验流程、甚至用Skill去编排多个AI代理协同完成复杂任务。但所有扩展之前，先把基本功打扎实——写出一个稳定好用的SKILL.md。