Cursor /orchestrate 深度实测：它让我少写了80%的代码，但我一秒都没敢不盯着它

你有没有经历过这种情况——把任务扔给 AI，它做完第一步，然后停下来问你："接下来怎么办？"

你输入下一步指令，它又做完，再停下来问。你做了个计算：这个任务需要5步，你就得回答5次问题，复制5次代码，检查5次结果。AI 确实帮你写了代码，但你全程都在当一个人肉传话筒。

上个月，Cursor 推出了 /orchestrate 命令。我用同样的任务试了一次——它自己跑完了4步，只在第3步停下来问了我一个问题。

这篇文章就是那次实验的完整复盘。

---

第一章：/orchestrate 是什么？先把概念说清楚

很多人第一次看到 /orchestrate 的介绍，会以为它是"更聪明的代码补全"。这个理解是错的，而且错得很关键。

你 → 提问 → AI 回答 → 你 → 提问 → AI 回答 → 你 → 提问...

你是指挥官，也是执行者。每一步都需要你手动触发、手动确认、手动推进。

你 → 描述目标 → AI 拆解任务 → AI 自主执行步骤1 → 步骤2 → 步骤3（遇到歧义暂停）→ 步骤4 → 步骤5 → 交付结果

你只是指挥官。AI 接管了执行层。

这个差别听起来不大，实际上是质变。它意味着 AI 可以：

• 跨文件追踪依赖，自己决定改哪些文件
• 保持任务上下文，不需要你每次都重新解释背景
• 在多个子任务之间传递状态，而不是每次从零开始

Cursor 官方对这个功能的定位是：适合需要多步骤、跨文件协作的复杂工程任务。关键词是"复杂"和"多步骤"——如果你只是让它改一个函数，用普通 Composer 更快。

---

第二章：我的实验——一个真实的5步重构任务全程复盘

任务背景

我有一个用了三年的 Express.js 项目，早期写的时候 async/await 还没普及，大量用了回调风格（callback hell 那种）。技术债欠了很久，决定趁这次实验彻底重构。

涉及文件：23个路由文件 + 8个中间件文件 + 41个测试文件，总计约 6000 行需要审查的代码。

手动完成这个任务，我估算需要：

我输入的指令

/orchestrate 将这个 Express.js 项目从 callback 风格全面迁移到 async/await。
要求：
1. 保持所有现有 API 接口行为不变
2. 统一错误处理为 try/catch + next(err) 模式
3. 同步更新所有相关测试文件
4. 每个步骤完成后输出变更摘要

它自动拆解的任务清单

📋 任务编排计划

>

Step 1 — 扫描项目结构，识别所有使用回调模式的文件（预计影响范围分析）

>

Step 2 — 按依赖顺序改写中间件层（优先级最高，其他文件依赖它）

>

Step 3 — 改写路由层（按模块分组，逐组处理）

>

Step 4 — 更新错误处理链（统一 error handler 签名）

>

Step 5 — 同步测试文件，运行测试套件

>

⚠️ 在 Step 3 执行前将暂停确认，因为部分路由存在业务逻辑歧义需要人工判断

注意最后那行——它自己判断出了需要暂停的节点，而不是盲目执行。这个细节让我对这次实验的信心增加了不少。

实际执行过程

// 原始回调风格
function verifyToken(req, res, next) {
jwt.verify(req.headers.token, SECRET, function(err, decoded) {
if (err) {
return res.status(401).json({ error: 'Invalid token' });
}
req.user = decoded;
next();
});
}

// /orchestrate 输出的 async/await 版本
async function verifyToken(req, res, next) {
try {
const decoded = await jwt.verify(req.headers.token, SECRET);
req.user = decoded;
next();
} catch (err) {
next(new AuthError('Invalid token', 401));
}
}

这里它做了一个我没有明确要求的决策：把 res.status(401).json() 替换成了 next(new AuthError())，符合我在指令里说的"统一错误处理"原则。逻辑是对的，但这是它猜出来的——后面我会说这个"猜"字有多重要。

order.router.js 第 87 行存在一个嵌套回调，内层回调在外层回调失败后仍然可能被触发。改写为 async/await 后，这个行为会改变。请确认：是否保留原有行为（可能是 bug），还是修复为正确的错误中断逻辑？

