为什么命令行形态值得用：与 IDE 插件形态的分工

先破除一个偏见

"都 2026 年了还用终端？"这是我推荐 Claude Code 时最常听到的反驳。持有这种想法的朋友，通常把终端理解成了"落后于 IDE 的古老界面"。但换个角度看：终端是一个通用执行环境——你的构建工具、测试框架、Git、包管理器、部署脚本、SSH，全都以终端为一等公民。一个 Agent 想真正"替你干活"，它必须能执行命令，而终端就是命令的原生栖息地。

Claude Code 遵循 Unix 哲学，可组合（composable）。这意味着它能接管道、能进脚本、能上 CI——这些是 IDE 插件形态天生做不到或做不好的。反过来，IDE 插件的可视化能力也是终端给不了的。本章把这笔账算清楚，帮你建立"混合使用"的决策框架，而不是站队。

还有一层隐性优势经常被忽略：终端形态的训练成本会复利。你在终端里学会的每一个技巧——管道、脚本、参数——都不会过时，而且同时强化了你的 shell 功底；而某个编辑器插件里的花式操作，换个编辑器就清零。对一个打算干十年开发的工程师来说，这笔账不难算。

终端形态的五个独有优势

1. 可管道化。 任何命令的输出都能直接喂给它，这是最容易被低估的能力：

# 分析最近的错误日志，有异常就提醒你
tail -200 app.log | claude -p "检查有没有异常，有就总结原因"

# 对本次改动的文件做安全审查
git diff main --name-only | claude -p "review 这些改动里的安全问题"

# 一次性任务，跑完就退出
claude -p "解释 src/utils/date.ts 这个函数的作用"

-p（print 模式）让 Claude Code 变成了一个标准的 Unix 工具：输入、输出、退出码齐全，grep 能接它，cron 能调它，CI 能跑它。这层能力在"无头模式与 CI"那一章会展开成完整玩法。

2. 远程可达。 只要能 SSH 到服务器，就能用 Claude Code。你可以在跳板机上直接让它排查生产问题（当然要配合权限管控），不需要先把代码拉到本地再打开某个编辑器。容器里、开发机上、嵌入式交叉编译环境里，只要有 shell 就有它的工位。

3. 与 shell 生态无缝。 别名、函数、脚本都能包一层。比如：

# 写进 .bashrc / .zshrc
alias askc='claude -p'          # 快速提问
alias cr='claude -p "review 我工作区里未提交的改动，按严重程度排序"'

从此你自定义了一个"审查"命令，成本一行。这种把 AI 缝进个人工作流的自由度，是图形界面给不了的。

4. 资源占用轻。 没有语言服务器、没有索引后台、没有 UI 渲染，一个二进制加一个终端窗口。老机器、容器、多人共用的开发服务器上跑都不心疼。

5. 会话可复现、可接管。 claude -c 接着上一次聊，claude -r 从列表里挑一次恢复，所有对话落在本地 JSONL 文件里。命令行会话的生命周期完全由你掌控，还能导出成文本归档。

IDE 插件的价值：可视化与行内反馈

说完终端的好，也要公平地讲 IDE 插件（VS Code / JetBrains）的价值，否则你就错过了组合打法：

• 行内 diff 审阅：改动直接显示在编辑器里，逐行接受或拒绝，比终端里看 diff 舒服；
• 选中即上下文：选中一段代码问"这段什么意思"，不用描述文件路径；
• @ 文件引用与计划审阅：在面板里引用文件、审阅执行计划；
• 调试联动：编辑器的断点、报错面板和 AI 会话在同一屏幕。

两个形态读的是同一套配置（CLAUDE.md、settings.json、MCP 服务器都通用），所以不存在"选边站"，只存在"什么时候用哪个"。

分工决策表

下面这张表是我用了大半年后总结的分工，供参考：

一句话总结分工：编辑器适合"你在写、AI 帮"，终端适合"AI 写、你看"。 工作量越大的任务，越应该交给后者。

从 IDE 用户的视角迁移过来

如果你是编辑器重度用户，刚开始用终端形态会有几个不适应，提前打个预防针：

• 没有"光标"概念。你不说"这里"，要说"src/payments/ 里的退款逻辑"。一开始会觉得啰嗦，习惯后发现这反而逼你把任务描述得更清楚——而清晰的任务描述本来就是用好一切 AI 编程工具的前提；
• diff 是文本流。如果实在不适应，可以装 VS Code 插件配合用：终端里跑 Agent，改动在编辑器里审；
• 键盘流更彻底。Shift+Tab 切权限模式、Esc 打断、Ctrl+R 搜历史，这些肌肉记忆一周就形成了；
• 输出是流式的。它会边干活边滚动输出，第一次看会觉得眼花。其实你只需要扫"当前动作"那一行，其他的等最终汇报。

一个真实的下午（混合形态）

14:00 终端: claude → 计划模式里让它规划订单模块重构方案
14:20 批准计划，切 acceptEdits，它自己改了 12 个文件
14:50 VS Code: 逐个文件看 diff，改了两处命名
15:00 终端: "跑全量测试"，失败 1 个，它自己修好了
15:10 终端: "写提交信息并提交，然后开 PR"

注意整个过程终端和编辑器交替出场，各干各擅长的事。没有谁取代谁，只有谁在什么时候出场。

会话控制的命令面

终端形态下，会话的进入与恢复都是命令行参数，这套接口值得背下来：

claude                # 交互模式，从头开始
claude "修这个报错"   # 交互模式 + 初始任务
claude -p "问题"      # 一次性回答，输出后退出（无头模式的基础）
claude -c             # 继续当前目录最近一次会话
claude -r             # 弹出会话列表，挑一个恢复

-c 和 -r 是"接力棒"：上午跑一半的重构，下午一条 claude -c 继续干，上下文原样接上。配合 --resume 加会话 ID 可以在脚本里精确恢复某一次对话。这些参数的完整清单在会话管理那一章整理成表。

退出和中断也很干净：Ctrl+C 中断当前动作，空闲时按两次退出；Ctrl+D 按两次退出。会话数据都落在本地，不怕丢。

什么情况下终端形态不是最优

诚实地说也有短板：

• 重度可视化调试（断点单步、内存视图）——编辑器强项；
• UI 走查——它看不到像素，浏览器集成和截图是辅助手段；
• 团队里全是编辑器原教旨主义者——习惯也是生产力，别硬掰。

终端老手的三个加分习惯

习惯一：把常用问法固化成脚本。 团队里如果有固定的审查口径，写成一个 shell 脚本放进仓库，谁都能跑：

#!/usr/bin/env bash
# scripts/ai-review.sh — 对当前分支的改动做一次预审
git diff main --name-only | claude -p \
  "逐个文件 review 以下改动，重点看：空指针、事务边界、日志缺失。按严重程度输出。"

习惯二：输出重定向归档。 -p 模式的输出可以落文件，留档或贴给同事都方便：

claude -p "总结这个模块的对外 API" > docs/api-summary.md

习惯三：环境即配置。 代理、密钥、模型偏好在终端里可以用环境变量表达，同一套脚本在本地、CI、服务器上行为一致——这是图形工具永远给不了的可复制性。

工具的意义是降低摩擦，哪个顺手用哪个。想看 AI 编辑器这一支的完整玩法，可以对照本站《Cursor 高效技巧》：Cursor 技巧书和《Trae 进阶技巧》：Trae 技巧书。命令与参数的权威定义，以官方 CLI 文档为准。

本章由 WorkBuddy 原创整理，事实性内容参考 Claude Code 官方文档。