05｜16 小时 Claude Code：界面、快捷键、Prompt 与日常工作流

14 · 交互界面与快捷键：把手放对地方

「欸，你这 Esc 按一下和按两下不一样？」

「对，差远了。按一下是踩刹车——让 Claude 停下来；按两下是倒车——把整段对话退回到上一个点。」

「……我之前一直当成一个键在用。」

说句实话，这是新手最容易搞混的一句话。Claude Code 的界面看着简单，就一个输入框加几行字，但底下藏着一整套键盘动作和特殊符号，知道的人用得飞起，不知道的人全靠鼠标和回车硬刚。我头两周也这样——有一回它顺着我一句模糊的话开始疯狂改一堆文件，我盯着满屏滚动的输出干等了快三分钟，眼看越改越偏，才猛地想起来「我按个 Esc 不就停了吗」，那一刻是真有点想抽自己。

这一篇不教你提需求（那是下一篇的事），只干一件事：让你把手放对地方。

看完这一篇，你会拿到：

• 一张「界面分区图」——输入框、状态行、模式提示分别在哪、看什么
• 一张能贴在显示器边上的高频快捷键速查表（Esc、Ctrl+C、Ctrl+D、Shift+Tab、上箭头……）
• 输入框里 @ ! 两个特殊前缀怎么用，外加 / 和 # 是干嘛的一句话交代
• 多行输入到底怎么打（这个坑太多人踩过）

01 先看懂这块屏：界面分成哪几部分

先给结论：Claude Code 的界面，你只需要认住三块——输入框、状态行、模式 / 权限提示。其他的滚动区域都是它在跟你「说话」，不用专门学。

类比：看汽车仪表盘。 你开车不用认全所有指示灯，但方向盘、挡位、油表这几样必须一眼能找到。界面也一样，认住主操作区和几个关键读数就能开走。

claude 启动后，从下往上大致是这么个布局：

• 输入框：最底下那一行，前面通常有个 > 提示符。这是你跟 Claude 说话的唯一入口，打字、贴代码、敲特殊命令全在这儿。
• 状态行 / 页脚：紧贴输入框上下的那几行小字。它会显示一些上下文信息——比如当前在哪个目录、有没有后台任务在跑、如果你这个分支有打开的 PR，官方文档说还会在页脚显示一个可点击的「PR #编号」链接，下划线颜色代表审查状态（绿=已批准、黄=待审、红=请求改动、灰=草稿）。
• 模式 / 权限提示：告诉你现在是「普通模式」还是「计划模式（plan）」还是「自动接受编辑（acceptEdits）」。这块最该盯——它决定了 Claude 接下来动手前问不问你。

这里有个新手特别容易慌的场景：屏幕突然变花、或者一半空白了。别以为崩了。官方给了个专门的键 Ctrl+L，强制重绘屏幕，输入和对话历史都保留。我自己最常撞上的就是在 tmux 里跑 Claude，切到别的窗口办点事、再切回来满屏乱码，第一次遇到我还真以为会话挂了、手都伸到重启上了，后来才知道一个 Ctrl+L 就干净了——现在屏幕一花我条件反射就按它。

💡 一句话总结：界面认住「输入框 + 状态行 + 模式提示」三块就够开工，屏幕花了别慌，Ctrl+L 重绘。

02 高频快捷键：像换挡和喇叭，熟了不用低头看

这是本篇的核心。

类比：车上的换挡杆和喇叭。 新手开车眼睛老往挡位上瞟，老司机手一搭就知道在几挡，喇叭抬手就按——因为这些动作进了肌肉记忆，不占注意力。快捷键就是这么个东西：头三天你得照着表按，按熟了，全程手不离键盘，眼睛只盯输出。

下面这张表，全部按官方 interactive-mode.md / keybindings.md 核对过，挑的都是新手每天都会用到的。建议你截图贴在显示器边上，用一周就记住了：

挑三个最容易被搞混的，单独说清楚：

Esc 一下 vs 两下：踩刹车还是倒车

官方文档把这俩写得明明白白，翻译成人话就是：

• Esc 按一下 = 踩刹车。Claude 正在回答或正在调工具，你一按它就停在当下，已经做完的部分会保留，你可以接着补一句重新指挥它。
• Esc 按两下 = 倒车。但有个前提——输入框必须是空的。空的时候连按两下 Esc，会弹出回退菜单（就是第 07 篇讲过的检查点 / 回溯），让你跳回之前的状态。

⚠️ 这是最坑的一点（官方明确写了）：如果输入框里有文字，连按两下 Esc 是「清空这段文字并存进历史草稿」，不是打开回退菜单。所以要回退，先把输入框清空。

新手很容易在这上面栽——输入框里打了半句话，想回退，狂按 Esc，结果文字没了、菜单也没出来，一脸懵。搞懂了就好办：先清空，再双击 Esc。

Ctrl+C vs Ctrl+D：清场还是退场

这俩都带点「停」的意思，但完全两码事：

• Ctrl+C = 清场不离场。有任务在跑就中断任务；没任务时第一次按清掉你输入框里的字，连按第二次才退出。
• Ctrl+D = 直接退场。一下就退出整个会话（它发的是 EOF 信号）。

顺带说个冷知识：这两个键是官方文档里明确标注的「保留快捷键」，硬编码、不能重新绑定（同一批的还有 Ctrl+M，因为它在终端里等于回车）。所以哪个终端、哪个系统，Ctrl+C / Ctrl+D 的行为都一致，放心用。

Shift+Tab：一键切换「问不问你」

Shift+Tab 大概是日常用得最多的快捷键，没有之一。它在几个权限模式之间循环：

