在 AI 时代构建 MVP

构建最小可行产品（MVP）总是要在极短的时间内完成。AI 可以通过基于他人经验提出替代方案来部分缓解这种时间压力。虽然它不能做出决策，但可以帮助团队更好地了解情况从而做出决策。他们仍然需要通过实验来验证这些决策，但 AI 也可以在这方面提供帮助，即生成运行实验所需的部分支持代码。

AI 对软件架构的潜在好处

在之前的一篇文章中，我们定义了“软件架构”对我们而言意味着什么：

“软件架构在于记捕捉决策，而不是描述结构。[......] 架构设计的关键活动在于形成关于系统如何满足质量属性目标的假设，然后使用实证主义来检验系统是否满足这些目标，然后重复这个循环，直到系统满足其质量目标。”

而最重要的架构决策在于质量属性需求（QAR）之间的权衡。

软件架构师如何做出这些权衡，AI 又如何能提供帮助？下表总结了 AI 可能在我们认为对软件架构至关重要的任务中为团队提供的帮助方式。“AI 能否提供帮助”这一列表明了 AI 在该任务中所能提供的帮助程度，图中阴影部分代表我们认为 AI 能够提供的帮助程度。虽然 AI 无法完全执行任何任务，但它对某些任务的支持程度要高于其他任务。

以下各节将详细讨论这些内容。

理解解决方案必须满足的 QARs

构建最小可行产品（MVP）的一个关键方面是形成并测试有关系统如何满足其质量属性要求（QARs）的假设。理解并优先考虑这些 QARs 并非易事，尤其是对于缺乏大量架构经验的团队而言。

当团队通过在提示中描述系统必须满足的 QARs 并请求大语言模型（LLM）提出相关需求来提供上下文时，AI 可以提供帮助。LLM 可能会提出团队可能忽略的其他 QARs。例如，如果性能、安全性和可用性是团队正在考虑的前三个 QARs，LLM 可能会建议考虑可扩展性和弹性。这对于软件架构新手来说尤其有帮助。

例如，在实现 MVP 时，满足可扩展性需求是一个重要但经常被忽视的挑战。实际上确实存在可扩展性需求；它们只是难以察觉。每个系统都有其业务案例，而业务案例中隐含着可扩展性要求。使用 LLM 可以帮助团队考虑他们可能忽略的可扩展性需求，特别是在构建 MVP 时。

推动架构决策

早期的一个架构挑战在于迅速缩小寻找合适框架和技术的范围。尽管 LLM 不能决定使用哪些技术，但它可以通过识别潜在选项并收集这些潜在选项的正面和负面报告来缩小搜索范围。

重要的是要理解 AI 不能对权衡做出决策：它可以提出有助于决策的替代方案，但权衡取舍则取决于开发团队。要从 LLM 中获得最大收益，他们必须在向 LLM 提问时提供具体的上下文细节。

例如，如果性能是系统必须满足的 QARs 之一，那么在提示中询问“让系统变快”的建议不太可能得到有用的建议。如果还向大语言模型提供关键系统特性，那么具体说明对响应时间/延迟、周转时间或吞吐量的要求将获得更好的建议集。它也可能迫使团队更深入地思考领域，以便能够简洁地解释需求。

在某种程度上，提示工程和提供重要上下文的行为可能和 LLM 提供的结果一样有用。获得好的结果需要具体的需求、清晰的沟通和对期望结果的理解。无论你是否使用 LLM，这一点都是成立的。这是一个“欲速则不达”的例子，因为花时间更深入地思考问题领域，才能从大语言模型提供的快速结果中获益。

通过实验获取支持其决策的经验结果

AI 在帮助开发人员创建解决特定问题的代码方面可以非常强大，但开发人员必须验证 AI 生成的结果，正如以下引语所表明的那样：

“虽然 AI 可以生成代码，但仍然需要人类专家确保它是正确的、高效的和可维护的。”

 

Joanna Parke

Thoughtworks 首席人才和运营官

有时验证 AI 的结果可能需要比从头开始创建解决方案更高的技能，就像有时看到别人写的代码并意识到它比自己写的更好一样。如果代码质量高，这可以成为提升开发者技能的有效途径。AI 还能帮助你发现并修复代码中的缺陷，这些缺陷可能是你自己忽略的。

除了简单的代码检查，实验为验证 AI 生成的结果提供了一种手段。事实上，正如一些研究人员所发现的那样，实验是验证它的唯一真正方法。

在之前的文章中，我们已经描述了使用实验来测试和验证架构的必要性。架构的某些部分是由 AI 生成的这一事实并不改变这一基本真理：架构只能通过经验来评估，不能从一系列原则中生成。

