企业官网建设流程全解析

直接说结论：Cursor好不好用，在你打开编辑器之前就决定了。我见过很多人装上Cursor之后第一件事就是让它“帮我写个登录接口”，结果生成一堆看似能跑、实则到处要返工的代码。然后又觉得AI不听话。其实问题不在模型，在于你没有把“你的要求”变成“它能读懂的规则”。

我自己的转变发生在半年多前，那时候我维护一个Python后端项目，每天有大把时间花在跟AI反复解释项目结构、代码风格、依赖关系上。后来我把这些东西沉淀成一堆规则文件，让Cursor在每次生成代码之前就“知道”这些约束。效果非常直接：很多以前需要重写两三次的代码，第一次生成就能直接提交。日常增删改查的代码量，体感至少少了一半。

这篇文章把我整理规则、调试规则的完整思路写出来。不说虚的，尽量给可以直接抄作业的写法，以及那些容易踩的坑。

1. 先理清楚：Cursor的规则到底在调什么

很多人以为规则就是“告诉AI要写Python”或者“加一句代码要简洁”，这是把规则理解成了提示词。实际上规则是在调三样东西：上下文、约束、行为模式。

1.1 规则的本质是压缩“隐性上下文”

我举个简单的例子。你让一个刚入职的同事写接口，你不会只说“写个接口”，你会告诉他：项目用什么框架，路由怎么组织，参数校验在哪层做，数据库操作用什么方式，之前谁踩过什么坑。这些都是“隐性上下文”。

Cursor也是这样。模型本身不懂你的项目，你每次提问时它临时看到的文件就是它的全部世界。如果你的规则文件里有“本项目用Flask写API，所有路由放在routes目录下，数据库访问通过service层调用”，那么它生成代码时就不需要你每次重新交代一遍，也不会生成长得歪七扭八的项目结构。

规则的本质，就是把你的隐性上下文显式化，让它在每次对话时自动注入。这是我理解Cursor配置的核心，也是后续所有技巧的基础。

1.2 三类规则，分别解决不同的问题

我建议把规则按作用域分成三类，分开管理。

全局规则：放在用户配置里，对所有项目生效。适合写通用的代码风格偏好、语言习惯、工作流约定。比如“函数命名用下划线”“错误信息用中文写明原因”“所有改动默认带上必要注释”。

项目规则：放在项目目录里，跟着仓库走。适合写这个项目特有的一切：技术栈、目录结构、业务约定、团队规范。

会话内指令：每次对话时用自然语言额外补充的临时要求。适合处理一次性约束，比如“今天只改这几个文件，其他不要动”。

常见的新手误区是：把所有内容都塞进全局规则，或者把所有内容都塞进项目规则。结果是AI要么对所有项目用一套模板，要么读了一堆和你当前代码无关的约束，两边都不讨好。

我自己现在的分配原则很简单：能用项目规则表达的，不塞全局规则；能用规则文件表达的，不放在每个prompt里重新说。

2. 把技术栈和代码风格写进规则，生成质量立刻上一个台阶

很多人说“我加了规则但还是不好用”，大部分时候原因只有一个：规则写得太空。比如“请写出高质量的代码”——这句话模型理解不了一点点东西。你要告诉它的，是“高质量”在你的语境里具体指什么。

2.1 技术栈是规则里最不该省略的部分

我发现很多人配置规则时不写技术栈，理由是我每次对话会加“用React写”“用Python写”。这种一次性说明的问题是：上下文窗口里确实有这句话，但它的约束力度非常弱。模型读到这句话的位置离它真正生成代码的位置可能有几千字的距离，它对“用React”的理解程度，远不如放在规则文件里、出现在对话抬头时来得强。

所以在规则文件里，第一步就是把技术栈写成明确清单。格式无所谓，能看清楚就行。这是一段我非常典型的py项目规则：

# 项目技术栈与强制约束 - 语言：Python 3.12 - Web框架：FastAPI - 数据库：PostgreSQL（通过SQLAlchemy 2.0异步访问） - 缓存：Redis（通过redis.asyncio客户端） - 接口文档：自动生成OpenAPI，不需要手写 - 所有新代码必须匹配上述技术栈，不得引入其他框架或驱动

最后一条很多新手不会写，但它恰恰很重要。模型有个让人头疼的习惯：你本来用FastAPI写得好好的，它会在一段代码里突然引入一个requests库的Session，理由是要“优化性能”。如果你在规则里明确“不得引入其他框架或驱动”，这种问题发生的概率会大幅下降。

2.2 把“代码风格”写成一条条可检查的约束

