Claude Code 的记忆功能:如何在大型项目中使用 AI 编程

889 阅读17分钟

hello 大家好,这篇文章想跟大家聊聊 Claude Code 的记忆功能:如何在大型项目中使用 AI 编程 ,如果大家遇到任何问题,欢迎 联系我 或者直接微信添加 superZidan41

🔥🔥🔥 前方高能,干货满满,建议点赞➕关注➕收藏;

image.png

借助智能记忆管理,将 Token 成本转化为团队知识

1.Claude Code:这不是一款工具——而是一种思维方式的转变

多年来,我见过数十种声称将彻底改变我们写代码方式的开发者工具。大多数最终都只能在边角处帮点忙——自动补全一个函数、给点重构建议、也许加快模版代码的生成。说实用也没错。但称得上颠覆的很少。

Claude Code 则完全不同。

它不只是像个乐于助人的助手坐在你旁边。它与你一起思考。与你一起规划。与你一起重构。Claude Code 更像是一位具备资深洞察力的结对编程伙伴——就嵌在你的终端里,那里蕴含着上下文,无谓的干扰也随之消散。你给它一个目标,它不只是被动回应。它会制定计划,把工作拆解成任务,自己写代码和测试,然后输出往往无需再做微调的结果。

这正是让我耳目一新的地方:Claude Code 的表现像一位尊重这门手艺的工程师。它不靠花里胡哨的输出或肤浅的捷径来取悦你。相反,它直面工作的复杂性——并把事情做好。

依我浅见(也受终端提示所激发):Claude Code 是第一个像真正懂行那样写代码的 AI。它不只是你工作流中的一件工具。只要你愿意,它就是工作流本身。

2.为什么 token 效率很重要——以及“让 Claude 放手去干”的代价

当你在大型代码库上使用 Claude Code 时,开发流程会发生根本性的变化。你不再只是来回切换在编码和提示之间。相反,Claude 会在很长一段时间里掌舵。你交给它一个任务,它会安静地“热身”,甚至在开始输出一行文字之前就已经做了:遍历你的代码库、学习你的设计模式、理解架构、制定策略等事情。

这种深度思考的方式让 Claude Code 功力非凡——但也以一种非常具体的方式让它变得十分昂贵。

无论你使用按量付费的 API 模式,还是像 Claude MAX 这样的固定月费计划,每个请求都会消耗 token——而这些 token 是有上限的。计费不仅取决于使用频率,还取决于它读取了多少、思考得多深入。

每次和 Claude 的交互都包含三个相互关联的成本驱动因素:

成本 =(LLM 调用次数)×(每次调用的 token 数)×(模型质量)

首先是你发起的调用次数。每当 Claude 开始“思考”,都算一次。然后是它需要思考的程度——这直接取决于你的请求消耗了多少 token。尤其在大型代码库上,即便看似简单的问题,Claude 往往也需要加载成千上万行的上下文。最后是你选择的模型。比如 Claude Opus 会给出更深入、更细腻的回答,胜过 Sonnet——但它的每个 token 成本也显著更高。

人们很容易陷入一种陷阱:一遍又一遍地让 Claude 去“自己搞定”——让它反复解析同样的文件、重建同样的结构、从头重新分析架构。结果呢?你在不知不觉中烧光了 token 预算,原本指望的效率提升反而烟消云散。

这就是为什么理解并管理 Claude 的记忆系统至关重要。这就像与一个记得你蓝图的建筑师合作,和一个每次你提问都得把蓝图重读一遍的建筑师合作之间的差别。

接下来让我们看看它是如何运作的。

3.Claude Code 记忆系统:你的持久化上下文架构师

Claude Code 的记忆系统表面上看似简单——它不过是一些 Markdown 文件。但在这份简单背后,隐藏着一个复杂的层级系统,从根本上改变了 AI 对你的代码库的理解方式。

三层架构

