企业官网建设流程全解析

很多人第一次用Cursor，头两天会觉得这玩意儿简直通人性，写个需求它就哗哗给你把代码铺出来。但用一周左右，很多人会开始骂骂咧咧：AI写的代码跟我的项目风格完全不搭，要么乱引库，要么注释风格跟屎一样，要么生成一堆用不上的封装，改来改去比自己写还累。问题出在哪儿？大概率不是Cursor不行，而是你没给它立规矩。我用了很长一段时间，中间反复调教，最后把一套规则文件沉淀下来，配合Tab补全和Agent模式，写业务代码的效率差不多翻了一倍，好多重复性的样板代码根本不用手敲。这篇就聊聊我是怎么配置Cursor的，以及这些规则为什么能省掉一大半工作量。

1. 为什么别人的Cursor比你的好用：先搞清楚规则到底是什么

1.1 默认配置下的“AI糊涂蛋”现象

先问你一个问题：你装好Cursor之后，第一件事是干嘛？大概率是打开一个项目，然后直接在对话框里说“帮我写一个用户列表页面”。Cursor确实能写，但它是在对你一无所知的情况下硬写的。

它不知道你用的是React还是Vue，不知道你是用TypeScript还是JavaScript，不知道你项目里有没有封装好的请求库，不知道你变量命名是camelCase还是snake_case，更不知道你们团队习惯把组件放哪个目录。于是它只能按照“绝大多数项目的样子”来猜，猜出来的东西放在通用场景下没错，放到你的项目里就是一堆需要返工的垃圾代码。

我刚开始用的时候就是这种状态，每次让它生成一个模块，拿过来一看，好嘛，又给我造了一个新的axios实例，组件文件可能超过两百行，接口地址直接写死在代码里。我删掉重写的时间比自己写还长，那段时间我差点把Cursor卸载了。后来我才意识到问题不在AI，在于我把它当成了一个无所不知的全能助手，却没给它任何“你的项目上下文”。

1.2 Cursor的三级规则体系

后来我去翻官方的文档和社区的教程，发现Cursor其实提供了一整套规则机制，可以让AI在生成代码之前先“读一遍”你的偏好。这套机制我把它分成三级：

第一级是全局规则。你在设置里配置的Rules，任何时候、任何项目都会生效。适合放一些通用的、跨项目都成立的约束，比如“代码注释用中文”“不使用console.log调试”“不生成示例类的伪代码”。这一层管得宽，但管得浅，对特定项目来说没什么针对性。

第二级是项目级规则。在项目根目录放一个.cursorrules文件，Cursor在对话时会自动读取这个文件里的内容，并把它作为隐式的上下文。这一层是核心，因为每个项目的技术栈、目录结构、编码规范都不一样，只有项目级规则才能真正贴合代码库。我很多项目都有自己的.cursorrules，里面写了这个项目特有的约束，AI的表现在不同项目里完全是两个档次。

第三级是你手动指定的文件或规则。在会话里通过@符号引用指定文件，告诉AI“你现在重点看这几个文件”，或者直接在对话里补充一句额外的要求。这一层是动态的，适合临时任务。

三级配合用的逻辑是：全局规则堵住通用问题，项目规则解决特定项目的痛点，手动引用处理临时的上下文。很多人只配了全局规则，或者干脆一个都没配，那自然感受不到Cursor的神奇之处。

1.3 规则文件从哪里加载

既然项目级规则这么重要，那就得说一下它的加载逻辑。Cursor会在开发环境启动时读取当前工作区根目录下的.cursorrules文件，如果你是DevChat或者Agent模式，它在处理任务之前就会把这份规则作为系统提示词的一部分送进模型。

这一点非常关键：它不是等你开口问才生效的，而是在整个对话窗口里始终存在。规则在这里的作用等于给模型设定了一个“人设”，它会在生成每一个回答、每段代码之前先考虑你的约束条件。

