用 Claude Code 30 分钟建立代码心智模型

程序员 60% 的时间花在读代码上，但没人教过你怎么读。接手陌生项目不是从 Controller 一路硬啃------Claude Code 能帮你在 30 分钟内建立一个项目的心智模型。五个技巧，从骨架到考古，一套组合拳打下来，三天的活压成半小时。

新入职第一天，leader 在群里丢过来一个仓库地址："你先熟悉一下 order-service，下周开始改需求。"

打开项目。README.md 最后更新时间：2023 年 8 月。打开 OrderController，87 个方法。点进 createOrder()，调了 OrderService，OrderService 调了 PriceCalculator，PriceCalculator 里面一个 switch-case 有 14 个分支，每个分支注释写着"临时方案"。

git log 看了一眼，最后一个 commit message 是"fix bug"，作者半年前离职了。

我以前的做法：泡三天，画流程图，写笔记，中间穿插十次"这写的什么玩意儿"。现在有一种更系统的方式。

1. 先要骨架，不要细节

接手陌生项目最蠢的做法：让 CC "帮我解释这个项目"。

它会给你一段话，大意是"这是一个基于 Spring Boot 的订单管理系统，采用了分层架构......"。谢谢，跟没说一样。

正确的姿势是分层提问，由粗到细。你不是要 CC 给你读代码，你是要它帮你画地图。

bash 复制代码

# 第一刀：模块全景
claude "列出项目所有 Maven 模块，每个模块一句话说清楚职责。只关注业务模块，忽略 common/util/config"

# 第二刀：主干路径
claude "这个项目核心业务流程有哪几条？从 HTTP 入口到数据库落库，画出主干路径。不要展开分支逻辑"

# 第三刀：承重墙
claude "哪些类是系统的核心抽象------改了会牵一发动全身的那种？列出来并说明为什么它们是承重墙"

三刀下去，5 分钟，你对这个系统的理解已经超过硬啃两小时的水平。

关键点：限定回答粒度。"一句话说清楚"、"只关注主干"、"不要展开分支"------这些约束让 CC 的输出从正确的废话变成有用的信息。

这一步的输出，直接贴进项目的 CLAUDE.md。后续所有对话都自动带上这个全景认知，CC 不会再每次重新分析。

2. 追调用链，不追实现

你要改 createOrder() 的逻辑，第一件事不是看它怎么实现的，是搞清楚它的影响范围。

自己追？从 Controller 往下点，到第三层你已经在想中午吃什么了。Spring 项目尤其恶心------@EventListener 在某个不相关的包里监听了 OrderCreatedEvent，@Async 让调用链在线程池里消失，AOP 切面在你看不见的地方拦截了一半逻辑。

这些"隐身调用"，人工阅读最容易漏，CC 最擅长抓。

bash 复制代码

# 向下追：这个方法触发了哪些 IO
claude "从 OrderService.createOrder() 开始，追踪到所有外部 IO：数据库写入、RPC 调用、MQ 发送、Redis 操作。列出完整链路，标注每一层做了什么数据转换"

# 向上追：谁在调这个方法
claude "OrderService.createOrder() 有哪些调用入口？包括 Controller、定时任务、MQ Consumer、其他 Service 的间接调用。我要知道改了这个方法谁会受影响"

进阶用法------反向追踪。你看到一段看不懂的 if-else，与其猜，不如让 CC 帮你追溯条件来源：

bash 复制代码

claude "OrderService.java 第 127-145 行这段特殊处理，追踪它依赖的所有条件来源。这些条件是业务规则还是技术约束？有没有对应的单测能说明意图？"

这一步的价值："追调用链"给你的是影响范围，不是实现细节。你知道改一行代码会炸多大一片，才能决定这刀该不该下。

3. 代码考古------还原"为什么"

每个屎山项目里都有那么几段代码：看着丑，但你不确定是前人的权宜之计还是深思熟虑。删了可能出事，留着碍眼。

以前问同事，同事说"我也不知道，反正别动"。现在同事已经是"半年前离职的那位"了。

CC 可以帮你做代码考古------结合 git history 判断一段代码的来龙去脉：

bash 复制代码

