Codex 和 Claude Code CLI 常用快捷键：终端不是退路，是编程的主场

很多人第一次接触 AI 编程工具，会先找 VS Code 插件、JetBrains 插件，或者干脆在网页里复制粘贴。这个路径当然能用，但用久了会发现一个问题：真正写代码的时候，最频繁发生的动作并不是“聊天”，而是读文件、改文件、跑测试、看日志、回滚思路、继续追问。

这些动作本来就发生在终端里。

所以我现在更倾向于把 Codex CLI 和 Claude Code CLI 当成主入口，而不是把它们当成编辑器旁边的聊天框。终端有一个很朴素的优点：它离项目最近。当前目录、环境变量、包管理器、测试命令、Git 状态、日志输出，全都在同一个平面里。AI 助手在这里工作，不需要一层又一层 UI 适配。

本文整理的是两个工具在终端交互里最常用的快捷键。重复的键位只列一次，但会标明 Codex 和 Claude Code 的行为差异；只属于其中一个工具的，会单独列出来。

先记这一组：两个 CLI 都常见

快捷键	Codex CLI	Claude Code CLI	我的使用建议
Ctrl+C	退出交互会话，或中断当前操作	中断当前操作；空闲时第一次清空输入，第二次退出	最重要的“刹车键”。AI 正在跑偏时，不要等它说完，直接打断
Ctrl+L	清屏，但不清会话	重绘屏幕，修复终端显示错乱	终端输出花了、滚动乱了，用它恢复视野
Ctrl+O	复制最近一次 Codex 输出为 Markdown	打开/关闭 transcript viewer，查看更完整的工具调用和执行细节	同一个键位，两边含义不同。Codex 偏“复制结果”，Claude 偏“查看过程”
Ctrl+R	搜索 prompt 历史	反向搜索历史命令/提示	复用旧 prompt 很有用，尤其是测试、审稿、重构类任务
Up / Down	在输入历史里切换草稿	光标移动或历史导航，取决于当前输入是否跨行	别重复手打长提示，历史记录就是第二块剪贴板
Tab	Codex 正在运行时，可排队下一条消息；也常用于补全/选择	接受提示建议；在历史搜索里可接受当前匹配	AI 还没跑完时，先把下一步排上，节奏会顺很多
Esc	取消搜索、关闭浮层，部分场景用于退出当前状态	中断 Claude；双击 Esc Esc 可清空输入或打开 rewind 菜单	Esc 是终端里的“退出当前层级”，比鼠标找关闭按钮快
/	打开 slash command 入口	打开 command / skill 入口	会用 / 才算开始进入 CLI 的工作流
!	直接输入 shell 命令，让命令输出进入上下文	进入 shell mode，直接执行命令并把输出放进上下文	小命令别让 AI 转述，直接 ! npm test、! pnpm lint
@	文件路径提及和补全	文件路径提及和补全	问具体文件时一定用 @，不要让模型猜路径

图片粘贴：Alt+V 值得单独记

Claude Code 官方文档明确写了：在 Windows 和 WSL 下，可以用 Alt+V 从剪贴板粘贴图片；在部分终端里也可以用 Ctrl+V 或 macOS iTerm2 的 Cmd+V。

Codex CLI 的官方功能页写的是可以把 screenshot / image 直接放进 composer；我本机安装包里的快捷键提示也能看到 “paste images” 相关入口。实际在 Windows 终端里，Alt+V 是最值得优先尝试的图片粘贴键，因为 Ctrl+V 经常会被终端、Shell 或编辑控件截走。

换句话说，记法很简单：

Windows / WSL 里给 CLI 粘贴图片：先试 Alt+V。

这个快捷键很实用。你可以把报错截图、UI 截图、设计稿局部、公式截图直接丢进终端，然后让 AI 结合当前仓库处理。这里的体验和网页聊天不同：截图进入的是同一个开发上下文。
但是调用的大模型必须支持多模态，否则CLI不能识图

Codex CLI 单独常用的快捷键

