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 的适配函数驱动开发发展为交付实践。Java 中的 ArchUnit、TypeScript 中的 dependency-cruiser，以及其他生态系统中的等效库都实现了该模式。将其接入 CI 流水线，当架构特征出现退化时阻止代码合并。支撑这套机制落地的核心实践是代码集体所有权：团队维护目录，将违规视为技术债务而非麻烦，将信任传感器作为架构准入门槛，避免人工评审成为流程瓶颈。
在借助 AI 加速迭代的代码库中，资深评审人员的精力存在上限，认知过载会拖慢团队进度并增加线上故障发生率。把架构合规性校验工作从人工评审转移至自动化检测工具，能让代码合并请求评审聚焦在设计动因的深度审视，而非机械核对功能清单。该机制的典型失效模式分为两种：一是采用同步制架构评审委员会，二是依赖某位全能资深工程师包揽所有架构核查。两种模式均效率低下、极易造成人员精力枯竭，且往往要等到线上暴露问题才能发现架构存在的隐患。第一步：梳理团队反馈最多的三大架构痛点，并在三十天内将每个痛点转化为会阻断 CI 流程的架构适配校验函数。
在同一价值流中落实这三个规范就能构建出本文反复提及的上下文存储库。该存储库分为四层：结构层、变更溯源层、行为层和一致性层——分别对应系统的解剖架构、塑造系统的推演逻辑、预期与实际运行的行为，以及所有约束条件的实时状态。基于这四层数据会生成两类可视化视图：一类是机器可读的知识图谱，供 AI 智能体与 CI 任务查询调用；另一类是人类可读的系统规约文档，供架构师查阅。Birgitta Böckeler 的 harness 框架也给出了相同的分层逻辑：规约文档属于前向指引，而测试用例与架构适配校验函数则是反馈传感器。
上下文存储是审查者在询问为什么服务拒绝超过 5MB 的请求时查询的东西，在仓库的三个不同工件中找到规格、测试和适应度函数。一个人工智能代理在下个季度接手同一个功能时，从原始工程师工作的同一份规格和适应度函数目录开始，每个决策背后的推理都持久化在旁边，这就是弥合跨时间、跨贡献者、以及跨人类审查者和现在并肩编写的人工智能代理之间边界上的上下文差距的方式。上下文存储是让那个边界对系统演进不再重要的东西。具体而言，在代码仓库中的体现为：/specs/ 目录；架构适配校验函数清单；合并请求模板，针对 AI 智能体主导提交的 PR 强制要求填写三项内容：规格文档引用、架构校验函数变更、80/20 交接说明。
结论
产能效率早已不再是核心议题。AI 生成代码的速度更快，这是既定事实。当下亟待解决的关键问题是：代码的上下文信息、设计意图、架构推导逻辑、团队沉淀的经验记忆该如何留存——过去这类信息都是人工编写代码时自然附带产出的。如今代码以机器级速度交付，但上下文信息跟不上产出节奏，而架构层面终将为此付出代价。亚马逊业务团队发生服务中断故障，DORA 指标呈现稳定性持续恶化趋势，二者本质上都是这一问题带来的代价体现。其中的收益逻辑清晰易懂：成本优化体现在新人上手效率提升、故障事后修复工作量缩减；交付吞吐能力提升体现在阻碍版本迭代的功能退化缺陷变少；合规价值则体现为可供审计人员核验的可执行约束规范。三者本质都是弥补同一底层信息缺失所带来的增益抓手。
演进式架构本身就自带补齐该信息断层的工具。架构适配函数、基于规约的 SDD 和 TDD 已存在多年。将三者融合为一个统一的校验系统，把实践产出的工件统一存入代码仓库，并在日常开发流程中随时调取查阅，这便是一套落地解决方案。演进式架构长久以来一直在铺垫应对这类问题，只是从未明确点明这套完整方案。视角重构至关重要：上下文存储库并不仅仅是代码合并前才用到的临时产物。上线部署前，它为 AI 智能体提供完整上下文，使其生成的代码贴合设计意图、符合合规要求；同时为评审人员提供依据，深度核查 AI 修改了哪些内容、背后的改动逻辑。上线部署后，它能帮助工程师梳理线上故障的背景信息、为后续重构规划提供支持、定义不同系统间集成所需的契约，还能生成架构可视化视图，供管理层决策技术发展路线。整套流程逻辑：先自动化校验，再检索上下文厘清全貌。
这套方案的目的不是让 AI 辅助开发速度慢下来。AI 智能体高速生成代码本身并无问题。真正的目的是让系统背后的设计逻辑具备可自动化校验能力，使得开发人员与 AI 智能体能够协同迭代系统，且不会丢失完整的设计脉络。
参考文献
Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot (arXiv:2302.06590). arXiv.
METR. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity.
CNBC. (2026, March 10). Amazon plans a deep-dive internal meeting to address AI-related outages.
DORA & Google Cloud. (2025). State of AI-assisted Software Development 2025. Google Cloud.
Mortimer, P. (2026, March). Complexity and creativity in software engineering [Conference talk]. QCon London 2026.
Westheide, D. (2026, March 18). Spec-Driven Development is Domain-Driven Design's Impatient Cousin: Why BMAD won't save you. INNOQ Blog.
Fowler, M. (n.d.). Exploring gen AI: Specification-driven development — tools. martinfowler.com.
Marri, S. R. (2026). Constitutional spec-driven development: Enforcing security by construction in AI-assisted code generation (arXiv:2602.02584). arXiv.
Beck, K. (2002). Test-driven development: By example. Addison-Wesley.
Fowler, M. (n.d.).Test-driven development. martinfowler.com Bliki.
Ford, N., Parsons, R., Kua, P., & Sadalage, P. (2023). Building evolutionary architectures: Automated software governance (2nd ed.). O'Reilly Media.
Thoughtworks. (n.d.). Fitness function-driven development. Thoughtworks Insights.
ArchUnit. (n.d.). ArchUnit: Unit test your Java architecture.
Böckeler, B. (n.d.). Harness engineering. martinfowler.com.
查看英文原文：https://www.infoq.com/articles/ai-speed-context-store-architecture/
