Cursor Plan Mode：AI 终于知道先想后做了

什么？Cursor 继 Agent、ASK 之后推出了 Plan Mode。直接解决了 AI 在执行处理复杂任务时鸡同鸭讲+左右互搏的痛点，赶快瞅瞅怎么个事儿？

什么是 Plan Mode？（用人话讲）

Plan Mode 的核心理念可以用一句话概括：让 AI 先画个饼，再真的做饼。

以前的流程是这样的：

css 复制代码

你：我要个蛋糕
AI：给你做了个芝士蛋糕 [直接动手]
你：我说的是生日蛋糕，而且我乳糖不耐受...

现在的流程是这样的：

markdown 复制代码

你：我要个蛋糕
AI：让我想想，根据上下文分析，你可能需要：
    1. 生日蛋糕（因为你朋友圈昨天说生日快乐）
    2. 无乳糖配方（根据你的健康记录）
    3. 8寸大小（根据你家人数）
    4. 草莓装饰（根据你的购买历史）
    这个方案怎么样？

你：完美！开始做吧
AI：收到，开始执行计划...

这就是**从"直接执行"到"先规划再执行"**的转变。

为什么需要 Plan Mode？（血泪史）

痛点一：AI 的"近视眼"问题

传统 AI 编程就像一个度数 800 但拒绝戴眼镜的程序员，能看清眼前的代码，但看不到 5 米外的依赖关系。

真实案例：

typescript 复制代码

// 我让 AI 优化这个函数
function fetchUserData(userId: string) {
  return api.get(`/users/${userId}`);
}

// AI 很贴心地改成了这样
async function getUserProfile(id: number) {
  const response = await api.get(`/user/profile/${id}`);
  return response.data;
}

// 然后我发现有23个文件在调用 fetchUserData
// 改个函数名我就得改23个文件 ... 哭晕在厕所

Plan Mode 的做法是：

复制代码

AI：我发现这个函数被23个地方引用，给你一个重构计划：
步骤1：创建新函数 getUserProfile
步骤2：修改 fetchUserData 内部调用新函数，保持接口不变
步骤3：逐步迁移调用方
步骤4：删除旧函数

这样可以避免破坏性变更，你觉得如何？

这就是全局思维 vs 局部思维的区别。

痛点二：提示词工程师的诞生

用过传统 AI 编程工具的都知道，想让 AI 干好活，你得先变成"提示词工程师"。

新手的提示词：

arduino 复制代码

"帮我写个登录功能"

专家的提示词：

markdown 复制代码

需求：实现用户登录功能
技术栈：React 18 + TypeScript + Zustand
项目结构：
├── src/
│   ├── components/auth/
│   ├── stores/authStore.ts
│   └── types/user.ts

具体要求：
1. 表单包含邮箱和密码字段
2. 客户端验证（邮箱格式、密码长度）
3. 登录成功后更新全局状态
4. 错误处理和 loading 状态
5. 支持"记住我"功能
6. 遵循现有的 UI 组件库设计规范

API 接口：
POST /api/auth/login
请求：{ email: string, password: string, remember: boolean }
响应：{ token: string, user: UserInfo }

约束条件：
- 不要使用 localStorage 存储敏感信息
- 密码输入框要支持显示/隐藏切换
- 兼容移动端响应式设计

看出差距了吗？新手的结果是不能用的代码，专家的结果是可以直接上线的功能。但问题是，为了用好 AI，你得先成为专家。这不是很讽刺吗？

Plan Mode 改变了这个局面：

markdown 复制代码

你："我需要一个登录功能"

AI："我分析了你的项目结构，这里是我的实现计划：

📋 登录功能实现方案

🔍 项目分析结果：
- 发现使用 React 18 + TypeScript
- 已有 Zustand 状态管理
- UI 组件库：Ant Design
- 认证相关文件：src/stores/authStore.ts

📝 实现计划：
步骤1：创建登录表单组件 (LoginForm.tsx)
  - 邮箱/密码输入框
  - 表单验证逻辑
  - 提交处理

步骤2：扩展 authStore
  - 添加 login action
  - 处理 loading 和 error 状态
  - Token 存储策略

步骤3：API 集成
  - 登录接口调用
  - 错误处理
  - 响应数据处理

步骤4：路由集成
  - 登录成功后跳转
  - 受保护路由处理

预计影响文件：
✏️ 新建：src/components/auth/LoginForm.tsx
✏️ 修改：src/stores/authStore.ts
✏️ 修改：src/types/user.ts (如果需要)

这个方案符合你的预期吗？"

从"人适应 AI"到"AI 适应人"，这就是 Plan Mode 的价值。

痛点三：上下文管理的噩梦

AI 的记忆力有限（token 限制），长期对话中它会"失忆"。

典型场景：

复制代码