话说回来，.cursorrules文件本质上就是个纯文本的规则描述，用什么语言写都行，我习惯用中文写约束、用英文写代码相关的名词，这样Cursor在解析的时候能更准确地理解技术栈相关术语。规则写清楚、写具体，模型才能给出贴合项目的结果，我后面会给出完整模板。

2. 建规则前必做的三件事：技术栈、代码习惯、输出约束

2.1 先定义技术栈和依赖，别让AI“自由发挥”

我见过不少人写的规则，上来就是“你是一个资深程序员，请写出高质量的代码”。这种话说了等于没说，模型当然知道自己是个资深程序员——它的训练数据里塞满了优质代码，问题是它不知道你的项目属于哪一卦。

所以在规则里，第一要务就是把你项目的技术栈交代清楚。拿我手头一个后台管理项目来说，我会明确告诉Cursor：前端是Vue3 + TypeScript + Vite，UI库用的是Element Plus，样式方案是SCSS且用BEM命名规范，状态管理是Pinia，不用Vuex，接口请求必须走项目里封装好的src/utils/request.ts，不允许直接引axios实例。后端是Node.js + NestJS，数据库用MySQL，所有数据库操作必须走Prisma。

这些信息写进去之后，Cursor生成的代码一下子就有“内味儿”了。比如让它写一个用户列表页，它自动就会从@/api/system/user导入接口，用ElTable渲染数据，分页组件也用的是项目里二次封装的Pagination。在后面几乎不用改什么，放到项目里直接能跑。

有人可能会觉得，这些信息我每次对话里手动说一下不就行了吗？是可以，但你要想清楚：每次新开会话都得重新说一遍，稍微漏说一个条件，AI就开始飘。规则文件的好处是它把一切固化了，你以后一个回车，它就已经站在正确轨道上了。

2.2 用项目代码习惯约束AI的命名和结构

技术栈之外，还有一个经常被忽略的东西：代码风格。不同团队、不同项目的代码风格差异太大了，不约束的话AI会按它训练数据里的“最大公约数”来写。

我在规则里会写清楚命名规范：组件文件名用PascalCase，页面路由组件也统一PascalCase；普通工具函数用camelCase；常量用全大写下划线；CSS类名用BEM。注释风格也要规定：中文注释，且每个函数都要有JSDoc注释，说明参数和返回值。再比如说，组件内部逻辑要遵循“组合式API优先，不要在setup里写大量面条式代码，复杂逻辑抽到独立useXxx函数里”。

这些约束看着琐碎，实际上每条都能让AI的输出质量上一个台阶。因为大模型是“看菜下饭”的，你给了越具体的框架，它越容易在这个框架里产出符合预期的东西。反之你只给一句“代码要好维护”，它根本不知道对你而言什么叫好维护。

这里有个小技巧：不要只写“禁止什么”，还要写“偏好什么”。比如写“不要用any”的时候，同时写“遇到不确定的类型时优先使用类型收窄或定义interface”。AI对“不要”的理解往往不如“要”来得直接，把禁止转换成更优的做法，效果立竿见影。

2.3 输出约束：告诉AI“什么不要做”比“做什么”更重要

技术栈和风格说完了，第三块是“行为边界”。就是明确告诉AI，什么情况下别自作主张，什么情况下要先问。

我在规则里的行为边界大概长这样：

• 不要生成没有任何调用方的工具函数，如果发现重复代码，先检查项目已有工具函数，能复用就复用。
• 不要擅自添加新的依赖，如果确实需要第三方库，先说明理由并等待确认。
• 不要“假装实现”业务逻辑：如果某个接口、某段逻辑需要调用后端，但你现在不知道接口返回结构，先写一个明确的TODO注释，不要编造字段。
• 不要修改与当前任务无关的代码，哪怕是顺手能优化也别动，保持diff最小化。
• 遇到不确定的需求细节，先列出问题清单，而不是直接按最可能的方向瞎做。

这些边界非常有用，尤其是“不要编造接口字段”这一条。插件做多了你就知道，AI特别喜欢自己编一个res.data.userInfo.name之类的变量名出来，当你改成真实接口时，一大片代码都要跟着调。有了这条规则之后，它会先停下来问你：“这个接口的字段结构是什么？”这才是真正靠谱的搭档。

