企业官网建设流程全解析

不知道你有没有遇到过这种情况：让 Cursor 改一个接口，它噼里啪啦输出三四十行，每个函数都带注释，看着挺专业，结果一跑类型检查直接红一片；让它顺手加个筛选条件，它把整个表格组件重排了一遍，提交的时候 diff 大到不敢点确认。次数一多，你很容易得出一个结论：AI 编程工具嘛，也就这样，鸡肋。

后来我发现，问题大概率不在模型，也不在工具，而在你还没给 Cursor“上装备”。这里说的外挂，不是作弊，也不是什么玄学咒语，而是一套显式的项目规则与上下文注入。说白了，就是把你自己脑子里的那份“项目地图”，完整复制一份给 AI。这篇内容就围绕这个“外挂”展开：它到底是什么、由哪几块拼成、怎么一步步配好、配好之后怎么用，以及我踩过的一些坑。适合已经在用 Cursor 或者别的 AI 编辑器、又觉得 AI 干活不够落地的开发者。

1. 先搞清楚：AI 干的活为什么会“鸡肋”

1.1 链子断在“你什么都没告诉它”

很多人在用 AI 编程工具时有个习惯：随手丢一句话，比如“把这个接口改成 POST”“给列表加个搜索框”。这句话对人是够的，因为人有脑子，知道你的项目长什么样。但 AI 不是人，它能看到的东西其实非常有限：你当前打开的若干文件、你主动粘进去的内容、以及你刚打的这句话。除此之外，它对你项目的了解接近于零。

于是它只能猜。猜你项目里二次封装了哪些组件，猜你的命名习惯是驼峰还是下划线，猜你的接口统一错误码是什么，猜你这个页面到底要不要走路由参数。猜对了是运气，猜错了是日常。这不是模型能力不行，而是它压根没有拿到该有的上下文。

我用一个类比来解释这件事：你让一个刚来的实习生“把这个页面改好看点”，他只会按照自己的审美自由发挥；但如果你告诉他“页面字号用设计规范里的三级字号，按钮统一用主色，布局间距走 8 像素栅格”，他的产出立刻变得能落地。Cursor 就是那个能力很强但完全不了解你项目的实习生，你缺的是一份“项目说明书”。

1.2 “外挂”到底是什么：规则、上下文、验证闭环

想明白鸡肋的根源，解决方案就清楚了。给 Cursor 装外挂，本质上是补三块东西：

第一块是上下文注入。把项目技术栈、目录结构、组件约定、接口规范、常见坑写成一个文档，放在仓库根目录，让 AI 动手之前先读一遍。这是解决“它不知道你们项目怎么回事”的问题。

第二块是行为规则绑定。把代码风格、安全红线、工作流程写成规则文件，告诉它什么能做什么不能做。这是解决“它明明知道该怎么做但不照做”的问题。

第三块是验证闭环。用 lint、类型检查、构建结果和最小 diff 当验收条件，让 AI 每次改完自己跑检查、自己汇报结果。这是解决“它改出来的东西你敢不敢用”的问题。

这三块缺一个，都会回到鸡肋状态。只给规则不给上下文，AI 知道“怎么改”，但不清楚“改在哪”；只给上下文不给规则，它懂了你的项目，但不一定遵守你的边界；两者都给了，没有验证闭环，它可能越改越飘，到后期你根本不敢让它碰代码。所以记住：所谓外挂，不是某个单一配置文件，而是一套最小闭环。

2. 配外挂之前，先盘点你项目里的“隐性约定”

2.1 用“新人入职清单”反推要补什么

很多人的误区是一上来就搜模板，把网上别人的 Cursor 规则往自己项目里塞。这跟相亲拿别人的自我介绍一样，包装得再好，底色对不上就是白搭。正确做法是先盘家底，搞清楚你的项目里有哪些“靠默契维持的约定”。

具体操作很简单：找一个最熟悉这个项目的人，或者你自己，回答一组问题。我常用的清单是这样的：

