每一次拉取请求、bug 修复和代码审查都变成了开发工具自动应用的永久经验
2025年8月18日
作者：Kieran Klaassen（Cora 总经理）
在我打开笔记本电脑之前，代码已经自我审查过了。
我登录 GitHub，原本准备进入日常流程------标记命名不当的变量、删掉冗余的测试、建议更简单的错误处理方式。结果发现 Claude Code（在我终端里写代码和编辑代码的 AI）已经留下了几条有力的评论：
"将变量命名修改为匹配 PR #234 的模式，根据 PR #219 的反馈删除了过度的测试覆盖率，增加了类似 PR #241 的错误处理。"
换句话说，Claude 从过去三个月的代码审查中学习，并主动应用这些经验。它彻底掌握了我的偏好，就像一个聪明的新队友------而且有"证据"可查。
这感觉像作弊，但其实不是------这是"复利工程（compounding engineering）"。每次我们修复点什么，系统都会学习；每次我们审查点什么，系统都会学习；每次我们在可避免的地方失败，系统也会学习。我们现在构建 Cora（Every 的 AI 邮件助手）就是这么做的：创造能创造系统的系统，然后让开。
我称之为复利工程：构建自我改进的开发系统，每一次迭代都让下一次更快、更安全、更好。
典型的 AI 工程关注的是短期收益。你发一个 prompt，它写代码，你上线，然后一切重来。复利工程则在于构建有记忆的系统：每一个 PR 都会教会系统点东西，每一个 bug 都会变成永久经验，每一次代码审查都会更新默认值。AI 工程让你今天更快；复利工程让你明天和未来每天都更快。
三个月的复利工程已经彻底改变了我看待代码的方式。我已经无法再单纯写函数而不去想"这是否在教会系统"或"仅仅解决了今天的问题"。如果一个 bug 修复不能阻止整个类别的问题，我就觉得没修彻底；如果一次代码审查没有可提取的经验，我会觉得是浪费时间。
当你读完这篇文章，你也会被这种"执念"感染。
投入 10 分钟，获得永久回报
复利工程需要前期投入：你必须先教会工具，它们才能自我学习。
举个实际的例子：我正在为 Cora 构建一个"挫败感检测器"，目标是让我们的 AI 助手能察觉用户因应用行为而感到恼火，并自动生成改进报告。传统方法是写检测器、手动测试、修改、重复。这需要大量专业知识和时间，还要频繁在"用户思维"和"开发者思维"之间切换。如果系统能自我学习，岂不是更好？
所以我先写一个对话样例，在其中表达挫败感------比如反复问同一个问题，并且语气越来越简短。然后交给 Claude，一个简单的提示："这段对话表现了挫败感。写一个测试，检查我们的工具能否捕捉到它。"
Claude 写了测试，测试失败------这正是测试驱动开发（TDD）的第一步。接着我让 Claude 写检测逻辑。第一次写的不完美，这也正常。精彩之处来了：我可以让 Claude 不断迭代提示，直到测试通过。
不仅如此，它还能自己持续迭代。Claude 会调整提示，重新运行测试，阅读日志，看漏掉了什么挫败信号，再改。几轮之后，测试通过。
但是 AI 输出不是确定性的------一次有效的提示，下一次可能会失败。
于是我让 Claude 连跑 10 次。结果它只在 4/10 的情况下识别出挫败。Claude 分析了失败的 6 次，研究了每次失败时的 chain of thought（逐步推理过程），发现了规律：它忽略了用户可能使用的模棱两可语气，比如"嗯，不太对"，这种礼貌但带着不满的表达，当和重复请求搭配时就是挫败信号。于是 Claude 更新了提示，专门捕捉这种"礼貌但不耐烦"的语言。
下一次迭代，它 10 次里有 9 次能识别出挫败。足够上线了。
我们把整个工作流------从识别挫败模式到迭代提示再到验证------都写进 CLAUDE.md，这个特殊文件会在 Claude 每次对话前作为上下文读取。下次我们要检测其他用户情绪或行为时，不必重来，只要说："用挫败感检测器的工作流。" 系统已经知道该怎么做。
与人工编写的代码不同，这里的"实现"是一段 Claude 能基于测试结果无限改进的提示。每一次失败都教会系统，每一次成功都成为模式。（我们计划开源这个提示测试框架，让其他团队也能构建自己的复利工作流。）
从终端到"任务控制中心"
大多数工程师把 AI 当作额外的一双手。复利工程让它变成一整个团队，每做一次任务就更快、更聪明、更契合。
在 Cora，我们已经用这种方法：
- 把生产错误变成永久修复：AI agent 自动调查崩溃、根据日志复现问题，并生成解决方案和测试，确保不再发生。这让每一次失败都变成"一次性的"。
- 提取架构决策：记录团队设计讨论，让 Claude 自动文档化为什么选择某种方案，新成员第一天就能继承标准。
- 构建多元审查 agent：捕捉我的个人偏好，生成"Kieran 审查者"来执行我的风格要求，再加上"Rails 专家审查者""性能审查者"等专门视角。
- 自动化视觉文档：agent 自动检测界面改动，生成前后截图和多尺寸文档，节省人工 30 分钟，还确保审查时完整记录界面变化。
- 并行解决反馈：为每条审查意见创建专属 agent，同时工作，把原本要花数小时的往返沟通压缩成并行流程。
这种工作方式改变了工程师的意义。你的工作不再是"写代码"，而是"设计能设计系统的系统"。这是我发现的唯一方法：今天的工作能让明天的工作指数级变轻松，并且每一个改进都是永久性的。
在我们对 Cora 实行复利工程的三个月里，指标已经明显变化：功能的交付时间从一周以上缩短到 1--3 天，提前发现的 bug 大幅增加，PR 审查周期从几天压缩到几小时。
复利工程的操作手册
要构建会学习的系统，你需要重塑对开发的思维。经过几个月的打磨（以及大量失败的实验），我把它总结为五个步骤：
Step 1：通过工作来教学
每次你做决定，都要记录并固化，这样 AI 就不会再犯同样的错。
- CLAUDE.md：用简洁的自然语言存储你的个人偏好，比如"为什么我更喜欢 guard clause 而不是嵌套 if"、"为什么我会用某种命名方式"。
- llms.txt：保存更高层次的架构决策，比如设计原则和系统性规则，它们不会因为具体功能重构而改变。
这些文件把你的偏好转化为 Claude 的永久系统知识。
Step 2：把失败变成升级
东西坏了？很好，这是数据。但大多数工程师就此止步，只修眼前问题。复利工程师会写测试、更新规则、增加验证。
比如 Cora 的一个用户说从未收到过每日 Brief------严重故障！我们写了测试来捕捉类似问题，更新监控规则以检测 Brief 未送达，并构建评估程序来持续验证管道。现在系统始终会监控这一类问题。
Step 3：并行编排
AI 工作者可以按需扩展，唯一的限制是编排能力和算力，而不是人数或招聘成本。你可以同时调度五个专门 agent，而花费几乎可以忽略。
我的屏幕现在像任务控制中心：
- 左侧：规划。Claude 阅读问题、研究方法、写出实现计划。
- 中间：执行。另一个 Claude 写代码、生成测试、实现功能。
- 右侧：审查。第三个 Claude 根据 CLAUDE.md 审查输出、提出改进。
起初感觉很别扭，但一周内就自然了。
Step 4：保持上下文精简但"属于你"
网上充斥着所谓"终极 CLAUDE.md 文件"，别抄。上下文应该反映你的代码库、模式和经验。10 条具体的个人规则胜过 100 条通用的。无用的规则要删掉。
我审查自己的 CLAUDE.md 和 agent 文件时，就像在读我的软件哲学------它反映了我的学习、价值观和代码理念。
Step 5：信任流程，但验证输出
这是最难的。你会本能地想要事无巨细地检查每一行。但应该做的是：信任你建立的系统，用测试、评估和抽查来验证。出现错误时，告诉系统为什么错，下次就不会再犯。
停止编码，开始"复利"
有一点我很清楚：公司现在花每月 400 美元，就能得到过去一年需要 40 万美元才能买到的东西。一个人创业团队也能和融资团队竞争。AI 正在普及的不仅是编码，而是整个工程体系。杠杆正转移到那些比敲代码更快地教会系统的人手中。
从今天开始做一次实验记录。当某件本不该失败的事失败时，投入时间确保它永不再发生------写测试、更新规则、记录经验。开三个终端，试试"三车道工作流"：一个规划、一个构建、一个审查。说一声"拉取请求"，看分支如何开枝散叶。
然后明天再来一次，看看复利效应如何积累。
历史文章：