我的Cursor工作流

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

我认识的很多开发者使用AI代码助手的方式都一样：打开聊天窗口，描述想要的功能，接受输出，重复。这种方式确实有效——直到它失效。而当它失效时，每次都是同样的失败模式：模型漂移，上下文退化，最终你在调试一段你已经不完全拥有的代码。

过去几周，我一直在构建一个更有条理的工作流。我注意到，输出质量与我使用的哪个模型关系不大，而与在写下一行代码之前如何组织会话的关系更大。

这篇文章讲的就是那个结构。具体来说，是一个三层工作流，它让我的AI辅助开发会话更加可预测、更可审计、运行成本更低。

0、单一模型工作流的问题

当你用一个强大的模型完成所有工作——规划、实现、审查——你是在让它身兼数职。模型是针对上下文窗口内的下一个token预测进行优化的。它们并不擅长"元认知"——判断当前的上下文窗口是否包含了正确的问题。

还有一个token经济性的问题。前沿模型很贵。把一个token密集的上下文通过Claude Opus 4.7来处理每一个样板函数，就像用精密仪器去钉钉子。成本是实实在在的，而且开发速度也低于应有的水平。

更深层次的问题是可靠性。当你在同一个会话中规划和构建时，早期的框架性错误会不断累积。在规划阶段做出微妙的假设的模型，在五个迭代之后仍然在基于那个假设构建。等到你注意到漂移时，你已经深入一个放弃起来代价高昂的上下文中了。

按模型——以及按目的——分离工作流可以同时解决这三个问题。

我将以Cursor作为讨论的工具，但同样的原则适用于任何AI代码助手。

1、第一层：使用Claude Sonnet 4.6进行规划

在每次编码会话开始之前，我会打开一个独立的规划对话，使用Claude Sonnet 4.6。这个会话的目的不是产出代码，而是产出一个足够好的规格说明——好到几乎任何有能力的模型都能在不提出澄清问题的情况下执行它。

Sonnet 4.6在这个阶段表现出色，因为它在做出任何决定之前会仔细推理。这个模型会克制住不急于写代码，直到问题真正清晰——这正是你对规划模型的期望。

我的规划prompt遵循一个一致的结构：

我想构建[结果，而非实现方式]。我当前的架构是[简要背景]。我最关心的约束是[例如：不引入新依赖 / 必须在现有认证系统内 / 移动端优先]。我正在做哪些假设可能会在以后导致问题？请将其拆分为自包含的任务，每个任务都有明确的完成标准。

返回的是一份任务列表，而不是代码。每个项目的范围都足够紧凑，可以毫无歧义地交给构建阶段的模型。我会将其保存为参考文档，然后进入构建阶段。

关键纪律：不要让规划会话漂移到实现阶段。当Sonnet开始写代码的那一刻，你就失去了分离。停下来，提取计划，把它带到下一层。

2、第二层：使用Composer 2进行实现

Cursor的Composer 2是一个专门为代码库中的智能编码任务构建的模型。它不是最强大的推理模型，但它速度快、了解代码库、每token成本显著低于前沿模型——这使它恰好适合执行阶段。

这有一个实际的原因：来自Sonnet规划会话的一个定义明确的任务，不需要深度推理来实现。它需要的是准确的文件导航、正确使用你现有的模式、以及可靠的多文件编辑。Composer 2这些都做得很好。在清晰的规格上运行它不是妥协——它是合适的工具。

我在使用Composer 2时的会话纪律：

• 每个会话只处理一个任务。 从你的规划输出中取一个项目，作为一个完整的会话来运行。完成后，提交。然后为下一个任务开始一个新的会话。长会话会退化。随着对话的增长，模型的有效上下文会缩小，两小时会话末尾的建议质量明显低于开始时。
• 通过@提供上下文，而不是通过解释。 与其描述哪些文件存在或应该遵循什么模式，不如使用@file和@codebase直接让模型看到。这消耗更少的token，而且比用文字描述你的架构更准确。
• 审查diff，而不是整个文件。 每次Composer 2运行后，审查diff而不是完整文件。关注什么变了、哪些文件被触及了、范围是否与任务匹配。如果一个两行的改动触及了六个文件，在提交之前要理解为什么。

