1. 先搞明白 Skill 到底是个什么东西1.1 从一个让人抓狂的场景说起你肯定遇到过这种情况每次让 AI 帮你写周报它都像第一次上班一样你得从头告诉它格式是什么、语气要多正式、哪些数据必须放进去、哪些废话不能写。下一次再让它写它又忘了你又得重新说一遍。来回折腾三四次比自己动手写还累。Skill 就是为了解决这个问题而存在的。你可以把它理解成给 AI 写的一份“岗位操作手册”——把某个任务的标准流程、注意事项、输出格式全部写进一个文件里AI 每次执行这个任务时都会先读这份手册然后按照你定好的规矩来干活。不用重复交代不用反复调教一次写好次次管用。用更直白的话说Skill 就是把你的经验和方法论固化下来让 AI 变成一个按你标准作业的熟练工。它不是什么高深的技术本质上就是一个结构化的 Markdown 文件里面写清楚了“做什么、怎么做、做成什么样”。1.2 Skill 和 Agent 到底有什么区别这是被问得最多的问题我用一个类比来解释。想象你开了一家餐厅。Agent 就像你雇的一个全能店长他能自己决定今天进什么货、怎么排班、遇到客人投诉怎么处理有很强的自主决策能力。而Skill 更像是你贴在厨房墙上的菜谱上面写着“宫保鸡丁鸡胸肉切丁油温七成热先炒花生米再下鸡丁最后勾芡出锅”。厨师照着做就行不需要自己发挥。所以两者的核心区别在于Agent 强调自主规划和决策它能拆解复杂任务、调用不同工具、根据中间结果调整策略。Skill 强调标准化执行它是一套预设好的流程和知识AI 按部就班地执行不需要“思考人生”。在实际使用中两者往往是配合的。Agent 负责“决定做什么”Skill 负责“告诉它怎么做”。比如你让 AI 帮你做一份竞品分析报告Agent 会规划先搜集资料、再对比分析、最后输出报告而“竞品分析”这个 Skill 则规定了分析的维度、数据来源的优先级、报告的模板格式。1.3 为什么现在大家都在聊 Skill原因很简单大模型的通用能力已经足够强了但“通用”恰恰是它最大的问题。它什么都会一点但什么都不够精。你让它写代码它能写但不一定符合你团队的代码规范你让它做数据分析它能做但未必用你习惯的那套指标体系。Skill 的出现让普通用户也能把大模型“调教”成自己领域的专家。你不需要会训练模型不需要懂微调技术只需要会写清楚一份操作文档就能让 AI 在你的专业场景下表现得像个老手。这个门槛低到几乎所有人都能上手但效果提升却非常明显。提示Skill 的核心价值不在于让 AI 变聪明而在于让 AI 变“听话”。它解决的是“我知道该怎么做但每次都要跟 AI 重复说”的效率问题。2. 怎么找到好用的 Skill渠道与筛选方法2.1 常见的 Skill 获取渠道目前 Skill 的生态还在快速成长期获取渠道主要有这么几类官方市场和社区仓库是最主流的来源。很多 AI 编程工具和平台都开始内置 Skill 市场你可以直接浏览、搜索、一键安装。社区仓库则通常是开源项目的形式托管在代码平台上需要手动下载和配置。社区分享和论坛是另一个重要渠道。很多资深用户会把自己写的 Skill 分享出来附带详细的使用说明和效果对比。这类 Skill 往往针对特定场景打磨得很精细比如专门用于论文写作的、专门用于代码审查的、专门用于数据分析报告生成的。自己动手写其实是最推荐的路径。原因后面会详细说但核心逻辑是别人的 Skill 再好也不一定完全匹配你的工作流程和输出标准。自己写虽然前期投入一些时间但后续的回报是持续的。2.2 筛选 Skill 的几个硬标准面对一个 Skill怎么判断它值不值得用我总结了几个实用的判断维度判断维度好的信号需要警惕的信号描述清晰度明确说明适用场景和输入输出描述模糊什么都想做文件结构有清晰的步骤拆解和示例只有一段笼统的指令更新频率近期有维护和更新很久没更新可能已失效用户反馈有真实的使用评价和案例没有任何反馈信息复杂度聚焦单一任务逻辑清晰试图解决太多问题臃肿我个人的经验是一个 Skill 如果不能用一句话说清楚它是干什么的那它大概率不好用。好的 Skill 一定是聚焦的、具体的、有明确边界的。2.3 安装和配置的基本流程不同平台的安装方式不太一样但大体流程是相似的。以常见的 AI 编程工具为例通常的步骤是找到 Skill 文件一般是一个文件夹里面包含核心的 Markdown 文件和可能的辅助脚本把文件夹放到指定的 Skill 目录下在配置文件中注册这个 Skill重启工具或重新加载配置在对话中通过特定指令触发这个 Skill注意不同工具对 Skill 的目录结构和命名规范要求不同安装前一定要看清楚说明文档。我见过太多人因为文件夹名字写错了导致 Skill 死活加载不出来。3. 自己动手写一个 Skill从零到能用3.1 先想清楚什么任务值得写成 Skill不是所有事情都值得写成 Skill。我的判断标准是三个字重复性。如果一个任务你每周至少要做一次而且每次的流程和标准基本一致那就值得写成 Skill。比如每周的周报/月报生成代码审查的检查清单数据分析报告的固定模板会议纪要的整理规范特定格式的文档转换反过来如果任务每次都不一样、需要大量临场判断、或者一年才做一次那就不太值得投入时间写 Skill。3.2 SKILL.md 的核心结构一个 Skill 的核心就是一个 Markdown 文件通常命名为SKILL.md。它的结构不需要很复杂但有几个关键部分必须写清楚第一部分元信息。包括 Skill 的名称、版本、适用场景的简要描述。这部分是给人和 AI 看的“标签”帮助快速定位。第二部分触发条件。说明什么情况下应该使用这个 Skill。比如“当用户要求生成周报时”“当需要审查代码质量时”。这部分写得越具体AI 判断得越准确。第三部分执行步骤。这是核心中的核心。把完成任务的标准流程一步步写清楚每一步要做什么、注意什么、输出什么。步骤要具体到可执行的程度不能写“分析数据”这种模糊指令而要写“按照以下五个维度对数据进行分组统计”。第四部分输出规范。明确规定最终输出的格式、结构、语气、长度等要求。这部分决定了 AI 交付的成果是否符合你的预期。第五部分示例。给出一到两个完整的输入输出示例让 AI 有参照物。示例的力量比单纯的文字描述强十倍。3.3 写 Skill 的实操技巧写 Skill 这件事说难不难但有几个坑我踩过之后觉得值得分享技巧一用“如果……就……”的句式写判断逻辑。AI 很擅长处理条件判断你把各种边界情况用这种句式写清楚它执行起来会准确很多。比如“如果数据缺失超过 20%就在报告中标注数据质量警告如果缺失低于 20%正常分析但注明缺失比例”。技巧二把“不要做什么”也写进去。很多人写 Skill 只写要做什么忽略了禁止事项。但实际使用中AI 最容易犯的错误往往是你没明确禁止的那些。比如“不要使用被动语态”“不要添加原文中没有的数据”“不要超过 500 字”。技巧三版本迭代比一次完美更重要。第一版 Skill 不需要写得多完美先用起来在实际使用中发现问题再改。我自己的周报 Skill 已经迭代了七八个版本每次都是用到某个场景发现输出不对就回去补一条规则。技巧四善用辅助文件。复杂的 Skill 可以拆成多个文件主文件写流程辅助文件放模板、参考数据、检查清单等。这样结构更清晰维护起来也方便。3.4 一个完整的 Skill 示例下面是一个简化版的“技术文档写作”Skill 的核心内容供参考# 技术文档写作 Skill ## 触发条件 当用户要求撰写或修改技术文档、API 文档、开发指南时使用。 ## 执行步骤 1. 确认文档类型和目标读者新手/有经验开发者/架构师 2. 按照“概述-前提条件-操作步骤-示例-常见问题”的结构组织内容 3. 每个操作步骤必须包含做什么、为什么做、怎么做、预期结果 4. 代码示例必须可运行包含必要的注释 5. 术语首次出现时给出通俗解释 ## 输出规范 - 使用二级和三级标题组织内容 - 代码块标注语言类型 - 重要提示用引用块标注 - 全文避免营销语气保持客观平实 ## 禁止事项 - 不要使用“简单”“容易”“只需”等弱化难度的词汇 - 不要省略错误处理和边界情况 - 不要假设读者具备未说明的前置知识这个 Skill 写起来大概花了我二十分钟但之后每次让 AI 写技术文档输出质量都稳定在一个很高的水平线上省下来的反复修改时间远远超过二十分钟。4. 实际使用中会遇到的问题和排查方法4.1 Skill 不生效怎么办这是最常见的问题。排查思路按顺序来第一步检查文件位置和命名。确认 Skill 文件夹放在了正确的目录下文件夹名称和内部文件名是否符合平台要求。很多平台对大小写敏感Skill.md和skill.md可能被当成两个不同的东西。第二步检查配置注册。有些平台需要在配置文件里手动注册 Skill 才能被识别。看看配置文件里有没有正确添加路径。第三步检查触发条件。有些 Skill 需要特定的触发词或指令才能激活。确认你的使用方式是否匹配 Skill 定义的触发条件。第四步查看日志。大多数工具都有日志输出看看加载 Skill 时有没有报错信息。这一步能解决 80% 的疑难杂症。4.2 输出质量不稳定的原因有时候 Skill 生效了但输出质量时好时坏。常见原因有这几个指令冲突Skill 里的要求和系统默认行为矛盾AI 不知道该听谁的。解决办法是在 Skill 里明确写“优先遵循本 Skill 的规则”。步骤太笼统比如写了“分析数据”但没写具体怎么分析AI 每次的理解可能不一样。解决办法是把步骤拆到不能再拆。缺少示例没有示例的情况下AI 对输出格式的理解全靠猜。加一两个示例通常能大幅提升稳定性。上下文干扰对话历史太长前面的内容影响了 AI 对当前任务的理解。解决办法是在触发 Skill 时尽量开启新的对话。4.3 常见问题速查表问题现象可能原因解决方法Skill 完全不生效文件位置错误或未注册检查目录结构和配置文件输出格式不对输出规范写得太模糊补充具体格式要求和示例步骤执行不完整步骤描述不够具体拆解步骤每步写清楚输入输出每次输出差异大缺少约束条件和示例增加禁止事项和参考示例执行速度慢Skill 内容过于臃肿拆分 Skill聚焦单一任务与预期完全不符触发条件设置不当调整触发条件明确适用场景4.4 几个我踩过的坑坑一Skill 写得太长。一开始我觉得写得越详细越好结果一个 Skill 写了三千多字AI 执行起来反而容易遗漏关键步骤。后来我学乖了核心流程控制在 500 字以内详细内容放到辅助文件里。坑二忽略了输出示例。有段时间我写的 Skill 只有步骤没有示例结果 AI 每次输出的格式都不一样。后来每个 Skill 都加了一个完整的输入输出示例稳定性立刻上来了。坑三没有版本管理。改来改去最后不知道哪个版本好用。现在我会在 Skill 文件头部记录版本号和修改日期每次改动都写清楚改了什么、为什么改。提示Skill 的调试和代码调试一样不要一次改太多地方。每次只改一个变量确认效果后再改下一个这样才能准确定位问题。5. Skill 的进阶玩法和扩展思路5.1 组合多个 Skill 完成复杂任务单个 Skill 聚焦单一任务但实际工作往往需要多个步骤。你可以把多个 Skill 串联起来让 AI 按顺序执行。比如“数据清洗 Skill → 数据分析 Skill → 报告生成 Skill”这样一条流水线。关键是要定义好 Skill 之间的接口上一个 Skill 的输出格式要正好是下一个 Skill 能接受的输入格式。这需要在写 Skill 的时候就考虑到上下游的衔接。5.2 让 Skill 具备学习能力Skill 本身是静态的但你可以设计一种机制让它“越用越好”。具体做法是在 Skill 里加入一个“反馈收集”步骤每次执行完任务后让 AI 记录下这次执行中遇到的问题和用户的修改意见积累到一定数量后你根据这些反馈来更新 Skill。这本质上是一种人工参与的持续优化循环。虽然不如自动学习那么智能但实际效果很好因为你的判断力比任何自动化机制都靠谱。5.3 Skill 的分享和协作当你写出了一个好用的 Skill可以分享给团队或社区。分享的时候有几个建议附上详细的使用说明和适用场景给出真实的输入输出示例说明已知的限制和不适用的场景标注版本号和更新日志协作方面团队可以建立共享的 Skill 库每个人负责维护自己擅长的领域。新人加入时直接使用这些 Skill 就能快速达到团队的平均水平大大缩短上手时间。5.4 不同领域的 Skill 应用场景Skill 的适用范围远不止编程和写作。我见过和用过的一些有意思的场景科研领域文献综述 Skill 可以规定检索策略、筛选标准、笔记格式、综述结构让 AI 按照学术规范来整理文献。数学建模 Skill 可以规定建模流程、假设检验步骤、结果验证方法。教育领域出题 Skill 可以规定题型分布、难度梯度、知识点覆盖范围、解析详细程度。批改 Skill 可以规定评分标准、评语风格、错误分类方式。商业领域竞品分析 Skill 可以规定分析维度、数据来源、对比框架、报告模板。用户调研 Skill 可以规定问卷设计原则、样本筛选标准、数据分析方法。创意领域文案写作 Skill 可以规定品牌调性、目标受众、禁用词汇、结构模板。视频脚本 Skill 可以规定时长分配、镜头描述格式、旁白风格。每个领域的 Skill 都有其独特的专业细节但核心逻辑是一样的把领域知识结构化让 AI 能够稳定地按照专业标准输出。6. 关于 Skill 的一些个人体会写了这么多 Skill用了这么多 Skill我最大的体会是Skill 的价值不在于技术含量而在于你对自身工作流程的理解深度。一个写得好的 Skill背后一定是一个想清楚了自己在做什么、为什么这么做、怎么做才最好的人。很多人觉得写 Skill 麻烦不如每次直接跟 AI 说。但我的经验是前期花二十分钟写一个 Skill后面能省下几十个小时的重复沟通时间。而且随着 Skill 不断迭代输出质量会越来越高最终达到“闭着眼睛用都不会出错”的程度。另一个体会是不要追求一次写出完美的 Skill。第一版能跑通就行然后在实际使用中不断打磨。我最好的几个 Skill 都是经过十几次迭代才稳定下来的每次迭代都是因为在实际使用中发现了新的边界情况。最后分享一个小技巧写 Skill 的时候想象你在给一个聪明但完全不了解你工作的新人写操作手册。这个新人学习能力很强但没有任何背景知识也不会主动问你问题。你写的内容必须让他看完就能独立完成任务不需要任何额外的解释。用这个标准来写你的 Skill 质量一定不会差。这个方向后续还可以继续扩展比如把 Skill 和自动化工作流结合起来让 AI 在特定事件触发时自动执行 Skill或者建立 Skill 的评估体系用量化指标来衡量一个 Skill 的好坏。这些方向都很有意思等我在实际项目中验证之后再找机会分享。