Cursor Vibe Coding心得分享

最近在使用 Cursor pro 从零开始设计并编写一个项目（React 前端 + FastAPI 后端 + Tauri 打包），完全 vibe coding，几乎没有手写一行代码。

在这个过程中我摸索出一套 AI Agent 编写项目的技巧。今天就来分享一些我使用 Cursor vibe coding 的心得。

写在前面

这篇心得并不鼓吹“全自动 AI 编程”。我深知 AI 能力有限，也在实践中慢慢摸索 AI 能力的边界。我只想分享一些我摸索出的 AI 协作工作流与心法，不希望给读者”一句话就能完成一个项目“、”完全vibe coding，一路 Accept，不需要人工干预“的印象。

虽然我确实在整个编码阶段都在 vibe coding —— 只提需求，放心让 AI 全自动编码，也没怎么 review 代码，但实际上我在项目过程中做了很多工作：

1. 项目前期规划，定义项目愿景、MVP、UI/UX设计、系统架构设计等等，并且形成 AI 可读的文档，为 AI 提供项目上下文
2. 仔细审查 AI 生成的每一个任务规划
3. AI 完成阶段性任务后，由我来测试、验证并提供反馈。
4. 定期重构，保持代码整洁

这些工作乍一看没太大意义，但实际上是 AI Agent 高效运转的基石。具体为什么，容我先卖个关子。

准备工作

在开始一个项目之前，我们需要先配置好 Cursor。这里配置指的不仅仅是配置编程环境、安装插件，更重要的是，为 Agent 配置好工具 —— Cursor rules、项目文档以及 MCP 服务器。

Cursor rules

在 Cursor 中，我们可以通过 Cursor rules 为 Agent 设定行动规则、提供上下文。具体的配置方式是，在项目根目录的 .cursor/rules/ 文件夹下创建一系列的 *.mdc 文件，在其中添加规则。

对于每个项目，我会添加以下规则：

• 基于 RIPER-5 提示词的 Cursor rules： CursorRIPER
• MCP 工具规则，用于介绍可用的 MCP 工具，以及使用工具时的规则
• 项目专属规则：开发过程中随时补充的其它规则，比如语言偏好、代码风格等等

RIPER-5 提示词是 robotlovehuman 在 Cursor 论坛中提出的一个提示词，它为 Agent 设定了五个模式：

1. Research mode（研究模式）：负责收集资料、阅读项目代码
2. Innovate mode（创新模式）：负责头脑风暴、探索关于项目的新想法、新功能
3. Plan mode（规划模式）：负责规划任务以及下一步行动
4. Execute mode（执行模式）：负责执行计划中的任务，编写实际代码
5. Review mode（评审模式）：负责审阅代码，检查代码是否实现计划中的任务

Cursor RIPER 结合了 RIPER-5 提示词和 Memory bank（记忆银行）。Memory bank 主要用于为模型提供必要的项目上下文，比如项目概述、项目所用技术栈、项目进度等等。¹

项目文档

重要的事说三遍：一定要有文档，一定要有文档，一定要有文档！哪怕是 AI 生成的文档也比没有文档强。从 AI 上下文窗口的角度来看，制作项目文档相当于压缩项目代码和之前项目进度，使得 Agent 可以在有限的上下文窗口中了解项目。

项目文档对于 Agent 特别重要，因为 Agent 是无状态的（stateless）。

我们在做项目时，我们会在大脑中构建一个关于整个项目的心智模型（mental model），包含代码结构、业务逻辑、代码风格，甚至团队成员间不成文的约定等等。但对于 Agent 来说，它没有这样一个心智模型。你需要在对话中为它提供必要的项目信息，帮它构建一个临时的心智模式。

简单来说，你可以把 Agent 想象成一位新来的实习生：每次开启新的对话，都相当于换了一个全新的实习生。如果你没有提供足够上下文信息，这个新实习生就不了解当前项目，两眼一抹黑，表现自然就会很差。

当然，你也不可能指望把所有资料全压在一个对话窗口中，从项目开发之初到项目结束只使用一个对话窗口；或者让 Agent 一次性读完项目中所有代码来理解项目。