• default（默认）：动手改文件前会停下问你。
• acceptEdits（自动接受编辑）：编辑类操作不再逐个问，提速用。
• plan（计划模式）：只出方案不动手，适合大改动前先对齐思路。
• 以及你额外开启的其他模式（如 auto / bypassPermissions）。

权限模式（Permission Mode），说白了就是「实习生动手前问不问你」的那个开关。

按一下 Shift+Tab 就在它们之间转圈，状态行会实时显示你当前在哪个模式。这套模式具体每个是干嘛、怎么配，第 20 篇「权限配置」专门讲，这里你只要记住：想换模式，Shift+Tab 转就完事了。

（一个平台差异：官方注明在某些 Windows 配置下（不支持 VT 模式的旧版终端、较老的 Node / Bun 运行时），这个键默认是 Alt+M 而不是 Shift+Tab，遇到不灵的换它试试。）

💡 一句话总结：Esc 一下刹车两下倒车、Ctrl+C 清场 Ctrl+D 退场、Shift+Tab 切「问不问你」——这四个焊进肌肉记忆，你就出师一半了。

03 输入框里的特殊前缀：@ 和 ! 是两把快刀

光会按键还不够。Claude Code 的输入框其实是「智能」的——某些符号打在开头，会触发完全不同的行为。官方在「快速命令」里列得很清楚，对新手最有用的是这两个：@ 和 !。

类比：手机输入法里打 @ 自动跳出联系人。 你不用记全名，敲个 @ 它就把候选人列出来给你选。@ 在 Claude Code 里也是这个味道，只不过选的是文件。

@：精准点名一个文件 / 目录

直接在输入框里打 @，会触发文件路径自动补全——它会列出当前项目里的文件让你选，你接着打几个字母过滤，选中即可。

为什么要用它？因为这是把一个具体文件「钉」进你这句话里最准的方式。比如你想让它看某个文件：

@src/auth.ts 这里的登录逻辑有没有问题？

这么打，Claude 明确知道你指的是哪个文件，不用它自己去猜、去全项目里翻。写复杂指令时基本离不开 @——项目一大，文件重名的多，用大白话说「那个 auth 文件」它经常找错，@ 一点名就没歧义了。

!：不用等批准，直接跑个 shell 命令

在输入框开头打 !，后面跟一条命令，就进入 Shell 模式（Bash 模式）：这条命令直接在你的终端跑，不用 Claude 批准、也不用它先「理解」你的话再替你跑，跑完的输出会被加进对话上下文里。

! git status

! ls -la

这玩意儿什么时候香？当你想顺手看一眼仓库状态，不想打一句大白话让它猜你要跑什么、再等一轮批准。比如改到一半，想确认下当前 git 状态，直接 ! git status，结果立刻出来，Claude 也「看到」了这个输出，下一句就能接着这个状态聊。

跑完之后 Claude 回不回话？分两种情况，成本账也不一样：

• 默认（v2.1.186 起）：自动回你一句。 比如 ! npm test 跑完，它会直接跟一句解释哪儿失败了，不用你再问。省事，但这次回复按一条普通提示词计费——所以默认情况下 ! 省的是「描述需求 + 等批准」那一来一回，不是 token。
• 在 settings.json 里设 respondToBashCommands: false：只记录、不回话。 回到 v2.1.186 之前的老行为——输出只进上下文，当下不发起任何模型调用，「省 token」这个卖点就回来了。严格说也不是零成本：这段输出会随你下一条消息按输入 token 计费，通常小到可以忽略；但要是 ! 跑了个刷屏的长日志，这个尾巴就不小了。

怎么选：想让它顺手点评一下输出（比如跑完测试直接听它解释哪儿挂了），用默认；只想把现场数据「喂」进对话、自己掌握节奏，设 false。

几个官方提到的实用细节：

• 想退出 Shell 模式：按 Esc、Backspace，或在空提示上按 Ctrl+U。
• 它支持基于历史的补全：打一半命令按 Tab，能从你这个项目里之前跑过的 ! 命令补全。

那 / 和 # 呢？

你可能在别处见过这俩，这里一句话交代清楚，别混淆：

• /（斜杠开头） = 调用命令 / Skill。打一个 / 会弹出一长串可用命令（/help、/clear 等）。这套斜杠命令体系内容很多，我们留到第 36 篇「斜杠 / 命令」专门展开，本篇你只要知道「/ 是命令入口」就够了。
• #（井号开头） = 历史上有过「用 # 开头快速往记忆（CLAUDE.md）里记一条」的用法，但不同版本行为有差异。Claude Code 怎么「记住」你的偏好、CLAUDE.md 怎么写，是第 18 篇「CLAUDE.md 使用指南」和第 25 篇「记忆系统」 的正题，到那儿再系统讲。这里不展开，免得你按了发现版本对不上。

把四个前缀放一起对照，你就不会记串了：

💡 一句话总结：@ 点名文件、! 顺手跑命令，这俩是天天用的快刀；/ 和 # 各有专篇，本篇只认识它们存在就行。

04 多行输入：回车老是把话发出去，怎么办

这是个高频「卡点」，单独拎出来讲。

问题来了：你想给 Claude 一段比较长的、分好几行的指令，结果按回车想换行，话却直接发出去了——半句话就被提交了。新手十个里有八个第一周都中过这招。

原因很简单：输入框里 Enter 默认就是「发送」，不是「换行」。要换行，得用别的键。官方给了好几种打法，按「最不挑终端」到「最方便」排：

一个稳妥的习惯：记死一个 \ + Enter 就够了——因为它「在所有终端都工作」，换机器、换终端都不用重新适应。等你固定用某个终端了，再去试 Shift+Enter 那种更顺手的。