3. 直接可抄的规则模板：前端、Python后端、全栈通用

3.1 一套通用基础规则模板

技术栈、习惯、边界这三块讲清楚了，下面直接给模板。这是我自己用的一套通用版本，任何项目拿过来微调一下就能用，我平时新开项目第一件事就是把它复制进去。

你是一名资深软件工程师，请严格遵循以下规则完成任务。 ## 代码风格 - 代码必须与当前项目的主流风格保持一致，先查看项目中已有文件的写法再动手。 - 命名规范：组件、类名使用 PascalCase；函数、变量使用 camelCase；常量使用 UPPER_SNAKE_CASE。 - 所有代码需要引导性注释，解释“为什么这么做”，而不是解释“代码做了什么”。 - 注释统一使用中文，代码里的标识符一律使用英文。 ## 质量红线 - 只输出可运行、可交付的代码，禁止输出示例性质的伪代码。 - 不新增依赖。如必须新增，先说明用途、体积、替代方案，等待确认后再实施。 - 不编辑与当前任务无关的文件，保持变更范围最小化。 - 不编造不存在的接口字段、配置项或API，遇到信息缺失先提问。 ## 任务处理 - 动手前先阅读相关文件，理解数据流和模块边界。 - 涉及多处调用关系时，先列出改动影响面，再开始编码。 - 如果任务描述模糊，先提出2-3个关键问题，而不是直接开写。 - 实现完成后，说明你改了哪些文件、每个变更的用途、以及测试验证方法。

这个模板覆盖了行为、风格、任务边界三个维度，基本能Hold住大部分项目。你看里面几乎没有某个具体框架的痕迹，所以换项目它都能用，这也是放在全局规则里的首选。

3.2 前端项目规则示例

如果项目是React + TypeScript，我会在项目根目录单独加一份补充规则，或者直接把全局规则里没覆盖到的细节塞进.cursorrules里。

# 项目技术栈 - 框架：React 18 + TypeScript + Vite - 路由：React Router v6 - 状态管理：Zustand，禁止使用Redux - UI库：Ant Design 5，避免引入其他UI组件库 - 样式：CSS Modules，禁止使用内联style（动态变量除外） - 请求：统一使用 `src/api/request.ts` 中的封装 # 组件开发规范 - 函数组件为主，禁止使用class组件。 - Props类型必须使用interface定义，导出供复用。 - 组件拆分粒度要合理，超过200行必须考虑拆分。 - 列表渲染的key不能用index，必须用业务唯一ID。 - 状态提升优先，共用状态抽到最近公共父组件或用Zustand。 # 接口对接 - 所有API调用必须在 `src/api` 目录下建独立模块，禁止在组件里直接写请求逻辑。 - 接口函数返回类型需要明确定义，禁止返回 `any`。 - loading、error状态必须在调用处处理，不要抛到全局。

这套规则下，AI生成的代码几乎可以无缝嵌进现有项目。我印象特别深的是，有一次我需要做一组批量操作按钮，让Cursor在表格上方生成一个工具栏，它自动判断了操作按钮禁用条件，还用useState管理选中行，整个过程只手动微调了两三处样式，这种体验跟之前那种“刷新后全是红线”完全两个世界。

3.3 Python后端规则示例

Python后端项目的侧重点又不一样。我自己的一个FastAPI项目里，规则文件长这样：

# 项目语言与框架 - Python 3.11 + FastAPI + SQLAlchemy 2.0 - 数据库模型用Declarative Base，不在业务逻辑中裸写SQL。 - Pydantic v2模型负责请求与响应校验，禁止使用v1风格。 # 开发约束 - 类型标注必须完整：函数入参、返回值、变量一律标注类型。 - 使用 `async def` 声明异步接口，并在依赖中注入DB会话。 - 业务错误使用自定义异常+全局异常处理器，禁止在视图函数中 try-except 各种吞异常。 - 日志统一用 `logging.getLogger(__name__)`，禁止print。 # 目录结构 - `routers/` 放路由与参数定义，`services/` 放业务逻辑，`models/` 放ORM模型。 - 视图函数内不写业务逻辑，只负责参数校验、调用service、返回结果。 - service层函数职责单一，一个函数只做一件事。