第1轮：你告诉 AI 项目用的是 React 18
第2轮：AI 记住了，给出兼容方案
第3轮：讨论状态管理架构
第4轮：AI 还记得 React 版本
第5轮：开始实现具体功能
第6轮：AI 忘了 React 版本，给出了 React 16 的写法
你：？？？

Plan Mode 通过"计划文档"的方式固化了上下文：

diff 复制代码

📋 项目上下文 (Plan Mode 自动维护)
- React 18.2.0 + TypeScript 4.8
- 状态管理：Zustand
- UI 库：Ant Design 5.x
- 构建工具：Vite
- 代码风格：项目内置 ESLint 规则

这个上下文在整个执行过程中都保持一致，避免了"AI 精神分裂"的问题。

Plan Mode 的工作原理（技术深挖）

阶段一：项目理解（Context Analysis）

AI 不再是拿到任务就开干，而是先进入"侦探模式"：

typescript 复制代码

// AI 内部的分析过程（简化版）
interface ProjectAnalysis {
  structure: FileTree; // 项目结构
  dependencies: DependencyGraph; // 依赖关系
  patterns: CodePattern[]; // 代码模式
  constraints: Constraint[]; // 约束条件
}

// 比如分析到：
const analysis: ProjectAnalysis = {
  structure: {
    "src/components/": ["UserCard.tsx", "LoginForm.tsx"],
    "src/stores/": ["authStore.ts"],
    "src/types/": ["user.ts"],
  },
  dependencies: {
    "UserCard.tsx": ["user.ts", "authStore.ts"],
    "LoginForm.tsx": ["authStore.ts"],
  },
  patterns: [
    { type: "StateManagement", library: "zustand" },
    { type: "Styling", approach: "css-modules" },
  ],
  constraints: [
    { type: "TypeScript", strict: true },
    { type: "Performance", requirement: "memo-optimization" },
  ],
};

这个分析过程让 AI 对项目有了"全局视野"。

阶段二：方案设计（Solution Design）

基于项目理解，AI 开始"头脑风暴"：

typescript 复制代码

interface ExecutionPlan {
  objective: string;
  steps: PlanStep[];
  risks: Risk[];
  alternatives: Alternative[];
}

interface PlanStep {
  id: string;
  description: string;
  files: FileOperation[];
  dependencies: string[];
  estimatedImpact: "low" | "medium" | "high";
}

// 例如：
const plan: ExecutionPlan = {
  objective: "优化 UserCard 组件性能",
  steps: [
    {
      id: "step-1",
      description: "添加 React.memo 包装",
      files: [{ path: "src/components/UserCard.tsx", operation: "modify" }],
      dependencies: [],
      estimatedImpact: "low",
    },
    {
      id: "step-2",
      description: "优化 props 传递",
      files: [
        { path: "src/components/UserCard.tsx", operation: "modify" },
        { path: "src/pages/UserList.tsx", operation: "modify" },
        { path: "src/pages/Profile.tsx", operation: "modify" },
      ],
      dependencies: ["step-1"],
      estimatedImpact: "medium",
    },
  ],
  risks: [
    {
      description: "props 接口变更可能影响其他组件",
      mitigation: "保持向后兼容或同步更新所有调用方",
    },
  ],
};

这就是**从"想到哪写到哪"到"系统性设计"**的升级。

阶段三：人机协作（Human Review）

这是 Plan Mode 最巧妙的设计，它不是把计划扔给你就不管了，而是启动了一个"技术评审会议"：

scss 复制代码

🤖 AI：这是我的实现方案，请审阅：

👨‍💻 你：步骤2的影响评估有问题，UserCard 还在 Dashboard 页面用到了

🤖 AI：你说得对！我重新分析了代码，发现还有3个地方的调用：
  - src/pages/Dashboard.tsx (第45行)
  - src/components/TeamMembers.tsx (第23行)
  - src/pages/AdminPanel.tsx (第67行)

  我更新了计划，加入了这些文件的同步修改。

👨‍💻 你：AdminPanel 那个调用方式不一样，它传的是 userData 对象

🤖 AI：明白了，我看到了差异。AdminPanel 使用的是：
  <UserCard userData={user} showActions={false} />

  而其他地方是：
  <UserCard user={user} />

  我会在步骤3中处理这个特殊情况。

👨‍💻 你：好的，可以开始执行了

🤖 AI：收到！开始执行修改计划...

这个过程就像真正的团队协作------AI 是方案提供者，你是架构师/reviewer。

我的使用心得（踩坑指南）

什么时候用 Plan Mode？

✅ 适合的场景：

跨文件的重构任务
新功能开发（涉及多个模块）
架构调整
复杂的 bug 修复
不熟悉的代码库

❌ 不必要的场景：

简单的样式调整
单行代码修改
实验性的小改动
你很确定影响范围的任务

如何写好需求描述？

Plan Mode 降低了提示词门槛，但不意味着可以随便说话：

❌ 不好的描述：

arduino 复制代码

