一个让我决定开始写这本书的下午

2026 年 4 月底,GPT-5.5 刚发布两天。我开着 Cursor 写《AI Agent 评测工程实战》的第 13 章 LLM-as-Judge,想换 GPT-5.5 跑一组校准数据。问题来了:这玩意儿只对 ChatGPT 订阅开放,API key 拿不到。我手上有 Claude Max、有 ChatGPT Plus、有谷歌一杯免费的 Gemini 额度,全是 OAuth 凭证,没有一个能直接喂给我的评测脚本。

到 GitHub 搜了一下,发现这事社区已经吵翻天了。Simon Willison 在 GPT-5.5 发布几小时内就反编译了 Codex CLI 的 auth flow,做了个能跑的 PoC。一周内冒出十几个 “把 Claude Code / Codex CLI 包成 OpenAI 接口” 的项目。我点开 star 数最高的那个—— router-for-me/CLIProxyAPI,35K star,637 个 release,当天还在发新版。

打开它的 internal/ 目录,坐在那里读了一下午。

读完后我做了两件事。第一,把它跑起来,接到 Cursor 和我那本评测书的脚本里,问题解决,没多花一分钱。第二,我意识到一件事:这个项目里有 3-4 个设计点,值得拎出来给人讲清楚——四协议互译怎么映射 OpenAI 的 tool_calls 和 Anthropic 的 tool_use、OAuth Manager 怎么在 5 种 CLI 凭证之间抽象出统一接口、配置热更新用 fsnotify + SHA256 hash diff 怎么做防抖。这几块东西,README 不讲,DeepWiki 也只是摘要式罗列,真正能让人学到东西的部分,需要一个有判断力的工程师坐下来,把代码读完,把取舍讲透。

那天晚上我开了这个仓库。

这本书在做一件什么事

工程师吸收知识最高效的两种方式我反复试过:亲手造一遍,或者读懂别人造好的。前者门槛高,周期至少几周;后者门槛低,周末就能做,但绝大多数源码精读文章止步于”它做了什么”,不回答另外两个更重要的问题:

• 它为什么这么做——作者面对几种方案,凭什么选了这个
• 换我来做会怎么改——读完源码后,你有没有自己的判断

我读了一百多个开源项目的源码,99% 的精读文章在第二个问题上是缺位的。它们把作者捧得很高,把项目讲得很完美,读完读者只剩”哇好厉害”四个字,没有任何可以带走的东西。

这本书想把后两个问题做到位。每一章挑一个值得读、足够成熟、设计上有取舍可讲的开源仓库,带读者走完三件事:

1. 用一张图把这个项目的核心抽象讲清楚
2. 挑 3-5 个最有意思的取舍,讲清楚作者为什么选 A 没选 B
3. 诚实评价它的局限,你如果要重做会怎么改

不做教程式 walk-through,不做逐文件翻译,不当作者的形象代言人。每一篇精读末尾都有一节”诚实评价 + 局限”,写满 800-1500 字——找不到这么多局限,就不是合格的精读,要么是我没读懂,要么是这个项目不够格被选。

这本书写给谁

适合的读者:

• 有 2 年以上工程经验,想从”会用 API”进阶到”会造 API”
• 对 AI Agent / LLM Infra / 开发者工具这些领域的开源项目有兴趣
• 习惯先读源码再相信文档——认同 “看 README 不如看 internal/”
• 不喜欢被作者用市场话术哄,愿意花时间看技术品味

不适合的读者:

• 刚学编程的新手——每一章默认你能读懂目标项目的语言(Go / Python / TS 都会出现)
• 只想找现成方案抄的人——本书不提供”复制粘贴可用”的最小实现
• 想要”今天读完明天就涨薪”的人——精读是慢功夫,半年读 5 章比一周读 50 篇博客有用得多

这本书覆盖什么 / 不覆盖什么

覆盖:开源项目的架构设计、关键模块拆解、设计取舍、工程品味。

不覆盖:

• 项目的入门教程——README 已经写了,我没必要重复
• 项目的部署运维细节——这是用户文档的事
• 当章项目的同领域全景综述——精读不是横评,每篇只盯一个项目

怎么读这本书

每一篇精读都是独立的,可以从任何一章开始。三条推荐路线:

快速浏览路线(1-2 小时/篇):只读”全景架构 + 关键设计取舍 + 诚实评价”三节,快速建立对这个项目的判断。适合”我在选型,想看看这个项目值不值得用”的读者。

深入精读路线(半天/篇):全文读,对照源码同步看。打开目标项目的对应 tag 检出到本地,边读文章边在编辑器里跳转源码。适合”我想搞懂这个项目背后的工程思路”的读者。

对比建造路线(一周/篇):读完后强迫自己用熟悉的语言重新实现一遍核心模块。比如 CLIProxyAPI 是 Go 写的,你可以用 TS / Rust / Python 重写一个最小版,只实现核心两层(协议翻译 + Auth)。这条路线学到的东西是前两条的 5 倍,但代价也是 5 倍。

几条我对自己的约束

写这本书,有几件事我提前对自己讲清楚:

• 不夸大。star 高不代表设计好,star 低不代表不值得读。判断一个项目是否值得精读,只看”设计上有没有取舍可讲”
• 不绕开局限。每一篇必须写局限,而且写满。这不是为了显得客观,是因为技术债和设计缺陷往往比成功之处更有教育意义
• 不引 main 分支。每篇开头声明”本文基于 vX.Y.Z 写就”,所有源码引用锁定到具体 tag——精读会过时,但锚点不能漂
• 不抄 DeepWiki。读源码读到哪里讲到哪里,DeepWiki 的现成摘要只用来交叉验证,不作为内容来源

配套资源

• GitHub 仓库:diguike/book-source-reading
• 每一篇精读对应的目标项目会列出 git clone 命令和推荐 tag,读者可以拉到本地 _references/ 下边读边看
• 勘误 / 候选项目提名:开 issue 讨论

致谢

感谢每一个被精读对象的作者。读你们的代码我学到了很多——本书不是评判,是学习笔记的公开版本。如果哪一篇我读错了、误解了你的设计意图,欢迎开 issue 告诉我,我会更正并署名感谢。

——diguike,2026 年 5 月,杭州