这一层的token节省是真实存在的，并且会在项目中累积。Composer 2的运行成本是前沿模型的一小部分。在一个一百小时的项目中，这个差距不是微不足道的。

3、第三层：使用Codex 5.3作为独立评审

在功能构建完成并通过基本功能测试后，我切换到OpenAI的Codex 5.3进行代码审查。这是很多开发者跳过的层，但根据我的经验，它捕获的是最高价值的问题。

使用不同模型进行审查的原因不是不信任Composer 2。它和你不应该在刚写完一篇文章后立即校对它是一样的道理：作者的意图会渗透到阅读中。在我的情况下，Codex不知道规划决策，不关心实现选择，也不了解我试图做什么。它只看到代码实际做了什么。

我的审查prompt：

审查以下代码是否存在：逻辑错误、未处理的边界情况、我应该知道的安全问题，以及不必要的复杂性。只给我一个按优先级排序的问题列表。

Codex系列模型特别适合这个角色，因为它们是为精度而非创造力训练的。Claude模型往往更具生成性和上下文敏感——这些品质在规划阶段有帮助，但在审查阶段会引入合理化的风险。Codex更加字面化，在标记代码中实际错误方面更加一致，而不是标记可以改进的地方。

输出通常是一个简短的列表。很多项目是微不足道的。偶尔会有一项让你免于生产事故。

4、为什么这种分离有效

三层结构不仅仅是关于使用不同的模型。它是关于在工作不同阶段强制执行不同的认知模式。

规划需要退一步，思考问题的形态。实现需要专注于定义明确的任务。审查需要对输出持对抗性的怀疑态度。这三种模式是真正不同的，模型——和人一样——无法在单个会话中干净地在它们之间切换。

通过将工作分离为三个独立的交互，你不仅仅是在为每个工作使用正确的工具。你还在防止单个模型在所有三种模式之间保持上下文时发生的漂移。规划模型看不到实现。实现模型不会质疑计划。评审模型对两者都没有利益关系。

结果是输出更加可预测、更可审计、更符合你的原始意图——因为你的原始意图被捕获在一个独立于代码的计划中。

5、实际成本

每个功能运行三个模型听起来很贵。实际上，总成本低于通过单一前沿模型运行的单模型工作流。

使用Sonnet 4.6的规划会话相对较短且高价值——token花费很低，因为目标是一份规格文档，而不是代码库。使用Composer 2的构建会话是token使用的大头，较低的每token成本使这成为高效的层。Codex 5.3的审查是针对性和简短的——几百行代码，一个狭窄的prompt，一个简短的输出。

将此与用前沿模型会话同时进行规划、构建和调试相比。总token数量更高，每token成本更高，可靠性更低，因为上下文退化在长时间、多用途的会话中最为严重。

6、使用Cursor的Agent模式强化各层

三层结构适用于任何AI代码助手，但如果你使用Cursor，它的五个内置Agent模式——Ask、Plan、Agent、Debug和Multitask——值得作为自然的下一步来探索。完整的细分超出了本文的范围，但核心思想很简单：每种模式约束了AI可以做什么，而注意你处于哪种模式——只读还是智能体、规划还是执行——强化了这个工作流所建立的分离关注点。

7、这项工作流所需的元技能

我的三层工作流需要一种AI工具往往会侵蚀的东西：在构建之前写出计划的纪律。

很多开发者跳过规划，因为写规格说明感觉比开始会话慢。从前期来看确实更慢。但从更少的调试循环、更少的上下文重置、更少的"我需要重做这部分"的时刻中节省的时间，使得在任何有意义的规模的项目中整体更快。

另一种纪律是知道会话何时出了问题并及时停止。一个运行了二十分钟后产生奇怪结果的Composer 2会话，几乎肯定处于退化的上下文状态。停下来，提交你已有的内容，然后重新开始，这比调试AI的困惑更快。经验教会你去感受一个失去线索的会话的质感。

这些都不是新思维。分离关注点、使用正确的工具、独立审查——这些都是基本功。智能AI只是让遵循它们成为了默认选择，而非例外。

原文链接：How to Properly Use an AI Code Assistant

汇智网翻译整理，转载请标明出处