我的 Vibe Codeing 工作流

我用 Cursor 做主力开发工具已经将近两年了。我的工作流程和大多数人用 AI 编码工具的方式不同。

多数开发者的做法是：输入提示词，可能用一下 Plan 模式,修错误，重复。更激进的人会拼接 Ralph loops、MCPs、Gas Towns（还记得吗?）等工具。这两种做法的结果都是一团糟，遇到稍微复杂的任务就崩溃。

Ralph Loops：一种让 AI 自主迭代直到任务完成的循环机制。核心是 while true; do claude "..."; done，让 Claude Code 在一个持续循环中工作，每次迭代用新的上下文窗口，通过外部状态（git 历史、TODO 文件）追踪进度。名字来自《辛普森一家》里的 Ralph Wiggum（一个会不断重试的角色）。

Gas Town：Steve Yegge 在 2026 年 1 月推出的 AI 编码代理编排平台。它让你同时运行 20-30 个 AI 代理，用类似 Kubernetes 的架构管理它们（有"polecats"短期工作者、"dogs"持久工作者、"mayor"协调者等角色）。解决的是多个 AI 实例并行工作时的混乱问题。

MCPs (Model Context Protocol)：Anthropic 的标准协议，让 AI 连接外部工具和数据源。

我的工作流只有一个核心原则：在 review 并 confirm 计划之前，不让 Cursor 写代码。这种 plan 与 coding 的分离是我做的最重要的事。它避免了无效工作，让我掌控架构决策，相比直接跳到代码，它用更少的 token 产出明显更好的结果。

阶段一：研究

每个有用的任务都从深度阅读指令开始。我要求 Cursor 在做任何事之前，先彻底理解代码库的相关部分。并且我总是要求把研究结果写入一个持久化的 markdown 文件，而不是在聊天中口头总结。

深度阅读这个文件夹，深入理解它的工作原理、功能和所有细节。完成后，把你的学习和发现写成详细报告，保存到 research.md

详细研究通知系统，理解它的复杂性，把关于通知如何工作的所有知识写成详细的 research.md 文档

遍历任务调度流程，深入理解它，寻找潜在的 bug。系统里肯定有 bug，因为它有时会运行本该被取消的任务。持续研究这个流程直到找到所有 bug，找到之前不要停。完成后，把发现写成详细报告，保存到 research.md

注意这些用词："深度"、"详细"、"复杂性"、"遍历所有"。这不是废话。没有这些词，Cursor 会粗略的阅读。它会读一个文件，看看函数签名层面做了什么，然后就跳过了。你需要明确表示表面阅读不可接受。

research.md 是关键。这是我的审查界面。我可以阅读它，验证 Cursor 确实理解了系统，在任何计划发生之前纠正误解。如果研究错了，计划就会错，实现就会错。垃圾进，垃圾出。

阶段二：计划

审查完 research.md 后，我会要求在单独的 plan.md 文件中写一份详细的实现计划。

我想构建一个新功能 <名称和描述>，扩展系统以实现 <业务目标>。写一份详细的 plan.md 文档，说明如何实现。包含代码片段

列表应该支持分页。写一份详细的 plan.md 说明如何实现。在提出修改前先阅读源文件，基于实际代码库制定计划

生成的计划总是包含：方法的详细解释、展示实际修改的代码片段、将被修改的文件路径、考虑因素和权衡。

我用自己的 .md 计划文件，而不是 Cursor 的内置 plan 模式。内置 plan 模式很糟糕。我的 markdown 文件给我完全控制权。我可以在编辑器中编辑它，添加内联注释，它作为项目中的真实产物持久存在。

一个我常用的技巧：对于边界清晰的功能，如果我在开源项目中见过好的实现，我会把那段代码作为参考和计划请求一起分享。如果我想添加可排序 ID，我会粘贴一个做得好的项目的 ID 生成代码，然后说"这是他们实现可排序 ID 的方式，写一份 plan.md 解释我们如何采用类似方法。"相比从零设计，Cursor 有具体的参考实现时效果明显更好。

标注循环

这是我工作流中最独特的部分，也是我增加最多价值的地方。

Claude 写 plan.md
    ↓
我在编辑器中审查
    ↓
我添加内联注释
    ↓
