本文永久链接 – https://tonybai.com/2026/02/21/compound-engineering-ai-native-software-development-philosophy

大家好，我是Tony Bai。

在 2024 年和 2025 年，开发者们经历了一场狂欢。从 GitHub Copilot 到 Cursor，再到 Claude Code，我们习惯了通过自然语言生成代码。然而，随着项目规模的扩大，许多团队发现了一个尴尬的现象：AI 带来的加速度开始衰减。

为什么？因为传统的软件开发是线性的。你解决了一个 Bug，写了一个功能，代码库变大了，但也变得更复杂了。复杂度是软件工程的头号杀手。在传统模式下，新功能的开发往往是对旧代码的妥协。

而在 AI 辅助开发中，如果我们只是把 AI 当作一个更快的打字机，我们只是在以更快的速度制造“遗留代码（Legacy Code）”。每一次对话结束后，AI 对项目的理解（Context）往往随着会话窗口的关闭而重置。下一次，你不仅要重新解释需求，还要面对上次 AI 生成的、你可能都没完全读懂的代码。

Every.to 发布的最新报告《Compound Engineering: The AI-native engineering philosophy》中提出了 “复利工程（Compound Engineering）”，正是为了解决这个问题而生。这是一种哲学——如何让每一次开发迭代，都成为系统智慧的积累，而非技术债务的堆叠。它的核心理念颠覆了我们对软件资产的定义：代码本身不再是最重要的资产，系统对业务逻辑、设计规范和架构决策的“记忆”才是。

本文将深度拆解这一理念，探讨如何构建一个能够“自我进化”的 AI 开发系统。

什么是复利工程？

复利工程是一种 AI 原生的工程哲学。它要求我们将开发过程视为一个闭环系统，每一次迭代不仅要交付功能，更要沉淀知识。

在这个体系中，软件开发不再是简单的“编写代码”，而是由四个步骤组成的无限循环：

Plan（规划）-> Work（执行）-> Review（审查）-> Compound（复利/沉淀）

这看似普通的四个词，在 Agentic AI（智能体式 AI）的加持下，拥有了全新的含义。

在传统开发中，工程师是全能工匠。而在复利工程中，工程师晋升为“系统架构师”和“智能体指挥官”。

• 旧模式：工程师思考 -> 编写 Spec -> 工程师写代码 -> 工程师 Review -> 迭代。
• 新模式：工程师定义目标 -> 智能体规划 -> 智能体集群并发执行 -> 智能体集群多维审查 -> 系统自动沉淀知识 -> 工程师验收。

这种转变要求我们放弃对“手写每一行代码”的执念，转而专注于如何教 AI 学会我们的品味（Taste）和规范。

深度拆解：复利工程的四大循环

让我们深入技术细节，看看这四个步骤是如何在实际的 AI 原生工作流中落地的。

第一步：Plan（规划）—— 模糊性的消亡

在 AI 开发中，模糊是最大的敌人。如果需求描述不清，AI 会用幻觉填补空白，导致灾难性的后果。

复利工程要求在写第一行代码前，进行极度详尽的规划。但这不再需要工程师耗费数小时。

通过 workflows:brainstorm 和 workflows:plan 等指令，我们可以让 AI：

1. 理解需求：不仅仅是“做什么”，更是“为什么做”以及“有哪些限制”。
2. 研究代码库：AI 自动扫描现有架构，确保新功能不会破坏原有逻辑。
3. 外部调研：自动查阅框架文档、最佳实践，甚至 StackOverflow 的解决方案。
4. 设计方案：输出一份详尽的 PLAN.md。

这个阶段的产出物不是代码，而是决策。工程师的职责是在这个阶段介入，确认 AI 的路径是否正确。只要 Plan 是对的，执行只是算力问题。

第二步：Work（执行）—— 并发与隔离

这是复利工程最“暴力美学”的部分。

传统的开发者一次只能写一个文件，修一个 Bug。但在 Agent 原生架构中，我们可以利用 Git Worktree 或分支技术，实现并发执行。

通过 workflows:work，系统可以：

1. 创建隔离环境：为每个任务创建一个独立的分支或 Worktree。
2. 自动执行：AI 根据 Plan 编写代码。
3. 自我验证：自动运行 Linter、Type Checker 和单元测试。
4. 进度追踪：实时监控任务状态。

这彻底改变了“速度”的定义。速度不再取决于你的打字速度，而取决于你能同时指挥多少个 Agent 并行工作。

第三步：Review（审查）—— AI 审查委员会

