# Claude Code：你不知道的架构、治理与工程实践

本文欲回答的核心问题：Claude Code 到底是怎么从底层运作的？为什么上下文越来越乱、工具越多效果越差？怎样通过正确的架构治理、Skills 设计和 Hooks 让它真正成为可靠的工程工具，而不是随手一用的聊天机器人？

我用了两个账号，每个月花 40 美元氪金，深度折腾 Claude Code 半年。刚开始我真把它当成普通聊天工具，写写 Prompt 就完事。后来发现不对劲：上下文乱成一锅粥，规则越写越长却越不遵守，工具堆得越来越多却越来越不听话。折腾了好久，我才搞清楚，这根本不是 Prompt 写得不够好，而是整个系统的设计逻辑就这样。我把这些踩坑经验和底层拆解写出来，希望帮到正在用或者打算用的朋友。

我把 Claude Code 拆成六层来看待。这六层分别是底层运行机制、上下文工程、概念边界、Skills 设计、工具与 Hooks、Subagents 与验证闭环。只强化其中一层，系统就会失衡。CLAUDE.md 写太长，上下文先把自己污染了；工具太多，选择就迷糊了；Subagents 开得到处都是，状态就漂移了；验证跳过，出了问题根本不知道哪里挂。

## 本段欲回答的核心问题：Claude Code 底层到底是怎么运行的？它是一个怎样的反复循环过程？

Claude Code 的核心不是单纯回答问题，而是一个反复循环的代理过程。我一开始没意识到这点，总觉得卡住是因为模型不够聪明。后来才明白，问题大多出在给了错误的上下文，或者写出来了却没法判断对不对，也没法撤回。

整个循环长这样：

收集上下文 → 采取行动 → 验证结果 → [完成 or 回到收集]

↑ ↓

CLAUDE.md Hooks / 权限 / 沙箱

Skills Tools / MCP

Memory

这五个层面我后来反复看，对着它们排查问题就清晰多了。结果不稳定？查上下文加载顺序，不是模型的事。自动化失控？看控制层有没有设计好，不是 agent 太主动。长会话质量下降？中间产物把上下文污染了，换个新会话比反复调 Prompt 有用得多。

我把这张底层运行图贴在这里，直观感受一下循环是怎么转的。

对着这几个面看，很多问题就好排查了。我自己后来养成习惯，每次卡住就先问自己：上下文对不对？验证闭环有没有？控制层设计了没？这样省了很多时间。

## 本段欲回答的核心问题：Claude Code 里 MCP、Plugin、Tools、Skills、Hooks、Subagents 这些概念到底有什么边界？怎么区分使用？

很多人把这些词混着用，结果工具和规则乱套。我后来把它们划得清清楚楚，简单记：给 Claude 新动作能力用 Tool 或 MCP，给它一套工作方法用 Skill，需要隔离执行环境用 Subagent，要强制约束和审计用 Hook，跨项目分发用 Plugin。

我把这张边界对比图放上来，一眼就能记住区别。

MCP Plugin Tools Skills Hooks Subagents 边界图

这样划分后，我再也不乱套了。需要 Claude 干活就给 Tool，需要它按流程走就给 Skill，需要它别乱改文件就加 Hook。边界清楚了，系统就稳了。

## 本段欲回答的核心问题：Claude Code 的上下文为什么总是乱？真实成本构成是什么？怎么分层治理才能保持干净高效？

很多人把上下文当容量问题，觉得 200K 够大就行。但我发现卡住的地方通常不是不够长，而是太吵了，有用的信息被大量无关内容淹没了。

真实的上下文成本构成我后来算得很细。200K 总上下文里，固定开销就有 15-20K：系统指令 2K，所有启用的 Skill 描述符 1-5K，MCP Server 工具定义最多能吃掉 10-20K，LSP 状态 2-5K。半固定还有 5-10K：CLAUDE.md 2-5K，Memory 1-2K。真正动态可用的只剩 160-180K。

一个典型 MCP Server 比如 GitHub，包含 20-30 个工具定义，每个约 200 tokens，合计 4000-6000 tokens。接 5 个 Server，光这部分固定开销就到 25000 tokens，占 12.5%。我第一次算出这个数字时吓一跳，在要读大量代码的场景，这 12.5% 真的很关键。

我把这张上下文成本分解图贴在这里，大家一看就明白为什么固定开销是隐形杀手。

推荐的上下文分层我现在严格遵守：

始终常驻 → CLAUDE.md：项目契约、构建命令、禁止事项

