企业官网建设流程全解析

说实话，用 AI 写代码这件事，我自己从最初的新鲜期一路走到现在，差不多经历了三个阶段：真香、鸡肋、真香。前两次“真香”中间夹着的那个“鸡肋期”，恰恰是我对 Cursor 这类 AI 编程工具从“看热闹”转向“看门道”的节点。如果你现在也觉得 AI 生成的代码多数只能当参考，真正落地还得靠自己重写，那这篇内容就是讲我怎么给 Cursor 装上各种“外挂”，把那些半吊子的 AI 输出，逐步变成能直接进生产环境的产出。

这篇文章适合谁？适合已经用过 Cursor、但总觉得 AI 写的东西不够顺手的人；也适合刚接触 AI 编程、想少走弯路的人。我会从问题根源讲起，再到规则文件、工具链接入、完整工作流，最后附上我踩坑后的排查记录。没有太多高深理论，全是能直接抄过去用的配置和思路。

1. 为什么 AI 干的活经常“鸡肋”

1.1 问题不在模型，在边界

很多人觉得 Cursor 生成代码“鸡肋”，是因为模型能力不够。但实际用下来，我更倾向于另一个结论：大部分问题出在使用边界没划清楚。模型有一个已知的强项，就是基于给定上下文做延续式生成，给的信息越具体，输出越接近预期；给的信息越宽泛，它就越容易发挥出“废话文学”的天赋。

比如你直接在对话框里写“帮我优化一下这段代码”，模型只能猜。猜你指的是性能优化、可读性优化还是安全优化，猜你现在的技术栈是什么，猜你有没有测试兜底。一旦猜偏，结果自然就是那种“说不上错、但根本没法直接用”的鸡肋代码。

1.2 缺上下文，是鸡肋的第一来源

我发现最常见的失败模式是这样的：AI 只看到了当前打开的一两个文件，就敢给出一版改动方案。它不知道这个项目有没有统一的路由封装，不知道接口请求走的什么层，更不知道状态管理用的什么方案。结果生成出来的代码，风格跟项目里其他文件完全对不上，复制进去之后，编译倒是能过，但代码审查时一眼就被打回。

人类程序员接手一个陌生项目时，第一件事是看 README、看目录结构、看整体架构。AI 不会主动做这些事，除非你告诉它。这就是为什么直接让它干活，往往只能得到“局部正确、整体无语”的结果。

1.3 没有反馈闭环，AI 在盲目飞行

再往深一层说，AI 干的活鸡肋，还有一个关键原因：它没有自己验证的能力。你写代码的时候，写完会编译、会跑测试、会看一眼报错；但 Cursor 里的 AI 默认没有这个环节，它生成完代码就开始等你的反馈，就像一个人在黑屋子里拍了一张照片，然后问你“拍得怎么样”。有时候它生成的是残缺函数，有时候是过时 API，但因为没有反馈，它自己并不知道。

所以后来我的思路整个转变了：与其指望 AI 一步到位，不如把环境给它配好，让它能查资料、能跑命令、能看报错、能自己改自己。这一步，就是从“对话式编程”迈向“代理式编程”的核心差异。

2. 先立规矩：规则文件是性价比最高的外挂

2.1 一分钟看懂规则文件机制

如果你还没认真用过 Cursor 里面的规则文件，那我建议从它开始。简单说，规则文件就是一段持续性注入给 AI 的上下文，它会随你的每次提问一起发送，相当于给 AI 立了一套“对话前必读”的行为准则。

这个机制的价值在于，你不用每一次对话都重复解释“我们是 Java 项目、用 Maven 构建、代码风格是 Google Style、不要随便动公共模块”。只要规则文件里写清楚了，AI 每次回答都会默认遵守。这就像给新同事发了一份入职手册，而不是等对方反复来问。

规则文件分为项目级和全局级。项目级放在项目根目录，文件名通常是 .cursorrules，生效范围局限在当前项目；全局级放在全局配置目录，对所有项目生效。我的做法是全局文件只写通用的行为准则，比如“不要编造不存在的 API”，项目文件才写具体的架构约束和编码规范。

2.2 一份生产可用的规则文件模板

下面这份模板我在多个项目里反复调整过，基本可以直接套用。关键不是模板本身，而是每一条背后要对应真实的项目约束，别写空话。

