企业官网建设流程全解析

我用了很久AI编程工具之后最大的感触是：很多人不是工具用得不好，而是压根没给工具立规矩。Cursor默认状态下像个热情过头的实习生——你说什么它都愿意干，但干出来的东西和你脑海里的预期总是隔着一段距离。要真正让它帮你少写一半代码，秘密不在对话技巧里，而在一套精心设计的规则配置里。这套规则，我用在内部管理后台、某跨平台系统、还有几个Demo项目上，实测下来代码重写率直线下降，很多页面和接口几乎是第一版就能直接验收。这篇就把我的配置思路、可复用的模板、踩过的坑一起盘出来。

1. 先想清楚：配置的本质是给AI立规矩

1.1 不配置的Cursor是什么状态

默认情况下，Cursor会基于当前打开的文件做一些推理。你要是只给它一句“写一个列表页”，它也能给你生成，但生成结果往往是"万能模板式"的：用了和项目不一致的命名风格，没接入团队封装的请求库，样式类名随手起，异常处理能省就省。你得自己在改代码上花时间，最终算下来，你只是把“手写”换成了“审改+重写”，根本没省多少事。

这不是模型能力问题，而是缺少约束。人类编码时的每一个决定背后都有上下文：技术栈、目录结构、命名规范、现有封装、团队约定。你不告诉工具这些上下文，它就只能靠猜。猜的结果看起来像模像样，但细节全偏。很多人的误区是试图用更复杂的对话去纠正它——一个页面来回聊十几次，最后可能还是自己动手改更快。

1.2 配置能解决的三类核心问题

在我看来，一套合格的配置至少要覆盖三个层面。第一是统一性和一致性：让生成的代码风格和项目现有代码保持高度一致，包括命名、缩进、注释习惯、组件拆分粒度。第二是约束与禁区：明确告诉AI哪些事绝对不能做，比如不许用any、不许把token写在组件里、不许在render中做复杂计算。第三是上下文补全：把项目里常用但分散的信息固化下来，比如技术栈版本、路由组织方式、接口请求封装、错误处理规范，让AI每次生成都自带这些知识。

这三类问题解决后，你会发现AI生成代码的“一次通过率”大幅提升。一次通过率是真正决定你能不能少写代码的指标：如果生成10次里8次能直接落地，你省下的就是8次的手写；如果10次里只有3次能用，那省下的工作量非常有限。配置的价值不在于让AI写得“更好”，而在于让AI写得“更对”。

1.3 配置的三个核心载体

很多人以为配置只是往项目里塞一个叫.cursorrules的文件，但实际上配置有三个层面，分别作用于不同粒度。

• 全局规则：在Cursor的设置界面中配置的Rules for AI。它在所有项目中生效，适合放那些跨项目通用的偏好，比如“代码中必须包含中文注释”“优先编写可测试的程序结构”“回答代码问题时先给思路再给完整实现”。
• 项目级规则：根目录的.cursorrules文件，或者.cursor/rules/目录下的规则文件。这里放的是某个项目专属的约定，比如技术栈、目录结构、命名习惯、封装的工具函数清单。项目级规则优先于全局规则，适合按照仓库独立维护。
• 会话级指令：在每一次对话里临时补充的说明和约束。适用于一次性任务，例如“这次接口对接请使用现有的request模块，不要引入axios”。

三层各有用途，配合起来才能覆盖不同场景。我见过不少人只配置全局规则，结果在项目里依然乱套；也有人只配项目规则，但换个机器人感觉完全换了个人——实际上就是全局信息缺失导致的。

2. 一套可以直接抄走的配置模板

2.1 全局规则怎么写：先说你是谁

全局规则的核心作用不是告诉AI“你要听我的”，而是告诉AI“我的工作环境和偏好是什么”。我的全局规则开头通常是这么一段：

You are a senior software engineer. You write clean, readable, and testable code. For Chinese comments, use simplified Chinese. When asked to write code, first restate the requirements in one or two sentences, then provide a plan, then code. If the code involves external dependencies, mention potential pitfalls.

很多配置指南都在教“命令式指令”，但我更推荐这种“角色+原则+流程”的写法。原因很简单：大模型本质是在做概率生成，你把它设定成一个资深工程师角色，它生成的代码风格会整体偏向更成熟、更稳健的那一类。加上固定流程约束，每次回答的结构都保持稳定，你要改的地方就少了。

