1. 为什么要从“会聊天”转向“能交付”Skills解决的不只是效率问题市面上聊Claude和Cursor的文章很多但真正讲清楚Skills如何改变交付质量的却不多。我过去一年一直是这两款工具的深度用户经历过只会从对话框里要答案的阶段也经历过把AI当“结对程序员”的时期。最后让我觉得“手上终于有完整工具箱”的不是更长的提示词而是一套经过整理的Skills。往简单了说Skills就像给AI装的“领域插件”装上之后它能按照你熟悉的规范、流程和输出格式来干活而不是每次都在自由发挥。也是从第一次把Skill跑通开始我才彻底理解“会聊天”和“能交付”之间那条真正的分界线。聊天是逐轮交互交付是稳定产出可用结果。一个能把你的开发规范、错误排查路径、文档模板都固化成文件的能力才是让Claude和Cursor从“聪明”变成“靠谱”的关键。1.1 Skills到底是什么一套可复用的“领域插件”Skills在Claude Code里的官方叫法是Agent Skills核心是把一段“工作手册”写成结构化文件让模型在执行任务前主动阅读并遵循。通常一个Skill就是一个文件夹里面有SKILL.md主文件还能附带参考文档、脚本、模板等辅助资源。模型在对话中判断当前任务和某个Skill的description匹配就会在后台加载这个文件夹里的全部内容然后按里面的规则行动。我常用一个生活化类比你不可能一上来就给一个新人实习生讲完整套公司流程但你会给他一份《新人入职手册》里面写清楚周报模板、代码规范、发布流程和常见问题的处理方案。Skills就是给AI的《新人入职手册》。区别在于这份手册不是一次性粘贴进对话框里的而是放在固定目录里需要时AI自己取用。目录结构一般长这样my-skill/ SKILL.md reference/ coding-standards.md scripts/ check-template.pySKILL.md的开头用YAML描述名称和触发条件正文写具体指令。关键点在于description一定要写清楚“什么时候用”因为模型先靠description来决定是否加载这个Skill。1.2 装了Skills之后Claude/Cursor会有什么不一样没有Skills的时候你需要在每次对话里重新交代背景、规范、输出格式。几分钟的对话可能有一半是在重复“请按我们团队的风格写”“记得生成测试”“不要用某个库”。装了Skills之后这些上下文全部沉淀在文件里提示词可以短到只剩一句“帮我生成用户管理模块”剩下的细节模型会从Skill文件里自己拿。我感受到的差异有三个。第一是输出稳定性明显提高同样的需求连续问三次结果更接近不会一次用函数式、一次用面向对象。第二是可复用性变强团队里一个人维护Skills文件其他人拉下来就能获得同样的“经验值”。第三是交接成本下降新成员看一遍Skill目录就能理解你们团队的开发习惯和交付标准。Skills不是只能给程序员用。我做研究、写技术文档、做安全审计时也分别配了不同SkillClaude和Cursor都可以通过这套机制变成特定领域的“熟练工”。这也是我把这套工具箱叫“从会聊天到能交付”的原因它让你使用AI的方式从碰运气变成靠体系。2. 我的8个Skills工具箱从对话到交付的完整链路接下来分享我目前在用的8个Skills。它们覆盖了一个需求从想法到落地的完整链路先搭结构、再做页面、然后画架构图、写代码、补测试、出文档、最后做安全审查。这套组合并非一开始就设计好的而是我在实际项目里不断“缺什么补什么”沉淀出来的。Skill名称解决的核心问题典型场景脚手架生成器项目初始化慢、目录结构不统一从需求描述生成项目骨架前端开发助手页面开发中组件、样式、交互不标准生成Vue/React页面与组件结构图设计师需求文档与架构图脱节把文字需求变成结构图/Mermaid代码审查官PR中的逻辑漏洞和风格问题难发现自动扫描合并请求并给出评论测试用例生成器边界条件覆盖不足为函数或接口生成单测用例文档管家文档维护成本高、更新不及时生成README、CHANGELOG、提交信息学术研究辅助文献多、提炼慢、引用格式乱读论文、整理综述、生成参考文献安全审计助手上线前容易忽略安全配置在授权范围内扫描代码漏洞下面逐个说。2.1 脚手架生成器一句话变出可运行项目这个Skill我用来解决“从0到1”的启动问题。以前新开一个项目要花半小时配置目录、lint规则、构建脚本、路径别名现在只需要告诉Claude或Cursor“创建一个pnpm Vite TypeScript的前端项目带src、tests、docs目录使用ESLint Prettier并配置路径别名”脚手架Skill就会按照预置的模板生成整套目录结构。我建议在Skill里放一到两个完整的项目模板而不只是文字说明。因为模型在生成文件时如果有真实模板作为参考生成速度更快结构也更稳定。这个Skill对新手特别友好哪怕不太熟悉工程化配置也能得到一个规范起步的项目骨架。2.2 前端开发助手从布局到组件的“业务老手”前端开发Skill是我每天使用频率最高的一个。它里面写了具体的技术栈约定组件用函数式组件还是类组件、样式用CSS Modules还是Tailwind、状态管理用哪个库、API请求统一走哪个封装层。当我说“帮我写一个用户列表页面”时模型不会从零瞎猜而是按照Skill里的规范生成符合当前项目风格的代码。我还在这里放了一份“常见交互模式清单”包括表格分页、表单校验、弹窗确认、空状态处理等。这些场景很琐碎但每次重复写会占据大量时间。有了前端开发Skill之后我可以直接要求“按清单里的模式处理”输出质量基本稳定。如果是团队协作这份Skill还能充当“代码规范解释器”让所有AI生成的内容风格一致。2.3 结构图设计师让需求变成能讨论的蓝图很多人说自己“脑子里有思路但画不出图”结构图设计师Skill就是干这个用的。它专门负责把一段杂乱的需求文字转换成清晰的架构图、流程图、时序图或ER图。我一般会在Skill里给出若干示例包括系统模块图、数据流向图、部署拓扑图以及对应的图表语法模板。实际使用中这个Skill最妙的地方在于它能让讨论提前。以前需求评审时大家对着文档各说各话现在我会先让AI生成一版架构图扔到会议里让大家直接看图提意见。修改也比手工画图方便得多用对话描述“把支付模块拆出来加一个消息队列”它就能立刻改出新版图。结构图Skill不是画画工具而是帮你把模糊想法快速变成可以被质疑、被修改的讨论介质。2.4 代码审查官在合入前揪出80%的问题代码审查Skill不只是查语法错误我让它重点干三件事看逻辑漏洞、看安全隐患、看代码可读性。具体写法上我在Skill里定义了审查流程比如先通读变更再逐函数分析分支条件最后检查错误处理和资源释放。举个例子我曾经让它审查一个订单超时处理的PR。普通静态检查工具只会提示“Missing default branch”但这个Skill会追问超时时间从哪里读取状态变更有没有考虑并发如果订单支付刚好在超时前到达怎么办这些正是在真实review中容易被忽略的点。有了这个Skill我能把更多的审查精力放在设计层面而不是沦为“人形lint工具”。2.5 测试用例生成器把边界情况交给AI帮你“抬杠”很多开发者写需求代码很快一到写测试就拖延。测试用例生成Skill的价值在于它会主动站在“抬杠”的角度去思考如果参数是null怎么办如果金额是负数怎么办如果网络请求超时又重发怎么办它会按边界值、异常路径、正常路径三个维度生成测试用例并且直接产出可运行的单元测试代码。我在Skill里加入了一条强制要求“在生成用例前先列出至少5个边界条件和异常场景再开始写代码。”这能让AI先思考后动手而不是冷冰冰输出一堆模板测试。实测下来这个Skill尤其适合接口层和工具函数层能把覆盖率从50%左右拉到80%以上。2.6 文档管家自动维护README、CHANGELOG与提交信息文档是最容易被忽视的交付物。文档管家Skill承担了三个职责生成新项目README、维护CHANGELOG、根据git改动生成符合规范的提交信息。它会在生成文档前先扫描仓库结构、读取关键配置和现有注释再按模板输出。我特别喜欢的是提交信息这个功能。以前commit message写得随意回头排查问题时根本看不懂。现在用文档管家Skill生成的信息会带上影响范围和改动原因团队回溯版本时能省下大量时间。对于技术博主或开源维护者这个Skill还能把代码改动自动整理成更新日志配合release流程会很顺手。2.7 学术研究辅助读论文、找引用、整理综述这个Skill比较“跨界”但它直接解决我写技术方案时查资料慢的问题。学术研究辅助Skill会读取PDF或笔记提炼研究问题、方法、结论并按指定引文格式生成参考文献。我还会让它把多篇文献按主题合并生成一个带对比表格的综述草稿。有一次我需要快速了解某个算法的变体演进就让Claude Code加载三篇论文用这个Skill生成一张对比表包含年份、核心思路、优缺点和适用场景。以前这活儿要花一整天现在一小时就能出初稿。需要特别提醒的是AI生成的参考文献索引仍需要人工核对不能完全甩手。2.8 安全审计助手用攻击者视角检查授权系统安全审计助手的核心思路是让AI带着攻击者的视角读代码但只作用于你有权限审查的系统并且只做代码层面的风险提示不执行任何未授权操作。我会让它检查SQL拼接、硬编码密钥、越权访问、目录穿越、依赖版本漏洞等常见问题输出格式统一为“风险等级 问题位置 复现思路 修复建议”。实际用下来它在扫描历史代码时很有效。有一次我发现一个老项目的登录接口日志会打印完整密码就是被这个Skill精准定位出来的。这里再强调一遍安全审计Skill要在合法授权范围内使用把它当成代码健康检查工具而不是攻击工具。审查对象是你自己负责的系统逻辑才能站得住脚。3. 安装与配置在Claude Code和Cursor里跑通第一个Skill聊完8个Skills的用途你更关心的应该是怎么把它们装进自己的工具里。这里我先以Claude Code为主讲完整安装流程再补充Cursor的配置思路。其实两者的核心机制差不多都是“放一个文件夹 让模型知道什么时候调用”。3.1 Claude Code一条命令装好一个目录放Skill首先确认你的电脑上已经安装了Claude Code。官方推荐通过npm安装命令是npm install -g anthropic-ai/claude-code安装完成后检查版本claude --version如果提示claude不是可用命令多半是npm全局目录没有写入PATH。解决方式也很简单执行npm config get prefix找到全局安装路径再把对应的bin目录加进系统环境变量即可。这个话题和很多“claude code安装”相关的报错都能对上。接下来创建个人级别的Skills目录。Claude Code会读取以下几个位置按优先级从高到低项目级.claude/skills/跟着仓库走适合团队共享用户级~/.claude/skills/个人全局生效适合自己的常用Skill以创建“脚手架生成器”Skill为例mkdir -p ~/.claude/skills/scaffold-generator/reference然后创建SKILL.md内容大致如下--- name: scaffold-generator description: 当用户想从零创建项目、生成目录结构或初始化工程时使用 --- # 项目脚手架生成器 根据用户的技术栈和项目描述生成完整的项目目录结构。 ## 步骤 1. 确认技术栈与包管理器 2. 列出目录结构和关键文件清单 3. 生成配置文件、基础源码和README模板 ## 参考模板 见 reference/project-templates.md写完保存后重新启动Claude Code这个Skill就已注册。使用的时候不需要专门喊它的名字你直接说“帮我初始化一个Vue3项目”模型读到“初始化项目”就会匹配到这个Skill的description。3.2 Cursor用Rules和项目级Skills文件补足能力Cursor目前对Skills的支持路径跟Claude Code略有差别但思路相通。我自己常用的做法是两种结合项目规则和Skill文件夹。第一步在项目根目录创建.cursor/rules文件或者在Cursor设置里的Project Rules中加入一行“参考 .cursor/skills 目录下的Skill文件”让模型知道去哪里找。这一步很关键因为很多新手把Skill文件放进去了但模型根本不知道它的存在。第二步在项目根目录创建.cursor/skills/结构与Claude Code的Skill格式保持一致。这样同一套Skills文件可以同时给Claude Code和Cursor用。至于很多人关心的“Cursor中文设置”在界面左下角设置里找到语言选项改成简体中文即可但这不影响Skills文件的内容格式我建议Skills里的描述还是保留中英双语兼容性更好。还有一点Cursor本身支持Agent模式在Agent模式下多轮执行任务时更容易触发模型去读取外部Skill文件。如果你只是在普通的Chat面板里问问题加载外部文件的概率会低不少。想要最完整的体验建议用Agent模式跑。3.3 验证Skill是否生效两个排查小技巧装完Skill最怕的就是它“没反应”。我通常用两个方法验证。第一个方法是“直接调用法”。在一个新对话里输入和Skill用途强相关的指令比如“生成一个React项目的目录结构”然后故意一句话都不提具体规范。如果Skill生效模型生成的内容会明显带有SKILL.md里的风格比如目录结构里出现reference目录、带上了你在Skill里指定的ESLint版本。如果回答很随意、什么都不带那大概率Skill没被加载。第二个方法是“日志确认法”。在Claude Code里可以用verbose模式观察模型到底加载了哪些文件。如果看到模型读取了你的SKILL.md就说明路径和description都写得没问题。如果在Cursor里我会在生成结果中加一句“你参考了哪些文件”让模型把读取到的文件列出来也算一种直观确认。3.4 第三方Skills精选Superpower Skills与社区资源怎么选除了自己写社区里也有很多现成的Skills集合其中最有名的就是Superpower Skills还有一些开发者整理的中文Skills仓库。这些集合的好处是开箱即用品类覆盖广从代码生成到文档整理都有。但危险也在这里一次性装几百个Skills反而会让模型不知道该调哪个。我筛选第三方Skills的标准有三条。第一看description是否明确那种一个Skill能包办所有事情的通常什么都做不好。第二看文件结构是否精简一个Skill塞了几十份文档的话即使匹配了也会浪费上下文。第三看更新活跃度长期没人维护的Skill在最新模型版本下可能失效。我一般会把第三方Skill当成素材库把其中适合自己的部分摘出来再用自己的项目风格改一遍。这样既省了从零写的时间又不会因为全盘照搬而水土不服。4. 实战三个任务看“能交付”与“会聊天”的真正差距这套Skills有没有用看真实任务最直接。我准备了三个任务生成前端项目页面、把需求文档转成架构图、审查一个质量有点问题的PR。每个任务都用同一个原则提示词尽量短默认让Skill接管细节。4.1 从零生成一个带接口的Vue3后台页面我给脚手架Skill和前端的Skill同时在场的情况下输入提示词创建一个Vue3 TypeScript Pinia项目并实现一个商品列表页面包含搜索、分页、表格、删除确认接口地址先写成mock。这个任务如果靠“聊天”模型大概率会生成一堆文件但目录混乱、样式不统一、接口封装各写各的。而有了Skills的约束后模型会按脚手架模板先建好目录结构再按前端开发Skill里的组件规范生成页面。我得到的结果是src/api/product.ts统一封装接口src/views/product/index.vue页面主逻辑src/components/ProductTable.vue表格组件src/stores/product.tsPinia状态管理src/styles/下自动引入全局基础样式整个过程中我只说了一句话。表面上看是AI聪明实际上是因为Skill把项目模板、组件设计原则和接口风格都提前喂给了模型。没有这些文件同样的提示词只会得到一堆“看起来能用但没法接进真实工程”的零散代码。4.2 把三段需求描述画成一张技术架构图这个任务的输入是一段很混乱的需求描述大意是“用户在小程序下单后端需要同步订单到ERP还能做促销活动订单要支持多渠道”。我让结构图设计师Skill先输出系统模块图和订单主流程图。Skill自动生成了模块划分小程序端、订单服务、商品服务、促销服务、ERP同步模块、消息队列。它还补充了我没明说的点ERP同步应该做成异步任务避免接口超时促销活动需要单独的时间判断模块以免影响订单主流程。这些判断并不是模型凭空冒出来的而是结构图Skill里写了大量关于“识别隐藏依赖”“划分边界”的规则。它输出的结果可以直接粘贴到支持Mermaid语法的文档工具里展示也可以在Cursor的图表预览里渲染成图。比起手绘架构图这个效率提升是肉眼可见的。更重要是在AI的引导下我提前发现了“促销模块和订单模块的状态耦合”这个坑在评审阶段就改掉了设计。4.3 用代码审查Skill扫描一个“看似能跑”的合并请求我拿一个真实PR做测试改动是“给订单列表增加按状态筛选”。代码本身没明显报错但代码审查Skill直接列出了几个问题筛选状态直接拼接进SQL存在注入风险每次筛选都全表查询没有走索引列表接口把数据库查询逻辑写在Controller层职责混乱没有处理状态参数为空字符串的边界情况这些判断看起来像是资深工程师在review其实是Skill文件里写了“先看数据流再看边界条件最后看性能”的流程并且给了大量错误示例作为对照。这让我意识到一个写得好的Skill可以继承经验而不仅继承规则。代码审查Skill正是在把“多年踩坑经验”转换成模型能执行的检查清单。5. 避坑指南我用Skills时踩过的5个坑工具再好用坑也不少。我把用过Skills之后遇到的最典型的5个问题列成一个速查表每个都附上原因和我的解决办法。现象可能原因解决办法Skill怎么都不生效description写得太宽泛模型匹配不上把description改成“当用户想创建项目时”这类强触发语句生成结果明显偏离Skill内容模型上下文太长Skill文件被截断精简SKILL.md把细节拆到reference子文件多个Skill抢同一个任务多个description描述重叠给每个Skill限定更窄的触发范围模型变得“教条”Skill里规则太多限制了灵活判断在Skill里加入“如果用户有明确要求以用户为准”升级后Skill失效工具语法或模型能力变化订阅更新日志定期重构Skill模板5.1 SKILL.md没被加载八成是description写得太“像聊天”我自己早期写的Skilldescription是“帮助用户生成代码、解答问题、提供建议”——这等于没写。模型遇到任何任务都有可能匹配它也可能都不匹配。后来我总结出一个原则description要模拟“一个实习生会在什么情况下翻看这本手册”它应该包含明确的动作和场景词。比如“当用户想从零开始创建项目并需要完整的目录结构时使用”就比“用于项目开发”强得多。description写好了Skill生效的概率会高很多。这也是我排查“Skills不生效”时第一个检查的地方。5.2 一个Skill塞了五万字上下文预算怎么控制Skill不是越详细越好。模型每次加载Skill都会占用上下文窗口如果一份SKILL.md内容太长会把宝贵的token预算耗尽反而影响回答质量。我现在的习惯是SKILL.md只保留最核心的规则和步骤不超过2K token详细模板、示例代码、项目规范放到reference目录下的子文件里。模型可以根据需要按文件名读取而不是一股脑全加载。这样既保留了信息又控制了上下文占用。5.3 命名冲突多个Skill抢同一个场景随着Skills越来越多会有两个Skill同时声称自己能处理“生成前端页面”。这时模型可能随机选择输出结果就不稳定。我的解决办法是给每个Skill增加一个优先级字段或者在description里明确细分。比如“脚手架生成器”只管初始化阶段“前端开发助手”只管已有项目里的页面开发这样两者边界清晰模型就不会选择困难。5.4 别让Skill代替你思考什么时候该关掉它有一段时间我过于依赖代码审查Skill它说改哪里我改哪里结果发现它在某个老项目里固守新项目规范反而不适用。后来我学会在特殊任务前关闭Skill或者对话里明确“这次不用参考某个Skill直接按我的要求来”。Skills是工具箱里的工具不是坐在屏幕前的决策者。保持“遇到新情况会停下来问人”的习惯AI才能成为好的协作者。5.5 Cursor/Claude Code版本更新带来的兼容性Cursor和Claude Code都处于快速迭代期Skills的目录结构、加载方式、甚至是模型对SKILL.md的解读方式都可能改变。记得有一次Claude Code更新后我突然发现项目级Skill不读取了查了半天才知道原来是新版本把项目级目录从.claude/skills迁移到了别的位置。遇到这种情况最直接的解决方式是查看官方changelog同时把Skills配置纳入版本控制。我会把自己的Skills统一放在一个ops-skills仓库里升级工具后一旦发现异常能快速对比历史版本而不是面对一整个目录抓瞎。最后再分享一个我自己的小偏好我会把Skills当成“可迭代的代码”来维护每两周复盘哪些Skill用得最多哪些从来没用上然后删掉没用的优化常用的。这套8个Skills就是从最初20多个Skill里慢慢筛选出来的。工具可以越装越多但真正好用的工具箱一定是经过时间和真实业务筛选过的。
