1. 为什么要在Cursor和Trae里折腾Skills用Cursor和Trae写代码的人大概都经历过这样一个阶段一开始觉得AI补全真香Tab按得飞起但用着用着就发现不对劲了。每次开新会话AI就像失忆了一样你得重新告诉它项目用什么框架、代码规范是什么、某个模块的上下文是什么。更别提团队协作的时候每个人调教出来的AI行为都不一样张三让AI写注释李四让AI别写注释最后代码风格乱成一锅粥。Skills这个东西本质上就是给AI编程工具装上一套“可复用的工作手册”。你可以把它理解成给AI写的SOP——什么场景下该怎么做、遵循什么规范、输出什么格式全部提前定义好。Cursor和Trae都支持通过配置文件来注入这种上下文只不过两边的实现方式略有差异。我最初接触Skills是因为一个很具体的痛点项目里有一套自研的组件库每次让AI写页面它都会用原生HTML标签而不是我们的组件。每次都要在提示词里重复说明烦不胜烦。后来把组件库的使用规范写成一个Skill文件问题一次性解决。从那以后我开始系统性地把各种重复性的指令沉淀成Skills效率提升非常明显。这篇文章适合两类人一是已经在用Cursor或Trae但还没用过Skills的开发者二是用过但觉得“没啥效果”想搞清楚正确姿势的人。我会从设计思路讲到具体配置再到实际踩过的坑尽量把每个环节都说透。2. Skills的核心机制与方案选型2.1 Skills到底是什么和普通提示词有什么区别很多人第一次听到Skills会觉得“不就是把提示词存成文件吗”。这个理解不算错但漏掉了关键部分。普通的提示词是你每次对话时临时输入的而Skills是一套有结构的、可以被AI自动识别和加载的上下文文件。区别体现在三个层面。第一是持久性Skills写在项目目录里跟着代码仓库走换台电脑、换个同事打开项目就能生效。第二是结构化它不是一段随便写的文字而是有明确的触发条件和作用范围比如“当编辑.vue文件时生效”或者“当执行数据库迁移相关操作时生效”。第三是可组合一个项目可以同时存在多个Skills分别负责代码风格、测试规范、API设计等不同维度。Cursor里这个机制主要通过.cursorrules文件和.cursor/rules目录来实现。Trae则支持AGENTS.md以及项目级的规则配置。两者虽然文件格式不同但核心思想一致把隐性的团队知识显性化让AI在每次生成代码时都能遵循。2.2 为什么选择项目级配置而不是全局配置Skills的配置可以放在两个位置全局级别和项目级别。全局配置对你本机所有项目生效项目级配置只对当前项目生效。我的建议是绝大多数Skills都应该放在项目级别。原因很简单不同项目的技术栈和规范差异太大了。你不可能用同一套规则去约束一个React项目和 一个Python后端项目。全局配置只适合放一些极其通用的偏好比如“用中文回复”或者“代码注释用英文”。真正有价值的Skills——组件库使用规范、API错误码约定、数据库命名规则——这些必须跟项目绑定。还有一个实际考量项目级配置可以提交到Git仓库。这意味着团队里任何人拉下代码AI的行为都是一致的。新同事入职第一天不需要看厚厚的文档AI会自动按照团队规范来辅助他写代码。这个价值比个人效率提升大得多。2.3 Cursor与Trae在Skills支持上的差异两个工具在Skills的实现上有一些值得注意的差异直接影响你的配置策略。Cursor的.cursorrules文件放在项目根目录是一个纯文本文件。它没有复杂的语法就是自然语言描述的规则。Cursor在每次对话时会自动读取这个文件的内容注入到系统提示中。后来Cursor引入了.cursor/rules目录支持把规则拆分成多个文件每个文件可以指定生效范围比如只对特定文件类型生效这比单一文件灵活很多。Trae这边AGENTS.md是核心的规则文件。它的定位更偏向于“告诉AI这个项目是什么、怎么运作”。Trae还支持在设置里配置项目级的系统提示。另外Trae的智能体功能允许你创建多个不同角色的Agent每个Agent可以关联不同的规则集这在处理全栈项目时特别有用——前端Agent和后端Agent可以有不同的Skills。实际使用中我倾向于在两个工具里维护一套内容相近但格式适配的Skills。核心规范只写一遍然后分别转换成.cursorrules和AGENTS.md的格式。虽然有一点维护成本但比起每个工具各写一套还是省事很多。3. 手把手配置你的第一个Skill3.1 从零开始一个最小可用的Skill示例先来看一个最简单的例子让你感受一下Skill是怎么工作的。假设你有一个Vue 3项目希望AI在写组件时遵循以下规范使用script setup语法、样式用Scoped CSS、组件名用PascalCase。在Cursor中你只需要在项目根目录创建.cursorrules文件写入以下内容本项目使用 Vue 3 TypeScript Vite。 编写组件时请遵循以下规范 - 统一使用 script setup langts 语法 - 样式使用 style scoped - 组件文件命名使用 PascalCase如 UserProfile.vue - Props 定义使用 defineProps 泛型语法 - Emits 定义使用 defineEmits 泛型语法 - 不要使用 Options API保存后在Cursor的对话中让AI写一个组件它就会自动遵循这些规则。你不需要在每次对话时重复说明。在Trae中同样的规则写在项目根目录的AGENTS.md文件里。格式上Trae更鼓励用Markdown的结构来组织# 项目技术栈 Vue 3 TypeScript Vite # 组件编写规范 - 统一使用 script setup langts 语法 - 样式使用 style scoped - 组件文件命名使用 PascalCase - Props 和 Emits 使用泛型语法定义 - 禁止使用 Options API两个工具的配置逻辑是一样的只是文件载体不同。你可以根据团队使用的工具来选择或者两个文件都放内容保持一致。3.2 进阶配置用条件规则实现精准控制基础配置能解决大部分问题但当你需要更精细的控制时就需要用到条件规则。Cursor的.cursor/rules目录支持在规则文件头部添加元信息指定规则的生效条件。比如你希望“数据库相关规范”只在操作src/db/目录下的文件时生效可以创建.cursor/rules/database.mdc文件--- description: 数据库操作规范 globs: src/db/**/*.ts --- - 所有数据库查询必须使用参数化查询禁止字符串拼接 - 事务操作必须使用 try-catch 包裹确保异常时回滚 - 查询结果必须做空值判断 - 新增表必须同时编写对应的 migration 文件这里的globs字段就是触发条件。当AI编辑的文件路径匹配src/db/**/*.ts时这些规则才会被加载。这样做的好处是避免规则互相干扰——前端组件的规则不会影响后端代码的生成。Trae的智能体配置也支持类似的能力。你可以在创建Agent时指定它负责的目录范围然后为这个Agent单独配置规则。比如创建一个“后端Agent”只负责server/目录下的代码规则里写后端相关的规范。3.3 规则文件的组织策略拆分还是合并当项目变大规则越来越多时一个很现实的问题就出现了所有规则塞在一个文件里还是拆成多个我的经验是按“变更频率”和“作用范围”两个维度来拆分。变更频率低的通用规则放在一个文件里比如代码风格、命名规范这些可能半年都不会改一次。变更频率高的业务规则单独放比如某个模块的API约定可能随着需求迭代经常调整。作用范围广的规则全项目生效和范围窄的规则只对特定目录生效也要分开。一个典型的拆分方案是这样的.cursor/rules/ base.mdc # 通用编码规范全项目生效 frontend.mdc # 前端规范只对 src/views/ 生效 backend.mdc # 后端规范只对 server/ 生效 database.mdc # 数据库规范只对 src/db/ 生效 testing.mdc # 测试规范只对 __tests__/ 生效每个文件保持精简只写这个领域最核心的规则。规则太多反而会让AI“分心”该遵守的没遵守不该管的瞎管。注意规则文件不是越多越好。我见过有人把规则拆成二十几个文件结果AI加载时反而容易遗漏。一般来说5到8个规则文件足够覆盖一个中型项目的需求。4. 实战用Skills解决四类高频问题4.1 统一代码风格让AI不再“自由发挥”代码风格不一致是团队协作中最常见的问题。即使有ESLint和PrettierAI生成的代码还是可能偏离团队习惯。比如有的成员喜欢用const箭头函数有的喜欢function声明有的喜欢提前return有的喜欢用else分支。把风格偏好写进SkillsAI就会按照统一的方式生成代码。以下是我在一个React项目中实际使用的规则片段# 代码风格 - 函数组件统一使用 const 箭头函数定义如 const MyComponent () {} - 事件处理函数命名以 handle 开头如 handleClick、handleSubmit - 条件渲染优先使用三元表达式复杂逻辑抽成变量 - 提前 return 代替嵌套 if-else - 导入顺序React 相关 第三方库 项目内部模块 样式文件这些规则看起来琐碎但累积起来对代码可读性的影响很大。特别是导入顺序这一条以前每次Code Review都要手动调整现在AI生成的就是对的。4.2 注入业务上下文让AI理解你的项目AI编程工具最大的局限是它不了解你的业务。它不知道“订单”和“工单”在你的系统里是两个完全不同的概念也不知道你们的用户体系分了几种角色。这些信息如果不告诉AI它生成的代码就只能是“看起来对但实际不能用”。Skills是注入业务上下文的最佳载体。你可以在规则文件里用简短的篇幅描述核心业务概念# 业务上下文 - 系统中有三种角色管理员(admin)、运营(operator)、普通用户(user) - 权限判断统一使用 usePermission() hook不要直接判断角色字符串 - 订单状态流转待支付 - 已支付 - 已发货 - 已完成取消状态为终态 - 所有金额字段单位为分展示时需除以100并保留两位小数有了这些上下文AI在写权限相关代码时就会自动使用usePermission()而不是自己发明一套判断逻辑。写金额展示时也会记得做单位转换。这些细节如果靠每次对话时口头说明既容易遗漏又浪费时间。4.3 规范API调用前后端约定一次搞定前后端联调时最烦的就是接口格式不统一。有的接口返回{ code, data, message }有的直接返回数据有的用GET传数组有的用POST。把这些约定写进SkillsAI生成的请求代码就会自动遵循统一模式。以下是一个实际项目中的API规范Skill# API 调用规范 - 所有请求通过 src/api/request.ts 中封装的 request 方法发起 - 接口返回格式统一为 { code: number, data: T, message: string } - code 为 0 表示成功非 0 表示业务异常 - 请求失败统一在 request 拦截器中处理业务代码只处理成功逻辑 - 列表接口的分页参数统一为 page 和 pageSize - 新增接口必须在 src/api/ 下对应的模块文件中定义类型这条规则带来的改变很直接以前AI生成的请求代码五花八门现在全部走统一封装。新人看代码时也不会困惑“为什么这个接口的调用方式不一样”。4.4 测试代码生成让AI写出能用的测试让AI写测试代码最常出现的问题是它写的测试根本跑不起来——mock数据不对、断言逻辑有误、异步处理不当。通过Skills注入测试规范可以大幅提升测试代码的可用性。# 测试规范 - 测试文件放在 __tests__ 目录下命名格式为 组件名.test.ts - 使用 Vitest 作为测试框架testing-library/react 作为组件测试工具 - 每个测试用例必须包含渲染、交互、断言三个部分 - Mock 数据统一放在 __tests__/mocks/ 目录下 - 异步操作使用 await waitFor() 包裹 - 禁止在测试中使用 snapshot所有断言必须显式编写特别是“禁止使用snapshot”这一条直接解决了我们团队的一个大问题。以前AI特别喜欢生成snapshot测试但snapshot一旦多了维护成本极高而且经常出现“测试通过了但实际是错的”这种情况。显式断言虽然写起来麻烦一点但可靠得多。5. 常见问题与排查技巧实录5.1 规则不生效先检查这几个地方配置了Skills但AI好像没反应这是最常见的问题。根据我的排查经验90%的情况是以下几个原因问题现象可能原因排查方法AI完全忽略规则文件位置不对确认.cursorrules在项目根目录.cursor/rules目录名拼写正确部分规则生效部分不生效规则之间有冲突检查是否有两条规则对同一行为做了相反约定规则时灵时不灵规则太长被截断单个规则文件控制在500行以内过长会导致AI遗漏条件规则不触发globs 路径不匹配检查文件路径是否真的匹配了 globs 模式Trae中规则不生效AGENTS.md 未被识别确认Trae版本支持该功能检查文件编码是否为UTF-8还有一个容易被忽略的点修改规则文件后需要开启新的对话才会生效。正在进行的对话不会重新加载规则。这个设计是合理的但如果不清楚就容易误以为规则没写对。5.2 规则冲突了怎么办当项目里存在多个规则文件时冲突是难免的。比如base规则说“所有函数都要写JSDoc注释”但前端规则说“组件文件不需要写注释”。AI遇到这种情况会怎么处理答案是不确定。它可能随机选一个也可能两个都不遵守。解决冲突的原则是越具体的规则优先级越高。在Cursor中可以通过规则文件的加载顺序来控制优先级后加载的规则会覆盖先加载的。在Trae中可以在AGENTS.md里用明确的优先级声明来处理。更根本的解决办法是定期审查规则文件消除矛盾。我一般每个月会花十分钟过一遍所有规则把过时的删掉把冲突的合并。规则文件也需要“代码审查”。5.3 规则写多长才合适这是一个很实际的问题。规则写太少AI的行为不受约束写太多AI记不住反而效果变差。我的经验值是单个规则文件控制在200到500行之间整个项目的规则总量控制在2000行以内。超过这个量AI对规则的遵守率会明显下降。与其堆砌大量规则不如把最核心的20%规则写好剩下的靠Code Review来兜底。另外规则的写法也很重要。用简洁的祈使句比用长篇大论的说明效果好得多。比如“使用PascalCase命名组件文件”就比“为了保持代码的一致性和可维护性我们建议在命名组件文件时采用PascalCase的命名方式”要好。AI不需要你解释为什么它只需要知道做什么。5.4 团队协作中如何管理SkillsSkills要发挥最大价值必须纳入团队协作流程。我的做法是把规则文件当作代码来管理。每次修改规则都走正常的PR流程至少一个人Review。规则变更后在团队群里同步一下让大家知道AI的行为有什么变化。新项目启动时从已有项目中复制一份规则文件作为起点再根据新项目的特点调整。还有一个实用技巧在规则文件里加一个“变更日志”区块记录每次修改的内容和原因。这样当AI行为出现异常时可以快速定位是不是最近的规则变更导致的。# 变更日志 - 2024-01-15: 新增金额单位转换规则 - 2024-01-20: 移除已废弃的旧版API调用规范 - 2024-02-01: 调整导入顺序规则将样式文件放到最后这个习惯看起来不起眼但在排查问题时能省很多时间。6. 让Skills真正融入日常开发流6.1 从“写规则”到“养规则”的心态转变很多人配置完Skills后就不管了然后抱怨“没什么用”。Skills不是一劳永逸的东西它需要持续维护。项目在演进技术栈在更新团队习惯在变化规则文件也得跟着变。我自己的做法是每次Code Review发现AI生成的代码有共性问题就顺手往规则文件里加一条。比如发现AI总是忘记处理loading状态就加一条“异步操作必须处理loading状态”。这种“遇到问题就补规则”的方式比一次性写一大堆规则更有效因为每条规则都对应一个真实发生过的问题。6.2 用Skills做新人 onboardingSkills还有一个被低估的用途新人入职培训。新同事拉下代码后AI会自动按照团队规范辅助他写代码。他不需要先花一周时间读文档、看代码而是在写代码的过程中就潜移默化地学会了团队规范。我甚至见过有团队把“阅读并理解AGENTS.md”作为新人第一天的任务之一。因为这份文件本身就是对项目技术栈和开发规范的精炼总结比很多项目文档都更准确、更及时。6.3 跨工具同步Cursor和Trae共用一套规则如果你同时使用Cursor和Trae维护两套规则文件确实有点烦。我的解决方案是把核心规则写在一个独立的Markdown文件里然后在.cursorrules和AGENTS.md中通过引用或复制的方式使用。具体来说我会创建一个docs/dev-rules.md文件里面写完整的规则内容。然后.cursorrules和AGENTS.md里只写一句话“请遵循 docs/dev-rules.md 中的所有规范。”这样规则只需要维护一份两个工具都能用。不过要注意Cursor对.cursorrules的读取是自动的但它不会自动读取其他文件。所以这种方式需要确认Cursor是否支持引用外部文件。如果不支持就只能用复制的方式每次修改后同步更新两个文件。虽然麻烦一点但总比维护两套不同步的规则要好。6.4 一个实际项目的完整配置示例最后分享一个我在实际项目中使用的配置结构供参考项目根目录/ .cursorrules # Cursor 主规则文件 AGENTS.md # Trae 主规则文件 .cursor/ rules/ base.mdc # 通用编码规范 frontend.mdc # 前端规范globs: src/views/** backend.mdc # 后端规范globs: server/** database.mdc # 数据库规范globs: src/db/** docs/ dev-rules.md # 完整规则文档供人阅读.cursorrules和AGENTS.md的内容保持同步都指向同一套规范。.cursor/rules/下的文件是Cursor特有的条件规则Trae中通过智能体配置来实现类似效果。docs/dev-rules.md是给人看的完整版方便新人快速了解项目规范。这套配置跑了大半年团队里五个人用下来AI生成代码的可用率从最初的不到50%提升到了80%以上。剩下的20%主要靠Code Review兜底整体开发效率提升非常明显。提示规则文件不要追求完美先写起来再迭代。我见过太多人花大量时间设计“完美的规则体系”结果项目都上线了规则还没写完。先写十条最核心的用起来再慢慢补。