这个问题问得很准。那段代码确实是个历史 bug，当时写的时候没发现，一直在生产环境里跑着（没有触发过，所以没暴露）。我选择了修复。

实际耗时对比

---

💡 实验用的底层模型是 Claude Sonnet 4.6。如果你也想在 Cursor 里用这个模型，但不想被 Cursor 的 token 配额限制，可以通过 [api.884819.xyz](https://api.884819.xyz) 直接接入——国内直连，按量付费，没有月租。新用户注册即送体验 token，国产模型（Deepseek/千问等）完全免费。配置方式见文末。

---

第三章：真正省力的3个环节 vs. 必须你盯着的2个坑

✅ 真正省力的地方

这是我体感最明显的地方。人工做这种重构，最怕的就是"漏改"——改了路由但忘了对应的测试，或者改了中间件但没更新调用它的地方。/orchestrate 在 Step 1 做了完整的依赖图扫描，后续每一步都基于这张图执行，几乎不会漏。

23个路由文件，改写模式基本相同。这种"同类操作批量执行"是它最擅长的场景。如果让你手动改，第10个文件你就开始走神了。

这是个老问题：改了实现，忘了改测试，CI 挂了才发现。/orchestrate 把"更新测试"作为任务的一部分内置进来，不需要你单独提醒。

⚠️ 必须你盯着的地方

前面说的 AuthError 那个例子就是典型。它猜对了，但它是在猜。如果你的代码库里有一些"看起来像 bug 但其实是刻意设计"的逻辑，它可能会"修掉"。

Step 4 的那次跑偏，根本原因是它不知道那个第三方库的版本约定。它只看到了代码，看不到你的 package.json 里的版本锁定和库的内部实现。

何时介入——简易决策表

---

第四章：/orchestrate 适合什么任务？给你一个选用框架

任务可编排指数（5维度自评）

在把任务交给 /orchestrate 之前，用这5个维度给它打分（每项1-2分，总分越高越适合）：

最适合的任务类型

• ✅ 语法/风格迁移（ES5 → ES6+、callback → async/await）
• ✅ 框架版本升级（API 变更的批量适配）
• ✅ 代码格式统一（统一错误处理、日志格式、命名规范）
• ✅ 测试文件批量生成/更新

不适合的任务类型

• ❌ 新功能开发（需要产品判断，规则不清晰）
• ❌ 架构重设计（影响面太广，风险太高）
• ❌ 依赖大量外部文档的集成（它看不到文档）
• ❌ 没有测试覆盖的遗留系统（没有安全网）

---

第五章：现阶段的局限和我的真实结论

三个明显局限

我的项目 6000 行代码在它的处理范围内，但如果项目再大一倍，上下文窗口会开始成为瓶颈。它在后期的任务执行中，偶尔会"忘记"早期步骤建立的一些约定，需要你手动提醒。

Step 4 我回滚了部分修改，然后继续执行。这个过程不够优雅——它没有"断点续传"的概念，我需要手动告诉它"从哪里继续"。如果任务在中间某步完全失败，重新开始的成本比你想象的高。

Express.js 这种主流框架效果很好。如果你用的是小众框架或者内部框架，它对框架约定的理解会明显下降，"猜"的成分会更多，出错率也会上升。

我的最终结论

我不打算说"各有优劣，看个人需求"这种废话。

但"可用"不等于"可以完全信任"。它更像一个能力很强但需要监督的实习生——你可以把执行层交给他，但判断层必须留在你这里。

自动挡不是无人驾驶。 它解放了你的手，但没有解放你的眼睛。

如果你有一个规则清晰、重复性强、有测试兜底的重构任务，现在就可以去试。如果你想把它用在新功能开发或者架构决策上，再等等——那个时代还没到。

---

📎 Cursor 接入自定义 API 配置方法

如果你想在 Cursor 里用性价比更高的模型接口：

• Base URL：api.884819.xyz
• 注册即送体验 token，国产模型完全免费，无月租

---

写在最后

下一篇，我想聊聊这件事：怎么让 AI 的推理过程"可审计"——不只是 Cursor，所有 Agent 类工具都面临这个问题。如果你也觉得"AI 黑盒执行"让你不安，记得关注更新。

---

#Cursor #AI编程 #代码重构 #orchestrate #AI工具 #开发效率 #Agent #8848AI