RC-1136Claude Code这几个字，最近在开发者圈子里几乎快成了AI编程的代名词。命令行里敲一句自然语言，它就能读项目、改代码、跑测试，甚至自己写脚本把活干完，这种工作方式确实让人上瘾。前段时间我看到Claude Code核心维护者在一次公开分享里聊了团队内部真实在用的10个使用技巧，信息量比官方文档大得多。我把内容结合自己的实操经验重新过了一遍，逐个验证、补细节，整理成下面这份偏实战的笔记。不管你是刚接触Claude Code，还是已经用它写了几个礼拜代码，这篇都能帮你把工具用得更稳、更狠。
1. 先弄明白Claude Code的工作方式，再谈技巧
1.1 它不是聊天框，是一个能动手干活的终端代理
很多人第一次用Claude Code会误把它当成ChatGPT式的问答框——你问一句它答一句，然后你把答案复制进编辑器，自己改。这么用当然也行，但完全没有发挥出它真正的价值。
Claude Code的本质是一个跑在终端里的AI代理，它能直接读取你项目目录里的文件、跨文件搜索关键词、定位函数定义、修改代码、执行命令，甚至操作Git提交。这意味着它并不是"回答你怎么改"，而是"直接把改好的结果给你"。你把它当成一个坐在你旁边、能看到整个代码库的结对同事，思路一下就通了。
这个定位差异很关键，后面10个技巧几乎都建立在这个认知上。如果你把Claude Code当高级问答框用，技巧二到技巧十基本都白扯。
1.2 三个不能绕开的核心概念：CLAUDE.md、权限模型、会话上下文
在展开技巧之前，有必要把三个基础概念点透。第一个是CLAUDE.md，这是项目根目录下的一个Markdown文件，Claude Code每次启动时会自动读取它，内容会被注入到上下文窗口里当作"项目说明书"。它对AI行为的影响，远远大于你在对话里临时补充的几句要求。
第二个是权限模型。Claude Code可以执行Shell命令、修改文件，但它不能绕过权限系统为所欲为。每次涉及敏感操作（写文件、执行命令）时需要得到授权，你可以在设置文件里配置允许执行的白名单命令、自动拒绝的危险命令、以及只读模式。这个模型是一切安全使用的前提。
第三个是会话上下文。Claude Code的上下文窗口有上限，而且每次交互都会累积token消耗。它不像人的大脑可以无限记住细节，聊得越多，旧信息越可能被截断或稀释。如何管理上下文，直接决定输出的稳定性。
把这三个概念吃透，接下来的10个技巧你才能看出门道：哪些是喂信息的技巧，哪些是节流省钱的技巧，哪些是防守保命的技巧。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 团队技巧前五条：把上下文喂饱，把效率拉满
2.1 技巧一：CLAUDE.md不是写给别人看的，是给AI的"入职培训"
团队分享的第一条技巧，就是把CLAUDE.md当作新人入职培训文档来写。很多人的CLAUDE.md只写两三行项目介绍，这就相当于招了个高级工程师却不告诉他业务背景和技术规范，他只能靠猜。
一份合格的CLAUDE.md至少应该包含四块内容：项目定位（这系统解决什么问题）、技术栈清单（语言、框架、数据库、关键依赖）、常用命令（怎么启动、怎么跑测试、怎么构建）、硬性约束（哪些目录不许动、哪些模式必须遵循、命名规范是什么）。
我维护的一个项目就是这么写的：
markdown复制# 项目定位
面向团队内部的文档协作平台，偏中型Web服务。
# 技术栈
Node.js + TypeScript + Express + PostgreSQL，前端为React。
# 常用命令
- 启动开发服务：npm run dev
- 运行测试：npm test
- 构建：npm run build
# 约束
- 所有数据库操作必须走repository层，禁止在controller里直连数据库。
- 禁止手动修改package-lock.json。
- 新API路由统一放在src/routes下。
写完之后你会明显感觉到，AI生成的代码风格更贴合项目，少了很多"通用模板味"。关键是要定期更新，项目演进后CLAUDE.md还停留在三个月前，等于给AI喂了过期地图。
2.2 技巧二：按分支开会话，用--resume衔接长期任务
Claude Code的会话是可以保存和恢复的。团队建议的使用方式是：一个功能分支只开一个会话，配合--resume参数，把跨天的任务衔接起来。
比如你接到一个任务"给支付模块增加退款能力"，第一天先是需求分析和初步设计，你敲了一条命令：
bash复制claude --resume payment-refund
第二天继续同一分支，同样用这条命令恢复会话，AI仍然记得之前已经做过的调研和设计讨论，而不是从头再问一遍"项目是什么、技术栈是什么"。
这么做的好处有两个。第一，上下文连续，减少重复铺垫；第二，上下文可控，不会让多个不相关任务混在一个会话里互相污染。我见过不少同事图省事用一个会话处理三个分支的活，结果AI把A分支的改动思路带到B分支，硬生生改出了跨分支的脏代码。
2.3 技巧三：自定义子代理，一个会话里演好几个角色
很多用户不知道Claude Code支持自定义子代理。所谓子代理，就是你把一段专用的系统提示词固化成一个角色，在需要时临时唤起来干活。
团队成员通常会定义几个固定角色：代码审查者（只读diff，专门挑毛病）、测试生成器（只看代码，输出测试用例）、数据库专家（专注SQL优化）、重构师（负责整理混乱代码）。
自定义子代理的配置文件放在.claude/agents目录下，每个角色一个YAML文件，我常用的代码审查角色长这样：
yaml复制name: code-reviewer
description: 代码审查专家，只读不写，输出审查意见
system-prompt: |
你是一名严格的代码审查者。
阅读用户提供的diff或代码后，按以下顺序输出：
1. 会导致bug的严重问题
2. 潜在风险与边界情况
3. 可读性和维护性改进
4. 性能优化机会
禁止直接修改文件，只输出审查意见。
实际使用中，让主会话负责开发、时不时唤出子代理做审查和测试，配合起来非常高效。这相当于你同时让一个开发和一个测试搭档干活，而不是全程只靠同一个模型自问自答。
2.4 技巧四：让AI先列改动计划，再动手写代码
这是团队提到的效率提升最明显的一条：不要一上来就让Claude Code直接改代码，先让它输出实施计划。
很多人习惯直接说"帮我加一个导出Excel的功能"，然后Claude Code就埋头开始改了。中途你发现它方案不对，已经产生的改动全部白费。正确做法是加一句限制："先不要改代码，先分析现有代码结构，列出改动计划，确认后再动手。"
以我自己的高频用法为例，我会这样提问：
"分析当前订单模块的代码结构，我要新增一个导出Excel功能。请先输出实施计划：涉及哪些文件、每处改动做什么、是否有风险点。确认前不要修改任何文件。"
这个习惯带来的改变是巨大的：AI先展示思路，你可以在动手前纠正方向；如果计划有问题，零成本调整；就算没问题，你在确认计划的过程中也等于做了一次轻量级代码走查。这招尤其适合新人，因为他们的技术判断力还不足以完全信任AI的方向感。
2.5 技巧五：每完成一个小目标就/clear，不给幻觉留机会
上下文窗口是有限的，但很多人没有主动管理上下文的意识。聊了两个小时，session里堆积了大量无关历史：中间说过的话、试错的代码、删掉的方案，这些垃圾信息不仅消耗token，还会让AI越来越"糊涂"，输出开始偏离需求、重复造轮子、甚至记住一些已经被推翻的错误结论。
团队的做法很简单：每完成一个小目标就执行一次/clear，清空当前对话历史。比如"帮我写一个工具函数并测试通过"，完成这个目标后，干净利落地清掉上下文，重新开始下一段对话。
这样做的代价是要重新提供一些上下文信息（所以CLAUDE.md要写得足够好），但换来的是每次对话的上下文干净、意图明确、输出质量稳定。我个人的体感是，一个目标一清，AI的失误率明显下降，尤其是中大型需求，分段处理才能保证每步都不跑偏。
3. 团队技巧后五条：把质量守住，把安全管住
3.1 技巧六：测试先行，让AI自己证明代码没写坏
靠肉眼审查AI生成的代码是不可靠的，团队第六个技巧简单又直接：先让AI写测试，再让它改代码或加功能，最后运行测试来验证。
具体做法是，接到需求后不要急着让AI实现，而是先要求它分析现有测试覆盖情况，补充新的测试用例来覆盖需求场景。然后再实现功能，实现完之后立刻跑测试，让测试结果说话。
一套组合提问模板是这样的：
- "为订单模块新增退款功能之前，先分析现有测试覆盖，并输出你觉得需要新增的测试用例列表。"
- "按列表补上测试用例，但先不要实现功能代码。"
- "现在实现退款功能，目标是让新增测试全部通过。"
- "运行npm test，如果失败就继续修复，直到全部通过。"
这套打法看起来慢，实际很快，因为AI在测试约束下写出的代码质量明显更高。它必须去理解"什么行为算是正确"，而不是只追求"代码能跑起来"。这一点我实测下来深有体会：有测试当锚，AI很少写出那种"看起来逻辑对但其实边界条件全没处理"的代码。
3.2 技巧七：权限白名单与只看不改模式
过去我吃过亏：让Claude Code一键执行格式化命令，结果不知道它执行了什么清理逻辑，把整个目录扫了一遍。团队的建议是，权限模型必须从一开始就明明白白配置好，别图省事给全域写权限。
以我的配置文件为例，我做了这样的权限设置：
json复制{
"permissions": {
"allow": [
"Read",
"Glob",
"Grep",
"Edit",
"Bash(npm test)",
"Bash(git diff)",
"Bash(git status)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(git push --force)"
]
}
}
配置的思路是：默认允许读操作、精准允许少数命令、明确拒绝高风险命令。这样Claude Code大部分时候可以自由工作，但涉及危险操作时必须停下来征求你的同意。
另外一个很有用的开关是只读模式，打开之后AI只能看代码、做分析，不能改任何文件。遇到"先理解一下这个模块在干嘛"的场景，我建议直接切只读模式，既保护代码不被意外改动，也让你安心理清思路。
3.3 技巧八：让AI写脚本自己执行，但每一步都要人确认
团队反复强调一个原则：宁可多一次确认，不要少一次审批。Claude Code可以在对话里直接写Shell脚本并执行，这个能力很强，但如果不加控制，它可能会执行一些你根本不知情的命令。
比如你要它"帮我把所有图片压缩一下放进dist目录"，它可能会写个脚本批量压缩。如果不限制，它连"帮你装个依赖"都会自己完成。我的建议是，除非你已经完全信任当前任务，否则明确要求："写好后先展示脚本内容，我确认后你再执行。"
实际操作中，我还会限制自动执行的次数。涉及多条命令执行时，尽量拆成单条命令、分批授权，而不是一次性给所有后续命令放行。虽然稍显繁琐，但能有效防止AI用一连串半对半错的操作把项目搞乱。
3.4 技巧九：复杂需求拆成子任务并行处理
单线程让Claude Code处理一个大型需求，通常会遇到上下文爆炸和输出变慢的问题。团队推荐的模式是：把大需求拆成多个可独立验证的子任务，然后用多个会话并行处理。
比如你做的是一个数据可视化大屏，需求包含数据接入、图表渲染、筛选交互、性能优化四块。完全可以按照模块拆成四个会话，每个会话独立完成一部分。拆完之后再开一个汇总会话，让AI基于CLAUDE.md和四份产出整合代码。
并行处理要注意依赖关系，先处理公共基础部分，再处理依赖它的上层模块。我常用的做法是先用一个分析会话理清模块依赖关系，画出任务清单，然后再并行开工。这种模式最怕的是子任务边界不清晰，两个会话同时改同一个文件，合并时冲突哭都来不及。所以拆任务时尽量按文件边界拆，尽量减少跨会话的文件交集。
3.5 技巧十：把每周复盘写回CLAUDE.md
最后一条技巧经常被忽略，但长期收益最大。团队成员会把本周使用过程中发现的"AI老犯的错"记录下来，沉淀到CLAUDE.md里，变成下一周AI启动时的默认认知。
比如我这周发现，Claude Code经常在改动数据库迁移脚本时不自动同步测试数据，于是我在CLAUDE.md里加了一条："修改数据库迁移脚本时，必须同步检查并更新测试数据。"又比如发现它写Error Handling时习惯把错误吞掉，就加一条："所有异步错误必须显式处理并返回错误响应。"
这个做法本质上是利用CLAUDE.md做团队经验的持续注入。每天我们花大量时间去纠正AI的错误，反复解释同一件事，为什么不把纠正结果固化下来，让AI从下次开始就记住？
我的习惯是每周五花十分钟回顾本周的无效沟通与典型纠错点，整理成三到五条新规则追加进CLAUDE.md。坚持两个月后，AI在你项目上的表现会从"一个聪明的外援"变成"一个熟悉团队习惯的老兵"。
4. 实践中的常见问题与排查实录
4.1 问题一：AI越改越偏，上下文被污染了
最典型的表现是：前半天还好好的，下午开始AI频繁忘记你早上定下的约定，输出的代码风格开始漂移，甚至重复改动已经确认过的文件。这通常是上下文被污染的信号。解决路径很简单，确认没有未提交的重要改动后，执行/clear重置上下文，然后重新加载CLAUDE.md，继续干活。
如果之前的关键结论很重要，别指望AI记得，花一分钟把它补进CLAUDE.md，这才是长期可靠的方案。
4.2 问题二：给了执行权限，结果它自己跑了十几分钟
有一次我让Claude Code帮忙做依赖升级，它居然自己启动了一长串shell命令，十几分钟没停。我赶紧强制中断，然后发现它有个操作正在下载一堆新依赖。
这种问题的根源是权限太宽松。后来我严格限制Bash权限，只放行明确知道安全的命令，并且要求每一步执行前都经过授权。经验教训就是：不要给你自己怕的命令开权限，权限配置的原则是"最小够用"，而不是"最方便"。
4.3 问题三：子代理不知道项目全局，产出对不上
让子代理做代码审查时，有时候它给出的意见明显没有结合项目背景，这是因为子代理的上下文是独立的，拿不到主会话里已经讨论过的项目信息。
排查思路是：子代理适合处理局部、明确的任务（比如审查某个函数、生成某个模块的测试），不适合做需要全局判断的事。如果确实要子代理理解项目全局，要么把CLAUDE.md精简内容拼进提示词，要么把相关文件路径、核心描述一并传进去。别指望子代理有读心术。
4.4 我的排查三板斧：日志、最小复现、降级
最后聊一下我的通用排查框架。遇到Claude Code表现异常，我一般按三层查：
第一层查日志。Claude Code会把每次交互写入日志，翻日志能看到它到底执行了什么命令、在哪个环节开始出现问题。第二层做最小复现。把当前需求简化成一个最小的例子，丢给AI单独跑，看问题是否复现。第三层降级处理。如果问题只在复杂场景出现，就拆掉部分上下文，分治处理，甚至暂时换个更稳的模型。
这套框架能帮我快速定位八成以上的问题，实际价值非常高。遇到"AI变蠢"，不要着急重写提示词，先按这三步排查。
我个人在实际操作中的体会是，Claude Code用得好不好，七分在配置、三分在技巧。CLAUDE.md、权限模型和上下文管理这三件事做扎实了，它就是一个靠谱的队友；这三件事没做好，它就只是个偶尔灵光的高级自动补全。
最后再分享一个小方法：把技巧四（先列计划再动手）和技巧六（测试先行）配合起来用，是我目前验证过质量最稳的组合。每次改动之前先让AI亮计划和测试，就像面试时先看作品集再决定要不要录用，错误率和返工率都会大幅下降。如果你也在用Claude Code，建议先从这两条开始尝试，大概率会有完全不一样的体验。