这是一个很常见的处境：项目跑起来了，用户在用，Star 也在涨——但有人问你「这里为什么这么设计」，你答不上来。
代码在跑，理解却断线了。这篇讲怎么把它接回来。
一、这不是你一个人的问题
用 AI 编程工具写代码，流程通常是这样的：
- 你描述想要什么
- AI 写出来
- 能跑 → 继续下一步
- 不能跑 → 把报错丢回去，AI 改
- 重复直到跑通
注意第 3 步到第 5 步：整个循环里没有"理解"这个环节。
它高效得可怕——你可以在完全不理解 useEffect 依赖数组的情况下，做出一个交互流畅的网站。问题只是：这条捷径省下的理解，会在别人问你"为什么"的时候一次性还回来。
最典型的就是面试。
二、为什么面试一定会问深度
面试官不会满足于「我用了 SQLite 存任务状态」。他会接着问：
「为什么用 SQLite 不用 Postgres？」
这时候如果答案是「AI 选的」，面试就结束了。
他想知道的不是数据库知识，而是：这个决策是你做的，还是工具替你做的。
这两者在面试里的分量完全不同——前者是工程师，后者是操作员。
三、好消息：你要补的不是「计算机科学」
一听到「基础薄弱」，很多人的第一反应是去学操作系统、编译原理、计算机网络。
别。那是无底洞，而且会在第三周让你崩溃——因为看不到尽头。
真实情况是：面试官问你项目，翻来覆去就是那些问题。它是个有限集合。
我把自己两个项目过了一遍，真正会被问到、且答不上来会崩的，只有 12 个点。
四、12 个必答点
按项目分成两组。
组一：LLM Agent 的可靠性（7 个）
| 编号 | 主题 | 它回答的问题 |
|---|---|---|
| 一 | 结构化输出 | 为什么 LLM 返回的 JSON 不能信 |
| 二 | Durable Run Store | 任务跑一半崩了怎么办 |
| 三 | Outbox | 改状态和发通知怎么才能不漏 |
| 四 | 租约与心跳 | 任务为什么不会永远卡死 |
| 五 | 评估框架 | 改了 prompt，怎么知道变好了 |
| 六 | HITL | Agent 什么时候该问而不是编 |
| 七 | 证据与透明度 | 结论怎么指得回原文 |
组二：开源项目的工程决策（5 个）
| 编号 | 主题 | 它回答的问题 |
|---|---|---|
| 八 | MCP | 怎么让 AI 直接调用你的能力 |
| 九 | 混合检索与 RRF | 为什么两路检索结果不能相加 |
| 十 | 一个中文检索缺陷 | 怎么定位并证明一个功能性失效 |
| 十一 | Embedding 缓存 | 为什么不每次重算 |
| 十二 | 生产部署 | 为什么不用托管平台 |
12 个，不是 1200 个。每个点花 2 到 3 小时，一天投入 3 到 4 小时，10 天能过完。
五、每个点用固定的四个问题过
这是我用下来最有效的方法。对每个点，逼自己回答：
① 它解决什么问题？ ← 先讲失败场景，不许用术语
② 不用它会怎样？ ← 举一个具体的、能想象出来的坏结果
③ 我的代码怎么做的？ ← 打开自己的文件，对着看
④ 怎么证明有效？ ← 测试 / 指标 / 真实数据检验标准很简单：这四问答得出来，你就能扛住面试；答不出来，就是还没读懂，回去读。
特别强调第 ① 条。如果你不能用"失败场景"解释一个机制，你就还没懂它。 「outbox 保证了原子性」是背的；「先改库再发通知，中间崩了用户就永远收不到结果」才是懂的。
六、为什么要回头读自己的代码
你可能会想：直接去学分布式系统不就好了？
差别在于动机。
学课本的时候，你会在第三章卡住，然后问自己：「我为什么要学 outbox？」 而你自己的项目里，有一段真实的 outbox 代码正在跑——你知道不用它会有什么后果，因为那个 bug 可能真的发生过。
从自己的代码学原理，比从课本学快得多，也忘不掉。而且读完之后，你收获的不只是「能应付面试」——你真的拥有了这个项目。
七、最后：诚实是底线
补课的目的是真的搞懂，不是背答案。
面试里说「这块我没深入」是可以接受的——大多数面试官见过太多不懂装懂的人，坦诚反而加印象分。
说「我懂」，然后被追问两句就崩——不可接受，而且比一开始就承认更伤。
所以：把「能讲」的边界画清楚，然后在边界内讲透。宁少勿虚。
这一篇是系列的开篇。后面 12 篇，每个点一篇，都按上面那四个问题的结构写。