这是质量控制的核心。在复利工程中，Review 不再仅仅依赖疲惫的同事，而是由一个专门训练的 Agent 审查委员会先行把关。

Every 的实践中，workflows:review 会唤起 14 个以上的专业 Agent，每个 Agent 佩戴不同的“透镜”：

• Security Sentinel（安全哨兵）：扫描 SQL 注入、权限绕过等 OWASP 漏洞。
• Performance Oracle（性能先知）：寻找 N+1 查询、无效索引、内存泄漏风险。
• Data Integrity Guardian（数据完整性卫士）：确保事务边界正确，数据迁移安全。
• Code Simplicity Reviewer（代码极简主义者）：强制执行 YAGNI 原则，删除过度设计的代码。
• Design Sync（设计同步者）：对比 Figma 设计稿与实现代码的像素级差异。

这些 Agent 不会疲倦，不会因为人情世故而放水。它们会输出一份包含 P1 (Critical) 到 P3 (Nit) 的详细报告。工程师只需要做最后的“法官”，决定是否合并。

第四步：Compound（复利）—— 灵魂所在

这是大多数 AI 工作流缺失的一环，也是“复利工程”得名的原因。

仅仅完成任务是不够的，我们必须让系统变得更聪明。

在 workflows:compound 阶段，系统会执行以下操作：

1. 捕获解决方案：AI 刚刚解决了什么难题？它是如何解决的？
2. 知识结构化：将这些隐性知识（Tacit Knowledge）转化为显性的文档、规则或 Skill。
3. 更新系统记忆：
   • 更新 CLAUDE.md：将新的代码规范、最佳实践写入系统级 Prompt 文件。
   • 创建新的 Skill：如果发现某个操作是重复的（例如“生成数据库迁移脚本”），自动将其封装为一个可复用的 Skill。
   • 优化检索标签：确保这些新知识在未来的任务中能被 RAG 系统准确检索到。

随着时间的推移，你的 AI 队友越来越懂你。它不再会犯同样的错误，不再需要你重复解释“我们团队使用 Kebab-case 而不是 CamelCase”。系统随着开发而生长，这就是复利。

必要的信念重塑：我们要遗忘什么？

要实施复利工程，技术栈的升级只是表象，更难的是工程师思维模式的转变。报告中列举了我们需要“遗忘”和“采纳”的信念。

需要遗忘的旧信念

1. “代码必须由人手写”
   • 新现实： 你的工作是交付价值，代码只是中间产物。只要代码是可维护、可测试、符合规范的，谁写的并不重要。
2. “每一行代码都需要人工审查”
   • 新现实： 这是瓶颈所在。对于常规逻辑，应信任自动化的 Agent Review 体系，人类只审查关键的架构决策和高风险逻辑。
3. “第一次尝试必须是完美的”
   • 新现实： AI 的边际成本极低。即使 AI 写了 95% 的垃圾代码，只要我们有机制快速筛选出那 5% 的精华，也是值得的。迭代速度 > 初始质量。
4. “写代码不仅是工作，更是自我表达”
   • 新现实： 这是一个痛苦的割舍。在商业软件开发中，我们要追求的是标准化和效率。将自我表达留在业余项目或架构设计中，而不是具体的实现细节里。

需要采纳的新信念

1. “将你的品味（Taste）提取到系统中”
   • 你对代码的审美、对架构的洁癖，不应该只存在于你的脑子里，而应该变成 CLAUDE.md 中的规则，变成 Lint 的配置，变成 Agent 的 System Prompt。
2. “50/50 法则”
   • 未来工程师的时间分配应该是：50% 用于规划（Planning）和沉淀（Compounding），50% 用于执行（Implementation）。以前这个比例可能是 10% / 90%。
3. “环境必须是 Agent-Native 的”
   • 如果一个任务（如运行测试、查看日志、截屏）人类能做但 Agent 做不了，那就是架构的缺陷。必须为 Agent 提供全套的 CLI 工具和 API 接口。

进阶实战：不仅是代码

复利工程的威力不仅限于后端开发，它正在渗透到软件生产的每一个环节。

Vibe Coding 与设计

对于前端和设计领域，报告提出了 “The Baby App Approach”（婴儿应用法）。

与其在庞大的生产库中小心翼翼地修改 UI，不如让 Agent 快速生成一个独立的、抛弃型的原型应用（Baby App）。

在这个沙盒中，你可以通过自然语言极速迭代设计（Vibe Coding），直到满意为止。然后，通过 Design Agents 提取其中的设计系统（颜色、间距、组件模式），再将其应用回主代码库。