按路径加载 → rules：语言、目录、文件类型特定规则

按需加载 → Skills：工作流、领域知识

隔离加载 → Subagents：大量探索、并行研究

不进上下文 → Hooks：确定性脚本、审计、阻断

偶尔用的东西就不要每次都加载进来。这条我踩过坑，早期把所有东西塞 CLAUDE.md，结果上下文先把自己污染了。

上下文最佳实践我总结了几条，用下来效果很好：

保持 CLAUDE.md 短、硬、可执行，优先写命令、约束、架构边界。Anthropic 官方自己的 CLAUDE.md 大约只有 2.5K tokens，我参考了，确实干净。

把大型参考文档拆到 Skills 的 supporting files，不要塞进 SKILL.md 正文。

使用 .claude/rules/ 做路径、语言规则，不让根 CLAUDE.md 承担所有差异。

长会话主动用 /context 观察消耗，不要等系统自动压缩后再补救。

任务切换优先 /clear，同一任务进入新阶段用 /compact。

把 Compact Instructions 写进 CLAUDE.md，压缩后必须保留什么由你控制，不由算法猜。

我把这张上下文最佳实践图也放上来，便于对照。

压缩机制的陷阱我最开始没注意，默认压缩算法按“可重新读取”判断，早期的 Tool Output 和文件内容会被优先删掉，顺带把架构决策和约束理由也一起扔了。两小时后再改，可能根本不记得两小时前定了什么，莫名其妙的 Bug 就是这么来的。

我把这张压缩陷阱示意图贴在这里，看完就知道为什么会丢关键信息。

解决方案我在 CLAUDE.md 里写明 Compact Instructions：

## Compact Instructions

When compressing, preserve in priority order:

Architecture decisions (NEVER summarize)
Modified files and their key changes
Current verification status (pass/fail)
Open TODOs and rollback notes
Tool outputs (can delete, keep pass/fail only)

还有一种更主动的方案：在开新会话前，先让 Claude 写一份 HANDOFF.md，把当前进度、尝试过什么、哪些走通了、哪些是死路、下一步该做什么写清楚。下一个 Claude 实例只读这个文件就能接着做，不依赖压缩算法的摘要质量。

我在 HANDOFF.md 里写清楚现在的进展。解释你试了什么、什么有效、什么没用，让下一个拿到新鲜上下文的 agent 只看这个文件就能继续完成任务。

写完后快速扫一眼，有缺漏直接让它补，然后开新会话，把 HANDOFF.md 的路径发过去就行。

Plan Mode 的工程价值我现在特别推。核心是把探索和执行拆开，探索阶段不动文件，确认方案后再执行。探索阶段以只读操作为主，Claude 可以先澄清目标和边界，再提交具体方案，执行成本在计划确认之后才发生。

我把这张 Plan Mode 价值图贴上来。

对于复杂重构、迁移、跨模块改动，这样做比急着出代码有用多了，它能显著降低在错误假设上持续修改的概率。按两下 Shift+Tab 进入 Plan Mode，进阶玩法是开一个 Claude 写计划，再开一个 Codex 以“高级工程师”身份审这个计划，让 AI 审 AI，效果很好。

我把这张 Plan Mode 操作图也放这里。

## 本段欲回答的核心问题：Skills 到底该怎么设计？它不是模板库，而是按需加载的工作流，怎么才能让它真正发挥作用？

Skill 官方描述是“按需加载的知识与工作流”，描述符常驻上下文，完整内容按需加载，用起来和“保存的 Prompt”差别挺大的。一个好 Skill 应该满足：描述要让模型知道“何时该用我”，而不是“我是干什么的”；有完整步骤、输入、输出和停止条件；正文只放导航和核心约束，大资料拆到 supporting files 里；有副作用的 Skill 要显式设置 disable-model-invocation: true，不然 Claude 会自己决定要不要跑。

我把一个比较稳定的 Skill 结构放出来：

.claude/skills/

└── incident-triage/

├── SKILL.md

├── runbook.md

├── examples.md

└── scripts/

    └── collect-context.sh

Skill 的三种典型类型我自己在开源 terminal 项目里用过，效果很稳。

类型一：检查清单型（质量门禁）

发布前跑一遍，确保不漏项：

---
name: release-check
description: Use before cutting a release to verify build, version, and smoke test.
---

## Pre-flight (All must pass)
- [ ] `cargo build --release` passes
- [ ] `cargo clippy -- -D warnings` clean
- [ ] Version bumped in Cargo.toml
- [ ] CHANGELOG updated
- [ ] `kaku doctor` passes on clean env

