1. 从“写不出提示词”到“1500个Skill随取随用”AI编程的痛点到底在哪用AI写代码这件事很多人卡住的地方其实不是模型不够聪明而是自己不知道该怎么说。你打开Cursor或者Claude Code面对一个空白对话框脑子里想的是“帮我写个登录功能”敲出来的也是“帮我写个登录功能”然后AI给你吐出来一段能跑但完全不符合你项目结构的代码。改吧不知道从哪改不改吧又确实不能用。这个场景我相信每个用过AI编程工具的人都经历过。问题的根源在于大多数人把AI编程当成了“搜索引擎升级版”觉得只要把需求描述清楚就行了。但实际上AI编程的核心能力不在于“问”而在于“给”——给它足够的上下文、给它明确的规则、给它可复用的模式。这就是Skill这个概念存在的意义。所谓Skill你可以把它理解成一份写给AI看的“操作手册”。它不是提示词模板那种简单的一句话而是一整套包含角色定义、任务流程、输出规范、边界条件、示例参考的结构化文档。一个设计良好的Skill能让AI在你指定的领域里表现得像一个有三年经验的熟手而不是一个刚入职的实习生。那1500个现成Skill意味着什么意味着你不需要从零开始琢磨“怎么跟AI说才能让它写出好代码”而是可以直接拿别人验证过的Skill来用或者在此基础上改吧改吧就成了自己的。这就像做菜你可以选择从种菜开始也可以选择去菜市场买现成的食材然后按自己的口味调味。绝大多数情况下后者效率更高。这篇文章适合几类人看第一类是用过Cursor、Claude Code、Windsurf这些工具但总觉得“差点意思”的开发者第二类是刚开始接触AI编程不知道从哪里入手的新手第三类是想把AI编程能力引入团队工作流的技术负责人。不管你是哪一类接下来的内容都会围绕一个核心问题展开怎么用Skill把AI编程从“碰运气”变成“可复现”。2. Skill到底是什么为什么它比提示词高一个维度2.1 从提示词到Skill的进化逻辑提示词是你对AI说的一句话Skill是你给AI的一套工作规范。这两者的区别就像你让一个装修师傅“帮我刷个墙”和给他一份包含色号、涂料品牌、施工步骤、验收标准的施工方案。前者他也能干但结果大概率不是你想要的后者他照着做出来的东西基本可控。我刚开始用Claude Code的时候也是直接写提示词。比如“帮我写一个React组件包含表单验证”出来的代码能用但每次风格都不一样有时候用useState有时候用useReducer有时候把验证逻辑写在组件里有时候抽出去。后来我把这些要求写成了一个Skill文档明确规定了“所有表单组件必须使用react-hook-form、验证逻辑必须抽离到独立的validators目录、错误提示必须使用统一的ErrorText组件”从此以后生成的代码就稳定多了。Skill的核心价值在于消除歧义。自然语言天然是模糊的你说“写个好看的按钮”AI不知道你说的好看是圆角还是直角、是渐变还是纯色、是阴影还是扁平。但如果你在Skill里写清楚了“按钮样式遵循项目design-system/button.md中的规范”AI就能精确执行。2.2 一个Skill的标准结构长什么样我拆过不少高质量的Skill总结下来一个能打的Skill通常包含这几个部分角色定义告诉AI它现在是谁。比如“你是一个有五年经验的React前端工程师熟悉TypeScript和Tailwind CSS”。任务描述明确这个Skill解决什么问题。比如“根据用户提供的Figma设计稿生成对应的React组件代码”。输入规范用户需要提供什么信息。比如“需要提供组件名称、props定义、设计稿截图或描述”。输出规范生成的代码需要满足什么标准。比如“必须使用函数式组件、必须包含PropTypes或TypeScript类型定义、必须导出默认组件”。流程步骤AI应该按什么顺序工作。比如“第一步分析设计稿结构第二步确定组件拆分方案第三步生成代码第四步自查”。边界条件什么情况下不应该使用这个Skill。比如“如果设计稿包含复杂的动画交互请先与用户确认动画实现方案”。示例参考给一个输入输出的例子让AI有样学样。这七个部分里输出规范和边界条件是最容易被忽略但最重要的。很多人写Skill只写了“做什么”没写“做到什么程度”和“什么不能做”结果AI要么过度发挥要么在边缘情况下胡来。2.3 为什么是1500个而不是50个数量本身不是目的但1500这个量级说明了一件事Skill已经覆盖了足够多的场景你大概率能找到跟自己需求匹配的那一个。我粗略统计过常见的Skill分类大概有这么几大类分类典型Skill适用场景前端开发React组件生成、Vue页面搭建、CSS样式调整Web应用开发后端开发API接口生成、数据库模型设计、中间件配置服务端开发数据处理数据清洗、格式转换、可视化图表数据分析自动化脚本文件批量处理、定时任务、爬虫运维和效率工具代码审查安全漏洞检测、性能优化建议、代码规范检查代码质量管理文档生成API文档、README、注释补全项目维护测试相关单元测试生成、集成测试、Mock数据质量保障1500个Skill意味着几乎每个细分场景都有现成的方案可以参考。你不需要成为提示词工程师只需要找到对的Skill然后根据自己项目的情况微调。3. 怎么找到并筛选适合你的Skill3.1 搜索Skill的正确姿势很多人找Skill的方式是直接搜“React Skill”或者“Python Skill”这样搜出来的结果要么太泛要么不匹配。更有效的方式是按具体任务来搜。比如你要写一个带分页的表格组件不要搜“前端Skill”搜“table pagination component”或者“分页表格生成”。你要写一个定时清理日志的脚本搜“log rotation script”比搜“运维Skill”精准得多。另外注意看Skill的更新时间和使用反馈。一个2023年写的React Skill可能还在用class组件而2024年之后的Skill基本都默认函数式组件了。使用反馈多的Skill通常经过更多人验证踩坑的概率更低。3.2 判断一个Skill质量的四个维度找到Skill之后怎么判断它值不值得用我一般看这四个方面第一看它的输出规范是否具体。好的Skill会明确说“生成的代码必须通过ESLint检查”或者“函数复杂度不超过10”差的Skill只会说“生成高质量的代码”。什么叫高质量没人知道。第二看它有没有处理边界情况。比如一个“生成API接口”的Skill如果只说了正常流程怎么处理没提参数校验失败、数据库连接超时、并发冲突这些情况那在实际项目里用起来就会很痛苦。第三看它的示例是否完整。好的Skill会给出一个完整的输入输出示例你能清楚地看到“如果我这样输入AI会那样输出”。差的Skill只给一个片段你根本不知道全貌。第四看它是否与你的技术栈匹配。一个用Vue写的Skill你拿到React项目里用虽然逻辑可能相通但具体代码肯定要改。与其改别人的不如找一个技术栈匹配的。3.3 我个人的Skill筛选流程我自己的流程是这样的先按任务关键词搜找到5到10个候选然后快速扫一遍每个Skill的结构筛掉那些只有一两句话的接着看示例和输出规范筛掉那些含糊其辞的最后拿一个实际的小任务试跑一下看生成结果是否符合预期。试跑这一步很关键。有些Skill看起来写得很漂亮但实际跑起来AI根本不按它说的做。原因可能是Skill太长超出了上下文限制也可能是指令之间有冲突。试跑一次就能暴露这些问题。提示不要一次性下载几百个Skill囤着。Skill的价值在于用不在于收集。找到三五个真正适合你当前项目的吃透它们比囤一千个用不上的强得多。4. 把Skill用起来从安装到落地的完整流程4.1 不同工具对Skill的支持方式Claude Code、Cursor、Windsurf这几个主流工具对Skill的支持方式不太一样我分别说一下。Claude Code对Skill的支持是最原生的。你可以在项目根目录下建一个.claude/skills文件夹把Skill文件放进去然后在对话中用/skill 名称来调用。Claude Code会自动读取Skill内容并按照里面的规范来执行。如果你用的是VS Code里的Claude Code插件配置方式是一样的只是文件路径可能需要在设置里指定一下。Cursor没有原生的Skill概念但你可以用.cursorrules文件来实现类似的效果。把Skill的核心内容写进.cursorrulesCursor在生成代码时就会参考这些规则。缺点是.cursorrules是全局生效的不能像Claude Code那样按需调用不同的Skill。不过你可以在项目里建多个.cursorrules文件通过切换项目来切换规则。Windsurf支持一种叫“Workflow”的机制本质上和Skill是一回事。你可以在Windsurf的设置里创建Workflow定义触发条件和执行步骤。Windsurf的Workflow支持更复杂的条件判断适合需要多步骤协作的场景。4.2 以Claude Code为例的完整配置流程假设你已经安装好了Claude Code下面是从零开始配置一个Skill的步骤。第一步在项目根目录创建Skill目录mkdir -p .claude/skills第二步创建一个Skill文件。比如我们要做一个“React组件生成”的Skill新建文件.claude/skills/react-component.md内容如下# React Component Generator ## Role 你是一个有五年经验的React前端工程师精通TypeScript、Tailwind CSS和React Hooks。 ## Task 根据用户提供的组件需求生成符合项目规范的React函数式组件代码。 ## Input 用户需要提供组件名称、功能描述、props定义可选、样式要求可选。 ## Output 生成的代码必须满足 - 使用函数式组件和TypeScript - 使用Tailwind CSS进行样式编写 - 组件文件放在src/components目录下 - 必须导出默认组件 - 必须包含Props类型定义 - 复杂逻辑必须抽离为自定义Hook ## Process 1. 分析用户需求确认组件职责 2. 设计Props接口 3. 编写组件代码 4. 自查是否满足Output中的所有要求 ## Constraints - 如果需求涉及复杂动画先与用户确认动画方案 - 如果组件需要请求数据使用项目已有的useRequest Hook - 不要生成class组件 ## Example 输入一个显示用户头像和昵称的卡片组件 输出src/components/UserCard.tsx包含UserCardProps类型定义和默认导出第三步在Claude Code对话中调用这个Skill/skill react-component 帮我生成一个显示用户头像和昵称的卡片组件Claude Code会读取Skill文件然后按照里面的规范生成代码。4.3 参数计算与选择Skill文件该写多长Skill文件不是越长越好。我试过写一个两千字的Skill结果Claude Code处理起来反而变慢了而且有时候会忽略后面的内容。后来我总结了一个经验单个Skill文件控制在500到800字之间最合适。这个长度大概能容纳角色定义50字、任务描述100字、输入输出规范200字、流程步骤150字、边界条件100字、示例100字。超过这个长度要么拆成多个Skill要么精简内容。如果你确实需要很长的规范比如一个完整的代码风格指南建议把它拆成多个小Skill每个Skill负责一个方面。比如“命名规范Skill”、“注释规范Skill”、“错误处理Skill”分开写用的时候组合调用。4.4 实操现场用Skill生成一个完整的登录页面我拿一个实际例子来演示。需求是生成一个包含邮箱密码登录、表单验证、错误提示的登录页面。首先调用Skill/skill react-component 生成一个登录页面组件包含邮箱和密码输入框、表单验证、错误提示、提交按钮。使用react-hook-form做表单管理zod做验证。Claude Code读取Skill后会按照规范生成代码。我截取关键部分// src/components/LoginForm.tsx import { useForm } from react-hook-form; import { zodResolver } from hookform/resolvers/zod; import { z } from zod; const loginSchema z.object({ email: z.string().email(请输入有效的邮箱地址), password: z.string().min(8, 密码至少8位), }); type LoginFormData z.infertypeof loginSchema; export default function LoginForm() { const { register, handleSubmit, formState: { errors } } useFormLoginFormData({ resolver: zodResolver(loginSchema), }); const onSubmit (data: LoginFormData) { // 提交逻辑 }; return ( form onSubmit{handleSubmit(onSubmit)} classNamespace-y-4 {/* 表单内容 */} /form ); }注意看生成的代码完全符合Skill里定义的规范函数式组件、TypeScript、Tailwind CSS、默认导出、Props类型定义这里是表单数据类型、复杂逻辑抽离验证逻辑在schema里。这就是Skill的价值——你不需要每次都在提示词里重复这些要求Skill帮你记住了。5. 常见问题与排查技巧实录5.1 Skill不生效怎么办这是最常见的问题。你明明配置了Skill但AI生成的结果完全不按Skill来。排查思路如下先检查文件路径。Claude Code默认读取.claude/skills目录如果你放在别的地方需要在设置里指定。Cursor的.cursorrules必须放在项目根目录放在子目录里不生效。再检查文件格式。Skill文件必须是Markdown格式扩展名是.md。有些工具对文件编码有要求建议用UTF-8。然后检查调用方式。Claude Code里必须用/skill 名称来调用直接写提示词是不会触发Skill的。Cursor的.cursorrules是自动生效的不需要手动调用。最后检查Skill内容是否有冲突。如果你同时配置了多个Skill它们之间的指令可能互相矛盾。比如一个Skill说“使用Tailwind”另一个说“使用CSS Modules”AI就不知道该听谁的。5.2 生成的代码不符合项目规范Skill里写了规范但AI生成的代码还是不符合通常有两个原因。一是规范写得太模糊。比如你写“使用项目已有的组件库”但AI不知道你的组件库叫什么、有哪些组件。改成“使用src/components/ui目录下的Button、Input、Form组件”AI就能精确引用了。二是AI的上下文里没有项目信息。Skill只是告诉AI“应该怎么做”但AI还需要知道“项目里有什么”。解决办法是在Skill里引用项目文件比如“组件样式参考src/styles/theme.ts中的定义”。Claude Code支持在Skill里引用其他文件Cursor则需要你把关键信息直接写进.cursorrules。5.3 多个Skill之间如何协作实际项目中一个任务往往需要多个Skill配合。比如“生成一个带API请求的用户列表页面”既需要“React组件生成”Skill又需要“API请求封装”Skill。Claude Code支持在一个对话中依次调用多个Skill。你可以先调用组件生成Skill再调用API SkillAI会把两者的输出结合起来。但要注意Skill的调用顺序会影响结果。先调用组件Skill再调用API Skill和反过来生成的代码结构可能不一样。我的经验是先调用定义数据结构的Skill再调用生成UI的Skill。因为UI依赖数据结构先把数据定下来UI生成时就有明确的类型可以参考。5.4 常见问题速查表问题现象可能原因解决方法Skill完全不生效文件路径错误检查是否放在指定目录Skill部分生效内容有冲突检查多个Skill之间是否矛盾生成代码风格不一致规范太模糊把规范写具体引用项目文件Skill处理速度慢文件太长拆分成多个小Skill调用Skill报错格式不正确检查Markdown格式和编码生成的代码缺少类型输出规范没写在Output里明确要求类型定义5.5 我踩过的三个坑第一个坑是Skill写得太泛。我最早写了一个“前端开发Skill”内容涵盖组件、样式、路由、状态管理结果AI每次生成代码都只关注其中一部分其他部分完全忽略。后来拆成四个独立Skill每个专注一个方面效果就好多了。第二个坑是在Skill里写了太多“不要做什么”。比如“不要使用any类型”、“不要写内联样式”、“不要用class组件”写了一大堆禁止项。结果AI变得畏手畏脚生成代码时反复自查速度慢了很多。后来我把禁止项精简到最关键的几条其他通过示例来暗示效率就上来了。第三个坑是忘了更新Skill。项目技术栈升级了比如从Tailwind 2升到Tailwind 3但Skill里还写着旧版本的配置方式生成的代码就跑不起来。现在我养成了习惯每次项目依赖升级同步检查一遍相关的Skill文件。注意Skill不是一劳永逸的。项目在变Skill也要跟着变。建议每个月花十分钟回顾一下正在使用的Skill看看有没有需要更新的地方。6. 从使用者到创造者怎么写出自己的Skill6.1 从现有Skill改起是最快的路径如果你找到了一个80%符合需求的Skill不要从零写新的直接改那个。改的时候重点关注三个地方输出规范、边界条件、示例。把输出规范改成你项目的标准把边界条件改成你遇到的特殊情况把示例换成你项目的真实代码。我自己的“React组件生成”Skill就是从别人的版本改来的。原版用的是CSS Modules我改成了Tailwind原版没有类型定义的要求我加上了TypeScript原版的示例是一个按钮组件我换成了项目里实际用的卡片组件。改完之后生成的代码直接就能用不需要再手动调整。6.2 用“反向工程”的方法提炼Skill如果你已经用AI生成了一段很满意的代码可以把这段代码反推成一个Skill。具体做法是分析这段代码满足了哪些规范把这些规范写成Skill的Output部分分析生成过程中你提供了哪些信息把这些信息写成Input部分分析生成步骤写成Process部分。这个方法特别适合团队协作。团队里有人用AI生成了一段好代码把它反推成Skill其他人就能复用同样的规范保证团队代码风格一致。6.3 Skill的版本管理Skill文件建议纳入Git管理和项目代码一起版本控制。这样每次修改都有记录出问题了可以回滚。如果团队多人使用还可以通过Pull Request来审核Skill的修改避免有人不小心改坏了规范。我在项目里建了一个.claude/skills目录里面每个Skill一个文件提交信息写清楚“修改了什么规范、为什么修改”。比如“react-component: 添加Tailwind 3的配置要求”或者“api-generator: 增加错误处理规范”。这样回头看的时候能清楚地知道每个Skill的演变过程。6.4 一个Skill从起草到稳定的时间线根据我的经验一个Skill从起草到稳定大概需要经历这几个阶段第一天起草初版写清楚角色、任务、输入输出规范。第一周在实际任务中试用三到五次记录哪些地方AI理解错了哪些规范没生效。第二周根据试用反馈修改补充边界条件和示例。第一个月再试用十次左右如果连续五次生成结果都符合预期基本就稳定了。之后随着项目变化做微调但核心结构不再大改。这个过程听起来慢但实际上每次修改只需要几分钟。而且一旦稳定下来后面用起来就非常省心。6.5 团队协作中的Skill共享机制如果是团队使用建议建一个共享的Skill仓库。每个人都可以提交自己的Skill经过审核后合并到主分支。新成员加入时直接拉取这个仓库就能获得团队积累的所有Skill。审核Skill时重点看三点一是输出规范是否与团队标准一致二是边界条件是否覆盖了常见异常三是示例是否使用了团队的真实代码。这三点没问题基本就可以合并了。另外建议定期组织Skill分享会。每个人讲讲自己最近写了什么Skill、解决了什么问题、踩了什么坑。这种分享比文档更生动也更容易激发新的想法。7. 一些关于Skill的冷思考Skill确实能大幅提升AI编程的效率但它不是银弹。我见过有人把Skill当成“自动写代码”的按钮以为配好了Skill就能什么都不管结果生成一堆跑不起来的代码反而浪费了更多时间。Skill的本质是把人的经验固化下来让AI去执行。它解决的是“怎么说”的问题不是“做什么”的问题。你仍然需要清楚自己要做什么需要判断生成的代码对不对需要在Skill覆盖不到的地方做决策。另外Skill的数量不是越多越好。我见过有人收集了三百多个Skill但实际常用的就五六个。剩下的要么场景太窄用不上要么质量不行不敢用。与其追求数量不如把常用的那几个打磨好。最后说一个我自己的体会写Skill的过程其实是在梳理自己的编程经验。当你试图把“怎么写出好代码”这件事写成一份AI能看懂的规范时你会发现自己对很多问题的理解其实并不清晰。写Skill逼着你把模糊的经验变成明确的规则这个过程本身就很有价值。如果你还没开始用Skill建议从一个小任务开始。找一个你经常重复的编程任务比如“生成一个CRUD接口”或者“写一个表单组件”试着把它写成Skill。第一次可能写得不好但改几次之后你会发现AI越来越懂你了。