如果你用的是 VS Code、Cursor、Alacritty、Zed、Devin Desktop 这类（它们的内置终端默认不支持 Shift+Enter 换行），官方给了个一劳永逸的办法：运行 /terminal-setup 自动装上换行绑定。

还有个更舒服的玩法：嫌在小输入框里写长指令憋屈，可以按 Ctrl+G，直接在你的默认文本编辑器里写，写完保存就带回来了。写那种几十行、带格式的复杂需求时基本都这么干，比在终端里硬敲舒服太多。

💡 一句话总结：回车默认是「发送」不是「换行」；换行记死 \ + Enter 万能，长指令直接 Ctrl+G 开编辑器写。

05 动手：三分钟把这几个键全试一遍

光看不练，明天就忘。下面给一套最小验证流程，不依赖任何复杂项目，随便找个文件夹就能跑。打开终端跟着走。

第一步：进任意一个有文件的文件夹，启动

cd ~/Desktop
claude

预期：出现欢迎界面，最底下是输入框（前面一个 >）。

第二步：试 ! Shell 模式

在输入框里打（注意 ! 顶格开头）：

! echo hello-shortcuts

回车。预期：终端直接打印出 hello-shortcuts（没有经过「征求批准」那一步），命令和输出被记进对话，然后 Claude 会针对这个输出简单回一句（默认设置下）——这就是 Shell 模式的完整流程。

第三步：试 ↑ 翻历史

输入框空着的时候，按一下上箭头 ↑。

预期：刚才那条 ! echo hello-shortcuts 被原样调回输入框里。这就是命令历史，重发指令不用重打。先按 Esc 或 Ctrl+U 清掉它。

第四步：试 Shift+Tab 切模式

按一下 Shift+Tab，再按一下，再按一下。

预期：状态行里的模式提示在 default / acceptEdits / plan 之间循环变化（你启用了哪些模式就在哪些之间转）。看到那行字在变，就说明你切对了。多按几下转回 default。

第五步：试多行输入

打一个字母，然后按 \ 再按 Enter，再打第二行：

第一行 \
第二行

预期：\ + Enter 让光标换到了下一行而不是把「第一行」发出去。这就对了。

第六步：退出

按 Ctrl+D。

预期：直接退出 Claude Code，回到普通终端。

跑完这六步，本篇讲的 !、历史、Shift+Tab、多行、退出，你就全亲手验证过一遍了。

⚠️ 一个可能的小插曲：如果你在 macOS 上发现 Option+Enter 之类的 Option 键快捷键不灵，那是终端没把 Option 配成 Meta 键。这是终端设置问题、不是 Claude 的 bug——\ + Enter 永远能用，先拿它顶着。

💡 一句话总结：照着这六步亲手跑一遍，!、↑ 历史、Shift+Tab、\ + Enter 换行、Ctrl+D 退出就全过了一遍肌肉记忆，比看十遍表都记得牢。

06 进阶一句：所有键都能改

最后留个钩子。上面这些键全是默认值，但 Claude Code 支持自定义快捷键——觉得哪个键不顺手，可以改。

按官方文档（需要 v2.1.18 或更高版本，用 claude --version 查），运行：

/keybindings

会创建 / 打开 ~/.claude/keybindings.json，你在里面就能重新绑定。不过有几个键改不了——前面说的 Ctrl+C、Ctrl+D 是硬编码的保留键。

给新手的建议是：先别急着改。 默认配置是官方反复打磨过的，先用熟，等你明确感觉到「这个键我每天按、但位置别扭」了，再去动它。一般用上快一个月、才会真正想改某个键，在那之前默认的全够用。

💡 一句话总结：键不顺手能用 /keybindings 改，但新手先把默认的用熟，别一上来就折腾配置。

07 小结

这一篇没教你怎么提需求，专门教你把手放对地方——界面看哪、键怎么按、特殊符号怎么用。

把核心动作收成一张表，揣兜里：

你现在应该能： 一眼认出界面的输入框、状态行和模式提示；用 Esc 精准刹车、Shift+Tab 切权限模式；用 @ 点名文件、! 跑命令；不再被「回车把半句话发出去」坑到。这些动作熟了之后，你跟 Claude Code 的交互会从「鼠标键盘来回切」变成「手不离键盘」——效率的差距，就在这儿拉开。

下一篇 15「怎么提问和给指令」——手放对地方了，接下来就是「嘴」的功夫了。同样一个需求，会问的人三句话搞定，不会问的人来回扯五轮还跑偏。下一篇咱们就聊：到底怎么跟 Claude 说话，它才听得准、干得对？

15 · 怎么提问和给指令：把话说到 Claude 心坎里

说句不太中听的实话：很多人刚上手 Claude Code 那阵子，都把它当搜索引擎使。

设想这样一个场景：项目里一个函数报错，你啪地甩过去一句「修一下这个 bug」，连哪个文件、什么报错都没说，回车，等着看戏。结果它「猜」了个它以为的 bug，改了三个文件，没一个是你真正想修的那处。你盯着满屏 diff 一脸懵，心里还嘀咕「这 AI 不行啊」。

回头一想就明白了——不行的不是它。问题压根不在 Claude，在那句话太烂：信息量约等于零，它只能靠脑补。脑补错了，能怪谁？

这么说吧：Claude Code 的天花板，很大程度上是被你的提问方式锁死的。同一个模型、同一个项目，会提需求的人三句话搞定，不会提的人来回返工五轮还一肚子火。今天就把「怎么把一句话需求说清楚」这套通用说话法则给你讲透——不是教你背模板，是教你想明白「Claude 到底需要知道什么才不跑偏」。

