如何使用Claude Code，看这一篇就够了
更新时间：2026年7月30日
安装、账号、Windows与WSL2选择，以及中转站风险，请先看《Claude Code安装与使用指南及中转站风险说明》。本文不再重复安装步骤，主要讲Claude Code进入真实项目以后，怎样把它从“会写代码的聊天工具”用成一个能理解、执行和验证的编程Agent。
本文最初参考并翻译自“How I use every Claude Code feature”。2026年7月更新时，依据Claude Code官方文档、变更日志和当前实际功能重新整理，保留原文偏实战的写法，不再沿用已经变化的命令和配置。
背景
我几乎每天都在使用Claude Code。早期使用它时，最容易获得成就感的做法是把权限放开，再扔给它一句“把这个功能做出来”。小项目里确实经常有效，代码也会很快铺开。但只要项目稍微复杂，问题马上出现：它可能没读到真正的入口，理解错团队约定，修改了不该动的模块，最后还很自信地说已经完成。
这不是某个模型独有的问题。现在的CLI Agent都在面对同一件事：模型能力越来越强，真正拉开差距的却是上下文、规则、工具、权限和验证怎样组织。一个任务能不能做完，往往取决于Agent开始之前知道了什么，执行过程中能碰什么，以及完成以后用什么证据证明它真的好了。
所以我现在使用Claude Code，会把一项工作分成五步：先理解项目，再明确目标，接着制定计划，执行修改，最后验证和复查。下面介绍的CLAUDE.md、Rules、Skills、Subagents、Hooks、MCP和Worktree，都是服务于这条主线，而不是为了把配置目录堆得很复杂。
先建立一条稳定的主工作流
进入一个陌生项目后，我通常不会直接说“实现订单退款”。第一轮会先让它只读：
先阅读项目结构、订单模块、支付适配层和相关测试。
说明退款流程现在从哪里进入，状态怎样变化，失败怎样处理。
引用具体文件作为依据，不要修改任何内容。这一步的目的不是让Claude复述目录，而是检查它有没有找到真正的调用链。它说错了，后面的计划再漂亮也没有用。
确认现状后，再把任务边界和验收条件说清楚：
目标：支持支付成功后24小时内的全额退款。
边界：不改动现有支付接口签名，不处理部分退款。
验收：补充服务层测试；退款失败时订单状态不能改变；
运行与订单、支付相关的测试，并说明结果。然后让它进入Plan Mode。计划里应该出现准备修改的文件、关键数据流、兼容性和验证方式，而不只是“第一步分析、第二步实现、第三步测试”这种没有信息量的目录。计划确认后再执行，过程中如果发现原先判断不成立，就停下来更新计划，不要为了走完步骤硬改。
最后一定看Diff和测试输出。Claude Code能调用测试工具，不代表它每次都会选择最有价值的验证；测试命令成功，也不代表需求真的满足。Agent负责扩大执行能力，人仍然负责判断交付是否成立。
CLAUDE.md：把团队长期不变的约定交代清楚
CLAUDE.md是Claude Code最重要的项目说明文件。它适合放每次进入项目都应该知道的事情：项目做什么、主要目录、构建和测试命令、代码风格、禁止修改的区域，以及提交前必须完成的检查。
一个够用的CLAUDE.md可以很短：
# 项目说明
- 后端是 Spring Boot，前端在 web/，API 定义在 api-contract/。
- 修改接口时先更新契约，再修改前后端实现。
- 单元测试：mvn test
- 前端检查：npm run lint 和 npm test
- 不要修改 generated/ 下的文件，它们由构建生成。
- 不要提交 .env、密钥、构建产物和本地数据库。它不是第二份README，也不是把整个架构文档复制进来。写得越长，真正重要的约束越容易被淹没。官方文档也提醒，过大的CLAUDE.md会占用上下文并降低遵循效果。我的经验是：先放会反复用到、又容易做错的内容；某条规则只影响一个目录，就交给Rules处理。
Rules：让规则只在相关文件出现时生效
较大的项目可以把规则拆到.claude/rules/。例如数据库迁移、前端组件、API契约和测试各自有不同要求，不必全部塞进每次会话。
Rules可以按路径限定作用范围。这样Claude处理前端文件时才加载前端约定，修改数据库迁移时才看到迁移规则。它既减少上下文噪音，也比一句笼统的“遵循项目最佳实践”更容易执行。
这里要分清一件事：CLAUDE.md和Rules是在告诉模型应该怎样做，属于行为指导；Permissions和Sandbox才是客户端真正执行的限制。想禁止读取密钥或阻止危险命令，不能只在CLAUDE.md里写一句“不要读”。
自动记忆：有用，但要看得见
新版本Claude Code提供自动记忆。它会在工作过程中记录构建命令、调试经验、架构说明和项目习惯，并在后续会话里按需取回。记忆文件仍然是普通Markdown，可以通过/memory查看、编辑或删除。
我会让自动记忆保存“以后仍然成立的发现”，例如某组集成测试需要本地Redis，或者某个模块的生成文件不能手工改。临时任务状态、一次性错误信息和未经验证的猜测，不适合变成长期记忆。记错一条规则，比每次重新查一次更麻烦。
如果团队希望规则可审查、可共享，仍应把它写入版本控制中的CLAUDE.md或.claude/rules/。自动记忆默认保存在本机项目目录之外，不会自动在同事和云环境之间同步。
Context、Compact、Clear、Resume与Rewind
Claude Code工作久了，最常见的问题不是模型突然变笨，而是上下文里混入了太多旧计划、失败输出和已经推翻的判断。下面几个命令解决的是不同问题：
/context：查看上下文被什么占用。规则、Skills、MCP工具、历史消息和附件都可能吃掉空间。/compact：压缩较早的对话，保留任务主线。适合同一项长任务继续做。/clear：清空当前对话，从一个干净上下文开始。适合已经换了问题，不要为了“保留历史”继续拖着旧内容。/resume或claude -r：恢复之前的会话。给会话命名后，比只看自动生成标题更容易找到。/rewind：把对话或代码回到较早的检查点，适合某条执行路线明显走错时回退。
我通常以任务为单位管理会话。一个Bug、一项重构或一篇文档放在一个会话里；主题换了就开新会话。不要在同一个上下文里先排查登录，再写部署脚本，最后又让它重构支付模块。人自己都会串线，Agent更不会例外。
Checkpoint和Git各自解决什么
Claude Code的Checkpoint可以恢复Agent修改前的文件状态，适合快速撤销某一轮改动；Git则记录整个项目的明确版本和团队协作历史。两者不是替代关系。
开始大任务前，我仍然会先检查工作区，确认已有改动属于谁，再创建清楚的Git基线。执行过程中用Checkpoint快速回退，任务完成后看完整Diff和测试，再由人决定是否提交。不要因为有Checkpoint，就让Agent在一个混有大量未提交修改的目录里随意尝试。
Skills：把可重复的工作方法包装起来
Skills适合那些会反复出现、又不仅是一句提示词的工作。例如“检查数据库迁移”“为REST接口补契约测试”“按团队格式生成发布说明”。一个Skill可以包含说明、脚本和资源，Claude在任务需要时再加载，不必每次都占用完整上下文。
项目级Skill通常放在：
.claude/skills/<skill-name>/SKILL.md从2026年开始，自定义斜杠命令与Skills在使用层面逐步统一。与其为每一句固定提示建一个命令，不如把真正有步骤、输入、输出和验证要求的流程写成Skill。一个好的Skill应该告诉Claude什么时候使用、需要哪些材料、怎样判断完成，而不是只写“你是一位资深工程师”。
Skills也不必一开始就做得很大。先把团队每周重复两三次的流程提取出来，跑过几次以后再补边界和失败处理，比一上来做一个“万能开发Skill”更容易维护。
Subagents：让主会话少背一些上下文
子Agent拥有独立上下文，完成后把结果返回主会话。它适合边界清楚、只需要结论的任务，例如让一个子Agent搜索认证链路，让另一个检查测试覆盖，再由主会话合并结果。
自定义子Agent可以放在.claude/agents/，为它限定工具、模型和工作职责。比如安全审查Agent只需要读代码和搜索，不一定需要写文件；测试分析Agent可以运行测试，但不应接触部署凭据。
子Agent不是越多越快。多个Agent如果同时修改同一批文件，合并成本会抵消并行收益。最适合委派的是独立调查、代码审查、测试分析和可拆分模块。
Agent Teams：需要互相讨论时再使用
Agent Teams与子Agent最大的区别是，团队成员可以互相发消息、共享任务列表并独立推进。一个Agent负责前端，一个负责后端，一个负责测试，团队负责人再汇总结果。对于跨层功能、多个排查假设或并行研究，这种方式比所有信息都挤回主会话更自然。
但截至2026年7月，Agent Teams仍是实验功能，默认关闭，官方也明确提示它在恢复、协调和关闭行为上存在限制。每个成员都有自己的上下文，Token消耗会随人数增加。顺序任务、同文件修改和小修复，单会话或子Agent通常更划算。
Worktree：并行修改时先隔离文件
子Agent和Agent Teams解决“谁来做”，Git Worktree解决“在哪里改”。Claude Code可以用--worktree在隔离的工作树里开始会话，也可以让子Agent进入单独Worktree。这样不同任务不会直接踩在同一个工作目录上。
我会在下面几种场景使用Worktree：同时尝试两种修复方案、让Agent在后台完成独立功能、或者主工作区里已经有不能打扰的未提交修改。最后仍然要由人比较分支、解决冲突和决定合并，不要把隔离理解成自动安全。
Hooks：把提醒变成真正会执行的检查
CLAUDE.md里写“修改后运行测试”，模型可能忘记；Hook可以在特定事件发生时真的调用脚本或检查器。它能在工具调用前后、权限请求、会话停止、子Agent开始或结束时执行。
常见用途包括：
写文件前检查目标路径，阻止修改生成目录；
执行命令前扫描是否包含危险参数；
任务停止前运行格式检查或最小测试；
需要人工批准时发送桌面或团队通知；
把任务摘要、成本或失败信息写入团队日志。
Hook是确定性代码，写错了也会确定性地制造麻烦。先从只记录、不阻塞的Hook开始，观察输入输出，再逐步增加拦截逻辑。对密钥、生产部署和删除操作，应该使用权限和组织策略做硬限制，不要只依赖一个容易被跳过的脚本。
MCP：把外部资料和工具带进项目
MCP让Claude Code通过统一协议连接数据库、Issue系统、文档、浏览器、设计工具和内部服务。它解决的是“Claude怎样获得项目之外的信息和动作”，不是让模型自动知道所有业务。
一个常见场景是：Claude从Jira读取需求，到Confluence查接口说明，修改代码后再把结果更新回任务。过去需要为每个系统写一套私有集成，现在可以通过MCP Server提供标准工具。
MCP Server同样会占用上下文和权限。不要把所有服务器都长期打开。当前任务只需要读取Issue，就不必同时加载数据库写入、云部署和邮件发送工具。使用/mcp检查连接状态，并为高风险工具保留人工批准。
如果还不清楚MCP与Agent、RAG的分工，可以阅读《RAG、Agent、MCP之间到底是什么关系？》。
Plugins：把Skills、Agents、Hooks和MCP一起分发
当一个团队需要把同一套Skill、子Agent、Hook和MCP配置交给很多项目时，逐个复制目录很快会失控。Plugins就是这层打包和分发机制。它适合团队级的代码审查规范、发布流程、内部工具连接和安全检查。
插件更新需要版本管理和变更记录。不要让一个没有审查的Marketplace插件直接获得项目写权限和敏感MCP工具。它与普通软件依赖一样，也需要确认来源、版本、权限和升级影响。
Permissions与Sandbox：别把省确认当成省时间
Claude Code的Permissions可以对Read、Edit、Bash、WebFetch和MCP等工具设置allow、ask和deny。Sandbox则对Bash命令施加操作系统级文件和网络隔离。两者配合使用，才能既减少无意义的弹窗，又守住真正不能碰的边界。
我只会对低风险、可重复、路径明确的命令自动允许，例如项目目录内的格式检查和单元测试。数据库删除、云资源修改、发布、密钥读取和项目外写入仍然保持询问或拒绝。
原文提到过--dangerously-skip-permissions。它在一次性虚拟机或完全隔离的实验环境里可以节省确认，但不适合作为日常默认设置，更不应该在带有生产凭据、公司代码和个人文件的电脑上长期使用。
Windows原生模式目前不支持Claude Code Sandbox；需要Sandbox时应使用WSL2、macOS或Linux。即使启用Sandbox，也要检查它是否真正启动，企业环境可以设置在Sandbox不可用时直接失败，避免无声退回无隔离执行。
settings.json：把配置放到合适的作用域
Claude Code设置大致有四层：
用户级：
~/.claude/settings.json，放个人长期偏好。项目级：
.claude/settings.json，可以提交到版本库，供团队共享。本地项目级：
.claude/settings.local.json，适合个人机器上的项目设置，不应提交。组织托管级：由管理员下发，用户和项目不能覆盖，用于认证、权限、Sandbox和合规要求。
一个实用原则是：团队共同遵守的东西进项目级，个人习惯进用户级，本机路径和临时开关进local，安全底线进组织托管设置。不要为了图方便，把个人Token或本机绝对路径提交进项目配置。
Claude Code SDK与GitHub Actions
当一次交互式会话变成稳定流程以后，可以用Claude Agent SDK把同一套Agent能力嵌入脚本和内部系统。例如新Issue进入后做影响分析、CI失败后收集日志、定期检查依赖升级，或者自动生成一份等待人工审查的修改。
GitHub Actions适合把Claude接入Issue、Pull Request和CI。比较稳的做法是让它生成分支、评论或建议，不直接合并到主分支；把测试、权限和人工审查留在原有流水线里。
自动化不是把交互提示词复制到服务器就完成了。还要补上幂等、超时、费用上限、凭据轮换、失败通知和产物保存。真正长期运行的Agent，更像一个需要运维的服务，而不是一次聊天。
IDE、Web与Remote Control怎么分工
终端适合深度控制和脚本，IDE适合边看代码边审查Diff，Web与Remote Control适合让远程任务继续运行，再从其他设备补充信息或批准下一步。它们使用的是同一类Claude Code能力，但上下文、环境和凭据来源可能不同。
不要默认本地CLI里设置的环境变量会自动出现在Web或云环境。远程任务需要单独配置仓库权限、依赖、Secret和网络。反过来，Web中的订阅凭据也不会被本地ANTHROPIC_API_KEY覆盖。
一套我现在会采用的项目配置顺序
先写一份不超过必要长度的CLAUDE.md，放项目入口、测试命令和关键禁区。
把只影响特定目录的约定拆进
.claude/rules/。用项目级settings设置最小权限，本机差异放settings.local。
先接一个真正需要的MCP Server，不一次性加载整个工具箱。
把每周重复的检查做成一个Skill，确认稳定后再做Hook。
独立调查交给Subagent；只有确实需要互相讨论和并行修改时才用Agent Teams与Worktree。
每项任务仍然从理解、计划、执行、测试和Diff复查走完，不因为配置多了就取消人工判断。
如果团队还在建立AI辅助开发规范，可以继续阅读《AI辅助开发不只是工具：规则、上下文和评测体系》。工具只是执行入口，真正能长期提高质量的是规则、上下文、测试、评测和代码审查共同组成的闭环。
总结
Claude Code现在的功能很多，但不需要第一天全部配置。先把一个真实任务做稳：让它找到正确代码，给出有依据的计划，在明确权限里修改，再用测试和Diff证明结果。等你发现某些信息总要重复，再写CLAUDE.md和Rules；发现某个流程总要重做，再提炼成Skill；需要确定性检查时，再加入Hook。
最容易犯的错误，是把“Agent可以自主工作”理解成“人可以不再定义边界和验收”。Claude Code真正强的地方，是让一个清楚的工程过程跑得更快，而不是替工程过程本身消失。