个人网页

最近几个月，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 可能是整个链路中最需要人的一环

上一篇文章把软件开发中的知识拆成了六个层次：代码、业务逻辑、架构设计、历史决策、需求、基础知识

拆完之后，一个很自然的问题就摆在了面前：六层知识浩瀚如海，但一次具体的开发任务——比如「在退款流程里加一个超 30 天拒退的校验」——只需要其中的极少一部分。剩下的全是噪音，不仅没用，还会干扰判断

怎么从知识的海洋中，捞出刚好需要的那一滴？

这就是 Context 要解决的问题。在整个 AI Native 软件开发的链路中：

1

Knowledge → Context → Decision → Specification → Execution

Context 是第二环，承接 Knowledge，支撑 Decision。但我越来越觉得，它可能是整个链路中最难的一环

不是因为其他环节简单，而是因为这一环要解决的问题，本质上没有一个完美解

上一篇文章讨论了一个观点：软件开发真正管理的对象，也许从来都不是代码，而是知识。AI 的出现没有让知识变重要——它只是让我们不得不正视这个一直存在的事实

但文章写完之后，一个更基础的问题一直在我脑子里转：

当我们说「知识」的时候，到底在指什么？

代码算知识吗？业务逻辑呢？架构设计呢？那些只存在于老员工脑子里的历史决策呢？这些看起来完全不相关的东西，为什么都叫「知识」？

这篇文章把这个问题拆开来看

最近一段时间，一个感受变得非常清晰：AI 写代码的速度，已经远超过去了

一个 CRUD 接口、一个 Controller、一个 SQL，甚至一整个功能模块，AI 都能够很快完成

但是，在真正的业务项目里，我花费时间最多的，却越来越不是写代码

而是：

• 不知道应该改哪里；
• 不知道为什么这里要这样设计；
• 不知道有没有类似实现；
• 不知道修改之后会影响哪些地方；
• 不知道这个看起来无关的模块为什么会一起坏掉。

举一个很常见的例子，一个需求只是：修改退款流程中的某一个逻辑。看起来只是改一个 Service，结果上线测试之后，却发现：

• 积分没有发放；
• 优惠券状态异常；
• 消息通知没有发送。

最后检查代码才发现：退款流程后面还有

• MQ
• Event
• 定时任务
• 另外几个系统的监听逻辑

这些依赖关系，并没有直接写在你修改的代码里

困难的地方，从来都不是：怎么写代码，而是：如何理解这个系统