首先，模型上下文窗口有限。目前上下文窗口最大的 Gemini 模型的窗口大小也只有一百万 token，Claude Sonnet 4也才二十万。更重要的是，就算上下文窗口足够大，模型在长上下文的表现也很有限。简单来说，它在一次任务中能够有效关注和处理的信息有限。参考资料：

• Fiction.LiveBench：一个测试模型在长上下文表现的 benchmark
• Lost in the Middle - How Language Models Use Long Contexts：模型在处理长文本时，更容易关注头尾的文本，而忽略中间的文本
• On the Emergence of Position Bias in Transformers：模型存在位置偏误

沿用上面的类比，把所有内容全压在一个对话窗口中就相当于让新来的实习生一次读完所有项目代码、文档，然后立马开始干活。这当然是不可能的。

我把项目文档分成几类：

1. 整体项目文档：包括项目愿景、项目需求文档（PRD）、MVP定义文档、系统架构设计图、开发指南。这些文档会被保存在项目根目录的 docs/ 下，后续基本不会修改。这些文档是项目的基石，用于项目 Memory bank 初始化，以及规划下一步功能
2. 模块文档：在每一个文件夹下创建一个 README.md，描述该文件夹内所有文件的主要内容、职责。这可以帮助 Agent 快速了解项目，找到对应的模块，而不需要直接阅读代码 —— 极大地节省了 Token 消耗 和 Agent 的“注意力”。

在实际编码时，我一般会引入“架构设计”和“开发指南”两个文档，让 Agent 以这两个文档为起点。如果它在执行具体任务时需要查看某个模块的文档，它会自己去查看。

举一个例子，比如说有一个前端项目，其文件结构如下：

frontend/src
├── App.css
├── App.tsx
├── components
│   ├── a.tsx
|   ├── b.tsx
│   └── tabs
│   │   ├── c.tsx
│   │   ├── d.tsx
├── hooks
│   ├── e.ts
│   ├── f.ts
│   ├── g.ts
│   ├── h.ts
├── main.tsx

我会在 frontend/src 目录下创建一个 docs 文件夹，存放以下项目文档：

• 架构设计：包含项目概述、技术架构层次、核心组件（Mermaid 图）以及项目结构（项目文件夹结构 + 指向模块文档的链接）
• 设计风格：包含页面 UI 设计风格
• 开发指南：包含设计原则、代码风格
• 技术选型：包含所用的技术栈

然后分别在每个子目录（components、hooks）下，创建 README.md，概述该文件夹下所有文件的内容，主要包含模块概览、每个文件的文件名和职责描述。

在实际开发时，我会让 Agent 从顶层的架构设计、开发指南出发，先阅读顶层文档，再逐步阅读下层文档，规划、拆解任务。

如果你像我一样想偷懒，也可以让 Agent 生成文档。创建文档提示词如下：

我想让你逐步阅读frontend/src/hooks下的所有文件，理解该模块的主要内容、职责、代码结构，然后在这个文件夹下创建一个README.md，概述该文件夹的结构、设计原则、详细描述每个文件的主要内容、职责、功能，但不要包含具体代码。要求通俗易懂，让新来的实习生也能够快速了解项目，融入团队。

如果文件夹下有嵌套文件夹，你可以先阅读其中的README.md。如果其中没有README.md，那就先阅读该文件夹中下所有文件，先创建该文件夹的README.md。如果一直碰到文件夹，你需要重复这个过程。

一定要保证文档能够反映项目的最新状态。我有时候会在任务结束的最后，让 Agent 更新相关文档；有时候也会一次性让它更新所有文档。更新文档提示词如下：

我想让你逐步阅读frontend/src下的所有文件，更新相关的文档，使得文档up to date，让新来的实习生能快速了解项目，融入团队。要求不要包含具体代码。

MCP 服务器

MCP（Model Context Protocol，模型上下文协议）是一个协议，允许 AI 安全地访问外部的数据和工具。简单来说，MCP 服务器为 Agent 提供了可以使用的外部工具，拓展模型的能力。

