跟上 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 辅助代码新增了高级工程师审批的要求。这道审批关卡只解决了流程层面的问题，更深一层的结构性隐患并未消除 —— 当初这些变更看似具备可审核性，实则无人掌握代码背后的设计逻辑，该核心问题丝毫未得到处理。在管理层决策层面，谷歌 2025 年 DORA 报告指出，尽管代码交付的吞吐量在提升，但 AI 的持续采用与软件交付的不稳定性呈正相关。AI 大幅加快迭代变更速度，现有的测试、版本控制与反馈闭环体系已跟不上节奏，底层短板彻底暴露。首席技术官们查看监控面板时能直观察觉到整体态势发生了变化，却无法向董事会阐明架构层面究竟出现了哪些根本性改变。这两种隐患在暴露之前都是隐形的，唯有特定时刻才会暴露出来：生产事故爆发时、核心骨干离职时、技术重构立项时。每到这种关头，企业都会面对同一个无从解答的疑问：系统为什么是这样运行的？问题无关负责交付的团队，也无关系统本身。一旦代码编写环节不再是瓶颈，更棘手的难题便会凸显：快速且持续地验证人工编写或 AI 生成的代码是否仍符合团队预期、遵循既定架构规范且与业务依赖的可执行契约保持一致。在 AI 辅助开发的代码库中，这个问题还存在另一重难点：团队及其使用的智能体需要理解它正在改变的系统，而不仅仅是验证它。演进式架构历经二十年发展，形成了一套工具集，专门服务于需要持续迭代、同时保持整体一致性的系统：用于验证架构合规性的适配函数、通过明确权责边界与服务契约引导系统演化的限界上下文，以及作为动态防护屏障的架构特性（而非一次性敲定后便束之高阁）。这套工具集本身行之有效，但当初并未预料到会出现一种特殊的贡献者 —— 能以机器级速度产出代码却完全不具备对系统底层设计逻辑的完整认知。可理解性本是演进式架构的一个维度，AI 辅助开发使其重新凸显出来。它与可用性、弹性、容灾韧性、安全性等成熟架构质量特性并列，是团队在设计与运维阶段必须保障的核心指标。Phillip Mortimer 在 2026 年伦敦 QCon 大会上的演讲一针见血地点明了底层现状：软件复杂性正在超越人类理解的极限。这些技术与 AI 并不矛盾，反而会因 AI 的普及变得更为关键。当代码生成成为商品时，设计阶段将成为刚需，差异化变成了理解领域和设计护栏，让系统底层逻辑在全生命周期内始终可控。本文余下内容将论证：用于弥合上下文认知鸿沟的运行机制早已蕴含在演进式架构体系中。以规范为基准的契约驱动开发、测试驱动开发与架构适配函数构成了一套统一的验证系统，其价值远不止完成校验工作。这个系统会生成可检索的上下文存储库：既有用于规范产出内容的前向引导约束，也有用于评估已交付产物的反馈检测节点，全部与代码一同存储和进行版本化管理。上下文存储库可同时服务于人工审核人员、AI 智能体和后续的维护人员。正因如此，系统认知能力成为演进式架构贯穿全生命周期的固有属性，而不仅仅是在代码合并前关注的阶段性问题。框架：三大校验规范融合为一个系统企业真正需要的是上下文存储库：一个确定性的、版本化的意图、行为和架构一致性记录，可供开发人员和 AI 智能体在系统迭代变更时随时查询。唯一可信数据源是代码库中的工程产物，而非大模型对这些内容的临时记忆。团队可按系统边界自主决策：允许大模型基于该存储库进行多大范围的概率化检索，以及哪些场景必须使用确定性查询。框架假设自定义开发界面、可执行规格、CI 工具和版本化仓库，无代码平台和打包解决方案不在其适用范围内。仅维护单一服务的小型团队在系统规模尚未超出单人认知承载极限前可仅落地部分校验规范，不必搭建完整的上下文存储库。架构师熟知的三大工程规范——基于规约的 SDD、TDD 和架构适配函数——就是这个上下文存储库的内容来源。这三项技术本身都并非新生事物，创新点在于三者的融合：处于同一节奏的三个验证循环，保持其活跃的三种实践，以及作为共享产出的上下文存储库。图 1 直观展示了这种融合：三行分别对应三大工程规范，各列代表价值流各阶段，上方的条带是配套的实践，下方的条带是人类和 AI 智能体都能查询的确定性上下文存储库。图 1：三大验证规范（基于规约的 SDD、TDD 和架构适配函数）融合为一个完整的系统，贯穿交付价值流七大阶段：发现、规格化、设计、实现、验证、发布、运营。矩阵上方标注了每种规范必须严格执行的团队协作流程；三者协同生成并持续更新矩阵下方的确定性上下文存储库，该存储库分为四层，分别记录了结构、变更溯源、行为和一致性信息。图中以颜色区分各规范在不同阶段的角色：深青色代表核心主导，浅青色代表积极参与，米色代表辅助支持。资料来源：本文作者基于规约的 SDD 负责搭建意图层。一份持续迭代、机器可读的规约，捕获了意图、范围、约束和验收标准，与代码一起存放在代码库中，并在每次发生变更时强制执行。该规约是 AI 编码智能体的开发需求刚要，也是人类评审人员的参考依据。SDD 继承了自领域驱动设计的通用语言传统：该规约是通用语言的机器可读形式，人类和智能体都可用。针对它的操作很简单，但属于硬性要求：规约像代码一样编写和评审，有差异对比和审批，当实现与原始设计意图出现偏差时必须进行修订。最后一条是将该实践与现代外衣下的前期大设计区分开来的关键。这种失效模式正是 Martin Fowler 所说的”先写规约，写完即弃“：为给智能体提供开发纲要生成一份规约，后续却再也不更新。缺少配套协作，智能体只能依据过时的设计意图生成代码，团队就产出了流于形式的纸面文档。早期的实证开始出现，Marri 2026 年的一份银行微服务落地案例研究显示，若在规约层强制施加各类约束，相比无约束的 AI 代码生成安全缺陷数量下降 73%。一个案例研究虽不足以形成普适结论，但它指出了效能提升的关键切入点。第一步：在一个冲刺中为一个功能新建一个 /specs/ 文件，将其视为审查工件，若代码变更与规约不符、且未同步修订规约，则驳回该变更。TDD 建立行为层。先编写会失败的测试用例，再实现业务代码，遵循红、绿、重构三步流程。正如Kent Beck在其经典著作中提及、Martin Fowler 持续完善的理论所诉的那样，测试会在单元与功能层面锁定程序行为，保障重构操作安全可控。TDD 相关理论已有二十年发展历史，而 AI 改变的是这套方法的应用权重。当代码产出速度超过人工审阅速度时，唯有测试层能够捕获人工评审员无暇发现的程序行为退化问题。实践分为两大组成部分。第一个是先写测试规范，所有偏离该规范的行为都需留档记录，不允许私下默许豁免。第二个是具备足够的系统认知深度，以判断下一步该编写何种测试。测试既是智能体的任务说明文档，也是对智能体输出的验证依据，这意味着工程师判断哪些内容需要校验的能力是整个开发循环中的核心技能。在系统演进时培养工程师的专业技术功底与提示词编写能力才能在系统迭代过程中持续保持上下文存储库可靠可信。一种失败模式是把 TDD 当成额外负担：事后补写测试只为满足代码覆盖率门槛，这样会造成代码强耦合、团队抵触情绪滋生。第一步：后续所有由 AI 智能体生成的代码变更统一执行先编写测试的规范。在接受 AI 生成的代码之前，先编写或审核通过会运行失败的测试用例。架构适配函数建立结构层。自动化、可执行的校验规则用于核验架构合规性：模块化、性能、安全性、可部署性、可观测性。它们是单元测试在架构层面的对应方案，由 Ford, Parsons, Kua 和 Sadalage 提出，并通过 Thoughtworks