Claude Code Skills 完全指南7：如何构建可复利增长的项目上下文？
一只阿木木约 20 分钟知识管理系统：如何构建可复利增长的项目上下文？
这是「Claude Code Skills 完全指南」系列的第七篇。建议先阅读前六篇再继续。
写在前面
前六篇构建了一条从单 Skill 到多 Skill 编排的完整技术链路。你现在知道怎么设计 Skill、怎么让它触发、怎么组织内容、怎么管理上下文、怎么把多个 Skill 编排成工作流。
但有一个你每天都在经历、却可能从未认真对待的问题：
昨天的 Claude，不记得前天的你。
你花了四小时调试一个棘手的数据库迁移，和 Claude Code 来回交流了三十条消息，搞清楚了精确的 schema 演化过程。然后你关了终端，吃完晚饭回来，开了一个新会话——Claude 完全不知道你们之前搞明白了什么。你写的 CLAUDE.md 太笼统。Git 提交记录在，但"为什么"消失了。
每过几天，你开始一个新的 Claude Code 会话，又要重新解释你的项目——架构、你做的决策、你遵循的模式、你发现的坑。Claude Code 在会话内很强大。但在会话之间，它失忆了。
这个问题的表层是"记忆"，但本质是知识管理。前六篇教你如何往 Claude 的脑子里"装"东西（Skills）。这篇教你如何让装进去的东西持久化、结构化、可增长——让每一次使用都让系统变得更聪明。
一、Claude Code 的记忆架构：两个系统，三个层级
1.1 两个互补的记忆系统
Claude Code 有两个互补的记忆系统。每次会话都从一个全新的上下文窗口开始。两种机制将知识传递到会话之间：CLAUDE.md 文件——你编写的持久化指令；Auto memory——Claude 基于你的纠正和偏好自动记录的笔记。两者都在每次对话开始时加载。
Claude 将它们视为上下文，而不是强制配置。你的指令越具体和简洁，Claude 就越一致地遵循它们。
1.2 三个记忆层级
三个记忆层级共存——项目级、用户级和自动记忆——采用自上而下的冲突解决机制。
让我画一张完整的层级图：
text
┌──────────────────────────────────────────────────────────┐
│ 第 1 层：用户级（~/.claude/CLAUDE.md） │
│ · 你所有项目都适用的全局偏好 │
│ · 个人工作风格、语言偏好、通用工具配置 │
│ · 示例："回复使用中文" / "优先使用 pnpm" │
└──────────────────────────────────────────────────────────┘
↓ 加载到每个项目
┌──────────────────────────────────────────────────────────┐
│ 第 2 层：项目级（./CLAUDE.md + 目录级 CLAUDE.md） │
│ · 项目特定的架构、约定、工作流 │
│ · 提交到 git，团队共享 │
│ · 目录级覆盖：src/auth/CLAUDE.md、src/api/CLAUDE.md │
└──────────────────────────────────────────────────────────┘
↓ 仅在该目录中工作时加载
┌──────────────────────────────────────────────────────────┐
│ 第 3 层：自动记忆（~/.claude/projects/<project>/memory/） │
│ · Claude 自己记的笔记——构建命令、调试洞察、架构决策 │
│ · 纯 Markdown，可阅读、编辑、删除 │
│ · 机器本地化，不提交到 git │
└──────────────────────────────────────────────────────────┘
冲突时，项目 CLAUDE.md 优先于用户文件。自动记忆作为补充，永远不会覆盖前两者。
1.3 自动记忆：Claude 自己的笔记本
自动记忆让 Claude 在会话之间积累知识，无需你写任何东西。Claude 在工作时为自己保存笔记：构建命令、调试洞察、架构笔记、代码风格偏好和工作流习惯。Claude 不会每次会话都保存东西。它根据信息是否在未来对话中有用来决定值不值得记住。
自动记忆在 2026 年 2 月 26 日的 v2.1.59 中发布。它的范围是按项目的——每个 git 仓库一个记忆目录，如果你在 git 仓库外则按工作目录。
记忆目录包含一个 MEMORY.md 入口点和可选的主题文件。MEMORY.md 充当记忆目录的索引。Claude 在会话中读写这个目录中的文件，用 MEMORY.md 来追踪什么存储在哪里。
text
~/.claude/projects/<project>/memory/
├── MEMORY.md # 简洁索引，每次会话都加载
├── debugging.md # 调试模式的详细笔记
├── api-conventions.md # API 设计决策
└── ... # Claude 创建的其他主题文件
自动记忆文件是纯 Markdown，你可以随时编辑或删除。运行 /memory 可以从会话中浏览和打开记忆文件。
二、为什么 90% 的人没有用好记忆系统？
好消息是：Claude Code 实际上有一个强大的多层记忆系统。大多数开发者可能只使用了它 10% 的功能。
在 2026 年，记忆系统仍然是 Claude Code 中最未被充分利用的生产力杠杆。只有 35% 的用户配置了结构化的 CLAUDE.md，尽管投资回报是即时的。
为什么？因为大多数人犯了同一个错误。
很多人得出了一个错误的结论。他们想："如果这只是被注入的文本，我应该描述所有东西。每个偏好。每个边界情况。每个可能的交互。"
这引出了知识管理的核心悖论：你想让 Claude 知道一切，但你给它的信息越多，它遵循每一条的概率就越低。
一个高性能的 CLAUDE.md 遵循精确的原则。200 行以内的文件实现了超过 92% 的规则应用率，而超过 400 行的文件只有 71%。
一个 500 行的 CLAUDE.md 淹没了关键指令。Claude Code 以最大注意力处理前 200 行。超过这个数字，权重下降。应该将内容拆分为模块化规则。
在实践中，一个 80 行的 CLAUDE.md 在一个 50,000 行的 TypeScript 项目上减少了 40% 的手动纠正。
三、记忆的分层策略：什么放在哪里？
3.1 决策框架
如果你希望 Claude 在 6 个月后还知道某件事，就把它放在 CLAUDE.md 里。如果它可能下周就变了，改用提示。
对于只在某些时候才相关的领域知识或工作流，使用 Skills。Claude 按需加载它们，不会膨胀每次对话。
把 CLAUDE.md 保留给持久的、跨领域的、非敏感的指令——其他一切都有更好的去处。
让我用一张决策表把这些原则统一起来：
text
这条知识的特征是什么？ 放在哪里？
──────────────────────────────────────────────────────────
每次会话都需要 + 6 个月不变 → CLAUDE.md
每次会话都需要 + 可能经常变 → 对话中提供，不写入文件
某些任务才需要 + 是工作流/标准 → Skill（.claude/skills/）
某些任务才需要 + 是参考知识 → Skill 的 references/ 目录
偶尔需要 + 高度动态 → Auto memory（Claude 自行管理）
特定目录才需要 → 目录级 CLAUDE.md
一次性信息 → 直接在对话中说，不持久化
──────────────────────────────────────────────────────────
3.2 一个真实案例：从 189 行到 63 行
一位开发者的 ~/.claude/CLAUDE.md 从 189 行减少到了 63 行。七个新文件放入 ~/.claude/memory/，覆盖了之前被塞进 CLAUDE.md 的工具和领域知识。三个新文件放入项目记忆，用于当前正在工作的仓库。还有一个指针条目用于某个产品。加上一个自动初始化指令，让每个新项目从第一天就获得这个结构。
那个臃肿的 CLAUDE.md，之前每次会话都加载 155 行密集的参考内容，现在变成了 63 行——指向在需要时才加载的文件。小事情。复合增长。
这就是知识管理的核心操作：从"全塞进 CLAUDE.md"到"分层按需加载"。
四、构建可复利增长的知识系统
4.1 复合效应的原理
把 CLAUDE.md 提交到 git，这样你的团队可以贡献。这个文件的价值随时间复合增长。
当你输入 /project ilp-website，Claude 加载上次会话的项目状态、它学到的关于 WordPress 发布怪癖的教训、上周做的 SEO 决策、以及昨天每日日志中的未结线索。整个过程大约四秒钟。当它犯了错，这个错误变成永久的教训。下次会话，它不会再犯。当你说"flush"，它捕获你们做的所有事情、每个决策、每条未结线索，写入三个位置，然后你才关闭终端。当你明天或下周回来，上下文就在那里。
这就是复合效应：每一次会话不只是完成了工作，还让系统学到了新东西。下一次会话从更高的基线开始。
4.2 三级知识架构
不是所有记忆都平等。有些上下文每次会话都需要。有些只是偶尔需要。把所有东西放进 CLAUDE.md 浪费上下文窗口。把所有东西放进数据库意味着 Claude 必须主动搜索基础知识。
第一层：CLAUDE.md（约 150 行）——一份紧凑的简报文档，自动生成和自动更新。包含按置信度和访问频率排名的最重要项目知识。Claude 在启动时自动读取，零提示。
有时第一层不够。Claude 可能需要记起三周前的一个特定 API 设计决策，或者数据库 schema 选择背后的理由。这就是第二层的用武之地——按需搜索的更深层记忆。
text
第 1 层：始终加载（< 200 行）
┌─────────────────────────────────────┐
│ CLAUDE.md │
│ · 项目架构和技术栈 │
│ · 核心约定和规范 │
│ · 构建/测试命令 │
│ · 最重要的 3-5 条规则 │
│ · 面包屑指向第 2 层 │
└─────────────────────────────────────┘
↓ 按需加载
第 2 层：引用文件 + Skills
┌─────────────────────────────────────┐
│ .claude/rules/ │
│ .claude/skills/ │
│ Auto memory topic files │
│ · 详细的编码规范 │
│ · 特定模块的知识 │
│ · 工作流模板 │
└─────────────────────────────────────┘
↓ 深度搜索
第 3 层：外部记忆（可选）
┌─────────────────────────────────────┐
│ MCP 记忆服务器 │
│ Daily logs │
│ 决策记录归档 │
│ · 三周前的 API 设计决策 │
│ · 历史调试记录 │
│ · 全文搜索 │
└─────────────────────────────────────┘
4.3 面包屑技巧：连接层级之间的桥梁
面包屑技巧——在 CLAUDE.md 的末尾放置类似"详情见 MCP memory，标签 [josui, persona]"的指引。这些面包屑告诉模型更丰富的上下文存在于记忆中以及在哪里找到它。即使模型跳过了"会话开始时搜索记忆"的显式指令，它也经常在对话需要更深上下文时遵循这些嵌入的引用。静态文本种下了"记忆存在且可搜索"的想法，模型就会据此行动。
这是一个极其实用的模式：第一层不需要包含所有答案，但必须包含"答案在哪里找"的线索。
Markdown
# CLAUDE.md（项目级）## Architecture
- pnpm monorepo with 3 packages: api, web, shared
- Database: PostgreSQL 16 via Prisma 5.x
## Conventions
- See .claude/rules/code-style.md for detailed conventions
- See .claude/skills/api-conventions/ for REST API standards
## Memory References
- Authentication patterns → auto memory: api-conventions.md
- Debugging history → auto memory: debugging.md
- Past decisions → daily logs in ~/llm-data/daily-log/
五、CLAUDE.md 的工程化管理
5.1 像管理代码一样管理 CLAUDE.md
把 CLAUDE.md 当作代码来对待：当事情出错时审查它，定期修剪它，并通过观察 Claude 的行为是否真的改变来测试变更。
这不是比喻——这是字面意思。CLAUDE.md 应该：
有版本控制：提交到 git，团队可以 PR 和 review 有测试：观察 Claude 是否遵循了规则，如果没有，修改规则或修剪文件 有重构：定期将过长的内容拆分到 rules/ 或 skills/ 中
保持简洁。对每一行，问自己："删除它会导致 Claude 犯错吗？"如果不会，就删掉。臃肿的 CLAUDE.md 文件会导致 Claude 忽略你的实际指令！如果 Claude 尽管有规则却一直做你不想要的事，文件可能太长了，规则被淹没了。
5.2 CLAUDE.md 的最佳模板
用清晰的 Markdown 标题组织文件为明确的块。Claude Code 按顺序读取文件，并对前面的行赋予更多权重。
基于这个原则，CLAUDE.md 应该按优先级从高到低组织：
Markdown
# [项目名]## Critical Rules (最重要的放最前面)
- NEVER commit directly to main
- ALWAYS run tests before creating PR
- Use TypeScript strict mode
## Architecture
- pnpm monorepo: api/, web/, shared/
- Database: PostgreSQL 16 via Prisma 5.x
- Auth: JWT + refresh tokens
## Commands
- Build: pnpm build
- Test: pnpm test
- Lint: pnpm lint
## Conventions
- See .claude/rules/ for detailed style guides
- See .claude/skills/ for workflow patterns
## Compression Guidance
When compacting, always preserve:
- The complete list of modified files
- All test commands and their results
- Current task status and next steps
CLAUDE.md 完全存活于压缩之后。执行 /compact 后，Claude 从磁盘重新读取你的 CLAUDE.md 并将其重新注入会话。如果某个指令在压缩后消失了，说明它只是在对话中给出的，没有写入 CLAUDE.md。把它加入 CLAUDE.md 使其跨会话持久化。
5.3 模块化规则系统
当 CLAUDE.md 接近 200 行时，是时候拆分了。
文件超过 200 行会消耗更多上下文，可能降低遵循率。将详细内容移到用 @path 导入引用的独立文件中，或将指令拆分到 .claude/rules/ 文件中。
text
.claude/
├── rules/
│ ├── code-style.md # TypeScript 编码风格（条件加载）
│ ├── testing.md # 测试规范（条件加载）
│ ├── git-workflow.md # Git 工作流（条件加载）
│ └── security.md # 安全规则（条件加载）
├── skills/
│ ├── api-conventions/ # API 规范 Skill
│ └── code-review/ # 代码审查 Skill
└── settings.json # Hooks 配置
当两个层级矛盾时，Claude Code 应用最具体的规则。在实践中，一个 .claude/rules/testing.md 中强制使用 Jest 的文件会覆盖根 CLAUDE.md 中提到 Vitest 的内容。这种特异性逻辑覆盖了 95% 的冲突情况。
六、自动记忆的管理策略
6.1 让 Claude 自己学习
自动记忆让 Claude 在会话之间积累知识，无需你写任何东西。Claude 在工作时为自己保存笔记：构建命令、调试洞察、架构笔记、代码风格偏好和工作流习惯。Claude 不会每次会话都保存。它根据信息在未来对话中是否有用来决定值不值得记住。
当你要求 Claude 记住某件事，比如"总是用 pnpm，不要用 npm"或"记住 API 测试需要本地 Redis 实例"，Claude 会保存到自动记忆。要将指令添加到 CLAUDE.md 中，直接告诉 Claude"把这个加到 CLAUDE.md"，或通过 /memory 自行编辑。
6.2 定期维护自动记忆
定期检查 MEMORY.md 的内容——删除过时的观察。避免与 CLAUDE.md 重复——如果一条规则是稳定的，将其移到 CLAUDE.md。MEMORY.md 是 Claude Code 的自我喂养记忆——定期检查它，并将稳定的观察移到 CLAUDE.md。
这是一个被大多数人忽略的维护任务。自动记忆会随时间膨胀——Claude 保存了越来越多的笔记，其中一些可能已经过时或与 CLAUDE.md 重复。
维护流程（建议每两周一次）：
text
1. 运行 /memory 查看所有记忆文件
2. 对每一条记忆问：
□ 这还准确吗？（过时的 → 删除）
□ 这已经在 CLAUDE.md 中了吗？（重复 → 删除）
□ 这够稳定应该"升级"到 CLAUDE.md 吗？（是 → 移动）
□ 这只对我有用还是对团队也有用？（团队 → 项目 CLAUDE.md）
3. 将清理后的变更提交
6.3 知识"毕业"路径
知识在系统中有一个自然的生命周期：
text
对话中的临时提供 → Auto memory 记录 → CLAUDE.md 规则 → Skill 标准化例如：
第 1 天：你告诉 Claude "用 Zod 做验证"
第 3 天：Claude 自动记忆了这个偏好
第 7 天：你确认这是稳定规则，移到 CLAUDE.md
第 14 天：你基于这个规则构建了一个完整的 validation Skill
每一次"毕业"都让知识更结构化、更可复用、更不容易丢失。这就是复合增长的机制。
七、会话连续性：跨会话不丢失上下文
7.1 Session Memory：后台自动运行
Session Memory 是 Claude Code 的自动后台系统，用于跨会话记住你做了什么。与 CLAUDE.md 不同——后者需要你手动编写和维护——Session Memory 无需你任何输入就能运行。它观察你的对话，提取重要部分，并将结构化摘要保存到磁盘。
在会话开始时会出现"Recalled X memories"——Claude 加载了此项目中先前会话的摘要。"Wrote X memories"在会话期间周期性出现——Claude 刚保存了当前工作的快照。两条消息都包含 (ctrl+o to expand)，方便你检查被召回或写入的确切内容。
当你开始新会话时，Claude 将相关的过去会话摘要注入其上下文。这些摘要带有一个注释："来自可能与当前任务无关的过去会话。"Claude 将它们作为背景知识使用，而不是活跃指令。这意味着 Claude 不会盲目遵循三周前的决策。它将过去的会话视为参考材料，给你上下文的连续性而不会有硬编码指令的僵化。
7.2 结构化交接：/flush 模式
当自动记忆不够时——比如你需要精确控制保留什么——你需要手动的"交接"仪式。
每日日志：一个文件一天。每次 /flush 追加一个带时间戳的条目，记录做了什么、做了什么决策、未结线索和学到的教训。来自 cron 的自动心跳告警也写在这里。
每个项目的 State 部分小到加载它不会吃掉上下文窗口，但详细到 Claude 能精确地从上次中断的地方继续。在两天内，他在项目之间跳转了几十次，没有丢失一条线索。
你可以构建一个简单的 /flush Skill：
Markdown
---
name: flush
description: >
Save current session state. Use when user says "flush",
"save state", "wrap up", or "end of day".
disable-model-invocation: true
---## End-of-Session Flush
1. Summarize what was accomplished this session
2. List all files modified
3. Note any decisions made and their rationale
4. Record open questions or unfinished work
5. Write everything to daily log file:
~/llm-data/daily-log/YYYY-MM-DD.md (append)
6. Update project's MEMORY.md with new learnings
7.3 API Memory Tool：长期项目的终极武器
Memory tool 使 Claude 能够通过记忆文件目录跨对话存储和检索信息。Claude 可以创建、读取、更新和删除跨会话持久化的文件，使它能随时间构建知识而不必将所有内容保持在上下文窗口中。这是即时上下文检索的关键原语：Agent 不是预先加载所有相关信息，而是将学到的东西存入记忆并按需取回。这使活跃上下文聚焦于当前相关的内容——对于加载所有内容会压垮上下文窗口的长期运行工作流至关重要。
对于跨越多个 Agent 会话的长期运行��件项目，记忆文件需要刻意地被引导，而不是随着工作进展临时写入。这种模式将记忆变成结构化的恢复机制，使每个新会话都能精确地从上一个会话中断的地方继续。初始化会话：第一个会话在任何实质性工作开始之前设置记忆工件。这包括一个进度日志（追踪做了什么和下一步是什么）、一个功能清单（定义工作范围）、以及对项目需要的任何启动脚本的引用。
会话结束更新：在会话结束之前，更新进度日志记录完成了什么和剩余什么。这确保下一个会话有准确的起点。一次只处理一个功能。只有在端到端验证确认功能可用后才标记为完成——而不仅仅是代码写完。这使进度日志可信并防止范围蔓延跨会话复合。
八、完整的知识管理目录结构
综合上述所有内容，这是我推荐的项目级知识管理结构：
text
project-root/
│
├── CLAUDE.md # 🧠 第 1 层：核心记忆（< 200 行）
│ ├── Critical Rules # 最重要的规则放最前
│ ├── Architecture # 技术栈和架构
│ ├── Commands # 构建/测试/部署命令
│ ├── Conventions (引用) # 指向 rules/ 和 skills/
│ └── Compression Guidance # 压缩时保留什么
│
├── .claude/
│ ├── rules/ # 📏 模块化规则（条件加载）
│ │ ├── code-style.md
│ │ ├── testing.md
│ │ ├── git-workflow.md
│ │ └── security.md
│ │
│ ├── skills/ # 🛠️ 按需加载的 Skills
│ │ ├── api-conventions/
│ │ ├── code-review/
│ │ ├── flush/ # 会话结束交接
│ │ └── retrospective/ # 复盘提取
│ │
│ ├── agents/ # 🤖 子代理定义
│ │ ├── researcher.md
│ │ └── code-reviewer.md
│ │
│ └── settings.json # ⚙️ Hooks 配置
│
├── src/
│ ├── auth/
│ │ └── CLAUDE.md # 📂 目录级上下文（认证模块）
│ ├── api/
│ │ └── CLAUDE.md # 📂 目录级上下文（API 层）
│ └── frontend/
│ └── CLAUDE.md # 📂 目录级上下文（前端）
│
└── docs/
├── SPEC.md # 📋 规格文档（规划会话的输出）
├── decisions/ # 📝 架构决策记录
│ ├── 001-auth-approach.md
│ └── 002-database-choice.md
└── knowledge/ # 📚 深层技术知识
├── prisma-patterns.md
└── oauth-quirks.md
这个结构体现了三个核心原则：
分层按需加载：CLAUDE.md 精简核心 → rules/ 条件加载 → skills/ 按需触发 → references/ 深度引用 知识毕业路径：对话 → auto memory → CLAUDE.md → Skill 面包屑连接：每一层都包含指向下一层的引用
九、知识的三大生命周期操作
9.1 捕获：从工作中提取知识
在工作时，你自然会提供上下文、解释偏好和分享程序性知识。留意你反复提供的信息。识别可复用的模式：完成任务后，识别出你提供的哪些上下文对未来类似任务有用。例如：如果你完成了一次 BigQuery 分析，你可能提供了表名、字段定义、过滤规则（如"总是排除测试账户"）和常见查询模式。
让 Claude A 创建 Skill："创建一个 Skill，捕获我们刚才使用的这个 BigQuery 分析模式。包含表 schema、命名约定和关于过滤测试账户的规则。"Claude 模型原生理解 Skill 的格式和结构。你不需要特殊的系统提示来让 Claude 帮助创建 Skills。只需直接要求 Claude 创建一个 Skill，它就会生成具有适当 frontmatter 和正文内容的正确结构的 SKILL.md 内容。
一个 /learn Skill 已经实现了版本控制的知识积累：每个发现保存为一个 SKILL.md 文件，包含问题、解决方案和验证步骤——这有时被称为"结构化知识库"模式。
9.2 维护：保持知识健康
Skills 是活文档。计划基于反馈进行迭代。
维护有三个维度：
准确性：知识还正确吗？模型更新后规则是否过时了？
相关性：这条知识还有人用吗？两周没触发的 Skill 可能该卸载了。
一致性：不同层级之间有没有矛盾？CLAUDE.md 说用 Jest，rules/testing.md 说用 Vitest——这是灾难性的。
70% 的 Agent 行为问题来自三个记忆系统配置错误。在 CLAUDE.md 中写"使用箭头函数"同时在 .claude/rules/code-style.md 中写"使用函数声明"会造成冲突。
9.3 退役：知道什么时候该删除
知识不是只增不减的。过时的知识比没有知识更危险——它是第五篇中讨论的 Context Poisoning 的一种形式。
退役信号：
基础模型已经内化了这个能力（Skill 的 A/B 测试不再优于基线） 技术栈已经变了（你不再用 Prisma 了，但 prisma-patterns 还在 knowledge/ 里） 规则自相矛盾（两条规则在不同位置说不同的话）
十、常见误区
误区 1：「把所有东西都放进 CLAUDE.md」
一个结构不良的 CLAUDE.md 比完全没有 CLAUDE.md 还糟。
一个过于冗长的 CLAUDE.md 降低性能。一个 500 行的文件消耗大约 3,800 个 token，即上下文窗口的 3%。这个预算减少了 Claude Code 分析源代码可用的空间。
误区 2：「让 Auto Memory 自己管就好」
记忆召回不可靠，因为它完全取决于 Claude 选择去搜索。Claude 必须自己决定调用搜索等工具来触发检索。如果它没意识到需要某条记忆，相关内容就不会出现。而且每个记忆层级都需要自己的显式工具调用，所以如果 Claude 没想到要查，就没有后备方案。
Auto Memory 是有用的补充，但不能替代你主动的知识结构化工作。
误区 3：「记忆系统搭好就不用管了」
对大多数项目来说，这些方法大概能获得 80% 想要的连续性。剩下的 20% 是你真正无法重建的东西：你们当时正在发展的细微方向、Claude 详细列出的三个替代方案中你说"让我想想"的那些。那部分你得接受它的丢失。你不能在一个按会话设计的工具中拥有完美记忆。你能做的是在需要时更快地恢复。
这是一条重要的现实主义原则：追求 80% 的连续性，接受 20% 的损失。 把精力放在让那 80% 尽可能高效，而不是追求完美记忆。
误区 4：「CLAUDE.md 和 Skill 是一回事」
使用 CLAUDE.md 文件来引导 Claude 的行为。自动记忆让 Claude 从你的纠正中学习而无需手动操作。
三者的定位完全不同：
| 谁写 | |||
| 何时加载 | |||
| 什么内容 | |||
| 是否共享 | |||
| 何时更新 |
十一、你今天就应该做的 3 件事
✅ 行动 1：审计你的 CLAUDE.md
打开你项目的 CLAUDE.md，数一下有多少行。
如果超过 200 行——你正在以 71% 的规则应用率运行，而不是 92%。
执行以下操作：
对每一行问："删除它会导致 Claude 犯错吗？"如果不会，删掉 将详细的编码规范移到 .claude/rules/将领域知识移到 .claude/skills/的 references/ 中确保最重要的规则在文件最前面
✅ 行动 2：检查你的 Auto Memory
运行 /memory 查看 Claude 为你保存了什么。你可能会惊讶于已经有了什么。
在运行任何东西之前，检查 Claude Code 已经在 ~/.claude/projects/ 中构建了什么——你可能会惊讶于已经存在的记忆文件夹中已经有了什么。
然后：
删除过时的观察 将稳定的规则"毕业"到 CLAUDE.md 确认没有矛盾信息
✅ 行动 3：创建你的第一个 /flush Skill
用本文第七节提供的模板创建一个 flush Skill。从今天开始，每次结束工作前运行 /flush。
两周后回来看你的 daily log——你会发现一个自然增长的项目知识库，每一天都比前一天更丰富。
本文的知识框架总结
text
知识管理系统
│
├── Claude Code 的记忆架构
│ ├── CLAUDE.md（你写的持久指令）
│ ├── Auto Memory（Claude 自己的笔记）
│ ├── Session Memory（后台自动摘要）
│ └── 三个层级：用户级 > 项目级 > 自动记忆
│
├── 分层策略：什么放在哪里
│ ├── 第 1 层：CLAUDE.md（< 200 行，始终加载）
│ ├── 第 2 层：rules/ + skills/ + topic files（按需加载）
│ └── 第 3 层：MCP 记忆 / daily logs（深度搜索）
│ └── 面包屑连接各层级
│
├── CLAUDE.md 工程化管理
│ ├── 200 行 → 92% 应用率 / 400 行 → 71%
│ ├── 前面的行获得更多权重
│ ├── 像管理代码一样管理（版本控制 + 测试 + 重构）
│ └── 模块化拆分到 rules/ 目录
│
├── 复合增长机制
│ ├── 知识毕业路径：对话 → auto memory → CLAUDE.md → Skill
│ ├── 每次会话 = 完成工作 + 学到新东西
│ └── 系统从更高基线开始下一次会话
│
├── 三大生命周期操作
│ ├── 捕获：从工作中提取知识（/learn、/flush）
│ ├── 维护：准确性 + 相关性 + 一致性
│ └── 退役：过时知识比没有知识更危险
│
└── 核心原则
├── 追求 80% 连续性，接受 20% 损失
├── 分层按需加载 > 全塞进 CLAUDE.md
├── CLAUDE.md 的价值随时间复合增长
└── 小事情，复合增长
下一篇预告
到目前为止，我们讨论了 Skills、MCP、Hooks、子代理、Agent Teams、CLAUDE.md、Auto Memory——Claude Code 提供了太多工具。
下一个问题是：面对一个具体任务，我到底该用哪个？
第 8 篇将构建一个完整的决策框架——Workflow vs Agent vs Skill，什么时候该用什么？什么时候原生 Claude Code 就足够了？什么时候复杂编排反而有害？我们将用成本、可靠性和维护负担三个维度来量化每种选择的 tradeoff。
本文是「Claude Code Skills 完全指南」系列的第 7 篇，共 10 篇。全系列目录：
| → 7 | 知识管理系统 | 如何构建可复利增长的项目上下文？ |
📞 AI+obsidian 读书与知识管理星球
请点击了解详情 →
AII
松花酿酒，春水煎茶。
眉上风止，见字如晤。
一只阿木木