具体的配置方式可以参考 Cursor 的官方文档。我的 MCP 服务器配置如下图：

Context 7

模型可以使用 Context 7 MCP 提供的工具查询依赖包的最新文档，可以避免知识库过时或者模型幻觉问题。基本上每次模型要处理与依赖包相关的代码时，我都会提示模型 请先使用context 7工具查看最新文档，再开始执行任务 。比如说，如果不使用 context 7 MCP，模型会使用 Tauri v1.x、Tailwind CSS v3，而不是用最新的 Tauri v2.0、Tailwind CSS v4. 即使你提示它用最新的库，它也不知道怎么用，会写出一堆有问题的代码。

MCP feedback enhanced

模型可以使用 MCP feedback enhanced提供的工具与用户交互。这个 MCP 看起来平平无奇，但实际上它为 vibe coding 提供了一个很重要的反馈功能。

接着刚刚的类比，把 Agent 看成一个实习生。在没有这个 MCP 之前，你提出需求，这个实习生会一口气一路干到最后，中间没有任何反馈或修正的机会。结果等你运行起来才发现，效果根本不是你想要的，或者出现各种问题。

而一旦有这个MCP，情况就大不同了。你可以让它每完成一个小任务就给你写一份工作报告，总结所做的修改，并寻求你的反馈。经过你的审阅、测试，确认没问题之后，再继续执行下一个任务。一旦发现问题，你也可以立即要求它进行修改，而不是在错误的道路上一错再错。

举一个常见的例子：在写前端项目时，你可以充当人肉测试员。Agent 每完成一个小模块或功能实现后，你可以负责测试页面的功能和UI是否符合预期。如果哪里有问题，可以及时反馈给 Agent，让它进行修复，然后你继续测试，重复这个过程一直到满意为止。如果你想更偷懒一些，你可以提示模型 如果你有什么疑问，完成小任务之后、或者需要我测试前端页面，请务必使用mcp-feedback-enhanced与我沟通、反馈。如果需要我测试，请提供一份测试方案，让 AI 给你提供测试方案。

这个MCP的出现，也让我彻底放弃了让 AI 使用 Playwright MCP 自行测试前端的想法——相比之下，人工测试效果更佳，也更放心。

在使用这个 MCP 的过程中，我总结了几点心得和注意事项：

1. 在需要创建代码保存点（checkpoint）时，务必打断这个 MCP 的调用。在 Cursor 中，每一次对话都会存一份代码保存点，方便回滚到当时的代码状态；但调用 MCP 时并不会存保存点。我碰到过这种情况：将一个大任务拆解成若干任务阶段，每一个任务阶段都有若干子任务。Agent 完成第一阶段任务之后，通过 MCP 向我确认。我确认没问题之后，它会在同一个对话中继续执行第二阶段任务。当第二阶段任务出错之后，我想回滚到第一阶段完成时的状态时，结果发现没有相应的保存点，只能返回到最开始的地方，白白浪费时间。因此，我的建议是：每完成一个阶段性任务，就主动打断 MCP 的调用，然后在新的对话中让 Agent 继续执行下一个阶段的任务，这样就能确保每一步都有可回溯的保存点。
2. 如果上下文太长，要及时切换到另一个对话窗口。这个 MCP 会让你觉得“这个对话窗口也没多少对话”，但实际上可能上下文窗口已经满了。

Desktop Commander

Desktop Commander MCP为模型提供了操作编程中常见的工具，包括读写文件、运行命令。这个 MCP 我没有深度使用，所以不做太多推荐。只说一个应用场景：Cursor 内置的文件读取功能有行数限制，如果文件比较大，模型只能读取一部分。使用 Desktop Commander 就能读取所有的文件内容。

如果你想用它替代 Cursor 内置的文件读写以及运行命令功能，有几个注意事项：