从实际效果看，这套规则最大的价值在于让AI生成的代码天然贴合分层架构。之前我把需求丢给Cursor，它会在路由里写一堆业务逻辑，几十行代码糊在一个函数里。现在规则约束之后，它生成的是“路由薄薄一层、service清晰分层、模型定义完整”的结构化代码，代码评审的时候舒服太多了。

3.4 规则文件怎么组织最不容易乱

模板有了，我再介绍下我的文件组织习惯。全局规则我放在Cursor Settings里的Rules框里，长驻生效。项目规则我放.cursorrules，每个项目一份。有人还会用.cursor/rules/目录来拆分多条规则文件，但当下的版本里，直接维护一个.cursorrules其实最省事。

需要注意，.cursorrules是跟着项目走的，如果你们团队多人协作，建议把它提交到Git仓库里。这样新同事拉下代码，规则一起拉下来，大家看到的AI行为是一致的，这比口头传递技术债务强得多。我自己的做法是一个项目从初始化开始就建好规则文件，技术栈升级或者团队规范变化时同步更新，尽量让规则文件活起来。

4. 让规则真正生效：Tab补全、Agent模式与上下文管理

4.1 为什么AI偶尔会“不听”规则——上下文窗口的真相

规则文件写了，但很多人会问：为啥我配了规则，它偶尔还是像失忆一样乱来？问题往往出在上下文管理上。

当前的模型都有上下文窗口限制，Cursor免费版和不同套餐覆盖的模型不同，可用的上下文长度也不太一样。对话篇幅一长，早期喂给模型的规则和代码就被挤出了有效窗口，AI自然会“变回原形”，开始自由发挥。

应对办法是：让上下文尽量保持精简。你不需要把整个项目都塞给它，每次任务只把相关的文件引用给它，规则文件在项目里自动生效，再加上本次任务的描述，这个信息量是合适的。不要在一个会话里连续问十几个不相关的事情，问完之后再回头看，前面那些上下文反而挤占了规则的空间。

从实际操作来说，我习惯一个会话只处理一个模块。比如“把商品列表页做完”是一个会话，“把订单详情页做完”开新会话。这样上下文干净，AI不仅能记住规则，还能记住前面几轮对话里的具体决策，生成质量最稳定。

4.2 用@引用文件和指令让规则落地

规则的另外一个大用途是配合@引用。比如我在处理一个历史遗留代码时，会让Cursor先读一遍对应的文件，再结合规则说“基于这个文件的现有风格，帮我新增一个XX功能”。它在规则约束下会先模仿旧代码的结构，再按照新需求的逻辑去扩展，生成的东西能维持整个项目风格的一致性，这个体验在接手老项目时特别值钱。

具体操作也很简单：在对话框里输入@，选择要引用的文件或文件夹。我习惯至少把下面几个文件丢给它：涉及修改的页面文件、对应的接口定义、路由配置文件、以及数据库模型文件（如果有）。这些文件是规则之外最宝贵的上下文，AI有了真实的数据结构，就不会再瞎猜字段名。

4.3 Agent模式下的长任务处理技巧

如果你的任务比较复杂，比如“实现用户权限管理模块，包括角色管理、菜单配置、接口权限”，建议直接用Agent模式而不是普通对话。Agent模式会自己规划步骤、读文件、改代码、跑命令，一步步推进。

我在Agent模式下会额外给它几条指令：先列出你理解的模块边界和涉及文件清单，再分步骤实施；每一步完成后自查一次是否符合规则；涉及数据库变更时先整理字段列表和初始数据。这样它不会一头扎下去闷头大改。