接着我会加上几条不依赖具体项目的通用禁忌：

- Do not use `any` unless strictly necessary. - Do not over-engineer: create abstractions only when they are immediately necessary. - Do not leave TODO without a reason; if you must, explain why. - Always handle obvious error cases in I/O operations.

注意，禁忌不能一窝蜂全塞进去。全局规则只保留通用性强、跨语言跨框架都成立的。像“不要用var”“hooks依赖数组必须完整”这种具体到语言或框架的规则，放全局虽然无害，但会白白占掉上下文窗口，效果也会打折扣。

2.2 项目级规则模板：核心中的核心

项目级规则才是决定“少写一半代码”的关键。一份能直接套用的模板大概长这样，我会以内部管理后台项目为例：

# Project Overview - Admin dashboard built with Vue 3 + TypeScript + Vite. - UI library: Element Plus. - State management: Pinia. - HTTP requests: axios wrapper in `src/utils/request.ts`, exports `request()` and `requestUpload()`. - Routing: vue-router, routes defined in `src/router/index.ts`. # Code Style Constraints - Components use `<script setup lang="ts">`. - Props and emits are defined with `defineProps` and `defineEmits`, with TypeScript types. - Use `ref` and `computed` instead of `reactive` for primitives and one-layer objects. - v-model naming follows Vue 3 conventions. - Pages are placed under `src/views/<module>/`, commonly used components in `src/components/<module>/`. # Naming Convention - File names: kebab-case. - Component names: PascalCase in script. - API service files: `src/api/<module>.ts`, export `getXxx`, `postXxx` functions. - CSS classes: camelCase or BEM according to existing pages. # Business Constraints - All dates formatted by `dayjs` and displayed as `YYYY-MM-DD HH:mm:ss`. - List page queries must include `page` and `pageSize`, default `pageSize: 20`. - Table operations must confirm before destructive actions. - Permission control uses `v-permission` directive and `$route.meta.permission`. # Common Tasks - New list page: create `views/<module>/index.vue`, `api/<module>.ts`, optional `components/search-form.vue`. - New modal form: use `el-dialog` + `el-form`, validate rules inline. - Make sure to read existing files in the project to keep conventions consistent.

这模板看着不长，每一条都是我从项目里沉淀出来的。真正跑通之后，你会发现一个明显的现象：当AI生成一个新列表页时，它会直接用项目的request封装、直接用统一的日期格式、直接按现有代码风格拆分组件，几乎不需要你反复纠正。

2.3 会话级指令模板：临时任务不失控

即使全局和项目规则都配好了，每个具体任务仍然有特殊性。我有几个固定的会话指令模板，按场景切换。

新写一个页面时我会在开头加一句：“请参考src/views/user/list.vue的实现风格，新建src/views/role/list.vue，职责是角色列表，需要支持名称模糊搜索、状态筛选、分页，操作列包含新建、编辑、删除，删除需要二次确认。”一次把参考文件、目标文件、职责范围、关键交互全说清楚，AI很难跑偏。

改一个bug时我会说：“不要解释太多，直接定位问题并给出完整修改方案。改动要尽量小，不要重构周边代码。如果有多个可能原因，请列出排查结论再动手改。”这条指令能显著减少AI顺手把周围代码重写一遍的风险。

给AI立规矩不是限制它，而是把项目里散落的隐性知识显性化，让它不用猜。对开发者来说，最贵的不是让AI替你写代码，而是替你把代码写错之后你来回改的那些时间。

3. 让规则真正发挥作用的关键细节

3.1 规则文件位置与生效逻辑

很多人配了规则却发现AI根本不听，最大原因是对生效机制理解有误。.cursorrules文件只会在根目录被自动识别，而Cursor会从打开的文件和当前工作区环境里判断上下文。如果你没有在会话中把规则文件所在的目录打开，很多规则并不会生效。

实际使用时要注意：规则文件只认根目录。如果你是打开一个子文件夹在写代码，项目根目录的.cursorrules就可能读不到。这时最简单的做法是让Cursor打开项目根目录，而不是直接打开文件。另一个常见问题是.cursorrules拼写错误，或者文件名写成了.cursorrule、.cursor_rules这类变体，都不会被识别。建议在项目根目录确认一下文件名。