• 技术栈和构建工具分别是什么？
• 目录是怎么划分的，新模块应该放哪个文件夹？
• UI 组件库是哪个，有没有二次封装？
• 样式体系用 Tailwind、CSS Modules 还是设计令牌？
• 接口请求封装在哪里，错误码怎么约定？
• 状态管理用什么，业务数据统一放哪？
• 有没有必须遵守的安全红线？
• 命名、注释、文件组织有哪些惯例？
• 新增一个页面或模块的标准步骤是什么？
• 提交之前必须跑哪几条命令？

每个问题用一两行记录下来，最后汇总成一份十几条的清单。这份清单就是你“外挂”的核心内容。以我最近在配的一个后台管理系统“模拟项目X”为例，它是 Vue3 加 TypeScript 加 Vite 加 Pinia 的技术栈，最终盘出来的关键约定有十几条，其中对 AI 影响最大的有这些：

表格一律用二次封装的 XTable，禁止直接拼原生表格组件；新增和编辑统一用 XFormDialog 包一层；接口文件放在 src/api 下，按业务模块拆分；请求统一走 request.ts，错误码非 0 时全局统一提示；色值不许写死，要用主题令牌；组件文件必须有文件头注释；禁止在代码里写模拟数据；命名上文件用 kebab-case、组件用大驼峰、store 用 use 前缀。

这些约定看着不起眼，但 AI 如果不知道，就会用原生组件写一套独立风格，等代码合并进仓库，别人一看就知道是 AI 写的“外来物种”。

2.2 规则文件怎么放：全局、项目、任务三层

盘点完约定，接下来要决定每一条放哪。我自己在实践里把规则分成三层，按优先级从低到高排列。

第一层是全局层，对应 Cursor 的用户级规则，适用于所有仓库。这一层放的就是“你个人的编码习惯”，比如“函数超过 60 行必须拆分”“注释一律用中文”“禁止使用 any”。这些约束不管在哪个项目里都成立，所以放全局，省得每个项目重复写。

第二层是项目层，放在仓库根目录的 .cursor/rules 目录里，或者旧版本用根目录的 .cursorrules 文件。这一层放的是这个项目独有的约定，比如“表格用 XTable”“请求必须走 request.ts”。项目层会覆盖全局层，所以一旦出现冲突，以项目层为准。

第三层是任务层，也就是你在当前对话里临时粘贴的约束，例如“这次只改 src/views/dashboard，不要动其他文件”。任务层优先级最高，只在当前对话里生效。

这三层各有分工，维护原则是“越通用越往上放，越具体越往下放”。建议用新版 .cursor/rules 目录时，每个规则文件都要加上简短的描述和生效范围，这样 Cursor 才知道什么时候该加载哪条规则。拿不准自己用的是哪种机制的话，去翻一下官方文档，或者直接在输入框输入“/”看有没有 rules 相关命令。

3. 实战：给“模拟项目X”装上外挂

3.1 第一站：写一份“AI 项目入职手册”

我习惯把第一份关键文件放在仓库根目录，命名为 CURSOR.md（有的团队叫 AGENTS.md，原理一样）。这份手册不追求长，追求让 AI 看完立刻知道“这个项目是什么、约定是什么、哪些事不能做”。以下是我给模拟项目X 写的精简版本，你可以直接当一个底稿来改：

# 模拟项目X 开发说明（AI 必读） ## 项目定位 某后台管理系统前端，用于配置管理和数据看板。 ## 技术栈 Vue 3.4 + TypeScript 5.x + Vite + Pinia + Vue Router UI 使用基于 Element Plus 二次封装的自研组件库。 ## 目录速查 - src/api：接口定义，按业务模块拆分 - src/components：通用业务组件，优先复用 - src/composables：可复用逻辑 - src/stores：Pinia store，业务状态统一放这里 - src/views：页面 - src/styles：全局样式与设计令牌 - src/types：类型定义 - src/router：路由配置 ## 关键约定 1. 表格优先用 XTable，新增/编辑用 XFormDialog。 2. 接口请求统一通过 src/api/request.ts，错误码 0 表示成功，非 0 全局 toast。 3. 业务数据统一放 Pinia store，组件只维护 UI 状态。 4. 禁止写死色值，使用 tokens。 5. 组件文件必须加文件头注释。 6. 状态字段命名用驼峰，接口字段转换在 api 层完成。 ## 常用命令 pnpm install pnpm dev pnpm lint pnpm typecheck pnpm build ## 常见陷阱 - 不要在页面里直接 import 组件库原生组件，优先用封装组件。 - 不要绕过 request.ts 直接 fetch。 - 不要在生产代码里保留 console.log。