看完这一篇，你会拿到：

• 一张「烂提问 vs 好提问」对照表，照着改，返工率立降
• 四条提需求的硬核心法：具体、给上下文、给验收标准、复杂任务先列计划
• @ 引用文件把范围圈准的正确姿势
• 一个可照做的「同一需求两种说法」实验，亲眼看出差距

01 烂提问到底烂在哪

把上面那次翻车摊开看。「修一下这个 bug」这句话，站在 Claude 的角度，信息缺得离谱：

• 哪个 bug？它得自己猜你说的是哪处。
• 哪个文件？它得满项目翻。
• 期望的正确行为是啥？它根本不知道，只能按「一般来说应该怎样」脑补。

类比：带新人。 你跟一个刚入职的实习生说「把那个东西弄一下」，他能弄对才有鬼。换成「把首页右上角那个登录按钮，颜色从灰色改成品牌蓝 #1A73E8」，他闭着眼都能做对。指令越具体，新人越不跑偏；你越是甩一句模糊的，他越得猜，猜错的概率越大。 Claude 一模一样。

来看官方文档里反复强调的这组对照（按官方的意思译成了中文）：

看出门道没？好提问全在干一件事：把 Claude 本来要靠猜的东西，提前喂给它。

💡 一句话总结：烂提问烂在「信息缺口全靠 Claude 脑补」，好提问就是把它要猜的，你提前说清楚。

这张 Before/After 把同一个需求的两种问法摆到一起：左边模糊提问，Claude 只能脑补、反问一堆；右边把范围、上下文（@文件）、验收标准三件套给齐，它一次命中、直接跑测试通过。差距不在 Claude，在你怎么说。

02 心法一：具体 > 模糊

这是四条心法里最重要的一条，没有之一。

官方文档里有句话特别值得记住，原话是：

你的指令越精确，你需要的更正就越少。

翻译成大白话：前面多说一句，后面少返工三轮。 你以为「省事」是少打几个字，其实少打的那几个字，最后都变成来回拉扯的代价加倍还给你。

具体到什么程度？ 三个维度往里塞：

第一，圈定范围——哪个文件、哪个函数、哪个场景。别让它满项目大海捞针。

第二，说清约束——「别引新库」「保持向后兼容」「别动测试文件」。你不说，它就按自己的偏好来，回头未必合你心意。

第三，指个参照——「照 HotDogWidget.php 那个模式来」。这招实测下来最省心：与其用语言描述你想要的风格，不如直接甩给它一个你已经满意的现成例子，它照着抄，八九不离十。

这里有个反直觉的例外得讲清楚：模糊提问不是绝对的错。 当你在「探索阶段」、自己也没想好方向时，一句开放的「你觉得这个文件有什么可以改进的？」反而能炸出一些你压根没想到要问的东西。官方原话叫「当你在探索并能够改正方向时，模糊的提示可能很有用」。规律是：要结果时往死里具体，找灵感时故意留白。

做一个小工具的时候很容易踩到这个边界——一开始就想看看 Claude 怎么理解那摊乱代码，故意问得很泛，它给的几个改进点确实有启发；可一旦心里有了明确目标，再用模糊提问就纯属浪费回合了，它每次都得重新猜你到底要啥。

💡 一句话总结：要确定结果就往死里具体（范围 + 约束 + 参照），只有在主动找灵感时才故意留白。

03 心法二：给上下文，别让它瞎猜

具体之外，第二招是把「料」直接喂到它嘴边，而不是用嘴描述「料」在哪。

最高频的两个动作，记住就够用一大半：

第一，用 @ 引用文件。 在输入框打 @，会弹出文件路径补全，选中后这个文件的完整内容会被直接塞进对话——Claude 不用先去找、再去读，省一步还不会找错。

参考 @src/types/user.ts 里的类型定义，给 UserService 补上类型注解

这比「项目里有个 user 类型文件，你去找找」靠谱一万倍。官方文档明确写了 @ 引用「在响应前读取文件的完整内容」。

类比：USB 接口。 @ 就像把一块「文件 U 盘」直接插进 Claude 的工作台——插上即用，它要的资料一秒到位；你光用嘴说「资料在三楼档案室第二个柜子」，它还得自己跑一趟，跑错了更耽误事。

第二，报错直接整段贴。 这条值得练成肌肉记忆——遇到 traceback，别概括「它报了个空指针」，把完整堆栈原样糊进去：

运行时报了这个错，帮我定位原因：
TypeError: Cannot read properties of null (reading 'userId')
    at getUserProfile (src/services/user.ts:42:18)
    at async ProfileController.getProfile (src/controllers/profile.ts:15:20)

为啥要整段贴？因为堆栈里文件名、行号、调用链全有，Claude 顺着 user.ts:42 就能精准定位。你概括一遍，等于把这些关键坐标全删了，它又得从头猜。

一句话：凡是能「贴」的，绝不用「说」。 Claude 读原始材料，永远比读你对材料的二手转述准。

💡 一句话总结：用 @ 把文件、用粘贴把报错和截图直接怼到它面前，别让它顺着你的描述去猜。

04 心法三：给一个「可验证」的成功标准

这条最容易被忽略，但威力巨大：你得让 Claude 知道「干成什么样算成功」，而且这个标准最好它自己能验。

为什么关键？官方文档点破了底层逻辑——

当工作看起来完成时，Claude 会停止。没有它可以运行的检查，「看起来完成」是唯一可用的信号，你成为验证循环：每个错误都在等待你注意到它。

