> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Cursor 使用教程：我的完整工作流 - URL: https://www.hubwiz.com/blog/my-cursor-workflow/ - Published: 2026-05-15T11:20:55.000Z - Updated: 2026-10-16T10:38:34.000Z - Description: 我的三层工作流，让开发更加可预测、更可审计、运行成本更低。 - Author: admin - Tags: AGENT, CURSOR, #Import 2026-10-14 14:41 我认识的很多开发者使用AI代码助手的方式都一样：打开聊天窗口，描述想要的功能，接受输出，重复。这种方式确实有效——直到它失效。而当它失效时，每次都是同样的失败模式：模型漂移，上下文退化，最终你在调试一段你已经不完全拥有的代码。 过去几周，我一直在构建一个更有条理的工作流。我注意到，输出质量与我使用的哪个模型关系不大，而与在写下一行代码之前如何组织会话的关系更大。 这篇文章讲的就是那个结构。具体来说，是一个三层工作流，它让我的AI辅助开发会话更加可预测、更可审计、运行成本更低。 ## 0、单一模型工作流的问题 当你用一个强大的模型完成所有工作——规划、实现、审查——你是在让它身兼数职。模型是针对上下文窗口内的下一个token预测进行优化的。它们并不擅长"元认知"——判断当前的上下文窗口是否包含了正确的问题。 还有一个token经济性的问题。前沿模型很贵。把一个token密集的上下文通过Claude Opus 4.7来处理每一个样板函数，就像用精密仪器去钉钉子。成本是实实在在的，而且开发速度也低于应有的水平。 更深层次的问题是可靠性。当你在同一个会话中规划和构建时，早期的框架性错误会不断累积。在规划阶段做出微妙的假设的模型，在五个迭代之后仍然在基于那个假设构建。等到你注意到漂移时，你已经深入一个放弃起来代价高昂的上下文中了。 按模型——以及按目的——分离工作流可以同时解决这三个问题。 我将以Cursor作为讨论的工具，但同样的原则适用于任何AI代码助手。 ![Cursor的模型选择器及每个模型的计算评分](https://www.hubwiz.com/blog/content/images/2026/05/1-mUX8mWuB2OqSC43vPjoOlQ.png) *图1：Cursor的模型选择器及每个模型的计算评分* ## 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可以做什么，而注意你处于哪种模式——只读还是智能体、规划还是执行——强化了这个工作流所建立的分离关注点。 ![Cursor的模式选择器](https://www.hubwiz.com/blog/content/images/2026/05/1-gMF8Oo5l2S1EGQpgO8eoJA.png) *图2：Cursor的模式选择器* ## 7、这项工作流所需的元技能 我的三层工作流需要一种AI工具往往会侵蚀的东西：在构建之前写出计划的纪律。 很多开发者跳过规划，因为写规格说明感觉比开始会话慢。从前期来看确实更慢。但从更少的调试循环、更少的上下文重置、更少的"我需要重做这部分"的时刻中节省的时间，使得在任何有意义的规模的项目中整体更快。 另一种纪律是知道会话何时出了问题并及时停止。一个运行了二十分钟后产生奇怪结果的Composer 2会话，几乎肯定处于退化的上下文状态。停下来，提交你已有的内容，然后重新开始，这比调试AI的困惑更快。经验教会你去感受一个失去线索的会话的质感。 这些都不是新思维。分离关注点、使用正确的工具、独立审查——这些都是基本功。智能AI只是让遵循它们成为了默认选择，而非例外。 --- 原文链接：[How to Properly Use an AI Code Assistant](https://pub.towardsai.net/how-to-properly-use-an-ai-code-assistant-b0c7b4139fdf?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)