# 项目背景 这是一个面向内部运营人员使用的数据可视化平台，前端采用 React 18 + TypeScript + Vite， 后端采用 Spring Boot 3，数据库为 MySQL 8。项目内已存在统一的请求封装（src/utils/request.ts）， 所有接口请求必须通过该封装发起，禁止在业务代码中直接使用 fetch 或 axios。 # 代码规范 - 组件文件使用 PascalCase 命名，工具函数使用 camelCase 命名。 - 样式优先使用 CSS Modules，禁止使用全局 class 污染。 - 所有异步操作必须考虑 loading 和 error 状态，不得静默失败。 - 禁止在组件内部直接写复杂的业务逻辑，请抽取到 src/hooks 或 src/services。 # 架构约束 - 业务状态管理使用 zustand，已有 store 位于 src/stores。 - 公共组件放在 src/components/common，业务组件放在 src/features/{业务名}/components。 - 新增页面必须配置路由与菜单权限，相关配置位于 src/router。 # 开发流程 - 修改前先阅读相关文件，理解现状后再动手。 - 涉及多个文件的大改动，请先输出改动清单，等待确认后再开始编码。 - 生成代码必须符合 TypeScript 严格模式，禁止使用 any。 # 不要做什么 - 不要改动 package.json 中已有依赖的版本。 - 不要修改后端接口定义，如有需要请提出建议，由人工确认。 - 不要生成没有实际调用的死代码。

注意，规则文件不是越长越好。我自己吃过亏，一开始恨不得把所有约定都塞进去，结果 AI 经常被长规则干扰，反而把重要约束给忽略了。后来我控制在十到二十条，每条一句话讲清楚，效果明显改善。把最重要的约束放前面，因为模型对靠前内容的注意力通常更强。

2.3 规则文件里的三个常见误区

第一个误区是把规则写成散文。比如“希望 AI 能生成高质量且可维护的代码，注意遵循业界最佳实践”，这种内容没有任何信息量。规则要具体到能被执行和校验，最好是有“是或否”的判断标准。

第二个误区是规则之间互相冲突。比如前一条说“所有接口走统一封装”，后一条又说“某些场景可直接使用 axios”。一旦出现这种情况，AI 的表现会非常不稳定，这次听这条，下次听那条。所以规则文件里要尽量避免“例外条款”，如果真有必要例外，就明确写清楚触发条件。

第三个误区是写了规则就再也不更新。规则文件应该跟项目同步演进，公共模块一旦调整，规则里的描述也要跟着改。我习惯每次代码审查时顺手过一遍规则，发现过时描述就更新，这个习惯帮我避掉过不少 AI 乱带节奏的坑。

3. 打通工具链：让 AI 真正“动手干活”

3.1 从“会聊天”到“会办事”的关键一步

规则文件解决了“AI 说人话”的问题，但距离“AI 干实事”还差一步：它仍然不能主动查资料、执行命令、跑测试。默认情况下，Cursor 里的人工只能靠对话框输入，AI 输出文字和代码块，剩下的动作全部由人来完成。这就像你请了一个只肯写方案、不肯动手打印的助理。

后来我接入了一套东西，业内管它叫 MCP，全称是 Model Context Protocol。你可以把它理解成给 AI 装上的“手脚”——让模型能够通过标准协议去调用外部工具。这样 AI 就可以自己检查项目文件、执行构建命令、搜索文档、操作浏览器，甚至查数据库。它彻底改变了协作方式：从“人想一步、AI 写一步”，变成“人提目标、AI 自己想办法完成并自我验证”。

3.2 用一个最小配置跑通 MCP

接入 MCP 的第一步是配置文件。在项目根目录创建 .mcp.json，内容类似下面这样：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "."] }, "command-runner": { "command": "npx", "args": ["-y", "mcp-server-command-runner"], "env": { "ALLOWED_COMMANDS": "npm,git,node,python" } } } }

配置里给 AI 开了两个“外挂”：一个是文件系统访问，让它能读取项目目录里的任何文件；另一个是命令执行器，限定只能运行 npm、git、node 等命令。从我实际使用的安全角度来说，给 AI 开放命令行权限要克制，越具体的命令白名单，越是好习惯。

配好之后，重启 Cursor 的会话，AI 那边会自动识别可用工具。你在对话里提出需求，它会在回复的过程中调起这些工具。比如让它“看看这个目录下有哪些文件”，它不再只是猜测，而是真的去列出文件列表。这一步一旦走通，后面很多工作流都会轻松不少。

3.3 自定义斜杠命令：把高频操作变成一键触发

除了 MCP，Cursor 还支持自定义斜杠命令。我把它理解成“给 AI 预设的常用话术模板”。举个例子，我写了一个 /review 命令，作用是把当前改动的代码交给 AI 做一轮代码审查。每次写完功能，我不需要再打字说明“请你看一下我改的东西，重点关注边界条件和错误处理”，只需要敲 /review 回车。

