CLI与桌面端不是两个版本,而是两种人机协作范式
1. 一个被严重低估的真相CLI 和桌面端根本不是“两个版本”而是两种工作范式我第一次在终端里敲下claude code命令看着光标安静地闪烁心里想的是“这不就是个带点智能的git吗”——直到我把同一个项目拖进桌面端打开 Code 选项卡把窗格拖成四宫格一边看 diff、一边跑预览、一边在侧边栏问“这段代码为什么用useCallback而不是useMemo”另一边终端还在后台自动重试失败的 CI。那一刻我才意识到我们不是在比较两个工具而是在对比两种截然不同的“人机协作操作系统”。这不是“哪个更好用”的问题而是“你此刻在扮演什么角色”的问题。CLI 是你的副驾驶——它听指令、记日志、可脚本化适合你作为工程师在写代码时需要一个沉默但精准的执行者桌面端则是你的协作者兼工作台——它有记忆、会布局、能预览、懂上下文隔离适合你作为项目负责人在推进一个功能闭环时需要一个能同时处理设计、编码、测试、部署多个维度的伙伴。关键词“Claude Code CLI”和“Claude Code 桌面端”背后藏着一个被热搜词掩盖的核心事实绝大多数人安装了桌面端却把它当成了“图形化的 CLI”来用而多数人用 CLI又只把它当成“命令行版的 Chat UI”来调用。结果就是CLI 用户抱怨“它不会自己开终端跑测试”桌面端用户吐槽“它老让我确认每一步比我自己干还慢”。这根本不是产品缺陷而是使用范式错配。就像你不会用 Photoshop 的图层功能去写 Python 脚本也不该用 CLI 的原子化命令去完成一个需要多视图协同的重构任务。本文不讲“怎么安装”不列“功能对比表”而是带你一层层剥开CLI 的底层契约是什么桌面端的隐含协议又是什么当你在某个具体场景下卡住时到底是工具不行还是你没找到它为你预留的那条“正确路径”我过去三个月里用 CLI 完成了 17 个自动化脚本从每日依赖扫描到 PR 自动分类也用桌面端交付了 3 个全栈项目从原型验证到上线监控。踩过的坑、绕过的弯、突然顿悟的“啊哈时刻”都会在这里摊开讲。你不需要记住所有命令或菜单路径只需要理解什么时候该把控制权交给 CLI什么时候该把注意力让渡给桌面端——这才是真正决定效率上限的关键分水岭。2. CLI 的本质一个“无状态、可审计、可嵌入”的执行引擎很多人一看到claude code --model sonnet --permission-mode auto-accept-edits这类命令第一反应是“参数好复杂”。但如果你拆开看就会发现 CLI 的设计哲学极其冷峻它不保存任何状态不维护任何上下文不做任何假设只做三件事——接收输入、执行动作、输出结果。它像一台精密的 CNC 机床你给它 G 代码它就按坐标切削切完就停不问你下一步要做什么。2.1 为什么claude not found报错永远排在热搜第一搜索热词里“claude 不是内部或外部命令”高居榜首。这根本不是安装问题而是对 CLI 运行机制的彻底误解。CLI 不是“装上就能用”的应用它是一个环境变量契约。当你在终端执行npm install -g claude-code-cli实际发生的是npm 将可执行文件claude放入全局bin目录如/usr/local/bin/claude终端启动时会读取 shell 配置文件.zshrc/.bashrc/PowerShell profile将PATH环境变量指向这个bin目录当你输入claudeshell 在PATH列表中逐个查找找到后加载执行。所以command not found的真实含义是你的当前终端会话压根不知道claude这个命令存在。解决方案从来不是“重装”而是三步诊断提示在 macOS/Linux 终端运行echo $PATH | tr : \n | grep -i bin检查输出中是否包含/usr/local/bin或~/.npm-global/bin在 Windows PowerShell运行$env:PATH -split ; | Select-String npm。如果没出现说明 PATH 未生效。场景一新装完 CLI新开终端才生效这是最常见情况。npm install -g修改的是 shell 配置文件但当前终端进程已启动不会自动 reload。必须新开一个终端窗口或手动执行source ~/.zshrcmacOS/Linux或. $PROFILEPowerShell。场景二Windows 上用 CMD 而非 PowerShellnpm 全局安装默认将路径写入 PowerShell 的$PROFILECMD 完全读不到。解决方案只有两个永远用 PowerShell 运行 CLI或在 CMD 中手动set PATH%PATH%;C:\Users\YourName\AppData\Roaming\npm临时生效。场景三企业环境禁用了全局安装很多公司策略禁止npm install -g要求用npx claude-code-cli代替。npx会临时下载并执行不依赖 PATH但每次都会网络请求速度慢。此时应联系 IT 部署私有 npm registry或改用桌面端——因为桌面端的 CLI 引擎是内置的不走 PATH 查找。这背后是 CLI 的核心信条它拒绝承担环境管理责任。它假设你对自己的系统有完全掌控力。一旦你把 CLI 当成“点开即用”的软件这个契约就崩了。2.2--dangerously-skip-permissions不是“跳过确认”而是“放弃监护权”另一个高频报错是You are using an unsupported command-line flag: --unsafely。注意错误信息里写的是--unsafely但你在文档里查到的是--dangerously-skip-permissions。这并非笔误而是 Anthropic 故意为之的设计语言CLI 用参数名本身作为安全警示牌。--dangerously-skip-permissions的真实作用是关闭 CLI 的“沙箱护栏”。我们来看一个具体案例# 场景需要批量重命名项目中所有 .js 文件为 .ts claude code \ --project ./my-app \ --prompt 将 src/ 下所有 .js 文件重命名为 .ts保留原内容 \ --permission-mode auto-accept-edits执行后CLI 会列出所有待重命名文件等待你输入y确认。这是auto-accept-edits模式——它自动接受mv、mkdir等文件系统命令但对git commit、npm publish等高危操作仍会拦截。而加上--dangerously-skip-permissionsclaude code \ --project ./my-app \ --prompt 将 src/ 下所有 .js 文件重命名为 .ts保留原内容 \ --permission-mode auto-accept-edits \ --dangerously-skip-permissions这时 CLI 会直接执行mv src/file.js src/file.ts且不会向你展示任何 diff不记录任何操作日志不提供回滚路径。它变成了一个纯粹的命令转发器等同于你手动在终端敲find ./src -name *.js -exec bash -c mv $1 ${1%.js}.ts _ {} \;。注意--dangerously-skip-permissions在桌面端对应的是“绕过权限模式”但它被刻意放在“设置 → Claude Code”深层菜单里并要求二次确认。这是因为桌面端默认承载了“可视化审查”这一关键安全环节而 CLI 没有。CLI 的安全模型是信任由你赋予风险由你承担。所以当你看到“unsafely”报错不要急着谷歌“怎么修复”先问自己我是否真的需要放弃所有操作可见性如果答案是否定的那就用--permission-mode ask默认模式老老实实看 diff、点确认。CLI 的“危险”参数本质是给你一把没有保险栓的枪——它不阻止你扣扳机但也不会替你瞄准。2.3 CLI 的不可替代性当“自动化”成为刚需时CLI 的真正价值从来不在单次交互而在它能被嵌入到任何自动化流程中。这是我用 CLI 完成的三个真实场景场景一Git Hook 自动化代码审查在.git/hooks/pre-push中加入#!/bin/bash echo Running Claude Code review before push... claude code \ --project $PWD \ --prompt Review all staged changes for security vulnerabilities and logic errors. Output only a JSON array of {file, line, message}. \ --output-format json /tmp/claude-review.json if [ -s /tmp/claude-review.json ]; then echo ⚠️ Claude found issues: cat /tmp/claude-review.json | jq .[] | \(.file):\(.line) - \(.message) exit 1 fi每次git push前自动触发一次轻量级审查。桌面端无法做到这点因为它没有--output-format json这种结构化输出能力。场景二CI 流水线中的“智能重试”在 GitHub Actions 的test.yml中- name: Run tests with Claude-assisted debug if: ${{ failure() }} run: | claude code \ --project $GITHUB_WORKSPACE \ --prompt The test suite failed with error: ${{ steps.test.outputs.error }}. Analyze the failing test file and suggest one minimal fix to make it pass. \ --permission-mode auto-accept-edits npm test当测试失败时自动让 Claude 分析错误日志修改代码再重试。这依赖 CLI 的--permission-mode auto-accept-edits和静默执行能力桌面端的 GUI 交互会阻塞整个流水线。场景三跨平台构建脚本写一个build.sh#!/bin/bash # 根据当前 OS 自动选择模型和工具链 if [[ $OSTYPE darwin* ]]; then MODELopus TOOLCHAINxcodebuild elif [[ $OSTYPE linux-gnu* ]]; then MODELsonnet TOOLCHAINmake else MODELhaiku TOOLCHAINmsbuild fi claude code \ --project ./app \ --model $MODEL \ --prompt Build the app using $TOOLCHAIN and package for distribution. \ --add-dir ./config/prodCLI 的参数化能力让它天然适配 DevOps 场景。桌面端的“模型下拉菜单”再方便也无法在脚本里动态切换。CLI 的终极定位是成为你工程体系里的一个标准 Unix 工具——它应该像grep、sed、curl一样可以被管道、被重定向、被条件判断。一旦你开始用它做这些事你就不会再纠结“它为什么没有桌面端的预览窗格”因为你已经把它用在了它最该在的地方。3. 桌面端的隐藏协议一个“有状态、可感知、可编排”的协作空间如果说 CLI 是一台 CNC 机床那么桌面端就是一座智能工厂。它不只执行命令还管理空间、协调资源、记住偏好、预测意图。但绝大多数人打开桌面端做的第一件事却是——关掉所有窗格只留一个聊天框然后开始打字活脱脱一个“带图形界面的 CLI”。这就像开着特斯拉去停车场画方格完全浪费了它的自动驾驶能力。3.1 “侧边栏会话”不是“多开窗口”而是“Git Worktree 级别的上下文隔离”桌面端侧边栏里那些并排的会话图标90% 的用户以为只是“多个聊天窗口”。错。它们是基于 Git Worktree 的完整项目副本每个会话都拥有独立的分支、独立的文件系统快照、独立的终端环境。我们来做一个实验在桌面端新建一个会话选择项目my-app模型选sonnet让 Claude 修改src/App.js添加一行console.log(from session A);不提交直接新建第二个会话同样选择my-app在第二个会话里让 Claude 修改同一文件添加console.log(from session B);。此时打开终端运行cd my-app git worktree list # 输出类似 # /path/to/my-app abcd1234 [main] # /path/to/my-app/.claude/worktrees/session-A efgh5678 [claude-session-A] # /path/to/my-app/.claude/worktrees/session-B ijkl9012 [claude-session-B]你会发现两个会话的操作互不影响。Session A 的修改只存在于claude-session-A分支Session B 的修改只在claude-session-B分支。这就是为什么你可以同时让一个会话做“前端样式调整”另一个会话做“后端 API 重构”完全不用担心冲突。提示桌面端默认将 worktree 存放在project-root/.claude/worktrees/。你可以在“设置 → Claude Code”里修改位置甚至设置分支前缀如claude-让所有自动生成的分支一目了然。这种隔离的代价是什么是磁盘空间。每个 worktree 都是完整项目副本硬链接除外。但收益是巨大的它让你摆脱了“先切分支、再改代码、再切回来”的心智负担。你不再需要记住“我上次在这个功能上改到哪了”因为桌面端已经用一个会话图标帮你固化了那个状态。而 CLI 的--worktree参数只是模拟了这个行为它不会自动创建 worktree需要你手动git worktree add。桌面端把这套 Git 最佳实践封装成了一个点击即用的抽象层。3.2 “预览窗格”不是“浏览器”而是“Claude 的自我验证闭环”桌面端最被低估的功能是预览窗格Preview Pane。很多人把它当成一个简单的localhost:3000查看器但它的真正价值在于它让 Claude 从“代码生成器”升级为“可验证的开发者”。当你在会话中说“帮我修复登录页的表单验证”Claude 不仅会修改Login.jsx还会自动读取项目配置package.json、vite.config.js识别开发服务器命令npm run dev在集成终端中执行该命令启动服务打开预览窗格加载http://localhost:3000/login自动截图、检查 DOM、填充表单、提交、验证返回结果如果验证失败它会分析错误日志再次修改代码重启服务重新验证——直到成功。这个过程CLI 无法完成因为它没有“视觉反馈”能力。CLI 可以curl http://localhost:3000/login但无法判断“提交按钮是否变灰”、“错误提示是否显示在正确位置”。而桌面端的预览窗格通过嵌入式 Chromium给了 Claude 一双眼睛。更关键的是这个验证过程是可配置、可复现的。所有配置都存放在项目根目录的.claude/launch.json中。比如你的 Next.js 项目需要{ version: 0.0.1, configurations: [ { name: frontend, runtimeExecutable: yarn, runtimeArgs: [dev], port: 3000, autoPort: true } ] }当你把这个文件提交到 Git所有团队成员打开桌面端预览行为完全一致。而 CLI 用户只能靠文档约定“大家都要用yarn dev”一旦有人手误npm run dev验证就失效了。注意预览的自动验证autoVerify默认开启。如果你想关闭只需在.claude/launch.json中添加autoVerify: false。但建议只在调试时关闭——因为验证失败时Claude 会给出比终端日志更直观的错误描述如“表单提交后页面未跳转检查onSubmit事件是否被阻止”。3.3 “权限模式”不是“开关”而是“人机协作的信任光谱”桌面端右上角的权限模式下拉菜单从“询问权限”到“绕过权限”看起来像一个简单的滑块。但它的设计揭示了 Anthropic 对人机协作的深刻理解信任不是二元的是/否而是一个连续的光谱需要根据任务复杂度动态调节。我们用一个真实重构任务来演示任务将一个 React 类组件UserProfile.js迁移到函数组件 Hooks。阶段一Plan Mode计划模式切换到 Plan Mode输入“将UserProfile.js迁移到函数组件使用useState管理user和loading状态用useEffect替代componentDidMount。”Claude 不会直接改代码而是输出一个详细计划创建新文件UserProfile.jsx复制原组件的render()方法内容将this.state.user替换为const [user, setUser] useState(null)将componentDidMount替换为useEffect(() { fetchUser(); }, []);删除UserProfile.js。此时你可以审查这个计划确认逻辑无误再进入下一阶段。阶段二Auto-accept Edits自动接受编辑切换到此模式输入“按上述计划执行迁移。”Claude 会自动创建新文件、修改内容、删除旧文件但对git commit、npm test等命令仍会弹窗确认。这是你对“代码变更”给予信任但对“项目操作”保留控制。阶段三Ask Permission询问权限如果你不确定useEffect的依赖数组是否正确可以切回此模式让 Claude 每一步都弹窗“将第 12 行useEffect(() {...}, [])的空数组改为[userId]是否确认”这是最高粒度的控制适合学习或高风险重构。而 CLI 的--permission-mode只有ask、auto-accept-edits、dont-ask三种缺少 Plan Mode 这个“先思考、再行动”的中间态。Plan Mode 是桌面端独有的认知缓冲区它把“AI 生成代码”这个黑盒拆解成了“人类审计划 AI 执行”的白盒流程。提示Plan Mode 在远程会话中不可用因为远程环境默认沙箱化无需额外防护。这也印证了桌面端的设计哲学——本地会话的信任光谱是为你的物理机器量身定制的。4. 关键决策树什么场景该用 CLI什么场景该用桌面端理论讲得再多不如一张清晰的决策地图。以下是我根据上百次真实项目经验总结的“CLAUDE CODE 使用决策树”覆盖 95% 的日常开发场景。它不告诉你“哪个更好”而是告诉你“此刻该选哪个”。4.1 选 CLI 的 5 个铁律场景当你遇到以下任一情况请立刻关闭桌面端打开终端场景为什么 CLI 是唯一解实操命令示例需要结构化输出供其他程序消费桌面端所有输出都是 UI 渲染无法被jq、awk、grep处理。CLI 的--output-format json是唯一标准接口。claude code --project ./api --prompt List all unused environment variables --output-format json | jq .unused[]必须嵌入到自动化流程CI/CD/Git Hook桌面端是交互式 GUI会阻塞流水线。CLI 是纯命令行支持--quiet静默模式、--timeout 300超时控制。claude code --project $PWD --prompt Generate changelog for last 5 commits --output-format markdown CHANGELOG.md跨多个项目批量执行相同操作桌面端一次只能处理一个项目。CLI 可用for循环或xargs并行处理。find ./microservices -name package.json -execdir claude code --prompt Upgrade all dependencies to latest major \;需要与现有 CLI 生态无缝集成你想用fzf模糊搜索文件后传给 Claude或用ripgrep找到错误日志再让 Claude 分析。CLI 天然支持管道和重定向。rg TypeError ./logs | claude code --prompt Analyze this error log and suggest fix在无 GUI 环境Linux 服务器、Docker 容器、WSL工作桌面端官方声明“Linux 不支持”而 CLI 是 Node.js 应用只要node和npm存在即可运行。docker run -it --rm -v $(pwd):/workspace node:18 npm install -g claude-code-cli claude code --project /workspace ...注意以上场景中如果你强行用桌面端要么无法实现如结构化输出要么需要写大量胶水代码如用 AutoHotKey 模拟鼠标点击要么根本不可靠如在 Docker 中启动 GUI。CLI 在这里不是“备选”而是“基础设施”。4.2 选桌面端的 5 个黄金场景当你进入以下情境请果断退出终端启动桌面端场景为什么桌面端不可替代关键操作路径从零开始构建一个功能模块含 UI、API、测试CLI 无法同时管理多个文件的协同修改、无法实时预览效果、无法可视化 diff。桌面端的“四宫格布局”聊天diff预览终端是唯一能承载完整开发流的界面。新建会话 → 拖拽窗格成四宫格 → 输入“创建一个用户注册表单包含邮箱验证和密码强度检查” → 让 Claude 自动启动预览并验证需要多人协作评审一个 PRCLI 生成的 diff 是文本流难以标注。桌面端的 diff 视图支持逐行评论、截图批注、提及同事且所有评论直接关联到 Git 分支。在 diff 视图中点击某行 → 输入评论 →CmdEnter提交 → Claude 自动将评论同步到 GitHub PR 的对应行调试一个涉及 GUI 交互的 Bug如按钮点击无响应CLI 无法感知屏幕内容。桌面端的“计算机使用”功能需 Pro 计划可让 Claude 真实操作你的鼠标键盘在浏览器中重现问题。设置 → 常规 → 开启“计算机使用” → 在会话中输入“在 Chrome 中打开 localhost:3000点击注册按钮观察控制台报错”需要长期记忆和上下文沉淀如项目规范、技术决策CLI 每次会话都是全新上下文。桌面端的CLAUDE.md文件会自动记录所有会话的指令、Claude 的回复、你确认的修改形成可搜索的知识库。在项目根目录创建CLAUDE.md→ 每次会话后Claude 会自动追加## [日期] [任务摘要]区块包含完整对话和 diff进行跨技术栈整合如前端调用 Python APICLI 无法同时管理不同语言的环境。桌面端支持 SSH 会话可让你在一个界面里左边编辑 React 代码右边通过 SSH 连接到 Ubuntu 服务器运行 Python Flask中间用预览窗格查看整合效果。启动会话 → 环境选择 “SSH” → 配置userubuntu-server→ 在集成终端中运行python3 app.py→ 预览窗格访问http://ubuntu-server:5000/api提示桌面端的“Dispatch”功能手机端发送任务到桌面端执行是上述场景的放大器。比如你在地铁上想到“需要优化首页加载速度”用手机 Claude App 发送任务到工位后桌面端已自动创建会话预览窗格正显示 Lighthouse 报告终端里webpack-bundle-analyzer已运行完毕。4.3 混合工作流CLI 和桌面端如何“无缝接力”最高效的用法不是非此即彼而是让两者像齿轮一样咬合。我的标准工作流是启动阶段用 CLI 快速初始化# 用 CLI 创建标准化项目结构 claude code \ --project ./new-project \ --prompt Initialize a Next.js app with Tailwind CSS, ESLint, and Prettier. Add a /api/hello route. \ --permission-mode auto-accept-edits开发阶段切桌面端深度协作启动桌面端打开./new-project利用四宫格布局完成核心功能开发、实时预览、PR 生成。交付阶段用 CLI 自动化收尾# 用 CLI 生成发布包和文档 claude code \ --project ./new-project \ --prompt Generate a release checklist, update CHANGELOG.md, and create a GitHub release draft. \ --output-format markdown RELEASE-DRAFT.md关键衔接点是CLAUDE.md和.claude/launch.json。这两个文件被 CLI 和桌面端共同读写确保配置和记忆同步。你不需要手动复制粘贴它们天然就是同一个数据源。经验在团队中推行此混合工作流时我强制要求所有项目根目录必须包含.claude/launch.json和CLAUDE.md。新成员只需git clonenpm install然后双击桌面端图标所有开发环境、验证规则、项目规范就自动加载。CLI 则作为“幕后运维员”处理那些不该出现在 GUI 中的脏活累活。5. 那些没人告诉你的“反直觉”细节避开最深的坑最后分享几个我在实战中踩过、查遍文档才搞懂的“反直觉”细节。它们不会出现在官网教程里但每一个都曾让我卡住数小时。5.1 “模型切换”不是实时生效而是会话级快照你以为在会话中点击模型下拉菜单从sonnet切到opusClaude 就立刻用更强模型思考错。模型选择只在会话启动时生效后续切换只影响新消息的推理不改变已有上下文的模型。实测案例新建会话选sonnet让 Claude 分析一个 500 行的 Python 脚本它花了 12 秒给出中等深度的建议然后切换模型到opus输入“再分析一遍这次重点看内存泄漏风险。”结果Claude 依然用sonnet的上下文因为初始会话是sonnet只是新消息用opus回复但分析深度受限于初始模型的 token 限制。正确做法如果需要全程用opus必须新建会话并在启动时就选择opus。或者在初始会话中用/compact命令清空上下文再切换模型——但这会丢失之前的对话历史。5.2 “mention 文件”在远程会话中完全失效但有替代方案桌面端文档说“mention 文件在远程会话中不可用。” 这句话很误导。它不是“不支持”而是远程会话的文件系统是隔离的mention 无法穿透网络边界。但你仍有办法方案一用附加文件功能点击提示框旁的→Attach files→ 选择本地文件PDF、图片、文本。Claude 会将其内容作为上下文读取。这是最常用、最可靠的方式。方案二用Add directory添加远程仓库在远程会话启动时点击存储库 pill 旁的添加 GitHub 仓库 URL。Claude 会克隆整个仓库到远程环境之后你就可以像操作本地文件一样mention了。方案三用 CLI 作为桥梁在本地 CLI 中运行claude code --project ./local --prompt Read README.md and summarize key points --output-format json summary.json然后把summary.json附加到桌面端远程会话。5.3 “计算机使用”的权限层级远比你想象的精细桌面端的“计算机使用”常被误解为“给 Claude 全盘控制权”。实际上Anthropic 设计了一套极细的权限分层应用类别Claude 可操作范围典型场景如何触发仅查看截图、OCR 文字、分析 DOM浏览器、Figma、NotionClaude 自动识别无需你授权仅点击点击、滚动、切换 TabVS Code、Terminal、Finder第一次操作时弹窗选择“允许此会话”完全控制点击、输入文字、拖拽、快捷键CmdC/VChrome、Slack、系统设置需在“设置 → 常规”中手动开启“计算机使用”并授予 macOS 辅助功能权限最关键的细节“完全控制”权限不会自动授予。即使你开启了计算机使用当 Claude 首次尝试在 Chrome 中输入网址时它会弹出一个带警告的授权框“Claude 将控制 Chrome可能访问敏感信息。是否允许” 你必须点击“允许此会话”它才能操作。而且这个授权只对当前会话有效下次新会话需重新授权。经验我曾因忘记授权让 Claude 在 Chrome 中“打开 localhost:3000”结果它一直卡在地址栏光标闪烁却不输入。检查授权框才发现被我误点了“拒绝”。解决方法在会话中输入/permissionsCLI 命令桌面端不支持或直接重启会话。5.4 “Worktree” 的磁盘空间陷阱如何避免项目体积爆炸桌面端的 Git Worktree 隔离虽好但有个隐藏成本每个 worktree 都是完整项目副本包括node_modules。一个 500MB 的项目10 个会话就是 5GB。解决方案有三方案一启用core.sparseCheckout推荐在项目根目录运行git config core.sparseCheckout true echo src/* .git/info/sparse-checkout echo public/* .git/info/sparse-checkout git read-tree -m -u HEAD这样 worktree 只检出src和public目录node_modules不会被复制。方案二在.claude/settings.json中配置添加{ worktree: { exclude: [node_modules, dist, .git] } }桌面端会在创建 worktree 时自动忽略这些目录。方案三定期清理在“设置 → Claude Code”中开启“自动存档”或手动悬停会话图标点击 ️。存档的会话会自动git worktree remove并删除文件夹。我个人习惯是日常开发用桌面端每天下班前运行claude code --cleanupCLI 命令清理所有未存档 worktree。CLI 的--cleanup会扫描.claude/worktrees/删除超过 7 天未访问的 worktree比手动操作可靠得多。我最初以为搞懂 CLI 和桌面端的区别就是背熟参数和菜单。后来才明白真正的分水岭在于你是否愿意承认自己不是一个在“用工具”而是在“参与设计一个人机协作的新操作系统”。CLI 的冷峻契约桌面端的温润协议都不是偶然设计而是 Anthropic 对“开发者心智模型”的一次精准建模。所以别再问“哪个更好用”。下次打开终端或桌面端前先问自己一句“此刻我需要一个绝对可靠的执行者还是一个能和我并肩作战的协作者”答案自然浮现。