个人网页

想象一下：你面前是一个完全陌生的代码库——可能是刚入职接手的老系统，可能是内部转岗换了方向，也可能是公司合并后塞过来的项目。几十万行代码，文档要么不存在，要么三年前写的。你在终端里敲了一行 prompt，让 AI 帮你实现第一个需求。 这大概是当下最典型的开局。也是最容易出问题的开局。 问题出在哪？三件事同时撞在一起了。 第一，你对这个系统一无所知——它的代码风格、历史约定、哪里埋过坑，你都不知道。第二，AI 也不了解你的项目——它只会给你通用的写法，而不是这个项目里最安全的写法。第三，你看不出 AI 给的方案靠不靠谱——因为你脑子里没有判断的参照物。 这三个条件凑在一起，结果不是「效率低了一点」。是你越靠 AI 交付得快，你离真正懂这个系统越远。理解力债务从第一天就开始滚雪球了。 这篇文章想讲清楚一件事：在面对不熟悉的代码库时，加速理解和替代理解是两个方向。同一个工具，相反的结果。以及，你应该怎么走第一条路。 理解力债务是什么 在展开之前，先把这个贯穿全文的概念讲清楚。 你用过导航软件吧？跟着导航走，左转右转，顺利到达目的地。但如果关掉导航让你原路返回，你大概率做不到。你到...

我是后端开发。最近一年，AI 编程 agent 已经成了日常开发的主力——Claude Code、Pi、Codex，经常同时开好几个，让它们各干各的。 单个 agent 用得都挺顺手，但 agent 一多，它们之间的配合就开始让人头疼了。 任务分派断裂 一个需求经常要动好几个仓库。我在某个项目目录（或者几个仓库的共同父目录）里跟 agent 讨论了半小时，方案终于敲定了——然后呢？ 我得自己记住「order-service 要做 A、user-service 要做 B」； 手动打开新终端、cd 到对应仓库、再起一个 agent； 把刚才讨论的结论复制粘贴过去，还要祈祷上下文没丢； 然后对第二个仓库重复一遍…… 沟通的现场和执行的现场是分离的，中间靠人肉搬运上下文。每个终端里的 agent 都是孤岛，不知道其他 agent 的存在，更谈不上协作。 最近我试了一个叫 Herdr 的工具。它是一个终端工作区管理工具，和同类工具最大的区别是：它提供了一套 CLI 和本地 socket API，让 agent 之间可以互相操作——需求讨论完，主 agent 直接在自己的终端里创建 ...

这算是一个不成熟的想法，想先记录下来，接受大家的检验和讨论。 故事要从我的日常说起。 自测的一天 我是一个后端开发，技术栈主要是 Spring Boot。一个典型的需求开发流程大概是这样的： 1理解需求 → 编码 → 自测 → 联调 → 提测 每一步都还好——除了自测。 自测意味着：我需要证明这个接口在各种业务状态下行为正确。为了达到这个目标，我通常需要： 准备数据：手动往数据库里插各种状态的用户、订单、账户 部署服务：把改动部署到测试环境（或者本地跑起来） 构造请求：部署后在页面上一个场景一个场景地操作，模拟各种用户行为 验证结果：检查返回值、检查数据库落库、检查下游是否被正确调用 发现问题 → 修 → 重新部署 → 重新造数 → 重新验证 协调上下游：有些数据自己造不了，得找对应的同学帮忙——或者自己搭 Mock 服务 写自测文档：如果团队有这个要求——把测试场景、测试数据、测试结果整理成文档，附到需求上 这一套走下来，大半天甚至一天就过去了。而且这还没算上中途被拉去开个会、被各种消息打断的碎片化开销。 更糟糕的是：下次需求变了，这套流程从头再来一遍。 上次构造的测试数据...

在之前的《知识沉淀的第一步——统一语言与 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 软件开发系列，在底层逻辑上有很深的共鸣。这篇文章试着把两边的思考放在一起，做一个梳理。 两种世界，两种文化 Sean 在文章开头提出了一个很有用的二分：软件工程里存在两种截然不同的文化。 世界 A：小型代码库文化。 Redis、个人项目、小型开源库。代码量可控，作者长期维护，架构可以全部装入脑中。这种环境里的人天然认为——「如果你不能理解整个代码库，你就无法做好修改。」追求的是对程序的完整理论模型（theory of the program，即对程序运行机制的完整心智模型）。 世界 B：大型商业系统文化。 Google 搜索后端、GitHub、大型企业内部系统。...

