defer_loading：工具的延迟加载

始终常驻 → CLAUDE.md：项目契约 / 构建命令 / 禁止事项 按路径加载 → rules：语言 / 目录 / 文件类型特定规则 按需加载 → Skills：工作流 / 领域知识 隔离加载 → Subagents：大量探索 / 并行研究 不进上下文 → Hooks：确定性脚本 / 审计 / 阻断

以下是按照你提供的模板对这篇文章的完整解读：

📌 元数据概览

标题： 《你不知道的 Claude Code：架构、治理与工程实践》——聚焦于如何从工程视角深度使用和治理 Claude Code 这一 AI 编程 Agent 工具。

作者： Tw93，独立开发者，维护个人技术博客与 Weekly 周刊，有开源 terminal 项目 Kaku（Rust + Lua）等实际工程产出，具备较深的前沿 AI 工具工程实践经验。

链接： tw93.fun

标签： #ClaudeCode #AI编程Agent #上下文工程 #PromptCaching #MCP #Skills #Hooks #Subagents #CLAUDE.md #工程实践

✨ 核心观点与亮点

主张： Claude Code 的使用瓶颈不在于模型能力，而在于系统设计层面的治理缺失。作者将其拆解为六层架构（CLAUDE.md / Tools / Skills / Hooks / Subagents / Verifiers），并主张每一层都需要精心设计，任何一层的失衡都会导致整个协作系统崩坏。

亮点： - 对 200K 上下文的真实成本进行了精确拆解，揭示了 MCP 工具定义是最大的"隐形上下文杀手"（5 个 Server 即可消耗 12.5% 的上下文）； - 提出了用 HANDOFF.md 跨会话传递进度的实用模式，解决了压缩算法丢失架构决策的痛点； - 揭示了 Prompt Caching 的前缀匹配机制及其对架构设计的深层影响，包括"会话中途切换模型反而更贵"这一反直觉结论； - 提出"让 AI 审 AI"的 Plan Mode 进阶玩法（一个 Claude 写计划，一个 Codex 以高级工程师身份审计）； - 分享了 Claude Code 内部工具演进的真实案例，包括 AskUserQuestion 独立工具的设计哲学。

🔍 逐层深入理解

开始： 文章以作者半年双账号、每月 40 美元的深度使用经历为引子，指出大多数人把 Claude Code 当 ChatBot 用所遇到的典型困境——上下文越来越乱、工具堆越多效果越差、规则越长越不遵守。作者的核心判断是：这不是 Prompt 问题，而是系统设计问题。

发展： 文章以六层架构为骨架，逐层展开工程实践。上下文工程部分详细拆解了 200K 窗口的真实占用结构，并给出分层加载策略（常驻 / 按路径 / 按需 / 隔离 / 不进上下文）。Skills 部分区分了检查清单型、工作流型、领域专家型三种设计模式，并强调描述符的精简对上下文节省的重要性。Hooks 部分说明了强制执行逻辑与模型自由判断之间的边界。Subagents 部分强调其核心价值在于"隔离"而非"并行"。Prompt Caching 部分则深入剖析了 Claude Code 整个架构围绕缓存前缀匹配而构建的设计逻辑，包括 defer_loading、Compaction 的实现原理等。

结论： 作者总结了用户使用 Claude Code 的三个阶段（工具使用者 → 流程优化者 → 系统设计者），并提出一个核心判断标准：如果你说不清楚"什么叫做完"，这个任务就不适合直接交给 Claude 自主完成。验证标准是 Agent 能否可靠运作的前提，而非事后补充。

📚 关键术语/概念

CLAUDE.md： 项目级持久契约文件，每次会话都必须成立的命令、边界与禁止项。应保持短、硬、可执行，避免写成团队知识库。

MCP（Model Context Protocol）： 外部能力接入协议，让 Claude 访问 GitHub、Sentry、数据库等外部系统。每个 Server 的工具定义会占用大量固定上下文，是最大的隐形成本来源。

Skills： 按需加载的知识与工作流，描述符常驻上下文，完整内容按需拉取。核心设计原则是"progressive disclosure"（渐进式披露）。

