大家好，我是前端宝哥。今天，我将结合我个人的使用体验，和大家深入探讨 AI 编程工具，尤其是像 Cursor 这样的工具，如何能够更有效地为我们服务。
AI 编码工具如 Cursor，既可以是开发者的福音，也可能成为困扰的源头。当它们有效运作时，能带来奇迹般的效率提升；然而，一旦失控，其后果可能就像让一个缺乏经验的人在您的代码库中随意操作。我曾多次面对 AI 生成的混乱代码，不禁反思是否传统的手动编码反而更为稳妥。在经历了多次深夜调试的挑战后，我终于总结出了一套行之有效的方法，确保 Cursor 能够稳定地满足我的需求。以下是我从实战中提炼出的策略，希望能帮助各位避免混乱，充分发挥 Cursor 的潜力。
为什么 Cursor 可能破坏您的代码（以及如何修正）
核心问题在于：Cursor 并非具备读取我们心思的能力。如果在缺乏明确计划的情况下直接让它编码，无异于迫使其猜测您的意图——而它在猜测方面往往表现不佳。我曾有过深刻教训：在一次尝试让 Cursor 构建任务管理应用时，由于指令模糊，最终得到的是一个由各种不兼容框架拼凑而成的混乱项目。解决方案是什么？关键在于规划——更准确地说，是七分规划，三分执行。接下来，我将详细阐述。
第一步：将规划置于首位
我过去也曾习惯于直接启动 Cursor，输入“帮我构建一个应用”之类的模糊指令。事实证明，这是一个重大的错误。现在，我将规划视为整个工作流程的基石，这一转变带来了显著的成效。
我的辅助工具：ChatGPT 语音功能
我知道，使用另一款 AI 工具来辅助 Cursor 的使用听起来可能有些不同寻常，但请容我解释。在正式编码前，我会利用 ChatGPT 的语音功能来口述我的思路。将想法清晰地表达出来，哪怕只是自述，也能帮助我更透彻地理解需求。例如，在构思一个任务管理应用时，我可能会这样描述：
“我正在构建一个用于管理任务的应用。用户需要能够添加、编辑和删除任务。我需要一个主页来列出所有任务，一个表单用于添加新任务，以及一个页面用于编辑现有任务。”
ChatGPT 语音功能帮助我勾勒出初步的框架，我通常会将其简要记录下来（是的，我依然保留着一些传统的记录习惯）：
任务应用计划 - 核心概念：简洁的任务管理 - 必备功能： - 添加、编辑、删除任务 - 查看所有任务 - 用户流程： - 主页：任务列表 - 添加任务页面：表单 - 任务详情页面：编辑功能
这份简单的草案便成为我后续工作的指引，确保我与 Cursor 的协作能够沿着正确的方向进行。
第二步：完备的文档记录
这是我从实践中得到的一个重要教训：AI 生成代码的质量，直接取决于您所提供的上下文信息。如果忽略了文档环节，Cursor 很可能会做出不理想的决策——例如，我曾遇到过它构建的后端 API 缺乏基本的错误处理机制，这非常令人困扰。
我的首选工具：CodeGuide
我使用一款名为 CodeGuide 的工具来生成两份核心文档：
- 产品需求文档 (PRD)：明确“做什么”——包括功能特性、用户故事、边缘案例等。
- 技术栈文档：明确“如何做”——包括所使用的框架、库和工具。
以我的任务应用为例，以下是 PRD 的部分片段：
PRD: TaskMaster (任务大师)
- 目标：实现极致简洁的任务管理
- 用户故事：
- 我希望能够添加任务来追踪我的工作
- 我希望能够编辑任务以修正输入错误
- 我希望在任务完成后能够将其删除
- 技术栈：
- 前端：React + TypeScript (保障类型安全)
- 后端：Node.js + Express (轻量且高效)
- 数据库：MongoDB (适用于小型项目的灵活性)
这些文档为 Cursor 提供了清晰的指导，有效避免了不必要的猜测。
第三步：避免从零开始
使用 AI 工具时，从一个完全空白的项目开始往往会引发问题。Cursor 在处理项目初始化（如文件结构、样板代码、依赖关系配置）方面可能表现不佳。我曾遇到过它生成的 React 项目中 Webpack 配置存在错误的情况。因此，我现在总是选择使用一个合适的启动模板 (starter kit)。对于我的任务应用，我选择了一个包含 React 和 Node.js 的启动模板，其结构大致如下：
taskmaster/
├── frontend/
│ ├── src/
│ │ ├── components/
│ │ ├── pages/
│ │ └── App.tsx
├── backend/
│ ├── src/
│ │ ├── routes/
│ │ └── server.ts
└── README.md
使用启动模板能让 Cursor 更专注于功能实现，而非基础架构的搭建。这如同为厨师准备好预处理的食材，可以减少不必要的麻烦，提升工作效率。
第四步：正确配置 Cursor
当规划、文档和启动模板都准备就绪后，在向 Cursor 输入第一个提示之前，还有一些关键的设置步骤：
- 在您的项目根目录下创建一个名为
Instructions的文件夹。 - 将您通过 CodeGuide 生成的文档放入此文件夹。
- 通过以下指令告知 Cursor 使用这些文档作为上下文：
Go through all files in Instructions and use them as context.
(请查阅 Instructions 文件夹中的所有文件，并将其用作上下文。)
这个步骤相当于在项目开始前为 Cursor 提供一份详细的蓝图。忽略此步骤可能会导致后续出现预期之外的问题。
第五步：“项目规则”的运用
这是提升 Cursor 使用效果的关键环节。以往 Cursor 频繁生成不符合预期的代码，主要原因在于未能设定明确的规则。缺乏规则引导，它只能进行猜测——而这些猜测往往是不准确的。例如，我曾明确需要 React 函数组件，但它却生成了类组件，这非常令人沮丧。
.cursorrules 的局限性
Cursor 最初依赖单一的 .cursorrules 文件进行规则管理，但这在实践中效果不佳。所有指令集中在单个文件中，Cursor 常常会忽略部分内容，其可扩展性差，导致 AI 响应不稳定。
项目规则 (.mdc 文件) 的引入
幸运的是，Cursor 引入了项目规则 (Project Rules)，通过在项目根目录下创建 .cursor/rules/ 目录，并在其中使用 .mdc 文件进行管理。这是一项重大的改进。项目规则允许您为项目的不同部分设定具体指令。以我的任务应用为例，我设置了如下规则：
taskmaster/
├── .cursor/
│ └── rules/
│ ├── frontend.mdc (前端规则)
│ └── backend.mdc (后端规则)
frontend.mdc (前端规则)
Scope: **/*.tsx (作用域：所有 .tsx 文件)
Rules:
- Use functional components + React hooks (no class nonsense) (使用函数式组件和 React Hooks，避免使用类组件)
- Stick to TypeScript strict mode (I'm a type nerd) (遵循 TypeScript 严格模式，我注重类型规范)
- Use Tailwind CSS (it's fast) (使用 Tailwind CSS，因其构建速度快)
backend.mdc (后端规则)
Scope: api/**/*.ts (作用域：api 目录下的所有 .ts 文件)
Rules:
- Use Express.js for routing (my go-to) (使用 Express.js 进行路由管理，这是我的首选方案)
- Follow RESTful API conventions (standards matter) (遵循 RESTful API 设计规范，标准至关重要)
- Use async/await (no callback hell) (使用 async/await 处理异步操作，避免回调嵌套)
通过这些精确的规则，Cursor 的行为变得更加可预测，能够生成符合要求的代码，效果有了显著提升。
第六步：收获成效
自从采用项目规则后，我的工作流程得到了明显改善。Cursor 产生的错误减少，能够更好地遵循我的编码风格，并且多数情况下能一次性生成符合要求的代码。这种体验类似于有了一位能够准确理解并执行指令的初级开发人员协助工作。
第七步：关于项目规则的实践建议
以下是我在实践中总结的关于有效使用项目规则的一些建议：
- 规则应具体化：针对前端、后端等不同模块分别设置规则，避免将所有指令混杂在单一文件中。
- 作用范围需精确：确保规则仅应用于指定的代码范围，例如
.tsx文件对应 React 组件，api/**/*.ts对应后端接口。 - 尽早进行测试：首先生成小段代码片段，以验证 Cursor 是否正确遵循了您设定的规则。
- 根据需要及时更新：如果项目需求或技术栈发生变化，务必同步更新您的规则，避免规则陈旧失效。
AI 编码的关键
如果您对 AI 生成代码的不可靠性感到困扰，核心的解决之道在于：充分准备和有效控制。通过 ChatGPT 语音版进行规划，使用 CodeGuide 撰写文档，基于启动模板开始项目，并利用 .mdc 文件设置明确规则——遵循这些步骤，Cursor 可以从一个潜在的困扰源转变为一个高效的编程助手。
我希望大家能够运用智慧，更高效地利用这些工具进行编码，而不是进行低效的重复劳动。
以上便是前端宝哥本次的经验分享，希望能对各位有所裨益。