claude "分析 PaymentService.java 第 89-120 行这段逻辑。结合 git blame 和相关 commit message，告诉我：1. 什么时候加的 2. 当时的 commit 说了什么 3. 是临时 workaround 还是正式设计 4. 关联的 PR 或 issue 有没有更多上下文"

判断出"这是当年双十一前的紧急 hotfix"------你就敢删，因为那个场景可能早就不存在了。判断出"这是为了兼容历史订单的数据迁移"------你就知道别动，或者先确认迁移是否完成。

批量扫雷也很好用：

bash 复制代码

claude "扫描 order-service 模块，找出所有 TODO/FIXME/HACK/临时 注释。按风险分级：哪些是无害的待优化项，哪些是不处理早晚出事的定时炸弹"

我上次在一个项目里用这招，扫出来一个 // TODO: 这里有并发问题，上线前必须修------注释日期是 2022 年，线上已经跑了两年了。

4. 画边界------找出"不能动"和"随便改"

重构最大的恐惧不是"改不好"，是"不知道改了会影响谁"。

Java 项目在这方面其实比动态语言友好得多------你有 interface、有 package-private、有明确的 module 边界。问题是大部分人的代码里这些边界形同虚设，public 方法乱飞，DTO 满天跑。

让 CC 帮你把真实边界画出来：

bash 复制代码

# 分清 contract 和 implementation
claude "分析 OrderService 的所有 public 方法：1. 哪些被其他模块或服务调用（是 contract，不能随便改签名） 2. 哪些只有本模块内部调用（可以安全重构） 3. 哪些 public 但其实应该是 package-private（暴露过度）"

升级版------改一个 DTO 之前先做影响分析：

bash 复制代码

claude "如果我修改 OrderDTO 的字段结构，影响范围是什么？包括：Controller 返回值、Feign 接口定义、MQ 消息体序列化、前端对接的字段映射"

这个分析 2 分钟跑完，可能帮你省掉重构后半天的 CI 红灯。

我的习惯是把这类分析结果存进 Memory。下次要动相关代码时 CC 自动提醒你"上次分析过，OrderDTO 被 3 个下游服务依赖"。

5. 生成活文档------给下一个接盘侠留条活路

你终于读懂了这坨代码。如果不做任何沉淀，三个月后的你（或者下一个接手的倒霉蛋）又要重新受苦。

但写文档这事，Java 程序员有创伤------Confluence 上的设计文档，代码改了 17 版，文档还停留在第 1 版。

我的方案：不写传统文档，生成"导读"。关键区别：传统文档描述"系统是什么"，导读描述"从哪开始看"和"为什么这样"。

bash 复制代码

# 生成新人导读
claude "假设一个新同事下周接手 order-service，写一份 500 字的导读：从哪个类开始看、核心流程怎么走、哪些地方有坑要小心、哪些目录可以先跳过。语气像同事在工位上跟你聊天，不是写官方 wiki"

# 生成架构决策记录
claude "基于代码现状，总结 order-service 的 3 个关键设计决策。每个决策写清楚：选了什么、为什么不选另一种方案、什么情况下需要重新评估。每个 3-5 句话"

这些输出扔进项目根目录或 CLAUDE.md，维护成本接近于零------因为下次代码变了，你让 CC 重新跑一遍就行。

唯一要注意的：CC 偶尔会合理化一些没有理由的设计。它会给一段烂代码编一个听起来说得通的理由。生成后花 5 分钟人工 review，删掉那些"其实就是写烂了"的美化描述。

组合拳

五个技巧不是散装的，它们组成一套流程：

markdown 复制代码

接手新项目的标准动作（30-60 分钟）：

骨架（5 分钟）→ 画出全景地图
  → 调用链（10 分钟）→ 追出关键路径
    → 考古（10 分钟）→ 搞清历史决策
      → 边界（5 分钟）→ 标记安全区域
        → 活文档（10 分钟）→ 沉淀给下一个人

以前这套流程需要三天加一个热心老同事手把手带。现在老同事离职了，但你有 CC。区别是 CC 不会说"这个我也不清楚，问问张工吧"------它会直接把 git history 翻出来告诉你答案。