"这个页面有点慢，优化一下"

✅ 更好的描述：

arduino 复制代码

"课程列表页面在加载1000+课程时出现卡顿，滚动不流畅，
需要优化渲染性能，目标是60fps流畅滚动"

关键要素：

明确问题：什么慢？怎么个慢法？
量化指标：多少数据？期望多快？
约束条件：不能改什么？必须保持什么？

如何审阅 AI 的计划？

这是 Plan Mode 的核心技能，我总结了几个要点：

1. 检查遗漏

diff 复制代码

AI 说要修改这些文件：
- ComponentA.tsx
- ComponentB.tsx

我会问自己：
- 还有其他地方用到相关接口吗？
- 类型定义文件需要更新吗？
- 测试文件需要同步修改吗？

2. 评估风险

diff 复制代码

AI 计划修改核心组件的 props 接口

我的checklist：
- 这是破坏性变更吗？
- 向后兼容性如何保证？
- 有没有更安全的渐进方案？

3. 考虑长期影响

diff 复制代码

AI 建议引入新的状态管理库

我会思考：
- 这与现有架构兼容吗？
- 会增加项目复杂度吗？
- 团队其他成员容易理解吗？

常见坑点及避免方法

坑点 1：AI 过于自信

AI 有时候会显得很确定，但实际上它可能理解错了需求。

arduino 复制代码

AI："根据分析，这个性能问题是因为重复渲染，
    我建议用 useCallback 优化"

实际上：问题可能是数据量太大，需要虚拟滚动

避免方法：保持怀疑精神，如果方案看起来"太简单"，多问几个为什么。

坑点 2：忽略业务逻辑

AI 擅长技术实现，但对业务逻辑的理解有限。

arduino 复制代码

AI："我优化了数据加载，现在会预加载下一页数据"

业务需求：用户可能永远不会翻页，预加载是浪费

避免方法：在审阅计划时，从用户体验角度思考方案是否合理。

坑点 3：技术选型过于激进

AI 喜欢用新技术，但不考虑团队接受度和维护成本。

arduino 复制代码

AI："我建议重写这个模块，用最新的 React Server Components"

现实：团队对 RSC 不熟悉，引入风险大于收益

避免方法：坚持"合适 > 先进"的原则。

对我的启示（哲学思考）

开发模式的变化

旧模式：开发者 → 大量准备 → 精确指令 → AI → 输出。
新模式：开发者 → 简单意图 → AI 自主规划 → 展示计划 → 校对计划 → 执行。

之前用 AI 写代码，感觉更像是指挥一个执行力很强但缺少全局观的助手。你说一句，它做一件事，至于这件事会不会影响其他地方、是不是最优解，它不太管。结果就是你要么把任务拆得特别细，要么就得做好返工的准备。想让 AI 处理复杂任务，不但需要对原项目有足够深的理解，还要掌握良好的提示词技巧。在 AI 开始工作之前要做大量的前置工作（例如上下文注入、任务拆分）。很多时候前置准备工作其实挺耗费心力的，这个时间拿来自己写代码可能也差不多了。想用好 AI，必须先踏过提示词工程化这道门槛。

Plan Mode 在一定程度上缓解了这个问题。在实际修改代码之前，AI 会先制定详细的执行计划，将较长的任务分解为具有依赖关系的可管理步骤，然后把这个思考过程展示出来，开发者可以在执行前调整计划。这个设计其实挺符合软件工程的基本原则------先规划再执行，而不是边做边想，对于大型重构、跨文件修改等复杂任务，有计划地执行比直接修改更可靠。在执行过程中还会将计划以虚拟文件的形式存储，可以编辑和共享，使长任务更容易理解和跟踪。

当然，这不意味着不需要专业能力了，但至少门槛降低了，从"必须是专家才能用好"变成了"新手也能用，专家用得更好"。工具在变，但对 AI 本质的理解不会过时。AI 可以生成代码，但它替代不了对"为什么要这么做"的思考。技术选型背后的权衡、架构设计的长期影响、代码质量的标准，这些需要理解业务、理解用户、理解技术演进趋势，短期内 AI 很难做到。业务理解和技术深度仍然非常重要，决定着项目的内核和 AI 的上限。AI 时代的开发者，不是要和机器竞争执行力，而是要展现人类独有的判断力、创造力和洞察力。

对开发者意味着：

机会：

从繁琐的实现细节中解放出来
有更多时间思考架构和业务
工作重心从"怎么做"转向"为什么做"

挑战：

需要培养方案审阅能力
要保持对技术本质的理解
必须提升系统性思维

Plan Mode 可能只是 AI 开发工具演进过程中的一个小节点，但它影射了 AI 工具的发展方向：不是让 AI 完全替代人，也不是让人完全适应 AI，而是找到一个合适的协作方式，让各自的优势都能发挥出来。这不意味着编码技能不重要了，而是说编码从目的变成了手段。