企业官网建设流程全解析

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. 手把手配置你的第一个Skill

3.1 从零开始：一个最小可用的Skill示例

先来看一个最简单的例子，让你感受一下Skill是怎么工作的。假设你有一个Vue 3项目，希望AI在写组件时遵循以下规范：使用<script setup>语法、样式用Scoped CSS、组件名用PascalCase。

在Cursor中，你只需要在项目根目录创建.cursorrules文件，写入以下内容：

本项目使用 Vue 3 + TypeScript + Vite。 编写组件时请遵循以下规范： - 统一使用 <script setup lang="ts"> 语法 - 样式使用 <style scoped> - 组件文件命名使用 PascalCase，如 UserProfile.vue - Props 定义使用 defineProps 泛型语法 - Emits 定义使用 defineEmits 泛型语法 - 不要使用 Options API

保存后，在Cursor的对话中让AI写一个组件，它就会自动遵循这些规则。你不需要在每次对话时重复说明。

在Trae中，同样的规则写在项目根目录的AGENTS.md文件里。格式上Trae更鼓励用Markdown的结构来组织：

# 项目技术栈 Vue 3 + TypeScript + Vite # 组件编写规范 - 统一使用 `<script setup lang="ts">` 语法 - 样式使用 `<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和Prettier，AI生成的代码还是可能偏离团队习惯。比如有的成员喜欢用const箭头函数，有的喜欢function声明；有的喜欢提前return，有的喜欢用else分支。

把风格偏好写进Skills，AI就会按照统一的方式生成代码。以下是我在一个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。把这些约定写进Skills，AI生成的请求代码就会自动遵循统一模式。

以下是一个实际项目中的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%的情况是以下几个原因：

还有一个容易被忽略的点：修改规则文件后，需要开启新的对话才会生效。正在进行的对话不会重新加载规则。这个设计是合理的，但如果不清楚就容易误以为规则没写对。

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 团队协作中如何管理Skills

Skills要发挥最大价值，必须纳入团队协作流程。我的做法是：

把规则文件当作代码来管理。每次修改规则都走正常的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做新人 onboarding

Skills还有一个被低估的用途：新人入职培训。新同事拉下代码后，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兜底，整体开发效率提升非常明显。

提示：规则文件不要追求完美，先写起来再迭代。我见过太多人花大量时间设计“完美的规则体系”，结果项目都上线了规则还没写完。先写十条最核心的，用起来，再慢慢补。