这份文件写完后，就算其他规则文件一个都没配，AI 的可用性也已经提升了一大截。因为它第一次知道了“目录长什么样、组件该怎么选、请求该怎么发”。如果你的 Cursor 版本支持自动加载根目录说明文档，它每次回答前都会自带这些背景；万一不支持，你还可以在对话里输入 @ 把这个文件手动拽进上下文，效果一样。

3.2 第二站：写一份“行为规则”规则文件

上下文文档解决了“知不知”的问题，规则文件解决“动不动”的问题。新版 Cursor 的规则放在 .cursor/rules 目录下，每个文件以 .mdc 为后缀，开头用 frontmatter 写描述和生效范围。如果你用的是旧版机制，直接把内容去掉 frontmatter 放到根目录 .cursorrules 文件里也能用，原理都是往上下文里注入规则文本。

我给模拟项目X 写了三个规则文件，分别管编码风格、工作流和安全红线。

第一个文件是 code-style.mdc：

--- description: 编码规范，所有 TS/Vue 文件必须遵守 globs: ["**/*.ts", "**/*.vue", "**/*.tsx", "**/*.js"] alwaysApply: true --- - 单个函数不超过 60 行，超过必须拆分并给出合理命名。 - 禁止使用 any；优先 unknown，必要时用类型守卫收窄。 - 禁止在代码中写死 URL、密钥、token，必须通过配置文件或环境变量注入。 - 修改现有组件时，优先复用 src/components 下已有业务组件，禁止重复实现。 - 组件模板内联逻辑超过两行，提取为计算属性或函数。 - 新增文件必须添加文件头注释，说明用途。 - 不要擅自改变已有 API 的返回结构；如需调整，必须说明原因。

第二个文件是 workflow.mdc：

--- description: 任务执行流程约束，所有任务必须遵守 globs: ["*"] alwaysApply: true --- - 动手改代码前，先阅读 CURSOR.md；若存在其他规则文件，也一并阅读。 - 默认采用最小差异原则：只修改任务要求的文件和代码块，禁止顺手格式化无关代码。 - 涉及新增文件或多文件改动时，先输出文件清单和改动计划，等用户确认后再实施。 - 修改结束后，运行 pnpm lint 和 pnpm typecheck，并把最终结果汇报给用户。 - 禁止在没有明确任务的情况下主动“优化”无关模块。

第三个文件是 security.mdc：

--- description: 安全红线，任何改动不得违反 globs: ["*"] alwaysApply: true --- - 禁止将密钥、密码、token 以任何形式写入代码、注释或提交记录。 - 禁止移除或绕过现有的鉴权、权限校验逻辑；相关改动必须提示用户人工复核。 - 禁止在代码中构造虚假的成功返回；接口报错必须走统一错误处理。

可能有朋友会问，这些规则看起来也不复杂，为什么能治“鸡肋”？关键在于我故意把规则全部写成了动词和动作，而不是形容词。我说的是“函数超过 60 行必须拆分”，而不是“保持代码整洁”；我说的是“优先复用 src/components 下已有组件”，而不是“写出高质量的代码”。AI 对形容词的词义理解很模糊，但对“必须拆分”“禁止使用”“优先复用”这类可执行指令敏感得多。你让它“保证质量”，它只能自由发挥；你让它“超 60 行就拆”，它就有了明确标尺。

3.3 第三站：让 AI 按流程出活：任务模板

规则配好了，日常使用时还有一个关键动作：用结构化的任务描述启动对话。我总结了一个比较稳的任务模板，每次直接复制改一改就能用：