这解决了“在屎山上雕花”的风险，让创新变得零成本。

用户研究与角色模拟

传统的用户研究耗时耗力。在复利工程中，我们可以创建 Persona Agents（角色智能体）。

将用户访谈记录、通过 Descript 转录的文本喂给 AI，构建出代表典型用户的 Agent（如“忙碌的营销经理 Sarah”）。

在开发新功能时，先让 Sarah Agent 试用并反馈：“这个仪表盘数据太多了，我早上只有 5 分钟时间看，这对我没用。”

这缩短了反馈循环，从几周（等待用户测试）缩短到几分钟。

市场与文档

Copywriting Agent 可以学习你过往所有的博文和文档，掌握你的语调（Voice）。

Changelog Agent 可以监控 Git Commit，自动生成发布说明。

这些都不是简单的生成，而是基于“复利”——它们知道哪些功能是用户关心的，哪些只是底层重构，从而写出真正有价值的文档。

如何开始？成熟度模型

实施复利工程不可能一蹴而就。Every 提出了一个 0 到 5 的成熟度模型，你可以对照自查：

• Stage 0: 手工开发 (Manual)
  • 纯手写，StackOverflow 是主要帮手。
• Stage 1: 基于聊天的辅助 (Chat-based)
  • 使用 ChatGPT 或 Claude 网页版，复制粘贴代码。效率提升，但上下文割裂。
• Stage 2: 逐行审查的 Agent 工具 (Agentic Tools)
  • 使用 Cursor Composer 或 Claude Code。AI 可以读取文件、修改代码，但人类仍需像保姆一样盯着每一步。这是目前大多数 Early Adopter 所处的阶段。
• Stage 3: 计划优先，PR 级审查 (Plan-first, PR-only review)
  • 关键跃迁点。 人类只参与 Planning 和最终 PR Review。中间过程由 AI 自主完成。开始建立 CLAUDE.md 等沉淀机制。
• Stage 4: 从想法到 PR (Idea to PR)
  • AI 自主进行调研、规划、执行、自我审查。人类只需给出一个模糊的想法。
• Stage 5: 云端并发执行 (Parallel Cloud Execution)
  • 脱离本地机器，Agent 在云端沙箱中并发运行。你喝着咖啡，手机上收到 5 个已完成功能的 PR 通知。

你的目标，应该是尽快从 Stage 2 跨越到 Stage 3。

小结：拥抱从量变到质变的飞跃

复利工程的核心不在于某个具体的 Prompt 或工具，而在于“积累”。

在传统开发中，随着项目老化，开发速度必然下降（熵增定律）。

但在复利工程中，随着 Skill 的积累、CLAUDE.md 的完善、测试覆盖率的提升，开发速度是加速的。你的系统越庞大，AI 可用的“积木”越多，它构建新功能就越快。

这是一种反直觉的体验，也是 AI Native 时代最大的红利。

正如报告中所说：“Ship more value. Type less code.”（交付更多价值，少敲代码。）

这不仅是愿景，更是每一位工程师在这个时代保持竞争力的必经之路。

开始行动吧，别让你的代码库只有“债务”，没有“复利”。

资料链接：https://every.to/guides/compound-engineering

你处在哪个 Stage？

对照文中的“成熟度模型”，你目前的 AI 协作处于第几阶段？在你的开发流中，是否已经开始尝试利用 CLAUDE.md 或自定义 Skill 来实现“知识沉淀”？你认为“代码不再是最重要资产”这一观点激进吗？

欢迎在评论区分享你的 2026 进化心得！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/02/20/why-we-need-new-go-module-review-mechanism

大家好，我是Tony Bai。

你以为你在 GitHub 上看到的代码，就是你的 Go 程序编译时使用的代码吗？答案可能令你背脊发凉。

在 Go 语言的生态系统中，我们一直引以为傲的是其卓越的包管理和安全性。Go Checksum Database（校验和数据库）被公认为现代编程语言中最强大的完整性保障机制之一。然而，前 Go 安全团队负责人、著名的密码学家 Filippo Valsorda 在最近的一篇文章中揭示了一个令人不安的真相：虽然 Go 的工具链是安全的，但我们人类审查代码的方式却存在巨大的安全漏洞。

本文将深入探讨这一安全隐患的成因，剖析著名的“虚假 BoltDB”攻击案例，并介绍 Filippo 及其团队 Geomys 推出的解决方案——pkg.geomys.dev，一个致力于填补这一信任缺口的源码查看服务。

Go 的安全基石：坚不可摧的 SumDB

