破山中贼易，破心中贼难。

从设计者角度理解源码·方法篇：机制、原型与提问协议 这是《从设计者角度理解源码》系列的一篇"元文章"：它不讲某个模块怎么实现，只讲读源码这件事本身该怎么做。 案例全部来自同系列的 Hook 设计的两种答案——那篇给的是"填好的表"，本篇给的是"怎么用这张表"。 引言 先讲一个很常见的困境。 你遇到了

Hook 设计的两种答案：跨进程与同栈 前置阅读：Claude Code 的 Hook 体系设计（讲"这套系统内部怎么运转"）、Hook 设计机制（讲"契约为什么是双保险"）。 本篇不再重复那两篇的内容，只回答一个新问题：同样是"在生命周期节点插入第三方逻辑"，为什么 Claude Code 和 D

从设计者的角度理解源码–上下文工程：系统的话，为什么要借用户的嘴说？ 引言 本篇是《从设计者的角度理解源码》系列里聚焦上下文工程的一篇。 我原以为「上下文工程」是个玄学词——不就是「把该给模型看的东西塞进 prompt」吗？直到我盯着 Claude Code 的源码看久了，才意识到它其实是一套有明确

从设计者的角度理解源码 -- Claude Code 的 Hook 体系设计引言本篇，作为《从设计者的角度理解源码》系列的第六篇，试图回答一个比「工具怎么统一」更棘手的问题：Claude Code 怎么敢让用户自己写的代码（Hook），插进它的核心执行流程，参与「要不要执行这个危险操作」的决策？上一

从设计者的角度理解源码 -- Claude Code 的工具体系设计引言本篇，作为《从设计者的角度理解源码》系列的第五篇，试图回答一个看起来不该成为问题的问题：Claude Code 怎么用「一个接口」统一调度几十种语义完全不同的工具？读文件的 Read、跑命令的 Bash、改代码的 Edit、搜代

从设计者的角度理解源码 -- Claude Code 的权限系统设计引言本篇，作为《从设计者的角度理解源码》系列的第四篇，试图回答一个安全领域最朴素、也最难的问题：Claude Code 怎么敢让一个 LLM 直接在你电脑上执行 rm -rf？这个问题的难度在于：LLM 的能力和可信度是错配的。它的

从设计者的角度理解源码 -- ClaudeCode的消息机制设计引言本篇，作为《从设计者的角度理解源码》系列的第三篇，试图回答一个看似简单的问题：Claude Code 的消息系统为什么长成现在这个样子？如果你翻过源码，你会发现 messages.ts 有 3000+ 行，里面塞满了 isMeta、

从设计者的角度理解源码–记忆压缩的七种刀法引言本篇是《从设计者的角度理解源码》系列里聚焦上下文与记忆的一篇。聊一个每个做 LLM 应用的人都会撞上的问题：对话跑长了，token 不够用了怎么办？大部分项目的答案很简单——快爆了就让模型自己总结一下，用摘要替换历史。这当然能用，但总觉得糙。Claude

父子 Agent 的三条通信路径：为什么不是一条？拆解 Claude Code 父子 Agent 通信机制的源码设计，以及我手写复现时的踩坑。0. 一个反直觉的事实如果你去看 Claude Code 的源码，会发现一个反直觉的现象：父 Agent 和子 Agent 之间的通信，不是一条路径，而是三条

你又往前迈了一大步！而且你敏锐地发现了一件很多人会混淆的事：你说"如何设计质检指标"，又说"如何设计评估指标"——这其实是两种完全不同的指标，处在流程的不同位置。 先把这两者分清楚，是回答你问题的前提。 第一件事：你混用了两个概念，先分清 质检指标（数据侧） 评估指标（模型侧） 衡量的对象 数据好不