把 Claude 送回文档
    ↓
Claude 更新计划
    ↓
满意？→ 否 → 回到审查
    ↓
   是
    ↓
请求 todo 列表

Cursor 写完计划后，我在编辑器中打开它，直接在文档中添加内联注释。这些注释纠正假设、拒绝方法、添加约束，或提供 Cursor 没有的领域知识。

注释长度差异很大。有时一条注释只有两个字：在 Cursor 标记为可选的参数旁边写"必填"。有时是一段话，解释业务约束或粘贴代码片段展示我期望的数据结构。

一些真实的注释示例：

• "用 drizzle:generate 做迁移，不要用原始 SQL" — Cursor 不知道的领域知识

• "不对 — 这应该是 PATCH，不是 PUT" — 纠正错误假设

• "完全删除这一节，我们这里不需要缓存" — 拒绝提议的方法

• "队列消费者已经处理重试了，所以这个重试逻辑是冗余的。删掉它，让它直接失败" — 解释为什么要改

• "这是错的，visibility 字段需要在列表本身上，不是在单个项目上。当列表是公开的，所有项目都是公开的。相应地重构 schema 部分" — 重定向整个计划章节

然后我把 Cursor 送回文档：

我在文档中添加了几条注释，处理所有注释并相应更新文档。先不要实现

这个循环重复 1 到 6 次。明确的"先不要实现"保护是必需的。没有它，Cursor 会在认为计划足够好的时候就跳到代码。只有我说够好才是够好。

为什么这样做效果好

markdown 文件充当我和 Cursor 之间的共享可变状态。我可以按自己的节奏思考，精确标注哪里有问题，然后重新参与而不丢失上下文。我不需要在聊天消息中解释所有事情。我指向文档中问题的确切位置，直接在那里写下修正。

这和通过聊天消息引导实现根本不同。计划是一个结构化、完整的规范，我可以整体审查。聊天对话是我必须滚动浏览才能重建决策的东西。计划每次都赢。

三轮"我添加了注释，更新计划"可以把一个通用的实现计划转变为完美契合现有系统的计划。Cursor 擅长理解代码、提出解决方案、编写实现。但它不知道我的产品优先级、用户的痛点，或我愿意做的工程权衡。标注循环是我注入这些判断的方式。

Todo 列表

在实现开始前，我总是请求一个细粒度的任务分解：

在计划中添加详细的 todo 列表，包含完成计划所需的所有阶段和单个任务 - 先不要实现

这创建了一个检查清单，在实现过程中作为进度追踪器。Cursor 在进行时标记已完成的项目，所以我可以随时瞥一眼计划，准确看到进展到哪里了。在持续数小时的会话中尤其有价值。

阶段三：实现

计划准备好后，我发出实现指令。我把它提炼成一个跨会话复用的标准提示词：

全部实现。完成一个任务或阶段后，在计划文档中标记为已完成。不要停，直到所有任务和阶段都完成。不要添加不必要的注释或 jsdocs，不要使用 any 或 unknown 类型。持续运行 typecheck 确保你没有引入新问题。

这个提示词编码了所有重要的事：

• "全部实现"：做计划中的所有事，不要挑挑拣拣

• "在计划文档中标记为已完成"：计划是进度的唯一真相来源

• "不要停，直到所有任务和阶段都完成"：不要在中途暂停等确认

• "不要添加不必要的注释或 jsdocs"：保持代码干净

• "不要使用 any 或 unknown 类型"：维持严格类型

• "持续运行 typecheck"：尽早发现问题，不要等到最后

我在几乎每个实现会话中都用这个确切的措辞（有小的变化）。当我说"全部实现"时，每个决策都已经做出并验证过了。实现变成机械的，而不是创造性的。这是刻意的。我想让实现变得无聊。创造性工作发生在标注循环中。一旦计划正确，执行就应该是直接的。

没有计划阶段，通常发生的是 Cursor 早期做了一个合理但错误的假设，在此基础上构建 15 分钟，然后我必须回退一连串的修改。"先不要实现"保护完全消除了这个问题。

实现过程中的反馈

一旦 Claude 开始执行计划，我的角色从架构师转变为监督者。我的提示词变得明显更短。

Claude 实现
    ↓
我审查 / 测试
    ↓