在深入探讨漏洞之前，我们有必要先回顾一下 Go 语言为何被誉为拥有“无可争议的最佳包完整性故事”。这主要归功于 Go Checksum Database (SumDB)。

Go 模块的获取本质上是去中心化的。你可以直接从 GitHub、GitLab 或任何 Git 托管服务上拉取代码。例如，当你运行 go get github.com/example/mod@v1.2.3 时，Go 工具链（在 GOPROXY=direct 模式下）会直接克隆对应的 Git 仓库并检出 v1.2.3 标签。

这种去中心化虽然灵活，但带来了巨大的安全风险：如果代码托管方（如 GitHub）被入侵，或者作者遭受胁迫修改了代码，亦或是作者恶意 Force-push（强制推送）覆盖了标签，下游用户该如何察觉？

SumDB 应运而生。它的工作原理如下：

1. 首次记录：当某个模块版本第一次被 Go 生态系统中的任何人请求时，Go 代理（Proxy）会下载该模块，计算其内容的加密哈希值，并将其永久记录在 SumDB 中。
2. 永久锁定：SumDB 是一个透明日志（Transparency Log），类似于区块链的 Merkle Tree 结构。这意味着记录一旦写入，就无法被篡改或删除（即使是 Google 也做不到）。
3. 全网一致：此后，世界上任何一台机器下载该版本的模块时，Go 工具链都会计算本地下载内容的哈希，并与 SumDB 中的记录比对。如果 GitHub 上的标签被篡改导致哈希不匹配，构建将直接失败。

这种机制比传统的 PGP 签名或作者管理私钥要实用得多，同时提供了极高的安全性保障。

信任链的断裂：人类的“弱点”

既然 SumDB 如此完美，漏洞从何而来？

Filippo 指出，漏洞不在于机器，而在于人。

每当我们直接在代码托管平台（如 GitHub）上阅读代码时，我们就引入了一个薄弱环节。

Go 工具链验证的是下载到本地缓存中的 ZIP 包的哈希值。而我们在浏览器中打开 https://github.com/example/mod/blob/v1.2.3/exp.go 时，看到的是 GitHub 当前展示的 v1.2.3 标签对应的内容。

关键问题在于：Git 标签是可变的（Mutable）。GitHub 允许维护者强制推送标签。一个恶意的维护者（或攻击者）可以这样做：

1. 发布一个包含恶意代码的 v1.2.3 版本。
2. 诱导受害者（或通过自动化的 Go Proxy）下载该版本，使其恶意哈希被记录在 SumDB 中。
3. 立即 Force-push 一个“干净”的 v1.2.3 版本覆盖原标签。
4. 当安全研究员或用户去 GitHub 审查代码时，他们看到的是干净的代码，认为一切正常。
5. 但受害者的 go.sum 中已经锁定了那个恶意的哈希，他们的构建使用的是恶意代码。

这种“狸猫换太子”的攻击方式，利用了 Web 界面（GitHub）与构建工具（Go Toolchain）之间的数据源不一致。

真实案例回顾：虚假 BoltDB 投毒事件

这并非理论上的恐慌，而是已经发生的现实。

去年，Go 生态系统遭受了一次经典的域名抢注（Typosquatting）攻击。攻击者发布了一个名为“BoltDB”的虚假模块（利用了大小写或相似名称的混淆）。为了掩人耳目，攻击者利用了上述机制：

• 恶意代码被发布并被 Go Proxy 缓存。
• 随后，攻击者向 GitHub 强制推送了无害的代码。
• 当社区发现有可疑模块并试图去 GitHub 审查时，看到的只有人畜无害的代码逻辑。

当时，一些评论员错误地将此归咎于 Go Module Mirror 的缓存机制。但 Filippo 一针见血地指出：这本质上是利用了 GitHub Web 界面天然缺乏验证机制的漏洞。GitHub 展示的代码，并不是 Go 工具链正在使用的、经过 SumDB 验证的“真实”代码。

如何正确地审查 Go 模块？

既然 GitHub 不可信，作为开发者，我们该如何确保自己在审查“正确”的代码？

方案 A：本地硬核审查（CLI）

最安全的方法是将 Go 工具链实际使用的代码下载到本地进行审查。Filippo 给出了一个基于命令行的解决方案：

cd $(go mod download -json filippo.io/age@v1.3.1 | jq -r .Dir)

这条命令做了三件事：

1. go mod download：通过 Go 代理下载指定版本的模块，并自动进行 SumDB 校验。
2. -json：输出模块的元数据，包括其在本地缓存中的解压路径。
3. cd：直接进入该目录。