技术栈只是骨架，代码风格才是肉。“风格”这个词很虚，靠模型自己领悟是不靠谱的。你要把风格拆成可检查的一条条。我举几个实际用的条目：

# 代码风格约定 - 变量命名使用snake_case，类名使用PascalCase - 私有函数以下划线开头 - 每个文件必须有一个文件头注释，说明这个文件的职责，不超过三行 - 函数必须有docstring，说明参数、返回值、异常，禁止只写一行“Args:” - 所有异常必须被捕获并记录日志，禁止裸except - 导入顺序：标准库、第三方库、本地模块，三组之间空一行，组内按字母顺序 - 行宽不超过100字符（黑线崩溃的另说）

这类规则的价值在于，它们每一条都可以被“检查”。模型在生成代码时，会倾向按你给的模板来。一旦规则写得足够具体，它输出风格会稳定很多，不需要你反复调整。

说个反面例子，如果你写“代码风格要简洁优雅”，模型的理解和你的理解大概率不是一回事。你想要的简洁可能是“不要写一堆不必要的包装类”，它理解的简洁可能是“把所有逻辑挤在一行列表推导式里”。所以在规则里，尽量用“做什么/不做什么”来描述，少用形容词。

2.3 一个可以直接改的规则文件模板

如果你不想从零开始分，我在一个模拟项目的目录结构里写了下面这个模板，你可以根据自己的项目改。

# Project Rules ## 目标 这个项目是一个给内部运营用的数据看板，代码会长期维护，可读性优先于执行效率。 ## 技术栈 - 前端：Vue 3 + TypeScript + Element Plus - 后端：Spring Boot 3 + Java 17 + MyBatis-Plus - 数据库：MySQL 8 - 中间件：Redis（缓存）、RocketMQ（消息） ## 目录约定 - 后端：controller -> service -> mapper 三层结构 - 前端：页面放src/views，公共组件放src/components，API封装放src/api - 新功能必须按现有目录结构放置，禁止自创新目录（除非常必要） ## 命名约定 - Java类名：业务含义 + Controller/Service/Mapper 后缀 - 接口路径：/api/模块/动作，单词全部小写，中划线分隔 - 数据库表：模块名复数，列名snake_case ## 代码行为 - 所有对外接口必须做参数校验，校验逻辑写在Controller层 - 业务异常统一抛出BizException，由全局异常处理器转换 - 查询数据库必须分页，禁止一次性全量查询 - 缓存操作集中封装，调用方不直接操作RedisTemplate ## 禁止事项 - 禁止在代码里写System.out.println，一律用日志框架 - 禁止注释掉的代码保留在提交代码里 - 禁止在循环内查数据库，需要批量数据先查询再组装 - 禁止修改公共工具类时影响其他模块，新增优先于修改 ## 测试要求 - 新建的工具类必须配套单元测试 - 测试数据不得写死具体业务数据，用随机或构造数据

这个模板不是最好的，因为每个项目诉求不同。但结构可以借鉴：目标、技术栈、目录约定、命名约定、代码行为、禁止事项、测试要求。这几个维度基本覆盖了AI生成代码时最容易出问题的点。

3. 规则里的关键写法：哪些该写、哪些写了也没用

写规则并不是把想到的东西全部堆进去。规则太多会让模型无所适从。我试过一份写了十来页的规则，结果模型反而开始“违反”。后来明白一个道理：规则是要钱的，每条规则都在消耗上下文空间和模型的注意力。

3.1 规则描述的是“边界”，不是“期望”

规则里的每一条，最好都能回答一个问题：什么样的情况算违反？能回答清楚，模型就能执行。回答不清楚，等于白写。

比如“代码要有良好的可维护性”，什么算良好，模型不知道。“变量命名要见名知意”，这个稍微好一点，但“见名知意”还是很主观。改成“变量命名优先选择完整单词，禁止使用a,b,tmp这类无意义单字母变量”，模型理解起来就非常直接。

我自己写规则时的隐藏规则是：尽量不用形容词，多用动词和反向词。反向词的意思是“不允许xxx”往往会比“必须xxx”更有效，因为模型对边界更敏感。下面这个对比可以看得很清楚：

弱规则：“代码应该高效。” 强规则：“禁止在循环体内执行数据库查询或远程调用。”

弱规则：“结构要清晰。” 强规则：“新功能必须放入controller/service/mapper三层结构中，禁止在Controller中写业务逻辑。”

如果你想安排高质量的生成，那规则的作用不是“让AI写得更好”，而是“让AI不要写出你会改掉的东西”。边界清楚了，自由发挥的部分自然有下限。

