AI生成架构图的能力边界：Diagrams AI Can, and Cannot, Generate
Billy Pilger · calendar Nov 12, 2024 · 8 min read · Article
现在，生成式人工智能（AI）创建文本和图像的能力已广为人知。生成系统架构图似乎是这种能力的自然延伸。在本文中，我们将研究 AI 生成系统架构图的三个用例。我们将评估 AI 创建以下类型图表的能力：侧重于技术的通用图表、用于计划或提议的未来系统的白板图表，以及详细描述真实、现有系统的系统图表。
生成通用 AI 图表
首先，给出一个定义：在此上下文中，_通用_图表是指与源代码或已部署的解决方案（无论是现在还是将来）无关的图表。它们通常完全是装饰性的，或者解释诸如 AWS 或 Kubernetes 之类的技术是如何工作的。由于它们不描述实际的解决方案，因此通用图表在准确性方面有很多回旋余地。任何足够合理的图表都是可以接受的。
首先，让我们向 ChatGPT （版本 4o）提出一个简单的要求：
你好。你能生成一张典型的 AWS Serverless 系统的图表吗？
结果：
ChatGPT 第一次尝试就成功了。虽然不是很漂亮，但该图包含了简单的三层 AWS Serverless 系统的所有关键要素：用于文件存储的 S3，一个 DynamoDB 数据库，用于计算的 Lambda，以及用于表示层的 API Gateway。AI 推测我们想要一个 Web 应用，并包含了 CDN。
ChatGPT 的结果令人印象深刻，但实际上，它并不比搜索相同内容的图片更好。大多数人会仅仅根据多样性和美观性来选择后者。
在线上可以找到许多通用的技术图表。
无论它们来自哪里，通用图表的价值都很小。即使花很少的钱购买，也是一笔糟糕的交易。因此，让我们继续研究更有趣的白板图表案例。
使用 AI 进行白板绘图
白板绘图是指绘制具有明确定义功能的未来系统的图表。目的是识别问题并探索潜在的解决方案。白板图比通用图（见上文）更详细，但不如系统图详细，我们将在下一节中进行研究。
为了获得这样的图表，我们很自然地会向 ChatGPT 提供有关拟议系统目标的更多详细信息：
请使用 Serverless AWS 模式生成一个基于浏览器的图像处理和存储解决方案的 mermaid 图。它应处理用户注册和身份验证，允许用户上传和处理图像，并下载结果。它还应允许用户存储原始图像和处理后的图像。假设 AWS Lambda 处理所有图像处理，并使用待定的库。
这个结果是一个好的开始。关键的 Serverless 组件再次出现，这一次，其中一些组件根据其目的进行了命名：Original Images 和 Processed Images (S3 存储桶)，以及 Image Processing (Lambda 函数)。
但也存在一些问题：
- User 应该在解决方案框之外，而 API Gateway 应该在其中。
- 应该有一条从 User 到 API Gateway 的链接；否则，网关就没有任何作用。
- 此流程图将身份验证、上传和下载混合到一个流程中。如果这些是单独的视角，则会更清晰。
让我们用以下提示进行修复：
让我们从一些清理工作开始。你能将 “User” 元素移到 “AWS_Image_Processing_Solution” 框之外，并将 “API Gateway” 元素移到其中吗？
User 仍然在框内，但这是朝着正确的方向迈出的一步。让我们进一步完善：
请添加一个从 “User” 元素到 “API Gateway” 元素的箭头，并标记为 “Image Upload”。此外，是否可以为元素添加 AWS 图标并使用 AWS 颜色？
ChatGPT 乐于回复说 Mermaid 本机不支持节点中的图标，并提出了一些替代工具。但是，它确实添加了颜色：
不幸的是，没有图标支持，并且颜色品牌不是很正确，但无论如何，它看起来更好。
接下来，是否可以改进图表的结构？现在，它是一个流程图，在一个流程中显示三个流程。这错误地暗示了（例如）注册和登录可能会触发下游的图像处理。让我们修复：
与其使用流程图，不如将其表示为一个或多个序列图？
还不错！它正确地分割了流程（尽管颜色消失了，令人遗憾）。让我们修复一些东西：
你能将 “Access API with Token”、“Verify Token” 和 “Token Validated” 步骤移动到第二个序列图吗？它们应该发生在 “Upload Image Request” 和 “Store Original Image” 之间。
非常好；它按要求工作。
使用 ChatGPT 进行白板绘图显然是可行的，至少对于小型项目而言。它提供了一个出色的初始图，并欣然接受了改进。唯一明显的盲点是图标，这更多是 Mermaid 的缺点。
也就是说，AI 辅助的白板绘图提供的好处比表面上看到的要少。通过改进来手动指导 AI 非常耗时且可能很昂贵。另一种选择是直接使用 diagrams-as-code 工具（如 Mermaid 或 Ilograph)，它以更少的击键次数提供更多的控制。这些替代方案的代价是学习 DSL（领域特定语言）。用户应该自己尝试这两种方法，以评估他们更喜欢哪一种。
使用 AI 进行系统图绘制
我们将通过要求 ChatGPT 绘制一个真实、可部署的系统图来显着增加难度。在上一节中，我们要求它绘制一个用文字描述的系统图。现在，我们将要求它从源代码中绘制一个系统图。
绘制真实系统的图更具挑战性，但也更有价值，无论是否使用 AI。真实系统的图可用作可视化文档；它们有助于入门、知识更新、对齐和事件响应。与白板绘图不同，细节是真实的，并且很重要。幻觉是不可接受的。
我们没有使用详细的提示，而是要求 ChatGPT 绘制我们上传的源代码存储库（它无法直接分析链接）。从理论上讲，彻底绘制系统图所需的所有信息都在存储库中。
我想改变一下思路。与其创建我描述的系统的图，我希望你从附加的源代码中生成一个图。虽然在自述文件中嵌入了一个图，但我希望你忽略它，并专注于 “source” 目录中的 CDK 构造和其他代码。请以 mermaid 格式输出。
上面的结果平淡无奇。它有严重的缺陷：
- 解决方案仅以最广泛的笔触呈现。
- 没有关于构造的详细信息，提示明确要求了这一点。
- 不清楚 “common resources” 是什么意思。
这个结果甚至比我们开始时的通用图更有价值。当被问及时，ChatGPT 拒绝进一步详细说明。
也许我们运气不好，或者 ChatGPT 不太适合这项任务。Claud.ai 在给出相同提示时的结果也好不到哪里去：
像 ChatGPT 的图一样，Claud.ai 的图也很模糊和不准确。它理解该解决方案会调整图像大小和进行编辑，但没有显示这是通过 AWS Rekognition 完成的。它凭空捏造了图像压缩和 DynamoDB 的使用，这两者都不是解决方案的一部分。该图的箭头也没有标记，并且在某些情况下渲染错误。
这两个 AI 系统都失败得很惨。虽然我们可以迭代这两个图，但这违背了让 AI 从源代码生成图的目的。
自动生成图表的挑战
为源代码生成图表是一个具有挑战性的问题，而且很明显 AI 还有很长的路要走。至少有三个重大挑战需要克服：
几乎没有训练数据
可部署系统的详细图表在网上几乎不存在。几乎所有公共存储库都是旨在成为系统一部分的代码库，而不是可以独立部署的系统。更糟糕的是，几乎所有这些都没有图表。在线找到的图几乎完全是本文第一节中讨论的那种 “通用” 图。
可部署系统的存储库主要掌握在私人公司手中，它们几乎没有动机发布其内部代码或图表。像 ChatGPT 和 Claude 这样的 AI 几乎没有见过这些图的例子；他们是在盲目飞行。
代码分析
AI 工具必须分析系统代码，而不是纯粹的 “生成” 练习。此输入通常很冗长，从而使分析成本高昂且容易出错。源代码的密度和复杂性也带来了一系列挑战：
- 它通常包含许多语言（配置、HTML、编程、bash 脚本等），AI 必须理解这些语言。
- 配置增加了大量的间接性；AI 必须协商在部署时定义的变量如何在运行时使用。例如，只有通过仔细理解代码和配置，才能收集到计算资源和数据库资源之间的关系。
- 在绘制执行序列图时，代码可以有很多分支路径。大多数都落在图表应重点关注的 “happy path” 之外，而找到该 “happy path” 并不容易。
代码没有描述策略
彻底绘制一个系统的图需要首先了解其目的。图的作者必须知道这一点才能有选择地包括和突出显示最关键的资源、关系和交互（最好使用多个视角）。如果没有这些知识，就没有希望创建信息丰富、连贯的图。
除非在其自述文件中进行了记录，否则此意图不会在代码存储库中。更糟糕的是，如果已部署的解决方案根据其配置具有截然不同的行为，则 AI 无法 知道其意图。
结论
AI 可以在一个相当狭窄的案例中帮助生成图表：为新系统进行白板绘图。但是，使用 AI 创建系统图根本还没有实现。自动更新图表以匹配源代码的梦想仍然遥不可及。
AI 现在是，并且可能永远不会替代人类的调查和学习。正如通常所说的那样，如果你想彻底学习某些东西，请尝试将其教给他人。系统图绘制也不例外：学习不熟悉系统的最佳方法之一是尝试绘制它。你不仅可以通过创建图来学习，而且下一个人将 从 你的图中学习。
有问题或意见？请通过 LinkedIn 或通过电子邮件（billy@ilograph.com）与我联系。