企业官网建设流程全解析

先说个真实感受：很多人装完 Cursor 就把它当普通编辑器用，顶多按两下 Ctrl+K 让它补个函数，然后抱怨“也就那样”。但你要是真把它用明白了，Cursor 完全能做到“你说需求、它出代码、你来 review”的程度。我自己从 VS Code 全家桶切到 Cursor 差不多一年，中间踩了不少坑，最后发现真正拉开效率差距的不是模型选谁，而是——规则怎么配。这篇文章就把我调教 Cursor 的完整思路、规则文件写法、以及实测对比结果都摊开讲，照着抄能少走很多弯路。

1. 为什么你的 Cursor 总感觉“缺点灵性”

先说一个我观察到的普遍现象：大多数人打开 Cursor，第一件事是切模型，第二件事是直接开聊。模型换了一圈，感觉各家都差不多，然后就下结论“AI 编程也就这样”。这其实是把工具用窄了。Cursor 的底层逻辑和纯聊天式 AI 完全不同，它的核心优势在于能理解你整个项目的上下文，但“理解”这件事本身是有条件的一一如果你不告诉它项目规范、代码风格、技术栈偏好，它就只能靠猜，猜的结果就是：代码能跑，但很“游客”，和你手写的风格完全不像，甚至会把项目里原本统一的设计模式搅得乱七八糟。

1.1 工具链错位的核心问题

Cursor 本质上是一个“编辑器 + Agent + 代码库索引”的组合体。你用普通编辑器的思路去用它，等于买了个智能手机天天只用来打电话。它真正发力的场景是：当你给它一个明确目标时，它能定位相关文件、修改多处代码、跑测试、根据报错自我修正。这个过程如果没有任何约束，AI 会自由发挥到让你血压飙升。举个例子，我维护的一个老项目里全是用axios封装好的请求函数，结果有一次让 Cursor 帮忙写新页面，它直接给你 import 了一个fetch，然后整个页面的错误处理风格和老代码完全不同，代码 review 的时候差点被同事吐槽死。这种问题靠换模型是解决不了的，模型不知道你团队的习惯，你需要主动“教”它。

1.2 规则配置的本质是“教学”

规则文件（.cursorrules 或 Rules 配置）就是用来做这件事的。它本质上是给 AI 的“使用说明书”，告诉它你的代码风格、框架偏好、需要避免的坑、以及输出格式。你可以把它理解成给新来的实习生讲团队规范——你不讲，他就按自己舒服的方式来；你讲清楚了，他干活才有章法。很多人的误区在于觉得规则文件是“大佬才需要搞的东西”，或者“写规则本身就很费时间”。但实际上，一套好的规则能让你在后续几个月的每一天都省时间，这是一笔非常划算的投资。

1.3 少写一半代码的真实来源

那“少写一半代码”到底是怎么实现的？我自己的体感是：省的不是键入手速，而是决策成本。没有规则时，你要反复跟 AI 交代背景、纠正方向、让它重写代码；有规则时，你只要说一句“按项目规范给用户模块加个导出功能”，它自动知道用哪个请求层、错误怎么抛、类型怎么定义、要不要写单测。这种效率提升是几何级的，因为规则把“需要解释的上下文”变成了“AI 自己的能力”。接下来我就按自己的实操路径，从基础配置讲到规则编写，再给出一套可以直接复制的模板。

2. 开局先配好这 4 个基础项

在碰规则文件之前，先把 Cursor 的基础设置调对。很多人配置了半天发现没效果，其实就是基础项没设好，AI 根本没拿到该有的信息。

2.1 模型选择：按场景分，不要一个模型走天下

Cursor 内置了多套模型，不同模型侧重点不一样。我的习惯是：

这里有个容易被忽略的点：模型的上下文窗口是有限的。你项目再大，AI 每次能“同时看到”的内容也就那么多。所以不要指望选个大窗口模型就万事大吉，真正决定它能否找到关键文件的，是后文会说的索引与引用技巧。另外，不同模型对规则文件的遵循程度也不同，我自己实测下来，Sonnet 对长规则的理解和执行是最稳的，这大概也是社区里很多人觉得“Cursor 默认给 Sonnet 有道理”的原因。