请先阅读 CURSOR.md 和 .cursor/rules 下的规则，然后执行下面的任务。 任务：新增“设备列表”页面，路由挂在系统管理菜单下。 需求： 1. 页面使用 XTable 展示设备列表，列包括设备名称、型号、状态、创建时间、操作。 2. 新增和编辑使用 XFormDialog，表单字段包括设备名称、型号、说明。 3. 接口从 src/api/device.ts 导出：getDeviceList / createDevice / updateDevice。 4. 数据加载成功后放入 Pinia store，页面组件只负责渲染。 5. 改完后运行 pnpm lint 和 pnpm typecheck。 请先告诉我你打算创建或修改的文件清单，确认后再动手。

这个模板里最有效的两个设计，一个是开头强制它先读规则，另一个是结尾强制它“先交计划再动手”。前者保证它不会失忆，后者保证它不会一口气改出一大片。我在实操中发现，只要加了这两句，AI 的“乱改率”能明显下降。它先列出清单，你扫一眼就能看出问题——比如它打算改一个不该碰的公共组件，你马上就能拦下来。

如果任务是改 bug，模板可以更轻，但边界一定要写清楚。比如“只改 src/views/dashboard 下的文件，不要动其他文件；修复后运行 lint 和 typecheck 并汇报结果”。任务边界写在第一句，比写在最后一句有用得多，因为 AI 会先记住第一句。

3.4 第四站：验证闭环：让产出可持续

配置做完了，不代表过程可以不管。我给这套外挂加了一个“验证闭环”，核心就一句话：让 AI 的产出每次都由检查工具守门，而不是由你的眼睛逐行扫雷。

具体操作分三步。第一步，让 AI 改完后自己跑 pnpm lint 和 pnpm typecheck，把结果贴回来。第二步，如果报错，把报错信息直接复制回对话框，让它基于报错修正，这比你自己去修快得多。第三步，在脑内加一道“diff 复盘法”：改完之后打开 diff，只看三样东西——是不是只改了该改的文件；有没有夹带私货；有没有绕过项目约定。这三样没问题，基本就可以放心提交。

我还会为每一个独立小任务开一个临时分支，强制自己执行最小粒度验证。如果 AI 改崩了，直接切回主分支，放弃这个临时分支，不做任何抢救。很多人在 AI 上一改崩就开始纠结“能不能修回来”，其实没必要，回滚分支比在泥潭里挣扎省时多了。

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

4.1 规则写好了但没生效

这是最常遇到的情况。辛苦配了一堆规则，结果 AI 回答起来还是老样子，第一反应是“这外挂是不是没插上”。按顺序排查这几点：

