你已经利用人工智能生成了“最有价值球员”模型——那么，这对你的软件架构来说意味着什么呢？

事实证明，人工智能是开发软件的强大工具。在之前的一篇文章中，我们探讨了人工智能在帮助团队构建软件架构方面所能发挥的作用。不可避免地，团队会想要超越将人工智能仅仅作为辅助工具来使用，而是利用它直接生成实现“最小可行架构”的代码。当这种情况发生时，软件架构的设计过程很可能会发生根本性的变化。

软件架构本质上就是决策的集合，但人工智能生成的代码却是一个“黑箱”

“任何足够先进的技术都与魔法无异。”——阿瑟·C·克拉克

有时候，人工智能的代码生成能力确实会让人觉得仿佛有一种魔力在起作用，但这种能力也带来了一个难题：人们根本无法理解为什么人工智能会生成那样的代码；这仅仅是该模型本身的运作方式罢了。团队可以利用人工智能为他们的“最小可行产品”生成代码，而这些代码实际上已经在隐含地决定了他们最终要构建的“最小可行架构”的具体形态。不过，在这样做的时候，团队需要考虑以下几个方面的问题：

1. 虽然人工智能会帮助生成“最小可行产品”，但团队却无法控制人工智能所做的那些架构决策。他们或许可以询问人工智能关于某些决策的具体原因，但许多决策仍然会显得晦涩难懂，因为人工智能本身并不明白自己所学到的代码为何会表现出那样的行为。这与我们在之前的一篇文章中讨论过的“框架问题”类似：框架会为你做出决策，但你往往并不知道这些决策的具体内容是什么。
2. 对于开发团队来说，人工智能生成的代码在很大程度上就是一个“黑箱”；即使人们能够理解它的运作原理，也没有人有时间去深入研究它。软件开发团队面临着巨大的时间压力，他们利用人工智能来部分缓解这种压力，但这样一来，业务方对他们的工作效率也会提出更高的期望。因此，开发团队根本就没有时间去了解人工智能在生成代码过程中所做的那些架构决策。
3. 从某种意义上说，人工智能实际上就是“产生技术债务的工厂”。与我们遇到的几乎所有“技术债务”一样，这种债务只有在灾难发生之前是无法被“偿还”的。人工智能生成的代码本身并不适合被长期维护，它们只能通过更多的人工智能生成的代码来替代。这就引发了一个关于系统可持续性的重要问题：团队们只希望未来的人工智能编码工具能够生成出更好、更可持续的代码来取代现有的代码。

一个同时涉及这三类挑战的例子是：当人工智能生成的代码需要与现有系统进行交互时，这种交互方式必须满足各种质量要求，比如安全标准。在可预见的未来，人工智能生成的代码始终需要与现有系统连接，通常是通过应用程序接口来实现的。开发团队必须确保整个系统架构能够继续满足这些质量要求。

评估这种由人工智能生成的系统行为的唯一方法就是通过实验来进行

正如我们在之前的一篇文章中讨论过的那样，团队在构建系统架构时需要回答三个关键问题；使用人工智能并不会改变这一事实，但它可以帮助团队更快地分析这些问题：

• 最糟糕的决策就是花费大量资源去开发一个根本不值得开发的产品。利用人工智能来生成部分或全部的解决方案，确实可以帮助团队更早、且以更低的成本与客户一起测试最小可行产品。
• 如果产品确实有开发的价值，那么下一个需要慎重考虑的问题就是：如何构建一个能够满足业务需求、且具备良好扩展性的系统。人工智能同样可以帮助团队更快地确定设计方案，并对这些方案进行实际测试；但如果这些方案无法实现扩展或达不到预期的性能，团队就只能重新开始设计。如果最终没有任何生成的解决方案能满足质量要求，团队就不得不手动编写代码，而在此过程中，他们可能会浪费大量时间去评估那些被淘汰的方案，从而导致整个项目失败。
• 当这三个问题都得到解决之后，接下来需要考虑的就是系统的生命周期成本——也就是如何确保系统在其整个使用期内都能得到有效的维护和支持。在这里，人工智能生成的解决方案就显得尤为麻烦了。与我们曾经使用过的所有代码生成工具一样，人工智能生成的代码本身并不适合被长期维护；如果这些代码存在错误或无法正常运行，就必须重新使用新的指令或相同的指令但通过不同的模型来重新生成它们。