此外，LLM 可以帮助团队快速创建简单但足够的用户界面（UI）来测试业务和架构假设。早期 MVP 不需要高度抛光的 UI；实际上，过早投资于复杂的 UI 可能是浪费的。一个更好的策略可能是使用 LLM 快速生成足够好的 UI 代码，以便尽早探索关键问题。

最后，AI 还可以帮助完成一些较为平凡但重要的编码任务，例如创建一组单元测试。许多团队都难以抽出时间来创建足够的单元测试覆盖率，而单元测试的相对简单性使其成为 AI 辅助的一个良好候选对象。

记录并传达架构

记录和传达架构决策及其实现是架构师必须做的一项重要工作。如果未来支持系统的团队不理解开发系统的团队所做的决策，他们的更改可能会导致系统性能下降。AI 可以在系统开发过程中提供帮助。这有助于随着时间的推移提高系统的可持续性。一些例子包括：

在团队讨论架构决策时使用语音记录和转录工具，并总结这些讨论。这可以在未来对架构决策提出质疑时提供背景信息，可能需要更新甚至推翻这些决策。

• 将文本转换为架构图并记录现有图。

• 生成标准代码文档，例如 API 描述。

• 更新设计文档以反映实际实现的内容，并标记与设计偏离的实现区域。有时实现纠正了设计中的缺陷，但有时它偏离了设计。两者都是有用的。

理解与其他系统的接口

MVP 实现几乎总是依赖于其他系统；没有团队是从零开始的。因此，他们可能会花费相当多的时间来理解这些系统所提供的接口，特别是当这些接口文档不完整时。如果这些系统是在几十年前创建的，并且是用一种旧语言编写的，例如 COBOL，这种语言现在很少有人能理解和使用了，那么这项任务几乎是不可能完成的。

在开发 MVP 时，团队根本没有时间去做这些。AI 可以通过扫描代码并生成文档来提供帮助，例如描述现有系统的 API，包括一些旧的和维护不善的系统。AI 还可以帮助记录可能被忽视的系统之间的依赖关系，例如当一个系统通过未记录的接口或隐式地通过共享数据调用另一个系统时。这提高了 MVA 的质量以及 MVP 成功的机会。

理解并管理系统的技术债

有效管理技术债对于系统的可持续性至关重要。减少技术债本身就是一个固有的挑战性权衡，许多组织都无法妥善处理。他们一直承受着在每个连续的、逐步推进的 MVP 中增加功能的压力，但在这样做的过程中，他们通常也会增加与相关 MVA 相关的技术债。

AI 或许有助于识别可能增加技术债的代码区域，但由于技术债源于过去所做的决策权衡，AI 只能识别出那些最明显的可能需要改进的低质量代码实例，它不能做出有效减少或消除技术债主要来源所需的决策权衡。

相反，当做出新决策时，AI 可以帮助总结与决策相关的技术债以及它与其他考虑的选项有何不同。如果团队更擅长记录所承担的技术债（通过 ADR），他们可以使用该文档来帮助推动未来关于“偿还”技术债的决策。该文档可以包括为未来决策提供给 LLM 的示例。

再次强调，提示中提供的背景信息越多，LLM 提供的信息就越相关。例如，团队可以提供已知的技术债示例，例如使用同步 API 作为临时解决方案，而不是使用指定的异步接口。

实施反馈循环

如前所述，实验提供了团队可以用来改进其系统架构的反馈类型。AI 还可以以其他方式帮助团队，比如通过测试、架构审查和自动化代码审查来帮助团队评估其决策。AI 或许还能生成自动化测试，并通过执行自动化代码审查来帮助团队标记问题，然后由团队进行评估。

风险识别与缓解

对于一个系统而言，其架构风险是独一无二的，取决于其特定的环境。与帮助理解 QARs 的方式类似，AI 可以提供一份通用的风险及缓解措施清单，但它无法预测你的系统是否会遭遇这些风险。如果向 AI 提供相关细节，这可能有助于为系统列出潜在风险清单，这或许需要团队就风险问题进行讨论，从而做出更好的决策。

结论

虽然软件架构师不会被 AI 取代，但他们确实需要学习如何以及在何处使用 AI 来做出更好的决策和实现更好的权衡。审视软件架构师的工作可以洞察到 AI 可以可以在哪些方面以及如何提供帮助。专注于 AI 如何帮助团队生成最小可行产品（MVP），进一步聚焦了 AI 如何提供帮助：它使团队能够在开发可持续架构的同时放宽一些他们面临的约束，同时仍然满足 MVP 的时间要求。这释放了团队，使他们能够发现更具创造性的解决方案来应对架构挑战。

原文链接：

https://www.infoq.com/articles/architecting-mvp-AI/