啥意思？你不给标准，Claude 凭「感觉差不多了」就收工，真正帮它兜底验收的人是你，每个漏洞都得你亲自逮。可一旦你给它一个能跑出「通过 / 失败」的检查，这个循环就自己闭合了：它干完 → 跑检查 → 看结果 → 没过就接着改，根本不用你盯。

对比一下就懂了：

注意最后一行那句「解决根本原因，别把错误压下去」——这是吃过亏才学会加的一句。不写这句，它有时候会图省事直接给你 try/except 一裹、或者加个 @ts-ignore 把红线消掉，报错是没了，病根还在。

进阶玩法：/goal 把验收标准变成「不达标不收工」。（需要 Claude Code v2.1.139 或更高版本）普通提问里写验收标准，是「这一轮跑一下」；而 /goal 是把标准钉成整个会话的目标——每跑完一轮，一个小模型（默认 Haiku）会按你的条件复查一遍，没达成就自动开下一轮，不把控制权还给你，直到条件满足才停。

/goal test/auth 里所有测试通过，并且 lint 这步是干净的

有个用 /goal 的关键细节别踩坑：那个评估小模型只看 Claude 在对话里「展示」出来的东西，它自己不会去跑命令、读文件。所以你的条件得是 Claude 自己的输出能证明的——「test/auth 测试全过」之所以成立，是因为 Claude 会真的去跑测试，结果打印在对话里，评估模型才读得到。你写「代码质量很高」这种没法从输出里看出来的，它判不了。

💡 一句话总结：给它一个能跑出通过 / 失败的检查（测试、截图比对、构建退出码），循环就自己闭合；想让它「不达标不撒手」，上 /goal。

05 心法四：复杂任务，先让它列计划再动手

最后一条，专治「大活儿」：遇到改动大、跨多文件、或者你自己也吃不准方向的任务，别让它上来就闷头写——先让它列个计划，你过一眼再放行。

这事第 06 篇（套餐与计费）埋过伏笔，这里说透为什么。官方文档的判断很干脆：

让 Claude 直接跳到编程可能会产生解决错误问题的代码。

说白了，先探索、再规划、最后编程——把「想清楚」和「动手干」拆开，免得它在错误的方向上一路狂奔，等你发现时已经改了一堆。

类比：装修先出图纸再砸墙。 没有哪个靠谱师傅二话不说抄起锤子就砸承重墙。他得先跟你确认「这面墙拆、这里走线、水管改道」，你点头了再开工。计划，就是 Claude 砸墙前递给你的那张图纸——图纸上发现不对，改两笔的成本，远低于墙都砸了再返工。

怎么让它先出图纸？两个办法：

办法一，嘴上说清「先别改」。 在普通对话里加一句限定就行：

我想给设置页加个深色模式开关。先告诉我要动哪些文件、改动思路是什么，
这一步先别改任何代码。

办法二，切到 Plan Mode（计划模式）。 这是 Claude Code 专门的「只读规划」档——它会读文件、提方案，但你批准前它一个字都不落盘。进入方式：会话里按 Shift + Tab（按一两下循环到 Plan Mode），模式会在 default → acceptEdits → plan 之间轮转。如果只想让某一条提示用 Plan Mode 跑、不切换整个会话，在那条消息前加 /plan 前缀即可。

不过官方也给了个很实在的提醒，别走极端把啥都拿去规划：

对于范围明确且修复很小的任务（如修复拼写错误、添加日志行或重命名变量），要求 Claude 直接执行。当你对方法不确定、更改修改多个文件或你不熟悉被修改的代码时，规划最有用。如果你能用一句话描述 diff，跳过计划。

最实用的土办法就是这最后半句：「能不能一句话说清这次改完长啥样？」能，直接干；卡壳了，说明这活儿够复杂，先让它列计划。 改个错别字也走 Plan Mode，纯属给自己加戏。

💡 一句话总结：拿不准 / 跨多文件 / 不熟的代码 → 先让它列计划（一句「先别改」或 Shift+Tab 进 Plan Mode）；一句话能说清 diff 的小活儿，直接干。

06 动手：同一个需求，两种说法见真章

光听道理不解渴，咱们做个能亲眼看出差距的小实验。准备一个三行的玩具文件就行，不依赖你任何现成项目。

第一步：建个有「坑」的玩具文件（Mac / Linux）

mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
    return sum(nums) / len(nums)' > stats.py

Windows 用户：mkdir prompt-demo、cd prompt-demo 照敲，stats.py 用记事本新建并贴入那两行。

这个函数有个坑：传进来空列表 [] 时，len(nums) 是 0，会触发「除以零」崩溃。我们就拿它当试验田。

第二步：在项目目录里启动 Claude

claude

预期：出现欢迎屏幕，底部有输入框。

第三步：先用「烂提问」，感受一下它怎么脑补

@stats.py 帮我改改这个函数

预期：Claude 大概率会「猜」你想干啥——也许加类型注解、也许加文档字符串，但它不知道你真正在意的是那个空列表崩溃，方向全凭运气。这就是模糊提问的代价：它在替你做决定。

第四步：换「好提问」——具体 + 上下文 + 验收标准三件套全上

@stats.py 里的 average 函数有个 bug：传入空列表时会因为除以零而崩溃。
期望行为是空列表返回 0。
帮我修复，并补一个测试：average([]) 应该返回 0、average([2, 4]) 应该返回 3。
写完把测试跑一遍，确认通过。

预期：这一次 Claude 的动作链条清清楚楚——定位空列表分支 → 加上判空返回 0 → 写出你点名的两个测试用例 → 真的去跑测试 → 把通过结果摆给你看。它不再猜你要啥，因为你把「修哪、改成怎样、怎么算成功」全说死了。