## Output
Pass / Fail per item. Any Fail must be fixed before release.

类型二：工作流型（标准化操作）

配置迁移高风险，显式调用 + 内置回滚步骤：

---
name: config-migration
description: Migrate config schema. Run only when explicitly requested.
disable-model-invocation: true
---

## Steps
1. Backup: `cp ~/.config/kaku/config.toml ~/.config/kaku/config.toml.bak`
2. Dry run: `kaku config migrate --dry-run`
3. Apply: remove `--dry-run` after confirming output
4. Verify: `kaku doctor` all pass

## Rollback
`cp ~/.config/kaku/config.toml.bak ~/.config/kaku/config.toml`

类型三：领域专家型（封装决策框架）

运行时出问题时让 Claude 按固定路径收集证据，不要瞎猜：

---
name: runtime-diagnosis
description: Use when kaku crashes, hangs, or behaves unexpectedly at runtime.
---

## Evidence Collection
1. Run `kaku doctor` and capture full output
2. Last 50 lines of `~/.local/share/kaku/logs/`
3. Plugin state: `kaku --list-plugins`

## Decision Matrix
| Symptom | First Check |
|---|---|
| Crash on startup | doctor output → Lua syntax error |
| Rendering glitch | GPU backend / terminal capability |
| Config not applied | Config path + schema version |

## Output Format
Root cause / Blast radius / Fix steps / Verification command

描述符写短点，每个 Skill 都在偷你的上下文空间。我优化前后差距很大：

低效（~45 tokens）

description: |

This skill helps you review code changes in Rust projects.

It checks for common issues like unsafe code, error handling…

Use this when you want to ensure code quality before merging.

高效（~9 tokens）

description: Use for PR reviews with focus on correctness.

disable-auto-invoke 使用策略我也总结了：高频（>1 次/会话）保持 auto-invoke，优化描述符；低频（<1 次/会话）disable-auto-invoke，手动触发；极低频（<1 次/月）移除 Skill，改为 AGENTS.md 中的文档。

Skills 反模式我踩过不少：描述过短、一个 Skill 覆盖五件事、有副作用却允许自动调用。这些坑现在我都避开了。

## 本段欲回答的核心问题：工具该怎么设计才能让 Claude 少选错？好工具和坏工具的区别在哪里？

我后面越用越觉得，给 Claude 的工具和给人写的 API 不是一回事。给人用的 API 追求功能齐全，但给 agent 用，重点不是功能堆得多完整，而是让它更容易用对。

好工具 vs 坏工具我总结了几个实用原则：名称前缀按系统或资源分层；对大响应支持 response_format: concise / detailed；错误响应要教模型如何修正；能合并成高层任务工具时，不要暴露过多底层碎片工具。

我把这张好工具设计原则图贴上来。

从 Claude Code 内部工具演进我学到很多。像需要中途问用户的场景，他们试了三种做法，最后独立做成 AskUserQuestion 工具最稳。Todo 工具早期有用，后来模型变强反而成了枷锁。搜索工具从 RAG 改成 Grep，让 Claude 自己搜索，效果显著提升，还实现了渐进式披露。

什么时候不该再加 Tool：本地 shell 可以可靠完成的事、模型只需要静态知识、需求更适合 Skill、还没验证过工具描述能被模型稳定使用。

我把工具演进的对比图也放这里。

还有 AskUserQuestion 为什么最稳的示意图。

Todo 工具演进图我也留着。

## 本段欲回答的核心问题：Hooks 到底该放什么？它是怎么在执行前后强制插入逻辑，让整个流程更确定性的？

Hooks 很容易被当成“自动运行的脚本”，但我自己用下来，觉得它更像是把一些不能交给 Claude 临场发挥的事情，重新收回到确定性的流程里。比如格式化要不要跑、保护文件能不能改、任务完成后要不要通知，这些事真不要指望 Claude 每次都自己记得。

当前支持的 Hook 点我严格按照官方来用。适合放 Hooks 的：阻断修改受保护文件、Edit 后自动格式化、SessionStart 后注入动态上下文、任务完成后推送通知。不适合：需要读大量上下文的复杂判断、长时间运行的业务流程、需要多步推理的决策。

我把这张 Hook 点示意图贴上来。

