AI编程让开发提速十倍，架构决策为何却愈发迟缓？

侯君璠，AI架构陪跑师，清华大学工程管理硕士（MEM），企业架构研究会发起人，国内大型央企单位技术总监、解决方案专家。20余年工作经验，曾任美国某大型科技公司-M中国区首席架构师，国内某大型险资技术总监、某大型科技咨询公司副总裁。深耕于企业架构、人工智能研究与落地方案，以及先进工程项目管理和企业数字化转型等领域。

最初阶段效果确实不错。

过去要耗费一整天才能完成的接口，借助AI只需十几分钟便能产出初步代码；反复出现的DTO、转换逻辑、单元测试及接口文档等也不再需要程序员逐行编写。

代码产出效率获得了显著提升。

然而半年之后，一个反直觉的状况却浮现出来：

具体功能的实现变快了，但决定这个功能应当如何融入系统的过程却越来越迟缓。

需求评审的耗时在持续增加。

代码审查的难度也在不断攀升。

一次看似简单的改动，也需要反复确认会牵连到哪些模块、哪些状态以及哪些历史逻辑。

架构师用于梳理既有系统的时间，已经超过了用于规划新系统的时间。

症结并不在于AI写不出代码。

症结在于代码太容易就被写出来了。

一、AI削减了实现的成本，但并未削减理解的成本。

传统的开发模式下，编码工作本身就是一道天然屏障。

开发者在着手写代码之前，通常会先查阅既有的实现方案，理清各模块间的关联，再决定代码的归属位置。

这一过程未必十分规范，但"写代码耗时费力"这一客观事实本身就构成了一道门槛。

AI Coding显著降低了解决问题的难度。

开发者只需给出目标，AI便能迅速产出一份看似完整的设计方案。

它能够检索可调用的方法、补全参数、对接已有接口，并尽量确保当前任务能够顺利执行。

从局部视角来看，这样的方案是可行的。

但系统架构所关注的远不止维持现有功能正常运转。

它还会追问：

AI可以出色地解决眼前的问题，但它并不会自动把维护长期结构边界视为自身的核心使命。

因此，团队收获的是更快的代码产出速度，却并未同步获得更快的系统理解能力。

这正是架构变得越来越迟缓的原因之一：

代码的增速远远超过了团队对代码的理解速度。

二、既有的代码Review模式已经失效。

起初我们仍沿用过去的评审方式。

检查命名是否符合规范。

判断实现是否简洁。

单元测试是否通过。

识别既有代码中的重复片段。

但很快我们就察觉到，这些并非AI代码最危险之处。

AI生成的代码通常格式规范、结构完整，且能补齐相应的测试用例。

真正的难点在于以下这些方面：

假设某项需求是"修改客户的所属单位"。

AI迅速定位到客户表中的机构字段，并产出更新逻辑。

从代码层面审视毫无破绽。

然而在实际业务中，客户机构的变动还会波及以下层面：

AI已将字段修改正确，但它并不清楚此次改动所蕴含的业务关系变化。

以往，Review主要聚焦于"代码写得是否正确"。

如今，Review的首要任务转变为：

"AI所应对的挑战是否就是我们真正要解决的问题？"

这难道不是普通的代码审核吗？

Review的重心需要从代码层面转向设计前提及业务影响层面。

三、模块边界并非瞬间崩溃，而是在一次次看似合理的改动中悄然消融。

为了让AI获取更丰富的上下文信息，我们不断为其投喂更多的代码。

从一个类开始。

随后扩展到整个模块。

再之后便是相关的服务、公共组件以及数据库结构等。

上下文越丰富，AI给出的方案就越全面。

但随之而来的问题也接踵而至。

当某个模块缺失某项功能时，AI最直接的应对就是调用具备相似功能的另一模块。

一次调用似乎无伤大雅。

第二次也能给出合理解释。

随着此类修改不断累积，原本清晰的依赖关系逐渐被侵蚀。

A调用B。

B为实现另一功能而调用了A。

公共模块开始感知具体的业务细节。

业务模块能够直接访问其他领域的数据。

架构并非经历一次大规模重构后就陷入失控。

它是在一次次"优先满足当下需求"的过程中逐渐丧失边界的。

AI知晓系统的各个组成部分是怎样的。

但它未必清楚的是：

哪些边界是即便为了眼前利益也不可逾越的长期约束？

因此，仅凭向AI投喂更多代码并不能解决架构层面的问题。

上下文向AI描述了当前系统的样貌。

架构规则则需要让AI明白：

该系统的哪些功能在未来仍需被坚守？

后来我们便把模块依赖、可调用的方向以及禁止访问的范围全部固化为具体规则，并通过自动化手段加以校验。

真正有效的架构约束，并非仅存于架构师的脑海中。

它应当能够被AI理解，同时也能够被CI所检验。

四、除技术债之外，又出现了认知债。

AI Coding带来的另一显著变化是功能增速大幅加快。

以往一个迭代仅能完成两项需求。

如今在同等时间内能够完成四到五项需求。

