Claude Code 新手的进阶路线图

用了一阵 Claude Code，你开始抱怨：“它总忘记测试。”于是去搜进阶教程，CLAUDE.md、auto memory、hooks、MCP、subagents 一字排开，看哪个都像解药，干脆一起配上。

可翻翻自己的记录，同一句抱怨背后可能是三种完全不同的情况：每次都要重新找测试命令；命令已经读到了，改完却直接宣布完成；检查条件早就稳定，只是每次都靠人提醒。第一种缺的是项目说明，第二种缺的是验证习惯，第三种才轮到自动化。

基础流程还没稳的时候，同时加好几项配置，出了问题更难判断是哪一层没起作用。进阶也要从卡点出发：

回看实际记录，找出读项目、计划、小改动、diff、验证和审查里哪一步还不稳；
按卡点在六条路线里选一条：日常协作、项目记忆、上下文管理、自动化、工具连接、多代理与团队工程；
用七天围绕这一条路线练习，每天一个能检查的小动作。

其他功能先放一放。七天后对照最初的问题看效果，再决定继续、调整还是换一条路。

01 先从记录里找卡点

准备好环境、分清上下文和权限以后，就可以沿着这条流程协作：

读项目 → 做计划 → 小步修改 → 查看 diff → 运行验证 → 人工审查

进阶前先回看实际记录，确认这些步骤哪些已经尝试过，哪些还不稳定。读完教程，能力未必就已形成；缺少记录时，先补一个可检查的小任务。

先问自己五个问题：

我是不是经常重复解释项目规则？
我是不是经常在长会话里丢失重点？
我是不是经常做重复检查、格式化、测试？
我是不是需要 Claude Code 连接外部工具？
我是不是想把它接入团队开发流程？

答案不同，优先路线也不同。

小黑从实际记录中的薄弱环节选择一条进阶路线，再拆成七天可检查动作

回到“它总忘记测试”，先翻记录，看看问题出在哪：

记录中的情况	可以先做什么
每次都要重新找测试命令	把已核实的入口整理进项目说明
已经读到命令，改完却直接宣布完成	练习实际运行验证，并记录结果
重复检查的条件已经稳定	再考虑自动化

先找到缺的是哪一步，再学对应的机制。只说“记忆不好”，还不足以决定练什么。

02 路线一：继续练日常协作

看记录时，如果发现找文件、写计划或验证结果还经常出问题，就先练日常协作。读项目、追流程、修小 bug、补测试、改文档，都能成为练习；审查 diff、准备 PR 描述也可以单独练。提交仍由你确认。

基础流程还没稳定下来时，继续练它很值得，MCP、hooks 和 subagents 先放下。每天把计划、验证和复盘留下来，才看得见下一次该练哪里。

03 路线二：项目记忆

如果基础协作已经能走通，麻烦却在每次开始任务时重复出现，就看看项目记忆这条路线。你可能会发现自己总在说：

为什么我每次都要重新告诉它项目规则？

比如：

这个项目用 `pnpm`，不用 `npm`
提交前要运行 `pnpm test`
API 文件都放在 `src/api`
组件要用 2 空格缩进
不要修改 `generated` 目录

这些信息每次重写，容易漏掉。这时可以学两种办法：

CLAUDE.md：由你明确写下项目规则。
auto memory（自动记忆）：由 Claude 根据你的纠正和偏好，自己记下笔记。

官方 Memory 文档对两者的区分正是这样。自动记忆可能不完整，也可能已经过期；需要长期遵守的项目规则，要核对后明确写进 CLAUDE.md 维护，临时推测只当参考。

先读已有规则，再补充已经核实的命令、依赖和目录约定。限制迁移或敏感资料读取时，也写明适用范围，保留原有的团队要求。

CLAUDE.md 让 Claude Code 能读到规则。要强制限制动作，还得配置权限、隔离措施，或经过验证的拦截 hook。规则本身写具体一点：“提交前运行 pnpm test”，就比“认真测试”更容易照着做。规则越写越多以后，怎样按作用范围拆分，可以看用三个问题把 CLAUDE.md 拆开。

04 路线三：上下文管理

长会话里反复冒出旧方案、漏掉已经确认的限制，可以检查上下文。这些现象也可能来自错误信息或执行问题，会话变长只是其中一种可能。先找出哪些材料仍然有效、哪些已经过期，再决定怎样保留任务状态。

先练三个低成本习惯：

任务变大时，先拆成小会话
研究型问题交给单独会话或 subagent
每次完成一个阶段，就让 Claude Code 总结目标、约束和当前状态

例如可以说：

请总结当前任务状态：
1. 已经确认了什么
2. 已经修改了什么
3. 验证结果是什么
4. 下一步只剩什么
5. 哪些内容已经不需要继续保留