2.2 全局规则 vs 项目规则：别混为一谈

Cursor 的规则分两个层级：全局规则（适用于所有项目）和项目级规则（只对当前项目生效）。很多人图省事，把所有要求都塞进全局规则，结果去写一个 Python 脚本时，AI 还在那儿按你的 Java 规范输出，非常闹心。我的建议是：

• 全局规则只放“放之四海皆准”的内容：比如代码注释语言、命名风格倾向、禁止使用any、生成的代码必须包含类型定义这类通用约束。
• 项目规则放与当前技术栈强相关的内容：比如“本项目使用 React + TypeScript + Tailwind，所有组件遵循函数式组件规范，接口请求统一走src/api下的封装”。

这样切分后，AI 在不同场景下都能拿到最贴合的指令，不会出现“上下文串台”的尴尬。

2.3 配置入口在哪里：新旧版本都要会用

Cursor 的规则配置入口经历了几次改版，现在两种方式并行，建议都掌握：

• 老方式：项目根目录放.cursorrules文件，里面直接写 Markdown 格式的规则，Cursor 会自动读取。
• 新方式：.cursor/rules/*.mdc文件（新的规则格式），支持给规则设置启用条件（比如只对某个目录生效），更灵活。

我的做法是两者混用：.cursorrules放核心的全局风格约束，.cursor/rules/放场景化规则。这样既保留了旧版兼容性，又能享受新版的条件规则能力。配置完记得重启 Cursor 或者执行 Reload Window，不然规则不生效。这个问题我踩过好几次，每次改完规则都觉得很稳，结果发现它压根没加载，白高兴一场。

2.4 模型是发动机，规则是方向盘

最后再强调一个底层认知：模型决定的是“能力上限”，规则决定的是“输出下限”。你换最强的模型，不写规则，它能生成很漂亮的代码，但大概率不是你项目需要的代码。反过来，模型稍弱但规则写得好，它也能稳定产出 60 分以上的代码，而你只需要把它改到 80 分就够了——这比从 0 到 100 省力得多。所以别纠结“用哪个模型最强”了，先把规则搞对，收益更大。

3. 核心来了：手把手写一套“少写一半代码”的规则

现在进入正题。这套规则我打磨了很久，基本是直接从生产项目里总结出来的，你完全可以复制后按自己项目改改。它的核心思想不是“规定 AI 怎么说话”，而是“规定 AI 怎么想问题”。

3.1 规则文件的第一段：先定义角色与目标

规则的开头不要直接罗列要求，先给 AI 一个“身份设定”。这个看起来像是废话，但实测非常有效。你告诉它“你是一个资深前端工程师”，和告诉它“你是一个代码生成器”，输出质量完全不一样。因为模型在接收到身份设定后，会从“堆砌代码”的模式切换到“理解需求并做工程决策”的模式。我的.cursorrules第一段长这样：

你是一名资深全栈工程师，擅长 Node.js、TypeScript 与 React。 你的目标是帮助开发者编写生产级代码，而非示例代码。 在回答时： - 优先考虑代码的可维护性和可测试性。 - 如果需求存在多种实现方案，先简要说明各方案取舍，再给出推荐方案。 - 生成的代码必须符合项目的现有架构，不得随意引入新依赖。

这段的核心作用是给后续所有指令定调子。AI 后续的每一个决策，都会不自觉地往这个“人设”上靠。很多人忽视这个，直接写“你要做xxx”，效果打折得厉害。

3.2 代码风格约束：把你团队规范翻译成 AI 看得懂的话

每家团队都有自己的代码风格，有的是 Airbnb 规范，有的是落地的自定义规范。这些规范如果在规则里不写清楚，AI 就会按它训练数据里的“最大公约数”来写——往往和你团队实际风格不一致。我通常会写以下几类：

• 命名风格：变量用camelCase，组件用PascalCase，常量用UPPER_CASE，CSS 类名用kebab-case。
• 类型约束：禁止使用any，未知类型必须定义 Interface 或 Type，API 返回数据必须有类型声明。
• 函数风格：优先纯函数，避免副作用，副作用操作要显式标注。
• 注释规范：注释只解释“为什么”，不解释“是什么”，代码本身应该自解释。

举个实际例子，我写过一个规则：“所有日期时间处理必须使用dayjs，禁止使用原生Date直接格式化，因为项目里有统一时区处理逻辑。”加了这个规则后，AI 再也没给我整出过new Date().toLocaleString()这种“能跑但污染全局”的代码。

3.3 架构与模式约束：防止 AI 给你“另起炉灶”

这是规则里最有价值的部分。AI 最讨厌的地方就是它会突然给你引入一种“干净”的新模式，然后整个项目的代码风格就分裂了。所以规则里要非常明确地指定：

- 项目采用 MVC 模式，所有业务逻辑必须放在 service 层，Controller 层只做参数校验与响应封装。 - 数据库访问统一走 Prisma Client，禁止直接写 SQL 字符串。 - 所有接口响应格式统一：{ code: number, message: string, data: T }，错误处理走全局异常过滤器。 - 新增功能时，优先模仿项目 `src/modules` 下同名模块的结构，不要自创文件组织方式。

写这种规则时有个技巧：不要只说“不要做什么”，要告诉它“应该仿照哪个现有文件来做”。因为 AI 对“模仿”的理解远比“遵守抽象规则”强。比如我写“新页面参考src/pages/ProductList的实现方式”，它给出的代码几乎可以直接用。

3.4 场景化规则：用 .cursor/rules 实现条件触发

如果你的项目很大，全放.cursorrules里会导致规则太长，AI 反而记不住重点。这时候.cursor/rules/*.mdc的条件规则就派上用场了。举个例子，我针对 API 层单独建了一个规则文件，只在修改src/api目录时生效：

--- glob: "src/api/**/*.{ts,tsx}" --- - 所有请求函数必须通过 `request` 实例发起，禁止直接使用 fetch。 - 请求函数必须声明返回类型泛型，例如 request.get<UserListResponse>(...)。 - 错误发生时，优先抛出业务异常码，由调用方处理。