3.2 负面规则的巨大价值

我发现很多人写规则时只会写正面的要求，不太会写“不要做什么”。这挺可惜的，因为AI的错误往往比正确更容易被约束。

举几个我项目里真实存在过的负面规则：

- 禁止在提交代码中留有 TODO、FIXME、HACK、AAA 等占位标记 - 禁止在接口返回体中原样透出数据库字段，字段名要转成前端约定格式 - 禁止在一个函数中混合处理输入解析、业务计算、结果输出三类逻辑 - 禁止为了通过类型检查使用any（除非有注释说明原因） - 禁止修改被标记为“不要动”的兼容层代码，如无法避免，必须额外说明

这类规则越具体，越能帮你省时间。因为它们拦住的，恰恰是你以前每次review代码时都要手动圈出来的那些问题。

3.3 技术栈和库版本要写死

另一个容易踩的坑是：模型会凭训练数据里常见的库版本写代码。比如你项目里Java 8，它给你生成var、List.of，编译直接过不了。比如你项目里用的是旧版Hutool，它按新版本的API写，运行直接找不到方法。

规则里写清楚大版本和关键API约定，能避免大部分这种低级错误。我常用的写法：

# 依赖与版本约束 - Java版本：8 - 禁止使用List.of、var、Record等Java 9+语法 - 工具包使用Hutool 5.x，API参考5.8版本，不使用6.x的包名 - 前端TS版本4.9，禁止使用satisfies等TS 5语法

这一步很多人忽略，但它实际上是“少写一半代码”的重要组成部分。编译错误和运行错误是最浪费时间的。提前把版本约束写明，模型大概率不会给你制造这种问题。

4. 规则驱动的工作流：Tab补全、Agent调用与文件约定

规则写好后，真正体验到“少写一半代码”是在日常使用里。光写规则不用，等于看菜谱不做菜。接下来讲我日常依赖的三个场景。

4.1 Tab补全：规则要能让补全“接得上”

Cursor的Tab补全（就是按Tab接受建议代码）用起来确实不错，但它的猜测质量高度依赖上下文。默认情况下，Cursor会读你当前文件、最近打开的文件和对话历史。如果你当前的代码风格混乱，它补出来的代码也会跟着乱。

我使用以后发现，规则文件存在时，补全的“稳定性”会好很多。比如我在一个文件里刚写完：

async def fetch_user_orders(user_id: int, page: int, size: int):

接着按Tab，它建议下一步代码时，会更愿意按已有的命名风格、注释格式、返回结构来生成，而不是自创一套。这是因为规则让模型对你“接下来会发生什么”有了预期。不过要注意一点：Tab补全只少量读取规则，它更适合用场景惯例来补全，不擅长执行多步任务。补全靠的是“惯性”，规则部分帮不上太多。

4.2 Agent模式下，规则直接决定返工次数

如果你用Agent模式（也就是让Cursor自己拆解任务、自己改多个文件），规则的作用会进一步放大。Agent模式有个问题：它会在中途“自由发挥”。你让它改一个接口，它可能会顺手把controller里其他接口的日志格式也改了；你让它加一个字段，它可能把数据库迁移脚本也给你换了写法。要防止这些“顺手改”，强约束规则是最好的工具。

我在项目规则里专门加了一段给Agent的约束：

# Agent工作约定 - 只做任务里明确要求的修改，禁止顺带修改其他功能 - 如果发现当前代码与规则冲突，先停下来询问，不要自己判断 - 改文件前先列出要改的文件列表，确认后再动手 - 任何跨文件改动，必须指出影响了哪些文件，并解释原因 - 不要在大文件里做整段重写，优先局部修改

有了这些之后，Agent模式下的返工次数明显下降。原来我经常发现它把不相关的文件也改了，然后要花时间看diff回滚。现在多了一些确认步骤，虽然每次会多花几秒，但总体时间省了一大截。

4.3 路径约定让“按图索骥”成为可能

另一件事是文件路径约定。不要让AI猜你的文件放在哪，直接在规则里列出来：

# 文件位置约定 - 页面组件: src/views/业务模块/页面名.vue - API定义: src/api/业务模块.ts - 状态管理: src/store/modules/业务模块.ts - 公共类型: src/types/api.d.ts

模型生成新文件或引用旧文件时，会照着这个路径规则来。这就避免了按功能找半天还找不到、或者同一个功能建了仨文件的悲剧。路径约定的价值在于，它让“AI按你的结构写代码”成为可能，而不是每次都要靠人肉告诉它“这个文件在哪个目录下”。

5. 别忽略的几个配置：模型、上下文、快捷键

