AI 正逐渐成为软件开发的强大工具。在之前的文章中，我们介绍了几种 AI 助力团队构建软件架构的方式。当团队不再满足于将 AI 仅作为头脑风暴的辅助工具，而是进一步用它来生成最小可行架构（MVA）的实现代码时，架构设计工作的本质也将随之发生实质性改变。
软件架构关乎决策，但 AI 生成的代码却是黑盒
“任何足够先进的技术都与魔法无异。”——Arthur C. Clarke
AI 的代码生成能力有时看上去近乎神奇，但也随之带来一个难题：我们无法真正看清或理解 AI 为何生成某段代码——这是模型本身的工作机制决定的。团队可以借助 AI 为 MVP 生成代码，而这一过程会隐式地做出关于 MVA 的相关决策。在此过程中，团队需要考虑以下几个架构问题：
当 AI 生成 MVP 时，团队无法控制 AI 做出的架构决策。他们或许可以就部分决策向 AI 询问，但大量决策依然是不透明的，因为 AI 并不理解它所学习的代码为何要那样设计。这与我们之前的文章中讨论过的框架问题类似：框架会替你做出决策，但你并不总能知晓这些决策具体是什么。
从开发团队的角度来看，AI 生成的代码在很大程度上就是一个黑盒；即便能够理解，也没人有足够的时间去逐一梳理。软件开发团队本就面临巨大的时间压力，他们借助 AI 来部分缓解这种压力，却也同时抬高了业务方对生产力的预期。如此一来，开发团队反而更没有时间去理解 AI 在代码生成过程中所做出的架构决策。
从某种意义上说，AI 就像一座生产技术债务的工厂，和我们遇到的几乎所有技术债务一样，它往往只有在出现问题时才会被“偿还”。AI 生成的代码本身并非为可维护性而设计，最终也只能靠更多的 AI 生成代码来替换。这就引出了一个关于系统可持续性的开放性问题：团队寄希望于未来的 AI 编码引擎，能用更优质、更可持续的代码来替换现有代码。
能体现这三类挑战的一个典型场景是：AI 生成的代码需要以满足 QAR（质量属性需求，如安全需求）的方式与现有系统对接。在可预见的未来，AI 生成的代码始终需要与现有系统集成，而这种集成通常通过 API 完成。开发团队必须确保整个系统体系的质量属性需求依然能够得到满足。
评估 AI 生成的黑盒的行为的唯一方法是实验
正如我们在之前的文章中所探讨的，团队需要回答关于其架构的三个问题；使用 AI 并不会改变这一点，尽管它能帮助他们更快地评估这些问题：
成本最高、也最需要优先考虑的决策，是开发一款本身就不值得开发的产品。借助 AI 生成（全部或部分）解决方案能够帮助团队更高效、更省力地通过 MVP 验证客户需求。
如果产品值得开发，那么代价第二高的决策就是构建出性能不足、无法按业务场景扩展的系统。AI 虽能帮助团队更快得到可实测的设计，但一旦方案无法扩展或性能不佳，团队只能让 AI 重新生成其他方案。如果到最后所有生成的方案都无法满足 QAR，他们就只能手动构建解决方案，而此时已经浪费了大量时间在评估那些被否决的方案上，甚至可能已经破坏了整个业务可行性。
在这些问题都得到满足后，接下来最关键的决策便与生命周期成本相关——即如何让系统在整个生命周期内具备可维护性与可支撑性，而这正是 AI 生成方案最容易出现问题的地方。和我们用过的所有代码生成工具一样，AI 生成的代码并非为可维护性而设计，一旦出错或失效，就只能通过新的提示词（或用原有提示词搭配新模型）重新生成。
对 AI 生成的系统进行面向 QAR 的实证测试，或许才是真正理解 AI 生成架构适用性的唯一方法。架构设计的关键在于判断哪些 QAR 对系统架构影响最大。团队永远没有足够的时间测试所有内容，因此明确测试重点至关重要。
AI 将架构设计的重心转向了如何验证架构
团队需要培养新的技能与洞察力来应对这一挑战。一些传统技术，例如架构评审、代码审查与检查、安全评审等，在面对大量 AI 生成代码时既不现实也低效。利用 AI 来审查代码或许是一种可行方案，但由于 AI 生成的代码本身并非为直接维护而设计，代码审查对其作用其实十分有限。
因此，架构工作的性质将从前期设计转向对 QAR 的实证评估，也就是对 MVA 进行验收测试。在这一转变过程中，开发团队需要协助业务方明确 MVP 的测试与评估方式。相应地，开发团队必须大幅提升对系统架构进行实证测试的能力。以下是可用于此目的的部分技术列表：
性能和可扩展性测试，重点关注系统满足其 QAR 的程度。
可用性测试，用于评估用户完成特定任务的有效性，确保系统易用且高效。
变更案例，包括直接影响 QAR 的架构变更案例，以及间接影响 QAR 的“功能”变更案例。
道德黑客测试，采用与黑客相同的工具对系统进行探测，在恶意攻击者利用漏洞前发现安全隐患。
Chaos Monkey——Netflix 开发的开源工具，用于帮助发现并修复系统漏洞。它会随机终止生产环境中的虚拟机实例与服务，以此测试系统的弹性。
对包含 AI 生成代码的系统进行测试变得愈发重要，测试重心需要从功能测试转向架构测试。在此过程中，开发团队需要找到并应用能尽可能自动化这些测试手段的工具。
软件架构仍然是关于决策和权衡
使用 AI 生成 MVA 并不会改变软件架构的基本逻辑：团队仍然需要对权衡做出决策。团队需要清楚可能存在哪些权衡，并在给 AI 的提示词中明确表述这些权衡。此时，AI 就像一个智能搜索引擎，去寻找能平衡这些权衡的解决方案。如前所述，这些方案仍需经过实证评估，但确实能为团队节省探索潜在方案的时间。
我们将这种方法称为 “Caveat Prompter”，你必须先理解问题与设计权衡，否则无法向 AI 提供足够信息，也就无法生成优质结果。这意味着团队在编写 AI 提示词时，需要明确权衡点与替代方案，让 AI 能在生成的代码中体现这些考量。
结论
AI 生成的代码是否会终结软件架构？答案是否定的。团队依然需要做出架构决策与权衡，但必须更清晰地阐述这些权衡及其背后的逻辑，才能在提示词中把这些思路传递给 AI。
然而，与任何技术一样，AI 在解决部分问题的同时，也带来了新的挑战。如果开发团队依赖 AI 生成代码来打造成功的 MVP 和 MVA，其实是在进行一场危险的博弈——他们交付的系统可能在未来某个时刻崩溃，而自身却无力修复。更糟的是，AI 生成代码的质量可能会随时间下降，新模型更容易出现静默却致命的故障模式，因为它们是用比旧模型质量更差的代码（通常本身就是 AI 生成的）训练出来的。这会让团队越来越难以改进依赖 AI 生成代码的系统。
除了将软件架构的重心转向实证验证外，团队还需要从新的角度思考可维护性：当 AI 的行为可能发生变化，甚至完全无法使用时，他们未来是否还能支撑这套系统？
原文链接：