快捷键	作用	场景
Ctrl+O	复制最近一次 Codex 输出	写完方案、总结、Review 结论后，直接复制成 Markdown
Ctrl+N	在 Codex Cloud task 视图里切换 attempts	多次尝试同一任务时，对比不同 attempt
Shift+Enter	换行输入	写长 prompt、贴日志、贴代码片段
Ctrl+G	打开外部编辑器编辑当前草稿	prompt 太长时，不要在单行输入框里硬写
Ctrl+T	查看 transcript / 终端记录相关入口	想回看上下文、过程或终端输出时使用
Esc Esc	退出/关闭某些浮层或状态	搜索、选择器、覆盖层里常用

Codex 还有一个很工程化的点：它支持 keymap 自定义。也就是说，快捷键不是只能背默认值；如果你长期用某种终端流派，可以把动作映射成自己习惯的键位。我的建议是先别急着改，先用默认键位一周，知道哪些动作真的高频以后再改。

Claude Code 单独常用的快捷键

Claude Code 的交互模式文档写得更细，尤其是文本编辑和 transcript viewer。下面这组是我认为真正值得记的。

快捷键	作用	场景
Ctrl+D	退出 Claude Code 会话	类似 EOF，结束当前交互
Ctrl+G 或 Ctrl+X Ctrl+E	用默认文本编辑器编辑当前 prompt	写复杂需求、改长提示
Ctrl+B	把正在运行的 bash 命令或 agent 放到后台	跑测试、构建、dev server 时继续对话
Ctrl+T	显示/隐藏 task list	Claude 拆多步任务时，看当前进度
Shift+Tab 或 Alt+M	切换 permission mode	在 default、acceptEdits、plan 等模式之间切换
Alt+P	切换模型	不清空当前 prompt 的情况下换模型
Alt+T	开关 extended thinking	需要更强推理时打开，不需要时关掉省时间
Alt+O	开关 fast mode	轻量任务优先速度
Ctrl+A	光标到当前行开头	编辑长 prompt
Ctrl+E	光标到当前行末尾	编辑长 prompt
Ctrl+K	删除到行尾	快速改写后半句
Ctrl+U	删除到行首	快速重写前半句
Ctrl+W	删除前一个单词	改英文命令、变量名很顺手
Ctrl+Y	粘贴刚删除的文本	配合 Ctrl+K / Ctrl+U
Alt+B / Alt+F	按单词后退/前进	比方向键快很多
Ctrl+J	换行输入	所有终端基本都能用
Shift+Enter	换行输入	Windows Terminal、iTerm2、WezTerm、Kitty 等终端常见可用
\ + Enter	换行输入	兼容性强，适合终端不识别 Shift+Enter 时

Claude 的 transcript viewer 也有一组值得记：