业务方自然会将节省下来的时间全部用于新增功能。

于是代码库迅速膨胀。

重复逻辑、临时适配、局部补丁以及类似的实现层出不穷。

这可以视作传统意义上的技术债。

但还有另一种债务更为棘手：

团队逐渐淡忘了代码是如何演变成如今这般模样的。

一段程序能够运行。

但无人知晓为何要如此实现。

状态字段发生了变更。

却无人能够完整列举其作用范围。

同一个公共方法被多个模块调用。

但无人了解当初为何将其放置于此处。

在团队着手重新组织代码时，最大的挑战已不再是修改代码本身，而是确定哪些事项是不可动摇的。

这便是一种认知层面的债务。

技术债意味着系统的难度日益攀升。

认知债则意味着团队越来越缺乏变革的勇气。

AI固然能够产出新的代码，却无法帮助组织找回那些未留下痕迹的设计思路。

五、新人虽能快速产出成果，却难以建立系统的认知。

AI Coding能够降低新成员融入项目的门槛。

过去新人需要先熟悉开发框架、代码结构及公共组件后，才有望完成首次需求交付。

如今他们已能够边向AI提问边让其解读代码，并产出相应的实现方案，在两到三天内便完成功能提交。

从表象来看，培养周期确实变短了。

但数月之后，我们发现部分新员工能够完成需求，却无法清晰地阐述系统的运作机理。

面对代码时，他们通常给出的回应是：

"这是AI生成的，我知道它能正常运行，但不清楚其内部原理。"

这并非因为新人使用了AI才导致的问题。

AI应当被定位为学习及开发的辅助工具。

问题在于AI使新人得以跳过部分理解环节而直接获得答案。

若团队仍以功能交付作为衡量成长的标准，那么新人便缺乏足够的动力去构建完整的系统认知。

因此新人在使用AI之后，架构学习本应变得更加清晰。

他们需要领悟的是：

代码库不只是一段可执行的程序。

它还需要能够被整个团队共同阐释。

若AI能够迅速穿梭于代码之间，但团队成员却无法阐明该系统的设计由来，那么组织便会逐渐丧失对系统的解释权。

六、为何架构师反而更为忙碌？

AI Coding并未降低架构工作的难度。

而是将工作重心从架构设计上转移开来。

过去，架构师将大部分时间投入于方案设计、模块划分及技术难题攻克。

如今所耗费的时间越来越多地用于：

代码速度提升之后，架构判断便跃升为新的瓶颈。

由于AI大幅缩短了"如何编写代码"的时间。

但它并不能自动降低以下问题的难度：

这些事项仍需由人来决策。

并且代码生成速度越快，所需要做出的判断就越多。

七、重塑AI编码工作，首要在于调整研发管理。

AI Coding不应仅作为提升效率的工具被简单嵌入团队。

它将重塑代码生产的模式，同时也需要相应的管理制度与之配套。

之后我们主要推进了以下几项工作。

第一，将架构规则转化为AI能够理解的约束条件。

不能仅停留在"系统采用分层架构"的描述。

而需要明确：

这些规则不仅传递给AI，还需通过自动化工具持续加以校验。

第二，Review的设计应以结果为导向，而非仅关注代码层面的结果。

人工Review主要聚焦于以下几个要点：

AI涉及的重要变更需被记录至PR中：

原始Prompt可作为补充材料使用，但不能取代设计说明。

第三，将技术债纳入正式的计划体系中。

不能将AI所节省的时间全部用于堆砌新功能。

团队需设立清晰的重构与治理规划。

具体比例应根据项目进度灵活调整，但不能等到业务空闲时再去处理。

业务通常不会突然就闲下来。

第四点在于不能对所有AI生成行为放任自流，而需加以约束。

低风险、边界明确的模块可充分利用AI。

对于核心领域的模型、资金、权限及重要状态等代码，则需实施更为严格的设计与审核。

这并非因为AI无法编写。

而是错误发生后所造成的影响，远超生产率提升所带来的收益。

第五个方面是利用AI辅助新人学习，而非让AI替代新人完成学习。

AI能够解读代码、对比不同方案并生成示例。

但新人仍需进行架构讲解、设计复盘以及关键模块的研读。

写出第一段代码，并不意味着对整个系统的理解已经完成。

AI coding并未使架构失去价值。

恰恰相反，它使人们愈发重视架构。

当代码成本高昂时，团队会自动限制代码的数量。

当代码几近免费时，真正的稀缺性已不再是技术能力，而是转变为：

AI Coding已重塑了软件工程成本的构成方式。

代码生产的成本已大幅降低。

架构判断、系统理解以及组织的一致性已成为新的稀缺资源。

因此，代码生成速度提升十倍之后，架构师并不会因此变得轻松。

他所承担的角色已从过去的"协助团队编写代码"，升级为一个更为重大的命题：

"在代码能够被大规模生成的时代，如何避免系统被海量代码所淹没？"

声明：本文核心文字内容由本人亲自撰写，图片由模型生成