个人网页

这算是一个不成熟的想法，想先记录下来，接受大家的检验和讨论。

故事要从我的日常说起。

自测的一天

我是一个后端开发，技术栈主要是 Spring Boot。一个典型的需求开发流程大概是这样的：

1

理解需求 → 编码 → 自测 → 联调 → 提测

每一步都还好——除了自测。

自测意味着：我需要证明这个接口在各种业务状态下行为正确。为了达到这个目标，我通常需要：

1. 准备数据：手动往数据库里插各种状态的用户、订单、账户
2. 部署服务：把改动部署到测试环境（或者本地跑起来）
3. 构造请求：部署后在页面上一个场景一个场景地操作，模拟各种用户行为
4. 验证结果：检查返回值、检查数据库落库、检查下游是否被正确调用
5. 发现问题 → 修 → 重新部署 → 重新造数 → 重新验证
6. 协调上下游：有些数据自己造不了，得找对应的同学帮忙——或者自己搭 Mock 服务
7. 写自测文档：如果团队有这个要求——把测试场景、测试数据、测试结果整理成文档，附到需求上

这一套走下来，大半天甚至一天就过去了。而且这还没算上中途被拉去开个会、被各种消息打断的碎片化开销。

更糟糕的是：下次需求变了，这套流程从头再来一遍。

上次构造的测试数据，这次用不了——因为业务状态变化了，字段可能也调整了。上次踩过的坑、验证过的边界条件，这次全靠人脑回忆。上次写的自测文档，能找到就算运气好，找到了也不一定还能用——因为接口都改过了。

仔细想想，这一轮一轮的自测里，真正能被沉淀下来的东西几乎没有。数据被丢弃了，操作经验留在了脑子里，测试文档随着需求流转消失在流程的某个环节里。每一次自测，都像第一次一样从零开始。

能不能每次自测之后，留下的不只是一份"已通过"的结论，而是一些可以积累的东西？比如：

• 这次用过的测试数据，下次稍微改改就能复用？
• 这次验证过的场景模板，下次同类需求可以直接套用？
• 这次的验证逻辑，下次变成自动化的脚本，不需要再手动点一遍？

有时候我在想：这一步，有没有可能不再这么累？

在之前的《知识沉淀的第一步——统一语言与 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、模型调用。但模型内部到底在做什么，一直处于一个「大概知道、细节模糊」的状态。

比如这些现象，我遇到过但解释不清楚：

• 为什么长上下文贵？
• 为什么 prompt 越长响应越慢？
• 为什么 RAG 需要控制 context？
• 为什么流式输出不是「假装」的？

这些问题都指向同一件事：推理阶段。 理解推理不需要先学会训练，也不需要成为算法工程师。只要从「一段文字进入模型到输出一个 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
2

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
2

Knowledge → Context → Decision → Specification → Execution
   收集        筛选        判断        翻译        执行

Specification 就是这个翻译层。它回答的问题是：如何把工程决策，变成 AI 可以精确执行、不会误解的描述？

经过了上一篇关于 Context 的讨论，一个自然的问题是：上下文构建完成之后呢？

上一篇文章的结论是，Context 构建永远不可能完美——五重约束互相冲突，完备性和最小性无法兼得。这意味着一个让人不太舒服的现实：工程决策，永远是在信息不完整的情况下做的

这听起来是个缺陷。但这正是「工程判断力」之所以存在的原因。如果每次决策之前信息都是完备的，那就不需要判断力了——按规则执行就行

在整个 AI Native 软件开发的链路中：

1

Knowledge → Context → Decision → Specification → Execution

Decision 是第三环。它是整个链路的价值兑现点——前面收集 Knowledge、构建 Context，全部是为了支撑这一环。如果 Decision 的判断质量低，上游的一切投入都白费了

更重要的是，Decision 可能是整个链路中最需要人的一环