1. 为什么我把CodeBuddy的Skills当回事第一次接触CodeBuddy的Skills功能我的反应跟大多数人一样又是一个听起来很美好的效率工具。毕竟这些年见惯了各种号称能让编程效率翻倍的东西从智能补全到代码生成真正能沉淀下来天天用的没几个。但用了大概两周之后我改主意了。Skills不是那种锦上添花的玩具它更像是把你脑子里那些每次都要重复一遍的隐性知识固化成了可复用的操作单元。说白了Skills解决的是一个很具体的痛点你在跟AI协作编程的时候每次都要重新解释一遍项目结构、代码规范、技术栈偏好、命名习惯。哪怕你用的是同一个AI编程助手换个会话窗口它就跟失忆了一样。Skills的价值就在于你把这些上下文一次性写好之后每次调用都自动带上不用再当复读机。这篇文章我打算聊五个我实际用下来觉得最值的Skills方向不是官方文档里那种Hello World级别的示例而是真正能嵌进日常开发流里的操作。适合谁看如果你已经在用CodeBuddy或者类似的AI编程工具但总觉得差点意思那这篇应该能帮你把那层窗户纸捅破。如果你还没开始用也可以先看看这些场景是不是你日常会遇到的再决定要不要入坑。2. 先搞清楚Skills到底在解决什么问题2.1 Skills和普通提示词的本质区别很多人第一次看到Skills会觉得这不就是保存了一段提示词吗我一开始也这么想。但用久了发现两者有个根本性的差异提示词是一次性的Skills是带上下文的。举个例子你让AI帮你写一个React组件。如果你只是丢一句帮我写个按钮组件它给你的东西大概率是能跑但不符合你项目规范的。但如果你有一个Skill里面定义了你项目的组件结构、样式方案比如用的是CSS Modules还是Tailwind、状态管理方式、甚至命名前缀那它生成的东西直接就能往项目里塞。更关键的是Skills可以嵌套和组合。你可以有一个基础代码规范的Skill然后在这个基础上叠加React组件开发的Skill再叠加单元测试生成的Skill。这种叠加不是简单的文本拼接而是有优先级的上下文注入。我实测下来这种分层结构比把所有东西塞进一个巨型提示词要稳定得多。2.2 为什么是这五个方向我选这五个Skills方向的标准很简单高频、通用、且能明显减少重复劳动。具体来说项目上下文注入解决AI不懂我项目的问题代码审查与重构解决AI写的代码我不敢直接用的问题Figma设计稿转代码解决设计到开发之间的翻译损耗的问题Craft模式下的多文件协作解决改一个地方要动十个文件的问题调试与错误排查解决报错信息看不懂的问题这五个方向覆盖了从开始写到写完检查再到出问题排查的完整链路。下面我逐个拆开讲每个都会给出具体的配置思路和实操中踩过的坑。3. 第一个Skill项目上下文注入3.1 为什么AI总是不懂你AI编程助手最让人抓狂的地方不是它不会写代码而是它写出来的代码味道不对。你项目里用的是函数式组件它给你写类组件你用的是Zustand做状态管理它给你引入Redux你的API请求封装在services目录下它直接在组件里写fetch。这不是AI笨是你没告诉它你的规矩。而每次开新会话都要重新说一遍规矩这件事本身就很不效率。项目上下文注入这个Skill的核心思路是把你项目的规矩写成一份结构化的文档作为Skill的固定上下文。每次AI生成代码之前先读这份文档再动手。3.2 具体怎么写这份上下文我自己的做法是分成四个模块来写技术栈声明列出项目用的框架、语言版本、关键库。比如React 18 TypeScript 5 Vite Tailwind CSS Zustand React Query。这部分要精确到版本号因为不同版本API差异很大。目录结构约定用树形结构列出关键目录和它们的职责。比如src/ components/ # 通用组件每个组件一个文件夹 features/ # 业务功能模块按领域划分 hooks/ # 自定义hooks services/ # API请求封装 utils/ # 纯函数工具 types/ # 全局类型定义代码风格规则这部分要写得具体不要写遵循最佳实践这种废话。要写组件文件用PascalCase命名hooks用camelCase且以use开头常量用UPPER_SNAKE_CASE。禁止事项明确列出你不希望AI做的事情。比如不要使用any类型、不要在组件内直接写API请求、不要引入新的第三方库除非我明确要求。注意这份上下文不要写得太长。我试过写了两千多字结果AI反而抓不住重点。控制在800字以内用列表和短句比大段描述有效得多。3.3 实操中的效果和调整配置好这个Skill之后最明显的变化是AI生成的代码一次通过率高了很多。以前我大概要来回改三四轮现在很多时候第一版就能直接用最多微调一下业务逻辑。但有个坑要提醒这份上下文不是写完就一劳永逸的。项目在演进技术栈在升级目录结构在调整这份文档也要跟着更新。我的习惯是每个迭代周期结束时花五分钟过一遍看看有没有需要补充的规则。另外一个小技巧如果你同时维护多个项目可以给每个项目建一个独立的上下文Skill然后在会话开始时明确指定用哪个。CodeBuddy支持在对话中切换Skill这个操作很顺手。4. 第二个Skill代码审查与重构4.1 让AI先当审查者再当写作者大多数人用AI编程工具的方式是让它写但我发现一个更高效的模式是让它先审再写。具体来说就是先让AI用审查者的视角看你现有的代码指出问题然后再让它基于审查结果去重构或写新代码。这个Skill的配置思路是定义一套审查清单让AI按照清单逐项检查。我的清单大概长这样是否有未处理的边界情况空值、空数组、超长输入是否有潜在的性能问题不必要的重渲染、未加防抖的事件处理是否有安全隐患用户输入未转义、敏感信息硬编码是否符合项目的错误处理规范是否有可以抽取的重复逻辑4.2 重构时的最小改动原则让AI重构代码最容易出现的问题是它用力过猛。你只是想让它把一个大组件拆小它顺便把你的状态管理方案也换了还引入了两个新依赖。这种惊喜在代码审查时很让人头疼。我的做法是在Skill里明确写一条规则重构时遵循最小改动原则只改与目标直接相关的部分不主动优化无关代码不引入新依赖。这条规则加上之后AI的重构行为明显克制了很多。它还是会指出其他问题但会以注释的形式标出来而不是直接改掉。这样我就能自己决定要不要采纳。4.3 一个具体的重构案例我有个项目里有个UserProfile组件大概四百多行包含了数据获取、表单处理、头像上传、权限判断等一堆逻辑。我用这个Skill让AI帮我拆。AI先输出了一份审查报告指出这个组件有七个职责其中三个可以抽成自定义hooks两个可以拆成子组件还有两个属于应该放在父层的逻辑。然后它给出了拆分方案我确认之后它才动手改。整个过程大概花了十分钟拆完之后每个文件都在一百行以内可读性提升很明显。如果我自己手动拆估计要花一个小时而且容易漏掉一些边界情况。实操心得重构之前一定要确保有测试覆盖或者至少手动验证过关键路径。AI重构虽然大部分时候靠谱但偶尔会在边界条件上出问题。我现在的习惯是重构前先跑一遍测试重构后再跑一遍对比结果。5. 第三个SkillFigma设计稿转代码5.1 设计到开发的翻译损耗问题前端开发有个老生常谈的痛点设计稿和实际代码之间总是有差距。设计师给的是Figma链接开发要手动量间距、取色值、切图标然后一点点还原。这个过程不仅耗时而且容易出错——设计师说这个间距是16px你写的时候手抖写成14px肉眼看不出来但就是感觉不对。Figma MCPModel Context Protocol的出现让这件事有了新的解法。简单说它让AI能直接读取Figma文件的结构化数据包括图层信息、样式属性、组件关系。你不再需要手动翻译设计稿AI可以基于原始数据生成代码。5.2 配置Figma MCP的关键步骤配置过程本身不复杂但有几个地方容易卡住。我按自己的操作顺序捋一遍第一步在Figma里获取访问令牌。这个在Figma账号设置的Personal Access Tokens里生成。注意这个令牌只显示一次生成后立刻复制保存。第二步在CodeBuddy的MCP配置里添加Figma服务。需要填入令牌和你要访问的Figma文件ID。文件ID在Figma链接里是/file/后面那串字符。第三步测试连接。在对话里让AI读取一个Figma文件的基本信息如果能返回图层列表就说明配置成功了。注意Figma MCP读取的是设计稿的结构化数据不是截图。所以你的Figma文件图层命名要规范否则AI读出来的东西是一堆Rectangle 123、Frame 456根本没法用。建议在配置之前先花点时间整理图层命名。5.3 生成代码的准确度能到什么程度我实测下来的感受是布局结构和间距基本能还原到90%以上颜色和字体也能准确读取。但有两个地方需要人工介入一是响应式适配。Figma设计稿通常是固定宽度的AI生成的代码默认也是固定布局。你需要额外告诉它断点规则和适配策略。二是交互逻辑。设计稿里的hover效果、点击反馈、加载状态这些静态数据里没有需要你自己补。所以我的工作流变成了AI生成静态结构和样式我补交互逻辑和响应式。整体效率大概能提升一倍左右尤其是那种重复性高的列表页、表单页效果最明显。5.4 关于Figma汉化和字体的小问题顺带提两个实操中遇到的小问题。Figma网页版默认是英文的如果你习惯中文界面可以在设置里切换语言。另外如果你在设计稿里用了特殊字体本地没有安装的话Figma会显示替代字体这会影响AI读取到的字体信息。建议在项目开始前确认字体是否已安装或者让设计师用系统默认字体。6. 第四个SkillCraft模式下的多文件协作6.1 什么时候该用Craft模式CodeBuddy的Craft模式跟普通对话模式有个本质区别Craft模式下AI可以同时操作多个文件理解文件之间的依赖关系并且按照你的指令批量修改。普通模式更适合问问题和写单个文件Craft模式更适合做一件事这件事涉及多个文件。我什么时候会用Craft模式举几个典型场景新增一个功能模块需要创建组件文件、hook文件、service文件、类型定义文件重命名一个核心概念需要改十几个文件里的引用调整项目结构需要移动文件并更新所有import路径这些操作如果手动做不仅繁琐而且容易漏。用Craft模式你描述清楚目标AI会自己规划步骤并执行。6.2 怎么给Craft模式下指令Craft模式下的指令写法跟普通对话不太一样。普通对话你可以很随意但Craft模式下你需要更工程化地描述任务。我的经验是遵循这个结构目标 范围 约束 验收标准。举个例子我要新增一个通知中心功能目标新增通知中心功能包含通知列表组件、未读计数hook、获取通知的service。 范围只在src/features/notifications/目录下创建新文件修改src/App.tsx添加路由。 约束使用现有的API请求封装不要引入新依赖组件样式用Tailwind。 验收标准通知列表能渲染模拟数据未读计数能正确显示路由能正常跳转。这样写的好处是AI不会跑偏它知道边界在哪里也知道什么算做完了。6.3 多文件修改时的回滚策略Craft模式虽然强大但有个风险它一次性改多个文件如果改错了回滚起来很麻烦。我的做法是每次用Craft模式之前先确保Git工作区是干净的这样万一出问题一个git checkout .就能回到原点。另外我建议把大任务拆成小批次。比如新增功能模块先让AI创建文件结构确认没问题之后再让它填充具体实现。不要一次性让它把所有东西都写完那样出问题时排查成本太高。实操心得Craft模式下AI有时候会自作主张地修改一些你没提到的文件。如果你发现它改了范围之外的东西立刻停止检查修改内容确认无误后再继续。我遇到过几次它顺手优化了无关代码的情况虽然大部分时候是好事但在团队协作中可能会引起不必要的冲突。7. 第五个Skill调试与错误排查7.1 让AI帮你读报错信息报错信息这东西对新手来说是天书对老手来说也是能看懂但不想看。尤其是那种嵌套了十几层的堆栈信息眼睛都要看花。这个Skill的思路很简单把报错信息丢给AI让它帮你定位问题。但直接丢报错信息效果一般因为AI不知道你的代码上下文。所以这个Skill的配置里我会加上几条规则先解释报错的含义用通俗语言然后定位到最可能出问题的文件和行号给出修复建议并解释为什么这样修如果有多种可能的原因按可能性排序7.2 排查思路比答案更重要我用这个Skill最大的收获不是它帮我修了多少bug而是它教会了我一套排查思路。以前我看到报错就慌现在我会先看错误类型再看堆栈里第一个属于我项目的文件然后顺着调用链往上找。AI在解释报错的时候会把它推理的过程展示出来。你看多了之后自己也会形成类似的思维模式。这比单纯得到一个修复方案有价值得多。7.3 常见错误类型速查我整理了一份自己经常遇到的错误类型和对应的排查方向放在Skill里作为参考错误类型常见原因排查方向TypeError: Cannot read property对象未初始化或异步数据未加载检查数据获取逻辑加可选链Hydration failed服务端和客户端渲染不一致检查是否有随机数、日期等动态内容Maximum update depth exceeded状态更新陷入循环检查useEffect依赖数组CORS error跨域请求被拦截检查后端配置或代理设置Module not found路径错误或依赖未安装检查import路径和package.json这份表格我放在Skill的上下文里AI排查时会参考我自己也会时不时翻一下。8. 几个让Skills更好用的隐藏操作8.1 Skill的组合调用前面提到过Skills可以叠加但具体怎么叠有讲究。我的经验是通用Skill在前专用Skill在后。比如项目上下文是通用的Figma转代码是专用的。先注入通用上下文再叠加专用规则AI的生成结果最稳定。如果你反过来先专用后通用有时候通用规则会覆盖掉专用规则里的特殊约定导致生成结果不符合预期。8.2 用快捷键快速切换CodeBuddy支持自定义快捷键我把常用的几个Skill绑定到了快捷键上。比如CtrlShift1是项目上下文CtrlShift2是代码审查。这样在写代码的时候不用鼠标点来点去手指一按就切换了。具体怎么绑定看你的操作系统和CodeBuddy版本在设置里的快捷键部分可以配置。我建议只绑定最常用的两三个太多了反而记不住。8.3 定期回顾和迭代Skill内容Skills不是写完就完了。我每个月会花半小时回顾一下这几个Skill的使用情况哪些规则从来没触发过哪些规则经常需要手动覆盖哪些场景反复出现但Skill里没覆盖到。根据回顾结果调整Skill内容。比如我发现不要引入新依赖这条规则经常被我自己打破因为有时候确实需要新依赖。后来我把它改成了引入新依赖前先询问我这样既保留了控制权又不会让AI束手束脚。9. 踩过的坑和对应的解法9.1 Skill写得太长导致AI失忆前面提过上下文太长AI反而抓不住重点。我一开始写项目上下文的时候恨不得把整个架构文档都塞进去结果AI生成代码时经常忽略后面的规则。后来压缩到800字以内用列表和短句效果明显好转。9.2 Craft模式下文件冲突有次我用Craft模式让AI重构一个模块它同时改了五个文件。改完之后我发现其中两个文件的修改有冲突——一个文件里引用了另一个文件里已经被删除的函数。这种问题在单文件模式下很少见但多文件操作时容易出现。解法是Craft模式执行完之后一定要跑一遍构建或类型检查。如果项目有CI本地先跑一遍tsc --noEmit或者npm run build能提前发现大部分引用问题。9.3 Figma MCP读取不到组件有次我配置好Figma MCP之后AI读取一个设计稿返回的图层列表里全是Group和Rectangle没有组件信息。排查后发现是设计师没有把重复元素做成Figma组件而是直接复制的。AI读取的是原始图层没有组件语义自然生成不出好的代码结构。解法是跟设计师沟通让他们把可复用的元素做成Figma组件。这不仅对AI友好对设计稿本身的维护也有好处。9.4 调试Skill给出的方案不适用AI排查错误时有时候会给出理论上正确但实际不适用的方案。比如它建议你改某个第三方库的源码或者建议你升级一个会引发连锁反应的依赖。遇到这种情况我会在Skill里加一条规则给出的修复方案必须是项目内可实施的不涉及修改第三方库源码不涉及大版本升级除非我明确要求。10. 关于效率翻倍这件事的真实感受效率翻倍这个说法我觉得要拆开看。在重复性高、模式固定的任务上比如写CRUD页面、生成类型定义、转换设计稿效率提升确实很明显有时候不止翻倍。但在需要创造性思考的任务上比如架构设计、复杂业务逻辑梳理AI的帮助有限更多是充当一个随时可以讨论的同事。我的建议是不要把Skills当成万能药而是当成一套杠杆。你本来就会做的事情用Skills放大产出你本来就不会的事情Skills也变不出来。真正让效率提升的还是你对项目的理解和对问题的拆解能力Skills只是把这些能力固化下来减少重复消耗。最后分享一个我最近在用的技巧把Skills和Git worktree结合起来。开一个新分支做实验性功能时用worktree创建一个独立的工作目录然后在这个目录里用Craft模式让AI大胆改。改坏了直接删掉worktree主分支完全不受影响。这个组合让我在尝试新方案时心理负担小了很多反正成本很低试错意愿自然就上来了。