先确认规则文件放的位置对不对。新版是 .cursor/rules 目录下的 .mdc 文件，旧版是根目录的 .cursorrules 文件，两者别混用，更别放错目录。再确认 globs 匹配范围是否覆盖你正在改的文件类型。比如 code-style.mdc 的 globs 只写了**/*.ts，那你改 .vue 文件时它自然不会加载。

规则文件修改后，建议执行一次重载窗口操作。Cursor 对规则文件的加载有时候会走缓存，重载一次能排除这个干扰。最后，还有一个快速验证方法：在对话框里输入 @ 并选择对应规则文件，看它是否能出现在上下文里；或者直接问它“请复述 code-style.mdc 的内容”，能复述就说明读到了。

4.2 AI 读到了规则，但就是不听话

规则能被复述，不代表它执行时一定照做。这里要理解一个关键点：规则只是上下文的一部分，AI 在生成过程中会根据当前对话权重做取舍，它是在“权衡”而不是在“执行程序”。所以当它反复无视某条规则时，不要以为写进文件就万事大吉。

我试过最有效的方法是在任务描述里显式点名。比如“请严格按照 workflow.mdc 执行，不要动本任务之外的文件”，比单纯让“遵守项目规则”有用得多。另一个方法是把最关键的一两条约束直接复制到当前对话里，放在任务描述后面。AI 对最近阅读的内容权重是最高的，你临时强调一下，比翻旧规则立竿见影。

还有一点：规则文件不是越多越好。我见过有人一口气塞了十几个规则文件，条目加起来一百多条，结果 AI 上下文被塞满，反而表现变差。规则是资源，你得克制。保留几条真正能改变结果的，其余删掉，效果反而好。

4.3 上下文被打爆，AI 表现变差

规则和手册写得太长，是另一个反面典型。我一开始写过一份三百行的 CURSOR.md，什么背景、历史、规划都往里塞，结果 AI 读到后面忘了前面，经常自己打自己脸。后来我把 CURSOR.md 压到十几条核心约定，背景资料挪到 docs 目录，只在需要时用 @ 主动拉进对话。

判断上下文是否过载有个简单方法：同一个约定你在规则里写、它在回答里做，但它们之间开始出现冲突，比如 AI 把旧约定和新规则混在一起说，大概率就是上下文里同类信息太多了。这时候别急着加规则，先做减法。保留 1 份上下文手册加 3 个以内规则文件，是一个比较稳的规模。

4.4 AI 改着改着开始“夹带私货”

最让人头疼的是，你让它加一个字段，它顺手把组件库封装改了；你让它修一个 bug，它顺手重命名了变量。这类“夹带私货”表面上没坏处，实际上让 diff 变得极其难审，时间一长，仓库里全是 AI 的私货。

应对方法有三个，都在前面提过但值得再说一遍：任务模板第一句圈定文件范围；workflow.mdc 里写明最小差异原则；每次改完用 diff 复盘。如果还是出现了夹带私货，最快的处理路径不是去修改，而是把那个文件回滚，重新下任务并再次强调边界。不要因为“它改得也不算差”就留下，这一次留着，下一次它就有理由继续越界。

我把常见的几个现象整理成了速查表，方便日常排查：

5. 我踩过的几个坑

这套外挂配置法，我是在反复踩坑之后才逐渐稳定的。第一次写规则，我几乎是把团队规范文档直接丢进去，全是“保持代码整洁”“注意可维护性”“遵循最佳实践”这类漂亮话。结果 AI 的执行效果跟没配规则差不多，因为形容词无法指导生成。后来我一条条改成动词，效果肉眼可见地变好。从那之后我给自己立了个规矩：规则文件里不出现形容词，不出现口号，只出现动作。

第二个坑是贪多。有一阵子我把规则文件增加到十个，每个文件都写得很详细，满心以为 AI 能像读操作手册一样严格执行。结果恰恰相反，规则之间互相争抢注意力，AI 经常捡了芝麻丢了西瓜。后来我把十个压缩到三个，专注于编码、流程、安全，反而体验直线上升。这让我意识到，规则的目的是改变 AI 的行为，而不是把文档做得多完整。

第三个坑是 CURSOR.md 写了一整版“项目百科”。那段时间 AI 经常表现出一种诡异的“知识分裂”，刚才还在按新约定写代码，过了一会儿又用起早就废弃的老组件。后来我才想到，它可能是从长文档里读到了过时的信息。压缩文档、删除过期段落、只留当前约定之后，这个问题就消失了。现在每隔一两个月，我会专门清理一次 CURSOR.md 和规则文件，把它当成给项目做一次约定层面的维护。

我个人用下来最值的一步，是把这份配置顺手当成了新人入职文档。同一位 AI 助手技能和同一个新人入职手册是同一份文件，新同事看了能快速上手，AI 看了也能快速对齐，一份投入两份收益。给 Cursor 装外挂这件事，说到底不是给 AI 加东西，而是逼你自己把项目里那些“靠默契”的东西显性化。规则配好之后，它干的活从“能用但不敢用”变成“能用且敢用”，这个转变值得你花一个下午去配。

如果后面想走得更深，你还可以把 lint、单测、构建脚本串成一条自动验证链路，让 AI 每次改完自动跑完所有检查再汇报。配置会随着项目演进而迭代，但核心思路不变：把上下文给它，把规则立起来，把验证闭环合上，AI 就不会继续干鸡肋的活了。