Claude Code 的 /ultraplan：把计划丢到云端写，终端专心干活

你有没有这种崩溃时刻：

• 想让 Claude 先写个执行计划（plan）
• 计划写得还行，但需要你反复改
• 结果你在终端里来回滚屏、复制粘贴、改一行错一行

/ultraplan 就是来治这个的。它把“写计划”这段活交给 Web 端云会话去跑，你的终端腾出来继续干活。计划写完，你在浏览器里像改文档一样修订，满意了再一键“传送”回本地终端接着执行。舒服很多。😌

/ultraplan 到底解决了什么痛点？

1）终端不再被 plan 占着

Claude 在云端研究你的代码库、起草计划。

你这边终端不需要等它“打草稿”，可以继续：

• 查日志
• 跑测试
• 回答同事消息
• 顺便把咖啡续上（这条很关键）

2）计划在浏览器里改，像改文档

之前 plan 写在终端里，改起来像“在便签纸上改需求”。

现在你在 Web 端看到完整 plan：

• 结构更清晰
• 易读
• 好改
• 改到满意再同步回终端

3）计划与执行分工更明确

很多人用 AI 写代码翻车，根因不是模型不行，而是计划没打磨清楚就开干。

/ultraplan 的思路很简单：

• 计划阶段：云端慢慢研究、慢慢打磨
• 执行阶段：回到本地终端动手改代码

怎么启动 /ultraplan（3 种方式）

你按习惯选就行。

方式 A：直接在终端输入 /ultraplan

适合你已经知道要干什么，想立刻让它出一份“靠谱施工方案”。

示例：

/ultraplan migrate the auth service from sessions to JWTs

这种指令很适合“迁移/重构/大改动”。比如：

• 把 sessions 登录改成 JWT
• 把一个服务拆到单独的模块
• 替换 ORM
• 升级框架主版本

方式 B：在普通提示词里带上关键字 ultraplan

你不想记命令也行。

在正常对话里写上 ultraplan，Claude 会自动走这条路径。

示例（随便一句话也能触发）：

ultraplan：帮我把支付模块从回调式接口改成 async/await，并列出改动风险和回滚方案。

方式 C：本地 /plan 起草一版，再升级到 Ultraplan

你已经用本地 /plan 写了个初稿，但感觉不够细、不够稳。

这时直接点：

No, refine with Ultraplan

等于把本地草案“升到云端”，让 Claude 用更适合编辑的方式继续打磨。

启动后你会看到什么？看终端状态就够了

/ultraplan 开跑后，终端底部会显示状态。你不用盯着它发呆，扫一眼就知道进度。

• ◇ ultraplan：正在起草

  • Claude 在云端研究项目、写计划

• ◇ ultraplan needs your input：Claude 有问题要问你

  • 它需要你补信息
  • 终端会给链接，点开去浏览器回答就行

• ◆ ultraplan ready：计划好了

  • 云端 plan 已完成
  • 去浏览器看、改、确认，然后传回本地继续执行

小技巧：

• 看到 needs your input 别拖太久，不然它卡在那里等你。
• 你回答越具体，它后面写出来的 plan 越像“你团队里那个靠谱的 tech lead”。

推荐工作流：这样用最省心

场景：你要做一次“登录体系从 Session 换成 JWT”

这类任务最怕两件事：

• 改一半发现没考虑刷新 token、注销、跨域、兼容旧客户端
• 线上出事故，回滚方案没写

用 /ultraplan 可以这样走：

1. 终端发起：

/ultraplan migrate the auth service from sessions to JWTs

2. 看到 ◇ ultraplan：正在起草，你继续做别的（比如先把相关测试跑起来）。

3. 如果出现 needs your input，去浏览器回答几个关键问题，比如：

• JWT 放哪（cookie / header）？
• 需不需要 refresh token？
• 旧 session 要不要兼容一段时间？
• 哪些服务依赖当前鉴权？

4. ready 以后，在浏览器里把 plan 当成“施工图”来改：

• 把步骤拆到可执行的 task（每个 task 有验收标准）
• 加风险点与回滚
• 标注需要改哪些文件/模块

5. 改到满意，一键传回终端。

6. 回到本地执行：按计划逐条做，边做边验证。

让 plan 更好用的几条要求（建议你直接复制给 Claude）

你在云端编辑 plan 时，可以加一句要求，让它输出更像“可落地的施工单”。

你可以这样写：

• “把 plan 写成 checklist，每一项都要有验收方式（怎么证明完成）。”
• “给出影响面：哪些 API、哪些前端页面、哪些配置项会受影响。”
• “列出回滚路径：出问题时怎么快速切回旧逻辑。”
• “把风险分级：高/中/低，并写出对应的缓解动作。”
• “拆分成小 PR 的节奏：每个 PR 做什么，怎么保证可合并。”

你会发现它写出来的计划，会从“看起来很对”变成“照着就能做”。

避坑清单（别踩这些雷）

• 需求不清就让它写计划

  • 结果 plan 会很“广”，你看完还是要补一堆信息。
  • 解决：遇到 needs your input，把关键约束一次说透。

• 计划写太宏大，不可验证

  • 例如“完成鉴权改造”这种话等于没说。
  • 解决：强制每一步都有验收方式：跑什么测试、看什么指标、对比什么行为。

• 没写回滚就开干

  • JWT 这种改动，线上出问题很正常。
  • 解决：让 plan 明确“开关/灰度/回滚”三件套。

• 把 /ultraplan 当成自动写代码工具

  • 它强项是“把路线图打磨到可执行”。
  • 代码执行还是在本地终端那套流程里更稳。

你该什么时候用 /ultraplan？

这玩意适合“动大手术”的活：

• 跨模块重构
• 迁移（sessions → JWT、REST → GraphQL、旧框架 → 新框架）
• 安全相关改造
• 大范围性能优化（需要测量、对比、回滚）

小修小补就别折腾了，直接在终端让 Claude 写代码更快。

如果你愿意，把你准备输入的 /ultraplan 任务句子发我。我可以帮你把这句话打磨得更“像指令”，让它生成的计划更贴近你项目的真实约束。