规则是核心，但Cursor的易用程度还受其他几个配置影响。我按重要性排一下我自己日常用到的。

5.1 模型选择：快模型做琐事，强模型做思考

模型选错也是效率杀手。Cursor默认可能会用一些很快的小模型来做简单补全和对话，这些小模型读规则的能力相对弱一些。如果你发现“规则都写了但补全总是不遵守”，先看看当前用的什么模型。

我的习惯是：简单重复的补全和命令用快模型，涉及跨文件修改、业务逻辑推理这类高难度操作切换到更强的模型。第一条规则的约束，对强模型遵守得更好。这不算玄学，大模型的推理能力和上下文遵循能力确实有差距。

5.2 上下文配置：别让规则淹没在无关内容里

第二个关键是上下文管理。Cursor支持把文件夹加进上下文，可以让AI看到更多文件，但文件越多，注意力越分散。如果你的上下文里塞了几十个无关文件，规则反而容易被淹没。

我不建议把整个仓库都丢给AI，除非你确实需要它全局理解。日常做法是把本次任务相关的模块文件夹、核心入口文件加进上下文，其他的一律不加。这样规则和当前代码在上下文中占的比例更高，输出质量更稳定。

5.3 快捷键和你最常用的操作绑定

快捷配置其实很多人忽略了。Cursor里频繁用到的操作就那几个：打开对话、切换Agent模式、接受补全、放弃补全。

如果你愿意花十分钟把常用操作绑到顺手的位置，日常使用会流畅很多。我个人的配置习惯是：把“接受补全”放到不跟其他操作冲突的地方，防止误触；把“打开对话”放在左手能按到的位置，因为每天用几十次。

这里说个很实的教训：默认快捷键和输入法容易冲突。国内用户经常遇到按某个组合键弹不出对话、反而切了输入法。解决办法是在键盘设置里把所有涉及单个修饰键的快捷键都重新绑一遍，确保和输入法快捷键不冲突。

5.4 .cursorignore：让规则看不见不该看的东西

还有一个容易被忽略的文件是.cursorignore，它有点类似gitignore。如果你把node_modules、dist、大型数据文件等加进去，AI就不会去读也没啥负担。这对Context效率影响还挺明显的，尤其是前端项目，node_modules里有几万个文件，让AI去索引这些内容纯属浪费。

我给不同项目维护的.cursorignore的内容大概是这样：

node_modules/ dist/ build/ .coverage/ *.min.js *.map *.lock logs/

加上这个后，AI读取文件的速度和上下文质量都有提高。值得养成习惯。

6. 常见问题排查实录：规则为什么不生效

写规则的时候总会有各种奇奇怪怪的问题，下面是我遇到过的、以及朋友群里高频出现的问题，按出现概率排列。

6.1 规则文件写好了但AI完全不理会

先检查路径。有些文件需要放在固定的目录或使用固定的文件名才生效。其次是看全局和项目的作用域区别：如果全局规则和项目规则打架，通常项目规则优先，但这个优先级也可能带来困惑。

我自己曾经犯过的错误是：把项目规则写成了全局规则，结果另一个项目也加载了这些约束，改动代码时AI自动带入上一个项目的风格。

如果你排查的结果都没问题，那还要考虑一个很常见的变体：修改规则后，旧的对话上下文没有刷新。跨会话的系统提示是在新对话时注入的，老对话还带着旧的约定。遇到过好几次“改了规则没生效”的情况，其实是新开一个会话就好了。

6.2 规则写得太贪，AI反而更迟钝

这个问题的典型表现是：规则文件几千行，项目里每个细节都写了个遍，但AI生成的代码反而越来越不对劲，甚至开始忘掉前面的基本要求。

我自己的经验是规则文件超过某一量级后，概念密度太高，模型真的“顾不过来”。规则也是有上下文的，你的规则占了那么多token，留给代码数据的就更少。极端情况下，模型会在执行层忘掉规则里的某些重要约束，转而顺从对话里最新的信息。

现在我的规则文件尽量保持在几百行以内。每一条都必须有明确目的，删掉一条会明显导致降级的才留下。如果项目特别复杂，可以拆成多个规则文件，按功能分：技术栈一个文件，代码风格一个文件，业务流程一个文件。这样反而比全部塞在一起更清晰。

6.3 规则和现有代码风格不匹配时的处理方案

这个问题会在老项目上加新规则时经常出现。比如你定义了新的命名规范，但项目里几千个老文件都是旧风格。你让AI改一个老模块时，它的行为就会出现摇摆：是照旧风格还是新规则？

