跟上 AI 的节奏：为演进式架构构建上下文存储库 文章

2023年，微软研究院的一项研究"显示，使用 GitHub Copilot 的开发者完成编码任务的速度比对照组快了 55.8%。这个数字在厂商演示文稿和工程招聘计划中流传开来，成为业界衡量 AI 对软件开发影响的通用基准。两年后，METR" 让经验丰富的开发者在他们自己的大型代码库中进行对照实验。经济学家预测的 39% 加速和机器学习专家预测的 38% 加速与试验发现的结果截然相反。使用 AI 工具的开发者耗时反而增加了 19%。研究结束后，这批开发者却主观认为 AI 让自己的效率提高了 20%，主观认知与客观实测结果之间存在 39 个百分点的差距。这种认知落差有着清晰的规律：在开发一项功能的前 80% 环节，AI 会让人感觉效率大幅提升 —— 基础代码框架一键生成、代码可直接编译、自动生成测试用例，演示也能顺利运行。真正繁重的工作量都集中在最后 20% 环节。与现有系统集成、边界情况处理、调试没人记得当初如何编写的笨重测试环境、解决无文档记录的性能限制，还要吃透历史版本做出相关设计取舍的知识积累。AI 在前 80% 的开发流程里确实效率极高，但系统架构层面的核心难点全部落在最后的 20%，工作流程中最省时的前期环节掩盖了最耗时、影响最深远的后期工作，当开发者意识到问题时，早已没有调整方案的余地。并不是说 AI 辅助开发更慢。智能体高速生成代码是真实的生产力提升，这一点本身不存在问题。真正亟待解决的痛点是企业在高速产出代码的过程中流失掉的上下文信息：意图、行为、架构推理——工程系统从未适配如此高速的代码迭代节奏。这个差距就是本文要探讨的主题。AI 辅助开发带来的影响远比单纯讨论生产力高低更为微妙。它正在解耦过去同时发生的两件事：编写代码和理解代码背后的逻辑。在 AI 出现之前，开发者同时产出两者，编写代码的过程就是开发者理解业务与架构的过程。AI 消除了这个过程。代码现在以机器级的速度交付，但理解速度并没有跟上。两种维度下的上下文断层成本体现在两个层面。在团队执行层面，亚马逊 2026 年 3 月份发生的线上店铺宕机事故"是因为借助 AI 生成的代码变更未经规范审核便合并上线。公司随后进行了代码安全重置，并针对所有 AI 辅助代码新增了高级工程师审批的要求。