Claude Code 4.8 进阶用法：从入门到精通
我为什么会重新研究这个工具
上个月我在重构一个遗留的 Node.js 支付模块，大概 14,000 行代码，散落在 60 多个文件里。我试着用普通的聊天式 AI 助手来做，结果发现我每天有一半时间在复制粘贴代码、粘贴报错、再复制回答回去——工具替我写了代码，但“搬运”的工作全压在了我身上。
当时我想：能不能让 AI 直接在我的项目目录里工作？于是我花了两周时间认真用了 Claude Code 4.8，踩了不少坑，也总结出了一套自己的工作流。这篇文章就是那份总结。
基础但常被忽略的设置
安装很简单：
npm install -g @anthropic-ai/claude-code
cd your-project
claude
但我一开始犯的第一个错误是：在 home 目录下直接启动。它会把整个目录当作工作上下文，响应慢得离谱，而且它经常读到一堆无关文件。后来我养成了习惯——永远在具体的项目根目录启动。
第二个值得早点做的事是配置 CLAUDE.md。这个文件是每次会话自动加载的项目说明，我现在的写法是：
# 项目约定
- 使用 pnpm，不要用 npm
- 测试框架是 Vitest，运行命令：pnpm test
- 所有 API 响应必须经过 src/utils/validator.ts
- 提交信息用中文，格式：类型: 描述
# 常见陷阱
- src/legacy/ 目录下的代码不要动，等 Q3 重构
- 环境变量在 .env.example 里有完整列表
加了这个文件之后，我发现它不再反复生成 npm 命令让我纠正，一次会话能省下十几次来回。
真正拉开差距的：权限模式
Claude Code 有一个我一开始完全误解的机制——权限确认。默认情况下它每要执行一个 bash 命令都会问你。前两天我像个傻瓜一样按了几百次 "yes"。
后来我学会了在会话里输入 /permissions，把安全命令加进白名单：
允许: pnpm test
允许: pnpm lint
允许: git status, git diff, git log
拒绝: rm -rf *
更进一步，如果你信任某个任务，可以用：
claude --dangerously-skip-permissions
但我强烈建议只在与外界隔离的环境里这么做（比如 Docker 容器或专用的开发分支机器）。我有一次在主项目上用了这个模式，它为了“修复依赖”直接改了我的 lock 文件，回滚花了我半小时。
实战技巧一：先规划，后执行
这是我用了两周后最大的一个认知转变。直接说“帮我重构支付模块”效果很差——它一上来就改代码，改到一半方向就歪了。
现在我的标准流程是分两步：
第一步，只要计划不要代码：
先不要写任何代码。分析 src/payment/ 目录，列出你认为
需要重构的点，按风险从高到低排序，每个点说明你打算
怎么改。我会审核后再让你执行。
第二步，审核通过后再说“按第 1、3 点执行”。
这个流程让我的返工率降了大概 70%。因为它被迫先读完整个模块再动手，而不是边读边改。
实战技巧二：用 git 当安全网
我现在有个铁律：让 Claude Code 动手之前，工作区必须是干净的。
git add -A && git commit -m "重构前快照"
然后在提示里明确告诉它：
每完成一个逻辑完整的步骤，就单独 commit 一次，
commit message 说明改了什么、为什么改。
这样一旦某一步改坏了，我可以精确回滚到那一步，而不是整个推倒重来。有一次它重构时悄悄删掉了一个它认为“没人用”的工具函数——结果测试挂了，我直接 git revert 那一个 commit 就解决了，其他 8 个 commit 的成果都保住了。
实战技巧三：处理大型代码库
14,000 行的项目不可能整个塞进上下文。我的做法：
- 让它先画地图：“列出 src/payment/ 的模块依赖关系，用文字描述谁调用谁”
- 指定范围：“只看 TransactionService.ts 和它的直接依赖”
- 用子任务拆解：4.8 版本支持在会话里派发子任务，我会说“把这个重构拆成 5 个独立的小任务，逐个执行”
还有一个实用命令是 claude --resume，可以恢复之前的会话。我经常早上接着昨晚的上下文继续干，省去了重新解释项目的麻烦。
一个意外惊喜：让它写测试
我最开始只让它写业务代码，效果时好时坏。直到有一次我换个思路：
先读 src/utils/dateParser.ts，然后列出你从这个实现中
推断出的所有边界情况，为每种情况写一个失败优先的测试，
再修代码让测试通过。
效果出乎意料地好。因为它先读实现再反推边界条件，找出了我手动测试时漏掉的时区转换问题。现在我几乎总是把“补测试”作为任务的收尾步骤。
诚实地说说局限
用了一个月，我也得泼点冷水：
- 长会话会“忘记”早期约定。聊了两三个小时后，它有时又开始用 npm。解决办法是重要的规则写进
CLAUDE.md，不要只靠口头交代。 - 它对“隐式业务知识”一无所知。比如“这个 if 分支看起来冗余，但它兼容了某客户的特殊数据”，它不知道就会删掉。涉及业务判断的代码，务必自己逐行 review。
- 复杂的多文件重构有时会半途而废，改到第 7 个文件突然说“其余类似”。我的对策是任务拆小，一次只让它改两三个文件。
- token 消耗不低。重度使用一天下来成本不便宜，所以我会把纯机械性的工作（格式化、改命名）留给脚本，把省下的额度花在真正需要思考的任务上。
我的最终建议
如果你刚开始用，记住三件事：写好 CLAUDE.md、配置好权限白名单、永远在干净的 git 状态下让它动手。做到这三点，你就已经超过大多数用户了。
往上一级，学会“先规划后执行”和“任务拆小”，它能帮你完成以前不敢想象的重构工程。
它不是替你写代码的机器，而是一个需要你给出清晰方向、并替你把关的结对程序员。把它当成同事而不是工具来协作，收获会大得多。