通过对人工智能生成的系统进行实际测试，以验证它是否满足各种质量要求，可能是真正了解这种架构适用性的唯一方法。在构建系统架构时，关键在于要弄清楚哪些质量要求对整个系统的设计最为重要。由于团队根本没有足够的时间去测试所有可能性，因此明确测试的重点就显得至关重要。

人工智能改变了我们评估架构可行性的方式

为了应对这一挑战，团队需要掌握新的技能并获得新的认知。对于系统中大量存在的人工智能生成的代码来说，一些传统的开发方法，如架构评审、代码审查以及安全检查等，都已经变得不切实际且效率低下。虽然可以利用人工智能来辅助代码审查，但由于人工智能生成的代码本来就不是为长期维护而设计的，因此这种审查方式对这类代码来说并没有太大的帮助。

因此，软件架构设计的重点将从前期设计工作转变为对系统是否满足需求规格的实证评估，也就是对最小可行产品的验收测试。作为这一转变的一部分，开发团队需要协助业务负责人确定如何对这些产品进行测试与评估。为此，开发团队必须提高自己通过实证方法来检测系统架构的能力。以下是一些可用于实现这一目标的技巧：

• 性能与可扩展性测试，用于评估系统在满足需求规格方面的表现。
• 可用性测试，用于检验用户完成特定任务的效率，确保系统能够被轻松且高效地使用。
• 变更案例分析，包括那些会直接影响需求规格的架构变更，以及那些间接影响需求规格的“功能”变更。
• 道德黑客测试，利用与恶意攻击者相同的工具来探测系统中的安全漏洞，以便在它们被利用之前发现并修复这些缺陷。
• Chaos Monkey——这是Netflix开发的一款开源工具，它通过随机终止生产环境中的虚拟机实例和服务来测试系统的抗干扰能力。

对于那些包含由人工智能生成的代码的系统来说，进行测试就显得更为重要了。此时，测试的重点应该从功能测试转向架构测试。为此，开发团队需要寻找并使用能够自动化执行这些测试流程的工具。

软件架构依然涉及决策与权衡

虽然利用人工智能来生成最小可行产品，但这一过程并不会改变软件架构的基本规律：开发团队仍然必须面对各种权衡与抉择。他们需要明确自己可能需要做出哪些权衡，并将这些信息清晰地传达给人工智能系统。人工智能则会像一个高效的搜索引擎一样，帮助寻找可能解决这些问题的方案。不过，这些方案最终仍需通过实证方法进行评估，但这一过程确实能为开发团队节省大量时间。

我们将这种设计方法称为“明确提示原则”——因为只有充分理解问题所在及相关的权衡因素，才能为人工智能系统提供足够的信息，从而生成高质量的成果。这意味着，在为人工智能系统编写提示语时，开发团队必须明确说明各种权衡选项及其背后的原因，这样人工智能才能在生成的代码中体现这些考虑因素。

结论

由人工智能生成的代码是否会终结软件架构的设计流程呢？并不会。开发团队仍然需要做出各种架构决策并进行权衡，但他们必须更加清晰地表达自己的这些考量与判断，并将这些信息融入到提示语中，才能让人工智能系统据此生成合适的代码。

然而，像任何技术一样，人工智能在解决某些问题的同时也会引发新的问题。如果开发团队基于人工智能生成的代码成功构建了MVP或MVA产品，他们其实可能正在玩一场危险的游戏——他们所开发的系统在未来某个时刻可能会出现故障，而他们可能根本无法修复这些故障。更糟糕的是，随着时间的推移，人工智能生成代码的质量可能会下降。较新的模型由于使用质量较低的代码进行训练（而这些代码往往也是由人工智能生成的），因此更容易出现那些“无声但致命”的故障。这样一来，对于那些依赖人工智能生成代码来开发系统的团队来说，要想逐步改进这些系统就会变得更加困难。<除了需要将软件架构设计的重点转向实证验证之外，各开发团队还必须以不同的方式来考虑系统的可维护性：当人工智能的技术发展方式发生变化时，或者当这些技术根本不再被使用的时候，他们是否还能继续维护这套系统呢？>