这种“按目录生效”的规则特别好用，相当于给每个模块配了个专属助手，不占用全局有限的注意力。而且新版的.mdc还支持 description 字段，配合模型@agent引用时能自动匹配合适的规则。

3.5 输出格式约束：review 时不脑溢血

最后还有一类容易忽略的规则——控制 AI 怎么输出。不是说它会输出乱七八糟的东西，而是它太爱“贴心”地解释了。你要的是代码，它给你来一段“好的，这里我们用到了 XXX 技术，让我们一步步分析”。在对话里倒还好，在代码生成里就非常碍事。我的规则里有这么一条：

当生成代码时，直接输出代码，不要输出解释性文字。 如需说明，在代码块上方用一句简短的话概括改动点。

还配合一条：所有生成的代码必须能在严格模式（TypeScriptstrict: true）下通过编译。这两条加在一起，AI 的输出干净利落，review 的效率直线上升。说到底，规则不是用来限制 AI 的，是用来让 AI 输出更“省心”的。

4. 规则之外的决定性细节：上下文与索引

规则写得再好，模型找不到你的文件，一切都白搭。很多人在小项目里觉得 Cursor 挺好用，一旦项目变复杂，就开始发现“AI 总是找不到我想改的那段代码”。这还真不是 Cursor 蠢，而是你的上下文喂法不对。

4.1 善用 @ 引用：精确投喂比什么都重要

Cursor 里最常见的低效用法，就是直接输入“帮我把登录接口的 bug 修了”，然后期待它自己翻遍整个项目找到问题。AI 确实能翻，但翻的效率和准确率都不稳定。更可靠的姿势是把相关文件拖进对话——输入@选择文件，明确告诉它“问题在这里，改这里”。我实测下来，有明确引用时的修改准确率比不引用至少高 30%，而且返工次数明显减少。这就像请人帮你改代码，你肯定要把相关文件摆到他面前，而不是让他自己去翻你的硬盘。

4.2 Codebase 检索：别每次都全库扫描