正确？→ 否 → 简短纠正 → 回到实现
    ↓
   是
    ↓
还有任务？→ 是 → 回到实现
    ↓
   否
    ↓
完成

计划阶段的注释可能是一段话，实现阶段的纠正通常是一句话：

• "你没有实现 deduplicateByTitle 函数。"

• "你在主应用中构建了设置页面，它应该在管理应用中，移过去。"

Cursor 有计划的完整上下文和正在进行的会话，所以简短的纠正就够了。

前端工作是最迭代的部分。我在浏览器中测试，快速发出纠正：

• "更宽"

• "还是被裁剪了"

• "有 2px 的间隙"

对于视觉问题，我有时会附上截图。一张错位表格的截图比描述问题更快传达信息。

我也经常引用现有代码：

这个表格应该看起来和用户表格完全一样，相同的表头、相同的分页、相同的行密度。

这比从头描述设计精确得多。成熟代码库中的大多数功能都是现有模式的变体。新的设置页面应该看起来像现有的设置页面。指向参考传达了所有隐含的需求，不用逐一说明。Claude 通常会在做出纠正前阅读参考文件。

当某事走向错误方向时，我不会试图修补它。我回退并通过丢弃 git 修改重新确定范围：

我回退了所有东西。现在我只想让列表视图更简洁 — 其他都不要。

回退后缩小范围几乎总是比试图逐步修复错误方法产生更好的结果。

保持主导权

尽管我把执行委托给 Cursor，但我从不给它对构建内容的完全自主权。我在 plan.md 文档中做绝大多数的主动引导。

这很重要，因为 Cursor 有时会提出技术上正确但对项目来说错误的解决方案。可能方法过度设计了，或者它改变了系统其他部分依赖的公共 API 签名，或者它选择了更复杂的选项而简单的就够用。我有关于更广泛系统、产品方向和工程文化的上下文，而 Cursor 没有。

Cursor 提出变更
    ↓
我评估每一项
    ↓
接受原样 / 修改方法 / 跳过删除 / 覆盖技术选择
    ↓
精炼的实现范围

从提案中挑选：当 Cursor 识别出多个问题时，我逐个过一遍："第一个，直接用 Promise.all，不要搞得过于复杂；第三个，提取成单独的函数以提高可读性；忽略第四和第五个，它们不值得增加复杂度。"我基于对当前重要事项的了解做逐项决策。

削减范围：当计划包含锦上添花的功能时，我主动砍掉它们。"从计划中删除下载功能，我现在不想实现这个。"这防止了范围蔓延。

保护现有接口：当我知道某些东西不应该改变时，我设置硬约束："这三个函数的签名不应该改变，调用者应该适配，而不是库。"

覆盖技术选择：有时我有 Cursor 不会知道的特定偏好："用这个模型而不是那个"或"用这个库的内置方法而不是写自定义的。"快速、直接的覆盖。

Cursor 处理机械执行，而我做判断。计划预先捕获大决策，选择性指导处理实现过程中出现的小决策。

单个长会话

我在单个长会话中运行研究、计划和实现，而不是把它们分成单独的会话。一个会话可能从深度阅读一个文件夹开始，经历三轮计划标注，然后运行完整实现，全部在一个连续对话中。

我没有看到大家说的上下文窗口超过 50% 后的性能下降。实际上，当我说"全部实现"时，Cursor 已经在整个会话中建立了理解：在研究期间阅读文件，在标注循环中精炼心智模型，吸收我的领域知识纠正。

当上下文窗口填满时，Cursor 的自动压缩保持足够的上下文继续进行。而 plan.md 文档，这个持久化的产物，以完整保真度在压缩中存活。我可以在任何时间点指向它。

一句话总结工作流

深度阅读，写计划，标注计划直到正确，然后让 Cursor 不停地执行整个事情，沿途检查类型。

就这样。没有魔法提示词，没有复杂的系统指令，没有聪明的技巧。只是一个分离思考和打字的有纪律的流程。研究防止 Cursor 做出无知的修改。计划防止它做出错误的修改。标注循环注入我的判断。实现指令让它在所有决策做出后不间断运行。

试试我的工作流，你会好奇没有一个标注的计划文档坐在你和代码之间，你以前是怎么用编码代理交付任何东西的。