前言：
随着AI技术的飞速发展，‘AI能否取代软件架构师’这一问题已成为热门话题。今天，我们将一起探讨生成式AI能否取代软件架构师的工作。如果你正在关注AI如何在架构设计中应用，或者有兴趣了解如何将AI技术落地，我作为一名🔧 技术实战派｜AI软硬件一体解决者，可以为你提供更多的实践经验与帮助。欢迎私信我！
正文：
“AI是否会取代软件工程师”一直是2022年及以后技术圈的核心问题。产品经理、图形设计师等角色紧随其后，成为这个话题的讨论对象。今天，我想从另一个角度探讨这个问题——至少对我而言，这构成了这一担忧的核心部分。这个问题是——是否有可能在没有软件架构技能的情况下设计和架构一个大规模复杂的系统？
问题是，当软件工程师担心AI替代时，关注点主要集中在AI能够生成代码（而且往往是相当连贯的代码）这个概念上。但这只是软件创建过程的一小部分。更重要的问题是，AI，尤其是大语言模型，能否生成完整的可用应用程序——或者至少能够指导某人从头到尾创建这样一个系统。
问题被简化为“生成式AI能否取代软件架构师？”尽管，这实际上是想探索生成式AI能否取代架构技能本身。毕竟，软件架构师确实是那些应该知道如何将一切联系在一起，设计出一个可行应用程序的人。同时，根据公司的类型和其他因素，软件架构并不总是与某个特定角色挂钩。软件工程师和开发者在开发软件的过程中也经常进行“软件架构”。一个软件工程师对软件架构的责任，通常与个人的经验水平成正比。经验越丰富，他们的角色就越多地围绕着软件架构展开，而不仅仅是软件的开发。
所以，真正重要的问题不一定是——“我能否用生成式AI来创建一个解决特定问题的代码？”而是——今天我能否用生成式AI来生成一个系统的全面蓝图？这实际上就是架构师和其他相似角色所做的事情。
归根结底，问题是——软件架构师是否不可替代？还是我们只差一个提示，就能被自动化取代？
因此，我做了一个实验……我给了一些大语言模型一个架构问题，看看它们能想到什么，是否能接近你期望一位经验丰富的架构师所能提供的解决方案？
结果有点令人惊讶……
实验设置
我要求四个领先的大语言模型设计一个真实世界系统的架构。我想挑选一个既实际又复杂的系统。我也希望它是一些不太常见的东西。例如，电子商务系统、库存跟踪应用和视频流媒体等常被提及并作为架构练习的示例。我想要一些更独特的东西。所以我为这些大语言模型设定的挑战是：设计一个加密货币交易所的架构。它是一个复杂的领域，涉及高风险、敏感数据、监管要求和大量变动的部分，这正是许多软件架构师喜欢深入研究的问题。
我解决问题的方式是发出一个初步的提示，然后跟进后续提示。这样做是为了模拟我们作为架构师在设计系统时的典型流程。首先，和利益相关者进行初步讨论。通常这些讨论比较模糊，不完全。然后，我们开始深入细节，揭示系统的更多层面。
我从我自己的软件、解决方案和企业架构经验出发，审查了这些回答。接着，我让每个大语言模型评估自己的回答，得到了非常有趣的结果。
我给每个大语言模型相同的提示，后续也问了相同的问题。起点也相同。没有提供额外的背景信息或上下文。
首先，我问了系统的一般架构。
然后，我要求深入探讨一个特定方面（KYC —— 知识你的客户）。
最后，我要求每个大语言模型审查自己的架构并给出评分。正是在这一环节，我收到了大多数令我吃惊的回答。
以下是我按特定顺序发出的提示：
提示 #1
你是一个经验丰富的软件架构师，负责设计一个现代加密货币交易平台的完整架构，类似于Coinbase或Kraken。你的设计必须详细，并考虑技术和商业复杂性。
提示 #2
请用C4符号表示法绘制以下架构图，表示你刚刚描述的服务生态系统。系统景观图、系统上下文图、容器图。请用ASCII画这些图。
提示 #3
让我们聚焦到KYC服务。这个服务的架构考虑因素有哪些，你会如何设计它？请描述一个负责为该服务创建架构的人需要包含的所有内容。不要涉及代码，但要概述构建该服务时的所有技术和非技术考虑事项。
提示 #4
假设你是银行的架构评审委员会成员。审查你刚刚呈现的KYC架构，找出任何空白、风险、缺失部分以及需要澄清的一般事项。
提示 #5
在1到10的评分范围内，10分为最高，你如何评分你刚刚审查过的KYC服务架构？为什么？
参与者
在这个实验中，我评估了：
- ChatGPT-4o
- Claude 3.7 Sonnet
- Gemini 2.0 Flash
- Grok 3（Beta）
每个大语言模型也都得到了一个昵称，旨在大致说明它最接近哪种“架构师角色”。
准备好，开始吧！
提示 #1
你是一个经验丰富的软件架构师，负责设计一个现代加密货币交易平台的完整架构，类似于Coinbase或Binance。你的设计必须详细，并考虑技术和商业复杂性。
目的是了解每个大语言模型如何设计一个复杂系统的端到端架构——包括组件、分层、服务和高层次策略。
ChatGPT：企业解决方案架构师——精致、高层次、充满术语
整体感觉
提供了一个精致的多层架构，清晰地区分了各个领域。将系统划分为7层（客户端、API网关、应用程序、领域、数据、基础设施、运维）。输出结构化且具有咨询级别，但感觉像是一个最终状态的参考模型。
它非常通用，充满了隐含的假设，这些假设应该被明确指出。例如，它建议使用CQRS，但没有解释CQRS是什么以及为什么要使用它。尽管提到了可扩展性、可观察性等架构特性，但它们只是顺便提到，并未深入讨论。
输出部分
• 高层次的业务需求
• 架构概述（7层：客户端、网关、应用、领域、数据、基础设施、运维）
• 领域层（钱包、匹配引擎）
• 数据层
• 基础设施层
• 运维层
• 安全架构
• 可扩展性和性能
• 可审计性和合规性
• 可选增强功能
• 示例技术栈
优点
• 采用高度模块化的方法
• 干净且精致的高层架构
• 提供了架构模式（CQRS、微服务、领域驱动设计），但没有深入说明为什么使用这些模式
• 一些非功能性覆盖（安全性、合规性、可观察性）
• 强调容错和可观察性，尽管没有细节——仅为大致框架
• 在某些情况下提到了技术、合规标准和潜在的第三方/供应商
• 生成了一个高层次的领域边界（微服务）图
缺点
• 太理想化——缺少阶段性实现思维、演化架构以及对许多选择的理由的解释。例如——技术栈
• 实现现实性较轻
• 感觉应该深入一些方面
• 没有提到架构取舍
• 做出了隐含假设，使用了大量术语，却没有清晰说明为什么做出这个或那个架构选择
在架构设计中，我们不仅需要了解技术的基本应用，还要考虑实际落地的可行性和运营维护的需求。如果你有任何关于AI模型训练与应用的问题，或者想了解如何在项目中融合AI技术，随时可以📩 私信我，我会根据你具体的需求提供更有价值的建议。
最佳用途
作为在受监管机构中进行大规模规划时展示参考架构的框架，但需要对架构的每个方面进行深入探讨并考虑其原因和影响。
作为初稿蓝图，帮助你理解涉及的概念是什么。
Claude：顾问——回应RFP
整体感觉
读起来像是对需求文档（RFP——需求提案）的一种回应。与上述的ChatGPT类似，它从一个较远的视角涵盖了所有内容，但没有深度或强烈的观点。缺乏优先级排序或技术顺序。有一个广泛的服务清单，采用了项目符号形式，但缺乏深度的叙述。强调了组件名称，但缺乏深入的联系。
感觉更像是一个面向内部或供应商的需求对接。
输出部分
• 核心组件（用户管理、钱包、市场数据、KYC等）
• 数据存储（关系型、NoSQL、缓存）
• 基础设施与部署
• 安全考虑
• 商业考虑
• API设计
• 部署策略
• 未来考虑
优点
• 涉及了所有主要必要组件
• 同时关注商业和技术领域
• 安全且广泛——在检查清单层面没有遗漏
缺点
• 感觉过于通用，像是模板化
• 没有关于优先顺序、架构特性的深入探讨
• 极少有批判性思维或架构叙事
• 比ChatGPT更为通用。尽管有一些具体技术提到，但很少提到合规标准。
最佳用途
用于内部或供应商间的初步需求对接，目标是生成一个非常广泛的待考虑事项列表，而不深入讨论任何层面。
Gemini：技术产品负责人——将第一想法写在纸上
整体感觉
与Claude和ChatGPT类似，但感觉更加粗略且高层次。在这三者中，它提供了最概括的概述，同时奇怪的是，它在技术方面也给出了最多的具体性。但没有提到为什么使用这些或那种技术。
输出部分
• 整体架构概述
• 核心组件
• 数据存储
• 技术和基础设施
• 安全考虑
• 商业考虑
• API设计
• 部署策略
• 未来考虑
优点
• 简洁明了
• 将大多数信息汇总到每个特定功能领域下，这样更容易理解，而不是将技术或其他考虑事项分开讨论
缺点
• 紧凑且缺乏精致——读起来像是内部文档的纲要
• 最小化的视觉结构或图示
• 即便是初步利益相关者会议，仍需更多的细节
最佳用途
适用于技术产品负责人或解决方案架构师为创建高层架构文档的初步纲要。
Grok：软件架构师——旨在全面覆盖
整体感觉
这感觉像是一个项目的坚实起步。一方面，它足够通用；另一方面，它确实深入一些细节，给出了团队在构建加密货币交易所时需要考虑的关键领域的全面概述。干净地分解为所有关键主题的部分，如功能需求、非功能性需求、风险等。
这是唯一一个明确提到风险和操作问题的版本，同时也明确指出了非功能性需求的重要性。
优点
• 对合规性、隐私、审计和监管准备有很强的理解
• 很好地指出了风险和操作考虑因素
• 清晰地分解了各个部分，按实际项目中处理的顺序进行
• 比其他版本更全面
缺点
• 没有提供业务领域的图示
• 对于没有强大架构领导的团队来说，可能会让人感到不知所措
• 对架构做了一些假设（微服务、事件驱动），但没有解释为什么要使用这些架构或替代方案
输出部分
• 功能需求
• 非功能需求
• 高层架构
• 详细的组件设计
• 安全
• 可扩展性和性能
• 合规性和法律
• 技术栈
• 操作考虑
• 未来扩展能力
• 风险和缓解措施
最佳用途
适用于开始考虑如何构建系统的团队，并且为创建初步的架构文档、将项目拆分为较小的部分以及考虑的关键要点提供高层描述。
提示 #2
用C4符号表示法绘制以下架构图，表示你刚刚描述的服务生态系统。系统景观图、系统上下文图、容器图。请用ASCII画这些图。
目的：评估大语言模型是否能以视觉化的方式组织其思维，并通过创建有用的架构图来展示系统级的推理能力。
✨ ChatGPT
图示清晰，并附有文本描述。
ChatGPT：系统景观图
ChatGPT：上下文图
ChatGPT：KYC容器图
✨ Claude
准确地展示了服务的视觉表示，并详细描述了每个图示的意义。
Claude：系统景观图
Claude：上下文图
Claude：KYC容器图
✨ Gemini
并没有实际绘制ASCII图示，而是提供了PlantUML代码（使用Archimate符号），可以通过PlantUML渲染器来可视化。
✨ Grok
图示整洁且准确，标明了关系，概述了每个图示的目的，并附有详细描述。
Grok：系统景观图
Grok：上下文图
Grok：KYC容器图
提示 #3
让我们聚焦到KYC服务。这个服务的架构考虑因素有哪些，你会如何设计它？请描述一个负责为该服务创建架构的人需要包含的所有内容。不要涉及代码，但要概述构建该服务时的所有技术和非技术考虑事项。
目的：评估每个大语言模型在一个复杂且重视监管的组件（如KYC服务）中，能深入到什么程度。
✨ ChatGPT
• 提供了KYC服务的稳健概述，介绍了其责任。
• 提出了关键的架构考虑因素——尽管这些内容与功能需求交织在一起。
• 简要提到领域数据模型，甚至概述了一个基本的数据库表设计。
• 提到与第三方的集成、可观察性、合规性和监管要求。
• 开始深入API设计，并概述了一个基本的C4容器图。
• 以最终检查清单进行总结，提到了构建和运营该服务的角色。
• 没有提到灾难恢复和业务连续性。
✨ Claude
• 将功能性与非功能性需求区分开，帮助理清了事情的脉络。
• 概述了KYC服务中的子服务。
• 提到了集成模式、部署架构和安全考虑。
• 指出了法规要求和灾难恢复。
• 提到成本，并将其细分为开发、运营和扩展三类，帮助厘清了细节。
• 没有图示。
✨ Gemini
• 提供了非常通用的技术和非技术考虑概述。
• 提到成本，但没有深入探讨。
• 对架构特性和考虑事项提供了稳固概述。
• 没有涉及代码或架构设计、图示等方面。
✨ Grok
• 提供了最全面的KYC架构深入分析——将其划分为多个子服务（生物识别、反洗钱、OCR、评分、案例管理）。
• 涵盖了数据生命周期、监控、部署和监管要求。
• 深入讨论了事件架构和数据库表设计。
• 明确指出了风险和需要进一步详细说明的部分。
• 每个部分都有相当多的细节。
• 清晰区分了功能性和非功能性需求，并对非功能性需求进行了深入剖析。
提示 #4–5（合并）
假设你是银行的架构评审委员会成员。审查你刚刚呈现的KYC架构，找出任何空白、风险、缺失部分以及需要澄清的一般事项。
在1到10的评分范围内，10分为最高，你如何评分你刚刚审查过的KYC服务架构？为什么？
目的：测试大语言模型批判性思考其输出的能力，识别空白，模拟治理/企业级架构评审。
✨ ChatGPT
识别了多个空白和风险，包括：
• 没有提到数据的“真实来源”系统
• 对如何处理GDPR及其他相关法规没有具体说明
• 没有灾难恢复计划和非RTO/RPO目标
• 很少提到审计性，特别是手动工作流过程中的审计问题
• 没有提到使用第三方时的风险
• 测试方法存在空白
最后，提供了额外的建议。
评分：ChatGPT给自己的评分是7.5/10。
ChatGPT对其架构的评价是：
“KYC服务架构在概念上强大，并且为现代快速发展的加密平台提供了良好的结构，但要达到银行级别的环境，还需要解决关键的合规性、运营和安全性空白。”
该架构涵盖了大多数正确的技术和功能模式，特别适用于一个优化市场时间和模块化的技术驱动、加密原生产品。
然而，从金融机构的角度来看——在这里，KYC不仅是合规性问题，更是法律责任、审计风险和声誉保障——该架构存在以下不足：
✨ Claude
• 清晰地划分了空白/风险类型：技术、合规、运营。还提到了关键的空白。
• 提到培训和专业技能差距，这一点非常重要，但通常被忽略。
• 清楚指出了哪些领域需要澄清。
• 包含了改进建议。
• 总体上，简洁明了的评审，没有过多细节。
评分：Claude给自己的评分是7/10。
Claude对其架构的评价是：
“该架构提供了一个强大的基础，但在实施前需要解决这些空白，特别是在考虑到加密货币交易所KYC流程的高监管要求和金融风险时。一个良好的KYC系统（7/10）与优秀的系统（9–10/10）之间的差距，通常体现在这些细节上，这些细节能确保合规性、运营卓越性以及强大的防欺诈能力。”
✨ Gemini
提供了相当详细的空白和缺失部分评审，包括：
• 数据驻留和保留政策
• 同意管理
• 边缘案例处理
• KYC工作流的手动审核
• 缺乏清晰的审计性
• SLA（服务水平协议）
• 灾难恢复和业务连续性
• 数据训练——这在很多情况下被忽略
• 数据、合规性、第三方风险
• 变化中的法规
• 没有明确识别出不同部分的责任
Gemini提到的大多数关键空白和风险都得到了详尽解释，足够一个团队开始解决这些问题。Gemini还提到了整体评估总结和一些详细的建议。
评分：Gemini给自己的评分是6/10。
Gemini对其架构的评价是：
“本质上，初始提案展示了对KYC服务的基本组件和考虑事项的良好理解。然而，它缺乏足够的深度和具体性，我们不能自信地将其视为一个适用于受监管金融机构的强大生产架构。它提供了一个扎实的基础（因此评分为6），但需要大量工作来完善细节，解决已识别的空白和风险，并提供关于安全性、合规性、可靠性和运营效率所需的保证。在我们可以将其视为更高评分的架构之前，需要一个更详细的蓝图。”
✨ Grok
• 提供了比其他大语言模型更为详细的自我评审。
• 其他大语言模型提供的是通用概述，Grok深入分析了每一个空白和风险，并建议了改进的行动方案。
• 提供了详细的分析，解释了为什么给出这个评分——而不是给出更高或更低的评分。
• 提出了改进计划。
评分：Grok给自己的评分是6/10。
Grok对其架构的评价是：
“这份KYC服务架构获得6/10的评分，得益于其强大的技术基础、合规意识和以用户为中心的功能，但在合规性细节、运营成熟度、安全性强度以及第三方依赖管理方面存在显著空白。这些缺陷在银行环境中尤为关键，因为监管审查和安全性要求至关重要。通过解决已识别的问题，架构可以发展成为一个强大且合规的解决方案，适用于在银行监管下运营的加密货币交易所。”
提示逐一回顾表
总结 — 这意味着什么？
在我得出结论之前，必须强调这个结论应当谨慎对待。毋庸置疑，我的分析、结果和解释都是主观的，可能会有偏差。
此实验过程中，存在许多因素，由于大语言模型处理和输出的非确定性，你可能会得到不同的结果，即使是使用完全相同的提示。
此外，大语言模型正在不断微调和重新训练。它们在不断演进。因此，今天它们给我的答案，三个月后可能会大不相同。
考虑到这些因素——我即将得出的结论，仍然像是某种真实的状态——至少在这一时刻是如此。
尽管我所进行的分析极其有限，但它确实反映了如果某人没有任何架构经验，他会经历的过程。
此外，在我的分析过程中，我提了一些问题，如果我今天没有这些经验，我可能根本不会想到要问。
正如每个有经验的软件工程师和架构师所知道的那样，从零开始构建一个系统，既是一门艺术，也是一门科学。
老实说？有时候，它更像是艺术。
在构建这样的系统时，你需要考虑的细节极其复杂，几乎让人难以承受。要想在一、两次或三次尝试中掌握这些细节，几乎是不可能的。
你如何架构一个系统——实际上，如何架构任何系统——是通过一个既有结构又无结构的发现、调查、演变和实验过程。如果你没有架构经验，或者不知道如何以架构师的方式思考，你就不知道应该问哪些问题。
你可以问第一个问题——例如：“我如何构建XYZ系统？”作为产品负责人、业务分析师、工程副总裁、业务利益相关者、软件工程师等。
然而，知道接下来该去哪里，就会变得非常具有挑战性。
事实上，我敢打赌，如果你经历了这种类型的练习——向你最喜欢的大语言模型询问系统设计——你可能从未想到要问它这个简单却极其有力的问题：“你自己架构中的空白是什么？”
这就是问题所在。软件架构以及成为一名软件架构师，并不仅仅是知道所有答案。它真正的核心是知道什么时候、为什么以及如何提出问题。
带着这个思维进行实验，让我有了两个清晰的印象：
📍 并不意外的是，通常来说，大语言模型提供了类似的结果。 我预料到这些回答会非常高层次。我并没有指望看到许多关于架构取舍的讨论，也没有期待深入探讨那些架构特性，除了可扩展性、弹性和可观察性。
📍 让我感到意外的是Grok的表现。 它更详细、自我批评，深入探讨了其他模型没有涉及但应该探讨的领域。它并不完美，远远没有，但它展现了更多的深度、自我意识和对现实世界系统设计中杂乱无章现实的探索。
甚至它的自我批评——给自己打了6/10——也算是一个积极的信号。批判自己设计工作的能力是许多经验丰富的架构师都在挣扎的问题。
在所有的大语言模型中，Grok脱颖而出。
那么，这将我们引向哪里？
至少目前，生成式AI不太可能在短期内取代架构师。这是我的看法，当然，你可以不同意。
架构并不仅仅是创建一个图表或为业务利益相关者制作一个展示。它更关乎于图表背后那些批判性、反思性、迭代性的思维。这仍然是一个人类的技能。
然而，关键是，未来属于那些能够适应的人。
软件架构师不会被AI取代。
但他们可能会被那些比任何人都更了解如何使用AI的架构师所取代。
经过这次实验，虽然AI能够辅助架构设计，但完全取代架构师仍面临许多挑战。如果你想深入了解如何利用AI优化你的系统架构，或者在实际项目中如何落地AI技术，我🚀 专注用10年工程经验 + 商业认知，赋能AI产品从概念到落地，可以为你提供专业的技术支持与咨询。📩 学AI？做AI项目？买AI训练推理设备？欢迎关注私信。