Cursor 的 “Codebase” 功能很强，能帮你语义检索整个项目。但它不是万能的，尤其在大项目里，全库扫描会非常吃上下文窗口，甚至会漏掉关键位置。我的策略是：先用@精准引用核心文件，再让 Cursor 分析。只有当完全不确定代码在哪时，才用 Codebase 检索。另外，用 Codebase 时尽量带上项目相关的关键词，比“帮我找 bug”这种模糊提问有效得多。比如“找出用户登录后 token 存储的位置”明显比“帮我看看登录为什么失败”更精准。

4.3 索引设置：它漏掉代码的元凶

Cursor 依赖本地索引来理解项目结构。如果你的.gitignore配置不当，或者索引尚未完成，AI 就会“看不见”某些文件。我的经验是：

• 确保.gitignore里排除了node_modules、dist、构建产物等大目录，否则索引会痛苦到崩溃。
• 偶尔遇到 AI 说“项目中不存在某个文件”时，先检查索引是否过期，重启 Cursor 重建索引。
• 有些项目有特殊的源码目录（如packages/*/src），最好在设置里手动确认索引范围。

这一块我当年折腾了好久，感觉 Cursor 对我的 monorepo 结构总是理解不到位，后来发现是索引没包含子包的src目录，调好之后整个项目的感知力完全不一样了。

4.4 对话隔离：每个任务一个聊天，别开历史杂货铺

Cursor 的对话式交互很爽，但也容易把上下文聊成“一锅粥”。同一个对话里一会儿让写登录，一会儿让改样式，AI 记住的焦点就模糊了。我的习惯是：每个独立任务开一个新 Chat，任务之间不交叉。Commit 后把当前 Chat 清空，重新开始。这个小习惯对输出质量影响极大，比你去调模型参数都有用。原理很简单：上下文越干净，模型越能专注在当前任务上，越不会“联想着”给你加戏。

5. 实测：同一套规则，效果能差多少

说了这么多，还是得用数据说话。我自己拿一个真实场景做过对比：一个 React + TypeScript 的中台项目，需要给用户模块新增一个“导出用户列表”的后端接口。分别在没有规则、有基础规则、有完整规则三种状态下跑 Cursor，记录从提出需求到代码能提交的过程。

5.1 无规则状态：AI 自由发挥到让你怀疑人生

没有规则时，Cursor 生成的代码堪称“看起来像模像样，实际上处处是坑”。它会自己定义请求函数的写法，完全不 follow 你项目里的request封装；类型会直接用any混过去；响应格式会按它自己的想法来，导致前端根本接不上；更夸张的是，它甚至会自己造一个接口地址去调用。你得来回跟它解释“不是这样写的，你看一下src/api/user.ts里的其他函数是怎么写的”。一轮下来，省的那点打字时间全耗在纠错上了。最后算总账，不仅没快，反而比自己敲还慢。

5.2 有基础规则状态：好了一些，但仍需返工

只配置了通用代码风格规则后，AI 的表现好了不少：类型不再用any了，函数命名也规范了，但架构问题依然存在。它倾向于把业务逻辑直接塞进 Controller，而不是放到 Service 层；接口返回格式还是有概率不对；错误处理也没有走全局过滤器。我的体感是，它像一个“有点基础但没受过正规训练”的实习生——说不上哪里大错，但总能给你整出点不符合项目结构的小问题，就像个高需求的敏感女友，满足一个细节，又有另一个细节不对付。

5.3 完整规则状态：这才是“少写一半代码”的真相

当我把3.3节的架构规则、3.2节的风格规则和3.4节的 API 规则全部配好后，效果可以说立竿见影。同样是“新增用户导出接口”，Cursor 直接模仿了src/modules/user下的既有模式，生成了包含 Controller、Service、DTO、路由注册在内的完整代码，还自动补了参数校验和分页逻辑。我只需要 review 一下命名和边界条件，基本直接就能提交。这一次的耗时大概是前两种状态的一半不到，而且质量更稳定。这就是“规则投资”的回报：前期花半小时写规则，后期每次任务省半小时。

5.4 额外收益：团队协作时规则统一了代码风格

还有一个意外收获：当我把这套规则文件维护到项目仓库里后，团队里其他同事用 Cursor 写代码时，也就自动遵循了同一套规范。新同事上手项目的速度明显变快了，因为 AI 这个“隐形导师”直接把团队积累的约定教给了他们。从代码 review 的角度看，AI 生成的代码和团队风格统一之后，review 成本大幅下降。这可能是规则配置里最容易被忽视的价值——它不只是“个人效率工具”，更是“团队知识沉淀”。

6. 规则配置中常见的问题与避坑实录

最后这部分是我踩坑经验的汇总，基本涵盖了多数人会用到的疑难杂症。配置规则时出现的很多问题，表象千奇百怪，根子往往就那么几个。

6.1 规则太长，AI 反而“变笨”

很多人觉得规则写得越全越好，结果把 AI 的注意力彻底稀释了，每条规则都记不清。我自己的观测是，规则文件超过 50 行后，AI 对后面内容的遵循度会明显下降。解决方案很简单：规则要“少而精”，只写对未来有长期影响的核心决策；一次性需求直接写在对话里，不要进规则文件。另外，把规则拆成.mdc条件规则按目录生效，也能有效稀释单次任务的规则负担。

6.2 规则文件不生效，改了白改

最典型的场景是：你把.cursorrules改了，但 Cursor 还停在旧配置上。这个问题的根源是 Cursor 只在某些时机重新加载规则文件（如窗口重载或新对话开始时）。如果你改了之后发现没效果，先试试Ctrl+Shift+P执行 “Reload Window”。如果还是不生效，检查一下文件名是不是拼错了，以及目录层级对不对。这些看着基础，但确实是我见到过最多人卡住的环节。

6.3 规则之间互相矛盾，AI 无所适从

当全局规则说“代码必须简洁”，项目级规则又说“所有函数必须写详细 JSDoc”，AI 就会陷入纠结，表现是代码风格忽左忽右。所以规则之间要通盘考虑，避免自相矛盾。我写规则的原则是：全局规则只说底线，项目规则说偏好，两者不要在同一维度上打架。出现矛盾时，AI 通常会选择遵循更具体的那条，但这也不一定是你想要的——所以最好还是从源头避免。

6.4 每年甚至每个季度都要 review 一次规则

规则不是写一次就一劳永逸的。项目技术栈升级、团队约定变化、甚至 AI 模型能力升级，都会让旧规则变得过时。比如早期版本里我会写“禁止使用某些不成熟的 API”，但模型更新后那些 API 已经稳定了，这条规则反而限制了发挥。我的习惯是：每季度 review 一遍规则文件，把不再需要的约束删掉，补充新的实践经验。让规则保持“活”的状态，它才能持续发挥价值。

6.5 单独说说@agent和 Chat 模式规则的分工

新版 Cursor 的 Agent 模式和普通 Chat 模式对规则的加载方式有区别。简单说，Agent 模式能自动猜测要做的事并主动调用工具，所以规则里要给它更多“自主决策”的空间；而 Chat 模式更多是被动响应，规则偏重输出格式。如果你在 Agent 模式下发现它“完全不听话”，可以先看看是不是规则里给它的“自主权”太少。我给 Agent 模式额外加的规则是“当发现任务目标模糊时，先总结你的理解并询问确认，再开始动手”，效果立竿见影。这个看起来多了一步，实际能省掉整段返工时间，非常值。

最后分享一点真实经验

前后折腾下来，我个人最深的一个体会是：Cursor 不是一个“装好就能飞”的工具，它更像是你的“结对编程搭档”，你花多少心思教它，它就还你多少效率。规则配置看起来要花时间，但它是我用过所有提升编程效率的方法里，性价比最高的一个——一次投入，长期复利。如果你刚接触 Cursor，建议按这个顺序来做：先把基础配置调好，再用我给的那套模板写个底线版本，然后在真实项目里按“不爽就加规则”的方式迭代。不用追求一步到位，规则是长出来的，不是写出来的。最后再唠叨一句：不要迷信任何人的规则模板，包括我的这套。拿回去当起点，结合自己的项目、团队、技术栈去改，它才会真正长成你自己的“少写一半代码”的利器。