从Cursor较新版本开始，支持在.cursor/rules/目录下写多个规则文件，每个文件可以用Front Matter标记适用范围。我目前是把通用规则拆到若干个小文件里，比如language.md、frontend.md、backend.md，通过Glob模式控制哪些文件在什么场景被加载。这个方式比一个大而全的.cursorrules更灵活，上下文窗口也更省。

3.2 用示例替代抽象描述

这是我认为配置里性价比最高的一个技巧。同样是“错误处理要有统一风格”，干巴巴写一句“请统一错误处理”，AI基本等于没看到。但如果你加一小段示例：

# API Error Handling When calling API, use the pattern below: const { data } = await request('/api/xxx', { method: 'POST', data: form }); // Unify error message by catching request exceptions in the wrapper; pages do not need try/catch.

AI对具体模式的理解能力远强于抽象要求。所以每一条业务约束，如果能补一个实际示例，规则的有效性会翻好几倍。编制规则的过程其实就是给AI准备一份“代码风格小样”，示例比任何形容词都管用。

3.3 规则优先级与冲突处理

项目中多份规则同时存在时，冲突难以避免。按我的经验，实际优先级大概是：会话指令 > 当前项目规则 > 全局规则。遇到冲突时，AI通常会采信更具体、更贴近当前任务的那一份。如果两条规则等量齐观，也可能出现“随机摇摆”，表现就是代码风格时好时坏。

处理冲突我有两个原则。第一，全局规则里的条目必须足够通用，不与任何项目的具体约定冲突。比如我全局写着“使用简洁命名”，到了某个项目里如果规范是全称命名，这里就会起冲突，代码风格会不稳定。第二，项目规则里不要放和全局规则完全对立的表述，除非你想覆盖它。覆盖时写清楚来源：“本规则声明覆盖全局规则中的XXX条目，因为本项目特殊。”我实测过，这种显式声明比默认隐含的覆盖更可靠。

3.4 配置文件的版本管理

.cursorrules和其他配置文件一样，理应纳入版本管理。但很多团队没把这当回事，导致新成员拉仓库后规则缺失，AI输出完全不一致。解决方式很简单：把.cursorrules放在仓库根目录提交，团队成员自动同步；如果你用的是.cursor/rules/目录，同样放到Git里。

版本管理还能带来另一个好处：你可以回溯不同版本的规则对输出质量的影响。比如某次升级后AI生成的代码风格明显变化，回头对比规则文件改动，就能快速定位到是哪些约束导致的变化。我一般会在规则文件头部写几行注释记录变更日期和原因，像改代码一样管理规则，这能避免“规则文件改乱了但不知道什么时候改的”这种尴尬。

4. 让“少写一半代码”落地的四种用法

4.1 从零生成页面：规则自动补齐上下文

配置好之后最直观的变化体现在新建页面时。以前我新建一个CRUD页面，光是搭列表、筛选表单、分页、编辑弹窗就要写几百行模板代码。现在只需要在会话里描述“角色管理，需要列表和弹窗表单”，Cursor基于项目规则自动识别出技术栈和组件库，会自动生成：

• 列表页文件views/role/index.vue
• 接口封装api/role.ts
• 弹窗表单组件components/role-form.vue
• 路由注册（如果你在指令中提到）

它生成的代码会直接使用request封装、统一日期格式、分页参数等约定。我之前统计过一个简单模块，手写大概需要400行，AI生成后我只改十几行的业务细节。真正帮你省掉的时间，基本就在这种地方积累出来的。

4.2 批量修改组件：规则避免“返工潮”

另一种高频场景是跨文件改造。比如设计稿更新，要求所有表格加一列操作按钮，或者所有删除操作增加二次确认。这种改动要是手写，得在几十个文件里重复查找替换；要是让AI自由发挥，它可能只改你当前的几个文件。

我的做法是在项目规则的“Common Tasks”部分定义好批量操作的规范，然后在会话里描述清楚：“遍历src/views下所有列表页，给它们统一加上导出按钮，导出使用requestDownload，文件名格式为模块名_yyyyMMdd.xlsx。”因为规则已经定义了工具函数和数据请求方式，AI不用猜，生成的改动基本一致。批量修改最怕的就是风格不统一，而规则恰恰能把这层风险兜住。