可以把 Claude 的记忆看作一组嵌套的上下文,每一层都有其特定用途:

项目记忆(./CLAUDE.md) —— 这是你们团队的共享大脑。它位于代码仓库根目录,并会提交到版本控制。在这里记录架构决策、编码规范、API 模式,以及任何需要在团队内保持一致的内容。新成员加入时,他们继承的不仅是代码——更是关于这份代码应如何演进的集体智慧。

本地项目记忆(./CLAUDE.local.md) —— 你的个人工作区笔记。也许你在对某个特定的沙箱 URL 进行测试,或者为这个项目总结了特有的调试策略。该文件会被 .gitignore 忽略,将你的个人偏好和临时上下文与团队的共享知识区分开来。它就像显示器上的便利贴——只不过 Claude 也能读到。

用户记忆(~/.claude/CLAUDE.md) —— 你的全局偏好,随你在所有项目间一同携带。更喜欢用 Tab 键而不是空格键?总是使用特定的 ESLint 规则?有一套固定的提交结构方式?这些偏好都放在这里,并会在你的主目录下自动合并到每一次 Claude 会话中。

Claude 如何加载上下文

关键之处在于 Claude 如何发现并加载这些文件。它并不是简单的“全部加载”——那会立刻耗尽你的 token 预算。相反,Claude 采用一种既全面又高效的递归搜索策略。

从你的当前工作目录开始,Claude 会向上逐级搜索直至根目录,加载它找到的每个 CLAUDE.md 和 CLAUDE.local.md 文件。这意味着你可以在仓库根目录放置通用指南,而在越深入的子目录中提供越具体的说明。源代码树深处的某个 React 组件可以拥有自己的记忆文件,包含组件特定的模式,同时仍然从上层继承更广泛的架构上下文。

巧妙之处在于:只有当 Claude 实际访问某个子目录中的文件时,才会加载该子目录的记忆文件。这种按需加载让你的活跃上下文保持聚焦,避免在与当前无关的代码库部分上浪费 token。

# Claude 的内存加载策略

