1. 先搞清楚 Rules 和 Skills 到底是什么前端圈最近聊 AI 编程助手动不动就是 Cursor、Windsurf、Copilot、Trae 大比拼但很多人试了一圈发现换工具并没有带来质的提升。问题往往不在工具本身而在于你不会“调教”它。我见过不少团队装上 Cursor 就开写结果 AI 给出的代码一半不能用改来改去比手写还慢。真正的分水岭是你有没有把项目的规矩、自己的习惯、团队的约定系统性地喂给 AI。这套东西现在主流助手统称为 Rules 和 Skills。先说结论Rules 是给 AI 划红线的“制度文件”Skills 是给 AI 准备的“技能包”。前者解决“AI 乱来”的问题后者解决“AI 帮你重复劳动”的问题。两个配合好AI 编程助手才真正从“高级补全插件”升级成“团队实习生成手”。1.1 Rules给 AI 立规矩的配置文件Rules 这个概念最早火的其实是 Cursor 里的.cursor/rules目录。它的本质是让 AI 在每次对话时都能读到一组约定这些约定可能包括项目用什么技术栈、代码风格是什么、组件文件怎么命名、请求错误怎么处理、注释怎么写、提交信息遵循什么规范……说白了你平时在 code review 里反复强调的内容都可以写进 Rules。很多人误以为 Rules 只在 Cursor 里有其实不是。Windsurf 叫“Rules”Trae 叫“AI 规则”VS Code Copilot 里可以用.github/copilot-instructions.md实现类似效果。各家名称不同底层逻辑一致通过一个固定的文件路径或配置入口把“项目元信息”注入到 AI 的上下文里。为什么要用 Rules 而不是每次都手动告诉 AI因为大模型对话有上下文窗口限制你不可能每次开会都重新交代一遍项目背景。Rules 文件放在项目根部AI 启动时自动读取相当于给 AI 发了一份“入职手册”。我见过最有效的做法是把 Rules 分成三层全局规则个人习惯、项目规则技术栈与架构、子模块规则比如src/pages下的特殊约定。后面我会给一套模板。1.2 Skills把常用操作打包成可复用技能如果说 Rules 是“制度”那 Skills 更像是“工具包”。它把一整套操作流程、指令模板、甚至带参数的命令封装成一个可重复调用的技能。比如“生成一个 Vue3 组件”你希望 AI 不仅写出组件代码还自动补上测试文件、样式文件、导出索引、Storybook 配置甚至更新路由。这一整套流程如果每次都要现场描述既啰嗦又容易漏。做成一个 Skill以后只需要说“用 Vue3 组件技能创建一个 Table 组件”AI 就会按你预先设定的步骤执行。Skills 这个词火起来很大程度是因为 Anthropic 在 Claude 里引入了 Agent Skills 概念之后 Codex 也出了 skills 规范。前端社区里有人整理了“superpower skills”合集里面包括代码审查、重构、写 commit message、做性能分析等常用技能。这个思路很对因为前端开发的重复场景实在太典型了新建页面、封装组件、对接接口、写表单校验、处理日期、配置路由……把这些沉淀成 Skills省下的时间非常可观。1.3 两者分工Rules 管“不能做什么”Skills 管“高效做什么”我见过很多人的误区是把 Rules 和 Skills 混为一谈。举个例子你写了一条 Rule“所有日期必须用 dayjs 处理不能用 new Date() 直接格式化。”这属于约束是纪律。而如果写一个 Skill叫做“生成日期工具函数”里面包含了你常用的一套格式化逻辑、时区处理、相对时间计算那这是能力是效率。Rules 更适合表达“必须”、“禁止”、“统一”、“优先使用”这类判断标准Skills 更适合表达“当你需要做 X 时按这些步骤来”。两者也有交汇点Skill 在执行时也应该遵守 Rules。所以我一般建议Rules 尽量精简成几条铁律Skills 里再去细化流程。如果 Rules 写得太多AI 在上下文有限时会抓不住重点反而影响生成质量。2. 工具选型主流助手怎么落地 Rules/Skills网上那些“AI 编程助手大比拼”的帖子动不动就对比谁家代码生成准确率高、谁家 UI 好看但真正落实到团队协作比的是谁家的规则与技能体系更容易维护。我四个主流工具都用过一段不短的时间下面说点掏心窝子的体验。2.1 Cursor 的.cursor/rules和 Rules 区域Cursor 做得最早生态也最成熟。它支持在项目根目录建.cursor/rules文件夹里面每个.mdc文件可以带 Glob 匹配规则比如*.tsx文件才会激活对应的规则。这样你可以细分写页面时 AI 遵守页面规范写 API 调用时 AI 遵守另一套规范。Cursor 还在设置里提供了一个“Rules”输入框那个是全局的适合放个人风格偏好比如“注释用中文代码用英文命名”“不要解释代码直接输出完整内容”。项目级的.cursor/rules则放团队约定。个人经验是全局 Rules 越短越好否则切换不同项目时AI 会被你的个人习惯带偏影响生成质量。2.2 Windsurf 的 Rules 与 WorkflowsWindsurf 现在官方叫 Guidelines早期版本叫 Rules。它有一个特别爽的地方可以在windsurf.rules文件里定义规则然后通过标注[AGENT]、[CODEX]等角色来区分作用对象。比如你写一条规则只对自动执行任务的 Agent 生效不需要干扰日常补全。更值得说的是 Workflows它其实就是可视化的 Skills。你可以把一个复杂的多步骤操作拖拽成流程比如“提交代码前先跑 lint、再跑单测、再更新 CHANGELOG”。虽然这个功能有学习成本但一旦做好团队新人也敢用 AI 做提交通道了。我试过把前端发布流程的检查项放进 Workflow实测下来明显减少了那种“本地能跑提交后被 CI 打断”的尴尬。2.3 VS Code Copilot 的自定义指令Copilot 最近跟进了copilot-instructions.md路径一般是项目根目录的.github/下。它能写指令也能引用skills.md。如果你不想离开 VS Code又想拥有类似 Cursor 的规则能力这个方案最平滑。Copilot 的编辑器中还可以通过#引用特定的指令文件比如#file:AGENTS.md。这个结构其实很适合大规模仓库因为它支持你维护一个根级AGENTS.md再在各子目录放局部指令。前端 monorepo 常见的 packages 目录每个包可以有自己的指令文件这样 AI 在某个子包中生成代码时会优先读取该子包的约定而不是把根目录的规则生搬硬套。2.4 Trae 的规则配置Trae 是字节出的 AI IDE最近热度很高尤其对国内开发者友好网络稳定性好。它的规则配置入口很直观在项目设置里可以直接新建规则文件。Trae 也支持类似 Skills 的“自定义指令”能力还可以把常用命令保存成技能卡片。我实测下来Trae 对中文指令的理解确实强适合中小团队快速上手。但它的 Skills 生态还不够丰富很多社区技能包还没完全兼容。如果你团队主力使用 Trae规则体系可以先用它内置的“项目规则”管理等 Skills 市场成熟了再扩展。2.5 我的选择建议工具没有绝对好坏关键看你的迁移成本。如果你已经在用 VS Code从 Copilot 开始最省事如果你追求最新的 AI 能力愿意接受学习曲线Cursor 依然是第一选择如果你在 monorepo 或者需要可视化流程编排Windsurf 的 Workflows 值得试如果你追求低门槛、中文友好Trae 可以日常用。但我必须强调无论选哪家Rules 和 Skills 的知识是通用的。你今天在 Cursor 里写好的规则稍微改改路径就能用于 Windsurf你写过的 Skill 步骤迁移到 Claude Code 或 Codex 只是换一套 yaml 头的问题。能力在你自己身上不在工具上。3. 实操从零搭建一套前端 Rules 规则光讲概念没意思。下面我以一套 Vue3 TypeScript Vite 项目为例演示实际怎么落地。你也可以照着改成 React、Next.js 或者其他技术栈。核心思路是不要一上来写五十条规则先把最痛的几条立住跑顺了再加。3.1 第一层全局个人规则先打开 Cursor 设置里的 Rules或者你工具的等效入口。我写下的是- 代码中变量、函数、组件命名使用英文 camelCase 或 PascalCase - 注释使用中文但不要写废话注释 - 不要解释代码含义直接输出可运行代码 - 如果问题不明确先列出假设再生成代码 - 优先使用原生 API 和已有依赖不要引入新的第三方库 - 生成的代码必须在类型上严格禁止 any注意全局规则一定要短。我见过有人在这里写了五百字结果 AI 每次对话都优先满足长篇大论忽略了用户当前的真实意图。全局规则是“性格”设定不是“百科全书”。3.2 第二层项目规则在项目根目录创建.cursor/rules/project.md# 项目全局约定 - 技术栈Vue 3.5 TypeScript 5 Vite 6 - 状态管理Pinia禁止直接修改 store 外的全局状态 - CSS 方案Tailwind CSS CSS Modules优先 Tailwind - 接口请求统一使用 src/api/request.ts 封装的 axios 实例 - 路由使用 vue-router路由表在 src/router/index.ts - 组件规范src/components 下每个组件一个目录包含 .vue、.ts、.scss如需要 - API 模块src/api 按业务域拆分文件文件内导出函数式 api - 日期处理统一使用 dayjs禁止使用 new Date().toLocaleString - 数字处理金额、百分比统一使用 utils/format.ts 中的方法 - 状态命名boolean 以 is/has/can 开头列表以 List 结尾这一层是给 AI 的“工作手册”。写完以后你可以随便开个对话让 AI 生成一个登录表单它会自动使用你的封装的 request 方法而不是每次自己造一个 fetch。这就是 Rules 的价值。3.3 第三层按目录细分的规则如果你项目足够大可以在.cursor/rules/加带 glob 的文件例如pages.mdc--- glob: src/pages/**/*.vue --- # 页面组件规范 - 页面组件必须使用 definePageMeta 或路由 meta 设置标题 - 页面组件不能直接调用 api必须通过对应 store action - 页面内组件拆分超过 200 行的模板必须拆分子组件 - 页面入参与详情展示使用子组件接收 props禁止在页面内到处定义响应式变量还有api.mdc--- glob: src/api/**/*.ts --- # API 模块规范 - 所有请求函数必须返回 PromiseT类型 T 从后端响应结构推导 - 错误处理统一在 request.ts 中拦截函数内不写 try/catch - 接口注释写明业务含义例如“获取用户列表” - 分页参数统一为 page 和 pageSize这种按目录匹配的规则特别适合中大型前端项目。我当年第一次实践时只给 pages 和 api 两个目录做了规则AI 生成的页面代码风格立刻统一了代码 review 压力明显降低。3.4 让 AI 理解项目结构和常用命令除了规则文件还建议在项目根目录维护一个AGENTS.md或者叫CLAUDE.md这不是给人类看的文档是给 AI 看的索引。里面可以写# AGENTS.md ## 项目结构 - src/main.ts 入口文件 - src/router 路由配置 - src/store 状态管理Pinia - src/api 接口层 - src/components 公共组件 - src/utils 工具函数 - src/views 页面 ## 常用命令 - pnpm install 安装依赖 - pnpm dev 启动开发服务 - pnpm build 构建 - pnpm lint 检查代码 - pnpm test 运行单测 ## 特殊说明 - 环境变量文件.env.development、.env.production - 接口代理vite.config.ts 中 server.proxy 配置这个文件的价值在于AI 在生成命令、判断路径、分析问题时会优先参考这个索引。很多 AI 生成的注释里乱写“请先运行 npm run dev”其实你的项目用的是 pnpm有了 AGENTS.md它就会写对。3.5 一套可以直接抄的 Rules 模板我整理一份常用前端规则模板你可以直接复制到项目里再改# 通用规则 1. 模板代码不允许出现硬编码的中文文案中文文案统一走 i18n 2. 组件 props 必须定义类型必填项使用 required: true 3. emit 事件命名使用 onXxx 格式 4. v-for 必须有 keykey 优先使用业务唯一 id 5. 禁止使用 any禁止非空断言 6. 样式优先使用 Tailwind 原子类复杂样式写在 style scoped 中 7. 本地存储 key 统一以项目前缀开头如 fe_demo_user_token 8. 接口错误统一由 request.ts 拦截并弹出提示业务代码不写 alert 9. 组件内不直接访问 localStorage必须通过 utils/storage.ts 封装 10. 异步操作统一使用 async/await禁止 .then/.catch这些规则是很多前端团队 code review 时的共识现在让 AI 提前遵守相当于把 review 前置了。注意不要贪多一次加十条跑一两周再复盘哪些规则 AI 老是违反再针对性调整表达方式。4. Skills 开发实战把高频操作变成一键技能Rules 解决的是“AI 会不会乱来”Skills 解决的是“AI 能不能帮你干活”。我见过有人项目里塞了 100 条 Rules但每天还是在重复地让 AI 做同样的事情。真正提效要做的是把重复动作变成 Skills。4.1 识别哪些场景值得做成 Skills不是所有操作都值得做 Skills。我的判断标准是三条频率高、流程固定、容易出错。频率不高但流程极端复杂的可以考虑频率高但每次都不同的不适合。前端最典型的适合场景有新建页面自动生成路由、创建 view 文件、配置菜单、添加接口调用新建组件生成组件骨架、props 类型、emit 声明、样式文件、测试文件写通用工具函数比如防抖、节流、深拷贝、日期格式化对接新接口根据后端接口文档生成 api 函数和类型定义代码审查按照团队规范逐文件检查并输出问题清单写提交信息根据 git diff 生成符合 conventional commits 的 message升级依赖检查依赖兼容性修改受影响的代码我自己最常用的是“新建页面”和“新建组件”两个 Skill。一天如果新增两三个页面以前手动要半小时现在一条指令两分钟效率提升非常可观。4.2 一个实际例子生成 Vue3 组件 Skill不同工具支持的 Skills 格式略有不同以 Claude 的 Skills 结构为参考你可以建一个类似这样的目录skills/ vue3-component/ SKILL.mdSKILL.md内部大致是# Vue3 组件生成 创建 Vue3 组件并补齐配套文件。 ## 输入参数 - componentName: 组件名PascalCase - propsList: 属性列表名称、类型、是否必填、默认值 - emitsList: 事件列表 - description: 组件用途说明 ## 执行步骤 1. 根据 propsList 和 emitsList 生成组件模板使用 script setup langts 2. 组件目录结构src/components/{componentName}/{componentName}.vue 3. 生成一个 index.ts 用于导出 4. 如果组件有复杂样式生成同目录下 styles.module.scss并引入 5. 生成测试文件 {componentName}.spec.ts测试主要 props 渲染和 emit 触发 6. 最后在 src/components/index.ts 中追加导出 ## 注意 - 组件文件顶部必须有 JSDoc 注释说明用途 - props 必须全部定义类型 - 事件命名使用 onUpdate:xxx 等符合 v-model 约定的格式写完 SKILL.md 后你在对话中说“使用 vue3-component 技能生成一个 Table 组件props 有 columns、data、loading”AI 就会自动按步骤执行。这就是 Skills 的杀手锏你不会再因为偶尔漏写测试文件、漏改导出索引而返工。4.3 让 Skills 和 Rules 配合Skills 在执行时AI 也会读取 Rules。所以你的 Rules 如果写了“禁止 any”那么 Skill 生成代码时也会自动避免 any。这就建立了“纪律 流程”的双保险。但这里有个坑Skills 中的步骤和 Rules 存在冲突时AI 往往会先执行 Skills 里的明文指令甚至忽略 Rules。比如你的 Skill 里写了“直接生成一个简化版组件”但全局 Rules 要求“组件必须有测试文件”AI 可能听从 Skill 删掉了测试。所以Skill 里的步骤不要和核心规则打架尤其不要把“为了简化”写进 Skill 步骤里。如果你想让某个 Rule 在所有 Skill 执行时都生效建议在 Rules 里用“绝对不允许”这种更强硬的表达。4.4 Skills 的调试与迭代第一次写完 Skill大概率不完美。我建议按照三个维度持续优化输出质量生成的结果是否直接可运行有没有编译错误上下文消耗Skill 的执行步骤是否过于冗长导致生成的代码反而缩水参数覆盖你日常输入的习惯是否跟 Skill 的输入参数匹配迭代方法很简单每次用 Skills 时如果发现 AI 漏做了一个步骤你就把这条步骤补进 SKILL.md。如果发现某一步 AI 总是理解偏了就加一个具体示例。我自己写 Skills 的习惯是先用自然语言描述然后跑一次再把失败的细节补进去大概三轮后这个技能就非常稳定了。另外现在社区有很多现成的 Skills 仓库比如有人整理的“codex skills”合集、前端面试题相关的面试官技能、数学建模辅助技能等不一定完全适合你但可以参考思路。你可以去搜“awesome skills”或“superpower skills”项目的列表挑几个高频场景拿回来改造成自己的。千万别贪多先做三五个真正高频的用熟再说。5. 提效核心法则与避坑指南写到这你会发现 Rules 和 Skills 并不是什么黑科技本质上就是工程化思维在 AI 时代的延续。但为什么很多人依然用不好我总结了几条核心法则每一句都是踩过坑换来的。5.1 五项核心法则法则一规则要少而硬不要多而软。少于十条的铁律AI 一定遵守超过五十条AI 就会选择性失忆。把真正不能破的底线写进 Rules其他建议写进文档不要塞给 AI。法则二上下文是稀缺资源不要浪费。每次对话AI 只能读取有限的 token。Rules 文件太长会挤占生成代码的空间。尽量使用关键词和简短句子而不是长篇大论。法则三一次只改一个变量。当你调整了一条 Rule 或一个 Skill不要同时改其他配置。否则 AI 行为发生变化时你无法判断是哪个改动引起的。我通常用一个分支专门测试规则改动。法则四建立反馈闭环。规则不是一劳永逸的。每两周花半小时翻一翻 AI 生成的代码看它重复犯了什么错然后针对性地修订 Rules。这个动作叫“规则维护”跟重构代码一样重要。法则五让团队成员共用规则。个人 Rule 再好只有自己用是低效的。把 Rules 纳入版本控制放公共仓库pull request 来更新。团队新人 clone 下来就有完整的规则体系AI 从第一天起就能产出符合规范的代码。5.2 常见问题排查表我用一张表整理高频问题方便你排查现象可能原因解决方法AI 不遵守规则Rules 文件路径不对或格式错误检查工具文档确认读取的是.cursor/rules、AGENTS.md还是copilot-instructions.md规则偶尔生效偶尔失效全局规则与项目规则冲突在 Rules 中增加优先级说明比如标注“项目规则优先于全局规则”生成的代码风格跟团队不一致规则文件放在个人目录而非项目根目录把规则放进项目仓库确保所有协作者和 AI 都读到同一套规则Skill 执行步骤经常漏掉某一步SKILL.md 描述不够具体补充该步骤的明确输出要求给一个例子Skill 生成结果冗长、偏离需求输入参数描述不清在调用时明确说明组件名、props、用途不要只说“帮我建个组件”AI 每次都要重新解释项目背景没有维护 AGENTS.md在项目根目录写清楚结构、命令和特殊说明这个表是我整理给团队内部用的几乎每次新人接入 AI 工具时遇到的都是这几类问题。5.3 个人实操心得我现在怎么用最后分享一段我最近的真实做法。我现在新开一个前端项目第一步不是装依赖而是先花二十分钟写好 Rules 和 AGENTS.md。第二步把自己常用的三个 Skills 建好新建页面、新建组件、代码审查。第三步才开始写业务代码。实测下来的感受是前三天多花了一点时间但后面每天节省的不止一小时。以前让 AI 帮我建一个查询列表页我要描述需求、纠正结构、补测试来来回回十几轮。现在一个指令AI 生成的页面直接能跑风格跟团队一致接口和状态管理都在正确的位置。还有一个体会Rules 和 Skills 的收益是复利型的。你项目越大规则越完善AI 的产出越稳定。像“当前端项目积累了二十条高质量规则和五个高频技能后AI 的代码几乎不需要大改”这种话不是夸张是真能做到。如果你正准备引入 AI 编程助手别急着比谁的生成速度快先花一个下午把自己的 Rules 和 Skills 搭起来。这套体系才是你真正驾驭 AI 的关键也是你和只会在对话框里敲“帮我写一个登录页面”的人最大的区别。