很多团队接触 AI coding 之后的体验大致相似。最初一两周感觉非常快：以前写半天的样板代码现在几分钟出来，以前懒得做的小工具现在一句话就能让 agent 开工。这个变化真实存在，但它只解释了第一周的兴奋，解释不了第二个月的疲惫。
第二个月问题换了一种形态。代码生成量上去了，review 排队堆起来了。agent 改得更快了，也更容易改坏旧逻辑了。它不知道哪些边界是不能动的，哪个模块的 owner 最在意什么抽象层级。每次新会话都要重复解释项目背景，因为上一轮的上下文没有被任何机制保留。团队里每个人都用 AI，但生成出来的风格、抽象边界和质量标准并不一致。AI 让写代码这件事成本骤降，但团队整体交付能力并不一定持续提升。快的是生成这一步，慢的环节变成了理解、验证、整合和决策。
什么叫复利？不是今天省下半小时，而是今天做的事能降低明天、下周、下个项目的成本。
如果拿这个定义来衡量，AI coding 里大多数被反复讨论的东西其实没有复利。
买工具不积累。许可证会到期，定价会调整，新工具会替代旧工具。工具是交付渠道，围绕它建起来的上下文、规则、测试和平台才是资产。
单次 prompt trick 不积累。它的半衰期以模型升级为单位，而现在模型升级的间隔是几个月。跨模型版本积累下来的，是上下文质量和验证体系的严密程度，不是某句话怎么措辞更管用。
以代码量衡量产出不但不积累，还会起反作用。如果一个团队用行数、commit 数、PR 数来衡量成功，AI 会让这些数字飞涨，但底下代码库在变烂。GitClear 分析了 2020 到 2024 年间 2.11 亿行代码变更，发现重构和移动代码的比例从 25% 降到了 10% 以下，代码块重复率在 2024 年达到了 2020 年的十倍。Larridin 记录了部署频率翻了两三倍，有意义的产出几乎没有变化。AI 时代该看的指标是代码存活率、变更失败率、review 负担、回滚频率和维护性评分，不是产出量。但多数团队的度量体系仍然围着产出量转，这本身就是 AI 放大工程债务的机制之一。
资深工程师手工 review 所有 AI 输出不积累。人脑阅读带宽是固定的硬上限。Colin Breck 的表述是：人类永远不会有足够的时间去看完 AI 写的所有代码。review 的方式必须从逐行语法检查转向逐意图设计评估：机器做约定和安全的自动化校验，人评估设计决策和业务风险。不转这个弯，senior 就成了组织想用 AI 绕开的那种瓶颈本身。
没有持久记录的培训也不积累。workshop 结束以后，如果没有任何东西被写进规则、测试或共享上下文文件，组织的资本就没有增加。MIT Sloan 的研究框架区分了三件事：Verification 保证这一次的质量，Evaluation 决定这一次做得对不对，Learning Capture 保证下一次的质量。很多团队做了前两步，没做第三步。每轮 review 的判断在下一轮开始前就蒸发了。这叫做 review 却没有复利。
刚才说的这五件事，判断标准都一样：能不能让下一轮工作比这一轮更容易。代码生成成本下降以后，工程系统的瓶颈从写代码转移到了五个地方：上下文供给、验证带宽、架构边界、工具可调用性和判断标准。个人和团队的复利，都发生在这五个地方。
第一个能积累的，是机器可读的上下文。项目背景、设计决策、失败尝试、测试约定、部署方式、个人偏好，这些东西写下来一次，未来所有 agent 会话都能复用。ChatGPT 式对话每次从零开始；项目文件夹里的规则、文档、测试套件和本地知识库会越用越厚。
这个逻辑在团队层面也一样。AGENTS.md 是一个跨工具的 Markdown 规范文件，告诉 AI agent 怎么做构建、怎么跑测试、遵守什么约定、避开哪些坑。它的维护原则很务实。Agent 第二次犯同样的错误时，把约束写进文件。这件事切换了文档更新的动力来源：从”完成文档 KPI”变成了”纠正 AI 行为”。后者自带持续性，因为不更新就会继续出错。Chris Reddington 直接把测试约定、架构约束、不可触犯的规则和 review 期望称为可复利的资产。写进去一次，未来所有 agent session 继承。
第二个能积累的，是确定性验证能力。使用 AI coding 时一个有效的做法是：在让 AI 写任何东西之前先问，做完之后怎么判断它对不对。测试、类型检查、lint、截图、benchmark、golden case，这些不是流程开销，是给 AI 的导航信号。验证越确定，AI 越能自己返工。没有验证，人就变成了 AI 出错和 AI 修改之间的反馈搬运工。这个模式无法持续。
验证这件事从个人习惯升格为团队基础设施，会产生一个质变。Google DORA 2025 覆盖近 5000 名从业者的报告得出过一个结论：AI 是放大器，放大强项也放大缺陷。工程基础好的团队在提升吞吐量的同时不影响稳定性；基础差的团队在加速产出的同时也加速出问题。Faros AI 的遥测数据覆盖超过一万名开发者，显示 AI 使用者 tasks completed +21%、PR merged +98%，但 PR review time +91%。个体产出飙升了，review 带宽没变，所以队列堆在了 review 那一步。测试、CI、pre-commit hooks、staging 环境和安全扫描不再只是”做得更好”的选项，它们变成了”能不能安全吸收 AI 速度”的必要条件。SonarSource 提了一个角度：当 AI 几秒钟生成数百行代码时，传统 peer review 的前提已经不成立，团队正在进入一个”黑箱代码”时代：代码看起来对、功能上也通过了，但其中包含的依赖关系和隐式假设没有一个开发者真正消化过。
第三个能积累的，是把团队标准编码为可执行的基础设施。Martin Fowler 和 Rahul Garg 对这个问题的表述是：资深工程师的模式检查、约定 enforcement 和风险提醒，可以从人脑里的判断变成共享基础设施。关键是”基础设施”这个区别：不是写给人类看的 style guide，而是写给 AI 执行的约束，要显式、多示例、带检查项、少抽象概括。有同事离职，他脑子里的标准不会跟着走。
这件事再往上看一层，就是平台工程作为 AI 赋能层。没有平台层的统一治理，每个团队都会各自发明一套规则、模型选择、成本跟踪和上下文管理，组织层面的能力根本攒不下来。Shopify 的做法提供了一个参考：他们没有统一成单一 AI 编码工具，而是做了一个集中的 LLM proxy，让 Cursor、Claude Code、GitHub Copilot 和实验性工具同时接入。平台提供统一的治理、成本控制、权限、上下文注入和审计日志，团队自己选工具。这样做把 AI 工具从一堆个人订阅，变成了一个有治理、可观测、能积累的组织能力。
第四个能积累的，是问题定义和验收标准。代码生成成本下降以后，真正稀缺的东西是知道该写什么、为什么写、写成什么样算对。个人能力的积累，是把模糊需求转成 agent 可执行的任务定义，把隐性的品味和判断转成可检查的标准。Every.to 提出了 Plan → Work → Review → Compound 四步循环，核心判断是 80% 的价值在规划和审查，不在编码本身。但规划的价值只有在最后一步”Compound”被做了才会积累：每个功能做完之后，方案选择的原因、被拒绝的替代方案、出过的 bug 和修复模式，这些判断需要写回仓库。没有第四步，每轮工作产出的判断就蒸发了。
与这个逻辑一脉相承的是刻意学习。Anthropic 的一项 RCT 让 52 名初级工程师在有无 AI 辅助的条件下完成编程任务后测理解程度，AI 辅助组在刚用过相关概念后，理解测验成绩比手写组低了 17%。但在高分组里，使用 AI 的方式有明显差异：先让 AI 生成，再追问解释、要求比较方案、自己复述和验证，而不是直接拿结果交差。AI 作为学习加速器会积累能力，AI 作为理解替代品会透支能力。这个区别是行为层面的，不是工具层面的。
外部数据进一步印证了”AI 放大既有能力”这个判断。Jellyfish 发现资深开发者用 Copilot 后编码速度提升了 22%，初级开发者只提升了 4%。Fastly 对大约 1,200 名开发者的调查显示，资深开发者更常把 AI 代码送入生产，也更常报告大幅加速。MIT Sloan 追踪 18.7 万名 GitHub 开发者的研究发现，Copilot 使用者接触新编程语言的累计频率相对基线增加了近 22%。AI coding 没有自动拉平能力差距。它把已有的认知资本放大了。跨栈经验本身又会变成下一次判断的原材料。
能积累的东西会复利，反过来也一样：坏模式、坏习惯和坏信号也会在 AI 的反馈回路里自我繁殖。
中心的机制是上下文污染。AI 生成了一段能跑的局部补丁，但包含了重复逻辑、隐式假设，或者模仿了一个已经没有人在遵循的旧模式。下一次迭代时，另一个 AI agent 读到这段代码，把它当成项目惯例模仿。坏模式不是通过开发者失职传播的，而是通过反馈回路自己传播的。每一代输出都在训练下一代。GitClear 的数据记录了这个现象：重构和移动代码的比例从 25% 降到了 10% 以下，而复制粘贴代码的比例从 8.3% 升到了 12.3%。AI 倾向于生成局部可用的代码，如果不做重构和架构判断，局部速度会转化成长期维护成本。代码在当前这个需求上能用，但代码库整体变得更难改。
多轮迭代还会累积安全风险。IEEE ISTAS 2025 的一项实验对 400 个样本做了 40 轮迭代，5 轮之后 critical vulnerabilities 就增加了 37.6%。即使明确要求 AI 提高安全性，仍然可能引入新漏洞。AI 自我迭代不是自动往好的方向走。如果把静态分析、安全测试和人工审计排除在闭环之外，多轮修改会把浅层修复变成深层风险积累。
更深层的问题是对系统理解的侵蚀。当核心业务逻辑从状态机设计到权限边界到故障恢复路径都由 AI 主导输出，而团队没有逐层校验理解时，整个系统行为合约的心理占有就逐渐消退。表面上看功能都在跑，测试也能通过，但再也没有人能说出”这个订单状态为什么允许从 pending 直接跳到 shipped”。测试能证明某些 case 通过，不能替代凌晨三点线上故障时有人清楚知道这个系统为什么会走到错误状态的能力。那个时刻的恢复成本，是几个月”省事”累积的账单。更麻烦的是，这种侵蚀是渐进的：每一轮 AI 迭代都在已有不透明逻辑上继续追加实现，直到没有人能独立改任何核心逻辑。
协作减少本身还有另一层代价。MIT Sloan 的研究记录了一个容易被忽略的变化：Copilot 使用者的同侪协作减少了近 80%。一部分可能确实是低价值打扰被 AI 替代了。但也有一部分，是以往通过随口问一句、pair programming 传递的隐性知识。如果这些知识没有沉淀为 agent 可读的文档，协作下降会变成长期知识断层。
信任数据也在往同一个方向走。Stack Overflow 2025 对 4.9 万多名开发者的调查显示，使用或计划使用 AI 工具的比例从 76% 升到了 84%，但不信任 AI 输出准确性的比例也从 31% 升到了 46%。高度信任只有 3.1%。JetBrains 2025 调研 24,534 名开发者，85% 在用 AI，但只有 44% 嵌入了核心工作流。使用率和信任度之间的缺口，就是”用了但不敢信”的状态。团队如果没有建立共用的验证标准来判断什么能信什么不能信，就会陷入最差的组合：AI 用得很频繁，每行生成的代码却还要人脑二次确认。
体感偏差让这个问题更难纠正。METR 招募 16 名有经验的开源开发者，在 246 个真实 issue 上随机分配是否使用 AI，结果是使用 AI 时完成时间反而增加了 19%，但开发者主观认为自己快了 20%。人的体感记住了生成瞬间的快，忽略了理解、修正和验证的慢。没有测量，个体就会倾向选择”感觉快”的模式，而不是”实际有效”的模式。
AI coding 的采用可以分成三层。第一层是把 AI 当成更快的输入法：同样的工作，更少的打字。收益直观、真实，但天花板就是人的思考速度。第二层是把 AI 当成协作者：开始建立上下文供给、反馈闭环和验证习惯。个人复利从这里开始。第三层是围绕 AI 重做工程系统：让文档、测试、接口、工具和知识库能够被 agent 消费、被机器验证、被人判断。团队复利活在这一层。
工具还会继续变强。但团队之间的差距，主要不来自谁买了更好的模型访问权。差距来自谁更早把工程环境改造成了一个 AI 能有效工作、人也能有效判断的环境。这个差距会复利。
AI 让代码生成趋近零成本之后，真正稀缺的东西仍然和过去相通：想清楚该做什么，系统性地验证它做对了，以及让下一轮工作比这一轮更容易的组织记忆。这些一直是工程美德。AI 只是让它们从”做到更好”变成了”不做到就出问题”。
换个角度看，AI coding 热潮里最容易被低估的，恰好是那些不太热闹的东西：一份持续更新的上下文文件、一条每次 AI session 都会跑的安全规则、一个团队共享的测试基础设施、一套把每一次事故教训写回系统的机制。这些东西不会上 Hacker News 首页，但它们决定了团队是在积累能力还是在透支能力。工具会过时，模型会换代，这些工程资产会复利。