Claude Code Desktop 使用教程

Claude Code Desktop 适合管理多个会话、审查 diff、整理任务计划和做交付复盘。它不是单纯聊天窗口，而是把任务过程看清楚的工作台。

Desktop 入口适合把任务“摊开来看”。相比 CLI 更贴近项目执行、IDE 更贴近当前文件，Desktop 更适合管理多个任务、审查改动、整理计划和做交付复盘。

可以先记住一句话：

CLI 负责执行，IDE 负责局部，Desktop 负责看全局。

Desktop 适合做什么

不适合 Desktop 的场景：

Desktop 不一定要亲自“动手改”。它更适合帮用户看清任务全貌。

第一次用 Desktop，不建议直接让它大范围改项目。先让它审查计划。

请在 Desktop 中帮我审查这个任务计划。

任务目标：
【写清楚目标】

要求：
1. 先只读理解任务。
2. 判断目标是否清楚。
3. 判断修改范围是否过大。
4. 列出需要确认的问题。
5. 给出建议执行顺序。
6. 不要修改文件。

如果计划里有“顺便重构”“统一优化”“整体调整”这类词，要特别警惕。Desktop 的价值就是让这些模糊范围暴露出来。

修改完成后，可以让 Desktop 用审查者视角看 diff。

请审查当前 diff。

重点看：
1. 是否只修改了任务相关文件。
2. 是否有无关格式化或重构。
3. 是否有敏感信息。
4. 是否需要补测试或验证。
5. 是否有可以收窄的改动。

请优先输出问题和风险，不要先总结完成情况。

如果 Desktop 发现问题，不要让它马上继续修。先确认是否确实要修，以及由哪个入口来修。

请把 Desktop 审查结果分级。

请分成：
1. 阻塞提交的问题。
2. 本次最好修的问题。
3. 可以之后单独处理的问题。
4. 只是风格偏好的建议。

不要把所有建议都当成必须修。

推荐流程：

避免两个入口同时拥有修改权。一个入口负责执行，另一个入口负责审查，任务会更稳。

请生成给 CLI 的执行交接。

要求：
1. 本次任务目标。
2. Desktop 已经审查出的风险。
3. 建议 CLI 只读确认的文件。
4. CLI 可以执行的最小修改。
5. CLI 修改后要如何验证。

Desktop 里最容易犯的错是开太多会话，每个会话都在聊同一个项目。

建议：

可以用这个提示词收尾：

请总结当前会话，作为任务记录。

要求：
1. 原始目标是什么。
2. 完成了什么。
3. 修改了哪些文件。
4. 做了哪些验证。
5. 还有哪些未完成或风险。
6. 是否有经验应该沉淀到 CLAUDE.md 或 Skill。

请用 Desktop 帮我管理这个任务。

任务目标：
【写清楚目标】

要求：
1. 先做计划审查。
2. 标出修改范围和风险。
3. 如果需要执行修改，请说明更适合 CLI、IDE 还是 Desktop。
4. 修改后帮我审查 diff。
5. 最后生成交付总结。