最近几个月，AI 编码工具已经成了日常开发的一部分。Claude Code、Cursor、Copilot——它们在代码生成和重构上的表现越来越好。 但用得越久，越觉得有一个断层：AI 在终端里帮我写代码，但我自己却要频繁切出终端去做别的事。查数据库切到 DataGrip，看日志 SSH 上服务器，构造测试数据打开另一个脚本。AI 离我的实际工作环境，其实还很远。 这个问题让我开始想一件事：能不能让 AI 编码工具直接触达数据库、服务器、日志——把它从一个「代码助手」变成一个真正的「研发工作台」？ 一、一个典型的排查场景 假设 QA 提了一个 bug：订单状态在某些情况下没有正确更新。 这时候我们需要放下手上的代码，开始排查： 12341. 切到 DataGrip → SELECT * FROM orders WHERE id = 123452. 看到 user_id = 67890 → SELECT * FROM users WHERE id = 678903. 想查这个用户相关的操作记录 → SSH 上服务器 → tail -n 500 /opt/logs/app.log ...

作为应用层开发者，这些概念我们每天都在用——Agent、RAG、Context Engineering、模型调用。但模型内部到底在做什么，一直处于一个「大概知道、细节模糊」的状态。 比如这些现象，我遇到过但解释不清楚： 为什么长上下文贵？ 为什么 prompt 越长响应越慢？ 为什么 RAG 需要控制 context？ 为什么流式输出不是「假装」的？ 这些问题都指向同一件事：推理阶段。 理解推理不需要先学会训练，也不需要成为算法工程师。只要从「一段文字进入模型到输出一个 token」这个完整链路走一遍，上面那些问题自然就有答案了。 这篇文章就是我走完这条路之后的笔记。它试图用后端开发能理解的方式来翻译 Transformer 内部的机制。 1. 当一次 API 调用发生时 先建立最核心的一张图。假设你调用 API，输入：“今天天气” 收到：“很好” 模型内部发生了什么： 123456789101112131415文字 "今天天气" ↓ Tokenizer —— 把文字切成 token，每个 token 查词表得到一个数字[1234, 5678, 9...

上一篇文章讨论了知识沉淀的第一步——用 CONTEXT.md 统一术语，用 ADR 记录不可逆决策。这两样东西构成了 AI 在项目中的知识底座 文章里提到一个关键动作：grilling。你运行 /grill-with-docs，AI 一次一个问题地追问你，同时在代码里搜索它能找到的事实。对话结束，术语更新了，决策记录了，共享理解也形成了 当时我写了一句话：「一次 grilling 跑完，AI 也已经在代码中走了一遍它能找到的相关路径——这个过程本身就是 Context 构建」 这句话对了一半。AI 确实走了一遍——但它走全了吗？ 会查 ≠ 查全了 grilling 的提示词里那条规则写得很清楚： If a fact can be found by exploring the environment, look it up rather than asking me. 翻译过来：事实如果能从代码里找到，别来问我，直接去查 这个设计方向是对的——人能少回答一个问题是一个。但它有一个隐含的前提：Agent 知道该查什么。 而实际上，Agent 查什么、查到什么程度、在哪停下来，...

上一篇文章的结尾，我提了一个问题：Execution 之后，代码自动进入了 Knowledge 空间，但其他几层知识不会自动更新。下一次任务还是会从同样不完整的 Context 出发 那么需要更新的到底是什么？怎么更新？ 这不是一个理论问题。如果你读完前六篇，觉得「把知识外化」听起来有道理，但不知道具体怎么动手——这篇文章就是给你的 很长一段时间，我对「知识沉淀」这四个字也十分抗拒。它听起来像某种咨询公司术语，暗示着一套繁重的文档体系。直到看到 Matt Pocock 的 skills 仓库中的实践，我才意识到这件事可以做到极简 两样东西就够了：统一语言和不可逆决策 两个文件 在 Matt 的实践中，一个项目的知识基础设施只需要两个目录： 1234567/├── CONTEXT.md ← 统一语言（glossary）├── docs/│ └── adr/│ ├── 0001-event-sourced-orders.md│ └── 0002-postgres-for-write-model.md└── src/ 不是「知识库」「文...

Specification 写好了。AI 知道改哪里、怎么改、不能动什么、需要测什么。接下来就是把这份精确的描述，变成可运行的代码 这就是 Execution。在整个链路中： 12Knowledge → Context → Decision → Specification → Execution 收集 筛选 判断 翻译 执行 它是最后一环——前面五环的全部投入，在这一环兑现 但 Execution 有一个独特之处：它是整个链路中 AI 最擅长的一环，却也是整个链路中最依赖上游质量的一环 如果 Specification 准确完整，Execution 是高效的、机械的、几乎不需要人工干预的。如果 Specification 有遗漏或歧义，AI 会忠实地把问题变成 bug。如果 Specification 约束过多，AI 被捆住手脚，发挥不出它在实现细节上的优势 Execution 的上限，是 Specification 的质量。而 Specification 的上限，是 Decision 的质量。以此类推。整个链路是一条质...