这里再分享一个我的独门提效思路：对于重复性的增删改查页面，我会在规则里直接把“标准页面生成协议”写进去，比如列表页必须包括哪些列、搜索区需要哪几个筛选项、新增和编辑是否共用一个弹窗、删除是否需要二次确认。以后每次提一句“帮我写一个XX管理页面”，Cursor就会照这个协议把页面完整生成出来，我不需要每次重复讲页面细节。这才是“少写一半代码”的真正来源。

5. 常见问题与避坑实录

5.1 规则写得越多越好吗？别把规则变成裹脚布

规则确实重要，但千万别走向另一个极端——把.cursorrules写成一部长篇小说。规则太长有两个问题：一是上下文窗口被规则占掉一大块，留给真实代码的空间变小；二是规则之间容易冲突，AI反而不知道该听哪条。

我见过有人把规则写成上千行，从设计模式到部署流程全塞进去，结果生成的代码畏手畏脚，动不动就停下来问“是否需要先确认”。

怎么算合适？我建议项目规则控制在150行以内，全局规则控制在80行以内。规则只写“当前项目中反复出现且影响巨大的问题”，那些一年碰不上一回的边缘约束就不用写了。规则文件应该像牛肉高汤，浓缩但精华，而不是一大盆白开水。

5.2 规则之间冲突了，优先级怎么定

规则写多了，冲突是难免的。比如全局规则说“代码注释用中文”，但某个项目里团队规定英文注释。我遇到过几次这种情况，AI的应对方式是偶尔中文偶尔英文，飘忽不定。

解决办法很简单：项目规则优先于全局规则。我在项目规则里会用一句明确的话开头：“本文件规则覆盖全局规则中的同名约束。”这句话能有效让模型把注意力转移到项目级规则上。如果项目内部还想再细分，比如某个目录下的代码风格不同，就在当前任务中用对话补充说明，这比继续堆规则更灵活。

5.3 规则文件明明写好了，但好像完全没生效？

每次有朋友来问我“为什么我的规则没生效”，我最先问的都是同一个问题：你重新打开会话了吗？.cursorrules文件在会话建立时读取，如果你改了规则文件但还在旧会话里继续聊，AI用的是旧规则。改完规则，直接开新会话，或者至少用新建对话的方式测试一次。

另外也要检查一下规则文件放的位置。.cursorrules要在项目根目录，Cursor才会自动读到。如果你不小心放到了子目录，它找不到，自然不会生效。

还有一个容易踩的坑：规则里使用了文件路径，但当前会话的引用方式是绝对路径还是相对路径没写清楚。我一般会在规则里统一用相对路径，以项目根目录为基准，这样不管在谁的电脑上拉下来都能用。

5.4 从“能用”到“好用”：规则需要持续迭代

最后聊聊规则迭代这件事。我自己的规则不是一开始就完美的，甚至踩过很多坑，最早那版规则写得特别空泛，比如“要写出高质量的代码”“要遵循最佳实践”，效果跟没写差不多。后来我养成了一个习惯：每遇到一次AI犯了同样的错误，就把它改成一条新规则。

举个例子，我做支付模块的时候，Cursor连续两次把金额类型生成了number，而我们项目的金额一律用string存储，避免浮点精度问题。第一次我手动改了，第二次我又自己改了，第三次我实在忍不住了，就在规则里加了一条：“金额字段类型必须为string，禁止使用number，涉及金额计算时统一使用decimal库。”

从那以后，支付模块相关代码再也没犯过这个错。规则就是这么一点一滴堆出来的，它不是一份写完就能一劳永逸的文档，更像你给AI做的一套“成长笔记”，每次踩坑就补一条，慢慢它就从一个通用AI进化成“熟悉我这个项目的老开发”。

我个人在实际操作中最深的体会是，Cursor的规则体系值得你花一个下午好好打磨，这个投入的回报极其可观。如果你现在还在忍受AI乱写代码的折磨，真心建议你把.cursorrules当成项目的一等公民对待，从今天开始第一条规则开始，不断迭代。坚持一两个月，你再看自己的开发速度，一定会感谢当初认真配规则的那个自己。