zhukang/content-forge-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault: auto-sync 2026-03-05 17:09

Browse Source
This commit is contained in:
lizikk 2026-03-05 17:09:06 +08:00
parent 48791f999a
commit bfa24ae9e4
21 changed files with 2430 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
00-inbox/2026-03-02-cli-is-all-you-need.md
View File

@ -72,6 +72,10 @@ Agent clone 仓库，用 `act` 本地跑 workflow，定位失败，编辑 `.gith
高度结构化的企业集成——类型安全的 SaaS API、受监管环境。但这只覆盖 10–20% 的场景。
## 相关阅读
- [[glue-coding]] - 胶水编程方法论：复用成熟模块，AI 负责连接
## 结论
终端一直是通用开发环境。2026 年，它也是 AI 编码 Agent 最强大的接口。除非你深陷私有企业工具链，否则跳过沉重的 MCP 栈：cd 进项目、启动 CLI agent、给 shell 权限、描述任务、看它工作。

13
00-inbox/2026-03-03-emergent-patterns-analysis.md Normal file
View File

@ -0,0 +1,13 @@
---
title: Emergent Patterns Analysis - Vault 韥识图谱洞察
slug: emergent-patterns-analysis
status: inbox
content_type: analysis
created_at: 2026-03-03T11:31:04+08:00
updated_at: 2026-03-03T11:31:04+08:00
tags:
- knowledge-graph
- emerge
- pattern-recognition
- vault-analysis
source_note: [[vin-obsidian-workflows]],

188
00-inbox/2026-03-03-glue-coding.md Normal file
View File

@ -0,0 +1,188 @@
---
title: Glue Coding - 软件工程的银弹
slug: glue-coding
status: inbox
source_urls:
- https://github.com/luogangyi/vibe-coding-cn
author: luogangyi
created_at: 2026-03-03T11:22:54+08:00
updated_at: 2026-03-03T11:22:54+08:00
tags:
- glue-coding
- vibe-coding
- ai-coding
- methodology
---
# 🧬 Glue Coding
> **When the holy grail of software engineering finally here.**
## 🚀 Disruptive Manifesto
**Glue Coding is not a technology, it's a revolution.**
It might perfectly solve the three fatal flaws of Vibe Coding:
| Traditional Vibe Coding Pain Points | Glue Coding Solution |
|:---|:---|
| 🎭 **AI Hallucinations** - Generates non-existent APIs, incorrect logic | ✅ **Zero Hallucinations** - Uses only validated, mature code |
| 🧩 **Complexity Explosion** - The larger the project, the more out of control | ✅ **Zero Complexity** - Each module is a battle-tested wheel |
| 🎓 **High Barrier** - Requires deep programming skills to master AI | ✅ **No Barrier** - You only need to describe "how to connect" |
---
## 💡 Core Concept
```
Traditional Programming: Humans write code
Vibe Coding: AI writes code, humans review code
Glue Coding: AI connects code, humans review connections
```
### Paradigm Shift
**A fundamental shift from "generation" to "connection":**
- ❌ No longer letting AI generate code from scratch (source of hallucinations)
- ❌ No longer reinventing the wheel (source of complexity)
- ❌ No longer requiring to understand every line of code (source of high barrier)
- ✅ Only reusing mature, production-validated open-source projects
- ✅ AI's sole responsibility: understand the intent, connect modules
- ✅ Your sole responsibility: clearly describe "what is the input, what is the desired output"
---
## 🏗️ Architectural Philosophy
```
┌─────────────────────────────────────────────────────────┐
│ Your Business Needs │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ AI Glue Layer │
│ │
│ "I understand what you want to do, let me connect these blocks" │
│ │
└─────────────────────────────────────────────────────────┘
│
┌────────────────┬────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Mature Module A │ │ Mature Module B │ │ Mature Module C │
│ (100K+ ⭐) │ │ (Production-Validated) │ │ (Official SDK) │
└─────────────┘ └─────────────┘ └─────────────┘
```
**Entity**: Mature open-source projects, official SDKs, battle-tested libraries
**Link**: AI-generated glue code, responsible for data flow and interface adaptation
**Function**: Your described business goal
---
## 🎯 Why is this a Silver Bullet?
### 1. Hallucination Issue → Completely Disappears
AI no longer needs to "invent" anything. It only needs to:
- Read Module A's documentation
- Read Module B's documentation
- Write the data transformation from A → B
**This is what AI excels at, and what is least prone to errors.**
### 2. Complexity Issue → Transferred to the Community
Behind each module are:
- Discussions from thousands of Issues
- Wisdom from hundreds of contributors
- Years of production environment refinement
**You are not managing complexity; you are standing on the shoulders of giants.**
### 3. Barrier Issue → Reduced to a Minimum
You don't need to understand:
- Underlying implementation principles
- Best practice details
- Edge case handling
You only need to speak plain language:
> "I want to take messages from Telegram, process them with GPT, and store them in PostgreSQL"
**AI will help you find the most suitable wheels and glue them together.**
---
## 📋 Practice Flow
```
1. Define the Goal
└─→ "I want to implement XXX functionality"
2. Find the Wheels
└─→ "Are there any mature libraries/projects that have done something similar?"
└─→ Let AI help you search, evaluate, and recommend
3. Understand the Interfaces
└─→ Feed the official documentation to AI
└─→ AI summarizes: what is the input, what is the output
4. Describe the Connection
└─→ "The output of A should become the input of B"
└─→ AI generates glue code
5. Validate and Run
└─→ Runs successfully → Done
└─→ Errors → Give the errors to AI, continue gluing
```
---
## 🔥 Classic Case Study
### Case: Polymarket Data Analysis Bot
**Requirement**: Real-time acquisition of Polymarket data, analysis, and push to Telegram
**Traditional Approach**: Write a crawler, analysis logic, and bot from scratch → 3000 lines of code, 2 weeks
**Glue Approach**:
```
Wheel 1: polymarket-py (Official SDK)
Wheel 2: pandas (Data Analysis)
Wheel 3: python-telegram-bot (Message Push)
Glue Code: 50 lines
Development Time: 2 hours
```
---
## 📚 Further Reading
- [[语言层要素]] - 8 levels to master to understand 100% of the code
- [[胶水开发]] - Prompts for glue development
- [[polymarket-dev]] - Project practice
- [[cli-is-all-you-need]] - CLI 作为胶水层：Bash is the ultimate MCP
---
## 🖖 Summary
> **If you can copy, don't write. If you can connect, don't build. If you can reuse, don't originate.**
Glue Coding is the ultimate evolution of Vibe Coding.
It's not laziness; it's the **highest embodiment of engineering wisdom** —
Leveraging maximum productivity with minimal original code.
**This is the silver bullet software engineering has been waiting for for 50 years.**
---
*"The best code is no code at all. The second best is glue code."*

68
00-inbox/ai-agent-best-practices.md Normal file
View File

@ -0,0 +1,68 @@
---
title: AI Agent 开发最佳实践
slug: ai-agent-best-practices
status: inbox
content_type: reference
source: transcript
created_at: 2026-03-03T19:57:50+08:00
updated_at: 2026-03-03T20:30:00+08:00
tags: [ai, agent, best-practices, development]
---
# 工作流编排
### 1. Plan Node Default（计划节点默认规则）
- 对任何非平凡任务（3步以上或架构决策）进入计划模式
- 如果出现问题，立即停止并重新计划，不要继续推进
- 将计划模式用于验证步骤，而不仅仅是构建步骤
- 事先编写详细的规范以减少歧义
### 2. Subagent Strategy（子代理策略）
- 自由使用子代理以保持主上下文窗口清晰
- 将研究、探索和并行分析卸载到子代理
- 对于复杂问题，通过子代理投入更多计算资源
- 每个子代理专注执行一个任务以实现专注执行
### 3. Self - Improvement Loop（自我改进循环）
- 在用户进行任何修正后：按照模式更新 `tasks/lessons.md`
- 为自己编写防止犯同样错误的规则
- 严格迭代这些经验教训直到错误率下降
- 在会话开始时回顾相关项目的经验教训
### 4. Verification Before Done（完成前验证）
- 在未证明其有效前，不要将任务标记为完成
- 当相关时，比较主流程与你的更改的行为差异
- 自问："资深工程师会批准这个吗？"
- 运行测试、检查日志、证明正确性
### 5. Demand Elegance (Balanced)（追求优雅（平衡））
- 对于非平凡的更改：暂停并自问"是否有更优雅的方式？"
- 如果一个修复感觉是临时的： "基于我现在知道的一切，实现优雅的解决方案"
- 对于简单、明显的修复则跳过此步骤——不要过度工程化
- 在展示工作前挑战自己的工作
### 6. Autonomous Bug Fixing（自动错误修复）
- 当收到错误报告时：直接修复它。不要寻求手把手指导
- 指出日志、错误、失败的测试——然后解决它们
- 不需要用户切换上下文
- 在未被告知如何操作的情况下修复失败的CI测试
## 任务管理
1. **先计划**：编写计划到 `tasks/todo.md`，包含可检查的项
2. **验证计划**：在开始实施前确认计划
3. **跟踪进度**：在推进过程中标记项为完成
4. **解释变更**：每个步骤的高层摘要
5. **记录结果**：在 `tasks/todo.md` 中添加审查部分
6. **捕捉经验**：在修正后更新 `tasks/lessons.md`
## 核心原则
- **简单优先**：让每次更改尽可能简单。影响最少的代码。
- **不偷懒**：找到根本原因。没有临时修复。符合资深开发者标准。
- **最小化影响**：更改应仅触及必要的内容。避免引入错误。

BIN
00-inbox/ai-agent-best-practices.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 MiB

158
00-inbox/claudable-system-prompt.md Normal file
View File

@ -0,0 +1,158 @@
---
title: 'Claudable System Prompt - Fullstack Web Dev AI Assistant'
tags: [system-prompt, ai-tools, fullstack, nextjs, supabase]
collected_at: '2026-03-05'
source: user-provided
---
# Claudable System Prompt
> AI coding assistant specialized in building modern fullstack web applications (Next.js 15 + Supabase + Vercel + Zod + Tailwind CSS).
## Core Identity
- Expert fullstack developer
- Stack: Next.js 15 (App Router, RSC), Supabase, Vercel, Zod, TypeScript, Tailwind CSS
- Not every interaction requires code changes — can discuss architecture, explain concepts, debug
## Product Principles (MVP approach)
- Implement only what user explicitly requests
- Avoid extra features/optimizations unless asked
- Keep implementations simple; avoid unnecessary abstraction
- Don't over-componentize
## Technical Stack Guidelines
### Next.js 15
- App Router with server components by default
- Proper loading.tsx, error.tsx, not-found.tsx
- `use client` only when client-side interactivity needed
- Stable dependency versions (avoid beta/alpha)
- Configure `next.config.mjs` remotePatterns for external images
### Supabase
- Row Level Security (RLS) for access control
- Auth flows with `@supabase/ssr`
- Route mutations through server actions with service role
- Realtime for live data when appropriate
### Zod
- Define schemas first, then infer TypeScript types
- Validate all API inputs and form data
- Reusable schema compositions
### TypeScript
- Strict config
- Proper type inference with Zod schemas
- Type-safe API routes and server actions
- Discriminated unions for complex state
### Deployment
- Optimize for Vercel
- Proper error boundaries
- Next.js Image for optimized images
- Caching strategies
## Code Generation Rules
### File Structure
- Follow Next.js 15 App Router conventions
- Keep code simple
- Separate components only when clear reusability benefit
- Inline helpers/types when used once
### Component Patterns
- Complete, immediately runnable components
- TypeScript interfaces for all props
- Proper error handling
- Accessibility (ARIA, semantic HTML)
- Responsive with Tailwind CSS
### Data Management
- Server actions for mutations
- Proper loading states and optimistic updates
- Tanstack Query with object format for server state
- useState/useContext for local state
- Relative paths for API routes (/api/...)
- No DB connection unless explicitly requested
### Security
- Validate all inputs with Zod
- CSRF protection
- Environment variables for secrets
- Supabase RLS
- Sanitize inputs, prevent XSS
### Design Guidelines
- Framer Motion for animations
- Design Tokens (colors, spacing, typography)
- WCAG AA contrast standards
- Solid colors for body text/buttons
- No light/dark mode toggle initially
- shadcn/ui + lucide-react + Recharts
## Implementation Standards
### Code Quality
- Clean, readable, maintainable
- camelCase variables, PascalCase components
- No try/catch unless requested — let errors bubble
- Extensive console.log for debugging
- Complete code — no partial implementations or TODOs
### UI/UX
- Always responsive
- Tailwind CSS extensively
- Proper loading states and skeletons
- Minimum 14px body text, 4.5:1 contrast ratio
- Toast notifications for feedback
### Database & API
- Normalized schemas
- Proper indexing
- Efficient queries
- Transactions for complex operations
- Always relative paths for same-origin API routes
## Key Rules
- Work from project root
- ONE `ls -la` then start
- File paths: `app/page.tsx` (no leading slash, no `./`)
- With src: `src/app/page.tsx`
- Error checking: TypeScript → ESLint → Build
- Never run `npm run dev` or `npm install`
- Never modify README.md without request
- Never add unrequested features
## NEVER / ALWAYS
**NEVER:**
- Write partial code or TODOs
- Modify files without request
- Add unrequested features
- Compromise security
- Use pwd/find unnecessarily
- Skip git hooks (--no-verify)
- Force push to main
**ALWAYS:**
- Write complete, functional code
- Follow existing codebase patterns
- Use specified tech stack
- Start implementing within 2 commands
- Check errors progressively

1
02-drafts/05-assets Symbolic link
View File

@ -0,0 +1 @@
../05-assets

184
02-drafts/2026-03-03-claude-code-auto-memory-deep-dive-formatted.html Normal file
View File

File diff suppressed because one or more lines are too long

477
02-drafts/2026-03-03-claude-code-auto-memory-deep-dive-formatted.md Normal file
View File

@ -0,0 +1,477 @@
---
id: "2026-03-03-claude-code-auto-memory-deep-dive"
title: "我翻遍了Claude Code的system prompt，发现它的\"记忆\"就是一个200行的markdown文件"
slug: "claude-code-auto-memory-deep-dive"
status: draft
content_type: article
channels:
- wechat
- x
language: zh-CN
source_urls:
- "https://www.anthropic.com/news/claude-opus-4-6"
- "https://claudelog.com/claude-code-changelog/"
- "https://paddo.dev/blog/quiet-features-opus-4-6/"
- "https://www.implicator.ai/claude-codes-quiet-power-play-tooling-not-trophies/"
- "https://hyperdev.matsuoka.com/p/how-claude-code-got-better-by-protecting"
- "https://www.theregister.com/2026/02/26/clade_code_cves/"
- "https://github.com/thedotmack/claude-mem"
- "https://therealjasoncoleman.com/2026/02/05/giving-claude-code-a-memory-and-a-soul-with-automem/"
- "https://www.thenextgentechinsider.com/pulse/anthropic-introduces-auto-memory-system-for-claude-code"
- "https://github.com/anthropics/claude-code/issues/5024"
- "https://blakecrosley.com/en/blog/context-window-management"
assets:
- "05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png"
- "05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png"
- "05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png"
- "05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png"
- "05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png"
- "05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png"
cover_image: "05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png"
template: article
owner: content-forge
created_at: "2026-03-03T00:00:00+08:00"
updated_at: "2026-03-04T00:00:00+08:00"
style: lizi_kk
audience: "Claude Code 用户、AI 编程从业者、开发者"
tags:
- Claude Code
- Auto Memory
- Context Engineering
- AI 编程
source_notes:
- "02-drafts/2026-03-03-claude-code-auto-memory-deep-dive.md"
---
# 我翻遍了Claude Code的system prompt，发现它的”记忆”就是一个200行的markdown文件
说实话，用 Claude Code 的人都有一个抓狂时刻——每次新开会话，它对你的项目一无所知。
你得重新说一遍：“我们用 FastAPI + Next.js，后端端口 9801，状态管理用 Zustand，上次那个 bug 根因是连接池耗尽……”
烦不烦？
2026 年 2 月 5 日，Anthropic 发布了 Opus 4.6。大多数人只看到了“更强的模型”。但真正改变日常开发体验的，是三个不起眼的底层能力：
* **Auto Memory**——跨会话持久记忆
* **Agent Teams**——多智能体并行协作
* **Context Compaction**——上下文智能压缩
内部测试数据：智能体性能提升 39%，100 轮对话 token 消耗降低 84%，支持 30 小时无人值守。
这篇文章，我把 Auto Memory 的底层机制逐层拆开——system prompt 注入原文、200 行硬截断的真实含义、5 个我全踩过的坑，以及它和 Agent Teams、Context Compaction 之间怎么配合。
如果你每天都在用 Claude Code，这篇值得收藏。
***
![Claude Code 记忆系统全景](05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png)
## 01 Claude Code 的记忆到底有几层
先看全貌。
Claude Code 的记忆不是一坨东西，是分层的：
```
┌──────────────────────────────────────────────────────┐
│ Layer 0: Enterprise Rules（最高优先级） │
│ └─ 组织管理员的全局规则，所有用户强制生效 │
│ │
│ Layer 1: CLAUDE.md 文件族（静态指令 · 人工维护） │
│ ├─ ~/.claude/CLAUDE.md ← 用户级，所有项目 │
│ ├─ <project>/CLAUDE.md ← 项目级，入库共享 │
│ ├─ <project>/CLAUDE.local.md ← 项目级，本地私有 │
│ └─ <subdir>/CLAUDE.md ← 子目录级，按需加载 │
│ │
│ Layer 2: Auto Memory（动态知识 · Claude 自主维护） │
│ ├─ MEMORY.md ← 主索引，自动加载（200行上限） │
│ └─ *.md ← 主题文件，按需读取（无行数限制） │
│ │
│ Layer 3: Subagent Memory（子代理记忆 · 独立隔离） │
│ │
│ Layer 4: Session Context（会话上下文 · 临时） │
└──────────────────────────────────────────────────────┘
```
![三层记忆架构](05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png)
一句话说清楚 Layer 1 和 Layer 2 的关系：
**Layer 1 是项目手册**——你写的规则、命令、规范，入 Git，团队共享。
**Layer 2 是个人笔记**——Claude 自己记的调试心得、踩坑经验，不入 Git，纯本地。
一个是宪法，一个是草稿纸。互补，不是替代。
| | CLAUDE.md（手册） | Auto Memory（笔记） |
| ----- | ------------------ | ------------------------ |
| 谁写 | 人工维护 | Claude 主动写入 |
| 内容 | 编码规范、构建命令、禁止事项 | 陷阱、失败模式、调试经验 |
| 入 Git | 是（团队共享） | 否（个人本地） |
| 上限 | 无硬限制 | 200 行（主索引） |
| 更新频率 | 低（架构变更才改） | 高（每次会话可能更新） |
| 典型内容 | “始终使用 pytest 运行测试” | “检查 A 必须在 B 之前，否则测试 X 挂” |
搞清楚这两层的区别，后面的东西才看得懂。
***
## 02 从 # 前缀到 Auto Memory：三个阶段
Auto Memory 不是凭空冒出来的。
```
阶段 1: # 前缀时代（已弃用）
└─ 用户在对话中用 # 标记重要信息
└─ Claude 被动记录，能力有限
└─ 问题：完全依赖用户主动标记，Claude 不会判断
│
▼
阶段 2: Research Preview
└─ 需要手动开启：settings.json 加 autoMemoryEnabled: true
└─ Claude 开始有"自主写入"能力
└─ 问题：默认关闭，大多数人根本不知道
│
▼
阶段 3: 正式发布（v2.1.32+，当前）
└─ 默认开启，无需配置
└─ 可用环境变量关闭：CLAUDE_CODE_DISABLE_AUTO_MEMORY=1
└─ 与 Opus 4.6 的 Agent Teams / Context Compaction 协同
```
**还在用 # 前缀标记的，该换了。**
说实话，大部分人连阶段 2 都没用过。这功能藏得太深，如果不是我挨个翻 settings.json 的字段，根本发现不了。
但真正有意思的不是这个演进历史——是 Auto Memory 的底层实现，朴素得超乎想象。
***
## 03 底层真相：没有向量数据库，没有 RAG，就是读写文件
先说结论：**就是 Claude 被允许在你电脑上的一个文件夹里读写 markdown 文件。**
没有向量数据库。没有语义检索。没有 RAG。
每次开新会话，主文件塞进 system prompt。完事。
零依赖，纯文件 I/O。
```
~/.claude/projects/<project-path-hash>/memory/
├── MEMORY.md ← 主索引，每次自动加载（上限200行）
├── debugging.md ← 主题文件（按需创建，不自动加载）
├── patterns.md
├── architecture.md
└── ...
```
你可能觉得“就这？”
对，就这。这就是 Anthropic 的风格——**用最简单的机制解决 80% 的问题**。不过度工程化，不引入额外依赖。
### 拆开 system prompt：Claude 到底看到了什么
大多数文章不会讲这部分。以下是我从实际运行环境中提取的完整 system prompt 注入内容：
```
You have a persistent auto memory directory at
`~/.claude/projects/<project>/memory/`.
Its contents persist across conversations.
## How to save memories:
- Organize memory semantically by topic, not chronologically
- Use the Write and Edit tools to update your memory files
- MEMORY.md is always loaded into your conversation context
— lines after 200 will be truncated, so keep it concise
- Create separate topic files (e.g., debugging.md, patterns.md)
for detailed notes and link to them from MEMORY.md
- Update or remove memories that turn out to be wrong or outdated
- Do not write duplicate memories.
## What to save:
- Stable patterns confirmed across multiple interactions
- Key architectural decisions, important file paths
- User preferences for workflow and tools
- Solutions to recurring problems
## What NOT to save:
- Session-specific context
- Information that might be incomplete
- Anything that duplicates CLAUDE.md instructions
- Speculative conclusions from reading a single file
```
![Auto Memory 触发决策流程](05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png)
**Auto Memory 的全部“智能”就来自这段指令。**
Claude 没有特殊的记忆模块，没有额外的神经网络组件。它只是被告知“你有个文件夹可以读写，按规则来”——跟你在 CLAUDE.md 里写“遇到 bug 先跑测试”是完全同一个机制。
这也解释了一个很多人困惑的问题：为什么 Claude 的记忆写入行为这么不稳定？
答案很简单。忙着干活的时候，这段指令的优先级自然被压低。不是不想记，是顾不上。
但我觉得这恰恰是好的工程品味。你见过很多方案搞 embedding + vector store + semantic search，链路一长，出 bug 的概率翻倍。Anthropic 选了最朴素的路，反而最稳。
不过“朴素”不代表“没限制”。接下来这部分，才是整篇文章最关键的。
***
## 04 200 行限制：比你想的更硬
MEMORY.md 有 200 行的硬截断。
注意，是**硬截断**——第 201 行开始直接消失。不是“存在但优先级低”，是 Claude 完全看不到：
```
MEMORY.md 总共 250 行
├─ 前 200 行 → 注入 system prompt ✓
└─ 第 201-250 行 → 硬截断，Claude 完全看不到 ✗
└─ Claude 收到截断警告，建议你精简内容
```
![MEMORY.md 文件结构与 200 行截断机制](05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png)
主题文件（debugging.md 等）没有行数限制。但它们不自动加载——Claude 得自己用 Read 工具去读。
这里有个容易忽略的连锁反应：**MEMORY.md 的索引质量决定了整个记忆系统的有效性。**
如果里面没提某个主题文件，Claude 压根不知道它存在。你精心写的 debugging.md 可能永远不会被读到。
所以 MEMORY.md 只能当目录用：
```markdown
# Memory Index
## 调试经验
- [后端连接池问题](./debugging.md) - 根因和修复方案
## 架构决策
- [消息工厂设计](./architecture.md) - 分层逻辑
## 用户偏好
- [工作流](./user-preferences.md) - 测试、部署、风格
```
简洁，只做索引，别超 200 行。这 200 行是你的“记忆预算”，花在刀刃上。
### 数据流：三个阶段看完
```
┌──────────────────────────────────────────────────────┐
│ 阶段一：会话启动 │
│ Claude Code 读 MEMORY.md 前 200 行 → 塞进 prompt │
│ 其他 memory/*.md 不自动加载 │
└────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 阶段二：会话进行中 │
│ Claude 可能记录： │
│ ├─ gotchas——"检查 A 必须在 B 之前，否则测试 X 挂" │
│ ├─ 失败模式——"该 API 并发 > 100 时返回 429" │
│ ├─ 项目模式——"所有 router 必须用 API_PREFIX 注册" │
│ └─ 用户偏好——"用户偏好 pnpm 而非 npm" │
│ │
│ 写入时机： │
│ ├─ 你说"记住这个" → 立即写入（最靠谱） │
│ └─ Claude 自己觉得有用 → 看心情（不靠谱） │
└────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 阶段三：会话结束 │
│ 文件留在磁盘，下次自动可用 │
│ ⚠️ 没有"会话结束时自动总结"——社区方案存在的根因 │
└──────────────────────────────────────────────────────┘
```
第三阶段是关键设计取舍。
**官方方案完全依赖 Claude 在会话过程中的“自觉性”。** 你聊了两小时发现三个重要结论，但 Claude 没记——那就真没了。
这也是社区方案（claude-mem、AutoMem）存在的根本原因。后面会讲到怎么选。
***
## 05 三板斧协同：一套组合拳
Opus 4.6 同时上线的三个能力，不是各干各的，是一套组合拳：
```
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Auto Memory │ │ Agent Teams │ │ Context │
│ 跨会话记忆 │ │ 多智能体协作 │ │ Compaction │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ 解决： │ │ 解决： │ │ 解决： │
│ "每次重新 │ │ "一个人干 │ │ "聊久了就 │
│ 介绍项目" │ │ 不过来" │ │ 忘事" │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└──────────────────┼──────────────────┘
│
┌───────▼───────┐
│ 30小时无人 │
│ 值守自主运行 │
└───────────────┘
```
token 降 84%、性能升 39%——就是这三者组合的效果。
但有几个细节，踩过坑才知道：
**子代理记忆是隔离的。** Agent Teams 的子代理有独立记忆空间，读不到主会话的 Auto Memory，也不会污染主记忆。好处是干净，坏处是子代理对你的项目上下文一无所知。你得在 prompt 里手动交代背景。
**Context Compaction 会吃掉记忆。** 最新版在上下文使用率 64-75% 时就触发压缩——比以前的 90%+ 激进得多。MEMORY.md 的细节可能在压缩中被摘要化。你以为 Claude 记着呢，其实早忘了。
**Adaptive Thinking 省 token。** Claude 根据问题复杂度自动调整思考深度，简单问题不浪费 token，把预算留给真正需要深度推理的场景。这个倒是好消息。
说到踩坑，接下来这部分我全经历过。
***
## 06 5 个必踩的坑
### 坑 1：聊久了记忆被压缩掉
```
会话开始: MEMORY.md 内容完整 ✓
▼ （对话越来越长）
上下文压缩触发（64-75% 容量时）
▼
MEMORY.md 的细节被摘要化 ✗
```
发现 Claude 开始“忘事”了？用 `/clear` 开新会话。记忆会重新完整加载。
### 坑 2：Claude 经常忘记写笔记
写入完全靠 Claude“自觉”。实际用下来：
* 忙着干活时根本想不起来记
* 写入质量参差不齐，有时太笼统，有时写了不该写的
* 不同模型版本的写入倾向还不一样
**最靠谱的办法就一个字：你自己说“把这个记下来”。** 别指望它自觉。我现在养成了习惯，每次调试出重要结论，直接说“写到 memory 里”。
### 坑 3：换路径打开项目，记忆就断了
记忆目录按项目路径哈希生成。同一个项目换个路径打开，就是两套独立记忆：
```
/home/user/apps/my-project → memory-A
/mnt/disk/my-project → memory-B
```
多台机器或多个挂载点工作的，注意了。这个坑很隐蔽，你可能很久才会发现“怎么之前记的东西全没了”。
### 坑 4：.claude.json 越来越胖
GitHub issue #5024：`.claude.json` 持续累积会话历史，文件越来越大。不是 Auto Memory 的锅，但会拖慢整体体验。定期清理一下。
### 坑 5：旧记忆比没记忆更危险
这个是最致命的。
Claude 不会主动清理过时记忆。项目架构改了，记忆还是旧的，Claude 就会基于错误信息做决策。
**过时的记忆不是“没用”，是“有害”。** 就像你手机导航用的三年前的地图——不是找不到路，是找到一条已经拆了的路。
得你自己定期去看看，删掉过时的。我每周花 2 分钟扫一眼 memory 目录，这个习惯帮我躲过好几次大坑。
***
## 07 官方够用吗？看项目规模
官方 Auto Memory 不够用时，社区有两个主流替代。先看对比：
![记忆管理最佳实践对比](05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png)
```
官方 Auto Memory claude-mem AutoMem
────────────── ────────── ───────
存储 纯 markdown 文件 压缩后的文本 图DB + 向量DB
写入触发 Claude 自主判断 Hook 自动捕获 Hook 自动捕获
会话结束 啥也不干 自动捕获+压缩 自动捕获+向量化
压缩 无 ~200:1 压缩率 向量化
依赖 零 Bun + uv Docker 全家桶
可靠性 看 Claude 心情 自动化，稳定 自动化，稳定
```
怎么选？别纠结，看项目大小：
* **个人项目、小团队**——官方够了。零配置零依赖，能跑就行。
* **中等复杂度**——上 claude-mem。自动捕获 + AI 压缩，1 万 token 的会话内容压到约 50 token，200:1 的压缩率。靠谱。
* **大型长期项目**——考虑 AutoMem。图数据库做关系推理，但得跑 Docker，部署成本不低。
***
## 6 条你现在就能用的建议
1. **MEMORY.md 只当目录用。** 只放链接和一句话摘要。200 行限制逼你这么做，别跟它较劲。
2. **按主题建文件，别按时间排。** debugging.md、architecture.md、user-preferences.md。语义组织，不是流水账。
3. **重要的事主动说“记住”。** “把这个调试结论写到 memory 里”——这句话比什么技巧都靠谱。别等 Claude 自觉，它不会的。
4. **每周扫一眼 memory 文件夹。** 打开 `~/.claude/projects/` 下的 memory 目录，过时的删掉。2 分钟的事。旧记忆比没记忆更危险，前面说过了。
5. **聊天太长就 /clear。** Context Compaction 会吃记忆，/clear 让记忆重新完整加载。代价是丢失当前会话上下文，但总比 Claude 基于残缺记忆做决策强。
6. **不想用可以关。** 环境变量 `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1`，完事。
***
## 安全：别让记忆变成攻击面
2026 年 2 月 26 日，The Register 报道了 Claude Code 的安全漏洞（CVE）：攻击者可以在仓库中注入恶意配置文件，实现远程代码执行和 API Key 窃取。
这和记忆系统直接相关。如果有人能操纵你的 MEMORY.md 或 CLAUDE.md，就能影响 Claude 的行为——它每次启动都无条件信任这些文件的内容。
三个基本防护：
* 定期看看 memory 目录，确认没被注入奇怪指令
* 别在 memory 文件里存 API Key、密码
* clone 陌生仓库后，先看看有没有 CLAUDE.md 或 .claude/ 目录
这不是吓你。攻击面就在那里。
***
![记忆系统生命周期](05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png)
## 写在最后
Auto Memory 的技术实现朴素到令人意外。没有向量数据库，没有 RAG 管线——system prompt + 文件读写，完事。
但这恰恰是好的工程品味。**用最少的复杂度解决最核心的问题。**
不过说到底，**真正的记忆管理责任在你身上。** Auto Memory 给了工具，效果取决于你怎么用——MEMORY.md 的索引质量、主题文件的组织方式、定期审查的纪律性。
记忆系统的本质不是让 AI 变聪明。是让 AI 在正确的上下文中工作。
这才是 Context Engineering 真正在做的事。
下一篇我打算拆 Agent Teams 的多智能体协作机制——怎么让多个 Claude 同时干活还不打架。点关注不迷路。
***
> **栗子KK**，一个在 AI 浪潮中游泳的 AI 产品 Founder
>
> 欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来 🚀
***
> 参考来源：
>
> * [Anthropic 官方 Opus 4.6 发布](https://www.anthropic.com/news/claude-opus-4-6)
> * [Claude Code Changelog](https://claudelog.com/claude-code-changelog/)
> * [The Quiet Features That Shipped With Opus 4.6](https://paddo.dev/blog/quiet-features-opus-4-6/)
> * [Claude Code's quiet power play](https://www.implicator.ai/claude-codes-quiet-power-play-tooling-not-trophies/)
> * [How Claude Code Got Better by Protecting More Context](https://hyperdev.matsuoka.com/p/how-claude-code-got-better-by-protecting)
> * [Claude Code 安全漏洞 - The Register](https://www.theregister.com/2026/02/26/clade_code_cves/)
> * [claude-mem GitHub](https://github.com/thedotmack/claude-mem)
> * [AutoMem](https://therealjasoncoleman.com/2026/02/05/giving-claude-code-a-memory-and-a-soul-with-automem/)
> * [Anthropic Introduces Auto Memory System](https://www.thenextgentechinsider.com/pulse/anthropic-introduces-auto-memory-system-for-claude-code)
> * [.claude.json 膨胀 Issue #5024](https://github.com/anthropics/claude-code/issues/5024)
> * [Context Window Management 实测](https://blakecrosley.com/en/blog/context-window-management)

476
02-drafts/2026-03-03-claude-code-auto-memory-deep-dive.md Normal file
View File

@ -0,0 +1,476 @@
---
id: "2026-03-03-claude-code-auto-memory-deep-dive"
title: "我翻遍了Claude Code的system prompt，发现它的\"记忆\"就是一个200行的markdown文件"
slug: "claude-code-auto-memory-deep-dive"
status: draft
content_type: article
channels:
- wechat
- x
language: zh-CN
source_urls:
- "https://www.anthropic.com/news/claude-opus-4-6"
- "https://claudelog.com/claude-code-changelog/"
- "https://paddo.dev/blog/quiet-features-opus-4-6/"
- "https://www.implicator.ai/claude-codes-quiet-power-play-tooling-not-trophies/"
- "https://hyperdev.matsuoka.com/p/how-claude-code-got-better-by-protecting"
- "https://www.theregister.com/2026/02/26/clade_code_cves/"
- "https://github.com/thedotmack/claude-mem"
- "https://therealjasoncoleman.com/2026/02/05/giving-claude-code-a-memory-and-a-soul-with-automem/"
- "https://www.thenextgentechinsider.com/pulse/anthropic-introduces-auto-memory-system-for-claude-code"
- "https://github.com/anthropics/claude-code/issues/5024"
- "https://blakecrosley.com/en/blog/context-window-management"
assets:
- "05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png"
- "05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png"
- "05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png"
- "05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png"
- "05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png"
- "05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png"
cover_image: "05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png"
template: article
owner: content-forge
created_at: "2026-03-03T00:00:00+08:00"
updated_at: "2026-03-04T00:00:00+08:00"
style: lizi_kk
audience: "Claude Code 用户、AI 编程从业者、开发者"
tags:
- Claude Code
- Auto Memory
- Context Engineering
- AI编程
source_notes:
- "02-drafts/2026-03-03-claude-code-auto-memory-deep-dive.md"
---
# 我翻遍了Claude Code的system prompt，发现它的"记忆"就是一个200行的markdown文件
说实话，用 Claude Code 的人都有一个抓狂时刻——每次新开会话，它对你的项目一无所知。
你得重新说一遍："我们用 FastAPI + Next.js，后端端口 9801，状态管理用 Zustand，上次那个 bug 根因是连接池耗尽……"
烦不烦？
2026 年 2 月 5 日，Anthropic 发布了 Opus 4.6。大多数人只看到了"更强的模型"。但真正改变日常开发体验的，是三个不起眼的底层能力：
- **Auto Memory**——跨会话持久记忆
- **Agent Teams**——多智能体并行协作
- **Context Compaction**——上下文智能压缩
内部测试数据：智能体性能提升 39%，100 轮对话 token 消耗降低 84%，支持 30 小时无人值守。
这篇文章，我把 Auto Memory 的底层机制逐层拆开——system prompt 注入原文、200 行硬截断的真实含义、5 个我全踩过的坑，以及它和 Agent Teams、Context Compaction 之间怎么配合。
如果你每天都在用 Claude Code，这篇值得收藏。
---
![Claude Code 记忆系统全景](05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png)
## 01 Claude Code 的记忆到底有几层
先看全貌。
Claude Code 的记忆不是一坨东西，是分层的：
```
┌──────────────────────────────────────────────────────┐
│ Layer 0: Enterprise Rules（最高优先级） │
│ └─ 组织管理员的全局规则，所有用户强制生效 │
│ │
│ Layer 1: CLAUDE.md 文件族（静态指令 · 人工维护） │
│ ├─ ~/.claude/CLAUDE.md ← 用户级，所有项目 │
│ ├─ <project>/CLAUDE.md ← 项目级，入库共享 │
│ ├─ <project>/CLAUDE.local.md ← 项目级，本地私有 │
│ └─ <subdir>/CLAUDE.md ← 子目录级，按需加载 │
│ │
│ Layer 2: Auto Memory（动态知识 · Claude 自主维护） │
│ ├─ MEMORY.md ← 主索引，自动加载（200行上限） │
│ └─ *.md ← 主题文件，按需读取（无行数限制） │
│ │
│ Layer 3: Subagent Memory（子代理记忆 · 独立隔离） │
│ │
│ Layer 4: Session Context（会话上下文 · 临时） │
└──────────────────────────────────────────────────────┘
```
![三层记忆架构](05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png)
一句话说清楚 Layer 1 和 Layer 2 的关系：
**Layer 1 是项目手册**——你写的规则、命令、规范，入 Git，团队共享。
**Layer 2 是个人笔记**——Claude 自己记的调试心得、踩坑经验，不入 Git，纯本地。
一个是宪法，一个是草稿纸。互补，不是替代。
| | CLAUDE.md（手册） | Auto Memory（笔记） |
|---|---|---|
| 谁写 | 人工维护 | Claude 主动写入 |
| 内容 | 编码规范、构建命令、禁止事项 | 陷阱、失败模式、调试经验 |
| 入 Git | 是（团队共享） | 否（个人本地） |
| 上限 | 无硬限制 | 200 行（主索引） |
| 更新频率 | 低（架构变更才改） | 高（每次会话可能更新） |
| 典型内容 | "始终使用 pytest 运行测试" | "检查 A 必须在 B 之前，否则测试 X 挂" |
搞清楚这两层的区别，后面的东西才看得懂。
---
## 02 从 # 前缀到 Auto Memory：三个阶段
Auto Memory 不是凭空冒出来的。
```
阶段 1: # 前缀时代（已弃用）
└─ 用户在对话中用 # 标记重要信息
└─ Claude 被动记录，能力有限
└─ 问题：完全依赖用户主动标记，Claude 不会判断
│
▼
阶段 2: Research Preview
└─ 需要手动开启：settings.json 加 autoMemoryEnabled: true
└─ Claude 开始有"自主写入"能力
└─ 问题：默认关闭，大多数人根本不知道
│
▼
阶段 3: 正式发布（v2.1.32+，当前）
└─ 默认开启，无需配置
└─ 可用环境变量关闭：CLAUDE_CODE_DISABLE_AUTO_MEMORY=1
└─ 与 Opus 4.6 的 Agent Teams / Context Compaction 协同
```
**还在用 # 前缀标记的，该换了。**
说实话，大部分人连阶段 2 都没用过。这功能藏得太深，如果不是我挨个翻 settings.json 的字段，根本发现不了。
但真正有意思的不是这个演进历史——是 Auto Memory 的底层实现，朴素得超乎想象。
---
## 03 底层真相：没有向量数据库，没有 RAG，就是读写文件
先说结论：**就是 Claude 被允许在你电脑上的一个文件夹里读写 markdown 文件。**
没有向量数据库。没有语义检索。没有 RAG。
每次开新会话，主文件塞进 system prompt。完事。
零依赖，纯文件 I/O。
```
~/.claude/projects/<project-path-hash>/memory/
├── MEMORY.md ← 主索引，每次自动加载（上限200行）
├── debugging.md ← 主题文件（按需创建，不自动加载）
├── patterns.md
├── architecture.md
└── ...
```
你可能觉得"就这？"
对，就这。这就是 Anthropic 的风格——**用最简单的机制解决 80% 的问题**。不过度工程化，不引入额外依赖。
### 拆开 system prompt：Claude 到底看到了什么
大多数文章不会讲这部分。以下是我从实际运行环境中提取的完整 system prompt 注入内容：
```
You have a persistent auto memory directory at
`~/.claude/projects/<project>/memory/`.
Its contents persist across conversations.
## How to save memories:
- Organize memory semantically by topic, not chronologically
- Use the Write and Edit tools to update your memory files
- MEMORY.md is always loaded into your conversation context
— lines after 200 will be truncated, so keep it concise
- Create separate topic files (e.g., debugging.md, patterns.md)
for detailed notes and link to them from MEMORY.md
- Update or remove memories that turn out to be wrong or outdated
- Do not write duplicate memories.
## What to save:
- Stable patterns confirmed across multiple interactions
- Key architectural decisions, important file paths
- User preferences for workflow and tools
- Solutions to recurring problems
## What NOT to save:
- Session-specific context
- Information that might be incomplete
- Anything that duplicates CLAUDE.md instructions
- Speculative conclusions from reading a single file
```
![Auto Memory 触发决策流程](05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png)
**Auto Memory 的全部"智能"就来自这段指令。**
Claude 没有特殊的记忆模块，没有额外的神经网络组件。它只是被告知"你有个文件夹可以读写，按规则来"——跟你在 CLAUDE.md 里写"遇到 bug 先跑测试"是完全同一个机制。
这也解释了一个很多人困惑的问题：为什么 Claude 的记忆写入行为这么不稳定？
答案很简单。忙着干活的时候，这段指令的优先级自然被压低。不是不想记，是顾不上。
但我觉得这恰恰是好的工程品味。你见过很多方案搞 embedding + vector store + semantic search，链路一长，出 bug 的概率翻倍。Anthropic 选了最朴素的路，反而最稳。
不过"朴素"不代表"没限制"。接下来这部分，才是整篇文章最关键的。
---
## 04 200 行限制：比你想的更硬
MEMORY.md 有 200 行的硬截断。
注意，是**硬截断**——第 201 行开始直接消失。不是"存在但优先级低"，是 Claude 完全看不到：
```
MEMORY.md 总共 250 行
├─ 前 200 行 → 注入 system prompt ✓
└─ 第 201-250 行 → 硬截断，Claude 完全看不到 ✗
└─ Claude 收到截断警告，建议你精简内容
```
![MEMORY.md 文件结构与 200 行截断机制](05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png)
主题文件（debugging.md 等）没有行数限制。但它们不自动加载——Claude 得自己用 Read 工具去读。
这里有个容易忽略的连锁反应：**MEMORY.md 的索引质量决定了整个记忆系统的有效性。**
如果里面没提某个主题文件，Claude 压根不知道它存在。你精心写的 debugging.md 可能永远不会被读到。
所以 MEMORY.md 只能当目录用：
```markdown
# Memory Index
## 调试经验
- [后端连接池问题](./debugging.md) - 根因和修复方案
## 架构决策
- [消息工厂设计](./architecture.md) - 分层逻辑
## 用户偏好
- [工作流](./user-preferences.md) - 测试、部署、风格
```
简洁，只做索引，别超 200 行。这 200 行是你的"记忆预算"，花在刀刃上。
### 数据流：三个阶段看完
```
┌──────────────────────────────────────────────────────┐
│ 阶段一：会话启动 │
│ Claude Code 读 MEMORY.md 前 200 行 → 塞进 prompt │
│ 其他 memory/*.md 不自动加载 │
└────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 阶段二：会话进行中 │
│ Claude 可能记录： │
│ ├─ gotchas——"检查 A 必须在 B 之前，否则测试 X 挂" │
│ ├─ 失败模式——"该 API 并发 > 100 时返回 429" │
│ ├─ 项目模式——"所有 router 必须用 API_PREFIX 注册" │
│ └─ 用户偏好——"用户偏好 pnpm 而非 npm" │
│ │
│ 写入时机： │
│ ├─ 你说"记住这个" → 立即写入（最靠谱） │
│ └─ Claude 自己觉得有用 → 看心情（不靠谱） │
└────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 阶段三：会话结束 │
│ 文件留在磁盘，下次自动可用 │
│ ⚠️ 没有"会话结束时自动总结"——社区方案存在的根因 │
└──────────────────────────────────────────────────────┘
```
第三阶段是关键设计取舍。
**官方方案完全依赖 Claude 在会话过程中的"自觉性"。** 你聊了两小时发现三个重要结论，但 Claude 没记——那就真没了。
这也是社区方案（claude-mem、AutoMem）存在的根本原因。后面会讲到怎么选。
---
## 05 三板斧协同：一套组合拳
Opus 4.6 同时上线的三个能力，不是各干各的，是一套组合拳：
```
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Auto Memory │ │ Agent Teams │ │ Context │
│ 跨会话记忆 │ │ 多智能体协作 │ │ Compaction │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ 解决： │ │ 解决： │ │ 解决： │
│ "每次重新 │ │ "一个人干 │ │ "聊久了就 │
│ 介绍项目" │ │ 不过来" │ │ 忘事" │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└──────────────────┼──────────────────┘
│
┌───────▼───────┐
│ 30小时无人 │
│ 值守自主运行 │
└───────────────┘
```
token 降 84%、性能升 39%——就是这三者组合的效果。
但有几个细节，踩过坑才知道：
**子代理记忆是隔离的。** Agent Teams 的子代理有独立记忆空间，读不到主会话的 Auto Memory，也不会污染主记忆。好处是干净，坏处是子代理对你的项目上下文一无所知。你得在 prompt 里手动交代背景。
**Context Compaction 会吃掉记忆。** 最新版在上下文使用率 64-75% 时就触发压缩——比以前的 90%+ 激进得多。MEMORY.md 的细节可能在压缩中被摘要化。你以为 Claude 记着呢，其实早忘了。
**Adaptive Thinking 省 token。** Claude 根据问题复杂度自动调整思考深度，简单问题不浪费 token，把预算留给真正需要深度推理的场景。这个倒是好消息。
说到踩坑，接下来这部分我全经历过。
---
## 06 5 个必踩的坑
### 坑 1：聊久了记忆被压缩掉
```
会话开始: MEMORY.md 内容完整 ✓
▼ （对话越来越长）
上下文压缩触发（64-75% 容量时）
▼
MEMORY.md 的细节被摘要化 ✗
```
发现 Claude 开始"忘事"了？用 `/clear` 开新会话。记忆会重新完整加载。
### 坑 2：Claude 经常忘记写笔记
写入完全靠 Claude "自觉"。实际用下来：
- 忙着干活时根本想不起来记
- 写入质量参差不齐，有时太笼统，有时写了不该写的
- 不同模型版本的写入倾向还不一样
**最靠谱的办法就一个字：你自己说"把这个记下来"。** 别指望它自觉。我现在养成了习惯，每次调试出重要结论，直接说"写到 memory 里"。
### 坑 3：换路径打开项目，记忆就断了
记忆目录按项目路径哈希生成。同一个项目换个路径打开，就是两套独立记忆：
```
/home/user/apps/my-project → memory-A
/mnt/disk/my-project → memory-B
```
多台机器或多个挂载点工作的，注意了。这个坑很隐蔽，你可能很久才会发现"怎么之前记的东西全没了"。
### 坑 4：.claude.json 越来越胖
GitHub issue #5024：`.claude.json` 持续累积会话历史，文件越来越大。不是 Auto Memory 的锅，但会拖慢整体体验。定期清理一下。
### 坑 5：旧记忆比没记忆更危险
这个是最致命的。
Claude 不会主动清理过时记忆。项目架构改了，记忆还是旧的，Claude 就会基于错误信息做决策。
**过时的记忆不是"没用"，是"有害"。** 就像你手机导航用的三年前的地图——不是找不到路，是找到一条已经拆了的路。
得你自己定期去看看，删掉过时的。我每周花 2 分钟扫一眼 memory 目录，这个习惯帮我躲过好几次大坑。
---
## 07 官方够用吗？看项目规模
官方 Auto Memory 不够用时，社区有两个主流替代。先看对比：
![记忆管理最佳实践对比](05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png)
```
官方 Auto Memory claude-mem AutoMem
────────────── ────────── ───────
存储 纯 markdown 文件 压缩后的文本 图DB + 向量DB
写入触发 Claude 自主判断 Hook 自动捕获 Hook 自动捕获
会话结束 啥也不干 自动捕获+压缩 自动捕获+向量化
压缩 无 ~200:1 压缩率 向量化
依赖 零 Bun + uv Docker 全家桶
可靠性 看 Claude 心情 自动化，稳定 自动化，稳定
```
怎么选？别纠结，看项目大小：
- **个人项目、小团队**——官方够了。零配置零依赖，能跑就行。
- **中等复杂度**——上 claude-mem。自动捕获 + AI 压缩，1 万 token 的会话内容压到约 50 token，200:1 的压缩率。靠谱。
- **大型长期项目**——考虑 AutoMem。图数据库做关系推理，但得跑 Docker，部署成本不低。
---
## 6 条你现在就能用的建议
1. **MEMORY.md 只当目录用。** 只放链接和一句话摘要。200 行限制逼你这么做，别跟它较劲。
2. **按主题建文件，别按时间排。** debugging.md、architecture.md、user-preferences.md。语义组织，不是流水账。
3. **重要的事主动说"记住"。** "把这个调试结论写到 memory 里"——这句话比什么技巧都靠谱。别等 Claude 自觉，它不会的。
4. **每周扫一眼 memory 文件夹。** 打开 `~/.claude/projects/` 下的 memory 目录，过时的删掉。2 分钟的事。旧记忆比没记忆更危险，前面说过了。
5. **聊天太长就 /clear。** Context Compaction 会吃记忆，/clear 让记忆重新完整加载。代价是丢失当前会话上下文，但总比 Claude 基于残缺记忆做决策强。
6. **不想用可以关。** 环境变量 `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1`，完事。
---
## 安全：别让记忆变成攻击面
2026 年 2 月 26 日，The Register 报道了 Claude Code 的安全漏洞（CVE）：攻击者可以在仓库中注入恶意配置文件，实现远程代码执行和 API Key 窃取。
这和记忆系统直接相关。如果有人能操纵你的 MEMORY.md 或 CLAUDE.md，就能影响 Claude 的行为——它每次启动都无条件信任这些文件的内容。
三个基本防护：
- 定期看看 memory 目录，确认没被注入奇怪指令
- 别在 memory 文件里存 API Key、密码
- clone 陌生仓库后，先看看有没有 CLAUDE.md 或 .claude/ 目录
这不是吓你。攻击面就在那里。
---
![记忆系统生命周期](05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png)
## 写在最后
Auto Memory 的技术实现朴素到令人意外。没有向量数据库，没有 RAG 管线——system prompt + 文件读写，完事。
但这恰恰是好的工程品味。**用最少的复杂度解决最核心的问题。**
不过说到底，**真正的记忆管理责任在你身上。** Auto Memory 给了工具，效果取决于你怎么用——MEMORY.md 的索引质量、主题文件的组织方式、定期审查的纪律性。
记忆系统的本质不是让 AI 变聪明。是让 AI 在正确的上下文中工作。
这才是 Context Engineering 真正在做的事。
下一篇我打算拆 Agent Teams 的多智能体协作机制——怎么让多个 Claude 同时干活还不打架。点关注不迷路。
---
> **栗子KK**，一个在 AI 浪潮中游泳的 AI 产品 Founder
>
> 欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来 🚀
---
> 参考来源：
> - [Anthropic 官方 Opus 4.6 发布](https://www.anthropic.com/news/claude-opus-4-6)
> - [Claude Code Changelog](https://claudelog.com/claude-code-changelog/)
> - [The Quiet Features That Shipped With Opus 4.6](https://paddo.dev/blog/quiet-features-opus-4-6/)
> - [Claude Code's quiet power play](https://www.implicator.ai/claude-codes-quiet-power-play-tooling-not-trophies/)
> - [How Claude Code Got Better by Protecting More Context](https://hyperdev.matsuoka.com/p/how-claude-code-got-better-by-protecting)
> - [Claude Code 安全漏洞 - The Register](https://www.theregister.com/2026/02/26/clade_code_cves/)
> - [claude-mem GitHub](https://github.com/thedotmack/claude-mem)
> - [AutoMem](https://therealjasoncoleman.com/2026/02/05/giving-claude-code-a-memory-and-a-soul-with-automem/)
> - [Anthropic Introduces Auto Memory System](https://www.thenextgentechinsider.com/pulse/anthropic-introduces-auto-memory-system-for-claude-code)
> - [.claude.json 膨胀 Issue #5024](https://github.com/anthropics/claude-code/issues/5024)
> - [Context Window Management 实测](https://blakecrosley.com/en/blog/context-window-management)

BIN
05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.9 MiB

BIN
05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.8 MiB

BIN
05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.3 MiB

BIN
05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.8 MiB

BIN
05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.8 MiB

BIN
05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 MiB

48
05-assets/claude-code-auto-memory-deep-dive/outline.md Normal file
View File

@ -0,0 +1,48 @@
---
type: mixed
density: per-section
style: blueprint-dark
image_count: 6
---
## Illustration 1
**Position**: Article cover / after opening hook
**Purpose**: First impression — show the full picture of Claude Code's memory system at a glance
**Visual Content**: Central "Claude Code" brain icon surrounded by three orbiting modules: Auto Memory (file icon), Agent Teams (multi-agent icon), Context Compaction (compression icon). Stats floating: "39% performance", "84% token reduction", "30hr autonomous". Dark navy background with glowing blue technical lines.
**Type**: infographic
**Filename**: 01-infographic-memory-system-overview.png
## Illustration 2
**Position**: Section 01 — memory layer architecture
**Purpose**: Visualize the 5-layer memory hierarchy from Enterprise Rules to Session Context
**Visual Content**: Vertical stack of 5 layers as horizontal bars/panels, Layer 0 (Enterprise Rules) at top in amber/gold, Layer 1 (CLAUDE.md) in bright blue, Layer 2 (Auto Memory) in cyan with glow effect, Layer 3 (Subagent Memory) in muted blue, Layer 4 (Session Context) at bottom in gray. Left labels, right descriptions. Grid-aligned, engineering precision.
**Type**: framework
**Filename**: 02-framework-three-layer-architecture.png
## Illustration 3
**Position**: Section 03 — after system prompt reveal
**Purpose**: Show the decision flow for when Auto Memory writes vs doesn't write
**Visual Content**: Top-down flowchart. Start: "会话进行中". Decision diamond: "用户说'记住这个'?" → Yes: "立即写入 MEMORY.md ✓" (green/cyan). No → Decision: "Claude 自主判断有用?" → Yes: "可能写入 (不靠谱)" (amber). No: "不记录 ✗" (red/dim). Dark background, glowing flow lines.
**Type**: flowchart
**Filename**: 03-flowchart-auto-memory-trigger.png
## Illustration 4
**Position**: Section 04 — 200 line limit explanation
**Purpose**: Visualize MEMORY.md structure, the 200-line hard cutoff, and relationship to topic files
**Visual Content**: Center: stylized MEMORY.md file with line numbers. Lines 1-200 glow blue (visible to Claude), lines 201+ are red/crossed out (truncated). Branching arrows from MEMORY.md to satellite topic files: debugging.md, patterns.md, architecture.md. Label: "主索引 → 主题文件". Warning indicator on the 200-line boundary.
**Type**: infographic
**Filename**: 04-infographic-memory-file-structure.png
## Illustration 5
**Position**: Section 07 — comparison of memory solutions
**Purpose**: Visual comparison of 3 memory approaches
**Visual Content**: Three columns side by side. Left: "官方 Auto Memory" (simple file icon, "零依赖", blue). Center: "claude-mem" (compressed file icon, "200:1 压缩", cyan). Right: "AutoMem" (graph+vector DB icons, "图DB+向量DB", amber). Bottom row: complexity meter from simple to complex. Each column shows key stats. Dark background.
**Type**: comparison
**Filename**: 05-comparison-best-practices.png
## Illustration 6
**Position**: Before final section — lifecycle overview
**Purpose**: Show the complete lifecycle of the memory system across sessions
**Visual Content**: Circular/loop flowchart. Stages: "会话启动 (加载MEMORY.md)" → "会话进行 (可能写入)" → "会话结束 (文件留磁盘)" → "新会话启动 (重新加载)" with a side branch: "Context Compaction (细节被压缩)" and "定期清理 (人工审查)". Glowing loop arrows, dark background.
**Type**: flowchart
**Filename**: 06-flowchart-memory-lifecycle.png

448
06-archived/2026-03-03-claude-code-auto-memory-deep-dive-v1.md Normal file
View File

@ -0,0 +1,448 @@
---
id: "2026-03-03-claude-code-auto-memory-deep-dive"
title: "Claude Code 记忆全拆解：从 system prompt 到 200 行 markdown，AI 编程助手怎么记住你的项目"
slug: "claude-code-auto-memory-deep-dive"
status: "draft"
content_type: "article"
channels: ["wechat", "x"]
language: "zh-CN"
source_urls:
- "https://www.anthropic.com/news/claude-opus-4-6"
- "https://claudelog.com/claude-code-changelog/"
- "https://paddo.dev/blog/quiet-features-opus-4-6/"
- "https://www.implicator.ai/claude-codes-quiet-power-play-tooling-not-trophies/"
- "https://hyperdev.matsuoka.com/p/how-claude-code-got-better-by-protecting"
- "https://www.theregister.com/2026/02/26/clade_code_cves/"
- "https://github.com/thedotmack/claude-mem"
- "https://therealjasoncoleman.com/2026/02/05/giving-claude-code-a-memory-and-a-soul-with-automem/"
- "https://www.thenextgentechinsider.com/pulse/anthropic-introduces-auto-memory-system-for-claude-code"
- "https://github.com/anthropics/claude-code/issues/5024"
- "https://blakecrosley.com/en/blog/context-window-management"
assets:
- "05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png"
- "05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png"
- "05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png"
- "05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png"
- "05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png"
- "05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png"
cover_image: "05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png"
template: "tech-blog"
owner: "content-forge"
created_at: "2026-03-03T00:00:00+08:00"
updated_at: "2026-03-03T00:00:00+08:00"
---
# Claude Code 记忆全拆解：从 system prompt 到 200 行 markdown，AI 编程助手怎么"记住"你的项目
> 深度解析 · 2026年2月
![Claude Code 记忆系统全景](05-assets/claude-code-auto-memory-deep-dive/01-infographic-memory-system-overview.png)
---
## 每次新会话都要重新介绍项目，你烦不烦？
用 Claude Code 的人都有这个痛点：开一个新会话，它对你的项目一无所知。你得重新告诉它"我们用 FastAPI + Next.js，后端端口 9801，状态管理用 Zustand，上次那个 bug 的根因是连接池耗尽……"
2026 年 2 月 5 日，Anthropic 发布了 Opus 4.6。大多数人只看到了"更强的模型"。但真正改变日常开发体验的，是随 Claude Code 一起上线的三个底层能力：
- **Auto Memory**——跨会话持久记忆
- **Agent Teams**——多智能体并行协作
- **Context Compaction**——上下文智能压缩
Anthropic 内部测试：智能体性能提升 39%，100 轮对话 token 消耗降低 84%，支持 30 小时无人值守运行。
这篇文章把 Auto Memory 的底层机制逐层拆开——版本演进、system prompt 注入原文、200 行硬截断的真实含义、5 个已知坑点，以及它和 Agent Teams、Context Compaction 之间的协同关系。
---
## 一、Claude Code 的记忆到底有几层
![三层记忆架构](05-assets/claude-code-auto-memory-deep-dive/02-framework-three-layer-architecture.png)
先看全貌。Claude Code 的记忆不是一坨东西，是分层的：
```
┌─────────────────────────────────────────────────────────┐
│ Layer 0: Enterprise Rules（最高优先级） │
│ └─ 组织管理员定义的全局规则，所有用户强制生效 │
│ │
│ Layer 1: CLAUDE.md 文件族（静态指令 · 人工维护） │
│ ├─ ~/.claude/CLAUDE.md ← 用户级，所有项目 │
│ ├─ <project>/CLAUDE.md ← 项目级，入库共享 │
│ ├─ <project>/CLAUDE.local.md ← 项目级，本地私有 │
│ └─ <subdir>/CLAUDE.md ← 子目录级，按需加载 │
│ │
│ Layer 2: Auto Memory（动态知识 · Claude 自主维护） │
│ ├─ MEMORY.md ← 主索引，自动加载（200行上限） │
│ └─ *.md ← 主题文件，按需读取（无行数限制） │
│ │
│ Layer 3: Subagent Memory（子代理记忆 · 独立隔离） │
│ │
│ Layer 4: Session Context（会话上下文 · 临时） │
└─────────────────────────────────────────────────────────┘
```
Layer 1 是"项目手册"——你写的规则、命令、规范，入 Git，团队共享。
Layer 2 是"个人笔记"——Claude 自己记的调试心得、踩坑经验，不入 Git，纯本地。
一个是宪法，一个是草稿纸。互补，不是替代。
| | CLAUDE.md（手册） | Auto Memory（笔记） |
|---|---|---|
| 谁写 | 人工维护 | Claude 主动写入 |
| 内容 | 编码规范、构建命令、禁止事项 | gotchas（陷阱）、失败模式、调试经验 |
| 入 Git | 是（团队共享） | 否（个人本地） |
| 上限 | 无硬限制 | 200 行（主索引） |
| 更新频率 | 低（架构级变更才改） | 高（每次会话可能更新） |
| 典型内容 | "始终使用 pytest 运行测试" | "检查 A 必须在 B 之前，否则测试 X 会失败" |
---
## 二、版本演进：从 # 前缀到 Auto Memory
Auto Memory 不是凭空冒出来的。三个阶段：
```
阶段 1: # 前缀时代（已弃用）
└─ 用户在对话中用 # 标记重要信息
└─ Claude 被动记录，能力有限
└─ 问题：完全依赖用户主动标记，Claude 不会自己判断
│
▼
阶段 2: Research Preview
└─ 需要手动在 ~/.claude/settings.json 中添加：
{ "autoMemoryEnabled": true }
└─ Claude 开始有"自主写入"能力
└─ 问题：默认关闭，大多数用户不知道这个功能存在
│
▼
阶段 3: 正式发布（v2.1.32+，当前）
└─ 默认开启，无需配置
└─ 可通过环境变量禁用：
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1
└─ Claude 主动记录 gotchas、失败模式、项目模式
└─ 与 Opus 4.6 的 Agent Teams / Context Compaction 协同
```
**旧的 # 前缀已经弃用了。** 还在用 # 标记的，该换了。
---
## 三、底层真相：就是读写 markdown 文件
先说结论：**没有向量数据库，没有语义检索，没有 RAG。**
就是 Claude 被允许在你电脑上的一个文件夹里读写 markdown 文件。每次开新会话，主文件塞进 system prompt。完事。
零依赖，纯文件 I/O。
```
~/.claude/projects/<project-path-hash>/memory/
├── MEMORY.md ← 主索引，每次会话自动加载（上限200行）
├── debugging.md ← 主题文件（按需创建，不自动加载）
├── patterns.md
├── architecture.md
└── ...
```
你可能觉得"就这？"——但这就是 Anthropic 的风格：**用最简单的机制解决 80% 的问题**。不过度工程化，不引入额外依赖。
---
## 四、拆开 system prompt：Claude 到底看到了什么
大多数文章不会讲这部分。每次会话启动，Claude Code 在 system prompt 里塞了一段指令。以下是我从实际运行环境中提取的完整内容：
```
You have a persistent auto memory directory at
`~/.claude/projects/<project>/memory/`.
Its contents persist across conversations.
## How to save memories:
- Organize memory semantically by topic, not chronologically
- Use the Write and Edit tools to update your memory files
- MEMORY.md is always loaded into your conversation context
— lines after 200 will be truncated, so keep it concise
- Create separate topic files (e.g., debugging.md, patterns.md)
for detailed notes and link to them from MEMORY.md
- Update or remove memories that turn out to be wrong or outdated
- Do not write duplicate memories. First check if there is an
existing memory you can update before writing a new one.
## What to save:
- Stable patterns and conventions confirmed across multiple interactions
- Key architectural decisions, important file paths, and project structure
- User preferences for workflow, tools, and communication style
- Solutions to recurring problems and debugging insights
## What NOT to save:
- Session-specific context (current task details, in-progress work)
- Information that might be incomplete
— verify against project docs before writing
- Anything that duplicates or contradicts existing CLAUDE.md instructions
- Speculative or unverified conclusions from reading a single file
## Explicit user requests:
- When the user asks you to remember something across sessions,
save it — no need to wait for multiple interactions
- When the user asks to forget or stop remembering something,
find and remove the relevant entries from your memory files
```
**Auto Memory 的全部"智能"就来自这段指令。**
Claude 没有特殊的记忆模块，没有额外的神经网络组件。它只是被告知"你有个文件夹可以读写，按这些规则来用"。
所谓"自主判断是否写入"，本质上就是 LLM 在 system prompt 指令下的推理——和你在 CLAUDE.md 里写"遇到 bug 先跑测试"是同一个机制。
![Auto Memory 触发决策流程](05-assets/claude-code-auto-memory-deep-dive/03-flowchart-auto-memory-trigger.png)
这也解释了写入行为为什么不稳定。忙于复杂任务时，这段指令的优先级自然被压低。Claude 不是不想记，是顾不上。
---
## 五、200 行限制：比你想的更硬
MEMORY.md 有 200 行的硬截断。不是"存在但优先级低"，是**第 201 行开始直接消失**：
```
MEMORY.md 总共 250 行
├─ 前 200 行 → 注入 system prompt ✓
└─ 第 201-250 行 → 硬截断，Claude 完全看不到 ✗
└─ Claude 收到截断警告，建议精简内容
```
主题文件（debugging.md 等）没有行数限制。但它们不自动加载——Claude 得用 Read 工具主动去读。
这里有个容易忽略的连锁反应：**MEMORY.md 的索引质量决定了整个记忆系统的有效性。** 如果里面没提到某个主题文件，Claude 压根不知道它存在。你精心写的 debugging.md 可能永远不会被读到。
所以 MEMORY.md 只能当目录用：
```markdown
# Memory Index
## 调试经验
- [后端连接池问题排查](./debugging.md) - 连接池耗尽的根因和修复方案
## 架构决策
- [消息工厂设计](./architecture.md) - SYSTEM/USER 消息拼装的分层逻辑
## 用户偏好
- [工作流偏好](./user-preferences.md) - 测试命令、部署流程、代码风格
```
简洁、只做索引、别超 200 行。具体内容全放主题文件。这 200 行是你的"记忆预算"，花在刀刃上。
![MEMORY.md 文件结构与 200 行截断机制](05-assets/claude-code-auto-memory-deep-dive/04-infographic-memory-file-structure.png)
---
## 六、数据流：三个阶段，一张图说清
前面拆了 system prompt 的内容，这里看整体流转。重点关注第二和第三阶段——写入时机和会话结束的行为：
```
┌─────────────────────────────────────────────────────────┐
│ 阶段一：会话启动 │
│ Claude Code 读 MEMORY.md 前 200 行 → 塞进 system prompt │
│ 其他 memory/*.md 不自动加载，需要时 Claude 自己去读 │
└──────────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 阶段二：会话进行中 │
│ │
│ Claude 会记什么： │
│ ├─ gotchas —— "检查 A 必须在 B 之前，否则测试 X 挂" │
│ ├─ 失败模式 —— "该 API 并发 > 100 时返回 429" │
│ ├─ 项目模式 —— "所有 router 必须用 API_PREFIX 注册" │
│ └─ 用户偏好 —— "用户偏好 pnpm 而非 npm" │
│ │
│ 什么时候写： │
│ ├─ 你说"记住这个" → 立即写（最靠谱） │
│ └─ Claude 自己觉得有用 → 看心情（不靠谱） │
└──────────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 阶段三：会话结束 │
│ 文件留在磁盘，下次自动可用 │
│ ⚠️ 没有"会话结束时自动总结"——这是和 claude-mem 的核心区别 │
└─────────────────────────────────────────────────────────┘
```
第三阶段是关键设计取舍：**官方方案完全依赖 Claude 在会话过程中的"自觉性"。** 会话结束不会触发任何自动保存。你聊了两小时发现了三个重要结论，但 Claude 没记——那就真没了。
---
## 七、三板斧协同：Auto Memory × Agent Teams × Context Compaction
Opus 4.6 同时上线的三个能力是一套组合拳：
```
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Auto Memory │ │ Agent Teams │ │ Context │
│ 跨会话记忆 │ │ 多智能体协作 │ │ Compaction │
│ │ │ │ │ 上下文压缩 │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ 解决： │ │ 解决： │ │ 解决： │
│ "每次重新 │ │ "一个人干 │ │ "聊久了就 │
│ 介绍项目" │ │ 不过来" │ │ 忘事" │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└────────────────────┼────────────────────┘
│
┌───────▼───────┐
│ 30小时无人 │
│ 值守自主运行 │
└───────────────┘
```
前面提到的那组数据（token 降 84%、性能升 39%）就是这三者组合的效果。
但有几个细节容易踩坑：
**子代理记忆是隔离的。** Agent Teams 的子代理有独立记忆空间，读不到主会话的 Auto Memory，也不会污染主记忆。好处是干净，坏处是子代理对项目上下文一无所知。
**Context Compaction 会吃掉记忆。** 最新版本在上下文使用率 64-75% 时就触发压缩（比以前的 90%+ 激进得多），MEMORY.md 的细节可能在压缩中被摘要化。你以为 Claude 记着呢，其实早忘了。
**Adaptive Thinking 省 token。** Claude 根据问题复杂度自动调整思考深度，简单问题不浪费 token，把预算留给真正需要深度推理的场景。
---
## 八、5 个已知坑点
### 坑 1：聊久了记忆会被压缩掉
```
会话开始: MEMORY.md 内容完整 ✓
▼ （对话越来越长）
上下文压缩触发（64-75% 容量时）
▼
MEMORY.md 的细节被摘要化 ✗
```
发现 Claude 开始"忘事"了？用 `/clear` 开新会话。记忆会重新完整加载。
### 坑 2：Claude 经常忘记写笔记
写入完全靠 Claude "自觉"。实际用下来：
- 忙着干活时根本想不起来要记东西
- 写入质量参差不齐，有时太笼统，有时写了不该写的
- 不同模型版本的写入倾向还不一样
**最靠谱的办法就一个：你自己说"把这个记下来"。** 别指望它自觉。
### 坑 3：换路径打开项目，记忆就断了
记忆目录按项目路径哈希生成。同一个项目换个路径打开，就是两套独立记忆：
```
/home/user/apps/my-project → memory-A
/mnt/disk/my-project → memory-B
```
多台机器或多个挂载点工作的人要注意。
### 坑 4：.claude.json 越来越胖
GitHub issue #5024：`.claude.json` 持续累积会话历史，文件越来越大。不是 Auto Memory 的锅，但会拖慢整体体验。
### 坑 5：旧记忆比没记忆更危险
Claude 不会主动清理过时记忆。项目架构改了，记忆还是旧的，Claude 就会基于错误信息做决策。
**过时的记忆不是"没用"，是"有害"。** 得你自己定期去看看，删掉过时的。
---
## 九、官方够用吗？看项目规模
官方 Auto Memory 不够用时，社区有两个主流替代：
```
官方 Auto Memory claude-mem AutoMem
────────────── ────────── ───────
存储 纯 markdown 文件 压缩后的文本 图DB + 向量DB
写入触发 Claude 自主判断 Hook 自动捕获 Hook 自动捕获
会话结束 啥也不干 自动捕获+压缩 自动捕获+向量化
压缩 无 ~200:1 压缩率 向量化
关系推理 无 无 图数据库支持
依赖 零 Bun + uv Docker 全家桶
上限 MEMORY.md 200行 配置化 无硬限制
可靠性 看 Claude 心情 自动化，稳定 自动化，稳定
```
怎么选？看项目大小：
- **个人项目、小团队**——官方够了。零配置零依赖，能跑就行。
- **中等复杂度**——上 claude-mem。自动捕获 + AI 压缩，1 万 token 的会话内容压到约 50 token，200:1 的压缩率。
- **大型长期项目**——考虑 AutoMem。图数据库做关系推理，但得跑 Docker。
---
![记忆管理最佳实践对比](05-assets/claude-code-auto-memory-deep-dive/05-comparison-best-practices.png)
## 十、6 条实战建议
1. **MEMORY.md 只当目录用。** 只放链接和一句话摘要。200 行限制逼你这么做，别跟它较劲。
2. **按主题建文件，别按时间排。** debugging.md、architecture.md、user-preferences.md。语义组织，不是流水账。
3. **重要的事主动说"记住"。** "把这个调试结论写到 memory 里"——这句话比什么都靠谱。别等 Claude 自觉，它不会的。
4. **每周扫一眼 memory 文件夹。** 2 分钟的事。打开 `~/.claude/projects/` 下的 memory 目录，过时的删掉。旧记忆比没记忆更危险，前面说过了。
5. **聊天太长就 `/clear`。** Context Compaction 会吃记忆，`/clear` 让记忆重新完整加载。代价是丢失当前会话上下文，但总比 Claude 基于残缺记忆做决策强。
6. **不想用可以关。** 设置环境变量 `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1` 即可。
---
## 安全提醒
2026 年 2 月 26 日，The Register 报道了 Claude Code 的安全漏洞（CVE）：攻击者可以在仓库中注入恶意配置文件，实现远程代码执行和 API Key 窃取。
这和记忆系统直接相关。如果有人能操纵你的 MEMORY.md 或 CLAUDE.md，就能影响 Claude 的行为。想想看——Claude 每次启动都无条件信任这些文件的内容。
几个基本防护：
- 定期看看 memory 目录，确认没被注入奇怪的指令
- 别在 memory 文件里存 API Key、密码这类东西
- clone 陌生仓库后，先看看有没有 CLAUDE.md 或 .claude/ 目录
---
![记忆系统生命周期](05-assets/claude-code-auto-memory-deep-dive/06-flowchart-memory-lifecycle.png)
## 写在最后
Auto Memory 的技术实现朴素到令人意外。就是读写 markdown 文件。
但它代表了一个方向：AI 编程助手从"无状态工具"变成"有记忆的协作者"。Anthropic 选了最简单的路——不搞向量数据库，不搞 RAG 管线，system prompt + 文件读写，完事。
这个选择本身就是一种工程品味。用最少的复杂度解决最核心的问题。
不过，**真正的记忆管理责任在你身上。** Auto Memory 给了工具，但效果取决于你怎么用——MEMORY.md 的索引质量、主题文件的组织方式、定期审查的纪律性。
说到底，记忆系统的本质不是让 AI 变聪明。是让 AI 在正确的上下文中工作。这才是 Context Engineering 真正在做的事。
---
> 参考来源：
> - [Anthropic 官方 Opus 4.6 发布](https://www.anthropic.com/news/claude-opus-4-6)
> - [Claude Code Changelog](https://claudelog.com/claude-code-changelog/)
> - [The Quiet Features That Shipped With Opus 4.6](https://paddo.dev/blog/quiet-features-opus-4-6/)
> - [Claude Code's quiet power play](https://www.implicator.ai/claude-codes-quiet-power-play-tooling-not-trophies/)
> - [How Claude Code Got Better by Protecting More Context](https://hyperdev.matsuoka.com/p/how-claude-code-got-better-by-protecting)
> - [Claude Code 安全漏洞 - The Register](https://www.theregister.com/2026/02/26/clade_code_cves/)
> - [claude-mem GitHub](https://github.com/thedotmack/claude-mem)
> - [AutoMem](https://therealjasoncoleman.com/2026/02/05/giving-claude-code-a-memory-and-a-soul-with-automem/)
> - [Anthropic Introduces Auto Memory System](https://www.thenextgentechinsider.com/pulse/anthropic-introduces-auto-memory-system-for-claude-code)
> - [.claude.json 膨胀 Issue #5024](https://github.com/anthropics/claude-code/issues/5024)
> - [Context Window Management 实测](https://blakecrosley.com/en/blog/context-window-management)

153
templates/author-style-lizi-kk.md Normal file
View File

@ -0,0 +1,153 @@
# Author Style: 栗子KK
> 基于 `personal-context/` 目录 5 篇已发表文章分析提炼
## 1. 开头模式（Hook Patterns）
### 1.1 冲击式开头
```markdown
说实话，昨天深夜在算这几个月AI Coding开销的时候，我手稍微抖了一下。
**20,000 美金。**
```
### 1.2 反差式开头
```markdown
前几天刷技术博客，看到一篇Claude Code教程有3万+阅读，点进去一看我就傻眼了。
整篇文章洋洋洒洒5000字...结果连个CLAUDE.md配置文件都没提到。
```
### 1.3 共鸣式开头
```markdown
最近和几个AI创业的朋友聊天，发现一个有趣的现象：大家都在搞Agent，但聊起具体实现时，基本都在Message Flow这个环节栽过跟头。
```
### 1.4 经验式开头
```markdown
从cursor爆火到现在不到一年时间，我基本把市面上能找到的AI代码工具都长期用过了个遍。
```
## 2. 结构模板
### 2.1 数字编号结构
```markdown
## 01 主标题
### 02 次标题
### 03 次标题
...
## Part 5: 总结
```
### 2.2 段落规则
- 每段 **2-5 句话**
- 单段不超过 **150 字**
- 长内容必须拆段
### 2.3 列表使用
```markdown
- • 项目一（带圆点缩进）
- • 项目二
```
## 3. 语言特征
### 3.1 口语化表达
| 书面语 | 栗子KK风格 |
|--------|-----------|
| 我发现 | 说实话，我发现 |
| 这个问题很重要 | 这个问题我觉得特别典型 |
| 效果很好 | 效果立竿见影 |
| 很多人不知道 | 99%的教程都不提这个 |
| 成功了 | 这招真的管用 |
### 3.2 强调技巧
- **加粗关键词**：`**20,000 美金**`
- **数字冲击**："99%"、"90%"、"2000美金"
- **反问句**："为什么要发这个图？"、"这叫MVP吗？"
### 3.3 技术深度
- 代码示例：必须有，但不能太长（10-30行）
- 架构图：用文字描述或ASCII图
- 数据对比：配置前后对比表
## 4. 内容元素
### 4.1 必备元素
1. **个人经历**：踩过的坑、花过的钱、做过的项目
2. **具体案例**：不是泛泛而谈，要有细节
3. **代码示例**：技术文章必须有代码
4. **数据支撑**：效率提升X%、时间从Y降到Z
### 4.2 可选元素
- 名人金句引用（Linus、冯骥等）
- 对比表格
- 配图位置标记（`![图片]()`）
- 产品推荐（自己的或相关的）
### 4.3 结尾模板
```markdown
## 写在最后
[总结核心观点]
如果你也在[场景]，欢迎[CTA]。
栗子KK，
一个在AI浪潮中游泳的AI产品Founder
欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来 🚀
```
## 5. 语气调性
### 5.1 自信但不傲慢
- ✅ "我做了一个产品，我觉得还不错"
- ❌ "我做出了全球最好的产品"
### 5.2 专业但不晦涩
- ✅ 用类比解释复杂概念
- ✅ 代码示例配文字说明
- ❌ 纯技术术语堆砌
### 5.3 真实但不卖惨
- ✅ "烧了2000美金，但这钱花得值"
- ❌ "我花了好多钱好心疼"
## 6. 禁忌清单
| 避免 | 原因 |
|------|------|
| "赋能"、"生态"等空话 | 作者明确说不讲这些 |
| 纯理论无案例 | 缺乏说服力 |
| 过长的代码块 | 影响阅读节奏 |
| 没有个人观点 | 变成教程而非文章 |
| 完美主义收尾 | 作者信奉"Done is better than perfect" |
## 7. 适配场景
此风格适合：
- 技术深度文章
- 产品发布/介绍
- 踩坑经验分享
- 行业趋势分析
此风格**不适合**：
- 纯教程（步骤太多会打断节奏）
- 新闻报道（需要更多客观性）
- 学术论文（需要更正式的语气）
## 8. 示例段落
```markdown
## 真相：大部分人都在"裸奔"
"Claude Code不是安装了就能用吗？还需要配置什么？"
难怪你每次启动要等半分钟，每个项目都要重新解释一遍结构。
CLAUDE.md就像给Claude装了个大脑，你的项目规范、常用命令、核心逻辑都可以写进去。Claude会自动加载这些信息，不用每次都从头解释。
**效果立竿见影**：启动时间从15秒降到3秒，理解项目从5分钟变成0等待。
```

175
templates/review-checklist.md Normal file
View File

@ -0,0 +1,175 @@
# Review Checklist
> Template for structured content review. Use with `/review` command.
## Article Info
- **Title**: {{title}}
- **Slug**: {{slug}}
- **Status**: {{status}}
- **Review Date**: {{date}}
---
## 1. Structure Review (结构审)
### 1.1 Logic Flow
- [ ] Opening hooks reader effectively
- [ ] Main argument has clear progression
- [ ] Transitions between sections are smooth
- [ ] Conclusion reinforces key points
- [ ] No logical gaps or jumps
### 1.2 Paragraph Structure
- [ ] Each paragraph has single main idea
- [ ] Paragraphs are appropriately sized (3-7 sentences)
- [ ] Topic sentences are clear
- [ ] Supporting details are relevant
### 1.3 Information Hierarchy
- [ ] Headings reflect content accurately
- [ ] Important information is emphasized
- [ ] Subheadings break up long sections
- [ ] Visual elements support structure
**Issues Found**:
```
# List issues as: [{id, severity, description}]
# Example:
# - id: S1, severity: medium, description: "Section 3 lacks transition to Section 4"
```
---
## 2. Factual Review (事实审)
### 2.1 Data Accuracy
- [ ] All statistics have sources
- [ ] Numbers are correctly cited
- [ ] Claims are verifiable
- [ ] No fabricated data
### 2.2 Reference Quality
- [ ] Source URLs are accessible
- [ ] Quotes are accurate
- [ ] Citations follow consistent format
- [ ] No broken or outdated references
### 2.3 Technical Accuracy
- [ ] Technical terms used correctly
- [ ] Code examples work as described
- [ ] API references are current
- [ ] No misleading simplifications
**Issues Found**:
```
# Critical: Must fix before publication
# High: Strong recommendation to fix
# Medium: Should consider fixing
# Low: Nice to have
```
---
## 3. Style Review (文风审)
### 3.1 Audience Match
- [ ] Tone matches target audience ({{audience}})
- [ ] Jargon is appropriate or explained
- [ ] Examples resonate with readers
- [ ] Complexity level is consistent
### 3.2 Voice Consistency
- [ ] Writing style is consistent throughout
- [ ] Active voice is preferred
- [ ] Tense usage is consistent
- [ ] POV (first/second/third person) is consistent
### 3.3 Readability
- [ ] Sentences are clear and concise
- [ ] No unnecessary wordiness
- [ ] Complex ideas are well-explained
- [ ] Paragraph breaks aid scanning
**Issues Found**:
```
# Focus on patterns, not isolated issues
```
---
## 4. Format Review (格式审)
### 4.1 Markdown Compliance
- [ ] Headings use proper hierarchy (# ## ###)
- [ ] Lists are properly formatted
- [ ] Code blocks have language specified
- [ ] Links use correct syntax `[text](url)`
### 4.2 Frontmatter Integrity
- [ ] All required fields present
- [ ] Dates in ISO 8601 format
- [ ] Arrays use valid YAML syntax
- [ ] No trailing spaces or special chars
### 4.3 Asset References
- [ ] Images have alt text
- [ ] Asset paths are vault-relative
- [ ] Cover image is specified
- [ ] All referenced assets exist
**Issues Found**:
```
# Format issues block automated processing
```
---
## Summary
### Issue Counts
| Category | Critical | High | Medium | Low |
|----------|----------|------|--------|-----|
| Structure | 0 | 0 | 0 | 0 |
| Factual | 0 | 0 | 0 | 0 |
| Style | 0 | 0 | 0 | 0 |
| Format | 0 | 0 | 0 | 0 |
| **Total** | **0** | **0** | **0** | **0** |
### Decision
- [ ] **PASSED** - Ready for polish (Critical=0, High≤1)
- [ ] **FAILED** - Requires revision (Critical≥1 OR High>1)
### Review Status Update
```bash
# If PASSED:
obsidian property:set path="{{path}}" name="review_status" value="passed"
obsidian property:set path="{{path}}" name="review_passed_at" value="{{iso_timestamp}}"
# If FAILED:
obsidian property:set path="{{path}}" name="review_status" value="failed"
obsidian property:set path="{{path}}" name="status" value="revision"
obsidian property:set path="{{path}}" name="revision_count" value="{{new_count}}"
```
### Reviewer Notes
> Add any additional observations or recommendations for the author.
---
## Revision Tracking
After fixes are applied:
```yaml
revision_history:
- date: "{{date}}"
issues_fixed:
- "S1: Added transition paragraph"
- "F2: Updated source URL"
notes: "Author addressed all critical issues"
```

37
templates/viral-example.md Normal file
View File

@ -0,0 +1,37 @@
---
id: ""
title: ""
source_url: ""
platform: "" # x | wechat | xiaohongshu | douyin | bilibili | medium | other
author: ""
author_url: ""
published_at: ""
collected_at: ""
metrics:
likes: null
comments: null
shares: null
views: null
viral_score: null
tags: []
language: "zh-CN"
related_topics: []
analysis: null
takeaways: []
---
# 原文（或摘要）
[原文内容或核心观点摘要]
# 为什么火
[你的分析：时机、情绪、表达、平台特性等]
# 可复用点
-
# 关联选题
- [[01-topics/xxx|相关选题]]