1. 从零理解 Skill它到底解决了什么问题很多人第一次接触 Skill 这个概念时会下意识把它和 Prompt 混为一谈。我刚开始也是这样觉得无非就是写一段更长的提示词让模型按格式输出罢了。但真正用起来才发现Skill 和 Prompt 的关系更像是菜谱和今天想吃什么的关系——Prompt 是你当下提出的具体请求而 Skill 是一套被固化下来、可反复调用、带明确输入输出约定的能力封装。举个实际场景。假设你经常需要把一份杂乱的项目需求文档整理成结构化的任务清单。如果每次都靠临时写 Prompt你会发现自己反复在调整措辞这次强调按优先级排序下次忘了说标注依赖关系再下次输出的格式又变了。而 Skill 的思路是把这套整理逻辑、输出格式、边界条件全部写进一个 Markdown 文件里形成一个稳定的能力单元。之后你只需要说用任务整理 Skill 处理这份文档就能得到一致的结果。这就是 Skill 的核心价值把一次性的、易漂移的 Prompt 交互沉淀为可复用、可版本管理、可组合的能力模块。它特别适合三类人一是需要批量处理同类任务的运营和研究人员二是想把个人工作流标准化的开发者三是团队协作中需要统一输出规范的场景。从技术载体上看目前绝大多数 Skill 都是以 Markdown 文件.md的形式存在的。为什么是 Markdown 而不是 JSON 或 YAML我的理解是Markdown 天然适合人机共读——它既有结构标题、列表、代码块又能容纳大段自然语言描述模型读起来不费劲人维护起来也直观。你完全可以用 VS Code 打开一个 .md 文件边写边预览改完保存就能用。提示Skill 文件不是越长越好。我见过有人把一个 Skill 写成三千字结果模型反而抓不住重点。核心逻辑控制在 500 到 1500 字之间效果通常最稳。理解了这一层后面的创建、修改、调试才有意义。接下来我会按实际操作顺序把整个流程拆开讲清楚。2. 创建 Skill 前的准备工作环境与工具选型2.1 为什么我推荐用 VS Code 编辑 Markdown 文件创建 Skill 的第一步是选一个顺手的 Markdown 编辑器。市面上的选择不少Typora、Obsidian、VS Code 都能干这活。但我实测下来VS Code 在 Skill 编写这个场景里有几个不可替代的优势。第一是实时预览。Skill 文件里经常要写输出格式示例比如请按以下结构输出后面跟一段代码块。用 VS Code 的CtrlShiftV打开预览你能立刻看到渲染效果确认格式没写错。第二是多文件管理。当你积累到十几个 Skill 时用 VS Code 的侧边栏可以按文件夹分类比在单个编辑器里翻找高效得多。第三是插件生态。Markdown All in One 这个插件能自动生成目录、格式化表格写复杂 Skill 时省不少事。如果你之前没用过 VS Code 编辑 .md 文件操作路径很简单安装 VS Code新建一个后缀为.md的文件直接开始写。不需要任何额外配置它开箱就能识别 Markdown 语法并高亮显示。2.2 目录结构怎么规划才不会乱我踩过的第一个坑就是所有 Skill 文件全堆在一个文件夹里。用了两个月后文件名从task.md变成task_v2.md、task_final.md、task_really_final.md彻底失控。后来我改成按用途分目录清爽了很多skills/ writing/ # 写作类 summary.md rewrite.md analysis/ # 分析类 task-breakdown.md ># 会议纪要整理 ## 描述 将口语化的会议记录整理为结构化的决议与待办清单。 ## 触发条件 当用户提供一段会议记录并要求整理时使用。 ## 执行步骤 1. 通读全文忽略寒暄、重复和语气词。 2. 识别所有包含决定确定安排负责等动作词的句子。 3. 对每个任务抽取任务内容、负责人、截止时间。 4. 若某项信息缺失标注为待确认不要编造。 ## 输出格式 按以下表格输出不要添加额外解释 | 任务内容 | 负责人 | 截止时间 | |---------|--------|---------| | ... | ... | ... |这个文件不到 300 字但已经是一个完整可用的 Skill。关键在于每一步都是可执行的动作而不是模糊的描述。比如识别包含动作词的句子就比理解会议内容要明确得多。3.3 写完后立刻做一次冒烟测试Skill 写完不要急着投入使用先拿一个最简单的例子跑一遍。我管这叫冒烟测试——就像新硬件上电前先看看冒不冒烟。测试方法找一段三五行的会议记录手动喂给模型看输出是否符合预期格式。如果格式对了但内容漏了说明执行步骤不够细如果格式乱了说明输出格式部分写得不够强硬。我一般会加一句严格按以下格式输出不要添加任何额外文字能显著提升格式稳定性。注意测试时一定要用真实场景的边角案例比如一段没有任何任务的会议记录。很多 Skill 在正常输入下表现良好一遇到空输入就崩溃输出一堆编造的内容。4. 修改与迭代 Skill让能力越用越准4.1 什么时候该改 Skill什么时候该新建用了一段时间后你会发现有些 Skill 需要调整。但这里有个判断是修改现有 Skill还是新建一个我的原则是看核心意图是否改变。如果只是输出格式微调、补充几个边界条件那就改现有的。如果处理逻辑发生了根本变化比如原来做摘要、现在要做全文翻译那就新建一个。硬把两个不同意图塞进一个 Skill只会让文件越来越臃肿模型执行时也容易混淆。4.2 修改时的版本管理土办法Skill 文件也是代码改了之后要能回退。我不推荐上来就用 Git对非开发者门槛太高。一个简单的土办法是每次大改之前把原文件复制一份文件名加上日期后缀比如summary-20240115.md。放在一个archive/子目录里。这样既保留了历史版本又不会污染主目录。等你熟悉了之后再迁移到 Git 管理也不迟。核心是先养成改前备份的习惯这个习惯比用什么工具重要得多。4.3 根据失败案例反向优化Skill 迭代最有效的方法是收集失败案例。我专门建了一个failures.md文件每次 Skill 输出不符合预期时就把输入和错误输出记下来。攒够五六个案例后回头分析共性是某类输入没覆盖到还是某个步骤的措辞有歧义比如我之前有个代码审查Skill总是漏掉对异常处理的检查。翻看失败案例后发现是我在执行步骤里只写了检查逻辑正确性没明确提异常处理。补上一句重点检查 try-catch 覆盖和边界条件之后问题就解决了。这种基于真实失败案例的反向优化比凭空想象要高效得多。5. Skill 与 Prompt、Agent 的边界在哪里5.1 Skill 和 Prompt 的本质区别前面提过一点这里展开说透。Prompt 是一次性指令Skill 是可复用能力。但更深层的区别在于Prompt 通常针对单次对话上下文一换就失效Skill 是独立文件可以被不同的对话、不同的工具反复加载。打个比方Prompt 像是你临时跟同事口头交代一件事Skill 像是你写了一份标准操作手册放在共享盘里谁需要谁去取。手册可以更新可以版本管理可以被多人引用——这是 Prompt 做不到的。5.2 Skill 和 Agent 的协作关系Agent 是能自主规划、调用工具、多步执行的智能体。Skill 则是 Agent 可以调用的技能包。一个 Agent 可能同时挂载十几个 Skill根据任务需要选择调用哪个。理解这个关系很重要因为它决定了你写 Skill 时的定位Skill 不需要自己规划全局只需要把一件事做到极致。比如一个数据清洗Skill不用管数据从哪来、清洗完给谁用只管把清洗这一步做标准。规划的事交给 Agent执行的事交给 Skill各司其职。5.3 常见误区把 Skill 写成万能助手我见过最常见的错误就是有人试图写一个什么都能干的 Skill。结果文件里塞了几十个不相关的功能模型执行时经常串台。正确的做法是一个 Skill 只干一件事需要多个能力时写多个 Skill让上层去组合。这个原则和写函数是一样的单一职责。一个函数只做一件事一个 Skill 也只做一件事。这样调试容易、复用方便、组合灵活。6. 实战中踩过的坑与排查思路6.1 输出格式不稳定的三种原因Skill 用起来最让人头疼的就是输出格式时好时坏。我排查下来原因基本逃不出这三种第一种是格式描述不够具体。你写用表格输出模型可能给你三种不同列数的表格。要写成用三列表格输出列名依次为任务、负责人、截止时间。第二种是执行步骤和输出格式脱节。步骤里说要抽取四个字段输出格式里只列了三个模型就会自己发挥。两者必须严格对应。第三种是缺少负面约束。模型天生喜欢加解释、加总结。如果你不明确说不要添加额外文字它就会在表格前后各加一段废话。负面约束和正面要求同样重要。6.2 Skill 加载后不生效的排查链路有时候你明明写好了 Skill调用时却感觉没起作用。我的排查顺序是这样的确认文件被正确加载检查文件路径是否在工具的扫描范围内文件名是否符合规范。确认触发条件匹配你的调用语句是否命中了 Skill 里写的触发条件如果触发条件写得太窄可能根本没被激活。确认没有冲突同时加载了多个 Skill 时可能互相干扰。先禁用其他 Skill单独测试这一个。确认内容没有语法错误Markdown 格式错误比如代码块没闭合会导致解析失败整个 Skill 失效。这个链路我走过好几遍绝大多数问题都出在第一步和第二步——文件没放对位置或者触发条件写得太死。6.3 中文 Skill 的编码陷阱用中文写 Skill 时有个隐蔽的坑文件编码。如果保存成了 GBK 而不是 UTF-8某些工具读取时会乱码导致 Skill 内容变成一堆问号。VS Code 默认是 UTF-8但如果你从别处复制内容过来最好在右下角确认一下编码格式。另一个中文相关的坑是全角标点。中文输入法下打出的逗号、冒号是全角的在某些解析场景里会被当成普通字符而非语法符号。写 Skill 里的结构化内容比如字段名、格式标记时建议切到英文输入法用半角标点。7. 让 Skill 越用越顺的几个习惯7.1 建立自己的 Skill 索引当 Skill 数量超过十个找起来就开始费劲了。我的做法是在skills/目录下放一个README.md用表格列出所有 Skill 的名称、用途、最后修改日期。每次新增或修改后顺手更新一行成本极低但查找效率提升明显。Skill 名称用途最后修改summary长文摘要2024-01-15task-breakdown任务拆解2024-01-20code-review代码审查2024-01-227.2 定期清理和合并每隔一两个月我会翻一遍所有 Skill做两件事删掉三个月没用过的合并功能高度重叠的。Skill 不是越多越好维护成本会随着数量上升。保持精简每个都常用、都好用比囤一堆强。7.3 把调试经验写回 Skill 里每次解决一个 Skill 的问题后我会把解决思路用注释的形式写回文件里。比如在输出格式部分加一行!-- 注意不要用全角冒号会导致解析失败 --。这些注释不影响执行但下次修改时能提醒自己别重蹈覆辙。日积月累这些注释就成了这个 Skill 的病历本价值很高。我在实际使用中最大的体会是Skill 这东西写出来只是开始真正的价值在于持续迭代。一个用了半年、改过十几版的 Skill和一个刚写出来的 Skill稳定性完全不是一个量级。所以别追求一次写完美先写出来用起来在用的过程中慢慢磨这才是正道。