快捷键	作用
?	显示快捷键帮助面板
{ / }	跳到上一条/下一条用户 prompt
Ctrl+E	切换显示全部内容
[	把完整对话写回终端原生 scrollback，方便用终端搜索
v	用 $VISUAL 或 $EDITOR 打开临时文件查看对话
q / Ctrl+C / Esc	退出 transcript view

如果你开启了 Vim editor mode，Claude Code 还支持不少 Vim 风格按键，例如 i、a、A、o、h/j/k/l、w、b、dd、yy、p、u 等。这个部分不建议所有人一上来就背。如果你本来就用 Vim，那它会很自然；如果你不用 Vim，先把上面的通用快捷键练熟就够了。

我自己的优先级

如果只给新手十个键，我会让他先记这些：

优先级	快捷键	原因
1	Ctrl+C	先学会打断，才敢让 AI 多做事
2	Ctrl+L	终端乱了不用慌
3	Ctrl+R	找回历史 prompt
4	Up / Down	复用上一轮输入
5	/	找到 CLI 内置能力
6	!	直接跑命令，不绕弯
7	@	精确引用文件
8	Tab	接受建议、排队下一步
9	Alt+V	粘贴截图给 AI
10	Ctrl+G	长 prompt 交给编辑器

这十个键背下来，基本就能从“会打开 CLI”变成“真的在终端里工作”。

为什么我更建议把 CLI 当主入口

Codex 和 Claude Code 都有编辑器里的使用方式。VS Code 插件很方便，能看当前文件、能点按钮、能在侧边栏里聊天，对刚开始的人确实友好。但如果长期把插件当主入口，很容易形成一种习惯：只在“编辑器能看见的那一小块代码”里使用 AI。

这会限制 AI 编程的上限。

插件最强的是“就地辅助”。比如解释当前函数、补一段代码、根据选中内容改写、处理一个很局部的 bug。这类场景里，图形界面确实舒服，点一下就能用，不需要记命令，也不需要切换窗口。

但真实项目的问题通常没这么干净。一个接口失败，原因可能在环境变量；一个测试挂了，原因可能在 fixture；一个构建错误，原因可能在锁文件、脚本、Node 版本、Python venv、系统依赖，甚至是终端里刚刚跑过的命令。插件如果只围着编辑器转，就很容易把问题看窄。

CLI 强的地方不是“更酷”，而是它天然站在工程现场：

维度	编辑器插件	CLI
上下文	主要围绕当前文件、选区、打开的 tab	当前目录、命令输出、日志、测试、脚本、文件系统都在同一层
执行命令	往往要借助集成终端或额外确认	命令就是工作流的一部分
复现问题	容易停留在“看代码猜原因”	可以直接跑、直接看输出、继续追
自动化	更偏交互式辅助	更容易进入脚本、管道、CI、本地工具链
注意力	容易被 UI 面板、按钮、提示分散	输入、输出、反馈都压缩在一个线性过程里
可迁移性	依赖编辑器和插件生态	换机器、换编辑器、远程服务器上都能继续用

还有一个细节很重要：CLI 会逼你把问题说清楚。插件里很多动作是点出来的，人容易偷懒；CLI 里你要写路径、写命令、写目标、写约束。这个过程本身就是工程思考。你越能清楚描述“我要改哪里、怎么验证、失败时看什么”，AI 的输出就越稳定。

我不是说不要用 VS Code 插件。我的建议是分工：

场景	更适合用什么
解释当前选中代码	插件
小范围补全、改一个函数	插件
看 diff 后做局部调整	插件或 CLI 都可以
跑测试、读日志、反复修 bug	CLI
从需求推进到实现再到验证	CLI
远程服务器、容器、SSH 环境	CLI
写脚本、批处理、迁移、重构	CLI

插件像副驾驶屏幕，CLI 更像驾驶位。副驾驶屏幕能提供信息，但方向盘、油门、刹车、仪表盘都在驾驶位。你如果一直只盯着侧边栏，会错过项目真正发生变化的地方。

所以我更愿意把插件当辅助，把 CLI 当主入口。先在 CLI 里完成任务闭环，再回到编辑器里做精修和阅读。这个顺序比“先在插件里聊，聊不动了再打开终端”更稳。

为什么我觉得终端才是编程的终点

这句话听起来有点绝对，但我的意思不是所有人都要抛弃 IDE。IDE 当然有价值，尤其是补全、跳转、调试、重构。但编程这件事最后总要回到几个更底层的问题：

代码在哪个目录？
依赖怎么装？
测试怎么跑？
日志怎么读？
环境变量怎么配？
失败以后怎么复现？
这些问题的答案大多数都在终端里。AI 编程工具越强，越不应该把人从终端带走，而应该让人更敢使用终端。因为终端不是“高手才用的黑窗口”，它是项目最真实的控制台。

Codex CLI 和 Claude Code CLI 的意义也在这里。它们不是把聊天框搬到命令行，而是把 AI 放进开发工作流本身。你可以让它读代码、改代码、跑命令、看输出、继续修，再让它解释为什么这么做。整个过程不需要离开当前目录。

快捷键只是入口。真正要练的是一种节奏：看到问题，定位文件，跑命令，给上下文，打断错误方向，继续推进。这个节奏一旦形成，终端就不再是工具列表里的一个选项，而是编程的主场。

参考资料

• OpenAI Codex CLI features: https://developers.openai.com/codex/cli/features
• Claude Code interactive mode: https://code.claude.com/docs/en/interactive-mode