1 | 特别说明：此文由 ChatGPT 生成，后续由我本人编辑、修改而成。 |
0 引言
2025 年，AI 编码助手对许多开发者而言已从“玩具”变成了实打实的生产力工具。然而，要真正用好这些工具，并非简单地抛给模型一个模糊需求就能自动产出完美代码——我们需要一套有章可循的工程化工作流。当前，不少开发者使用 AI 的方式仍很零散：遇到问题临时求助、要功能时即兴生成、想不起用法就问一下。这种碎片化的使用方式带来了不稳定的质量和难以复用的经验。要解决这些问题，需要将 AI 助手的使用从“点状、临时”升级为“系统化协作”。
为什么同样的工具，有些人觉得好用，有些人觉得不好用？ 知名程序员 Peter Steinberger（PSPDFKit 创始人、Clawdbot 创建者）在《The Pragmatic Engineer》播客访谈中观察到一个典型模式：很多人写一个 prompt，丢进 AI，点发送，发现编译不过，于是失望地下结论说“这技术不行”。但他反问：“你真以为人类第一次写代码就能零 bug 吗？” AI 模型本质上是人类集体知识的幽灵，工作方式和我们非常像——第一次出错很正常，所以你才需要反馈闭环。与 AI 协作不是发一个 prompt 就完事，而是开启一段对话。这本身就是一项需要学习的技能，本指南的目标，正是帮助你系统性地掌握这项技能。后续章节将多次引用 Peter 的访谈——作为深度使用 AI 工具的资深开发者，他分享了许多宝贵的实战经验和心态转变。
本指南的目标是帮助开发者构建一套可复制、可控、可验证的 AI 编程工作流，以 Cursor 编辑器为核心工具。我们将借鉴经典的软件工程理念和最新的 AI 编程实践，将 AI 视为一名强大的“结对程序员”而非全自动的代码生成机器。整篇指南围绕 Plan-Execute-Verify（计划-执行-验证） 这一核心循环展开，强调工作流思维而非零散的工具技巧。正如《程序员修炼之道》所倡导的，好的开发实践重在思维方式和过程控制——在 AI 时代这一点更加重要。本指南将向读者展示如何像训练新同事一样“训练” AI 助手，与其协作编程，并最终达到提升效率而不降低代码质量的目的。
接下来，我们将首先介绍 AI 编程协作的思维框架，然后依次深入工作流中的各个关键环节：如何规划任务、构建最小闭环迭代、制定控制策略、管理上下文、撰写高效提示词、进行测试验证，以及如何沉淀项目资产并持续训练提升。让我们开始这一段“AI 工作流修炼”的旅程，把 AI 从简单助手升级为真正的智能工作流引擎。
1 工作流思维框架：Plan-Execute-Verify
要在 AI 协作编程中取得成功，首先需要转变思维，从“让模型一次生成大量代码”转向 Plan-Execute-Verify（计划-执行-验证） 的迭代循环。这一框架对应了软件开发的基本过程：先规划设计，再编码实现，最后测试审查。
1.1 Plan（计划）
在编写任何代码之前，先弄清楚要做什么。很多人使用 LLM 写代码的误区是一上来就要求模型输出大段实现，而没有讲清需求。正确的做法是花足够的时间梳理规格——明确需求、约束、边界条件，并让模型针对这些细节提出澄清问题。这一阶段的成果可以是一份结构化的规划文档（如 spec.md 或 Cursor 的 Plan 模式生成的 Markdown 计划），其中写明需求描述、架构设计、数据模型、依赖项、测试策略等关键要素。研究表明，有经验的开发者更倾向于在生成代码之前先规划，这能帮助我们更清晰地思考要构建的内容，并为 AI Agent 提供明确的目标。一句话，先做“15 分钟的微型瀑布开发”——在真正写代码前，用很短的时间完成结构化的规划，让后续编码更顺畅。
1.2 Execute（执行）
明确计划后，进入编码执行阶段。将大任务拆解为小步骤，逐步实现。每次只让模型完成一个子任务，例如根据计划里的第一个步骤编写相应代码。Cursor 提供了强大的 Agent 智能体，可以根据你的指令编辑代码、创建文件、修改项目。在执行过程中，充分利用 Cursor 的功能，如自动补全（Tab 模型）和 Agent 模式来加速编码。但无论 AI 写多少代码，记住你才是总指挥——决策每一步是否采纳、如何调整。执行阶段的关键是在严格按照计划的前提下，让 AI 发挥生成代码的威力，同时随时监控其行为，不让它偏离预期。
1.3 Verify（验证）
无论 AI 的回答看起来多么自信、生成的代码看起来多么完善，你都必须对其进行验证和测试。将 LLM 当作一个特别聪明但容易犯错的初级工程师——你需要审查每一个关键步骤，决定是否接受修改。验证包括多方面：
- 自己阅读代码逻辑并理解关键分支
- 编写并运行测试，验证行为符合预期
- 对重要的改动执行认真的 Code Review（可结合人工和另一种模型审查）
如果发现问题，就进入下一轮的循环：调整计划或提示，重新执行，再验证，直到满意为止。这个持续反馈闭环确保了代码质量的可控和可验证。
1.4 小结：闭环而非直线
以上三个阶段并非线性执行完毕，而是不断交替循环。Plan-Execute-Verify 构成了 AI 协同编程的最小闭环，可以不断嵌套和迭代。通过这样的循环，我们避免了“一股脑让模型生成整个应用”而失控的情况。相反，我们以小步快跑的方式，在每个小周期内保持对方向和质量的掌控。这种方法既借鉴了传统敏捷开发的小步迭代思想，也融合了 AI 工具的特点，是一种 AI 增强的软件工程方法论：AI 帮助我们更快地产出代码和方案，而我们确保每一步都在正确的轨道上前进。
在接下来的章节中，我们将首先探讨与 AI 协作所需的心态转变，然后详细阐述如何在实际开发中落实 Plan-Execute-Verify 框架的各个环节。
2 AI 协作心态
Plan-Execute-Verify 是一个结构化框架，但要真正用好它，还需要正确的心态。很多开发者使用 AI 不顺利，不是因为工具不好或技术不行，而是思维方式不对。本章探讨与 AI 协作时需要具备的几个核心心态。
2.1 对话而非指挥
在实际操作中，有一种更自然、流动的方式来实现 Plan-Execute-Verify。Peter Steinberger 在访谈中分享了他的做法：
有一点很多人没意识到：你不是在“指挥”它，而是在跟它对话。我会说：“我们看看这个结构，有哪些选项？这个特性考虑过没有？”因为每一轮对话开始时，模型对你的产品一无所知，你得给它一些指引，让它去探索不同方向。你不需要什么 plan mode，我就是一直聊，直到我说“build”，它才真正开始构建。有一些触发词——它们确实挺“急”的——但只要我说“我们讨论一下”或者“给我一些选项”，它们就不会动手。
这段话揭示了一个重要的认知转变：与 AI 协作不是发号施令，而是结对探索。
很多开发者使用 AI 的方式是“指挥式”的——上来就说“帮我写一个用户登录功能”，然后 AI 立刻开始写代码，写出来不对再改，改来改去越改越乱。而 Peter 的方式是“对话式”的：先和 AI 讨论结构、探索选项、确认特性，在说“build”之前，一直保持在探索状态。
这种方式背后有几个关键洞察：
“零认知”问题：每一轮对话开始时，AI 对你的产品、上下文、偏好都是一无所知的。如果你上来就让它执行，它只能靠猜测。而“给它一些指路标志”，就是在帮它建立认知，让它的输出更贴合你的预期。
延迟执行：AI 模型确实很“饥渴”——它们倾向于立即行动、立即输出代码。但你可以用语言来控制这种倾向。当你说“我们讨论一下”或“给我一些选项”时，AI 会进入探索模式而非执行模式。这是一种软性的 Plan mode，不需要切换任何设置，只需要用对话引导。
触发词作为阀门：你可以把一些短语当作“阀门”来使用：
- “我们讨论一下” → 保持探索，不要动手
- “有哪些选项？” → 列出方案供选择
- “这个特性考虑过没有？” → 引导它思考边界情况
- “build” / “开始实现” → 正式进入执行阶段
这种方式与结构化的 Plan-Execute-Verify 框架并不矛盾，而是一种更“有机”的实现。本质上都是延迟执行、先思考后动手，只是形式不同——一个是显式的阶段切换，一个是通过自然对话来引导。选择哪种方式取决于个人风格：喜欢清晰流程就用正式的 Plan 模式，喜欢自然交流就用对话控制节奏。两者目的相同：确保 AI 理解清楚后再动手，而不是盲目写代码。
2.2 雕塑式构建：让形状从过程中浮现
除了“对话而非指挥”，Peter 还分享了另一个深刻的构建哲学：
我见过很多人一上来就搭建复杂的编排层：自动创建工单、Agent 处理工单、Agent 再给另一个 Agent 发邮件……最后弄出一堆精致的混乱。何必呢？他们花好几个小时设计 spec，然后让机器用一整天把东西“造”出来。我不看好这种做法——本质上还是瀑布式开发，我们早就知道那条路走不通。
我的构建方式是一路向前，很少回滚，更像是雕塑：从一块石头开始，一点点凿，让雕像慢慢从大理石中浮现。这就是我理解的“构建”。
这个雕塑比喻揭示了两种截然不同的构建方式：
| 建筑式（瀑布） | 雕塑式（迭代） |
|---|---|
| 先有蓝图，再建造 | 边做边发现形状 |
| 一开始就知道最终样子 | 形状从过程中浮现 |
| 偏离蓝图 = 错误 | 偏离预期 = 新可能 |
| 追求执行的精确 | 追求探索的敏锐 |
为什么复杂编排层是陷阱？ 因为它本质上还是瀑布式思维——先设计完美的系统，再让机器执行。但我们早就知道瀑布式的问题：需求会变、理解会演进、最初的假设往往是错的。AI 时代更是如此——你不可能在动手之前就知道 AI 能做到什么、不能做到什么。
Peter 还强调了一个很多流程里缺失的东西：
我得去点、去摸、去感受。好软件需要“品味”，而这恰恰是很多流程里缺失的东西。
“品味”无法自动化。那些复杂的编排层追求的是效率和可复制性，但好软件不只是“能跑”——它需要你亲手触摸、反复感受、持续打磨。AI 可以帮你生成代码，但“这段代码好不好”的判断，需要你自己去“点、摸、感受”。
这种“雕塑式构建”的心态，本质上是把自己定位为创作者而非管理者：我不是在管理一个系统，我是在创造一个作品。米开朗基罗说过：“雕像本来就在石头里，我只是把多余的部分凿掉。” 与 AI 协作时，最好的作品往往也是这样“浮现”出来的——不是按图施工，而是在不断的对话和迭代中，让它逐渐成形。
2.3 心态是最大的门槛
以上讨论的“对话而非指挥”和“雕塑式构建”，本质上都是心态问题。很多开发者使用 AI 不顺利，不是工具不行或技术不熟，而是用错了思维方式——期望 AI“一步到位”，一个 prompt 就得到完美结果，不行就下结论“这技术不行”。
但正如 Peter 所说：“你真以为人类第一次写代码就能零 bug 吗？”AI 协作是一门需要学习的新技能，就像从吉他转到钢琴，需要时间适应。你越理解这些“小野兽”的思维方式，就越擅长与它协作。
关于心态转变和技能提升，我们会在第 10 章“持续训练与提升”中进一步深入讨论。现在，让我们带着正确的心态，进入实操环节。
在接下来的章节中，我们将详细阐述如何在实际开发中落实 Plan-Execute-Verify 框架，包括如何拆解任务形成最小闭环迭代、有哪些控制策略可保证 AI 输出受控、如何管理上下文避免信息混乱、怎样撰写高质量提示词引导 AI，以及如何进行测试验证和沉淀项目资产。每一部分都会给出具体可行的步骤、提示语模板和最佳实践，帮助你逐步建立起自己的 AI 编程工作流。
3 构建最小闭环
最小闭环指的是在开发中构建小型 Plan-Execute-Verify 循环，使每个循环都能产出可验证的结果（如通过测试的功能或修复）。与其让 AI 一次性生成庞大代码，不如将工作拆解成小块、迭代推进。LLM 在处理小而清晰的任务时效果最佳，而在“一次性写完整个应用”时往往会失控。因此，我们要学会像整理待办清单一样，将整体需求分解为一系列可以闭环的子任务，并逐一完成。
在讨论具体实践之前，先分享一个反直觉的策略。Peter 在访谈中提到：
我通常从一个想法开始，甚至会故意“欠提示”Agent，让它做点出乎意料的事，给我新灵感。可能 80% 的结果不怎么样，但总有一两个点让我意识到“这个角度我没想过”。然后我不断迭代、打磨。
现在的好处是：功能太容易生成了，不行就扔，或者换个提示词重来。
这段话包含了两个重要洞察：
“欠提示”策略：大多数人追求“精确的 prompt”——把需求描述得越清楚越好，让 AI 完美执行。但 Peter 的做法是故意留白，让 AI 有空间给他惊喜。为什么？因为你不知道自己不知道什么。如果你把所有细节都规定死了，AI 只会给你“你已经想到的东西”。而留白，可能会得到“你没想过的角度”。当然，80% 的结果可能不行——但这引出了第二个洞察。
试错成本极低：AI 时代最大的礼物是“功能太容易生成了，不行就扔”。以前写一个功能要几小时甚至几天，扔掉心疼。现在 AI 几分钟就能生成，不行就重来。这彻底改变了“试错”的经济学——你不需要第一次就对，只需快速迭代、不断逼近。
这正是“最小闭环”的哲学基础：不追求一次完美，而是追求快速验证、快速调整。每个闭环都是一次“凿石头”的动作——可能凿对了，可能凿歪了，但只要闭环够小，歪了也能快速修正。
3.1 具体实践
- 拆分任务：将你的需求或用户故事拆分成独立的小步骤，每个步骤都有明确的目标输出。比如，如果你在开发一个博客系统，不要一次性让 AI 写完所有功能，而是拆成“实现用户注册模块”、“实现文章发布模块”、“实现评论功能”等。再细一点，每个模块又可细分：例如“实现用户注册模块”可以进一步拆解为“设计用户数据模型”、“编写注册接口的单元测试”、“实现注册接口逻辑”、“对接第三方邮箱验证”等等。
- 计划每个子任务：对于每个小任务，先和 AI 一起制定一个简短计划。你可以直接告诉 Cursor Agent：“按照计划的第 1 步，实现 XX 功能”。如果这个任务稍复杂，可以进入 Plan 模式（Shift+Tab）让 Agent 生成一个实施计划，其中包含相关文件、修改点等。你可以审核这个计划，删除不必要的步骤或补充遗漏的信息，然后再让 Agent 执行实现。很多时候，对于很小的改动或你非常熟悉的任务，可以直接跳过详细计划，让 Agent 立即处理；但对于较复杂的任务，提前规划会让后续执行更顺利。
- 执行并完成子任务：让 Cursor Agent 根据计划或你的指令编写代码。务必一次只执行一个子任务，避免在一个对话里同时要求 AI 做太多事情。这样做有两个好处：其一，AI 在一个狭小明确的范围内工作时，输出的代码更可靠、更易于理解；其二，方便你在每个任务完成后进行验收和调整。当 Agent 完成代码后，查看 diff 或生成的文件，确认它基本满足了当下子任务的预期。
- 验证子任务结果：在接受 AI 的改动之前，先进行验证。这可以包括运行该子任务相关的测试（如果你提前编写了测试用例，最好现在运行看看是否通过），或者手动执行一下关键路径。确保这个小任务的输出没有明显问题。如果有测试未通过或者质量不满意，不要急于进入下一个任务，而应先修正当前任务的结果。你可以直接提示 AI 修复错误，例如：“测试 X 失败，错误信息如下，请根据错误修正代码”，或利用 Cursor 的调试功能定位问题然后再让 AI 修复。每个子任务结束时，都要达到“验收”标准：要么通过所有相关测试，要么经人工检查认为没有问题。
- 反馈和迭代：如果子任务结果不理想，与其在当前基础上反复让 AI 勉强修补，不如回到规划阶段重新审视。你可以撤销刚才 AI 的改动（Cursor 提供撤销/还原功能，或直接利用 Git 回滚），然后根据失败的情况调整计划或提示，把需求描述得更具体明确，再让 AI 重试。通常，相比在错误的实现上修修补补，重新规划并执行会得到更干净的结果。
- 小步提交：当一个子任务顺利完成后，将修改提交到版本控制（git）。保持小步提交、频繁提交，可以将每个闭环的成果都保存下来。这样一来，如果后来发现某次改动引入了问题，可以通过 git 历史快速定位并回滚。同时，一个清晰的提交历史本身也是极好的项目文档和上下文，下次让 AI 阅读提交信息或 diff，它可以理解你的项目演进过程。我们稍后在“控制策略”部分还会详细谈 git 的作用，这里先养成习惯：每完成一个闭环就提交，为下一个闭环做好干净的起点。
通过以上步骤，我们实现了以最小可验证单元为粒度的迭代开发。这种方法比让 LLM 一次生成一大块代码稳健得多——正如许多开发者的教训：“一次性让 LLM 生成整套应用，结果就像 10 个人各写一块、从未对齐过风格的代码”，而小步迭代 + 每步验收则能确保一致性、减少返工。在这个过程中，其实我们已经把传统的软件工程实践（如模块化、单元测试、持续集成等）融入到了 AI 协作中，每一轮 Plan-Execute-Verify 都是一个闭环，保证了输出的可靠性。
值得一提的是，Cursor 提供了一些强大的功能，可以帮助我们自动化这个闭环。比如，你可以利用 Agent Skills 和 Hooks 特性，使 Agent 不断循环迭代直到达到目标。官方博客提供了一个示例：通过编写 .cursor/hooks.json 和脚本，让 Agent 不断尝试修复直到所有测试通过。脚本会检测当前会话状态，如果测试未通过且迭代次数未超限，就让 Agent 继续下一轮：“继续工作，完成后在 .cursor/scratchpad.md 标记 DONE”。这种模式非常适合让 AI 自动反复执行，直到满足某个可验证条件（例如测试全绿、UI 与设计稿一致等）。不过在实践中，建议一开始先手动执行几个闭环循环，熟悉模式后再尝试引入这种自动化“研磨”技能。无论是否使用自动循环，核心理念都是一致的：让每次 AI 产出都形成一个闭环，要么达标，要么失败就反馈调整，决不在未验证的半成品上堆积更多产出。
通过构建最小闭环，我们实现了“短反馈回路”——AI 生成代码 → 立即验证 → 及时纠偏。正是这样高速的反馈，让 AI 生成的代码质量逐步接近人类水准，同时开发者始终对结果保持可控可知。在下一个章节中，我们将讨论如何进一步控制 AI 编程过程中的方方面面，确保整个工作流在我们的掌控之下。
4 控制策略
即使有了良好的规划和小步迭代，AI 编程仍然需要一系列控制策略来保证输出质量和过程可控。可以把这些策略看作是给 AI 这位“智能实习生”制定的纪律和护栏，确保它按照我们的预期工作，而不会“自由发挥”地引入风险。下面从多个角度介绍在 Cursor 工作流中可以采用的控制手段。
4.1 人不离场：Human-in-the-loop
首先也是最重要的一点：确保人始终参与决策，不要对 AI 生成的代码掉以轻心。尽管 AI 助手能显著提高效率，但责任终究在我们自己。把 AI 当作一个特别聪明但容易出错的初级工程师，这意味着：
- 不要盲目信任任何一段 AI 给出的代码，即使它语气自信、表面正确。至少要做到：自己过一遍 AI 生成的代码逻辑，理解每个关键分支；跑跑单元测试或集成测试，验证行为是否符合预期；对重要改动进行认真的 Code Review，必要时请团队同事或另一个模型帮忙审查。总之，在你亲自检查之前，不要让 AI 的代码直接进入生产。
- 人工随时有权叫停。Cursor 在 Agent 执行过程中提供了实时 diff 预览功能，如果你发现 Agent 的修改方向明显不对，可以立刻按下 Esc 键中断它。比如你让它修一个小 bug，它却开始修改大量无关文件，这时果断停止比任由其完成再回滚要高效得多。中断后，分析它偏离的原因，调整提示（或者干脆重新从 Plan 开始），再尝试执行。
- 明确分工：让 AI 多干机械重复的事，但关键决策点一定要人工拍板。AI 可以帮你写代码、跑测试、生成报告，但例如采用哪种架构方案、某个性能权衡的取舍、是否发布上线等决策，应当由有经验的你来决定。你可以让 Agent 提供选项和分析，但最后的决定请由人来做。
4.2 版本控制与隔离
良好的版本控制习惯是 AI 编程的重要安全网。当 AI 能短时间内生成大量代码时，只有细致的版本管理才能帮助我们快速止损和追溯。实践准则：
- 频繁小提交：正如前文所述，每完成一个小任务就做一次干净的 commit。Commit 信息写清楚做了什么改变。这样不仅便于日后查找问题，也方便你把
git diff提供给 AI 让它基于变化做分析和改进建议。例如，如果某次提交引入了 bug，你可以复制该 commit 的 diff 内容，提示 Cursor Agent：“根据以下 diff，找出潜在问题并尝试修复”——由于 commit 粒度小，这样的上下文 AI 是能看懂并给出针对性建议的。 - 使用分支/Worktree 隔离实验：对于较大的功能开发或者尝试性改动，不要在主线上直接大规模应用 AI 建议，可以新建一个分支甚至 Git worktree 来隔离这些改动。Cursor 实际上对 Git worktree 有原生支持，它会为每个并行运行的 Agent 自动创建独立的 worktree，使得多个 Agent 可以各自编辑、构建和测试，而互不干扰。你也可以手工创建分支，在分支上大胆让 AI 重构或生成新模块。如果发现走偏了，直接放弃该分支即可，不会影响主线代码。
- 利用 Git 历史回滚：当 AI 的修改导致项目进入不稳定状态时，不要陷在错误状态里硬改，可以借助 Git 快速回滚到之前的稳定版本，然后从那里重新开始。Cursor 编辑器内置了 “Revert Changes”/检查点等功能，可实现类似效果。不过正如一些用户指出的，Cursor 的临时检查点毕竟不如显式的 Git 历史可靠。因此，推荐还是以 Git commit 为主要的“存档点”，必要时通过
git reset或git revert来恢复过来，这比让 AI 在一团乱麻的错误状态中尝试修补要高效和稳妥得多。
4.3 规则与规范约束
AI 再智能，也无法凭空理解你项目特有的架构约定、编码规范、业务禁忌。这就需要我们主动提供规则和示例来“调教”AI，使其行为符合团队预期。正如你会给新入职的同事发一份团队开发规范文档，AI 也需要类似的“入职培训”。
Cursor 提供了 Rules（规则） 机制来实现这一点。你可以在项目的 .cursor/rules/ 目录下创建 Markdown 规则文件，为 Agent 提供持续生效的指令。规则可以涵盖：
- 项目中的常用命令：例如如何构建、如何运行测试、如何启动应用等。把常用脚本命令写进去，当 Agent 需要时就会参照使用。
- 代码风格和约定：例如使用何种模块系统，变量命名风格，有没有不允许使用的 API，组件放在哪个目录，等等。不要整篇风格指南都复制进去，抓重要的点，并引用项目里现有的示例文件而不是复制其内容。这样规则文件简洁且不会随着代码演进而过时。
- 工作流程相关：例如每次更改后要不要跑 typecheck、API 路由应该放在何处、哪些模式应该遵循既有模式等等。
撰写规则要注意聚焦重点，避免过度啰嗦。从简单开始，先建立 5 到 10 条核心规则即可。只有当发现 Agent 重复犯某类错误时，再把对应指导加到规则里。切忌一上来就给它一份巨长的说明试图涵盖所有情况，那样效果适得其反。规则文件本质上相当于每次对话的系统提示，内容太多反而淹没了关键信息。
共享规则：将 .cursor/rules/ 纳入版本控制，团队成员都可以受益。当某人发现 AI 在某方面反复出错时，可以更新相应规则。甚至在 GitHub 的 issue 或 PR 里，可以 @ 提示 @cursor 让 Agent 帮忙更新规则。这样团队经验会逐步固化下来，新人和 AI 都能遵循统一规范，减少因风格不一致带来的摩擦。当项目规则集逐步完善后，你会发现 AI 输出的代码与团队习惯高度一致，几乎看不出是机器生成的。
除了规则，示例代码也是极好的约束方式。LLM 非常擅长模式模仿，如果提供高质量的示例，它更容易生成风格一致、符合规范的代码。因此，在具体任务提示中，不妨多给 AI 展示“范例”：
- 提供参考实现：例如让它实现某个新功能时，先贴上一段项目里类似功能的代码，告诉它“请按照上述代码的风格实现…”。这样 AI 会在潜意识里模仿这个示例，输出的代码更符合你的期望。
- 明确禁止事项：如果你知道某些解法是不可取的，可以直接在提示里说明“不要采用 XXX 方式”或提供一个反例让它避免。例如“这里不能使用递归，会栈溢出”或“不要调用内部未公开的 API”。这样能让 AI 少走弯路。
4.4 动态调整和多模型协同
在使用 AI 编程时，还需要根据具体情况灵活调整策略，包括切换模型、引入额外检查等：
- 更换或组合模型：不同的 LLM 各有所长，有的善于解释和文档生成，有的在大代码库重构上更稳定。当一个模型频繁卡壳或输出质量一般时，尝试换用另一个模型试试。Cursor 支持同时选择多个模型运行同一个提示，并将结果并排比较。你甚至可以让模型之间互相审核：用模型 A 生成代码，再让模型 B 来审查提问题。这种“AI 审 AI”的方式常能发现单一模型容易遗漏的细节。Cursor 内置的 Agent Review 就体现了这个思想：Agent 完成后，可以点 Review → Find Issues，运行一次专门的审查流程，Agent 会逐行分析修改并标记潜在问题。利用不同模型的视角，可以提高错误发现率。
- 新对话还是继续：当一个对话进行太久，模型可能进入思维定式或引入大量无关上下文噪音。一般来说，如果你要开始一个不同的任务，或者感觉 Agent 有点糊涂总犯同样的错误，那就开启新对话。新的对话会清空旧的聊天记录，只保留规则等静态提示，从而让 AI 有个干净的思考空间。如果只是对同一个功能做小改动、调试刚生成的内容，且需要引用前文上下文，则可以继续当前对话。一个经验法则是：对话越长，越可能飘移。所以当你感觉 AI 回答开始偏题或者无视你的指令时，很可能是上下文干扰在作怪，不妨重启对话，从最新状态总结关键信息重新提供给它。
- 及时重置与澄清：AI 有时会“钻牛角尖”——无论你怎么提示都围着先前一个错误思路打转。这时，与其反复提示，不如彻底重置上下文。在 Cursor 中开启新 Chat，然后使用
@Past Chats功能，引用之前对话的重要部分（例如最终的需求描述或设计结论），跳过那些错误的尝试过程。Agent 可以有选择地读取过去聊天记录，只提取需要的上下文。这比把整段对话复制过来高效得多，也避免旧有错误思路的干扰。此外，如果 AI 对你的意图明显误解，与其越纠结越乱，不如停下来澄清需求：再次明确你想要什么，让 AI 完全重新考虑。这就是前文提到的“从计划重新开始”策略的另一种表述。 - AI 也需要 Debug：当 AI 反复输出错误代码时，不妨转换思路，让它自己也参与进来分析问题。比如“请解释一下为什么你生成的实现没有通过测试”或者“逐步调试上面的代码，找出逻辑错误”。让 AI 进入分析师模式而非生成模式，有时能更好地找出问题。如果效果不佳，可以考虑换个角度提问或者换模型。很多时候，另一个模型可能立即看出问题所在。这就像团队里让不同的人 Review 代码一样，有时新人看问题反而清晰。
- 手动介入引导：不要忘记，你可以随时亲自修改代码然后再交给 AI 继续。例如当 AI 在一个小地方卡壳反复错误，你完全可以手动修正那几行，然后告诉 AI：“我修改了 X 部分，剩下的你继续完善”。AI 对你给出的正确部分通常不会再改，而是专注于未完成的部分继续。人机协作不一定是纯粹的提示-回答模式，直接改代码也是种高效的沟通。
- 规模控制：AI 在面对超大文件或无结构任务时容易失控。一个实践经验是：限制单次处理的代码规模。比如当某个文件超过 400 行时，可以考虑让 AI 将其拆分成更小的模块。你可以提示：“这个文件太长了，请通过提炼功能将部分逻辑拆到新文件中”。这样一来，AI 处理每个文件的逻辑范围减小，理解和生成都会更准确。同样地，如果一个任务涉及太多步骤，不妨人为拆解成多个 Chat 分别处理。控制问题规模在很多情况下能避免 AI “思路混乱”或输出质量下降。
4.5 自定义工作流与成本控制
随着对 Cursor 的深入使用，你可能希望把自己的一套开发流程固化下来，让 AI 按你的流程来工作，而不仅仅是被动响应提示。Cursor Nightly 版本提供了 Custom Modes（自定义 Agent 模式）实验功能，允许我们为 AI 定制一套专属的工作规则和行为模式。通过编写详细的规则文档，你可以让 AI 具备系统性思维，按照预设的多阶段流程来与你交互。
举例来说，传统模式下你对 AI 说“帮我写一个用户登录功能”，AI 可能直接就开始写代码了。而启用自定义 Agent 后，AI 可能先回答：“我理解您需要开发用户登录功能。让我先进入需求分析阶段，深入分析这个功能的背景…”，然后按照你定义的阶段一步步来，例如先问需求细节，再设计数据结构，再编写代码，最后自检输出。这实际上是将我们在 Plan-Execute-Verify 框架下进一步细分、标准化，让 AI 严格按照工作流执行。
当然，自定义工作流也面临另一个现实问题：交互轮次成本。标准化流程通常意味着渐进式推进，每个阶段都需要人确认再进入下一阶段。多阶段交互可能消耗大量的提示请求次数。在 Cursor 中，如果每月只有一定配额的调用次数，一个完整复杂功能走完流程可能相当“烧 token”。针对这一点，一些高级用户探索了“一次请求内的多次交互”技巧（Feedback MCP 等）。简单来说，就是借助 Cursor Agent Skills，让 AI 在一次用户提示中自行执行多轮对话的效果。例如你发送一个特殊指令，AI 可以在后台循环调用自己，直到完成某个条件为止，然后把最终结果一次性返回给你。这样做可以极大减少人为来回确认的步骤，从而降低交互成本。不过这属于相当高阶的用法，需要编写脚本和熟悉 Cursor 扩展接口，这里不展开。对于大部分开发者来说，更实际的做法是合理规划每次对话要完成的内容，尽量减少无效来回。如果担心次数不够用，可以考虑升级更高的订阅方案或者使用本地模型辅助一些工作。在成本与效率之间，需要找到平衡。
总之，通过以上种种控制策略，我们可以极大程度地避免 AI 编程过程中的“走偏”和“失控”情况。就像经验丰富的导师带新人一样，我们既要给 AI 足够的自主发挥空间，让它展示智能的一面；又要设定明确的规则和随时指导，在必要时果断纠正。应用这些策略后，AI 将真正成为我们可控的工具，而不是一个不可预测的黑盒。下一节中，我们将讨论如何管理上下文信息，让 AI 始终“看得到”完成任务所需的所有关键资料。
5 上下文管理
上下文（Context）指 AI 在生成代码或回答问题时所能获取的所有相关信息，包括当前项目的代码、相关文档、之前的对话内容等。高效管理上下文——既让 AI 获取充分信息，又避免噪音干扰——是 AI 编程工作流的重要一环。
5.1 让 AI 找到所需的信息
Cursor 的 Agent 具有强大的代码搜索和浏览能力，因此你通常不需要在提示里手动贴上所有相关代码片段——它可以自行获取上下文。比如当你询问“身份验证流程（authentication flow）”时，Agent 会自动在代码库里用 grep 和语义搜索寻找相关文件，即使你的提示里没有出现精确的文件名。Cursor 内置的即时代码搜索工具可以在毫秒级完成代码库扫描。这意味着在大多数情况下，你可以直接用自然语言提问，AI 自会去查找涉及的模块。例如你问“登录功能的实现在哪里”，它会定位到 AuthService 或相关的代码文件然后回答。
然而，让 Agent 自由搜索并不意味着我们就可以撒手不管。要注意以下几点：
- 避免过载信息：如果你已经清楚知道相关的文件或函数名字，在提示中明确提及它们。例如：“请修改
user_controller.rb中的登录逻辑，确保密码错误 3 次后锁定账户。” 这样 Agent 会直接关注该文件的内容。而如果你不知道具体在哪里实现，也不要猜测贴一堆无关文件，直接告诉 Agent “请查找登录流程相关的代码”就好——它自然会去搜。不相关的文件可能让 Agent 混淆重点，所以上下文越精准越好。 - 利用 Cursor 特殊引用功能：Cursor 提供了
@引用语法来精确提供上下文。你可以在提示中用如@file(filename)、@folder(foldername)或@code(symbol)来引用特定文件、文件夹或代码符号。这样 Agent 在处理提示时会优先查看这些内容。例如，你可以对 Agent 说：“请查看@file(services/AuthService.ts)中的login方法，并修改为使用新的加密算法。” 这等价于把该文件内容作为上下文提供，Agent 会据此进行改写。精确引用可以大幅提升 AI 理解问题的准确度，尤其当项目较大时，这比它漫无目的搜索效率高得多。 - 代码库索引：对于非常庞大的项目，Cursor 提供了 Codebase Indexing（代码库索引）功能。开启后，Cursor 会在本地为整个项目创建嵌入索引（embedding），以提升跨文件回答的质量。这样 Agent 可以更“理解”代码库的结构和依赖关系。不过请注意，索引创建和更新需要一些时间，而且索引数据会上传存储在云端（但代码本身仍保存在本地，不会上传）。如果你的项目对隐私要求很高，可以考虑不开启此功能，转而通过手动引用或逐步搜索的方式提供上下文。
5.2 控制对话上下文
除了项目代码上下文，AI 对话本身的上下文管理也很关键。随着对话轮数增加，以前的聊天内容也会占据上下文窗口。Cursor Agent 的上下文窗口虽然较大，但不是无限的，过长的对话可能让早期内容被遗忘或被模型弱化处理。同时，长对话中往往混入了很多历史噪音，可能干扰模型的判断。因此我们需要策略性地管理对话过程中的上下文：
- 分阶段启动新对话：在任务切换或 AI 出现困惑时，可以考虑开启一个新对话。新对话会重新加载规则和关键静态提示，但不包含旧对话的聊天记录。你可以在新对话的开头，简要说明现在的上下文是什么。例如：“之前我们完成了用户注册功能的开发，现在开始新的任务：实现用户登录。以下是用户注册模块的接口定义：…” 通过这种方式，你人为控制了上下文的重置，确保 AI 不会因为前一话题的残留内容而跑题。
- Past Chats（引用过往对话）：Cursor 提供了非常方便的
@Past Chats功能，让你在新对话中引用之前的对话内容。与其一次性复制整个聊天记录，@Past Chats可以引用某次过去对话的标题或编号，然后 AI 会按需读取其中相关的部分。这相当于给 AI 提供了一个可查阅的知识库，它可以选择性提取需要的上下文，不会引入无关内容。这对长周期开发非常有用——你可以把某些重要决策、结论或者设计细节放在一个对话里，必要时在以后的对话中引用它，而不必每次从头解释。 - 维护上下文简洁：在同一个对话里，也要注意保持每次交互提供的信息足够简洁明了。尽量在一次提示中集中说明当前需要 AI 关注的重点，而不是扯入很多次要细节。如果本次任务只涉及后端，就没必要把前端代码片段贴进去；如果只修改配置文件，就无需加载整个项目结构。许多经验丰富的用户甚至会维护一个“知识库文件”，每遇到 AI 犯的新错误就记录下来，下次提示时把这个知识库也附上。例如建立一个
knowledgebase.md文件，里面写着项目的重要背景信息和已知陷阱，每次提问都@file(knowledgebase.md)引用一下。这样 AI 每次都有那些关键知识做支撑，就不容易再犯同样错误。当然，这有点类似手动的做法了——Cursor 的规则和技能体系从机制上提供了更优雅的上下文注入手段（规则等同于始终附加的知识库）。无论用什么方法，目标都是让 AI 手头的信息既不缺乏也不过载：该给的一定给，不该看的不要给。 - 外部资料引入：在某些情况下，任务所需的信息不全在代码里。例如要使用一个新库，而 AI 并不了解它的细节；或者涉及业务逻辑，需要参考需求文档。Cursor 支持将外部文档纳入上下文。在设置里，你可以添加一些 URL 或本地文档作为参考资料，让 AI 在回答时参考这些内容。另外，通过 Model Context Protocol（MCP），Cursor 可以与外部工具集成，例如 Slack、Confluence、数据库等，把那些来源的数据作为上下文提供给 AI。举个例子，你可以接入一个 Slack MCP，让 AI 能够读取某个 Slack 频道的聊天记录；或者接入一个 Figma MCP，让 AI 读取设计稿图片。这样，当你说“按照设计稿实现 UI”时，AI 就真的能看到设计稿细节了。这属于上下文扩展的高级玩法，对于需要综合多源信息的任务非常有帮助。引入外部资料的原则仍然是不滥用——只在需要的时候才添加，并确保提供的是可靠信息源。
总之，良好的上下文管理能让 AI 如虎添翼——在需要时迅速获取相关信息，而不被无关细节迷惑。开发者要对项目结构和知识来源了然于心，学会使用 Cursor 的各种上下文机制（代码搜索、@ 引用、Past Chats、规则/技能、MCP 等）。做到这一点，AI 就仿佛随时站在你肩膀上看着同样的资料，与你同步思考。下一章，我们将讨论如何编写高质量的提示词，最大化引导 AI 输出我们想要的结果。
6 提示词技巧
人与 AI 的交流是通过 提示词（prompt） 来完成的。提示词的质量直接决定了 AI 输出的质量。写提示词就像给同事下任务描述，讲究清晰、准确、上下文充分，还要考虑对方（AI）的“性格”和能力范围。下面，我们总结一系列编写高效提示词的技巧、模板和实例，帮助你更好地驱动 Cursor Agent 完成编程任务。
6.1 明确需求，避免含糊其辞
正如前文所述，许多开发者在使用 AI 时的误区是给出模糊的指令，比如“帮我写个登录功能”，然后希望 AI 猜出一切。提示词的第一要义是清晰明确。这包括：
- 说明要做什么：开门见山地描述需求或任务。例如：“实现一个新的用户登录 API，包括用户名密码校验、JWT 生成和错误处理。” 比 “帮我写登录功能” 要明确得多。
- 指出范围和目标：如果任务有明确边界，一定要说明。如“修改
OrderService中的createOrder方法，使其支持优惠券折扣”，限定了修改范围和目标功能。 - 提供背景：如果需求依赖某些背景假设，要在提示中说明。例如：“我们的应用使用 DDD 架构，订单聚合根在
Order类，实现新的折扣逻辑时需遵循聚合规则。” 这些信息能防止 AI 提供违背你架构原则的方案。
实践中，一个有效的方法是在提示开头先给出一段背景描述，然后再提出具体任务。比如：
我们的电商平台使用微服务架构，订单服务负责订单创建和支付。当前 OrderService#createOrder 方法没有考虑优惠券折扣。
任务：修改 OrderService#createOrder 方法，使其在计算总价时考虑优惠券折扣。如果请求中提供有效优惠码，则按优惠规则扣减相应金额。
要求：保证订单总价不低于 0，所有折扣逻辑放入 CouponService 处理，不要在 OrderService 中硬编码。
像这样结构化的提示包含了背景、任务和具体要求，AI 几乎不可能误解你的意图。
6.2 提供充分的上下文与约束
在提示词中，尽可能提供与任务相关的现有信息，这样 AI 就不必凭空假设：
- 指明相关文件或代码片段：如果你已经定位到需要修改的文件，最好把文件路径或片段告诉 AI。如：“参考
UserRepository.java中的findByEmail方法，实现一个新的findByUsername方法。” 这样 AI 就不会去别的地方找或者重复实现已有逻辑。 - 说明重要约束与不变量：明确告知哪些东西不能被破坏。比如：“修改这一函数时请确保不会破坏事务的一致性”或者“保持对现有 API 的向下兼容，不能改变返回值结构”。这些都是 AI 可能忽略但对你很重要的点，一定要在提示里提及。
- 给出项目里的示例：如果项目中已有类似实现，让 AI 照葫芦画瓢。比如“项目已有的
ProductService#addProduct方法就是个很好的参考，请按相似风格实现addCategory方法”。还可以贴出简短的示例代码片段。AI 擅长模仿模式，这样它输出的代码在风格和结构上更符合预期。 - 提供外部资料片段：对于 AI 不了解的新概念，直接提供资料摘要。比如在提示里粘贴某个库的 README 关键段落，然后让 AI 基于此使用该库 API。又或者，对于复杂的正则、晦涩的业务规则，你可以把相关说明文字贴进提示。原则是：凡是 AI 需要知道才能正确完成任务的信息，都应想办法提供。不要指望它去“想象”或推理出某些背景知识——与其相信 AI 的常识，不如明确给出依据。
- 设定反例和禁区：如果某些解法是不可取的，可以直截了当地告诉 AI “不要那样做”。例如：“性能至上，请勿使用
O(n^2)的解法”或者“出于安全考虑，决不能将密钥硬编码在代码中”。有时指出你不希望的方案，比描述你希望的方案同样重要。
6.3 要求 AI 自行澄清和检查
一个好的提示不只是单向命令，还可以引导 AI 进行交互式思考。Cursor Agent 具有多轮交互能力，我们可以在提示词中鼓励它提出问题或自行检查。例如：
- 让 AI 提问：在较复杂任务的提示末尾，可以加一句：“在开始实现之前，如有任何不明确的地方，请向我提问。” 这等于给了 AI 一个机会来澄清需求，而不是贸然生成。经验上，如果 AI 真的提出了澄清问题，说明你的需求可能还不够清晰，那就回答它的问题，直到 AI 满意为止再让它动手写代码。
- 分阶段执行：如果任务很复杂，不妨在提示中明确要求 AI 分步骤完成，不要一股脑给出最终代码。例如：“步骤 1：先给出实现方案和接口设计，不要写代码。步骤 2：经我确认后再编写代码。” 通过这种元指令，你可以把任务拆成两个回合：先让 AI 输出一个计划或设计，然后你审核后再让它继续。这相当于人工插入了 Plan-Execute 的中间检查点，可以显著提高复杂任务的正确率。
- 提示 AI 检查输出：在提示结尾加一句：“生成代码后，请检查是否有明显的错误或遗漏。” Cursor Agent 在完成主要任务后，会根据系统提示（包括规则）自动执行一些检查。你也可以直接要求，例如：“给出代码后，解释一下你的实现是否考虑了所有边缘情况。” 这样 AI 往往会在回答中先给代码，再附上一段自我检查的说明，指出可能的不足之处。这些自述可以帮助你了解 AI 的思路，还能及时发现它有没有忽略某些要求。
6.4 提示模板和实例
结合以上原则，这里提供几个实用的提示词模板，开发者可直接套用或修改：
6.4.1 功能实现类任务（使用 Plan-Execute 分步）
【背景】我们正在开发一款 Todo 应用，使用 Spring Boot + JPA。当前有用户管理模块。
【任务】实现“重置密码”功能：
- 提供一个 API 接口
POST /api/users/reset-password，接收邮箱地址。 - 验证该邮箱对应的用户存在，生成重置 Token（随机字符串，有效期 24 小时），保存到数据库（可新建
ResetPasswordToken实体）。 - 将重置 Token 通过邮件发送给用户（调用已有的
EmailService）。 - 如果用户不存在，返回 HTTP 404。
【要求】
- 所有数据库操作必须在事务中完成。
- Token 应该是唯一且安全的（使用 UUID 或加密随机数）。
- 切勿泄露用户不存在的信息（即邮箱不在系统中时，仍返回成功，以防止恶意探测）。
请先给出你计划如何实现，包括需要的新实体/方法/流程，然后再等待我确认。确认后再编写具体代码。
这个提示首先详细描述了背景和任务细节，然后要求 AI 先给出计划。你确认无误后，可以在同一对话继续说“好的，请按照你的计划生成代码”，AI 就会继续完成编码部分。通过这种方式，你既确保了需求的明确，又能介入设计过程。
6.4.2 Bug 调试与修复
我们有一个 Java 服务用于数据处理，但运行时报如下错误：
1 | Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 10 out of bounds for length 10 |
请找出 DataAnalyzer.java 中导致 IndexOutOfBoundsException 的原因，并修复代码。【提示】processData 方法似乎在用错误的边界条件迭代数据列表。
这个提示提供了错误堆栈和怀疑的原因，引导 AI 去阅读代码找问题。这相当于让 AI 充当调试助手。AI 可能会定位到 DataAnalyzer.java 并看出循环条件 i <= data.size() 多迭代了一次，造成索引越界，然后给出修复建议，比如改为 i < data.size()。
6.4.3 测试驱动开发（TDD）
我们要给 Account 类新增一个方法：transfer(BigDecimal amount, Account targetAccount) 实现账户间转账。
步骤 1：请先编写测试用例来规定该方法的行为。使用 JUnit 5 + AssertJ 风格：
- 转账后源账户余额减少、目标账户余额增加。
- 余额不足时转账应抛出
InsufficientBalanceException。
不要编写Account类实现，只需给出测试。
AI 会先输出测试代码，例如几个情景：正常转账、余额不足转账。你检查测试是否覆盖充分（需要的话手动调整并要求 AI 补充），然后：
步骤 2：很好，现在请运行这些测试（无需真实执行，假设失败），确认它们未通过。
步骤 3：现在请编写 Account.transfer 的实现代码，要求通过上述所有测试。请勿修改测试代码。如果第一次未通过测试，请根据失败信息持续修正，直到测试通过为止。
这一步 AI 会编写 transfer 方法实现。如果第一次不一定完善，你可以继续提示它输出假想的测试结果，然后让它根据错误信息调整，实现一个循环。这个过程其实就是让 AI 进入 “TDD 循环”：先让 AI 写测试 → 确认测试失败 → 写实现直到测试通过 → 最后人工验收提交。
6.4.4 代码审阅与改进
以上是 Cursor Agent 刚刚生成的代码实现。现在请以审查者身份逐行检查这段修改，指出其中可能存在的潜在问题、漏洞或可以改进之处，并给出修改建议。
这个提示可以在 Cursor 完成一次改动后提出，Agent 会进入 Review 模式，对代码做静态分析。它可能输出一个列表，比如：“第 12 行可能存在空指针风险，应先判断对象是否为空”、“第 27 行的算法复杂度较高，在大量数据时可能性能不足”。这利用了 AI 善于分析的能力，提供了一个“第二双眼睛”来帮助你审视代码。
6.4.5 复杂问题讨论
我们打算重构支付模块，目前有两种候选方案：
- 使用策略模式，根据支付类型分别实现。
- 使用规则引擎，根据配置决定支付流程。
请从代码维护性、扩展性、性能和开发工作量方面，帮我比较这两种方案的优劣，并给出你的建议。
这种开放性的提示让 AI 发挥长处——分析与文字总结。它会产出一篇分析文章，帮你梳理每种方案的优点缺点，然后给出推荐（也许会说更倾向哪种并解释理由）。这种用法相当于把 AI 当成顾问，一起头脑风暴和论证。
提示技巧小结：
- 写提示词时，可以使用 Markdown 的格式提升可读性（Cursor Agent 输出时通常保留你的格式）。比如用列表、粗体来强调关键步骤，这既是给 AI 看的，也是给你自己和团队看的（将来回顾聊天记录就像文档）。
- 语气和措辞也有影响。Cursor Agent 对明确的指令反应很好，所以不用客气，把需求和要求直截了当地说明。但是对于需要创意或分析的，让 AI 扮演某种角色（如“作为资深 Java 架构师，回答…”）可能会有效果。但切勿使用冒犯或过于情绪化的语气，对 AI 来说这样的信息无用还可能引起奇怪的输出。专业、礼貌且清晰，是提示词应有的风格。
- 尽量一次一个任务。如果在一个提示里罗列了许多不相关的要求，AI 可能漏掉部分要求甚至混乱。最好每次交互聚焦在单一目的上，完成后再进行下一个。
提示词的艺术需要通过实践不断打磨。建议你多保存一些有效的 prompt 模板，比如常用的“添加新接口”“修复 Bug”“写单元测试”“代码重构”“性能优化建议”等，把它们整理成一个属于你自己的 Prompt 手册。以后遇到类似场景可以快速引用，大大提高工作效率。
7 测试与验证
在 AI 编程工作流中，“验证”步骤至关重要，它是确保代码质量和功能正确性的最后防线。无论 AI 多么强大，我们仍必须通过测试和审查来验证其产出是否可靠。正如之前所强调的，Human-in-the-loop（人不离场）要求我们对每个关键结果进行把关。本节将讨论如何有效地将测试和验证融入 AI 协同开发，从而构建一个稳健的高频反馈闭环。
7.1 测试优先，驱动开发
在理想情况下，我们应尽量采用 测试驱动开发（TDD） 的方式与 AI 协作。这意味着在实现功能前，先定义好验收标准（测试用例），让测试来指导实现过程。实践中，可以像前文提示示例那样，先让 AI 根据需求生成测试用例，再让它去实现功能直到测试通过。测试的存在有多重好处：
- 为 AI 设定清晰的目标：模型的表现往往在有明确迭代目标时最好。测试用例就是明确的目标——通过/未通过是客观判断标准。有了这个“裁判”，AI 会不断修改自己的实现直到所有测试通过。这一过程减少了我们人工验证的负担，也防止 AI 偏离正轨，因为测试不通过就说明还有问题，逼着它继续改进。
- 防止过度实现或遗漏：写测试促使我们（和 AI）先认真思考功能规格，包括各种边缘情况，这避免了直接上手编码时可能遗漏的场景。AI 生成测试用例时，如果它遗漏了一些情况，你可以及时补充提示，这相当于在编码前就讨论清楚了需求细节。当测试覆盖全面后，AI 的实现也更有保障。
- 减少回归：当项目积累了测试集后，AI 每次改动都可以快速验证是否破坏了既有功能。Cursor Agent 可以被指示去运行测试（它背后实际调用终端来执行命令），并将结果反馈给你或自身。这就像给 AI 戴上了“紧箍咒”：一旦它的改动导致某个测试失败，立刻就能发现并进行修复。这在重构或大改动场景下尤其重要。
在 Cursor 中，你可以把常用的测试命令（如 npm run test 或 pytest）写入 Rules 的 Commands 部分，提醒 AI 在完成一系列修改后运行测试。甚至可以设置 Skills，让 AI 自动在每次生成后运行测试并判断结果。当然，不要忘记测试本身的质量：AI 生成的测试也需要你审查，有时 AI 写的测试用例不一定严谨，需要你调整。测试代码和产品代码一样，需要维护和演进。
7.2 让 AI 参与验证过程
除了编写和运行正式的测试，我们还可以让 AI 积极参与到验证环节，以多种方式检查代码质量：
- 静态分析和审查：Cursor Agent 具备代码分析能力。你可以显式提示 AI：“检查一下上面的代码是否有潜在空指针异常或者错误。” AI 会静态地阅读代码并指出可疑之处。这类似于让 AI 当 Lint 工具或 Code Review 助手。重要改动后也可以用另一模型审查，在 Cursor 里你可以直接切换模型提问。
- 对比多种方案：Cursor 支持并行运行多个模型，你可以让两个模型分别实现同一个功能，然后对比它们的输出差异。如果两份代码逻辑截然不同，可以让 AI 相互参考或者评估哪种更优。这有点像二次验证：当两个 AI 结果不一致时，引起你注意去深究；当结果一致时，说明实现基本是主流思路，可靠性也许更高。
- 运行和观察程序行为：在某些情况下，直接运行代码观察其行为也是验证的重要手段。你可以让 AI 执行某些命令。例如：“运行应用并访问
/api/test看看返回是什么”。如果环境允许，你也可以自己运行程序，复制控制台日志或错误信息给 AI，让它协助分析。举例来说，把程序运行时抛出的异常栈贴给 AI，问它“根据这个错误日志，程序可能哪里出了问题？应该如何修复？”。
7.3 人工验收与代码评审
无论测试多完善，我们仍强调人工的最终验收。这包括：
- 代码走读（Code Walkthrough）：亲自阅读 AI 生成的代码，确认逻辑正确、边界条件处理妥当。尤其是安全相关的代码，AI 可能不会完全理解安全隐患，必须由开发者来审视。例如检查是否有 SQL 注入风险、敏感信息日志泄露等。如果在团队中，可以把 AI 的产出提交 Pull Request，让其他同事审核，就像人工写的代码一样对待。
- 风格和规范检查：看 AI 写的代码是否符合团队的编码风格和规范。如果有 CI 集成了 lint 或格式检查，运行一下，看看有没有违规。一个 AI 友好的开发环境应有严格的 lint/格式检查，这其实也是为了保证 AI 产出符合规范。大模型有时会忘记格式，比如导入顺序、注释风格，你需要提醒或手动调整，然后把这些要求加入规则里防止下次再犯。
- 业务结果验证：代码通过测试并不意味着满足真实业务需求。要结合业务场景验证结果。例如在测试环境运行一下新功能，观察是否真正解决了问题、性能是否达标、UX 是否满足预期等等。AI 不会使用你的产品，这一步需要你换位从用户或业务角度验收。必要时可以请产品或 QA 一起验证。
持续集成和自动化检查也是测试验证的重要组成部分。确保你的项目有完善的 CI/CD 流水线，Pull Request 触发自动构建和测试。当 Cursor Agent 提交代码后，CI 如果报告了测试失败或覆盖率下降，你就能立刻知道。然后你可以把 CI 的失败信息反馈给 AI 修复：“CI 测试 X 失败，错误输出如下，请根据此修复代码。” 这种高频反馈闭环将 AI 牢牢控制在“有问题就改、改到通过为止”的循环中。整个过程你只需观察和最终拍板，大量机械调试修复的工作都可以由 AI 承担。
综上，“验证”绝不是可选项，而是 AI 工作流的必备环节。借助测试用例、AI 审查、CI 工具、人眼核验，我们构筑了多层保障，避免了 AI 的错漏流入最终产品。通过严谨的验证流程，我们既发挥了 AI 的速度优势，又确保了软件质量和可靠性。
7.4 关上反馈闭环：让 AI 自己验证自己
前面我们讨论的验证方式，主要是“人验证 AI 的输出”。但还有一种更高效的模式：让 AI 自己验证自己。这需要你把“反馈闭环”搭建好。
Peter Steinberger 在访谈中把这称为“最大的秘密”：
高效使用 coding agent 的关键，其实就一句话：你得把反馈闭环搭好。它必须能自己跑测试、自己 debug，这是最大的秘密。这也是为什么后来效率提升这么明显。用 Claude Code 的时候，我经常要回头修修补补，来回跑很多轮，算下来其实没快多少，只是更“互动”而已。现在用 Codex，绝大多数时候它一次就对了。
没有闭环时，AI 生成的东西第一次往往跑不通，忘了同步改其他地方，你要来回修补很多轮。有闭环时，AI 可以自己发现问题、自己修复，绝大多数时候一次就对。
那什么是“反馈闭环”？ Peter 给了几个具体例子：
1. 每个功能都配测试
我的基本策略一直是：做一个功能，就让它写测试，而且确保测试真的跑了。
这是最基础的闭环。AI 写完代码 → 跑测试 → 测试失败 → AI 修复 → 再跑测试… 直到通过。关键是“确保测试真的跑了”——不只是写测试，而是让 AI 在开发过程中持续运行测试。
2. 用 CLI 代替 GUI 调试
Mac App 调试特别烦——要 build、启动、点界面、看效果，再告诉它不行。现在我就直接说：给我建一个 CLI，专门用来 debug，走完全一样的代码路径，我可以直接调用。然后它就开始跑，一个小时后搞定了。
为什么要这样做？因为 GUI 的反馈循环太慢了。每次验证都要 build、启动、点击、观察… 而 CLI 可以秒级验证，AI 可以快速迭代。Peter 甚至在做网站时，也会把核心逻辑设计成可以通过 CLI 跑起来，因为“浏览器里的反馈循环实在太慢了”。
3. 自动化集成测试
我花了好久才反应过来：我在干嘛？这事就该自动化。于是我直接跟 Codex 说：设计一组集成测试——起一个 Docker 容器，装好整套系统，跑一个循环，用指定文件里的 API key，让模型读一张图片、生成一张图片，再回头看自己生成的图像理解成了什么。结果它真就自己搞定了。
这是更高级的闭环：整个系统级别的自动化验证。当你发现自己在反复手动测试同一个场景时，就应该想到“这事该自动化”。
为什么代码特别适合 AI？
Peter 点出了一个本质原因：
代码不一样，我可以编译、lint、执行、验证输出——只要你把系统设计好，就能形成一个非常完美的反馈闭环。但在创意写作上，它们的表现往往只是中等，因为创意很难验证。
代码的每一步都是可客观验证的：编译通过/不通过、lint 通过/不通过、测试通过/不通过、输出正确/不正确。这些二元判断让 AI 可以自己知道做对了没有。而创意写作的“好不好”是主观的，AI 无法自我判断。
信任的来源
你之所以可以不看，是因为你已经把验证闭环搭好了，你信任它，因为测试跑过了。这其实和在大公司做项目很像：所有测试都绿了，当然不代表百分之百没问题，但已经是一个很强的信号了。
很多人不敢信任 AI 写的代码，是因为没有验证手段。但如果你有完善的测试和 CI，你不需要逐行审查每一行代码。这和大公司的协作模式一样：你不会去看每个同事的每一行代码，你信任 CI 和测试。
如何搭建反馈闭环？
总结起来，要让 AI 能“自己验证自己”，你需要：
- 测试框架：确保项目有单元测试、集成测试，并且 AI 能运行它们
- 快速迭代环境：尽量用 CLI 而非 GUI，缩短每次验证的时间
- 自动化思维：当你发现自己在反复手动验证时，就让 AI 把这个验证过程也自动化
- CI/CD 集成：让测试在每次提交时自动运行，形成持续的质量守护
一旦搭好这些基础设施，AI 的效率会呈数量级提升。它不再是“生成代码然后等你验证”，而是“生成、测试、修复、再测试… 直到通过”的自主循环。你只需要在最后审查结果。
软件的本质没变，Test First 反而更容易了
关于反馈闭环，Peter Steinberger 还有一个更深层的洞察：
其实在 AI 之前也是一样。做复杂系统时，只要找一个真正做过的人，他第一件事一定是想：怎么让它可测试？接口怎么设计、类怎么拆、要不要 mock、要不要做端到端测试——这些都是非常困难、而且一旦决定就很难回头的架构选择。现在这些取舍依然存在，软件本质上没变。
“可测试性”一直是好架构的核心标志。这个原则在 AI 时代不仅没有过时，反而变得更加重要——因为你需要给 AI 一个能自我验证的环境。
但有一件事确实变了。Peter 坦诚地说：
写测试这件事真的太折磨人了，各种边界条件、分支逻辑。除了我非常尊敬的 Kent Beck——他来过播客，坚持 test-first——我几乎不认识真正喜欢写测试的开发者，包括我自己。我从来不喜欢写测试，就算假装喜欢，其实也没有。文档和测试对我来说，一直都不是一种“创作表达”。
这是大多数开发者的真实心态。Test First、TDD 在理论上很美好，但实际执行起来，写测试比写功能还累，感觉不是“创作”，而是“苦力活”。
但现在情况完全不一样了：
现在每当我设计一个功能，文档和测试都会自动成为流程的一部分。比如我们刚做完一个东西，我会立刻想：怎么测试它？换一种实现方式会不会更好测？于是“怎么关上闭环”已经成了我思考的一部分。模型必须能验证自己的工作，这会自然把我推向更好的架构。
我甚至觉得，现在不再亲手写代码了，反而写出了更好的代码。我以前就写得不错，但在公司里……现在情况完全不一样了。可以说，在我最近的项目里，文档质量是我做过最好的，而我一行都没亲手写。我不写测试，也不写文档，我只跟模型解释取舍：为什么要这么做。
这是一个很有意思的反转：
- 以前：写功能 → 勉强补测试 → 能跑就行
- 现在：想清楚怎么验证 → 让 AI 写测试和功能 → 确保闭环
AI 接管了那些“不是创作表达”的苦力活，而人专注于真正需要人来做的事：解释取舍、描述意图、想清楚“怎么验证”。
Kent Beck 的 Test First 理念，在 AI 时代反而更容易实践了。变的是实现者，不变的是原则。 这也许是 AI 带给软件工程最积极的影响之一：它让“理想的工程实践”从“应该做但做不到”变成了“自然而然会发生”。
8 项目资产沉淀
在传统开发中，我们注重代码复用和知识积累。AI 协作开发同样会产生许多有价值的项目资产：文档、规则、提示片段、测试用例等。善加利用这些资产，可以让 AI 未来表现更好，也让团队其他成员受益。本章讨论如何沉淀和复用 AI 协作过程中产生的知识与成果，打造不断自我增强的开发循环。
8.1 保存 AI 的“智慧”：计划和对话
Cursor 提供了一些功能，可以方便地保存 Agent 的输出内容。例如，当你使用 Plan 模式生成了实现计划后，可以点击 “Save to workspace” 将该计划文件保存到项目的 .cursor/plans/ 目录。这样一来，这份计划就成为项目文档的一部分，后续中断了也可以继续参考，还能提供给未来在同一功能上工作的 Agent 作为参考上下文。建议：把重要的 AI 规划文档都保存下来，例如 plans/2026-01-完成登录功能.md，并纳入版本管理。即使实现已经完成，这些计划文档也是宝贵的记录，反映了当时的思路和决策，供以后参考。
此外，对于 AI 生成的一些有价值的结论或分析，也可以整理出来，放入项目知识库（如 docs/ 目录或团队 Wiki）。例如，在前面的复杂问题讨论示例中，AI 给出了两种架构方案的详细比较和建议。这种内容完全可以稍加编辑后写入决策记录文档，方便团队后来者了解当初为何选择了某方案。通过把 AI 的输出正式文档化，我们避免了知识只存留在对话里然后被遗忘的情况。
至于 Past Chats 聊天记录引用功能，本质上是把对话内容当知识使用。所以当一段对话结束后，如果觉得其中结论重要，不妨给这段 Chat 取一个清晰的标题，并在需要时通过 Past Chats 取用。这相当于沉淀了隐性知识为显性可检索知识。
8.2 项目规则和配置积累
Cursor Rules 和 Skills 是项目资产沉淀的另一种形式。我们在“控制策略”部分已经详细讨论了规则的制定和演进。在这里强调其长期价值：
- 把团队的编码规范、架构约定、常用技巧不断加入到
.cursor/rules/中，你相当于打造了一个团队知识库，而 AI 会在每次对话开始时自动读取这些知识。随着规则集的丰富，AI 对项目的理解会越来越深刻，犯错越来越少。这有点像训练模型，但实际上只是喂了更多上下文——却实现了定制化的效果。 - 规则也可以有全局和项目特定之分。Cursor 支持在设置中添加全局规则，适用于所有项目，以及项目本地的规则文件。对于你个人/团队而言，可以慢慢建立一套“通用 AI 编程守则”，涵盖一些通用的最佳实践。这套全局规则就像每次 AI 协作时你都会告诉它的一些基本准则（比如“遇到不确定就提问”“不要在代码里泄露机密”等）。当这些守则变成资产后，新开启的项目也能快速引用，不必从零开始告诉 AI。
- Skills（技能）方面，如果你开发了某些 Agent 技能脚本，比如自动循环 Runner、特定领域的命令等，那么一定要把这些脚本纳入版本管理，并在团队内共享。这些技能脚本相当于可复用的自动化工作流。积累一套好用的 Skills 库，能极大提升团队整体效率，也让 AI 的作用不仅限于当前项目，还可以跨项目发挥。
8.3 测试和案例库
项目资产中非常重要的一部分是测试用例。AI 在协作过程中，很可能帮你生成了大量单元测试、集成测试。这本身就是项目的宝贵资产。一定要把这些测试纳入版本库，并持续维护。当新功能上线或旧功能修改时，相应增加或更新测试。长远来看，一个覆盖良好的测试集不仅保障代码质量，也是训练 AI 的最佳教材。未来当 AI 参与改动时，这些测试会告诉它何为正确行为。而且我们也提到，可以把失败的测试结果反馈给 AI 修复。当测试集完善后，你几乎可以把解决问题的负担很大一部分交给 AI——因为稍有差池测试就会报错，它就不得不改到通过为止。
8.4 工作流和提示模板库
随着你和团队使用 AI 的经验增长，你们会逐渐形成一套好用的 Prompt 模板和工作流脚本。这些都是值得沉淀的。例如：
- 把常用的提示语写成模板收集起来，分类存储（可以放在团队内部的 Wiki 或者一个专门的 Markdown 文件里）。比如 “Bug 修复提示模板”、“代码重构提示模板”、“API 文档生成提示模板” 等。团队新人在遇到类似任务时，可以从模板库里找到相应 prompt，稍作修改就能用。这避免了每个人都要从头尝试怎么问 AI 才好的过程。
- 如果你已经摸索出一套成功的 AI 协作工作流，不妨将其写成指南，在团队内部分享培训。将流程标准化，其他成员照着做可以少走弯路。例如，可以沉淀出一份“使用 Cursor 开发新功能的流程清单”：从编写 Plan、到实施、到测试、到审查，每一步都写清楚，并列出可能用到的工具/命令。这样，新成员来了按清单操作就能更快上手，老成员也有据可依不会遗漏关键步骤。
- 社区资源也可视为资产。比如官方博客、优秀的使用案例文章，你可以在团队内部做一些整理归纳。例如 “Cursor 高级用法 FAQ”“遇到 AI 乱改代码怎么办” 等 Q&A 文档。知识不仅来自自己，也来自社区，汇总后就是你们自己的财富。
8.5 经验反馈到 AI 模型
资产沉淀的终极形式，可以考虑将项目积累的数据反哺到 AI 模型本身。这超出了 Cursor 工具的范畴，但值得一提。例如，把项目的典型代码片段、术语、风格指南整理后，通过训练（Fine-tuning）定制一个专用模型，可能会让 AI 更贴合你的项目需求。不过目前大语言模型的微调成本较高，而且很多闭源模型无法微调。因此，更实际的做法是依托前面讲的规则、文档、例子，把知识“灌输”给 AI，而不是修改 AI 参数。
还有一种折中方式是通过向量数据库构建项目知识库，然后在提示时自动嵌入相关知识（即 Retrieval Augmented Generation, RAG）。Cursor 暂时没有开箱即用的向量库集成功能，但你可以借助 Hooks 或 MCP，接入自己的知识库。例如，当你问 AI 某模块的问题时，先从向量 DB 里检索相关文档片段插入到提示中。这个流程需要一些自定义开发，但是如果你的项目域知识复杂、文档繁多，这种方案可以显著提高 AI 回答准确率。
无论如何，让 AI 变得越来越聪明的关键不是等它升级模型（那是厂商的事），而是我们提供给它的项目知识越来越丰富规范。这些知识就体现在我们沉淀下来的资产中。每完成一个迭代，我们都应自问：这次 AI 遇到了哪些新问题？我们采取了哪些新的规则或提示技巧？能否把它总结为经验，纳入我们的库？如此不断积累，AI 对你的项目就像一个越干越久的老员工，知道的“潜规则”越来越多，表现也会越来越稳定可靠。
归根结底，资产沉淀不仅仅服务于 AI，也是团队自身能力的沉淀。在 AI 帮助下，你会更快产出更多成果，更需要及时整理，否则“今天解决的问题明天又忘了怎么解决”。养成及时总结的习惯，把分散在对话和代码中的知识提炼出来，长远来看，这些沉淀将大大提高团队协作和 AI 协作的效率，让工作流形成正向循环。
8.6 面向 Agent 设计代码库
前面讨论的资产沉淀——规则、文档、测试、模板——都是显式的、增量的。但还有一种更根本的资产：代码库本身。
Peter Steinberger 分享了一个很有启发的观点：
我设计代码库的时候，已经不只是考虑“对我好不好”，而是要考虑“对 agent 好不好”。我会为模型优化最省力的路径，因为最终是它们在跟代码打交道，我负责的是整体结构和架构。
现在 pull request 对我来说，更像是 prompt request。有人提 PR，我会看看需求，然后和我的 agent 从这个 PR 出发，按我理解的方式重新设计这个功能。
“对 Agent 好不好”成为设计考量
以前我们设计代码时考虑的是：对人类读者好不好理解？对团队协作好不好维护？现在多了一个维度：对 AI Agent 好不好操作？
什么是“对 Agent 好”的代码库？
- 清晰的模块边界：AI 更容易定位“这个功能在哪里”，不会在无关文件里迷路
- 一致的代码风格：AI 更容易模式匹配，生成风格一致的代码
- 好的命名：AI 通过名字理解意图，比通过注释更可靠
- 显式依赖：隐式的魔法、全局状态、副作用对 AI 是噩梦（前面提到的 Postgres 触发器 bug 就是例子）
- 可测试的结构：有测试的代码库让 AI 可以自我验证，形成反馈闭环
角色分工的变化
Peter 说“最终是它们在跟代码打交道，我负责的是整体结构和架构”。这描述了一种新的分工：
| 人 | AI |
|---|---|
| 整体结构和架构 | 跟代码打交道 |
| 决定“做什么”和“为什么” | 执行“怎么做” |
| 设计摩擦最小的路径 | 沿着路径走 |
你不需要亲自写每一行代码，但你需要设计让 AI 能高效工作的环境。这有点像城市规划师和建筑工人的关系——规划师设计道路和分区，工人在这个框架内建造。
PR = Prompt Request
“pull request 更像是 prompt request”这个重新定义很妙。PR 的本质从“请合并我的代码”变成了“这是我想要的功能，请按我的理解重新实现”。PR 成了需求的载体，而不是代码的载体。你看的是“这个 PR 想做什么”，然后让 AI 按你认为正确的方式重新实现。
代码库是 AI 的工作环境
这段话的核心启示是：你的代码库就是 AI 的工作环境。就像你会为新入职的同事准备好开发环境、文档、规范一样，你也需要为 AI 准备好一个“对它友好”的代码库。
代码库设计得越好，AI 的输出质量就越高，你需要介入纠正的次数就越少。这是一种基础设施思维：与其每次交互时费力引导 AI，不如一次性把代码库设计好，让 AI 每次都能自然地产出高质量代码。
所以，当你下次重构代码、设计新模块、或者制定编码规范时，不妨多问一句：这样设计，对 Agent 友好吗？
Prompt 才是更高信号量的东西
如果代码库是 AI 的工作环境，那什么才是真正的“产出”？Peter Steinberger 的回答可能会让你意外：
当我看到一个 PR 时，我更感兴趣的其实是 prompt，而不是代码本身。我会要求大家把用过的 prompt 一起提交。有些人会照做，而我会花更多时间读 prompt，而不是读代码。
对我来说，prompt 才是更高信号量的东西：你是怎么得到这个结果的？具体问了什么？中间做了多少引导？这些比最终代码本身更能让我理解输出。我甚至不需要细看代码。
这是一个颠覆性的观点：代码只是 prompt 的“输出”，真正重要的是产生代码的思考过程。
为什么 prompt 的信号量更高？
- 代码是“what”，prompt 是“why + how”：代码告诉你结果是什么，prompt 告诉你为什么这样设计、怎么引导 AI 得出这个结果
- 代码可以被 AI 重新生成，prompt 不能：如果你有好的 prompt，可以随时让 AI 重新生成代码；但如果只有代码，你很难还原当初的思考
- Prompt 暴露了思考质量：一个清晰、有结构的 prompt 说明作者想清楚了；一个模糊、混乱的 prompt 说明作者自己也不确定要什么
Peter 还进一步描述了他的工作流：
如果有人想要一个新功能，我会让他先写一个 prompt 需求，把它写清楚。因为我可以直接把这个 issue 丢给 agent，它就会帮我把功能做出来。真正的工作在于思考“它应该怎么工作”“细节是什么”。只要这些想清楚了，我几乎可以直接说一句“build”，它就能跑起来。
需求本身就是可执行的。传统流程是“需求 → 开发者理解 → 写代码”，中间有“理解”这个可能出错的环节。Peter 的流程是“Prompt 需求 → 直接丢给 Agent”，需求就是代码的源头。
这意味着：
- Code Review 的意义在改变：以前是审查“代码写得好不好”，现在可能是审查“你是怎么引导 AI 的”、“你的思考过程对不对”
- Prompt 会成为新的知识资产：值得保存、复用、改进的不只是代码，还有 prompt
- “写需求”的能力变得更重要：能把需求写得清晰、具体、可执行，就等于能直接“编程”
编码不是工作，思考才是。
9 持续训练与提升
AI 编程工作流的构建和优化并非一蹴而就，而是持续训练和改进的过程。这种训练不光是训练 AI，更是训练我们自己——如何更高效地与 AI 协作，不断提升开发技能。本章探讨如何制定持续学习和改进的计划，使个人和团队的 AI 协作能力稳步提升，真正将 AI 变成长期的生产力加速器。
9.1 强化基本功，AI 放大优势
在讨论“基本功”之前，我们先回答一个更根本的问题：为什么有些经验丰富的开发者对 AI 持强烈怀疑态度？
Peter Steinberger 在《The Pragmatic Engineer》播客访谈中分享了他的观察：
一周前我正好看到一篇博客，是 Nala Coco 写的，我非常尊敬他，也从他那里学到很多。但那篇文章基本在否定当前模型的工作方式。他测试了五六个模型，其中还包括一些根本不适合写代码的，比如 OpenAI 那个 120B 的开源模型。
在我看来，他就是写了一个 prompt，丢进 Claude Web，点发送，把输出直接跑了一下，发现编译不过，于是很失望。但这太正常了——你真以为人类第一次写代码就能零 bug 吗？这些模型本质上是人类集体知识的幽灵，工作方式和我们非常像。第一次出错很正常，所以你才需要反馈闭环。
而且你不是“发一个 prompt”就完事了，你是在开启一段对话：我想做什么。比如他抱怨模型用了旧 API，那是因为他没说 macOS 的版本，模型自然会假设用旧接口。它的训练数据不只是最近两年，旧数据远比新数据多。你越理解这些“小野兽”的思维方式，就越会 prompt。
他可能玩了一天左右，就下结论说这项技术还不够好。但要真正用好，你得投入更多时间。这就像你会弹吉他，我把你放到钢琴前，你随便试两下，说“这玩意不行，我还是回去弹吉他”。不对，这是完全不同的构建方式、完全不同的思维方式。
这段话揭示了批评者的典型模式：
1 | 写一个 prompt → 丢进 AI → 编译不过 → "这技术不行" |
问题在于：很多人期望 AI “一步到位”，但人类自己写代码都做不到这一点。
核心差异是心态：你是把 AI 当作“应该完美执行”的命令执行器，还是当作“需要学习如何协作”的对话伙伴？
Peter 的“吉他 vs 钢琴”类比非常精准。很多资深开发者的问题是：他们用“写代码”的思维方式去用 AI，发现不顺手，就说 AI 不行。但这就像吉他手试两下钢琴就说钢琴不行一样荒谬。AI 协作是一门全新的技能，需要专门学习。
Peter 还分享了他自己的学习历程：
你不知道我有多少次在凌晨三点对着 Claude Code 吼，因为它干了蠢事。慢慢地，我开始理解它为什么会严格按我说的去做，有时候甚至可以直接问它。去年在 Clawdbot 这个项目里，我感觉自己成了一个“人肉 merge 按钮”，社区太活跃了，我每天都在 review PR，几乎没时间写代码。一开始我会 cherry-pick 一点就关 PR，气得不行。后来我问它：你为什么这么做？它会说：当你这样说的时候，我是这样理解的。那一刻我意识到，我在学机器的语言。
我不断调整 prompt，现在几乎每次都能得到想要的结果，因为这本身就是一项技能。
这个转变过程值得细细品味：
- 一开始：凌晨三点对着 AI 吼，因为它干了蠢事
- 转折点：问它“你为什么这么做”，它解释了自己的理解
- 顿悟：“我在学机器的语言”
- 结果：不断调整 prompt，几乎每次都能得到想要的结果
“学机器的语言” ——这正是本指南想要帮助你掌握的。你越理解这些“小野兽”的思维方式，就越擅长与它协作。而这种理解的前提，是你自己具备扎实的工程基本功。
首先，要认识到：AI 放大的是你的已有能力。如果你具备扎实的工程基本功，AI 会让你的效率成倍提升；相反，如果基础薄弱，AI 可能放大的是混乱和幻觉。因此，在依赖 AI 的同时，不要忽视对基础技能的打磨：
- 持续学习算法、数据结构、设计模式等计算机科学知识。AI 可以快速写出代码实现，但由你来判断哪种算法或模式适用。如果对这些概念不熟悉，AI 给出错误方案你也难以察觉。
- 巩固软件工程实践：需求分析、架构设计、编程范式、测试设计、性能调优等。AI 可以加速执行这些实践，但前提是你知道要执行什么。比如，如果你平时就写规格文档、画架构图，那么用 AI 可以更快产出它们；但如果你从不做设计评审，上来就让 AI 写代码，结果可想而知。
- 保持良好的代码习惯：整洁的代码、清晰的抽象、合理的注释。这不仅让你的项目质量高，也给 AI 阅读代码提供了友好的环境。AI 善于模式匹配，如果整个项目风格统一、结构清晰，它输出的内容也更容易融入。而如果项目本身混乱不堪，AI 学了你的坏习惯，产出可能雪上加霜。
换句话说，把 AI 当作一面镜子，首先照出我们开发过程中的薄弱环节，然后加以改进。不要因为有了 AI 就放松对自己的要求——相反，应该以更高的标准要求自己。优秀开发者 + AI 的组合远胜于任何一方单独存在。所以在训练计划中，应包括对经典开发书籍和理念的学习（比如重温《Pragmatic Programmer》《Clean Code》等），然后思考如何将这些原则与 AI 协作结合。
知名程序员 Peter Steinberger（Clawdbot 创建者）在接受《The Pragmatic Engineer》播客访谈时分享了一个深刻的观察：
真正震撼我的是一个意识转变：现在我几乎什么都能做出来了。以前你得非常谨慎地选副项目，因为软件真的很难。现在当然还是难，但那种摩擦感不一样了。我会想：我在这类技术上很强，在那类技术上很弱——比如“那我们用 Go 写个 CLI 吧”，我对 Go 一无所知，但我有系统层面的理解。一旦你有这种理解，就会慢慢形成一种感觉，知道什么是对的、什么是别扭的，这本身就是一项技能。
这段话揭示了 AI 时代一个重要的能力转变：系统层面的理解比具体技术栈的熟练度更重要。当你理解软件架构的本质、知道好代码应该长什么样，即使面对陌生的语言或框架，也能借助 AI 快速产出高质量的代码。反过来，如果缺乏这种系统性认知，即使 AI 帮你写出了代码，你也很难判断它是否正确、是否优雅。
Peter 还提到了一个有趣的概念——与 AI 协作时的“摩擦感”：
我记得有人发过一条推，说写代码时你能感受到摩擦，这正是好架构诞生的方式。我在写 prompt 的时候也有同样的摩擦感。我能看到代码飞过去，能感知花了多长时间，能感觉 agent 有没有在“顶”你，能看出生成的东西是杂乱的还是有结构的。很多时候我一开始就能判断大概会花多久，如果明显更久，我就知道自己哪儿搞砸了。
这种“摩擦感”本质上是一种直觉——你能感知 AI 的状态：它是在顺畅地输出结构化代码，还是在磕磕绊绊地拼凑？当你发现 AI 生成得特别慢、输出特别杂乱时，往往意味着你的提示有问题，或者任务本身需要拆解。培养这种直觉，是成为 AI 协作高手的关键。
最终，Peter 将人与 AI 的关系描述为一种共生关系：
你会慢慢“感知”这个模型，知道它通常会怎么跑。这更像一种共生关系——我学会了如何跟它说话，甚至可以说是一门语言；与此同时，模型也在变得更好。
这正是本指南想要传达的核心理念：与 AI 协作是一门需要学习的“语言”，而掌握这门语言的前提是你自己具备扎实的工程基本功。
在同一次访谈中，主持人提出了一个尖锐的问题：AI 时代是否又回到了那种“大写 A 的架构师”模式——不写代码、只画蓝图、把方案往下传？Peter 的回应很有意思：
我不太用“架构师”这个词，我更喜欢“builder”。我发现用 AI 特别顺的人和特别痛苦的人，差异很明显。我更在意结果和产品体验，底层管道我关心结构，但不纠结最小细节。另一类人特别热爱写难算法，喜欢解决纯技术难题，不太喜欢做完整产品、营销这些，这类人往往最抗拒 AI，也最容易沮丧，因为 AI 恰恰擅长解决那些“难问题”。
这段话揭示了一个关键洞察：AI 时代最痛苦的，往往是那些以“解决难题”为身份认同的人。
为什么？因为 AI 恰恰擅长那些“难问题”——复杂算法、边界情况处理、技术细节优化。这些以前是稀缺技能，是程序员的护城河。一个能徒手写红黑树的人，在团队里是有光环的。但现在，AI 可以秒写这些东西。
这不意味着技术深度没用了。它的“交易价值”确实降低了——你不再能仅凭“会写难算法”换高薪。但它对于判断 AI 输出是否正确、理解系统为什么这样设计仍然至关重要。只不过，它从“可出售的稀缺技能”变成了“做好工作的基础素养”。这个转变很微妙，但影响深远。
Peter 说他更喜欢“Builder”而非“Architect”，这不是文字游戏，而是两种完全不同的心态：
| Architect（架构师） | Builder（建造者） |
|---|---|
| 关注蓝图和规范 | 关注结果和产品体验 |
| 追求技术完美 | 追求交付价值 |
| 纠结最小细节 | 关心结构但不钻牛角尖 |
| 身份认同：我是设计者 | 身份认同：我是创造者 |
Builder 的核心是：把东西做出来、交付价值。 AI 只是让这件事变得更快了。而那些以“能解决别人解决不了的问题”为傲的人，现在面临的不是技术问题，而是身份认同的挑战。
Peter 还说了一句特别重要的话：
这一年里，我学到的系统架构和设计知识，比过去五年加起来都多。这些模型里塞进了海量知识，几乎任何问题都能问到答案，前提是你得知道该问什么。
“知道该问什么”——这才是 AI 时代真正的核心能力。AI 模型里确实有海量知识，但它不会主动告诉你该学什么。你需要有足够的认知框架，才能提出正确的问题。这就是为什么 Peter 能“一年学到比五年都多”——不是因为他变聪明了，而是他知道该往哪个方向挖。
Peter 分享了一个具体的案例来说明这一点：
我当然也做过那个 Twitter 项目，到现在还没完工。整体功能其实能跑，但一旦用得稍微频繁一点，就会开始变得又卡又怪，然后过一阵子又恢复正常。我怎么都复现不了问题，调试起来特别痛苦，因为它不是那种稳定可重现的 bug，只是“用着用着就慢了”。
当时我在 Postgres 里写了一些逻辑，某些 insert 发生时会触发一些行为，结果数据库就会变得非常忙，而模型根本看不到这一层，因为抽象隔得太远了。模型很擅长顺着逻辑链条追溯，但这是一个非常隐蔽的副作用，只藏在一个文件里的某个函数里，跟其他地方几乎没有关联，名字也起得很糟，完全不显眼。我一直没问对问题，直到有一天我突然问：这个地方有没有任何副作用？结果一下就找到了，然后修掉了。说到底，一切都只差一个正确的问题。但前提是你得有足够的知识和经验，知道该往哪个方向问。
这个案例完美诠释了“问对问题”的含义。AI 的工作方式是：你指向哪里，它就分析哪里。它可以顺着调用链追溯、检查你提到的代码，但它不会主动想到“会不会是数据库层面有触发器？”或“这个性能问题可能和代码逻辑无关，而是基础设施的副作用？”——这需要你来问。
Peter 最终问的问题是“这个地方有没有任何副作用？”——这个问题之所以“对”，是因为它指向了正确的方向（不是问“代码哪里慢”，而是问“有没有隐藏的行为”），超越了直接的代码逻辑。而能问出这个问题，来自于他对系统的整体认知：知道数据库触发器可能造成性能问题，知道副作用往往藏在不起眼的地方。
这就是系统层面理解的具体体现。你不需要记住每个 API，但你需要知道系统有哪些层次、每一层可能出什么问题、性能瓶颈通常藏在哪里。这些认知框架，决定了你能向 AI 提出什么样的问题。
Peter 还提到了另一个重要的心态转变：
当你真正经营过一家公司、带过团队，你就知道不可能盯着每个人的代码，要求他们每一行都按你的方式来。很多没带过团队的人，很难学会放松一点，理解“这段代码也许不是我理想中的样子，但它能把我往目标方向推进”。不完美的地方，之后总能继续打磨。我非常相信迭代式改进。
这和 AI 协作是一个道理：你不可能（也不需要）控制 AI 写的每一行代码。“不完美但能推进目标”是完全可以接受的，不完美的地方之后总能继续打磨。迭代式改进——先让它跑起来，再慢慢优化——这比追求一次性完美要实际得多。
所以，回到“AI 时代是否需要强化基本功”这个问题，答案是明确的：不仅需要，而且比以前更需要。只不过，基本功的定义在悄然转变：
- 以前的基本功：能写复杂算法、能解决技术难题、能记住各种 API
- 现在的基本功：系统层面的理解、判断力、产品思维、知道该问什么问题
AI 改变的不只是工具，而是“什么是有价值的”这个定义本身。适应这个转变，技术上不难，心理上才是真正的挑战。
好奇心是最大的武器
如何建立系统层面的理解？Peter Steinberger 给出了一个简单但深刻的建议：
你现在拥有一台“无限耐心的机器”，它可以把一切给你解释清楚。你可以不停地问：为什么要这么设计？为什么是这个结构？通过这种方式建立系统层面的理解。但这需要真正的好奇心，而我觉得现在的大学教育并没有很好地教会你这一点。
这种理解通常是通过“吃苦”获得的，不会轻松。
这是 AI 时代学习的最大红利。以前，想理解一个复杂的开源项目，你要么自己硬啃代码（痛苦且低效），要么找个资深的人问（但他们没时间、也不愿意反复解释基础问题）。现在，你有了一个永远有耐心、永远不嫌你问题蠢的老师。
关键是：你愿不愿意不停地问“为什么”？
AI 工具人人都能用，但谁在用它不断追问“为什么”，谁就能建立起真正的系统理解。有些人用 AI 只是为了“快速得到答案”，复制粘贴就完事；另一些人用 AI 是为了理解——为什么这样设计？还有别的方案吗？各自的优缺点是什么？
前者只是在用工具，后者是在借助工具学习。长期来看，差距会非常大。
工具是平等的，好奇心是不平等的。
9.2 分阶段掌握 AI 工具
对于个人开发者，建议制定一个循序渐进的 AI 工具掌握计划，而不是一下子尝试最复杂的用法：
- 入门阶段：先将 Cursor 当作智能 IDE 使用，熟悉其基本功能。如自动补全、简单的 Chat 问答（比如“这段代码什么意思”）等。体会 AI 对提高日常编码效率的帮助。这阶段只需在小项目或日常脚本中用 AI 做辅助，不涉及关键产出。
- 进阶阶段：尝试使用 Cursor Agent 完成独立的小任务。例如写一个小型模块、一个算法函数等。练习编写清晰的提示，观察 AI 行为。此阶段着重练习 Plan-Execute-Verify 循环在小任务上的应用。例如给一个简单需求，让 AI Plan 一下再实现，然后写个小测试跑跑。通过这些练习，积累 prompt 技巧和对 AI 能力边界的认识。
- 应用阶段：将 AI 正式引入你的主要项目工作流。从简单任务开始，如用 AI 改几个 Bug、写几个单元测试，逐步扩大到实现新功能。在真实项目环境中应用之前学到的控制策略、上下文管理等。一开始可能让 AI 参与度在 20%-30%，你依然手工为主；随着信心增加，可以让 AI 承担更多，比如 50% 以上的代码产出。
- 高级阶段：当你对 Cursor 的功能和 AI 协作方式都驾轻就熟，可以探索更高级的用法，比如自定义 Agent、编写 Skills、整合 MCP 外部工具等。也可以尝试使用多个模型协同、甚至本地部署一些开源模型做辅助。这个阶段的目标是拓展 AI 能力边界，让它覆盖到更多流程环节，例如自动化部署脚本生成、运维日志分析、数据迁移脚本生成等等。
每个阶段都可以设定一些小目标和评估标准。例如，入门阶段目标是“掌握基本补全和聊天提问”；进阶阶段目标是“能用 AI 独立完成一个 500 行以内的小功能，测试通过”；应用阶段目标“团队引入 AI 协作流程，1 个月内提效 20%”；高级阶段目标“开发出 1 到 2 个自定义技能用于公司内部，提高特殊场景效率”。这些目标可以量化（比如开发速度、Bug 率的变化）来检验效果。
9.3 团队训练与协作
如果是在团队环境中推进 AI 工作流，可以考虑一些团队培训和协作机制：
- 内部工作坊/分享会：定期组织团队分享 AI 使用经验，交流成功的 Prompt 案例或踩过的坑。一方面促进大家同步水平，另一方面也收集改进建议。团队集思广益往往能碰撞出更好的 AI 使用方法。
- 导师制度：让已经熟练掌握 Cursor 的成员带新人。手把手演示一两个工作流循环，比如从 Plan 到最后测试通过的全过程。比起让新人自己琢磨，通过现场示范和指导会更高效。注意，这里的“新人”不一定是编程新人，而是对 AI 工具的新手——即使是资深开发，也需要学习如何与 AI 协作，这方面有经验的人可以作为导师。
- 制定团队 AI 使用指南：结合团队具体情况，编写一份内部的《 AI 编程工作流指南》。内容涵盖团队推荐的 Prompt 模板、规则约定、常见问题处理等。让每个团队成员都明确 AI 的定位——AI 不是来取代他们的，而是帮大家解除重复劳动、提供第二思路，但人仍然对最终质量负责。这样的指南能统一大家的认知，避免有人过度依赖 AI 或完全不敢用 AI 的两极化情况。
- 逐步扩大应用范围：可能起初团队只在部分项目、部分环节用 AI，比如先从测试生成或者文档生成开始，让大家建立信任。在看到效果后，再逐渐让 AI 参与核心编码。管理层也需要跟进 ROI，如果发现效率确实提升、错误率并未上升，那可以更大胆地投入。反之，如果初期效果不理想，要分析是工具问题、方法问题还是人员技能问题，及时调整训练计划。
9.4 跟踪 AI 技术演进
AI 技术日新月异，新模型、新工具层出不穷。要让你的工作流始终高效，保持对新技术的关注和学习也很重要：
- 关注 Cursor 官方更新：Cursor 官方博客和更新日志会发布新功能和改进。例如引入新的模型、改进 Agent 能力、推出新的集成功能等。及时了解这些更新，可以让你马上用上新工具。
- 参与社区：加入 Cursor 官方论坛、相关的 Discord/Reddit/微信群等。社区中大家会分享使用技巧、扩展插件、遇到的问题等。这是获取一手经验的好地方。积极参与讨论，你也可以提出自己的问题，往往很快会有热心人士或官方人员解答。
- 学习相关工具和思想：AI 辅助编程不仅仅是 Cursor 一家。GitHub Copilot、Tabnine、CodeGPT 等都有各自特色。了解不同工具的优劣，有助于完善你的方法。甚至可以将多种工具结合，例如用 Cursor 写代码、用 Copilot 补全小片段。再如了解一些提示工程（Prompt Engineering）的原理、LLM 的基础知识（如 token、上下文长度机制等），能让你更透彻地理解 AI 行为，写出更精准的提示。
- 评估新模型：当新模型推出，不妨试用并比较与旧模型的差异。新的模型可能有更强的推理能力、更大上下文等，这会影响提示写法和效果。Cursor 支持选择模型，所以当新模型推出，不妨试用并比较与旧模型的差异。始终保持对模型能力边界的最新认识，才能调整你的协作方式。
最后，要以成长的心态看待 AI 与开发者的关系。AI 不会让你退化，只会提供无数学习机会。把每次与 AI 协作当成切磋：当它给出一个你没见过的实现思路，认真研究背后的原理；当它出错时，分析原因反思自己是否也容易犯类似错误；当它提出不同方案，比较权衡从中提高架构能力。长远来看，你会发现自己不仅没有被 AI 取代，反而因为与 AI 共事而成为了一个更全面、更高效的工程师。
总结一句话：训练计划的核心是持续改进。持续地学、持续地用、持续地总结，再持续地学——正反馈循环。一开始也许需要花精力适应 AI 工具，但一旦工作流走上正轨，收益将非常显著。正如我们在开篇所说，这是“AI 增强的软件工程”，不是“AI 全自动的软件工程”。你付出的每一点学习和改进努力，都会通过 AI 的放大得到数倍的回报，助你在编程之路上更上一层楼。
10 结语与展望
10.1 大公司与 AI 转型
前面讨论的都是“个人如何与 AI 协作”。但如果你在大公司工作，可能会发现：即使个人已掌握这些技能，公司整体的 AI 采用进度却很慢。这不是错觉。
Peter Steinberger 在访谈中直言：
我觉得大公司会非常难以高效地采用 AI，因为这要求彻底重塑公司运作方式。比如在 Google，你要么是工程师，要么是经理；想同时决定 UI 长什么样，这个角色不存在。但新世界需要的是那种有完整产品视角、什么都能干的人，数量要少得多，但必须具备极高的自主性和能力。理论上，公司规模可以砍到原来的 30%。
所以我一点也不惊讶大公司现在用不好 AI。他们确实在用，但要真正用好，得先做一次大重构——不只是代码库，还有公司本身。
为什么大公司很难高效采用 AI？
大公司的组织结构是基于分工设计的：前端、后端、产品、设计、测试、运维… 每个人只负责一小块，通过流程和会议来协调。但 AI 打破了这种分工的必要性——一个人 + AI 可以自己写前端和后端、自己设计和实现、自己测试和部署。
分工的前提是“一个人做不完”，但现在这个前提被动摇了。
Peter 说的“新世界需要的人”，和他之前提到的“Builder”心态完全一致：
| 旧范式：专家分工 | 新范式：全栈 Builder |
|---|---|
| 每人只负责一小块 | 一人负责整个产品 |
| 通过流程协调 | 高度自主 |
| 数量多，能力中等 | 数量少，能力极高 |
| 身份认同：我是前端/后端 | 身份认同：我是创造者 |
重构公司比重构代码库更难
代码可以逐步重构，但组织变化涉及人、利益、情感：
- 涉及裁员：“规模砍到 30%”意味着大量人员调整
- 权力重新分配：中层管理的存在意义被削弱
- 文化冲突：大公司文化往往是“不要出错”，而 AI 协作需要“快速试错”
- 流程惯性：严格的审批流程是为“多人协作”设计的，但如果一人 + AI 就能完成，它们就成了阻碍
对个人的启示
如果你在大公司，不要等公司转型。先转型自己：
- 培养“全栈产品视角”——不只是写代码，要理解产品、用户、业务
- 学习与 AI 协作——本指南讨论的所有内容
- 让自己成为那种“什么都能干的人”——当变化来临时，你已经准备好了
历史上每次技术革命都会淘汰一批组织形式。AI 时代，新型组织形态会出现——可能是“一人公司 + AI”，可能是“3-5 人小团队 + AI”。传统大公司要么转型，要么被这些新形态取代。
无论你身处何种环境，能力的积累是属于你自己的。当整个行业重塑时，那些已经掌握了“AI 协作语言”的人，将拥有最大的选择权。
10.2 对新人的启示：你的“劣势”可能是优势
如果你是刚入行的新人，可能会焦虑：AI 时代，进入门槛更高了，前辈们都在用 AI，我怎么竞争？
Peter Steinberger 的观点可能会让你意外：
他们也有一个优势：没有被过往经验“污染”。他们会用 agent 做出很多我们根本想不到的事情，因为他们不知道“这原本是行不通的”。等他们这么用的时候，可能它已经真的行得通了。
前几天我有一个小的菜单栏应用，用来在 Cursor、Claude Code 这些环境里做成本追踪，性能有点慢。我想，那就来做性能分析吧。按我过去的习惯，我会打开 Instruments，到处点来点去。结果 agent 直接在终端里把所有事情都做完了，速度也提升了，还给了一些建议。我当时真的被震住了，完全不需要再打开 Instruments。
这是一个很有意思的反转。老手的问题是：他们“知道”什么行得通、什么行不通。但这些“知道”是基于过去的工具和能力形成的。AI 改变了能力边界，很多以前“行不通”的事情现在行得通了。
新人不知道这些“规则”，所以他们会天真地尝试——然后发现，居然成功了。
经验既是资产，也是负担——它让你知道什么可行，但也限制了你的想象力。
Peter 还说：
我觉得我们可能低估了进入科技行业的人有多么有办法，也低估了年轻人的潜力。回头看，很多伟大的公司都是非常年轻、经验并不丰富的人创办的，但他们有巨大的热情。这依然是存在的机会。
AI 时代，“能写代码”不再稀缺，但热情、好奇心、敢于尝试依然是稀缺的。技术可以学，但这些品质很难培养。
所以，对新人来说：不要把“经验不足”当作纯粹的劣势。保持好奇心，大胆尝试那些“老手觉得不可能”的事情。你可能会发现，在 AI 的帮助下，它们其实是可能的。
10.3 核心要点回顾
在结束之前，让我们回顾一下本指南的核心要点：
Plan-Execute-Verify 循环：这是 AI 协作编程的基本框架。先规划，再执行，最后验证——不断循环迭代，而不是期望一次性完美。
对话而非指挥：与 AI 协作不是发号施令，而是结对探索。用“我们讨论一下”、“有哪些选项”来延迟执行，在理解清楚之后再动手。
雕塑式构建：不追求一开始就有完美蓝图，而是边做边发现形状。“不行就扔，或者重提示”——试错成本极低，让形状从过程中浮现。
最小闭环：将大任务拆解为小步骤，每步都能产出可验证的结果。小步快跑，频繁提交，保持对方向和质量的掌控。
反馈闭环是关键：让 AI 能自己测试、自己 debug。有了测试和 CI，你不需要逐行审查，可以信任流程。
基本功比以前更重要：AI 放大的是你的已有能力。系统层面的理解、判断力、“知道该问什么”——这些才是 AI 时代的核心竞争力。
好奇心是最大的武器：你拥有一台“无限耐心的机器”，可以不停地问“为什么”。工具是平等的，好奇心是不平等的。
最后，记住 Peter Steinberger 的那句话：与 AI 协作是一门需要学习的“语言”。一开始可能会在凌晨三点对着它吼，但慢慢地，你会学会它的思维方式，几乎每次都能得到想要的结果。
这不是“AI 全自动的软件工程”，而是“AI 增强的软件工程”。你付出的每一点学习和改进努力，都会通过 AI 的放大得到数倍的回报。
祝你在 AI 协作编程的道路上，不断精进，成为驾驭 AI 的卓越开发者。
11 附录：资源与延伸阅读
构建 AI 编程工作流是一个综合性课题，这里列出一些优秀资源供进一步学习。读者可根据需要查阅，巩固和扩展本指南所涵盖的内容。
- Cursor 官方博客与文档：了解 Cursor 最新功能和最佳实践的权威来源。例如，官方博客的文章《使用 Agent 编码的最佳实践》详细讲解了从规划、上下文管理到自定义工作流的技巧。Cursor 官方中文文档站点也提供了规则、技能等功能的解释和示例。
- AI 编程工作流指南（SegmentFault）：一篇面向 2026 的实战指南（作者俞凡），总结了将 LLM 当作结对编程助手的 10 条准则，包括先写规格再写码、小步迭代、充分提供上下文、保持 Human-in-the-loop 等。本指南的很多理念与其不谋而合，强烈推荐阅读原文以获得更系统的认知。
- Cursor 高级配置与技巧：社区有不少分享 Cursor 使用技巧的文章，如《全网最全 Cursor 配置指南：从入门到高效工作流》，详细介绍了如何选择更强模型、扩大上下文、使用
@引用、集成外部文档和 MCP 等配置，可以帮助你将 Cursor 调校到最佳状态。另有《高效使用 Cursor 的 12 条黄金法则》也总结了一些宝贵经验。 - 自定义 Rules 和 Skills：想深入掌握 Cursor 扩展能力的读者，可以参考 Cursor 官网关于规则和技能的文档。另有中文社区文章对 Cursor Rules 的工作原理及四种类型做了浅析，GitHub 上也有他人整理的中文 Rules 示例仓库供参考。了解这些有助于你打造自己的个性化 AI 小助手。
- AI 辅助开发社区经验：加入相关社区以获取他人实践心得。例如 Reddit 的
r/ChatGPTCoding板块，有用户分享他们日常的 Cursor AI 工作流程；Bilibili 上也有系列视频教程演示 Cursor 从入门到实战的全过程。知乎、掘金等平台上亦不乏 Cursor 的使用案例和避坑指南。阅读和观看这些内容，能让你少走弯路、发现新技巧。 - 传统开发方法论书籍：不要忽视经典书籍的价值。《The Pragmatic Programmer》（《程序员修炼之道》）、《Clean Code》（《代码整洁之道》）、《Refactoring》（《重构》）等书中蕴含的原则在 AI 时代依然适用，甚至更加重要。将这些原则与 AI 工具结合，是打造高效工作流的最佳途径。
- AI 伦理与安全：提醒关于 AI 使用的伦理和安全方面资源。随着 AI 深度介入开发，要注意避免泄漏敏感代码到云端、警惕 AI 可能引入的有害代码片段等问题。可以参考微软等发布的安全指南，以及相关使用政策，确保在合规、安全的前提下使用 AI 工具。
希望以上资源能帮助你进一步深入学习。在 AI 编程工作流的探索之路上，多看、多问、多实践是关键。愿你不断汲取新知，在实践中融会贯通，早日将本指南的理念内化为自己的工作习惯，不断精进，做一个驾驭 AI 的卓越开发者！