想象一下：你面前是一个完全陌生的代码库——可能是刚入职接手的老系统，可能是内部转岗换了方向，也可能是公司合并后塞过来的项目。几十万行代码，文档要么不存在，要么三年前写的。你在终端里敲了一行 prompt，让 AI 帮你实现第一个需求。
这大概是当下最典型的开局。也是最容易出问题的开局。
问题出在哪？三件事同时撞在一起了。
第一，你对这个系统一无所知——它的代码风格、历史约定、哪里埋过坑，你都不知道。第二，AI 也不了解你的项目——它只会给你通用的写法，而不是这个项目里最安全的写法。第三，你看不出 AI 给的方案靠不靠谱——因为你脑子里没有判断的参照物。
这三个条件凑在一起，结果不是「效率低了一点」。是你越靠 AI 交付得快，你离真正懂这个系统越远。理解力债务从第一天就开始滚雪球了。
这篇文章想讲清楚一件事：在面对不熟悉的代码库时，加速理解和替代理解是两个方向。同一个工具，相反的结果。以及，你应该怎么走第一条路。
我是后端开发。最近一年，AI 编程 agent 已经成了日常开发的主力——Claude Code、Pi、Codex，经常同时开好几个，让它们各干各的。
单个 agent 用得都挺顺手，但 agent 一多，它们之间的配合就开始让人头疼了。
一个需求经常要动好几个仓库。我在某个项目目录（或者几个仓库的共同父目录）里跟 agent 讨论了半小时，方案终于敲定了——然后呢？
cd 到对应仓库、再起一个 agent；沟通的现场和执行的现场是分离的，中间靠人肉搬运上下文。每个终端里的 agent 都是孤岛，不知道其他 agent 的存在，更谈不上协作。
这算是一个不成熟的想法，想先记录下来，接受大家的检验和讨论。
故事要从我的日常说起。
我是一个后端开发，技术栈主要是 Spring Boot。一个典型的需求开发流程大概是这样的：
1 | 理解需求 → 编码 → 自测 → 联调 → 提测 |
每一步都还好——除了自测。
自测意味着：我需要证明这个接口在各种业务状态下行为正确。为了达到这个目标，我通常需要：
这一套走下来，大半天甚至一天就过去了。而且这还没算上中途被拉去开个会、被各种消息打断的碎片化开销。
更糟糕的是：下次需求变了，这套流程从头再来一遍。
上次构造的测试数据，这次用不了——因为业务状态变化了，字段可能也调整了。上次踩过的坑、验证过的边界条件，这次全靠人脑回忆。上次写的自测文档，能找到就算运气好，找到了也不一定还能用——因为接口都改过了。
仔细想想，这一轮一轮的自测里，真正能被沉淀下来的东西几乎没有。数据被丢弃了，操作经验留在了脑子里，测试文档随着需求流转消失在流程的某个环节里。每一次自测，都像第一次一样从零开始。
能不能每次自测之后，留下的不只是一份"已通过"的结论，而是一些可以积累的东西？比如：
有时候我在想：这一步，有没有可能不再这么累？
在之前的《知识沉淀的第一步——统一语言与 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 确实走了一遍——但它走全了吗？
上一篇文章的结尾，我提了一个问题：Execution 之后，代码自动进入了 Knowledge 空间，但其他几层知识不会自动更新。下一次任务还是会从同样不完整的 Context 出发
那么需要更新的到底是什么？怎么更新？
这不是一个理论问题。如果你读完前六篇，觉得「把知识外化」听起来有道理，但不知道具体怎么动手——这篇文章就是给你的
很长一段时间，我对「知识沉淀」这四个字也十分抗拒。它听起来像某种咨询公司术语，暗示着一套繁重的文档体系。直到看到 Matt Pocock 的 skills 仓库中的实践，我才意识到这件事可以做到极简
两样东西就够了：统一语言和不可逆决策
Specification 写好了。AI 知道改哪里、怎么改、不能动什么、需要测什么。接下来就是把这份精确的描述，变成可运行的代码
这就是 Execution。在整个链路中：
1 | Knowledge → Context → Decision → Specification → Execution |
它是最后一环——前面五环的全部投入，在这一环兑现
但 Execution 有一个独特之处：它是整个链路中 AI 最擅长的一环，却也是整个链路中最依赖上游质量的一环
如果 Specification 准确完整，Execution 是高效的、机械的、几乎不需要人工干预的。如果 Specification 有遗漏或歧义，AI 会忠实地把问题变成 bug。如果 Specification 约束过多，AI 被捆住手脚，发挥不出它在实现细节上的优势
Execution 的上限，是 Specification 的质量。而 Specification 的上限，是 Decision 的质量。以此类推。整个链路是一条质量传递链，Execution 是最后一道
但 Execution 不只是被动的接收者。它有两个重要的反馈功能，常常被忽略