~/.claude/
├── CLAUDE.md ----------------------┐
│   [全局偏好设置]                    │  始终加载
│                                    │  (在主目录下)
~/projects/awesome-app/              │
├── CLAUDE.md ----------------------┘
│   [项目架构,团队规则]              │
├── CLAUDE.local.md                  │  在项目中工作时加载
│   [你的沙盒 URL,本地笔记]          │
│                                    │
├── apps/                            │
│   ├── web/                         │
│   │   ├── CLAUDE.md --------------┐│
│   │   │   [React 模式,UI 规则]      ││   仅在 apps/web/**
│   │   ├── components/              ├┤   中工作时加载
│   │   └── Button.tsx -------------┘│
│   │                                 │
│   ├── api/                          │
│   │   ├── CLAUDE.md                 │   在处理 Button.tsx 时
│   │   │   [API 模式,REST 规则]      │   不加载
│   │   └── services/                 │
│   │                                 │
├── infrastructure/                   │
│   ├── CLAUDE.md                     │   在处理 Button.tsx 时
│   │   [Terraform 模式,AWS]          │   不加载
│   └── modules/                      │
│                                     │
└── docs/                             │
    └── architecture.md ---------------
        [@imported 仅在需要时导入]

## 在处理 Button.tsx 时,Claude 加载:

-`~/.claude/CLAUDE.md` (全局记忆)
-`~/projects/awesome-app/CLAUDE.md`
-`~/projects/awesome-app/CLAUDE.local.md`
-`~/projects/awesome-app/apps/web/CLAUDE.md`
-`~/projects/awesome-app/apps/api/CLAUDE.md`
-`~/projects/awesome-app/infrastructure/CLAUDE.md`

导入系统:模块化记忆管理

随着项目规模增长,记忆文件可能会变得臃肿难以管理。社区发现,Claude 支持一种使用 @path/to/file 语法的导入系统。这样一来,你可以让主记忆文件保持精简,同时维护可按需加载的详细规范。

例如,你的项目根目录下的 CLAUDE.md 可能如下所示:

# 项目概览
采用微服务后端的 Next.js 应用程序
# 架构
@docs/architecture/overview.md
@docs/architecture/api-design.md
# 编码规范
- TypeScript 严格模式
- 使用 Hooks 的函数式组件
- @standards/testing-guidelines.md

这种模块化方法意味着,Claude 只会在需要编写或审查测试时才加载详细的测试指南,从而使你的基础上下文保持高效。

记忆实践:真正有效的模式

通过社区的大量实践,已经涌现出几种特别有效的模式:

引导模式(The Bootstrap Pattern) :用 /init 开启新项目,它会分析你的代码库并生成一份全面的初始 CLAUDE.md 文件。这就像让 Claude 采访你的代码库,并为后续会话做笔记。

快速记忆模式(The Quick Memory Pattern) :在任何指令前加上 #,即可立即将其加入记忆。发现你的构建系统有个小问题?只需输入 # build fails if NODE_ENV isn't set explicitly,Claude 就会把它归档到相应的记忆文件中。

检查点模式(The Checkpoint Pattern) :在进行重大重构之前,明确告知 Claude 用当前的架构决策更新记忆文件。这样就会创建一个知识检查点,即使你需要开启一个全新的会话,它也会持续存在。

遗忘的代价

如果没有恰当的记忆管理,每次 Claude 会话都要从零开始。对于大型代码库,这意味着:

  • 反复讲解你的架构(每次 500–1000 个 token)
  • 重申编码规范(200–500 个 token)
  • 澄清项目特定的模式与惯例(300–800 个 token)
  • 纠正对你的技术栈的误解(每次纠正 100–300 个 token)

把这些乘以数十次会话,你会发现由于不必要的 token 消耗而花掉数千美元——更不用说因重复解释而损失的时间。

记忆维护:保持你的上下文新鲜

与任何知识系统一样,Claude 的记忆需要维护。记忆文件中过时或不正确的信息会把 Claude 误导,造成的危害甚至可能大于没有记忆。社区已经形成了几种维护策略:

定期审查:定期将记忆文件与实际代码库进行比对审计。架构在演进,模式在变化,昨日的最佳实践可能已成为今日的反模式。

范围化更新:当你就某个具体实现细节纠正 Claude 时,立刻更新相应的记忆文件。这样可以防止在后续会话中重复发生相同的误解。

记忆预算:将核心记忆文件控制在 500 行以内。对于详细规格,使用导入来引用,并且要果断清理过时信息。

最成功的团队把 Claude 的记忆文件当作活文档——不仅服务于 AI,也服务于整个开发团队。它们已成为一种新的架构决策记录形式,并随其所描述的代码库持续演进。

4.如何让 Claude Code 的记忆保持高效并及时更新

在使用 Claude Code 一段时间后,我整理出一套提示词,能把记忆管理从一件苦差事变成开发工作流中无缝衔接的一部分。这些不仅仅是命令——它们是一种对话,能教会 Claude 成为你特定项目中更好的合作伙伴。

教会 Claude 记忆:会话学习提示词

在 AI 辅助开发中,最大的浪费不是 token 消耗,而是知识流失。每次你纠正 Claude 或解释项目中的独特之处,这些学习通常会在会话结束时消失。下面是我用来将这些核心内容永久保存的提示词

# 使用本次会话中的相关知识更新 CLAUDE 文件

供参考:你(Claude Code)使用两种主要文件类型来管理持久化记忆:用于共享或全局项目上下文的 `CLAUDE.md`,以及用于私有、开发者特定笔记的 `CLAUDE.local.md`。系统会从当前工作目录开始向上递归搜索,加载所有相关的 `CLAUDE.md``CLAUDE.local.md` 文件,确保项目层面与个人上下文均可用。子目录中的 `CLAUDE.md` 仅在你在这些子文件夹内工作时才会被加载,从而保持当前上下文聚焦且高效。此外,在你的主目录放置一个 `CLAUDE.md`(例如 `~/.claude/CLAUDE.md`)可提供跨项目的全局个人记忆,它会自动合并进你主目录下的每个会话。

记忆文件行为摘要:
- 共享项目记忆(`CLAUDE.md`):
  - 位于代码仓库根目录或任意工作目录
  - 纳入版本控制,便于团队范围的上下文共享
  - 从当前目录向上递归加载直到根目录
- 本地、非共享记忆(`CLAUDE.local.md`):
  - 放在工作文件旁边或其上层目录,不纳入版本控制
  - 存储私有的、开发者特定的笔记与设置
  - 加载方式与 `CLAUDE.md` 相同,为递归加载
- 按需加载子目录:
  - 子文件夹中的 `CLAUDE.md` 仅在编辑该子文件夹内的文件时加载
  - 防止不必要的上下文膨胀
- 全局用户记忆(`~/.claude/CLAUDE.md`):
  - 作为个人的、跨项目的记忆
  - 会自动合并到主目录下的各个会话中

---
说明:
如果在本次会话期间:
- 你学到了关于项目的新内容
- 我对某个具体实现细节纠正了你
- 我纠正了你生成的源代码
- 你一时找不到特定信息而不得不对项目细节进行推断
- 你对项目结构一度失去跟踪,不得不在源码中查找信息

并且这些内容是相关的、起初未知且应当持久保存,请将其添加到相应的 `CLAUDE.md`(用于共享上下文)或 `CLAUDE.local.md`(用于私有笔记)文件中。若信息仅与某个子目录相关,请在该子目录内的 `CLAUDE.md` 中放置或更新。

当特定信息属于某个具体子组件时,请确保把它放入该组件对应的 CLAUDE 文件。例如:
- 信息 A 仅属于 heatsense-ui 组件 → 放入 apps/heatsense-ui/CLAUDE.md
- 信息 B 仅属于 heatsense-api 组件 → 放入 apps/heatsense-api/CLAUDE.md
- 信息 C 属于基础设施即代码(IaC)相关 → 放入 cdk/CLAUDE.md

我会在每次关键的会话结束后运行这个提示词,尤其是在深入调试或架构讨论之后。这就像让 Claude 为下一次会议自己写笔记——只是下一次会议的对象可能会换成你团队里的另一位开发者。

目录深度解析:从代码中构建上下文

当我在代码库的某个新模块开始工作,或者当 Claude 似乎缺少关键上下文时,我会使用这条排查提示。它之所以特别有用,是因为它会迫使 Claude 在做出任何假设之前,先真正阅读并理解代码。

    # 调研并记录目录架构
    **说明**:
    聚焦于指定目录 $ARGUMENTS 或当前工作目录:

    1. **调研架构**:分析该目录及其子目录中代码的实现原理与架构。重点关注:
       - 使用到的设计模式
       - 依赖项及其用途
       - 关键抽象与接口
       - 命名约定与代码组织

    2. **创建或更新文档**:创建一个 CLAUDE.md 文件,汇总上述信息;如果已存在,请用新发现进行更新。内容应包括:
       - 模块的目的与职责
       - 关键架构决策
       - 重要实现细节
       - 代码中普遍使用的模式
       - 可能的陷阱与不明显的行为

专业提示:你可以把第一个提示词中的会话学习上下文加入到这条提示中,以增强其效果。这样会生成更全面的文档更新,既涵盖代码分析,也包含你当前会话中的任何更正或澄清。

清理:保持记忆准确

记忆文件和任何文档一样,可能会与现实脱节。代码在演进,模式在变化,昨日的真理可能成了今日的误解。下面是我每月(或在重大重构之后)运行的维护提示词:

    # 审查并更新 CLAUDE 记忆文件
    **说明:**  
    **第1步:获取概览**  
    列出项目层级中的所有 CLAUDE.md 和 CLAUDE.local.md 文件。

    **第2步:迭代式审查**  
    系统化地处理每个文件,从根目录的 `CLAUDE.md` 文件开始:
    - 加载当前内容
    - 将文档中记录的模式与实际实现进行比较
    - 识别过时、不正确或缺失的信息

    **第3步:更新与重构**  
    对于每个记忆文件:
    - 将所有技术性陈述与当前代码库进行核对
    - 移除过时的信息
    - 合并重复条目
    - 确保信息位于最合适的文件中

    当信息属于某个特定子组件时,确保其被正确放置:
    * 与 UI 相关的模式 → `apps/myproject-ui/CLAUDE.md`
    * API 约定 → `apps/myproject-api/CLAUDE.md`
    * 基础设施细节 → `cdk/CLAUDE.md` 或 `infrastructure/CLAUDE.md`

    关注清晰性、准确性和相关性。删除任何对项目不再有用的信息。

这不仅仅是做做家务式的清理——而是对未来生产力的投资。干净、准确的记忆文件意味着 Claude 在每次会话开始时都拥有正确的上下文,从而减少 token 使用量和挫败感。

将这些提示词变成你自己的

这些提示词在我的工作流程中效果不错,但真正的力量来自根据你的需求进行适配。有的团队会新增“测试策略”部分,另一些会加入“部署说明”,我还见过开发者针对 API 文档或数据库模式更新创建专门的提示词。

核心思想?把这些提示词当作模板,而不是金科玉律。从我分享的版本起步,但要依据你项目的独特需求不断演进。最好的记忆管理系统,是你们团队真正会使用的那个。

最后补充一点:我注意到坚持做记忆维护的团队会获得复利式收益。Claude 不仅会随时间变得更有帮助,这些记忆文件本身也会成为对人类开发者极具价值的上手和入职文档。这是会自我生成的文档——并且因为被持续使用而始终保持最新。

这正是 Claude Code 的记忆系统之妙。它不只是让 AI 更聪明,而是用于捕捉并保存你整个开发过程的集体智慧。

结语:我们都还在学习

我写代码的年头多得都不太想承认了,而 Claude Code 是第一个让我从根本上重新思考开发方式的工具。并不是因为它能写出完美的代码——它做不到;也不是因为它从不犯错——它会犯错;而是因为它让我看到,AI 辅助开发的真正瓶颈不在于 AI 的能力,而在于我们能否有效地共享上下文。

我这里分享的记忆技巧并不完美。它们只是我和我的团队在反复尝试、偶尔受挫,以及付出不止几次高昂 token 账单之后,发现行之有效的方法。我相信还有更好的模式有待发掘。这正是令人兴奋之处——在这个领域里,我们都是先行者,正共同探索以全然不同的方式构建软件。

如果你已经摸索出管理 Claude 记忆的自有模式,我很想听听你的做法。若你尝试了这些方法并找到了改进之道,那就更好了。与 Claude Code 这样的工具共事,最美妙的一点在于:我们不仅是技术的使用者——我们还在积极塑造未来开发者的工作方式。

最后再补一句:这些记忆系统再强大,也只是一个起点。真正的魔力在于,当你不再把 Claude 视作工具,而是把它当作一位团队成员——恰好具备完美记忆、无限耐心,并渴望学习你那一套独特的构建软件方式。愿我们少些重复解释,多些保留下来的洞见,拥有会“记住自己故事”的代码库。愿你使用的 token 越来越少、上下文越来越丰富。

编程愉快——也祝你能够愉快地教会你的 AI 编程伙伴记住项目中的核心信息。

本文为翻译文,原文地址:medium.com/@tl_99311/c…