第五步：退出，看改动落没落地

cat stats.py

（Windows PowerShell 用 type stats.py）

预期：stats.py 里出现了对空列表的判断（类似 if not nums: return 0）。和你第四步要求的对得上 = 你已经摸到「把话说清」的手感了。

把两次提问并排放一起，差距一目了然：

💡 一句话总结：同一个文件、同一个 bug，烂提问让 Claude 替你做决定，好提问把「改哪、改成怎样、怎么算成功」全说死——亲手跑一遍这两步，差距比看十遍道理都直观。

07 小结

这一篇就讲了一件事：怎么把一句话需求，说到 Claude 能精准接住。

四条心法收个口，背不下来就记这张表：

你现在应该能： 把一句模糊的「帮我改改」翻译成 Claude 真正接得住的需求——圈准范围、喂足上下文、给出可验证的成功标准，复杂的还会先让它列计划。这套说话法则，是你之后用 Claude Code 一切操作的「内功」——功能再花哨，喂进去的提问烂，出来的活儿也好不了。

反过来想一个问题留给你：既然「把话说清」这么重要，那有些规矩（比如「这个项目永远别引新库」「测试一律放 tests/ 目录」）你每次都得重说一遍吗？有没有办法让 Claude「记住」，省得天天复读？

下一篇 16「常见工作流」——这一篇教的是「怎么把一句话说清」的通用法则，下一篇就把它落到四类最高频的具体活儿上：探索陌生代码库、修 bug、重构、写测试，每一类给你一套能照搬的标准打法。法则有了，该看招式了。

16 · 四个最常用的活儿：探索代码库、修 bug、重构、写测试

兄弟们，今天聊点最实在的。

你回想一下，自己天天对着代码到底在干啥？说白了翻来覆去就四件事：接手一个看不懂的项目、修一个莫名其妙的 bug、把一坨烂代码重构干净、给某个函数补上测试。别的需求当然也有，但这四类加起来，占了咱们日常时间的大头。

上一篇讲的是通用的「说话技巧」，这一篇要落到具体场景——这四类活儿各有各的标准打法，套路是固定的。用 Claude Code 用久了，最后沉淀下来的就是四个模板，存在备忘录里，遇到对应场景直接调出来填空。

这么说吧：通用技巧是内功，这四个模板是招式。内功你已经练过了，今天把招式给你。

看完这一篇，你会拿到：

• 四类高频任务（探索 / 修 bug / 重构 / 写测试）各一个可直接复制的指令模板
• 每一类「为什么这么打」的关键道理，不是死记模板
• 一张四类任务的速查卡，存下来随用随调
• 一个能照着跑、给了预期输出的完整实战（拿一个真 bug 走一遍修复流程）

01 先认住：四种活儿，四把工具

动手之前，先把这四类活儿的「性格」分清楚。它们对 Claude 的要求完全不一样，用错套路，效果差一大截。

类比：工具箱里的四把工具，认准各自的用途。 螺丝刀用来拧螺丝，扳手用来拧螺母，你拿扳手去拧螺丝当然别扭。探索、修 bug、重构、写测试，就是四把不同的工具——关键不是「会不会用 Claude」，而是「这活儿该掏哪把工具」。

它们最核心的区别在一个维度上：这活儿动不动你的代码？

看出来没？探索是零风险的（它只读不写），所以可以放心大胆问；修 bug 和重构是动刀的，得让它先讲清楚再动手；写测试介于两者之间，它新建文件不碰你原有代码，但你得盯它有没有偷懒只测「正常情况」。

记住这张表的判断逻辑，下面四节就是把每一把工具拆开教你怎么握。

💡 一句话总结：四类活儿先按「动不动代码」分清性格——探索零风险随便问，动刀的活儿先让它讲再让它改。

02 探索陌生代码库：从大到小，三层问下去

先说最高频的场景：你接手一个完全陌生的项目，第一件事是搞懂它。

这事儿以前怎么干？打开文件夹，对着几十个目录发懵，一个个点进去看，看俩小时还是云里雾里。现在不用了——Claude Code 把当前目录当工作区，它能自己读遍整个项目，你只管问。

类比：新到一家公司，你不会一上来就钻进某个模块的源码，而是先找老员工问三层。 第一层「咱们公司整个是做什么的、大架构长啥样」；第二层「负责支付的那块代码在哪儿」；第三层「一笔订单从下单到扣款，代码是怎么走的」。从大到小、从面到线，这就是探索的标准节奏。

按官方文档的演示，这三层分别对应三类问题：

给我一个这个代码库的整体概览，说说它的主要架构模式

负责用户认证的代码在哪些文件里？这几个文件是怎么协同工作的？

追踪一下登录流程，从前端一直到数据库是怎么走的

一个稳妥的习惯是，前两层一定在 Plan Mode（规划模式）里问——也就是上手前连按两次 Shift+Tab 切到规划模式（第一次进 acceptEdits，第二次才到 plan）。为啥？因为探索阶段我们只想让它读和讲，不想它一激动就开始改文件。Plan Mode 下它不会动你的源码，问得再多也不会改你一行代码。

比如接手一个三万行的老 Go 项目，第一天就可以这么干：先来一句「整体概览」摸清分了几个服务，再「负责 X 的代码在哪」逐个定位，最后挑核心链路「追踪一下这个请求怎么走的」。半天就能摸到门道，搁以前没两三天下不来。

这里直接给你探索模板，三层问题填好关键词就能用：

