IDE / Desktop / Web 怎么配合

Claude Code 的多个入口不是互相替代,而是负责不同环节。稳定工作流通常是:IDE 定位,CLI 执行,Desktop 审查,Web 跟进。

推荐组合

多个入口的关系不是“哪个最好”,而是“哪个最适合当前环节”。

可以先记住一句话:

IDE 适合定位,CLI 适合执行,Desktop 适合管理,Web/mobile 适合跟进。
入口最适合不适合
IDE当前文件、选中代码、局部解释、小范围编辑大范围跨项目修改、长时间后台任务
CLI本地项目读写、运行检查、批量修改、Git 状态确认没有项目目录概念的闲聊式需求
Desktop多会话管理、计划审查、diff 对比、任务复盘不看 diff 只当聊天窗口
Web/mobile远程跟进、长任务查看、离开电脑后的继续确认直接处理本地未提交文件

一个真实流程

1. 在 IDE 中定位问题文件和报错位置。
2. 在 CLI 中启动 Claude Code,让它进入 Plan Mode 分析。
3. 确认计划后让 CLI 执行修改和 /verify。
4. 在 Desktop 中审查 diff、总结风险和提交前检查。
5. 如果是长任务,再放到 Web 或 mobile 继续跟进。

更具体一点,可以这样用:

场景 1:修一个前端页面问题

  1. 在 IDE 里打开出问题的页面文件。
  2. 让 IDE 入口解释当前文件和相关组件。
  3. 切到 CLI,让 CC 只读分析整个页面链路。
  4. 确认计划后让 CLI 做最小修改。
  5. /run 看真实页面。
  6. 用 Desktop 或 CLI 审查 diff 和验证结果。

这个场景里,IDE 负责“看准位置”,CLI 负责“完成闭环”。

场景 2:做一次提交前检查

  1. 在 CLI 里让 CC 查看 Git 状态和 diff。
  2. 让 CC 按提交前清单检查无关文件、敏感信息、测试结果。
  3. 如果 diff 很多,可以在 Desktop 里并排审查。
  4. 确认没有问题后,再整理提交说明。

提交前检查最好不要只在 IDE 里做,因为 IDE 容易只看到当前文件,看不全项目 diff。

场景 3:长任务或多人跟进

  1. 先在 CLI 或 Desktop 里确认任务计划。
  2. 把任务拆成可交接的小步骤。
  3. 长时间执行或异步跟进时,用 Web/mobile 看进展。
  4. 回到本地后,必须重新审查结果和 diff。

Web/mobile 的价值是跟进,不是绕过本地验收。

不要这样用

切换入口前要同步什么

切换入口前,先让 CC 生成一段交接说明。

请生成一份入口切换交接说明。

我要从当前入口切到【CLI / IDE / Desktop / Web】继续。

请说明:
1. 当前任务目标是什么。
2. 已经完成了哪些分析。
3. 已经修改了哪些文件。
4. 哪些检查已经做过。
5. 哪些事情还没有确认。
6. 切换后第一步应该做什么。
7. 哪些文件不能让两个入口同时修改。

把这段交接说明发到新入口,比直接说“接着刚才做”稳定得多。

让 CC 帮忙切换入口

请判断当前任务适合在哪个 Claude Code 入口继续。

当前任务:
【描述任务】

请回答:
1. 继续用当前入口是否合适。
2. 是否应该切到 CLI、IDE、Desktop 或 Web。
3. 切换前要同步哪些上下文。
4. 如何避免两个入口同时修改同一批文件。

多入口冲突了怎么办

如果两个入口都改了文件,先暂停,不要让任何一个继续。

现在可能存在多个 Claude Code 入口同时修改文件的情况。

请先只读检查:
1. 当前 Git 状态。
2. 哪些文件被修改。
3. 哪些修改可能来自不同入口。
4. 是否存在互相覆盖或重复修改。
5. 最低风险的收敛方案是什么。

不要继续修改文件,先给我判断。

最常见的收敛方式是:保留一个入口继续,让另一个入口只做审查和总结。

推荐默认习惯

验收结果