普通总结不会清空历史。需要换会话时，先记录目标、约束、已改文件、验证状态和待办，再让新会话明确读取。接手后核对当前文件与记录是否一致，交接内容要靠这一步确认。长会话该清空、压缩还是交接，可以接着看长会话的整理方法。

05 路线四：自动化

有些检查每次都一样，做法也已经稳定下来，这时可以考虑自动化。先确认三件事：动作重复、触发条件明确、风险可控。自动执行时未必有人临场判断，条件含糊，就容易在不合适的时候做出动作。

hook 会在 Claude Code 运行过程中的特定时刻，自动执行你定义的动作。官方 Hooks 指南里的例子包括：Claude 等待输入时发桌面通知、每次编辑后自动格式化、拦住对受保护文件的编辑。

先用低风险的提醒验证触发时机，再逐步扩大 hook 的动作范围：

Claude 等待输入时给我通知
每次编辑后提醒我运行格式化
提交前提醒我运行测试

熟悉触发方式后，再考虑拦截敏感编辑、危险命令，或自动格式化、检查 lint。

设置 hook 时，要选对实际触发的事件。有拦截作用的 hook，“应该放行”和“应该阻止”两种情况都要试过。你在其他终端手动提交代码时，Claude Code 的工具 hook 管不到；要检查所有提交，需要另设 Git hook，或交给团队的 CI 检查。

06 路线五：连接外部工具

如果代码任务经常需要参考外部资料，比如设计文档、工单或团队消息，就有了学 MCP 的具体理由。MCP（Model Context Protocol）是连接 AI 工具与外部数据源的开放协议，也能让 Claude Code 连接内部工具。

连接以后，要读什么、能写什么，都得划清。选这条路线前，先确认自己能审查本地小改动，有明确的外部需求，也能说清新增的读写权限，这样才容易判断这些权限是否必要。

适合 MCP 的场景包括：

代码任务需要参考产品需求文档
修 bug 前需要读取 Jira issue
改 UI 前需要读取设计文档
团队希望 Claude Code 调用内部工具

07 路线六：多代理与团队工程

任务能拆成独立的子问题，或需要进入团队自动化时，可以学习子代理（subagents）、并行会话、GitHub Actions 和 Agent SDK。

子代理有独立的上下文、提示和工具权限。大量调研、日志分析或文件阅读，可以交给它们处理，让这些过程输出留在子任务里，减少对主会话的干扰。例如，只读审查子任务可以对照计划核对 diff，返回超范围改动、遗漏验证和风险的具体证据；主会话仍负责整合并核对结论。

团队用 GitHub 的话，也可以了解 Claude Code GitHub Actions。它在 GitHub Actions 工作流（workflow）中运行 Claude Code，可以把 issue 转成 PR、根据评论修 bug，也会参考项目说明和已有代码写法。这还涉及仓库权限、PR 权限和团队流程，等基础协作熟练后再学。

更进一步，如果要把 Claude Code 的能力做成自己的代理系统，可以看 Agent SDK。它提供与 Claude Code 相同的工具、代理循环和上下文管理，可以用 Python 或 TypeScript 编程调用，让代理读文件、运行命令、编辑代码。

增加代理前，先确认它能为当前任务带来什么。可独立调查的子问题、团队工作流和编程构建代理是三种不同的需求，按实际问题和已有基础分别选择。

08 七天只练一条路线

选路线时，对照自己的实际记录，把这几项想清楚：

我遇到的真实开发问题：
能证明这个问题的记录：
我最薄弱的协作步骤：
我选择的路线：
这条路线需要的前置能力：
本周明确暂缓的功能：

七天围绕同一条路线，每天安排一个能在可用时间内完成的小动作，留下文件、判断或验证记录。某天缺少前提，就先补齐或缩小任务，让当天的动作能做完。

天数	当天动作	可检查结果
第 1 天	从已有记录中确认一个具体问题	一段带证据的问题说明
第 2 天	学习该路线最基础的一个机制	一张边界说明卡
第 3 天	在低风险场景中做一次只读练习	一份分析记录
第 4 天	写一个最小配置、提示词或流程草案	一个可审查文件或草案
第 5 天	在练习项目中小范围试用	一份执行与验证记录
第 6 天	检查失败、风险和暂缓内容	一张修正清单
第 7 天	复盘路线是否解决原问题	继续、调整或更换路线的判断

例如选了项目记忆路线：第 2 天先分清 CLAUDE.md 和 auto memory；第 4 天写一份最小的 CLAUDE.md；第 5 天开新会话，检查规则有没有被读到。其他路线也一样，每次只学当前需要的机制；hooks、MCP 和 subagents，等出现对应问题时再学。

最后对照最初的问题与记录，检查路线是否匹配、每天的动作是否完成、结果能否核对。范围过大就缩小。七天后，那句“它总忘记测试”有没有少出现，就是决定继续、调整还是更换路线的依据。