我的解决思路是：在规则里明确“新代码用新规则，旧代码保持原样”。如果AI真的动了老代码，那么规则里一定要写“除非任务里明确要求重构，否则保持前代代码风格一致”。这样它就不会为了“统一风格”给你做大规模无关重构。

6.4 多个规则互相冲突时的调试

当两个规则文件对同一件事给出不同约束时，模型会随机发挥。比如全局规则说“函数命名用下划线”，项目规则说“接口方法用驼峰”，AI生成出来的代码就会五花八门。

排查方法很土但有用：把每个规则文件单独开一个会话，用同一个prompt让它输出代码，对比结果。如果输出不同，说明规则冲突了。再把冲突的文件一项项去掉，就能锁定是哪两条在打架。

6.5 上下文太长被截断的应对

如果你的对话历史特别长，语法被截断了，规则可能根本传不到AI。这时你会发现它突然变得“笨了”，之前还遵守的约束现在完全不理。最简单的解决方案是开新会话，然后把必要的上下文再补充进去。

另外，如果你本地有大型数据文件或者大体积二进制被意外加进上下文，AI的计算效率也会受影响。保持上下文里只有“真正必要的内容”始终是对的。

7. 我的规则维护经验：从一段失败史说起

最后分享我自己从“无效配置”走向“有效配置”的一些体会，也许比那些明确的规则条目更能帮到你。

7.1 每条规则都要能回答“为什么”

我有一条非常重要的自我约束：如果某条规则回答不了“为什么存在”这个问题，那我会把它删掉。

举个例子，我曾经写过一条“必须使用单引号”，理由是因为项目里现网代码都是单引号。后来项目里混入了大量双引号代码，我又加了“双引号也可以，但严禁混用”。这些都是有“为什么”的，因为它们背后关联着可读性和统一性。但我还写过“注释必须放在代码上方，禁止放在右侧”，这条后来被删了，因为有些情况下右侧注释更清晰。提醒我：不是每一条都可以固化成规则的。

规则不是越多越好，它必须忠于你的预期。写规则的时候多想一层“这条规则是为了避免什么问题的出现”，你就能自动筛掉一半废话。

7.2 规则也要维护，它是活文档

规则存在的时间长了，它就会和项目脱节。比如项目从某版本的框架升级到了新版本，但规则里还写着旧版本的API。如果你不更新，AI会照着旧规则生成新代码，结果照样编译不过。

我现在把维护规则当做项目文档的一部分，每次技术栈大升级后都要检查规则文件。“项目规则是一个活文档，而不是一份写一次就不看的合同。”这也是我用了这么久Cursor最重要的认知之一。

7.3 观察AI怎么犯错，反向补规则

如果你发现某类错误反复出现——比如模型总是把时分秒的格式化格式写错，或者总是不记得给接口加超时设置——那也不是它“不聪明”，而是你的规则库里没有提到这类边缘情况。

这个思路反过来用：“AI反复犯的错，就是你规则库里缺的规则。”我用了一个简单的表格来记录这类问题，像这样：

这个方法很笨，但效果很好。每填一行，AI在那类场景下的行为就稳定一分。

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

关于标题里“少写一半代码”，我想做个解释阶段：那个数字的来源，并不主要是AI替我自动写出了多少行。更大的是两部分变化：

一是减少重复劳动。以前每个接口写一套参数校验、异常处理、日志记录，现在AI按照规则一次性生成，我只需要改核心逻辑。工作重心从“打字”转移到“检查”。

二是减少“沟通成本”。以前人的沟通有一种叫做“上下文错位”的成本：每加一个功能，都要重新交代项目背景。现在规则文件帮我承担了这个角色，AI每次都知道背景，所以每次返工的概率大大下降。而返工是最消耗时间的，少返工一次，比写代码快多少都重要。

所以“少写一半代码”是一个综合结果。规则不是魔法，不能让你一个月变成高级工程师，但能把你已经确定好的工程约束稳定地传达给AI，让AI输出更贴合你的预期。

如果你现在正准备开始配置Cursor，我的建议是不要一上来就写一大堆规则。先把你最烦的三类问题找出来，针对这三类问题写规则。用一周之后，你会发现其它很多地方其实也可以拆成规则，到时候再加也不迟。让规则随着你的使用一起来，而不是当成一个一次性的大工程。

规则不多不少，项目上不会打架，AI又会判断，这就是一套能持续带来价值的配置。最后留一个小技巧：每改一次规则，前几次生成的结果都要留意，特别是有没有产生规则覆盖不到的新问题。AI的学习曲线，本质上也是你对规则列表的一次次校准。