1. 配置好它的配置文件（/.claude-server-commander/config.json），特别是允许它使用的命令以及访问的目录。
2. 善用 git。使用 Desktop Commander 修改文件时，Cursor 页面不会有任何提示，你只能通过 git diff 来查看模型所做的修改。而且也没有任何保存点，你只能自己使用 git 来保存。建议完成每一个小任务 commit 一次，最后再通过 git rebase 来整理 commit 信息。如果你不太熟悉 git rebase ，给你推荐一篇很好的教学文。

编码过程

核心原则：拆解

随着项目的推进，我意识到要用好 Agent 完成项目任务，提高 Agent 的表现，拆解必不可少。原因我在前文已经提到过——模型上下文窗口限制以及处理长文能力有限。

在整个过程中我实践过几种不一样的拆解：

1. 项目拆解：厘清项目愿景、定义 MVP、拆解出若干项目文档，为模型提供必要项目上下文
2. 任务拆解：将功能需求拆解为具体可实施的任务
3. 代码重构：重构代码，使得代码模块化、低耦合，减少一个项目文本的代码行数

关于项目拆解于编码过程没啥关系，我会再写一篇文章来介绍它，如何从一个想法开始发展成一个项目、再到 MVP 文档、UI/UX 设计、系统架构等等，以及在这个过程中如何使用 AI 辅助。

任务拆解：Plan and Solve

在提示词工程中，有一个经典的提示词方式叫 Plan and Solve（先规划后解决） —— 针对特定任务/功能需求，先让模型理解功能需求、拆解任务，制作一份详细的任务清单，然后再让模型一步一步按照计划完成任务。我们可以直接套用这个方法论。

在实际使用中，我们可以使用两个不同的模型，一个负责规划任务（Planner），另一个负责实际编码（Solver）。我喜欢用 Gemini 2.5 pro 规划任务，然后使用 Claude Sonnet 4 来编码。你可以根据自己的喜好、实践经验来选择 Planner 和 Solver。

这里稍稍偏个题，聊聊我对目前主流模型的理解和感觉：

• Gemini 2.5 pro：虽然在 Cursor中 Gemini 2.5 pro 被砍了上下文，但它的长文理解能力、逻辑推理能力以及长文输出能力都很强。所以它很适合作为 Planner。但是它调用工具的能力比较差，有时会做出破坏性改动——它觉得之前的代码有问题，它就会去修改，即使你没有叫它去改这一块代码。整体来说，作为 Solver 它的表现没有 Claude Sonnet 4 那么稳定，但还算可用。
• Claude Sonnet 4：它遵从指令、调用工具还有编码能力都很强，是一个合格的 Solver。用的人很多，导致整体响应慢，有时甚至不可用。用它来做规划也可以，只是我比较偏好 Gemini 2.5 pro。
• O3 & GPT 4.1 我都没有深度使用，不做评价。

具体提示词如下（Credit: kkkyyx）：

<你的需求>

请你进入PLAN模式，阅读相关文档、前后端代码，然后开始分析、规划，拆解任务。

在执行任务时，请遵循以下工作流程：

1. **任务分解阶段**：
    - 将主要任务分解为具体的、可执行的子任务
    - 每个子任务应该是明确的、可衡量的单一操作
    - 确保子任务之间有逻辑顺序和依赖关系
2. **任务清单制作**：
    - 使用以下格式列出所有子任务：
        `[ ] 子任务描述（具体操作内容） [ ] 子任务描述（具体操作内容）`
    - 按执行顺序排列任务
3. **任务执行阶段**：
    - 逐一完成每个子任务
    - 完成后将对应任务标记为：`[√] 已完成的任务描述`
    - 如遇到问题，说明具体困难并寻求解决方案

请在开始任何任务前，先展示完整的任务分解清单，获得确认后再开始执行。

一定要多使用 mcp-feedback-enhanced 工具多向我反馈、报告工作以及下一步任务。如果有需要我测试的地方（运行命令、调试前端等），也可以直接告诉我。只要你给出一份测试流程，我乐意帮忙测试。

它给出一份任务清单之后，你需要仔细阅读，思考这个方案合不合理。如果不合理，就跟进补充修改需求，或者让它再生成几次。这一步就别偷懒了，虽说是自动驾驶，但也不要完全自动:)

