Claude Code 使用技巧：核心是管理上下文和验证闭环

Claude Code 很强。

但它不是魔法。

如果你随手丢一句：

1	帮我改一下这个项目。

它当然也能动起来。

可是真正把 Claude Code 用顺的人，通常不是“提示词更玄学”，而是做对了两件事：

1 2	管理上下文建立验证闭环

这两个点，比任何花哨提示词都重要。

Anthropic 官方最佳实践里也反复强调：Claude Code 是 agentic coding environment，它能读文件、跑命令、改代码，但上下文窗口会快速被填满，性能也会随之下降。

所以你要学会让它少猜、少绕路、少读无关信息。

一、先给 Claude 一个可执行目标

Claude Code 不是普通聊天机器人。

它更适合接收工程任务。

不要这样说：

1	这个页面不好看，帮我优化。

更好的说法是：

请优化 dashboard 页面：
1. 保留现有信息结构
2. 提升移动端布局
3. 不改变接口字段
4. 改完运行 pnpm build
5. 用浏览器截图检查 1440px 和 390px 两个尺寸

这类提示会让 Claude Code 明确三个东西：

目标是什么
边界在哪里
怎么判断完成

很多失败不是模型不行，而是任务描述太松。Claude Code 会很努力，但努力的方向不一定是你想要的方向。

二、让 Claude 先探索，再计划，再写代码

我很少一上来就让 Claude Code 改复杂功能。

更常见的流程是：

1	先探索，不要修改文件。

比如：

请先阅读和用户设置相关的代码，告诉我：
1. 路由入口在哪里
2. 数据从哪里加载
3. 保存逻辑在哪里
4. 如果要新增头像上传，需要改哪些文件
先不要动代码。

等它输出分析后，再让它写计划：

1	基于刚才的分析，给我一个最小改动方案，列出文件级别的修改计划和验证方式。

最后才执行：

1	按这个计划实现，保持改动范围最小。

这个节奏很重要。

Claude Code 阅读能力很强，但如果一边找文件一边改代码，很容易在上下文里堆积太多噪音。先探索再执行，可以明显降低返工。

三、上下文是 Claude Code 的燃料，也是限制

Claude Code 的上下文会装进很多东西：

你的提示词
它读过的文件
命令输出
测试日志
前面的对话
中间计划和解释

一次调试如果反复跑大段日志，很快就会把上下文填满。

上下文快满的时候，Claude 可能开始忘记前面的约束，也可能重复探索已经看过的代码。

所以要学会控制输入。

比如不要让它整段贴出巨大日志，而是说：

1	运行测试，但只总结失败用例和关键报错，不要贴完整日志。

或者：

1	只阅读与登录流程相关的文件，不要扫描整个仓库。

再或者：

1	如果需要更多文件，先告诉我你要看哪些文件和原因。

Claude Code 很聪明，但上下文不是无限的。你越会节省上下文，它越能在关键地方发挥推理能力。

四、CLAUDE.md 要短，但要有用

很多项目会用 CLAUDE.md 存项目规则。

这个文件不要写成百科全书。

它更适合写这些东西：

项目技术栈
常用命令
目录约定
测试方式
代码风格
不要触碰的文件
提交前检查项

比如：

Use pnpm.
Run pnpm build before committing frontend changes.
Blog posts live in source/_posts and must include Hexo front matter.
Do not edit generated public/ files.

规则越短，Claude 越容易遵守。

如果你写了几千行“团队规范大全”，它不一定每次都能抓住重点。

我更喜欢把 CLAUDE.md 当作项目导航，而不是项目文档全集。

五、一定要给 Claude 一个检查方式

Anthropic 官方资料里很强调 verification。

这点我完全同意。

你不能只让 Claude Code “写完”。你要让它“证明写完”。

例如：

1	实现后运行 pnpm test。

1	实现后运行 pnpm build。

1	实现后用 curl 调用 /api/users/me，确认返回 200。

1	实现后打开浏览器截图，对比设计稿差异。

只要有可读的检查信号，Claude Code 就能自己迭代。

没有检查信号，它就会停在“代码看起来没问题”。

这一步是普通 AI 写代码和 agentic coding 的分界线。

六、复杂任务用 worktree 并行，不要混在一个目录

Claude Code 支持多会话和 worktree 场景。

这对复杂项目很有用。

比如你同时要做：

修一个线上 bug
改一个 UI 页面
补一组单元测试
写一篇技术文档

这些任务不应该全挤在同一个工作区。

更好的方式是：

1	一个任务一个 worktree

这样每个 Claude 会话都有独立上下文和独立 Git diff。

好处很明显：

不容易互相覆盖
diff 更干净
回滚更简单
每个任务可以单独验证
最后提交信息更清楚

并行不是为了显得高级，而是为了减少任务之间的干扰。

七、权限要预先设计，不要一刀切

Claude Code 频繁询问权限会打断节奏。

但完全跳过权限也有风险。

比较稳的做法是给常用安全命令预授权，比如：

pnpm build
pnpm test
git status
rg
sed

但对这些动作保留确认：

删除文件
改数据库
修改环境变量
安装新依赖
执行远程脚本
推送代码

权限配置不是越宽越好。

它应该让 Claude Code 少被无意义打断，同时保留关键风险点的人工确认。

八、及时纠偏，不要等它写完一大坨

Claude Code 很适合长任务，但长任务里最怕方向偏了还继续跑。

如果你看到它开始改无关文件，要马上停：

1	暂停。不要继续改这个方向。请恢复到只修改 xxx 文件，并解释为什么需要改其他文件。

如果它开始过度设计，也要直接说：

1	这个方案太重了。请改成最小实现，不引入新抽象。

如果它输出太啰嗦：

1	后续只给关键决策和验证结果，不要解释每一行代码。

Claude Code 很吃反馈。

早纠偏比最后回滚轻松得多。

九、一个实用提示模板

我常用这个模板：

目标：
xxx

请按这个流程做：
1. 先探索相关代码，不要修改
2. 给出简短计划
3. 等我确认后再实现
4. 实现时保持最小改动
5. 完成后运行 xxx
6. 最后总结改动文件和验证结果

限制：
不要引入新依赖
不要改无关文件
不要修改公共 API，除非先说明原因

如果任务很小，可以去掉确认步骤。

但对于跨模块任务，这个模板能明显提高成功率。

十、结语

Claude Code 的优势不是“它总能一次写对”。

真正的优势是：

1	它能在明确目标和验证信号下，持续探索、修改、运行、修复。

你要做的不是背提示词，而是设计工作流。

给它清晰目标，控制上下文，写好项目规则，提供验证命令，及时纠偏。

做到这些，Claude Code 就会从一个很会写代码的模型，变成一个真正能协作推进任务的开发伙伴。