斜杠命令需要放在项目目录的 .cursor/commands 下，每个命令一个 md 文件。下面是一个典型的提交助手命令：

# 文件：.cursor/commands/commit.md 请根据当前的 Git 改动内容，生成一条符合 Conventional Commits 规范的提交信息。 要求： 1. 先运行 git status 和 git diff --stat 查看改动范围。 2. 再查看 git diff 中的关键内容，理解改动意图。 3. 提交信息格式为 type(scope): description。 4. 如果改动涉及破坏性变更，在提交信息末尾注明 BREAKING CHANGE。

这样做的好处，不只是省几个字，而是让每次触发的“行为模板”保持稳定。我实际用下来，斜杠命令最重要的价值在于把人的经验固化下来。你平时是怎么指挥 AI 的？把最顺手的几套指挥方式沉淀成命令文件，下次在新项目里也直接同步过去，整个团队都能受益。

3.4 补充一个给 AI 配“技能包”的进阶方向

如果你有编程基础，还有另一个思路很值得尝试：为 AI 额外挂一个私有工具箱。原理不复杂，就是把你自己写的 Python 脚本、Node 脚本暴露成 MCP 服务，让 AI 在需要的时候调用。

举个例子，我维护一套数据库元信息读取脚本，AI 在写数据查询相关代码时，可以通过这个脚本直接读取表结构，而不是靠我的口述。这比让 AI 去翻建表语句文件要可靠得多，因为脚本的输出是清洗过的、聚焦的。这个能力做起来并不难，你需要在一个本地服务里实现几个 JSON-RPC 接口，注册到 MCP 配置里去。第一次配置会花一点时间，但一套完整的项目专属工具链，收益会持续很久。

4. 工作流实战：从需求到验收，告别一次性对话

4.1 一个真实的协作场景

前面把规则、工具链都讲了一遍，现在落到一个具体场景里串起来看。假设我要在一个老项目上加一个新功能：给订单列表增加一个“导出 CSV”按钮，后端接口已经有人写好了，但前端需要接入。

如果按老办法直接问 AI，大概率得到的结果是：一个写死的接口地址、一段没有 loading 状态的下载逻辑、还有一堆跟项目风格不一致的代码。但按我配好规则和工具的工作流，操作过程完全不一样。

4.2 四步推进法

第一步，让 AI 先“读”再“说”。我会要求它先查看路由配置、请求封装、列表页现有逻辑，然后输出一份改动影响清单。注意，这一步的关键不在清单本身，而是强迫 AI 在动手之前建立项目上下文。它输出的清单通常长这样：要改哪几个文件、每个文件改什么、是否新增接口封装、是否涉及权限菜单配置。我会检查一遍，确认无误后再让它开工。

第二步，拆分任务，小步推进。我不会让 AI 一次性把所有文件改完，而是拆成三个任务：新增 CSV 导出工具函数、接入列表页按钮、补充导出完成后的提示逻辑。每个任务都让 AI 遵循“先解释思路、再生成代码”的方式，完成后停下来等我的反馈。这样做的好处是，一旦某一步跑偏，修正成本很低，不用推倒重来。

第三步，强制自我验证。任务完成后，我会要求 AI 自己跑一遍相关检查，通常是指定它执行 linter 或 TypeScript 类型检查。如果环境中配好了 MCP，命令由 AI 自己触发；没有配好的话，我把检查结果贴回去让它修正。这一步是很多“鸡肋”输出的终结者，因为大量低级问题在类型检查阶段就暴露了，AI 自己就能改掉。

第四步，人工走查，重点看边界。AI 把功能做完之后，我不会直接合并。我会把注意力放在它最容易忽略的细节上，比如导出的文件名是否有时间戳、空列表时按钮是否可用、接口返回异常时用户看到什么提示。这些边界问题，规则文件里很难写全，必须靠人来补位。但有了前面几步，人工走查的负担已经降到很低了。

4.3 一个高价值的提示词模板

上面这套流程，我沉淀成了一套提示词模板，每次在 Cursor 新对话里开始时先发一遍：

我接下来会给你布置一个开发任务。请你按以下流程执行： 1. 先阅读相关文件和目录结构，理解现状，输出改动影响清单。 2. 等我确认清单后，再开始写代码。 3. 每次只完成一个子任务，完成后停下来等待反馈。 4. 每个子任务完成后，请主动说明你做了什么、改了哪些文件、验证了什么。 5. 如果你发现方案存在坑或有更优解，请直接指出，而不是蒙头执行。