Hooks： 在 Claude 执行操作的生命周期节点前后强制插入确定性逻辑的拦截层，不依赖模型判断，适合格式化、保护文件、推送通知等场景。

Subagents： 从主对话派出的独立 Claude 实例，有独立上下文窗口和受限工具集，核心价值是隔离而非并行。

Prompt Caching： 按前缀匹配工作的缓存机制，静态内容（系统指令、工具定义）应放在 Prompt 前端以最大化命中率。破坏缓存的常见操作包括在系统 Prompt 中嵌入时间戳、中途增删工具等。

Verifiers： 验证闭环机制，包括命令退出码、lint、测试、截图对比、生产日志等，是 Agent 工程化可信的基础。

HANDOFF.md： 在开新会话前由 Claude 生成的进度交接文件，记录当前进展、尝试路径、成功/失败结论及下一步方向，用于替代压缩算法的摘要质量依赖。

RTK（Rust Token Killer）： 一个通过 Hook 自动过滤命令输出、只保留决策所需核心信息的开源工具，系统化解决 Tool Output 噪声问题。

🚫 无关信息过滤

文章末尾的评论区互动（如"太牛了""收获颇丰"等读者留言）以及"请 Tw93 喝冰可乐"的打赏入口，与文章核心工程内容无关，可略过。另外，文末附带的另一篇文章预告《连龙虾都不会装的人，怎么会用龙虾呢？》属于站内推荐，不属于本文内容范畴。

🌟 文章摘要

本文是一篇面向工程师的 Claude Code 深度实践指南。作者从六层架构视角（CLAUDE.md、Tools/MCP、Skills、Hooks、Subagents、Verifiers）出发，系统阐述了如何治理上下文污染、精细设计 Skills 与工具、利用 Hooks 强制执行确定性逻辑、通过 Subagents 隔离复杂任务，以及围绕 Prompt Caching 机制进行架构设计。文章的核心论点是：Claude Code 的效果瓶颈不在模型，而在系统治理——只有把六层结构都设计到位，Agent 才能在约束下稳定自主运作。

💡 金句提取

"卡住的地方几乎从来不是模型不够聪明，更多时候是给了它错误的上下文，或者写出来了但根本没法判断对不对，也没法撤回。"

"假如一个任务你都说不清楚「Claude 怎么才算做对了」，那它大概率也不适合直接丢给 Claude 自动完成。"

"Cache Rules Everything Around Me——对 agent 同样如此，Claude Code 的整个架构都是围绕 Prompt 缓存构建的。"

"当初加这个工具是因为模型不够强，模型变强之后它反而变成了枷锁。值得过段时间回来检查一下，当初加的限制还成不成立。"

🔄 总结归纳

这篇文章的价值在于它把 Claude Code 从"一个好用的 AI 工具"重新定位为"一套需要工程化治理的 Agent 系统"。作者用半年真实踩坑经验，提炼出了一套从上下文管理、Skills 设计、Hooks 拦截到 Prompt Caching 架构的完整方法论。对于已经在使用 Claude Code 但感到"越用越乱"的工程师来说，这篇文章提供了一个清晰的诊断框架和可落地的改进路径，是目前中文社区中难得的一篇兼具深度与实操性的工程实践总结。

❓ 引发思考的问题

问题一： 文章提出"验证标准是 Agent 能否可靠运作的前提"，但在实际工程中，很多任务的验收标准本身就是模糊的（如"优化代码可读性"）。在这类场景下，如何设计出足够可信的 Verifier，而不是让验证本身也依赖模型的主观判断？

问题二： 随着模型能力的持续增强，文章中提到的很多约束层（如 TodoWrite 工具最终成为枷锁）可能会逐渐失效。那么，如何建立一套动态的"配置健康检查"机制，让 CLAUDE.md 和 Skills 随着模型能力的演进而持续迭代，而不是积累成越来越厚的历史负担？

C++想要真正意义上实现多态，还得给方法加上virtual关键字才行

当需要用到某年某周的场景，必须用周基年+周