1. 先搞清楚 Skill 到底是个什么东西很多人第一次听到 Skill 这个词脑子里浮现的是游戏里的技能树或者是某种需要长期训练才能掌握的硬本领。但在 AI 工具链的语境下Skill 的含义要具体得多也务实得多。它本质上是一份写给 AI 看的“操作手册”——用结构化的方式告诉 AI 在特定场景下应该怎么做、按什么顺序做、注意哪些坑。你可以把它理解成给 AI 装的一个“插件包”但这个插件包不是代码而是知识。1.1 从“每次都要重新解释”到“一次写好反复用”我先说一个几乎所有人都遇到过的场景。你让 AI 帮你写一份周报第一次你得告诉它格式要求、语气偏好、需要包含哪些模块、数据从哪里来。第二次你再让它写它又忘了你还得重新说一遍。第三次、第四次每次都在重复同样的解释工作。这种体验就像你招了一个新员工但他每天早上来上班都会失忆你得从头培训一遍。Skill 要解决的就是这个问题。你把周报的格式规范、语气要求、数据来源、常见模板全部写进一个 Skill 文件里之后每次让 AI 写周报它自动读取这个文件按照你定义好的流程执行。你不需要再重复解释它也不会再忘记。这个逻辑放到任何重复性任务上都成立代码审查、论文润色、数据清洗、会议纪要整理、甚至是帮你按照特定风格回复邮件。1.2 Skill 和 Agent 的区别一个是知识一个是执行者这是被问得最多的问题之一。很多人把 Skill 和 Agent 混为一谈其实两者的定位完全不同。Agent 是一个能自主决策、调用工具、执行多步任务的智能体它像是一个“员工”。而 Skill 是给这个员工看的“岗位操作手册”。Agent 负责决定“做什么”和“什么时候做”Skill 负责告诉它“具体怎么做”。举个例子。你有一个 Agent 负责帮你管理项目进度它需要定期检查任务状态、发送提醒、更新文档。这些动作的触发时机和优先级由 Agent 自己判断。但“检查任务状态”这个动作具体要查哪些字段、“发送提醒”要用什么模板、“更新文档”要遵循什么格式这些细节全部写在 Skill 里。Agent 是决策者Skill 是知识库。没有 Skill 的 Agent 就像一个聪明但什么都不懂的新人有 Skill 的 Agent 才是一个能直接上手的熟练工。1.3 为什么现在 Skill 突然火起来了Skill 这个概念并不是凭空冒出来的。它的流行和 AI 编程工具的普及直接相关。当越来越多的人开始用 Claude Code、Cursor 这类工具写代码时大家发现一个问题AI 写代码的能力很强但它不了解你的项目规范、不知道你的代码风格、不清楚你的目录结构约定。每次生成代码都要手动调整效率反而降低了。Skill 机制的出现让这个问题有了系统性的解法。你把项目的编码规范、目录结构、常用命令、测试流程写成一个 Skill 文件AI 在生成代码时自动参考这些信息输出的结果就直接符合你的要求。这个思路一旦被验证有效就迅速扩展到了编程之外的领域——写作、科研、数据分析、项目管理凡是需要“按照特定规范重复执行”的场景都可以用 Skill 来优化。2. 一个 Skill 文件里到底写了什么理解了 Skill 的定位之后下一个问题自然是它长什么样怎么写虽然不同平台和工具对 Skill 的具体格式要求可能有差异但核心结构是相通的。一个完整的 Skill 文件通常包含几个关键部分元信息、触发条件、执行步骤、注意事项、示例。2.1 元信息让 AI 知道这个 Skill 是干什么的元信息是 Skill 文件的头部区域用来说明这个 Skill 的名称、适用场景、版本等基础信息。这部分看起来简单但写得好不好直接影响 AI 能不能在正确的时机调用它。名称要具体不能太泛。“代码审查”就不如“Python 后端代码安全审查”来得明确。适用场景要写清楚什么情况下应该用这个 Skill什么情况下不该用。我见过很多人写 Skill 时忽略元信息觉得这只是个“标题”不重要。实际使用下来元信息写得好不好直接决定了 AI 能不能在正确的场景下自动匹配到这个 Skill。如果你的 Skill 名称太模糊AI 可能在不需要的时候调用它或者在需要的时候反而没调用。这就像给文件起名字叫“文档1”和叫“2024年Q3销售数据分析报告”后者的可检索性明显更高。2.2 触发条件什么时候该用这个 Skill触发条件是 Skill 设计中最需要动脑子的部分。你需要明确告诉 AI当用户提出什么类型的请求时应该加载这个 Skill。触发条件可以基于关键词、任务类型、文件类型、甚至是上下文中的特定模式。写触发条件时有一个常见的误区写得太窄或太宽。太窄了AI 经常匹配不到Skill 形同虚设。太宽了AI 在不相关的场景也调用它反而干扰正常输出。我的经验是触发条件要覆盖核心场景但不要试图覆盖所有边缘情况。宁可多写几个专门的 Skill也不要写一个“万能 Skill”试图处理所有事情。2.3 执行步骤核心中的核心执行步骤是 Skill 文件的主体也是最能体现写作者经验水平的部分。这部分要像写菜谱一样把每个步骤写清楚先做什么、再做什么、每步的输入是什么、输出是什么、遇到分支情况怎么处理。写执行步骤时我建议遵循几个原则。第一步骤要可执行不能是“优化代码质量”这种模糊描述而要具体到“检查是否存在未处理的异常”“确认所有数据库查询都有索引覆盖”。第二步骤之间要有明确的顺序和依赖关系让 AI 知道什么必须先做、什么可以并行。第三对于关键步骤要说明“为什么这样做”这样 AI 在遇到变体情况时能做出合理判断而不是死板地照搬。2.4 注意事项和示例让 Skill 真正好用注意事项部分记录的是“踩过的坑”和“容易出错的地方”。比如“不要在没有确认的情况下删除文件”“生成 SQL 时注意转义特殊字符”“处理中文时注意编码格式”。这些内容看起来琐碎但实际使用中能避免大量问题。示例部分则是给 AI 提供“参考答案”。一个具体的输入输出示例比一大段抽象描述更有效。我通常会在 Skill 里放两到三个典型示例覆盖正常情况和边界情况。示例不需要很长但要足够具体让 AI 能理解你期望的输出格式和风格。3. 去哪里找现成的 Skill不是每个人都需要从零开始写 Skill。很多时候你想要的功能已经有人写好了直接拿来用就行。但“去哪里找”这个问题确实让很多新手感到困惑。3.1 官方仓库和社区市场最直接的来源是各个平台的官方 Skill 仓库。Claude Code 有官方的 Skill 目录Cursor 也有自己的插件市场。这些官方渠道的 Skill 通常质量有保障更新也比较及时。缺点是数量有限覆盖的场景不一定完全匹配你的需求。社区市场是另一个重要来源。GitHub 上有大量个人开发者分享的 Skill 文件覆盖了从编程到写作到数据分析的各个领域。搜索时可以用“awesome-skills”“skill-collection”这类关键词能找到不少整理好的合集。不过社区来源的 Skill 质量参差不齐使用前最好先读一遍内容确认没有安全问题再加载。3.2 从别人的项目里“偷师”我个人的经验是最好的 Skill 往往不是专门去找的而是在阅读别人项目时顺手发现的。很多开源项目会在根目录放一个.skills文件夹或者SKILL.md文件里面记录了这个项目的开发规范、常用命令、代码风格约定。这些内容本身就是高质量的 Skill 素材。你可以在 GitHub 上搜索特定技术栈的项目看看他们有没有把项目规范写成 Skill 文件。比如搜索“SKILL.md Python”或者“skills 前端开发”能找到不少实际项目中的真实案例。这种从真实项目中提取的 Skill往往比通用模板更实用因为它们经过了实际使用的检验。3.3 怎么判断一个 Skill 值不值得用找到 Skill 之后怎么判断它好不好用我通常会看几个方面。第一看元信息是否清晰能不能一眼看出这个 Skill 的适用场景。第二看执行步骤是否具体有没有“正确的废话”。第三看有没有示例示例的质量如何。第四看更新时间和使用反馈太老的 Skill 可能已经不适配当前版本的工具了。还有一个很重要的判断标准这个 Skill 解决的问题是不是你真正遇到的问题。很多人看到“热门 Skill 推荐”就一股脑全装上结果发现大部分都用不上反而让 AI 的上下文变得混乱。我的建议是按需加载只装当前项目真正需要的 Skill。4. 自己动手写一个 Skill 的完整流程当你找不到合适的现成 Skill或者现有 Skill 不能完全满足需求时就需要自己动手写了。写 Skill 这件事门槛没有想象中那么高但写好确实需要一些经验和技巧。4.1 从“记录自己的操作流程”开始写 Skill 最好的起点不是打开编辑器开始敲字而是先观察自己平时是怎么做这件事的。比如你要写一个“代码审查 Skill”先回想一下你每次审查代码时会按什么顺序看先看目录结构还是先看核心逻辑会重点检查哪些问题有没有固定的检查清单把这些流程写下来就是 Skill 的雏形。我习惯用手机备忘录或者纸质笔记本记录因为写的时候不需要考虑格式想到什么写什么。等流程记录得差不多了再整理成结构化的 Skill 文件。这个“先记录后整理”的方法比直接对着空白文件想要高效得多。4.2 用 Skill Creator 工具加速开发如果你用的是 Claude Code它自带一个叫 Skill Creator 的功能可以帮你快速生成 Skill 文件的框架。你只需要描述想要实现的功能它会生成一个包含元信息、触发条件、执行步骤的模板你在这个基础上修改和补充就行。其他平台也有类似的辅助工具。比如有些社区开发的 Skill 生成器可以通过问答的方式引导你一步步完成 Skill 的编写。这些工具不能替代你的思考但能帮你省去搭建框架的时间让你把精力集中在内容本身上。4.3 迭代比一次性写完更重要我见过很多人写 Skill 时追求“一次写完”结果写出来的东西要么太理想化不实用要么漏掉了关键细节。我的经验是先写一个能用的版本然后在实际使用中不断迭代。第一版 Skill 不需要很完美能把核心流程说清楚就行。用几次之后你会发现哪些步骤 AI 理解不了、哪些地方容易出错、哪些场景没有覆盖到。根据这些反馈逐步补充和调整通常迭代三到五次之后Skill 的质量会有明显提升。这个过程和写文档、写教程是一样的好内容都是改出来的。4.4 一个实际案例从零写一个“周报生成 Skill”我拿周报生成这个场景来完整走一遍流程。首先明确需求每周五下午根据本周的 Git 提交记录和任务管理工具中的完成情况生成一份格式固定的周报。元信息部分写清楚名称叫“周报自动生成”适用场景是“每周五生成工作周报”版本号从 1.0 开始。触发条件设置为当用户提到“写周报”“生成周报”“本周总结”时加载。执行步骤分五步。第一步读取本周的 Git 提交记录提取 commit message 中的关键信息。第二步读取任务管理工具中本周完成的任务列表。第三步按照“本周完成”“进行中”“下周计划”“风险与问题”四个模块组织内容。第四步每个模块用简洁的条目式语言描述避免大段文字。第五步输出格式为 Markdown标题用二级标题条目用无序列表。注意事项写三条不要编造没有完成的任务如果某项任务没有明确结果标注“进行中”而不是“已完成”周报语气保持客观不要用“非常”“特别”这类主观修饰词。示例部分放一个完整的周报样例让 AI 知道最终输出应该长什么样。这个 Skill 写完之后我实际用了两个月中间调整了三次现在基本能做到一键生成只需要手动补充少量个性化内容。5. 写 Skill 时最容易踩的几个坑写了十几个 Skill 之后我总结出一些反复出现的问题。这些坑看起来不大但每一个都会显著影响 Skill 的实际效果。5.1 把 Skill 写成“愿望清单”这是新手最常犯的错误。写出来的 Skill 全是“要保证代码质量”“要输出高质量内容”“要注意用户体验”这类无法执行的描述。AI 看到这种 Skill 和没看到差不多因为它不知道具体该做什么。正确的做法是把每个要求都转化成可执行的动作。“保证代码质量”改成“检查所有函数是否有错误处理”“确认变量命名符合驼峰规范”“验证边界条件是否覆盖”。“输出高质量内容”改成“每个论点至少配一个具体案例”“段落长度控制在三到五行”“避免使用被动语态”。越具体AI 执行起来越准确。5.2 步骤之间缺少依赖关系有些 Skill 的步骤写得很详细但步骤之间是孤立的没有说明先后顺序和依赖关系。AI 在执行时可能会跳过某些步骤或者以错误的顺序执行。解决这个问题的方法是在步骤描述中明确标注依赖关系。比如“在完成第一步的数据读取之后再进行第二步的数据清洗”“第三步必须在第二步的输出基础上进行”。对于可以并行的步骤也要明确说明“以下两步可以同时进行”。这些标注看起来啰嗦但能大幅提升 AI 执行的准确率。5.3 忽略异常情况的处理大部分 Skill 只写了“正常流程”怎么做没有考虑“如果出错了怎么办”。实际使用中异常情况出现的频率远比想象中高文件不存在、数据格式不对、网络请求失败、权限不足。一个好的 Skill 应该包含基本的异常处理逻辑。比如“如果 Git 仓库不存在提示用户先初始化仓库”“如果任务管理工具无法访问跳过该步骤并记录警告”“如果输出格式不符合预期回退到默认模板”。这些处理逻辑不需要很复杂但能让 Skill 在非理想环境下也能正常工作。5.4 示例太少或者太简单示例是 Skill 中最容易被忽视的部分。很多人只放一个最简单的示例甚至不放示例。结果 AI 对输出格式的理解完全靠猜生成的内容和预期差距很大。我的建议是至少放三个示例一个最简单的正常情况、一个包含多个模块的复杂情况、一个边界情况。示例要完整包含输入和输出。如果输出是代码要包含完整的代码块如果输出是文档要包含完整的文档结构。示例越具体AI 的输出越稳定。6. 不同场景下的 Skill 设计思路Skill 的设计没有万能公式不同场景需要不同的思路。我挑几个典型场景说说各自的设计要点。6.1 编程开发类 Skill规范先行编程类 Skill 的核心是“规范”。你需要把项目的编码规范、目录结构、命名约定、测试要求全部写进去。这类 Skill 的触发条件通常和文件类型或操作类型相关比如“当用户要求生成 Python 代码时”“当用户要求创建新组件时”。执行步骤要包含读取项目配置文件、检查现有代码风格、生成符合规范的代码、运行格式化工具、执行相关测试。注意事项要特别强调“不要引入项目中没有使用过的依赖”“不要修改无关文件”“生成的代码必须包含类型注解”。6.2 写作类 Skill风格和结构并重写作类 Skill 需要同时定义“写什么”和“怎么写”。结构方面明确文章需要包含哪些部分、每部分的顺序和篇幅。风格方面定义语气、人称、句式、用词偏好。我写过一个“技术博客 Skill”里面定义了开头用场景引入而不是定义解释、每个章节必须有具体案例、代码块必须标注语言类型、避免使用“通过”“随着”这类套话。这些规则写进去之后AI 生成的初稿质量明显提升后期修改的工作量减少了一半以上。6.3 数据分析类 Skill流程和校验是关键数据分析类 Skill 的重点是流程的严谨性和结果的校验。执行步骤要包含数据加载、数据清洗、异常值处理、分析执行、结果验证、可视化输出。每个步骤都要有明确的输入输出定义。校验环节特别重要。我通常会在 Skill 里加入“检查数据行数是否在合理范围内”“确认关键字段没有空值”“验证计算结果和预期量级一致”这类校验步骤。这些检查能及时发现数据问题避免基于错误数据得出结论。6.4 科研辅助类 Skill引用和逻辑是核心科研场景对准确性和逻辑性的要求极高。科研类 Skill 需要特别强调所有引用必须可追溯、论证过程必须完整、不能编造数据或文献、结论必须有证据支撑。我见过有人用 AI 辅助写论文时AI 编造了不存在的参考文献。这个问题可以通过 Skill 来规避在 Skill 中明确要求“所有引用必须来自用户提供的文献列表”“如果找不到对应文献标注‘待补充’而不是编造”“每个论点必须有至少一个引用支撑”。这些规则能有效降低 AI 产生幻觉的风险。7. 让 Skill 真正融入日常工作流写好了 Skill 只是第一步让它真正融入日常工作流才能发挥价值。我分享几个实际使用中的经验。7.1 从高频重复任务开始不要一上来就给所有任务都写 Skill。先挑那些你每天或每周都要做、而且每次做法都差不多的任务。比如每天的代码提交检查、每周的周报生成、每月的项目进度汇总。这些任务写 Skill 的投入产出比最高。低频任务或者每次做法都不一样的任务写 Skill 的收益不大。因为 Skill 的价值在于“标准化重复流程”如果流程本身就不固定Skill 反而会成为束缚。7.2 建立自己的 Skill 库随着写的 Skill 越来越多你需要一个地方来管理它们。我建议在本地建一个专门的目录按场景分类存放。比如skills/development/放编程类skills/writing/放写作类skills/analysis/放分析类。每个 Skill 文件命名要清晰用英文小写加连字符比如python-code-review.md、weekly-report.md。文件头部加上版本号和更新日期方便追踪。如果 Skill 之间有依赖关系在文件里注明。7.3 定期回顾和清理Skill 不是写完就一劳永逸的。工具在更新项目在变化你的需求也在变。我每个月会花半小时回顾一下现有的 Skill看看哪些还在用、哪些已经过时、哪些需要更新。过时的 Skill 要及时删除或归档不要留在那里干扰 AI 的判断。需要更新的 Skill 要记录下需要改的地方集中处理。这个维护工作看起来麻烦但能保证你的 Skill 库始终处于可用状态。7.4 和团队共享 Skill如果你在团队中工作Skill 的共享能带来更大的价值。把团队通用的规范写成 Skill每个人都能用新成员上手也更快。共享的方式可以是通过 Git 仓库管理或者放在团队内部的文档平台上。共享 Skill 时要注意版本管理。不同人可能对同一个 Skill 有不同的修改需求需要有一个机制来合并和协调。我通常的做法是核心规范由一个人维护其他人可以提建议但不要直接改。这样能保证 Skill 的一致性。8. 关于 Skill 的一些常见疑问最后集中回答几个被问得比较多的问题。8.1 Skill 文件应该放在哪里不同工具的约定不一样。Claude Code 默认读取项目根目录下的.claude/skills/目录也支持用户主目录下的全局 Skill。Cursor 有自己的配置目录。具体位置要看工具的文档。我的建议是项目相关的 Skill 放在项目目录里通用 Skill 放在全局目录里。这样既能保证项目独立性又能复用通用能力。8.2 一个 Skill 文件可以有多长没有硬性限制但实际使用中太长的 Skill 会影响 AI 的加载速度和处理效果。我的经验是单个 Skill 文件控制在 2000 字以内超过这个长度就考虑拆分成多个 Skill。拆分的原则是按功能模块拆而不是按步骤拆。比如“代码审查”可以拆成“安全检查”“性能检查”“风格检查”三个独立 Skill。8.3 Skill 和提示词有什么区别提示词是你每次对话时输入的内容Skill 是预先写好、可以反复加载的规范文件。提示词是“一次性”的Skill 是“持久化”的。你可以把 Skill 理解成一种特殊的提示词它的特殊之处在于结构化、可复用、可版本管理、可共享。写 Skill 本质上就是在写一份高质量的、结构化的提示词。8.4 不会写代码能写 Skill 吗完全可以。Skill 文件本质上是结构化的文本不需要编程基础。你只需要能把一件事的流程说清楚就能写 Skill。我见过很多非技术背景的人写出了非常好用的 Skill比如行政人员写的“会议纪要整理 Skill”、HR 写的“面试反馈汇总 Skill”、运营写的“活动复盘 Skill”。关键不在于技术能力而在于你对业务流程的理解深度。8.5 Skill 会不会让 AI 变得死板这是一个合理的担心但实际使用下来好的 Skill 不会让 AI 死板反而能让它在正确的框架内发挥更大的灵活性。因为 Skill 定义的是“必须遵守的底线”和“推荐遵循的流程”而不是“唯一正确的答案”。AI 在执行 Skill 时仍然可以根据具体情况做出判断和调整。真正让 AI 死板的是那些写得过于僵化、不留任何余地的 Skill这是写作者的问题不是 Skill 机制本身的问题。8.6 怎么知道一个 Skill 有没有生效最直接的方法是看 AI 的输出是否符合 Skill 中定义的规范。如果 Skill 要求“每个函数必须有文档字符串”而 AI 生成的代码没有说明 Skill 没有生效。这时候需要检查Skill 文件是否放在了正确的目录、触发条件是否匹配、文件格式是否正确。有时候 AI 会部分执行 Skill 的内容这时候需要检查 Skill 中是否有相互矛盾的指令。8.7 Skill 需要定期更新吗需要。工具版本更新、项目规范变化、个人偏好调整都会导致原有 Skill 不再适用。我建议至少每季度检查一次看看有没有需要更新的地方。如果发现某个 Skill 经常出问题说明它需要重新设计而不是小修小补。8.8 多个 Skill 之间会冲突吗有可能。如果两个 Skill 对同一件事给出了不同的指令AI 可能会困惑。比如一个 Skill 说“代码注释用中文”另一个说“代码注释用英文”同时加载就会冲突。避免冲突的方法是在写 Skill 时就明确它的适用范围不要和其他 Skill 重叠。如果确实需要同时使用多个 Skill要确保它们之间没有矛盾的指令。8.9 怎么评估一个 Skill 的质量我通常从几个维度评估触发准确率该调用的时候有没有调用、执行完整度定义的步骤有没有全部执行、输出稳定性多次执行结果是否一致、维护成本是否需要频繁修改。这四个维度都表现好的 Skill就是高质量的 Skill。8.10 Skill 的未来会怎么发展从目前的趋势看Skill 正在从“个人工具”向“团队资产”演变。越来越多的团队开始把 Skill 作为知识管理的一部分把老员工的经验沉淀成 Skill 文件让新成员能快速上手。同时Skill 的格式和标准也在逐步统一未来可能会出现跨平台通用的 Skill 规范。对于个人来说现在开始积累自己的 Skill 库是在为未来的效率提升打基础。
AI Skill 完全指南：从概念到实战，打造可复用的AI操作手册
1. 先搞清楚 Skill 到底是个什么东西很多人第一次听到 Skill 这个词脑子里浮现的是游戏里的技能树或者是某种需要长期训练才能掌握的硬本领。但在 AI 工具链的语境下Skill 的含义要具体得多也务实得多。它本质上是一份写给 AI 看的“操作手册”——用结构化的方式告诉 AI 在特定场景下应该怎么做、按什么顺序做、注意哪些坑。你可以把它理解成给 AI 装的一个“插件包”但这个插件包不是代码而是知识。1.1 从“每次都要重新解释”到“一次写好反复用”我先说一个几乎所有人都遇到过的场景。你让 AI 帮你写一份周报第一次你得告诉它格式要求、语气偏好、需要包含哪些模块、数据从哪里来。第二次你再让它写它又忘了你还得重新说一遍。第三次、第四次每次都在重复同样的解释工作。这种体验就像你招了一个新员工但他每天早上来上班都会失忆你得从头培训一遍。Skill 要解决的就是这个问题。你把周报的格式规范、语气要求、数据来源、常见模板全部写进一个 Skill 文件里之后每次让 AI 写周报它自动读取这个文件按照你定义好的流程执行。你不需要再重复解释它也不会再忘记。这个逻辑放到任何重复性任务上都成立代码审查、论文润色、数据清洗、会议纪要整理、甚至是帮你按照特定风格回复邮件。1.2 Skill 和 Agent 的区别一个是知识一个是执行者这是被问得最多的问题之一。很多人把 Skill 和 Agent 混为一谈其实两者的定位完全不同。Agent 是一个能自主决策、调用工具、执行多步任务的智能体它像是一个“员工”。而 Skill 是给这个员工看的“岗位操作手册”。Agent 负责决定“做什么”和“什么时候做”Skill 负责告诉它“具体怎么做”。举个例子。你有一个 Agent 负责帮你管理项目进度它需要定期检查任务状态、发送提醒、更新文档。这些动作的触发时机和优先级由 Agent 自己判断。但“检查任务状态”这个动作具体要查哪些字段、“发送提醒”要用什么模板、“更新文档”要遵循什么格式这些细节全部写在 Skill 里。Agent 是决策者Skill 是知识库。没有 Skill 的 Agent 就像一个聪明但什么都不懂的新人有 Skill 的 Agent 才是一个能直接上手的熟练工。1.3 为什么现在 Skill 突然火起来了Skill 这个概念并不是凭空冒出来的。它的流行和 AI 编程工具的普及直接相关。当越来越多的人开始用 Claude Code、Cursor 这类工具写代码时大家发现一个问题AI 写代码的能力很强但它不了解你的项目规范、不知道你的代码风格、不清楚你的目录结构约定。每次生成代码都要手动调整效率反而降低了。Skill 机制的出现让这个问题有了系统性的解法。你把项目的编码规范、目录结构、常用命令、测试流程写成一个 Skill 文件AI 在生成代码时自动参考这些信息输出的结果就直接符合你的要求。这个思路一旦被验证有效就迅速扩展到了编程之外的领域——写作、科研、数据分析、项目管理凡是需要“按照特定规范重复执行”的场景都可以用 Skill 来优化。2. 一个 Skill 文件里到底写了什么理解了 Skill 的定位之后下一个问题自然是它长什么样怎么写虽然不同平台和工具对 Skill 的具体格式要求可能有差异但核心结构是相通的。一个完整的 Skill 文件通常包含几个关键部分元信息、触发条件、执行步骤、注意事项、示例。2.1 元信息让 AI 知道这个 Skill 是干什么的元信息是 Skill 文件的头部区域用来说明这个 Skill 的名称、适用场景、版本等基础信息。这部分看起来简单但写得好不好直接影响 AI 能不能在正确的时机调用它。名称要具体不能太泛。“代码审查”就不如“Python 后端代码安全审查”来得明确。适用场景要写清楚什么情况下应该用这个 Skill什么情况下不该用。我见过很多人写 Skill 时忽略元信息觉得这只是个“标题”不重要。实际使用下来元信息写得好不好直接决定了 AI 能不能在正确的场景下自动匹配到这个 Skill。如果你的 Skill 名称太模糊AI 可能在不需要的时候调用它或者在需要的时候反而没调用。这就像给文件起名字叫“文档1”和叫“2024年Q3销售数据分析报告”后者的可检索性明显更高。2.2 触发条件什么时候该用这个 Skill触发条件是 Skill 设计中最需要动脑子的部分。你需要明确告诉 AI当用户提出什么类型的请求时应该加载这个 Skill。触发条件可以基于关键词、任务类型、文件类型、甚至是上下文中的特定模式。写触发条件时有一个常见的误区写得太窄或太宽。太窄了AI 经常匹配不到Skill 形同虚设。太宽了AI 在不相关的场景也调用它反而干扰正常输出。我的经验是触发条件要覆盖核心场景但不要试图覆盖所有边缘情况。宁可多写几个专门的 Skill也不要写一个“万能 Skill”试图处理所有事情。2.3 执行步骤核心中的核心执行步骤是 Skill 文件的主体也是最能体现写作者经验水平的部分。这部分要像写菜谱一样把每个步骤写清楚先做什么、再做什么、每步的输入是什么、输出是什么、遇到分支情况怎么处理。写执行步骤时我建议遵循几个原则。第一步骤要可执行不能是“优化代码质量”这种模糊描述而要具体到“检查是否存在未处理的异常”“确认所有数据库查询都有索引覆盖”。第二步骤之间要有明确的顺序和依赖关系让 AI 知道什么必须先做、什么可以并行。第三对于关键步骤要说明“为什么这样做”这样 AI 在遇到变体情况时能做出合理判断而不是死板地照搬。2.4 注意事项和示例让 Skill 真正好用注意事项部分记录的是“踩过的坑”和“容易出错的地方”。比如“不要在没有确认的情况下删除文件”“生成 SQL 时注意转义特殊字符”“处理中文时注意编码格式”。这些内容看起来琐碎但实际使用中能避免大量问题。示例部分则是给 AI 提供“参考答案”。一个具体的输入输出示例比一大段抽象描述更有效。我通常会在 Skill 里放两到三个典型示例覆盖正常情况和边界情况。示例不需要很长但要足够具体让 AI 能理解你期望的输出格式和风格。3. 去哪里找现成的 Skill不是每个人都需要从零开始写 Skill。很多时候你想要的功能已经有人写好了直接拿来用就行。但“去哪里找”这个问题确实让很多新手感到困惑。3.1 官方仓库和社区市场最直接的来源是各个平台的官方 Skill 仓库。Claude Code 有官方的 Skill 目录Cursor 也有自己的插件市场。这些官方渠道的 Skill 通常质量有保障更新也比较及时。缺点是数量有限覆盖的场景不一定完全匹配你的需求。社区市场是另一个重要来源。GitHub 上有大量个人开发者分享的 Skill 文件覆盖了从编程到写作到数据分析的各个领域。搜索时可以用“awesome-skills”“skill-collection”这类关键词能找到不少整理好的合集。不过社区来源的 Skill 质量参差不齐使用前最好先读一遍内容确认没有安全问题再加载。3.2 从别人的项目里“偷师”我个人的经验是最好的 Skill 往往不是专门去找的而是在阅读别人项目时顺手发现的。很多开源项目会在根目录放一个.skills文件夹或者SKILL.md文件里面记录了这个项目的开发规范、常用命令、代码风格约定。这些内容本身就是高质量的 Skill 素材。你可以在 GitHub 上搜索特定技术栈的项目看看他们有没有把项目规范写成 Skill 文件。比如搜索“SKILL.md Python”或者“skills 前端开发”能找到不少实际项目中的真实案例。这种从真实项目中提取的 Skill往往比通用模板更实用因为它们经过了实际使用的检验。3.3 怎么判断一个 Skill 值不值得用找到 Skill 之后怎么判断它好不好用我通常会看几个方面。第一看元信息是否清晰能不能一眼看出这个 Skill 的适用场景。第二看执行步骤是否具体有没有“正确的废话”。第三看有没有示例示例的质量如何。第四看更新时间和使用反馈太老的 Skill 可能已经不适配当前版本的工具了。还有一个很重要的判断标准这个 Skill 解决的问题是不是你真正遇到的问题。很多人看到“热门 Skill 推荐”就一股脑全装上结果发现大部分都用不上反而让 AI 的上下文变得混乱。我的建议是按需加载只装当前项目真正需要的 Skill。4. 自己动手写一个 Skill 的完整流程当你找不到合适的现成 Skill或者现有 Skill 不能完全满足需求时就需要自己动手写了。写 Skill 这件事门槛没有想象中那么高但写好确实需要一些经验和技巧。4.1 从“记录自己的操作流程”开始写 Skill 最好的起点不是打开编辑器开始敲字而是先观察自己平时是怎么做这件事的。比如你要写一个“代码审查 Skill”先回想一下你每次审查代码时会按什么顺序看先看目录结构还是先看核心逻辑会重点检查哪些问题有没有固定的检查清单把这些流程写下来就是 Skill 的雏形。我习惯用手机备忘录或者纸质笔记本记录因为写的时候不需要考虑格式想到什么写什么。等流程记录得差不多了再整理成结构化的 Skill 文件。这个“先记录后整理”的方法比直接对着空白文件想要高效得多。4.2 用 Skill Creator 工具加速开发如果你用的是 Claude Code它自带一个叫 Skill Creator 的功能可以帮你快速生成 Skill 文件的框架。你只需要描述想要实现的功能它会生成一个包含元信息、触发条件、执行步骤的模板你在这个基础上修改和补充就行。其他平台也有类似的辅助工具。比如有些社区开发的 Skill 生成器可以通过问答的方式引导你一步步完成 Skill 的编写。这些工具不能替代你的思考但能帮你省去搭建框架的时间让你把精力集中在内容本身上。4.3 迭代比一次性写完更重要我见过很多人写 Skill 时追求“一次写完”结果写出来的东西要么太理想化不实用要么漏掉了关键细节。我的经验是先写一个能用的版本然后在实际使用中不断迭代。第一版 Skill 不需要很完美能把核心流程说清楚就行。用几次之后你会发现哪些步骤 AI 理解不了、哪些地方容易出错、哪些场景没有覆盖到。根据这些反馈逐步补充和调整通常迭代三到五次之后Skill 的质量会有明显提升。这个过程和写文档、写教程是一样的好内容都是改出来的。4.4 一个实际案例从零写一个“周报生成 Skill”我拿周报生成这个场景来完整走一遍流程。首先明确需求每周五下午根据本周的 Git 提交记录和任务管理工具中的完成情况生成一份格式固定的周报。元信息部分写清楚名称叫“周报自动生成”适用场景是“每周五生成工作周报”版本号从 1.0 开始。触发条件设置为当用户提到“写周报”“生成周报”“本周总结”时加载。执行步骤分五步。第一步读取本周的 Git 提交记录提取 commit message 中的关键信息。第二步读取任务管理工具中本周完成的任务列表。第三步按照“本周完成”“进行中”“下周计划”“风险与问题”四个模块组织内容。第四步每个模块用简洁的条目式语言描述避免大段文字。第五步输出格式为 Markdown标题用二级标题条目用无序列表。注意事项写三条不要编造没有完成的任务如果某项任务没有明确结果标注“进行中”而不是“已完成”周报语气保持客观不要用“非常”“特别”这类主观修饰词。示例部分放一个完整的周报样例让 AI 知道最终输出应该长什么样。这个 Skill 写完之后我实际用了两个月中间调整了三次现在基本能做到一键生成只需要手动补充少量个性化内容。5. 写 Skill 时最容易踩的几个坑写了十几个 Skill 之后我总结出一些反复出现的问题。这些坑看起来不大但每一个都会显著影响 Skill 的实际效果。5.1 把 Skill 写成“愿望清单”这是新手最常犯的错误。写出来的 Skill 全是“要保证代码质量”“要输出高质量内容”“要注意用户体验”这类无法执行的描述。AI 看到这种 Skill 和没看到差不多因为它不知道具体该做什么。正确的做法是把每个要求都转化成可执行的动作。“保证代码质量”改成“检查所有函数是否有错误处理”“确认变量命名符合驼峰规范”“验证边界条件是否覆盖”。“输出高质量内容”改成“每个论点至少配一个具体案例”“段落长度控制在三到五行”“避免使用被动语态”。越具体AI 执行起来越准确。5.2 步骤之间缺少依赖关系有些 Skill 的步骤写得很详细但步骤之间是孤立的没有说明先后顺序和依赖关系。AI 在执行时可能会跳过某些步骤或者以错误的顺序执行。解决这个问题的方法是在步骤描述中明确标注依赖关系。比如“在完成第一步的数据读取之后再进行第二步的数据清洗”“第三步必须在第二步的输出基础上进行”。对于可以并行的步骤也要明确说明“以下两步可以同时进行”。这些标注看起来啰嗦但能大幅提升 AI 执行的准确率。5.3 忽略异常情况的处理大部分 Skill 只写了“正常流程”怎么做没有考虑“如果出错了怎么办”。实际使用中异常情况出现的频率远比想象中高文件不存在、数据格式不对、网络请求失败、权限不足。一个好的 Skill 应该包含基本的异常处理逻辑。比如“如果 Git 仓库不存在提示用户先初始化仓库”“如果任务管理工具无法访问跳过该步骤并记录警告”“如果输出格式不符合预期回退到默认模板”。这些处理逻辑不需要很复杂但能让 Skill 在非理想环境下也能正常工作。5.4 示例太少或者太简单示例是 Skill 中最容易被忽视的部分。很多人只放一个最简单的示例甚至不放示例。结果 AI 对输出格式的理解完全靠猜生成的内容和预期差距很大。我的建议是至少放三个示例一个最简单的正常情况、一个包含多个模块的复杂情况、一个边界情况。示例要完整包含输入和输出。如果输出是代码要包含完整的代码块如果输出是文档要包含完整的文档结构。示例越具体AI 的输出越稳定。6. 不同场景下的 Skill 设计思路Skill 的设计没有万能公式不同场景需要不同的思路。我挑几个典型场景说说各自的设计要点。6.1 编程开发类 Skill规范先行编程类 Skill 的核心是“规范”。你需要把项目的编码规范、目录结构、命名约定、测试要求全部写进去。这类 Skill 的触发条件通常和文件类型或操作类型相关比如“当用户要求生成 Python 代码时”“当用户要求创建新组件时”。执行步骤要包含读取项目配置文件、检查现有代码风格、生成符合规范的代码、运行格式化工具、执行相关测试。注意事项要特别强调“不要引入项目中没有使用过的依赖”“不要修改无关文件”“生成的代码必须包含类型注解”。6.2 写作类 Skill风格和结构并重写作类 Skill 需要同时定义“写什么”和“怎么写”。结构方面明确文章需要包含哪些部分、每部分的顺序和篇幅。风格方面定义语气、人称、句式、用词偏好。我写过一个“技术博客 Skill”里面定义了开头用场景引入而不是定义解释、每个章节必须有具体案例、代码块必须标注语言类型、避免使用“通过”“随着”这类套话。这些规则写进去之后AI 生成的初稿质量明显提升后期修改的工作量减少了一半以上。6.3 数据分析类 Skill流程和校验是关键数据分析类 Skill 的重点是流程的严谨性和结果的校验。执行步骤要包含数据加载、数据清洗、异常值处理、分析执行、结果验证、可视化输出。每个步骤都要有明确的输入输出定义。校验环节特别重要。我通常会在 Skill 里加入“检查数据行数是否在合理范围内”“确认关键字段没有空值”“验证计算结果和预期量级一致”这类校验步骤。这些检查能及时发现数据问题避免基于错误数据得出结论。6.4 科研辅助类 Skill引用和逻辑是核心科研场景对准确性和逻辑性的要求极高。科研类 Skill 需要特别强调所有引用必须可追溯、论证过程必须完整、不能编造数据或文献、结论必须有证据支撑。我见过有人用 AI 辅助写论文时AI 编造了不存在的参考文献。这个问题可以通过 Skill 来规避在 Skill 中明确要求“所有引用必须来自用户提供的文献列表”“如果找不到对应文献标注‘待补充’而不是编造”“每个论点必须有至少一个引用支撑”。这些规则能有效降低 AI 产生幻觉的风险。7. 让 Skill 真正融入日常工作流写好了 Skill 只是第一步让它真正融入日常工作流才能发挥价值。我分享几个实际使用中的经验。7.1 从高频重复任务开始不要一上来就给所有任务都写 Skill。先挑那些你每天或每周都要做、而且每次做法都差不多的任务。比如每天的代码提交检查、每周的周报生成、每月的项目进度汇总。这些任务写 Skill 的投入产出比最高。低频任务或者每次做法都不一样的任务写 Skill 的收益不大。因为 Skill 的价值在于“标准化重复流程”如果流程本身就不固定Skill 反而会成为束缚。7.2 建立自己的 Skill 库随着写的 Skill 越来越多你需要一个地方来管理它们。我建议在本地建一个专门的目录按场景分类存放。比如skills/development/放编程类skills/writing/放写作类skills/analysis/放分析类。每个 Skill 文件命名要清晰用英文小写加连字符比如python-code-review.md、weekly-report.md。文件头部加上版本号和更新日期方便追踪。如果 Skill 之间有依赖关系在文件里注明。7.3 定期回顾和清理Skill 不是写完就一劳永逸的。工具在更新项目在变化你的需求也在变。我每个月会花半小时回顾一下现有的 Skill看看哪些还在用、哪些已经过时、哪些需要更新。过时的 Skill 要及时删除或归档不要留在那里干扰 AI 的判断。需要更新的 Skill 要记录下需要改的地方集中处理。这个维护工作看起来麻烦但能保证你的 Skill 库始终处于可用状态。7.4 和团队共享 Skill如果你在团队中工作Skill 的共享能带来更大的价值。把团队通用的规范写成 Skill每个人都能用新成员上手也更快。共享的方式可以是通过 Git 仓库管理或者放在团队内部的文档平台上。共享 Skill 时要注意版本管理。不同人可能对同一个 Skill 有不同的修改需求需要有一个机制来合并和协调。我通常的做法是核心规范由一个人维护其他人可以提建议但不要直接改。这样能保证 Skill 的一致性。8. 关于 Skill 的一些常见疑问最后集中回答几个被问得比较多的问题。8.1 Skill 文件应该放在哪里不同工具的约定不一样。Claude Code 默认读取项目根目录下的.claude/skills/目录也支持用户主目录下的全局 Skill。Cursor 有自己的配置目录。具体位置要看工具的文档。我的建议是项目相关的 Skill 放在项目目录里通用 Skill 放在全局目录里。这样既能保证项目独立性又能复用通用能力。8.2 一个 Skill 文件可以有多长没有硬性限制但实际使用中太长的 Skill 会影响 AI 的加载速度和处理效果。我的经验是单个 Skill 文件控制在 2000 字以内超过这个长度就考虑拆分成多个 Skill。拆分的原则是按功能模块拆而不是按步骤拆。比如“代码审查”可以拆成“安全检查”“性能检查”“风格检查”三个独立 Skill。8.3 Skill 和提示词有什么区别提示词是你每次对话时输入的内容Skill 是预先写好、可以反复加载的规范文件。提示词是“一次性”的Skill 是“持久化”的。你可以把 Skill 理解成一种特殊的提示词它的特殊之处在于结构化、可复用、可版本管理、可共享。写 Skill 本质上就是在写一份高质量的、结构化的提示词。8.4 不会写代码能写 Skill 吗完全可以。Skill 文件本质上是结构化的文本不需要编程基础。你只需要能把一件事的流程说清楚就能写 Skill。我见过很多非技术背景的人写出了非常好用的 Skill比如行政人员写的“会议纪要整理 Skill”、HR 写的“面试反馈汇总 Skill”、运营写的“活动复盘 Skill”。关键不在于技术能力而在于你对业务流程的理解深度。8.5 Skill 会不会让 AI 变得死板这是一个合理的担心但实际使用下来好的 Skill 不会让 AI 死板反而能让它在正确的框架内发挥更大的灵活性。因为 Skill 定义的是“必须遵守的底线”和“推荐遵循的流程”而不是“唯一正确的答案”。AI 在执行 Skill 时仍然可以根据具体情况做出判断和调整。真正让 AI 死板的是那些写得过于僵化、不留任何余地的 Skill这是写作者的问题不是 Skill 机制本身的问题。8.6 怎么知道一个 Skill 有没有生效最直接的方法是看 AI 的输出是否符合 Skill 中定义的规范。如果 Skill 要求“每个函数必须有文档字符串”而 AI 生成的代码没有说明 Skill 没有生效。这时候需要检查Skill 文件是否放在了正确的目录、触发条件是否匹配、文件格式是否正确。有时候 AI 会部分执行 Skill 的内容这时候需要检查 Skill 中是否有相互矛盾的指令。8.7 Skill 需要定期更新吗需要。工具版本更新、项目规范变化、个人偏好调整都会导致原有 Skill 不再适用。我建议至少每季度检查一次看看有没有需要更新的地方。如果发现某个 Skill 经常出问题说明它需要重新设计而不是小修小补。8.8 多个 Skill 之间会冲突吗有可能。如果两个 Skill 对同一件事给出了不同的指令AI 可能会困惑。比如一个 Skill 说“代码注释用中文”另一个说“代码注释用英文”同时加载就会冲突。避免冲突的方法是在写 Skill 时就明确它的适用范围不要和其他 Skill 重叠。如果确实需要同时使用多个 Skill要确保它们之间没有矛盾的指令。8.9 怎么评估一个 Skill 的质量我通常从几个维度评估触发准确率该调用的时候有没有调用、执行完整度定义的步骤有没有全部执行、输出稳定性多次执行结果是否一致、维护成本是否需要频繁修改。这四个维度都表现好的 Skill就是高质量的 Skill。8.10 Skill 的未来会怎么发展从目前的趋势看Skill 正在从“个人工具”向“团队资产”演变。越来越多的团队开始把 Skill 作为知识管理的一部分把老员工的经验沉淀成 Skill 文件让新成员能快速上手。同时Skill 的格式和标准也在逐步统一未来可能会出现跨平台通用的 Skill 规范。对于个人来说现在开始积累自己的 Skill 库是在为未来的效率提升打基础。