在之前的《知识沉淀的第一步——统一语言与 ADR》里，我讲了项目级的知识沉淀——统一语言（CONTEXT.md）和不可逆决策（ADR），两样东西就够。但沉淀的起点是「有知识」，项目里可以靠代码和讨论沉淀，可那些还没变成项目的知识呢？那些攒在收藏夹里、散落在微信文件传输助手和随手截图里的东西？
很长一段时间里，我对个人知识库的态度是「不折腾」。Notion 数据库建过，三个月后不再打开；Obsidian 仓库建过，里面躺着几篇孤零零的笔记；RAG 系统试过——上传一堆文档，然后呢？每次提问它都重新检索、重新拼装，好像我从来没读过它们一样——没有积累。
后来我发现了 karpathy 的 llm-wiki。它不是工具、不是框架、甚至不是教程，就是一个 markdown 文件——但它描述的模式，正是我需要的：
知识库不该由人维护，也不该由 RAG 现查现拼——应该让 LLM 增量维护一份持续编译、互相引用的 wiki。
这篇文章记录我照这个思路落地一个知识库的过程，包括全部结构和关键文件，以及三天里总结出的四条实战经验。如果你也想构建一个自己的知识库，这篇文章会给你一条已经跑通的路。
最近读到 Sean Goedecke 的一篇文章——In defense of not understanding your codebase（《为「不理解自己的代码库」辩护》）。文章的核心观点和很多程序员的直觉相反：
在大型软件系统中，「完全理解整个代码库」并不是优秀工程师的必要条件，甚至是不现实的目标。优秀工程师应该学会在「不完全理解」的情况下有效工作。
这个观点，和我过去几个月一直在写的 AI Native 软件开发系列，在底层逻辑上有很深的共鸣。这篇文章试着把两边的思考放在一起，做一个梳理。
最近几个月，AI 编码工具已经成了日常开发的一部分。Claude Code、Cursor、Copilot——它们在代码生成和重构上的表现越来越好。
但用得越久，越觉得有一个断层：AI 在终端里帮我写代码，但我自己却要频繁切出终端去做别的事。查数据库切到 DataGrip，看日志 SSH 上服务器，构造测试数据打开另一个脚本。AI 离我的实际工作环境，其实还很远。
这个问题让我开始想一件事：能不能让 AI 编码工具直接触达数据库、服务器、日志——把它从一个「代码助手」变成一个真正的「研发工作台」？
作为应用层开发者，这些概念我们每天都在用——Agent、RAG、Context Engineering、模型调用。但模型内部到底在做什么，一直处于一个「大概知道、细节模糊」的状态。
比如这些现象，我遇到过但解释不清楚：
这些问题都指向同一件事：推理阶段。 理解推理不需要先学会训练，也不需要成为算法工程师。只要从「一段文字进入模型到输出一个 token」这个完整链路走一遍，上面那些问题自然就有答案了。
这篇文章就是我走完这条路之后的笔记。它试图用后端开发能理解的方式来翻译 Transformer 内部的机制。
上一篇文章讨论了知识沉淀的第一步——用 CONTEXT.md 统一术语，用 ADR 记录不可逆决策。这两样东西构成了 AI 在项目中的知识底座
文章里提到一个关键动作：grilling。你运行 /grill-with-docs，AI 一次一个问题地追问你，同时在代码里搜索它能找到的事实。对话结束，术语更新了，决策记录了，共享理解也形成了
当时我写了一句话：「一次 grilling 跑完，AI 也已经在代码中走了一遍它能找到的相关路径——这个过程本身就是 Context 构建」
这句话对了一半。AI 确实走了一遍——但它走全了吗？
Specification 写好了。AI 知道改哪里、怎么改、不能动什么、需要测什么。接下来就是把这份精确的描述，变成可运行的代码
这就是 Execution。在整个链路中：
1 | Knowledge → Context → Decision → Specification → Execution |
它是最后一环——前面五环的全部投入，在这一环兑现
但 Execution 有一个独特之处：它是整个链路中 AI 最擅长的一环，却也是整个链路中最依赖上游质量的一环
如果 Specification 准确完整，Execution 是高效的、机械的、几乎不需要人工干预的。如果 Specification 有遗漏或歧义，AI 会忠实地把问题变成 bug。如果 Specification 约束过多，AI 被捆住手脚，发挥不出它在实现细节上的优势
Execution 的上限，是 Specification 的质量。而 Specification 的上限，是 Decision 的质量。以此类推。整个链路是一条质量传递链，Execution 是最后一道
但 Execution 不只是被动的接收者。它有两个重要的反馈功能，常常被忽略
上一篇文章讨论了 Decision——在信息不完整的情况下，如何做出最好的工程决策。
但决策做出来之后，问题还没完。决策是在人脑子里完成的——带着判断、权衡、以及对系统上下文的理解。而下一环 Execution，是由 AI 来执行的——AI 需要精确、完整、无歧义的输入
人脑子里的决策，和 AI 需要的输入，是两种不同的东西。二者之间存在一个翻译鸿沟
在整个链路中：
1 | Knowledge → Context → Decision → Specification → Execution |
Specification 就是这个翻译层。它回答的问题是：如何把工程决策，变成 AI 可以精确执行、不会误解的描述？
经过了上一篇关于 Context 的讨论，一个自然的问题是：上下文构建完成之后呢？
上一篇文章的结论是，Context 构建永远不可能完美——五重约束互相冲突，完备性和最小性无法兼得。这意味着一个让人不太舒服的现实：工程决策，永远是在信息不完整的情况下做的
这听起来是个缺陷。但这正是「工程判断力」之所以存在的原因。如果每次决策之前信息都是完备的，那就不需要判断力了——按规则执行就行
在整个 AI Native 软件开发的链路中：
1 | Knowledge → Context → Decision → Specification → Execution |
Decision 是第三环。它是整个链路的价值兑现点——前面收集 Knowledge、构建 Context，全部是为了支撑这一环。如果 Decision 的判断质量低，上游的一切投入都白费了
更重要的是，Decision 可能是整个链路中最需要人的一环
上一篇文章把软件开发中的知识拆成了六个层次：代码、业务逻辑、架构设计、历史决策、需求、基础知识
拆完之后，一个很自然的问题就摆在了面前：六层知识浩瀚如海，但一次具体的开发任务——比如「在退款流程里加一个超 30 天拒退的校验」——只需要其中的极少一部分。剩下的全是噪音，不仅没用，还会干扰判断
怎么从知识的海洋中，捞出刚好需要的那一滴？
这就是 Context 要解决的问题。在整个 AI Native 软件开发的链路中：
1 | Knowledge → Context → Decision → Specification → Execution |
Context 是第二环，承接 Knowledge，支撑 Decision。但我越来越觉得，它可能是整个链路中最难的一环
不是因为其他环节简单，而是因为这一环要解决的问题，本质上没有一个完美解