每次需求最好新启动一个会话，清空会话框所有的 Context，引入必要的项目文档（比如代码风格、前端架构文档等等），再配合上面的提示词开始一次任务。最好不要引入具体的代码文件，特别是很长的代码文件，这会污染上下文窗口。

注意清空会话框所有的 Context

代码重构

随着项目推进，代码会变得越来越复杂。我们需要有意识地重构旧代码，清理混乱和技术债，减轻自己和 Agent 的心智负担。

代码重构有两个核心意义：

1. 组件间解耦、保持低耦合：高耦合的代码是所有开发者（包括 AI）的噩梦。修改高耦合度的组件代码就得通读所有相关联的模块，这会消耗 Agent 宝贵的上下文窗口和注意力。我们平时处理高耦合代码的过程其实也差不多：需要思考所有可能涉及到的组件，更改某段代码会造成哪些影响，然后才能小心翼翼地修改。修改过后还要再做一次完整测试，确保所有组件工作正常。
2. 控制文件中的代码行数：我的经验法则是，单个文件尽量不要超过 500-700 行。超过之后 Agent 就会开始偷懒，只读其中的一小部分。把长代码文件拆分成若干小代码文件，再配上文档，Agent 就更容易找到并关注相关代码，修改时也不容易误伤不相关的逻辑。

我常常在几次小修改或者一次大修改之后重构代码。重构代码也可以让 AI 阅读代码、做方案，然后再执行。具体提示词如下：

我希望你能阅读并分析frontend/src/hooks中的代码，寻找其中可能的重构点、性能、安全改进点，主要目的是让它们更模块化、减少耦合性、更可维护、更高性能、更安全。

给出一份代码分析与改进建议报告，详细描述潜在的问题、重构方案以及优先级，并写入该文件夹的TODOs.md中

其它注意事项

• 完成阶段性任务之后，及时更新文档
• 如果 Agent 表现不够好，保持耐心。可以试试再拆解、细化，或者换一个模型，或者再生成几次。如果还是不行，说明 Agent 不能胜任这个任务，只能自己上了:(

总结

回顾全文，我的所有心得其实都围绕着如何让 AI 更好地工作，核心在于理解并应对它的边界：

• 知识边界：模型的知识库老旧 -> 使用工具解决，比如 context 7、联网
• 记忆边界：模型没有记忆、上下文窗口有限、处理长上下文能力有限 -> 管理上下文，核心在于拆解以及文档管理
• 能力边界：模型操作计算机测试能力有限 -> 由人工测试并给模型提供反馈
• 可靠性边界：模型会产生幻觉 -> 依靠人工审查和测试来保证代码质量

最后一点感想

我慢慢觉得，在 AI 时代我们要重新审视和定义开发者的角色。

在过去，技术栈是一个壁垒——如果你不熟悉某个技术栈，你需要先学习然后才能开发相关项目。但现在，AI 极大地拓宽了我们行动域，让我们可以做到过去不敢想或者做不到的事情。

在这个项目开始之前，我只自学过一些 React，懂 Python 和 一些 Rust，完全没有接触过 Tauri 框架。如果让我从头开始自己写这个项目，那没几个月是写不出来的。更可能的出现的情况是，耐心和精力耗尽，项目半路夭折。

在这个过程中，我更像是一个产品经理、一个项目总监、一个QA。我的精力更多地花在定义问题、设计方案、测试、以及把握项目的整体方向，而不是实际的编码工作。

这不意味着传统的编码技能不重要。你可能不需要手敲每一行代码，但你需要理解AI给出的代码是否合理，是否符合最佳实践；你可能不需要记住某个依赖的所有接口，但你需要知道什么时候，应该让AI去查阅某个文档或使用某个工具。

说到底，你的想法、审美、眼界也决定了 Agent 可以做到什么程度。

---

1. RIPER 5 + Memory bank在项目前期很好用，但在项目后期我基本上没怎么用。直接使用任务拆解提示词 + 及时更新项目文档对我而言效率更高一些 ↩︎