在这个目录中看到的代码，才是绝对真实、不可抵赖的代码。此外，Go 团队也正在开发 go mod verify -tag 命令（预计将在Go 1.27版本落地），用于验证本地 Git 仓库的内容是否与 SumDB 匹配，这将进一步简化本地审查流程。

方案 B：全新的在线审查工具——pkg.geomys.dev

虽然本地审查最安全，但不得不承认，在浏览器中点击 pkg.go.dev 的链接查看源码实在是太方便了。为了在“便利性”和“安全性”之间取得平衡，Filippo Valsorda 开发了一个全新的服务：pkg.geomys.dev。

这是一个类似于 go-mod-viewer 的源码查看器，但它在设计上完全针对安全性与现代体验进行了优化。它的核心价值在于：展示经 Go Proxy 和 SumDB 确认的、真实的 ZIP 包内容，而非 GitHub 上的 Git 仓库内容。

其核心特性包括：

1. 真实源头：它不克隆 Git 仓库，而是直接处理 Go 模块的 ZIP 归档文件。这确保了你看到的代码与 go get 下载的代码完全一致。
2. 优秀的阅读体验：支持语法高亮、行/多行链接、多种字体选择、自动暗色模式，以及完整的文件树和版本浏览器。
3. 浏览器插件支持：Filippo 提供了 Chrome 和 Firefox 插件。安装后，当你在官方的 pkg.go.dev 上点击源码链接时，它会自动将原本指向 GitHub 的链接重定向到 pkg.geomys.dev，实现无缝的安全升级。

它是如何工作的呢？

这个服务的实现非常精妙，充分利用了现代 Web 技术：

• HTTP Range 请求：它不需要下载整个模块的 ZIP 包。通过 HTTP Range 请求，它只获取 ZIP 文件的目录结构和特定文件的压缩数据。
• 浏览器端解压：解压缩过程直接在用户的浏览器中完成。这不仅减轻了服务器压力，也提高了响应速度。
• 未来的去中心化：目前的版本信任 Google 的 Module Proxy 提供的 ZIP 文件。Filippo 计划在未来（待 proxy.golang.org 修复 CORS 配置后）引入透明日志证明检查。届时，浏览器将能独立计算目录哈希（Dirhash），并与 SumDB 进行比对，甚至通过第三方八卦协议（Gossip）验证 SumDB 的一致性，从而实现真正的“零信任”安全查看。

对 Go 生态系统的启示

Filippo 的这项工作（以及背后的 Geomys 组织）不仅仅是造了一个轮子，它向整个软件供应链安全领域提出了一个严肃的问题：我们所依赖的基础设施，是否能够支撑“代码即法律”的信任？

长期以来，我们将 GitHub 视为代码的“真理之源”。但在现代包管理机制下，真理之源已经转移到了不可篡改的构件（Artifacts）和透明日志上。Go 语言通过 SumDB 先行一步，而工具链的配套设施（如 IDE、代码浏览器）也必须跟上这一步伐。

此外，Geomys 组织的运作模式也值得关注。它是由 Ava Labs、Teleport、Tailscale 和 Sentry 等知名科技公司资助的专业维护者组织。这种通过商业公司联合资助关键开源基础设施维护者的模式，或许是解决开源可持续性问题的一条新出路。

小结：与行动建议

作为一名负责任的 Go 开发者，我们应当意识到“便利”背后的代价。为了防止下一个“虚假 BoltDB”事件发生在你的项目中，我们建议：

1. 改变习惯：在进行安全性要求较高的代码审查（Security Review）时，不要盲目信任 GitHub 的 Web 界面。
2. 尝试新工具：安装 pkg.geomys.dev 的浏览器插件，将你的默认源码查看器切换到更安全的模式。这不仅是为了安全，也是为了获得比 GitHub 更纯粹的阅读体验。
3. 理解机制：深入理解 go.sum 和 SumDB 的工作原理。它们不是为了给 Git 仓库做备份，而是为了构建一个独立于代码托管商之外的信任锚点。

安全，往往隐藏在这些看似微不足道的细节之中。

参考链接：

• Inspecting the Source of Go Modules – Filippo Valsorda
• pkg.geomys.dev

你会怎么审代码？

习惯了在网页上“指点江山”的我们，可能都忽略了 ZIP 归档才是唯一的真理。在你的开发流程中，是否也曾遇到过 GitHub 源码与本地代码不一致的“灵异事件”？你会为了安全而安装那个将链接重定向到 pkg.geomys.dev 的插件吗？

欢迎在评论区分享你的安全观！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。