复利工程：AI 时代的软件资产积累之道

复利工程Compound Engineering这个提法最近在我所在的技术讨论圈子里出现得越来越频繁。它不是一个具体框架也没有标准实现但很多团队在复盘 AI 辅助开发的效果时都会绕到同一个结论上代码写得快不重要能留下来的东西越来越多才重要。把这个思路往前推一步就是复利工程——把软件开发中的每一次产出都当作本金让代码、文档、数据、上下文这些资产在时间轴上滚雪球让下一轮开发站在上一轮资产的肩膀上。这篇文章想跟你聊透这个概念它到底是什么、为什么在 AI 原生时代突然重要以及一个普通团队可以怎样分步骤落地。不管你是技术负责人还是正在寻找成长方法的开发者都应该能从这里面找到自己的切入口。1. 什么是复利工程从“交代码”到“养资产”1.1 复利这个比喻为什么会击中今天的软件开发者复利原本是金融概念本金产生的利息继续作为本金产生新的利息。软件开发里真正能产生复利的不是代码行数而是那些可以被反复调用、反复加工的知识载体。早期软件工程讲过程中期讲架构后来讲 DevOps现在讲 AI 原生而复利工程试图回答一个更根本的问题一个软件组织到底该积累什么才能让每一次开发都比上一次更快传统项目里我们经常遇到“单利式开发”。新需求来了翻不同的服务、找文档、问老同事最后在某个分支里把代码写出来。代码是写完了但下次找上下文的过程又会重新来一遍。整条开发链路里真正被长期使用的往往只有代码本身而代码背后的“为什么”“边界是什么”“哪些坑不能踩”仍然都留在人的脑子里。人一走经验就清零。复利工程要改变的就是这件事让每个环节的产出都以一种可以被检索、被消费、被增值的形式沉淀下来。在 AI 原生时代这个改变从“锦上添花”变成了“必选项”。AI 不会参加你的站会不会翻聊天记录。组织知识如果没有放在产品里、文档里、测试用例里、接口契约里AI 对它就完全无感。反过来说一旦组织知识变成机器可解的在线资产AI 就能以极低的边际成本参与下一次开发这个放大效应是指数级别的。1.2 复利工程的核心四类资产互相增强我给复利工程下了一个很朴素的定义它是一套以资产积累为中心让代码、知识、数据、AI 上下文在时间维度上互相增强的软件交付理念。代码资产可复用的模块、公共库、脚手架、API 契约。知识资产架构决策记录ADR、README、业务术语表、设计文档、会议结论。数据资产样本数据、测试数据、监控指标、埋点定义。上下文资产Prompt 模板、AI 评测集、模块上下文包、Agent 配置。这四类资产不是孤立的。代码越清晰知识资产越好写知识资产越完善AI 生成的代码越可靠AI 生成的代码质量越高代码资产越丰富测试数据越多AI 评测越准确。四者形成了一个互相增强的循环。可以拿整理工作台来类比。你每天工作都会留下工具和物料如果下班前随手归位第二天开工就很快如果每天都从杂物堆里翻东西那你的经验积累就是负的。复利工程就是给团队定一个“下班前归位”的纪律只是这里的归位对象不只是代码还包括所有能帮助未来开发的中间产物。1.3 与传统软件工程的关键差异复用对象扩展了传统软件工程说的“复用”主要指代码复用抽象公共函数、公共库、设计模式。但代码只是载体能被安全复用的前提是上下文完整。复利工程把复用对象扩展到知识、数据、上下文让复用不仅由人完成也可以由 AI 完成。维度传统软件工程复利工程核心问题如何高效交付本期功能如何让每次交付增加组织未来的交付能力复用焦点代码、组件代码、知识、数据、AI 上下文经验载体团队成员的记忆资产目录、上下文包、AI 可读文档迭代模式需求-开发-交付-维护需求-开发-沉淀-增值-再开发AI 的角色辅助编码工具资产消费者和放大器这个差异很重要。代码复用只是手段不是目的。很多团队的公共库放在那里没人敢用就是因为只有代码没有上下文。复利工程要求每次复用都要能回答这个资产能用在哪里、不能用在哪里、当初为什么这么做、改它会影响谁。这些问题不回答清楚代码资产就是一堆半成品。2. 为什么传统软件开发方式在 AI 时代开始失效2.1 项目制思维把“资产”挡在了门外项目制最典型的特征是目标导向按期上线交付验收。上线之后团队解散代码进入维护期文档归档处理。在这个过程中“资产”是被归档而不是被复利。一个结构良好、解决了一个典型问题的模块如果在项目结束后无人复用那这笔投入的复利就中断了。更关键的是项目评审会只问“这个项目值不值得做”从不会问“这个项目能给未来留下什么”。团队激励只看本期进度那自然没有动力把经验变成可复用资产。这不是开发者懒而是制度没有为复利留出空间。项目制并没有错错的是只看到项目而看不到项目背后的资产积累。2.2 代码复用率低不是开发者懒是上下文断了很多组织有公共组件库、脚手架、规范但复用率依然很低。为什么因为抽取出来的组件没有附带边界说明、兼容策略、迁移案例和决策记录。团队想用又害怕不可控。于是写一个相似但独立的实现。名义上是复用实际是重复。我见过一个典型的例子一个系统里存在三个冒烟测试工具功能几乎一样但因为实现方式略有不同各自的文档也都过时了后来维护的人不敢合并只能继续维护三份。每次都有人想“再写一个新的统一掉”结果又变成第四个。这说明复利工程的重点不只是“抽代码”还要“抽上下文”。一个资产如果无法被理解它就没有复利价值只有维护成本。2.3 AI 会十倍放大“上下文缺失”的代价在 AI 出现之前上下文缺失的代价主要体现在人身上新人翻代码、猜意图、问来问去多花时间而已。现在用 AI 写代码如果上下文缺失AI 会在代码层面显得很流畅但在业务语义层面错误百出。更麻烦的是这些错误看起来很合理评审时反而更难发现。团队如果没有把业务规则、约束、边界放进资产库AI 生成代码的收益会被返工成本对冲掉。反过来如果团队围绕 AI 重构了自己的上下文资产AI 能把开发周期压缩得极其极端。同样是使用同一代模型两个团队在效率上的差距可以拉开数量级。差别主要不在模型而在上下文资产的质量。2.4 “快”是 AI 时代最大的陷阱AI 让写代码的速度变快了但快速产出的不只是代码还有技术债和认知债。如果团队只看交付速度不建立资产沉淀机制AI 会把重复造轮子的过程也加速它可以从零写一个模块也可以继续把那段错误代码复制到更多地方。越快生成垃圾越多。这就是为什么“哲学”比“工具”更重要。工具解决的是“能不能更快”哲学解决的是“该积累什么才值得更快”。AI 原生时代先想清楚积累什么再谈效率否则效率只会让你更快速地制造混乱。3. 复利工程落地实践四个关键动作3.1 第一步盘点存量资产建立资产目录复利工程的第一件事不是写更多文档而是搞清楚你已经有什么。拉上后端、前端、数据、QA开一个半天的工作坊把系统里每个人知道的“可复用但没被索引”的东西全部列出来。不要只列代码。接口语义、测试数据构造方法、常用的 AI 提示词、部署手册里的坑、某个业务规则为什么这么定——这些都属于潜在资产。列完之后分三级A 类是过去 12 个月被反复引用、团队核心路径强烈依赖的B 类是有价值但缺文档、缺边界的C 类基本是一次性产品以后大概率不会再用。A 级立即补上下文包B 级按计划补C 级暂时不要投入。为什么这样分级因为复利工程的核心是“先利后复”没有回报支撑的资产建设不可持续。如果一开始就想把所有东西都资产化团队很快就会因为投入巨大而放弃。A 类资产是回报最清晰的部分先把它们做成样板比全面铺开更有效。3.2 第二步为高价值模块编写“上下文包”上下文包是我认为复利工程最直接的抓手。它指一个服务或模块在 AI 生成和维护代码时所需的全部最小知识集。一个典型的上下文包目录可以长这样payments-api/ ├── README.md # 这是什么、业务边界、关键概念 ├── adr/ # 架构决策记录为什么这么设计 ├── contract/ # 接口契约、错误码、版本策略 ├── fixtures/ # 可重复使用的测试数据与样例 ├── prompts/ # 该模块常用 AI 任务与期望输出 └── quality/ # 评测用例与验收标准为什么必须是这个结构因为它同时服务人类和 AI。新人接手时可以快速从 README 进入AI Agent 在动工前也可以先把整个目录扫描一遍。尤其是 adr 目录很多人觉得决策记录是给审计用的但在 AI 时代它是重定向最好的材料AI 如果知道“当初没选某个方案是因为什么”就不会再提出一个已经在坑里待过的替代方案也不会把代码结构改成一个未来寸步难行的形态。3.3 第三步把“先查资产再生成”变成默认工作流有了上下文包之后还要把它嵌入到实际开发流程中。如果大家写代码前后都不看那这些都只是静态文档。我建议在团队里定四条规则AI 生成任何新代码之前先加载相关上下文包。如果上下文包不存在或不完整先补包再生成或者边生成边补。每个 Merge Request 都必须包含“资产影响说明”这次改动了哪个资产新增了什么上下文。当 AI 生成了高质量解法时评审通过后把它抽象为资产写回资产库。第一点尤其重要。很多人用 AI 写代码是打开对话框直接描述需求AI 就开始输出。这种做法在没有复杂业务背景的系统里勉强可行但只要涉及遗留系统、多团队协作、严格约束产出质量就会很不稳定。让 AI 先读一遍上下文包代码第一次生成的成功率会有非常明显的提升。如果团队已经使用了支持模型上下文协议MCP的工具可以把上下文包直接暴露给 Agent就像给 AI 挂载了一个参考目录。这样“先查资产再生成”不是一句口号而是技术链路上真实发生的动作。3.4 第四步用资产指标替换部分交付指标不要完全否定交付速度指标但也应增加几项资产类指标否则复利工程很容易被冲刺节奏挤掉。建议至少盯四个数字资产覆盖率关键模块拥有可用上下文包的比例。目标可以从 20% 逐步提升到 80% 以上。首次进入效率新开发者或 AI 从拿到上下文包到提交可验收方案的时长。理想状态是明显短于没有上下文包的时候。复用率新功能对既有 A 类资产的复用占比。这个不追求 100%但如果在持续下降说明资产的边界或质量出了问题。变更前置时间从需求文档到可验收功能的时长。这个指标会伴随资产质量提升而逐步下降。要特别警惕一种情况速度在上扬但资产覆盖率在下滑。这通常意味着团队在透支过去的积累而不是在建立新的积累。短期的速度提升不可持续复利工程要的是跨越多个迭代的速度曲线。提示资产指标不是 KPI 考核工具而是帮助团队识别“透支”和“种植”的信号。指标是为了做决策不是为了给谁打分。4. 复利工程落地中的常见误区与避坑记录4.1 把“写了文档”当成复利最典型的问题就是团队一听说复利工程立刻开始猛写文档。几天后文档库多了几十个文件但距离“复利”还很远。没有消费者的文档不是资产而是负债。它占用存储、增加检索噪音、还会因为过期误导读文档的人。判断一份文档是不是资产只有一个标准有没有发生消费行为。比如新人读完之后是否不再反复问同一个问题AI 读完之后生成的代码是否更少返工如果两份答案都是否那这份文档应该被删掉或重写。我自己有一个技巧把文档当成代码来测。每次写完上下文包挑一个典型任务喂给 AI看它能不能独立完成。做不对就去改文档而不是怪 AI。这样文档质量会变成可检验的而不是“写了就好”。4.2 把“复制粘贴”当成复用复制粘贴在单点上看是最快的方式但它有一个致命问题分叉。每次复制出来改两行三份拷贝就变成了三个版本。此后同一个 bug 要修三遍同一个需求要改三个地方。这属于典型的负复利。正确的做法是给“三次原则”同一个模式出现三次时必须抽象。抽象的时候必须把边界和理由写清楚否则只是换了个地方粘贴。抽象后的代码要成为单一事实来源下游通过引用来继承它的行为而不是靠复制。改一遍所有使用者共同受益这才是正向复利。4.3 认为复利工程一定拖慢速度复利工程确实需要前期投入但不需要一次性大改进。最轻量的起步方式选一个正在迭代、问题最多的模块花半天补出一个最小上下文包未来两周内所有涉及该模块的任务都强制“先读包再做”记录这个模块的速度变化用数据说话实际经验里第一个模块往往在补包阶段就会产生回报。因为写包的过程本身就是一次强制的系统梳理你会顺手发现一批隐藏的坑契约不一致、依赖关系错乱、注释和实际行为不符。这些发现的价值通常已经覆盖了写文档的半天成本。4.4 忽视 AI 生成资产的质量治理AI 能生成代码、文档、Prompt但生成得很快不等于可以入库。如果不加审核、不打标签、不写清适用边界AI 的“半吊子输出”就会混进资产库成为未来 AI 和人类的错误上下文。这是复利工程里最隐蔽的风险低质量资产会像劣币一样驱逐良币。建议为 AI 生成内容设置“消毒流程”人工评审、补充边界说明、标注生成方式与验证结果。如果团队已经建立了 AI 评测集定期跑一遍可以有效防止上下文包或代码资产退化。把 AI 当成一个产出极高的新员工员工产出如果从不复盘、从不沉淀公司就不会真正获得积累。4.5 复利工程不是“知识管理”换了个说法知识管理像图书馆强调分类、归档、保管。复利工程像孵化器强调资产必须被投入下一轮生产并产生回报。区别在于闭环。图书馆里一本书没人借依然可以心安理得地放在架子上复利资产如果没人消费就必须被质疑。设计资产时应先想“谁会在什么场景下消费它”而不是“该放在哪个文件夹”。如果找不到明确的消费场景就不该把它做成独立资产。目标是让资产进入生产循环而不是建立一个漂亮的数字仓库。5. 复利工程对团队组织与个人发展的重塑5.1 团队从项目评审到资产评审如果复利工程只是个人习惯很难持续。要成为团队层面的哲学制度上需要增加一个“资产评审”的视角。代码评审时除了检查可读性、正确性、性能还可以问一句这次改动有没有让资产更清晰还是在消耗资产例会里也可以固定一个环节叫“资产增量复盘”每次只花十分钟列出本周新增的可复用模块、补全的上下文包、优化的 AI 评测集。绩效考核中“资产贡献”应当和“功能交付”一样被认可。提了一个可复用模块、补了一个高价值上下文包、把一个难问清的接口理清了——这些都值得在评审中被打高分。这意味着团队里开始出现一些新的隐性角色。有人擅长把业务知识结构化有人擅长定义模块边界有人擅长设计 AI 评测任务。这些角色不一定要有正式头衔但他们的存在会直接影响团队能否真正复利。5.2 个人把“每一次工作都为下一次加分”当成默认姿势对个人开发者来说复利工程不只属于团队它也可以成为职业发展策略。同一个三年经验的开发者A 可能做了三个功能后换了三家公司经验仍然停留在“做过”B 在每个项目里都留下了自己的知识库和可复用产物能力是逐年递增的。两者的差距在平时看不出来但五年后会很极端。个人层面的实操很简单修 bug 时顺手留一句“为什么会发生”的注释或关联文档。写复杂逻辑时随手写清边界和输入输出的定义。把常用的 Prompt 和踩过的坑放进自己的知识库而不是散落在聊天窗口。定期整理知识库把它当成你自己的“上下文包”。这些动作单次只需要几分钟但长期会形成巨大的差距。项目会结束团队会重组代码会被重写但你的方法论和沉淀不会消失。把每一次敲键盘都看成“养资产”长期回报会非常可观。5.3 团队能力模型从编码能力转向资产放大能力AI 原生时代编码门槛在降低。过去一个团队的核心竞争力是能不能写出高性能、高可用的代码现在代码生成越来越便宜真正稀缺的是“设计可积累资产的能力”。这种能力包括把业务知识转化成机器可理解的上下文、设计稳定的模块边界、通过评测集约束 AI 产出、在“快”和“稳”之间做权衡。传统技能当然还需要但它更像基础设施复利能力才是上层建筑。十个普通写码的人不一定会让团队走得更远一个能把资产结构理清的人可以让十个写码的人同时提速。我自己在这些项目里的体会是复利工程本质上不是工程流程而是一种写作习惯和认知习惯。真正管用的启动方式不是开动员大会而是把团队知识库当成产品来运营读者就是下一位开发者和你自己的 AI Agent。写每一份文档之前先想清楚“它会怎样改变下一次开发”这比任何流程表单都更能保证文档质量。如果你现在正觉得 AI 写了太多代码但团队速度并没有明显提升我建议从最小的模块开始花半天补一个上下文包然后让 AI 在下一次任务里先把它读完再让它动手。资产不会自己生长但它一旦被种对地方回报会一次比一次明显。