我刚接手这个项目，帮我快速上手。分三步：
1. 给我整体架构概览，说清主要模块和它们的职责
2. 负责 [你关心的功能，如「订单支付」] 的代码在哪些文件里
3. 追踪 [某条核心流程，如「一笔订单的创建到支付」] 的完整执行路径
用新手能懂的方式讲，先别改任何代码。

💡 一句话总结：探索就一个节奏——从大架构到具体文件再到执行链路，从大到小三层问下去，前两层在 Plan Mode 里问最稳。

03 修 bug：贴报错 → 找根因 → 改 → 加回归测试

修 bug 是另一类高频活儿，也是最容易翻车的一类。

为啥容易翻车？因为新手最常犯的错是：贴个报错就甩一句「帮我修一下」，然后 Claude 给你一个「能让报错消失」的修法。注意，「报错消失」不等于「问题解决」——很多时候它只是把症状盖住了，根因还在那儿埋着，下次换个姿势又炸。

类比：身上疼去看医生。 你不会进门就说「给我开点止疼药」，你会说清楚「哪儿疼、什么时候开始疼、做什么动作会更疼」，让医生先诊断病因，再开方子。修 bug 一模一样——先让它找根因，别让它急着「止疼」。

官方最佳实践里反复强调一条铁律，值得你贴墙上：

修复它并验证构建成功。解决根本原因，不要抑制错误。

所以正确的修 bug 流程是四步，缺一不可：

1. 贴报错 + 复现步骤：完整的报错信息、堆栈，外加「我做了什么才触发的」
2. 让它定位根因：先别让它改，让它说清楚「为什么会错」
3. 给修复：根因对了，再让它动手改
4. 加回归测试：补一个能复现这个 bug 的测试，保证以后不再犯同样的错

第四步是新手最容易漏的，但恰恰是最值钱的一步。官方的提法很妙：让 Claude「写一个失败的测试来复现问题，然后再修它」——这样修完测试自动变绿，等于给这个 bug 上了把锁，以后谁再不小心改回去，测试立刻报警。

这个亏很多人都吃过。比如修一个日期解析的 bug，当时 Claude 三下五除二改好了，看报错没了就提交了。结果两周后另一个同事重构时把那行又改回去了，同样的 bug 原地复活——因为当初没留测试，没人知道那行代码碰不得。所以修任何 bug 都该带上第四步。

直接给你修 bug 模板：

我遇到一个 bug。
报错信息：[完整粘贴报错和堆栈]
复现步骤：[我做了什么才触发，是偶发还是必现]
请你：
1. 先定位根本原因，解释为什么会出错，先别改代码
2. 给我修复方案，解决根因，不要只是把报错盖住
3. 改完补一个能复现这个 bug 的回归测试，跑一遍确认通过

💡 一句话总结：修 bug 四步走——贴报错和复现步骤、先找根因、再改、最后补回归测试；少了回归测试这把锁，同一个 bug 迟早复活。

04 重构：先讲现状 → 定目标 → 小步改 → 改前改后都测

重构这活儿，风险最高，因为它动的是「没坏的代码」。

修 bug 好歹有个明确的「修好了」标准——报错没了、测试绿了。重构没有，重构的目标是「代码更干净，但行为一个字都不能变」。一旦行为变了，你就是在重构的名义下偷偷引入 bug，这是最坑的一种 bug，因为没人会去测一段「只是整理了一下」的代码。

类比：给一个住人的房子重新装修，但不能让住户搬出去。 你得保证水电照常、人照住，只是把墙刷新、把线理顺。重构就是「带住户装修」——功能（住户的生活）必须全程不受影响。

所以重构的安全打法是四步，核心是「用测试把行为锁死」：

1. 先让它解释现状：搞清楚这段代码现在到底在干啥、有哪些隐藏行为
2. 说清重构目标：你要的是「拆函数」「换现代写法」还是「去重复」？说具体
3. 小步改：官方明确建议「以小的、可测试的增量进行重构」，别让它一次性推翻重写
4. 改前改后测试都过：重构前先跑一遍测试存个基准，改完再跑，两次结果必须一致

第四步是重构的命根子。如果这段代码现在没测试，那重构第一步不是改，而是先补测试——先用测试把「现在的行为」拍下来当快照，重构后对着快照验，行为没变才算成功。这点跟官方最佳实践完全一致：给 Claude 一种能验证自己工作的方式，否则「看起来对」就是唯一信号，而看起来对的重构，恰恰最容易藏雷。

这里有个值得守的硬规矩：没有测试覆盖的代码，别让 Claude 直接重构。设想一下图快的场景，让它重构一个没测试的工具函数，它把一个边界分支「优化」掉了——那个分支看着像废代码，其实处理了一种罕见输入。线上炸了才发现。一律先补测试再重构，慢是慢一点，但再不会翻车。

直接给你重构模板：

我想重构 [文件 / 函数名]。
重构目标：[具体说，如「拆成更小的函数」「换成现代写法」「消除重复」]
要求：
1. 先解释这段代码现在的行为，包括容易忽略的边界情况
2. 如果它还没有测试，先补上覆盖现有行为的测试
3. 小步重构，保持对外行为完全不变
4. 重构前后都跑一遍测试，确认结果一致

💡 一句话总结：重构的命根子是「行为不能变」——先讲现状、再定目标、小步改，用改前改后都过的测试把行为锁死；没测试就先补测试再动手。

05 写测试：重点是逼它覆盖边界情况

最后一类：给代码补测试。

写测试这事儿，Claude 干起来其实很顺手——它会去翻你现有的测试文件，照着你已经在用的框架、断言风格写，风格自动对齐，不用你教。但有个坑你必须知道：你不特别交代，它默认只测「正常情况」。

