Claude Code 怎么处理不同问题：思考节奏与自用方法论

老Z2026/4/2大约 6 分钟

Claude Code 本质是 模型 + 终端里一串工具（读文件、改文件、跑命令、搜仓库）。它不会魔法：同一套能力，你 怎么描述问题、给多少边界、何时让它停手验证，决定了结果是「一次改对」还是「改出一堆回归」。

这篇是我自己的 分工法：按 问题类型 说 该怎么下指令、先求证还是先动刀、怎么收尾。不是 Anthropic 官方口径；配置 MCP / Skills 见 Claude Code 进阶：MCP、Skills 与自用习惯，盯上下文与费用见 statusline 小技巧。

几条底层共识（所有场景通用）

先缩小范围，再扩大权限
一上来就「把整个项目重构了」往往翻车。先 复现路径、相关文件、期望行为，再允许它跨目录改。
工具循环 = 它的思考方式
它会 读 → 假设 → 改/跑 → 看输出 → 再读。你帮它省步数的方式是：贴关键报错、指到入口文件、说清运行命令（例如 pnpm test、go test ./...）。
上下文是硬通货
长会话里 旧结论会挤掉新 diff。大改动拆成 多轮小任务，每轮 commit 或 stash 一下，比单线程聊到底更稳。
你的「完成定义」要写死
「好了」对它可能是「能编译」。你要写：哪些测试必须绿、哪些行为不能变、哪些文件不许动。

下面按 常见题型 拆。

1）排错：现象已知、根因未知

目标：先定位，再 最小修复，别顺带「优化」。

推荐节奏：

给复现：命令、输入、完整报错栈（或日志片段），说明 预期 vs 实际。
允许只读探查：让它 grep、读相关模块，先出假设列表（一两句话即可），再动代码。
改完必须验证：同一组命令再跑一遍；若是 并发 / 时序 问题，说明「偶现」并让它 加日志或缩小复现。

话术骨架：

复现：…
我怀疑和 … 有关，但不确定。请先只读排查，列出最可能的 2～3 个原因，再改 最小 diff，最后跑 … 验证。

常见坑：报错里其实缺环境（Node 版本、.env、feature flag）。开头就写 「在某某环境、某某分支」，少兜圈。

2）读代码：接手陌生仓库、要快速建立心智模型

目标：地图，不是重写。

推荐节奏：

从入口问：CLI 的 main、HTTP 的 router、前端的 App / routes，让它画出 调用链 或 模块依赖（文字即可）。
按问题读：「钱从哪扣」「权限在哪验」「任务谁调度」—— 带着问题 比「介绍一下项目」有效。
让它输出可检索笔记：例如「10 条 bullet + 关键文件路径」，方便你贴进内部 wiki 或下一轮会话当 system 上下文。

话术骨架：

我只关心 {业务/模块 X}。请从入口开始，说明 数据怎么流、关键类型/接口在哪几个文件，不要改代码。

常见坑：仓库太大时，它会 猜目录结构。先指定 子目录 或包名，避免在无关区域空转。

3）小改与热修：改一行、发一版

目标：低风险、可回滚。

推荐节奏：

文件级范围：「只动 foo.ts 和对应测试」比「优化相关逻辑」安全。
禁止扩散：明确 不要重命名、不要格式化全文件（除非你真要）。
补丁要小：方便 code review 和 git bisect。

话术骨架：

需求：…
允许修改：path/a、path/b
禁止：动配置、动公共组件、全仓格式化
验收：… 通过即可

常见坑：它为了「干净」顺手 升级依赖 或 改类型导出——在提示里直接写 「不要改 package.json / lockfile」 往往更省事。

4）新功能：从 0 到可合并

目标：可测、可拆 PR，而不是「一坨能跑的脚本」。

推荐节奏：

先对齐接口：输入输出、错误语义、是否要幂等、是否碰 DB/API。
让它先写测试或调用示例（若你团队是 TDD），再写实现——减少「接口飘了」。
分阶段提交：例如「骨架 → 核心逻辑 → 边界情况 → 文档」。

话术骨架：

要实现：…
约束：遵循现有 … 风格；错误用 … 形式返回
交付：实现 + … 测试 + README 片段

常见坑：和现有抽象重复。让它先搜是否已有 util / middleware，再写新代码。

5）重构与迁移：换框架、换语言、换目录结构

目标：行为不变（或变更显式列出）。

推荐节奏：

冻结行为：列出 公开 API、关键用户路径，说明哪些 允许变（例如内部类型）。
机械步骤优先：重命名、搬文件、改 import，适合 脚本 + 小步 commit；逻辑重写和机械迁移 不要混在同一 diff。
对拍测试：旧新双跑，或 契约测试 / 快照，再删旧代码。

话术骨架：

迁移：A → B
不变：对外 HTTP 路径、响应 JSON 字段 …
步骤：先搬无逻辑文件 → 再迁模块 → 最后删废弃；每步可独立 git commit

常见坑：它 顺手「现代化」 删掉「看起来没用」的分支——重构提示里写 「禁止删除未标注为废弃的代码路径」。

6）一次性脚本、数据修复、运维活

目标：可重复执行、可审计，别留下 本机-only 的烂摊子。

推荐节奏：

声明环境：对谁跑（staging / prod）、是否要 dry-run。
要求幂等或明确二次运行后果。
日志与退出码：方便你塞进 CI 或交给同事接手。

话术骨架：

写脚本：…
必须：--dry-run、打印将修改的行数、非 0 退出码表示失败
禁止：硬编码我本机路径

常见坑：悄悄写死密钥路径。让它读 环境变量，并在 README 写一行 必填 env。

7）模糊需求：「你帮我看看怎么设计更好」

目标：多方案对比，而不是直接开工。

推荐节奏：

约束前置：延迟、成本、团队栈、是否要 自托管。
让它输出 2～3 个选项：各 优点 / 代价 / 适用条件，再让你选。
选定后再进实现模式——否则它会 边想边改，难回滚。

话术骨架：

目标：…
约束：…
请先给方案对比，不要改代码；我回复选项后再实现。

一张表：题型 → 你先强调什么

题型	第一句话建议带上的信息
排错	复现命令、完整报错、环境
读代码	关心的业务边界、入口文件或包名
小改	允许改的文件列表、禁止项
新功能	接口契约、测试与文档要不要
重构	哪些行为绝对不能变
脚本/运维	dry-run、幂等、运行环境
模糊设计	约束 + 「先方案后代码」

小结

Claude Code 没有一种固定「思考模式」；你能稳定复用的是 任务分型 + 边界写清 + 验证闭环。
排错先只读后改；读仓库 先入口再纵深；小改锁文件；新功能 先契约；重构先冻结行为；脚本先 dry-run；模糊事 先方案。
把它当 结对程序员：你负责 要什么、不要什么、何时停；它负责 在工具循环里把活干完。