一个实际的 Hooks 配置示例：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "pattern": "*.rs",
        "hooks": [
          {
            "type": "command",
            "command": "cargo check 2>&1 | head -30",
            "statusMessage": "Running cargo check..."
          }
        ]
      }
    ],
    "Notification": [
      {
        "type": "command",
        "command": "osascript -e 'display notification \"Task completed\" with title \"Claude Code\"'"
      }
    ]
  }
}

Hooks 越早发现错误越省时间。在 100 次编辑的会话中，每次节省 30-60 秒，累积节省 1-2 小时。注意限制输出长度，避免 Hook 输出反而污染上下文。

Hooks + Skills + CLAUDE.md 三层叠加最稳。只写 CLAUDE.md，Claude 经常当没看见；只靠 Hooks，细节判断又做不了。三样一起用才比较可靠。

我把这张 Hooks 省时示意图放上来。

## 本段欲回答的核心问题：Subagents 正确用法是什么？它到底该用来隔离什么，怎么配置才能不让主线程被污染？

Subagent 就是从主对话派出去的一个独立 Claude 实例，有自己的上下文窗口、只用你指定的工具、干完汇报结果。核心价值不是并行，而是隔离。扫代码库、跑测试、做审查这类会产生大量输出的事，交给 Subagent 做，主线程只拿摘要，不会被中间过程污染。

配置时要显式约束：tools / disallowedTools 限定权限；model 根据任务选 Haiku/Sonnet/Opus；maxTurns 防止跑飞；isolation: worktree 需要动文件时隔离文件系统。

长时间运行的 bash 命令可以按 Ctrl+B 移到后台，Claude 之后会用 BashOutput 工具查看结果，不会阻塞主线程。Subagent 同理，直接告诉它在后台跑就行。

几个常见反模式我避开了：子代理权限和主线程一样宽、输出格式不固定、子任务之间强依赖。

## 本段欲回答的核心问题：Prompt Caching 在 Claude Code 架构里到底有多重要？怎么设计 Prompt 才能最大化缓存命中率？

工程界有句话“Cache Rules Everything Around Me”，对 agent 同样如此。Claude Code 的整个架构都是围绕 Prompt 缓存构建的，高缓存命中率不只降低成本，也帮助创造更宽松的速率限制。

为缓存设计的 Prompt Layout 顺序很重要：

System Prompt → 静态，锁定
Tool Definitions → 静态，锁定
Chat History → 动态，在后面
当前用户输入 → 最后

我把这张 Prompt 缓存布局图贴上来。

破坏缓存的常见陷阱：静态系统 Prompt 放入带时间戳的内容、非确定性地打乱工具定义顺序、会话中途增删工具。

Compaction 的实际实现我后来搞清楚了：左边上下文快满，中间开 fork 调用 Summarize，命中缓存只需 1/10 价格，右边替换成摘要，System + Tools 还在。

我把这张 Compaction 执行流程图放这里。

defer_loading：工具的延迟加载，让缓存前缀保持稳定。

## 本段欲回答的核心问题：没有验证闭环的 Agent 到底能算工程工具吗？Verifier 该怎么层层定义？

“Claude 说完成了”其实没啥用，你得能知道它做没做对、出了问题能退回来、过程还能查，这才算数。

Verifier 的层级：

最低层：命令退出码、lint、typecheck、unit test

中间层：集成测试、截图对比、contract test、smoke test

更高层：生产日志验证、监控指标、人工审查清单

在 Prompt、Skill 和 CLAUDE.md 中显式定义验证。我的模板是：

## Verification

For backend changes:

Run make test and make lint
For API changes, update contract tests under tests/contracts/

For UI changes:

Capture before/after screenshots if visual

Definition of done:

All tests pass
Lint passes
No TODO left behind unless explicitly tracked

我自己有个判断：假如一个任务你都说不清楚“Claude 怎么才算做对了”，那它大概率也不适合直接丢给 Claude 自动完成。

## 本段欲回答的核心问题：高频命令到底有哪些？它们怎么帮助主动管理上下文和能力？

这些命令就干一件事：主动管理上下文，别等系统自己处理。

上下文管理：

/context # 查看 token 占用结构，排查 MCP 和文件读取占比

/clear # 清空会话，同一问题被纠偏两次以上就重来

/compact # 压缩但保留重点，配合 Compact Instructions

/memory # 确认哪些 CLAUDE.md 真的被加载了

能力与治理：

/mcp # 管理 MCP 连接，检查 token 成本，断开闲置 server

/hooks # 管理 hooks，控制平面入口

/permissions # 查看或更新权限白名单

/sandbox # 配置沙箱隔离，高自动化场景必备