什么叫只测正常情况？比如一个除法函数，它给你测「6 除以 2 等于 3」——对是对，但除以 0 呢？传进来负数呢？传个 null 呢？ 这些「边界情况（edge case）」才是真正会出 bug 的地方，也是测试最该覆盖的地方。

类比：招个人来给产品做质检，你不能只让他试「正常操作」。 真正值钱的质检是去试那些「作妖」的输入——空的、超长的、负的、乱码的。会出问题的永远是边界，不是正常路径。写测试的核心，就是逼 Claude 去测这些边界。

所以写测试模板的关键，就一句话：显式要求它覆盖边界情况。官方最佳实践给的好提示长这样——明确说清「测哪个函数、测什么场景、要不要 mock」：

为 foo.py 编写测试，涵盖用户已注销的边界情况。避免 mock。

对照一下两种问法，差距一目了然：

还有个小技巧：用 @ 把目标文件直接点给它（写 @src/utils/math.py），它会先读完整文件再动手，比你用文字描述「那个 math 文件里的 divide 函数」精准得多。@ 引用的用法前面篇章讲过，这里正好派上用场。

直接给你写测试模板：

给 @[文件路径] 里的 [函数名] 写测试。
要求：
1. 沿用项目现有的测试框架和断言风格
2. 重点覆盖边界情况：[列出你能想到的，如「空输入、零、负数、超大值、类型不对」]
3. 也帮我想想还有哪些我没列到的边界情况，一并测上
4. 写完跑一遍，有失败的修到通过

第 3 点是额外加的一招——主动让它帮你补漏。官方文档也提到，Claude 能分析代码路径、找出你可能遗漏的边界。写测试时基本都该带这句，它经常能揪出你压根没想到的输入组合，比一个人闷头列全多了。

💡 一句话总结：写测试别只说「写测试」——显式逼它覆盖边界情况（空值、零、负数、类型错误），再让它帮你补你没想到的边界，正常路径反而最不重要。

06 动手：拿一个真 bug 走一遍修复流程

光看模板不算会，得跑一遍。下面用「修 bug」这一类做实战——它四步最全，跑通它，另外三类你自然就会套。这里特意埋了个真 bug 给你修。

第一步：建一个带 bug 的玩具项目（Mac / Linux）

mkdir bug-demo
cd bug-demo
echo 'def average(numbers):
    return sum(numbers) / len(numbers)' > calc.py

Windows 用户：mkdir 和 cd 照敲，calc.py 用记事本新建，贴入上面那两行 Python。

这个 average 函数算平均值，看着没毛病——但传进去一个空列表，它会除以 0 崩掉。这就是我们要修的 bug。

预期：bug-demo 文件夹里有个 calc.py，内容是 average 函数那两行。

第二步：启动 Claude Code

claude

预期：出现欢迎屏幕，底部有输入框。

第三步：套用修 bug 模板，贴报错让它修

在输入框里敲（这就是把第 03 节模板填好的样子）：

我遇到一个 bug。
报错信息：调用 average([]) 时报 ZeroDivisionError: division by zero
复现步骤：给 calc.py 里的 average 函数传一个空列表就必现
请你：
1. 先定位根本原因，解释为什么会出错，先别改代码
2. 给我修复方案，解决根因，不要只是把报错盖住
3. 改完补一个能复现这个 bug 的回归测试，跑一遍确认通过

预期：Claude 会先告诉你根因——空列表时 len(numbers) 是 0，除以 0 就崩了；然后给一个 diff（比如空列表时返回 0 或抛一个更清楚的异常），停下来等你批准；批准后它还会新建一个测试文件（像 test_calc.py），里面有一条专门测空列表的用例。

第四步：批准改动，看它跑测试

看懂 diff 后选「同意 / Yes」。Claude 会接着运行刚写的测试。

预期：终端里能看到测试结果，类似：

test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSED

看到测试全绿 = 这个 bug 被修好了，而且上了锁——以后谁再把这行改回去，测试立刻变红报警。

第五步：退出，确认文件真的改了

退出 Claude（敲 exit 或按 Ctrl+D），回终端看：

cat calc.py

（Windows PowerShell 用 type calc.py）

预期：calc.py 里 average 函数已经加了空列表的处理逻辑，目录下还多了个测试文件。和你批准的 diff 对得上 = 修 bug 全流程跑通，恭喜！

⚠️ 注意： 如果第三步 Claude 没主动写测试，大概率是你的模板把第 3 点删了。别省那一句——回归测试这把锁，正是新手和老手的分水岭。

💡 一句话总结：修 bug 全流程亲手跑一遍——埋个真 bug、套模板让它先找根因再改、看着它补测试跑绿，跑通这一类，另外三类照葫芦画瓢就会。

07 小结

这一篇把你日常 80% 的活儿拆成了四类，每一类给了一套固定打法和一个能抄的模板：

你现在应该能： 拿到任何一类高频任务，不再对着光标发懵——直接调出对应模板填空，知道每一步该让 Claude 先干什么、自己该盯什么。这四个模板，是你之后绝大多数工作的脚手架；熟了之后你会发现，再复杂的任务也无非是这四类的组合与串联。

这四个模板经得起天天调用的考验——再花哨的任务，最后也还是绕回这四套打法。

下一篇 17「图片与多模态」——前面全是「打字给指令」，但有些事文字说不清：一个报错截图、一张设计稿、一份数据库结构图。下一篇就教你把图片直接喂给 Claude，让它看着图干活。想想看：你手里那张让你头疼的报错截图，如果能直接甩给它，是不是省事多了？