4.3 测试代码自动补齐

很多人忽略的一个“少写代码”场景是单元测试。测试代码重复度极高，手写会拖慢很多，又容易被拖延。有了项目规则，我可以在规则里约定测试风格，比如：

# Test Style - Unit tests use Vitest. - Test files are placed in `__tests__/` next to source files. - When testing async functions, use `vi.mock` for HTTP modules. - Always cover the happy path and at least one error branch.

之后在会话里给AI一段核心函数，让它直接补测试。因为规则里已经写了测试框架、文件位置、mock方式，生成的测试基本能直接接入项目。我在一个服务端模块里，用这个方式补齐了几十个接口的单元测试，比自己手写省了大概八成时间。

4.4 代码审查辅助：让AI按规则自检

最后这个用法常被忽略：让AI在生成代码后按照规则自检。很多人生成完代码直接粘贴，其实浪费了"规则约束"的二次收益。我会在会话末尾加一句：“现在检查你生成的代码，逐条核对项目规则，列出不符合规则的地方，并直接修正。”

这个做法能消除相当一部分低级问题，比如未使用的import、缺少类型标注、错误处理不完整、命名不符合约定。项目规则越具体，自检结果越可靠。这也反过来推动规则迭代——每次自检发现AI反复犯同一个错，就说明规则还没写到位，值得补充说明。

5. 常见问题与排查技巧实录

5.1 配置不生效怎么办

如果你发现AI完全不理会规则，首先检查当前打开的工作区是否包含规则文件所在目录。其次，在会话里直接问一句“请总结当前项目规则的关键内容”，看AI的回答是否包含规则里的要点。如果它答不出来，说明规则根本没被加载。这时检查文件路径和文件名，确认是.cursorrules且位于根目录。

如果你用的是.cursor/rules/目录方案，还要确认Front Matter里的Glob匹配范围。我踩过一次坑就是规则文件写成了中文文件名，结果AI一会儿生效一会儿不生效，最后发现是文件名编码有问题。建议统一用英文小写命名，别在这上面省事。

5.2 规则写得太死，AI反而变笨

规则不是越多越好，也不是越严越好。我见过一些团队把规则写成一份几十条的长篇大论，结果AI生成的代码非常机械化，遇到一点超出规则范围的情况就不知道怎么办，对话里反复确认“你希望我怎么处理”。规则过载的本质是上下文窗口被挤占，真正重要的约束被稀释了。

我的经验是每一条规则都要有明确收益：它帮你省了什么时间？避免了什么返工？如果一个约束从未被违反过，也不带来直接收益，就别写进去。项目通常保持15~30条有效规则，总体上不超过一个屏幕的高度。规则更新频率也不要太高，否则AI在对话里容易混淆新旧版本。

5.3 规则与AI输出冲突时的调和

还有一类问题是规则本身没错，但AI在执行时会“死守规则”而忽略任务的实际意图。比如规则里写了“所有列表页必须使用pageSize: 20”，但某个页面的业务就是要默认展示50条。这时候你直接在会话里补充一句“本条例外”，通常能解决。真正麻烦的是全局规则和项目规则冲突，这种情况下建议以项目规则为准，因为项目规则更贴近当前任务上下文。如果冲突频繁出现，就得反思全局规则是否写得过于武断。

5.4 多项目共用一个配置的心得

最后聊一下多项目场景。如果你同时维护好几个项目，技术栈各不相同，最忌讳的就是把所有偏好写到全局规则里。我的做法是全局只保留“作为一个严谨工程师如何思考”的原则，把具体技术栈全部下沉到项目规则。这样切项目时AI能迅速适应不同上下文，不会把这个项目的习惯带到另一个项目里。换项目之前，也可以花十分钟把新项目的关键约定补进项目规则，这笔投资回报率非常高。

写在最后

配置Cursor这件事，本质上不是在“调教工具”，而是在整理自己对项目的理解。每次完善规则，都是一次代码风格与工程约束的显式化。我最大的感受是：你愿意花多少心思把项目知识理清楚，AI就能帮你省下多少繁琐的编码时间。别一上来就追求大而全，从一个项目、几条规则开始，用两周时间迭代到顺手的状态，之后你会明显感觉到自己终于不是“AI代码的修理工”，而是那个盯着全局架构控场的人。