/model # 切换模型：Opus 用于深度推理，Sonnet 用于常规，Haiku 用于快速探索

会话连续性与并行：

claude –continue # 恢复当前目录最近会话，隔天接着做

claude –resume # 打开选择器恢复历史会话

claude –continue –fork # 从已有会话分叉，同一起点不同方案

claude –worktree # 创建隔离 git worktree

claude -p “prompt” # 非交互模式，接入 CI / pre-commit / 脚本

claude -p –output-format json # 结构化输出，便于脚本消费

几个不常见但很好用的命令：/simplify、/rewind、/btw、claude -p –output-format stream-json、/insight、双击 ESC 回溯。

对话历史都在本地：~/.claude/projects/ 下，想找历史直接 grep 就行。

我把这张能力与治理命令图贴上来。

## 本段欲回答的核心问题：CLAUDE.md 到底该怎么写？它到底是项目契约还是知识库？什么该放什么不该放？

CLAUDE.md 在我看来更像是你和 Claude 之间的协作契约，不是团队文档，也不是知识库，里面只放那些每次会话都得成立的事。

应该放什么：怎么 build、怎么 test、怎么跑；关键目录结构与模块边界；代码风格和命名约束；那些不明显的环境坑；绝对不能干的事（NEVER 列表）；压缩时必须保留的信息（Compact Instructions）。

不该放什么：大段背景介绍、完整 API 文档、空泛原则、Claude 通过读仓库即可推断的显然信息、大量背景资料和低频任务知识（这些放到 Skills）。

高质量模板我直接用这个：

# Project Contract

## Build And Test

- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`

## Architecture Boundaries

- HTTP handlers live in `src/http/handlers/`
- Domain logic lives in `src/domain/`
- Do not put persistence logic in handlers
- Shared types live in `src/contracts/`

## Coding Conventions

- Prefer pure functions in domain layer
- Do not introduce new global state without explicit justification
- Reuse existing error types from `src/errors/`

## Safety Rails

## NEVER

- Modify `.env`, lockfiles, or CI secrets without explicit approval
- Remove feature flags without searching all call sites
- Commit without running tests

## ALWAYS

- Show diff before committing
- Update CHANGELOG for user-facing changes

## Verification

- Backend changes: `make test` + `make lint`
- API changes: update contract tests under `tests/contracts/`
- UI changes: capture before/after screenshots

## Compact Instructions

Preserve:

1. Architecture decisions (NEVER summarize)
2. Modified files and key changes
3. Current verification status (pass/fail commands)
4. Open risks, TODOs, rollback notes

让 Claude 维护自己的 CLAUDE.md：每次纠正错误后，让它自己更新：“Update your CLAUDE.md so you don’t make that mistake again.” 用久了确实越来越少犯同样的错。

我把这张 CLAUDE.md 写作指南图放上来。

## 本段欲回答的核心问题：在混合语言项目中，Claude Code 还有哪些特别的工程实践值得注意？

春节放假时，我用 Claude Code 做了一个开源 terminal 项目，底层是 Rust + Lua，也带了一些 AI 能力。混合语言加上自定义配置系统，实际折腾下来暴露出不少典型的 agent 协作问题。

环境透明比你想象中重要。我加了个 doctor 命令，把环境状态、依赖和配置情况先统一收上来，输出一份结构化的健康报告。Claude Code 开始做事前先跑一次 doctor，省掉很多“环境没搞清楚就开干”的问题。

混合语言项目的 Hooks 实践我这样配：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "pattern": "*.rs",
        "hooks": [{
          "type": "command",
          "command": "cargo check 2>&1 | head -30",
          "statusMessage": "Checking Rust..."
        }]
      },
      {
        "matcher": "Edit",
        "pattern": "*.lua",
        "hooks": [{
          "type": "command",
          "command": "luajit -b $FILE /dev/null 2>&1 | head -10",
          "statusMessage": "Checking Lua syntax..."
        }]
      }
    ]
  }
}

完整的工程化布局参考我建议这样：

Project/
├── CLAUDE.md
├── .claude/
│   ├── rules/
│   │   ├── core.md
│   │   ├── config.md
│   │   └── release.md
│   ├── skills/
│   │   ├── runtime-diagnosis/
│   │   ├── config-migration/
│   │   ├── release-check/
│   │   └── incident-triage/
│   ├── agents/
│   │   ├── reviewer.md
│   │   └── explorer.md
│   └── settings.json
└── docs/
    └── ai/
        ├── architecture.md
        └── release-runbook.md

全局约束、路径约束、工作流和架构细节完全解耦，执行稳定性显著上升。

## 本段欲回答的核心问题：Claude Code 使用中最常见的反模式有哪些？怎么一眼避开？

我把最容易踩的几个反模式总结成图，大家一看就知道该躲哪些坑。

## 本段欲回答的核心问题：怎么快速检查自己的 Claude Code 配置健康度？有没有一键工具？

基于六层框架，我把检查整理成了一个开源 Skill。装好之后在任意会话里跑 /health，它会自动识别项目复杂度，对 CLAUDE.md、rules、skills、hooks、allowedTools 和实际行为模式各跑一遍检查，输出一份优先级报告。

## 本段欲回答的核心问题：用 Claude Code 大概会经历哪几个阶段？最终目标是什么？

用 Claude Code 大概会经历三个阶段。我把这张阶段图贴上来。

到了第三阶段，关注点会悄悄变掉，从“这个功能怎么用”变成“怎么让 agent 在约束下自己跑起来”。

有一个问题挺值得想的：假如一个任务你说不清楚“什么叫做完”，那大概率也不适合直接扔给 Claude 自主完成。

## 实用摘要 / 操作清单

先写短 CLAUDE.md，只放 build、test、NEVER 列表和 Compact Instructions。
把 Skills 拆成检查清单、工作流、领域专家三种，描述符控制在 10 tokens 以内。
Hooks 只放确定性校验和通知，限制输出长度。
Subagent 必须限工具、限 turns、隔离 worktree。
每次会话前跑 /context，看固定开销占比。
任务切换用 /clear，新阶段用 /compact。
复杂任务先开 Plan Mode，再让另一个 Claude 审计划。
纠正错误后立刻让 Claude 更新 CLAUDE.md。
混合语言项目加 doctor 命令和按文件类型的 Hooks。
每周跑一次 /health 检查配置健康度。

## 一页速览（One-page Summary）

Claude Code = 六层架构（运行循环 + 上下文 + 边界 + Skills + Tools/Hooks + Subagents/验证）

核心公式：短 CLAUDE.md + 分层 rules + 按需 Skills + 强制 Hooks + 隔离 Subagents + 显式 Verification

上下文公式：固定开销 ≤ 20K + Compact Instructions + HANDOFF.md 交接

缓存公式：System + Tools 锁定在前 + 动态在后 + defer_loading

验证公式：Prompt 定义 + Hook 硬校验 + Skill 决策矩阵 + CLAUDE.md Definition of done

用好这套，你会从“AI 帮我写代码”进化到“AI 在我的治理下自主交付可靠工程”。

## FAQ

Claude Code 上下文为什么总是乱？
因为固定开销（MCP 工具定义 + Skills 描述符）吃掉 15-20K，动态部分被中间产物污染。解决办法是分层治理 + Compact Instructions + HANDOFF.md。

Skills 和普通 Prompt 有什么本质区别？
Skills 是按需加载的工作流，描述符常驻但内容渐进披露；普通 Prompt 一次性全塞进去。Skill 必须有完整步骤、停止条件和 disable-model-invocation。

Hooks 适合放哪些场景？
只适合确定性脚本：Edit 后 lint、保护文件阻断、SessionStart 注入环境、任务完成通知。不适合复杂推理。

Plan Mode 什么时候最有用？
复杂重构、迁移、跨模块改动时。先探索只读方案，确认后再执行，能大幅降低错误假设上的浪费。

怎么让 Claude 自己维护 CLAUDE.md？
每次纠正错误后直接说：“Update your CLAUDE.md so you don’t make that mistake again.” 它会把规则补进去，用久了犯错越来越少。

Subagents 的核心价值是什么？
隔离。把大量输出任务（扫库、跑测试）扔给 Subagent，主线程只拿摘要，上下文不被污染。

/context 命令到底看什么？
看 token 占用结构，重点排查 MCP Server 和文件读取占比，帮你发现固定开销杀手。

混合语言项目怎么用 Hooks 最稳？
按文件类型 matcher 分别触发：.rs 跑 cargo check，.lua 跑 luajit 语法检查，输出限 | head -30 避免污染上下文。

这些经验是我半年氪金踩坑换来的。希望你读完就能少走弯路，直接让 Claude Code 变成真正听话的工程伙伴。欢迎把你自己的 Tricks 告诉我，一起把这套系统玩得更稳。

Claude Code架构详解：六层设计让AI代码助手从聊天机器人进阶为可靠工程伙伴