用了 /orchestrate 一周，我把真实感受都写在这里了

你有没有这种体验：一个任务本来不复杂，但要在 AI 和自己之间来回倒腾四次，每次都要重新解释上下文，复制上一步的输出，粘贴到下一个对话框，然后再等……

我管这叫"AI 搬运工"——你不是在用 AI 思考，你是在帮 AI 传话。

Cursor 的 /orchestrate 指令号称能解决这个问题。它的承诺很直接：你说一个目标，它帮你拆任务、派 Agent、跑流程。

我用了整整一周，测了三个不同规模的项目。这篇文章不是软文，是我把真实的执行日志、跑偏案例、Token 账单摊开来说一遍。

---

第一章：/orchestrate 到底做了什么，跟普通对话有什么本质区别

很多人第一次看到 /orchestrate 会以为它只是"更聪明的 Composer"——输入更复杂的 Prompt，输出更长的代码。

这个理解是错的。

普通的 Composer 或 Chat 模式，本质是一问一答的串行结构：你问，AI 答，你再问，AI 再答。即使你一次性给出很长的需求，它也是从头到尾线性处理，中间不会"分身"。

/orchestrate 的机制完全不同。它会先生成一个协调 Agent（Orchestrator），这个 Orchestrator 的职责不是写代码，而是理解你的目标、拆解任务树、决定哪些子任务可以并行、哪些必须串行依赖。

用一个不那么精确但很直观的类比：普通 Composer 是一个独立开发者接了你的需求，从头写到尾；/orchestrate 是一个项目经理接了需求，然后把活分给了一组人，有人同时在写前端、有人在写后端、有人在写测试，最后汇总。

执行结构大概长这样：

```

用户输入目标

└── Orchestrator（协调层）

├── Sub-Agent A：需求分析 & 技术选型

├── Sub-Agent B：核