这个模板的价值在于，它把一次性的大对话变成了多轮的小协作。AI 不再是一个“话痨生成器”，更像一个“有任务边界、会汇报进度的协作者”。我强烈建议你把这个模板存成全局斜杠命令，任何项目都能用。

4.4 关于人工审阅的聚焦建议

很多朋友问过我一个问题：既然 AI 都能跑了，人工还要看什么？我的经验是，人工看得不是代码本身，而是确认三件事：需求理解对不对、边界覆盖全不全、改动面是否最小。这三件事恰好是 AI 在现有技术条件下的短板。

需求理解方面，AI 容易把“导出 CSV”理解成“把当前表格内容导出”，但产品真正要的可能是“根据筛选条件导出全部匹配数据”。边界覆盖方面，AI 倾向于处理正常路径，对异常路径要么草草带过，要么写一堆防御代码。改动面控制方面，AI 有时为了达成目标，会顺手重构它觉得不顺眼的旧代码，这其实是工程上的大忌。每回人工走查时，把这三件事放在最前面，效率会高很多。

5. 常见问题与排查实录

5.1 规则“不生效”怎么办

最常遇到的问题就是明明写了规则文件，AI 还是我行我素。我自己排查下来，原因通常是三种：一是规则文件放错了位置，项目级规则必须放在项目根目录，而且文件名要完全正确；二是规则内容跟对话里的即时指令冲突，而即时指令的优先级更高，如果你在对话里又说“别管规则，直接给我答案”，那 AI 自然会顺从后续指令；三是规则写得太长或太抽象，模型没能有效提取约束。

解决办法也很直接。先确认文件路径和名称，再检查规则里的每一条是否具体可执行。如果都没问题但依然不生效，就把最关键的一条规则直接复制到当前对话里，强制它先确认收到。一个小技巧是，新改完规则文件后，最好新开一个对话，旧对话里的上下文不会自动加载最新的规则。

5.2 AI 改完的代码无法通过编译

这类问题的根源通常是 AI 没见过完整项目上下文，尤其是依赖关系比较复杂时。报错信息里经常出现“找不到模块”或“类型不存在”之类的提示。以前我的做法是自己去修，后来改成把报错信息原样贴回给 AI，让它自己追踪问题、给修复方案。

这里有个关键细节：不要只贴最后一两行报错，要贴完整日志，最好带上相关文件片段。AI 从完整日志里判断原因的准确率，比只看摘要高出一大截。顺着这个思路，我后来干脆把“编译检查”写进任务必做清单，每次任务收尾时让 AI 先跑一遍检查再交付，这类问题就少了很多。

5.3 不同会话之间“失忆”

如果不做额外处理，每次新开对话，AI 都不记得上一个对话发生了什么。这在多文件、多轮次的大功能开发中会很折磨人，上一轮刚确认的决策，下一轮它可能又跑偏。

我的经验是把关键决策固化到文件里。比如规则文件、设计说明文档、改动清单，这些都应该以文件形式存在于项目中。新对话开始后，先让 AI 去读这些文件，再开始工作。这相当于给 AI 建了一个“外部记忆库”，效果很好。另外，遇到跨大量文件的改动时，我会考虑把所有相关任务放在同一个对话里完成，减少中断传导的损失。

5.4 快速排查速查表

下面这张表是我自己贴在笔记里的小抄，遇到问题先对着找一遍，多数情况能快速定位：

5.5 一点关于预期管理的体会

最后说点个人体会。把 Cursor “外挂”配齐之后，并不是说你就可以躺平了，而是你的工作重心从“逐行写代码”变成了“定义标准、控制流程、审查边界”。我自己的时间里，写代码的比例反而下降了，思考设计和把关质量的比例明显上升。这个转变对个人心态也有影响，以前看到 AI 产出垃圾代码会烦躁，现在我会习惯性地想：是不是我的输入还不够具体，哪条规则没覆盖到。

这种把问题归因于“系统设计”而不是“工具垃圾”的思路，是我觉得用好 AI 编程工具最重要的心态转变。工具只是工具，规则、上下文、工具链、反馈机制，这些才决定它在你手里到底是一个“打字辅助”，还是一个真正能分担生产任务的协作者。

如果你也想给自己的 Cursor 装一套趁手的配置，我的建议是从规则文件开始，再到斜杠命令，最后尝试 MCP 工具链，循序渐进。不要一上来就追求一步到位，否则只会给自己徒增配置负担。先把一小块流程跑顺，再慢慢扩展，你会发现 AI 干的活，慢慢就不再鸡肋了。