对于一名架构师，最能让其感到兴奋的词汇莫过于“重构”。只要有重构的需求，就意味着有工作可做。

　　在大模型时代，全球范围内的大模型正在重新定义软件的面貌。在当前的世界正在重新定义软件的背景下，作为架构师应该如何应对？面临哪些机会和挑战？这些都是本演讲想要探讨的主题。

　　本文由 InfoQ 整理自 QCon 北京 2024 主论坛演讲 《大模型时代的架构思维》，经郭东白老师授权发布。以下为演讲实录：

　　本演讲将从大模型讲起，分析大模型的本质及其影响；然后我们将探讨大模型如何影响软件研发，以及它对软件架构的冲击是什么；最后将讨论我们应该如何应对这些挑战和冲击。这是一个清晰的逻辑过程：首先理解问题，然后制定应对策略。

　　大模型的基本原理很简单：你有一套训练数据，通过训练生成式模型，产生许多候选样本，然后人工挑选出较好的内容。接着，使用验收模型将人工挑选的过程自动化。这样一来，我们就形成了一个从生成式模型到验收模型的完整过程。当这个过程上线后，就可以形成一个循环，使得模型能够持续学习和进步。

　　大模型的突破之处在于其处理大量数据的能力，这使得它能够涌现出类似语义理解的能力。这让我们可以感觉到，大模型似乎能够在完全不同的语境中，甚至是跨越传统意义上的语言界限，实现近乎无损的语义转换。这就是大模型突然变得如此热门的原因。

　　事实上，我在一年前就已经在网易的一次演讲中提到了这些观点。我认为这个逻辑非常强大，它解释了为什么大模型对我们程序员或者说我们这个行业的冲击是最大的。大模型的冲击并不在于我们现在讨论的各种应用，而是在于它改变了传统软件开发中的角色。在传统软件中，生成式模型和验收模型都是由程序员和测试人员来完成的。但现在，生成式模型和验收模型都变成了机器模型，这就改变了程序员的位置。

　　如果你有一个从需求到代码，再到测试的映射过程，并且这些过程都能够进行自洽性验证，那么你可以在多种语言、不同的编译环境、测试环境和运营环境中形成多次约束，确保整个语义系统的正确性。这就是我们所说的闭环，而这个闭环在我们的领域是第一个形成的，它是一个非常强的语义闭环。因为它所施加的约束是严格的：代码要么无法运行，要么运行结果与预期验证结果不一致，这些都是容易出现的错误。在大模型出现之前，我们已经能够进行许多自动化测试，包括半自动化和半智能的测试。而大模型的出现使得测试过程变得更加迅速。拥有了这种能力之后，我们需要重新审视程序员的价值所在。如果产品和用户能够利用生成的文档来完全验证开发过程，那么在许多情况下，程序员的角色可能变得多余。

　　从今天的角度来看，我去年写的幻灯片其实已经完全成为事实了。图灵测试已经通过，人类的简单意图可以在代码层面上做到无损，而且成本低了很多，提高了好几个数量级的速度。

　　对于程序员来说，我们正处于不同的时代轮换中。在大模型时代到来时，它应该成为主要的生产力。就像马车时代马的重要性一样，在汽车时代汽车成为主要生产力，在大模型时代，大模型就是为该场景提供主要生产力。这意味着，并不是说大模型要取代所有人，而是如果一个人加上一个模型就比三个人快，那就已经很好了。就像汽车和马车一样，马在当时也是非常重要的生产力。我还记得之前举过的例子，直到现代社会发明蒸汽机之前，马一直具有很高的价值。在不同的社会中，马的价值是人的价值的三倍。如果某样东西的价值是你的两倍，那么它必然会取代你。这是一个非常有意义的观点。

　　接下来我想谈谈大模型对软件研发的影响。在我的极客时间架构课程和书中，我描述了传统软件研发中架构师的角色，通常被限定在一个相对较小的范围内。实际上，一个真正的架构师应该拥有更广阔的视野，考虑的因素应当包括人员、目标、经济价值、环境、过程控制以及文化等多个方面。

　　当我们进一步审视这个问题时，我们可以思考 AI，特别是大模型，对这些架构要素的影响程度。在这些架构要素中，哪一个会受到最大的影响？在进行大规模的架构活动，比如重构时，我们必须为这个活动设定一个明确的目标。这个目标定义了我们努力的方向和期望达成的成果。我们需要明确这个目标是什么，并考虑如何衡量成功与否。

　　人性是一个极其重要的元素，正如韦青老师之前提到的，它在架构中扮演着关键角色。人性涉及到参与者，包括目标用户的人性。这些因素会如何影响你的软件架构呢？此外，软件架构始终是一个成本问题，在任何企业中，成本都是不可忽视的因素，还有当前的计算软件环境。

　　我的评估是，大模型对我们最大的冲击在于成本方面。这种冲击可能会持续今后几年。人们关注大模型并不仅仅是因为它们有趣，而是因为它们能够以更低的成本完成工作。例如，在数据标注任务中，与传统的人工标注相比，使用大模型来生成样本的成本更低，而且生成的样本与人工标注的样本具有相同的价值。这就使得人工标注变得不再必要，大模型的引入成为了一种替代人工的过程。

　　从能力的角度来看，大模型对传统架构师的影响是客观存在的。我之前已经分享过相关的幻灯片，今天我们再次审视这个问题，即大模型的到来到底对哪些方面产生了冲击。其中，红色标记的部分显示，代码交付这一环节受到的冲击最为严重，这种冲击不仅限于未来，而是已经从现在就开始了。

　　在当前的软件开发环境中，即使是像兼职架构师这样的角色，也需要进行进度沟通等工作。然而，这些工作的价值已经不如以往。因为现在我们可以通过代码自动生成的总结来更准确地了解代码的改动情况，这种自动化的总结比人工编写的总结更为可靠。它能够清晰地展示出具体的代码更改，而不仅仅是描述完成了哪些任务。

　　在整个软件开发过程中，越是偏向个体研发的能力，受到的冲击就越大。换句话说，那些依赖于单兵作战的开发工作，如编写代码、调试等，更容易被自动化工具和智能系统所取代。而越往下，即越偏向于对整个开发场景的控制和管理，这些工作受到的冲击相对较小。

　　当我们意识到这些冲击必然会发生时，作为架构师或至少是决策者，我们应该采取什么行动呢？我们是与软件架构相关的独立决策者，我们应该考虑做些什么？

　　首先，我们需要思考我们要做什么决定，必须清楚我们到底是为企业创造了什么价值。我们需要分析出我们的价值，并在之前创造的价值不再存在时重新定位。作为架构师，真正的价值创造来自于弥补其他人决策盲区，这一点非常重要。你之所以被认为是架构师，是因为你能看到别人看不到的东西。

　　在大模型时代，我们必须认真思考：大模型时代是否存在决策盲区？这些决策盲区在哪里？大模型的出现是否会导致新的决策盲区？举例来说，钉钉正在研究 AI 模型，这些模型涉及数千个人工智能代理和人类之间的网络配对。例如，他创建了成千上万个这样的配对。在这些配对中，你该如何应对？你在这种情境下如何改变自己在这个新的决策环境中，你能弥补的盲区的价值定位是什么？我认为最重要的一点是，当前的大模型无法回答的问题。

　　大模型的盲区就是架构师创造价值的所在。实际上，关于我在《架构思维，从程序员到 CTO》这本书中提到的每一个架构要素，大模型都无法回答。第一个要素是大模型不知道你要解决什么问题。比如你要开发一个操作系统或做一个 AI 代理，你要解决什么问题是别人无法知晓的，作为架构师必须清楚地知道你的商业目标是什么。同样，人性方面，大模型的引入会改变某些人性机制。我们本来具有怎样的人性？现在突然引入大模型，会影响我们的人性。尽管大模型本身可能不具备人性，但是它的引入会给企业软件开发带来人性挑战。开发人员会怎么想？用户会怎么想？用户可能并不关心软件是由程序员编写还是由大模型生成的，但是企业人员可能会关心。经济价值会发生何种变化？收入和成本会发生巨大变化，因为作为架构师，你组织的架构活动中最大的成本是人力和时间。有了大模型，这两个成本都会发生巨大变化。你应该如何应对这些变化？还有环境和各种过程，我就不一一赘述了，但这些都是大模型无法回答的问题，因为大模型不了解你的工厂、你的企业，或者你的架构活动需要处理什么事情。因此，作为架构师，我们有机会为整个企业注入最佳的相关决策。

　　大模型对软件架构师的冲击很小，甚至会可能带来更大的市场需求。面对大模型可能带来的盲区，我持乐观的态度。尽管我的判断可能不完全准确，但我个人认为大模型对架构师职位的冲击相对较小，反而可能会带来更多的需求。在过去，一个拥有 100 多名员工的企业可能只需要两到三名架构师。但在将来，架构师的需求可能会增加，尽管与此同时，与架构师合作的程序员数量可能会减少，比如只有 10 到 15 人。这种情况可能导致架构师的角色变得更加普及，不再像以前那样是一个特殊的职业。但这并不意味着架构师的传统职责就消失了。

　　正如我们在之前讨论的中提到的，架构师的职责依然存在，包括确保架构活动有正确的目标、构建符合人性的架构等。这些职责在大模型时代仍然至关重要。

　　作为架构师，我们需要思考在这个时代中如何定位自己的工作。我们需要继续遵循那些在大模型时代之前总结的生存法则，这些法则至今仍然基本正确。例如，架构活动必须有一个正确的目标，这是任何架构师工作的基础。同时，我们也需要考虑到构建没有人性考量的架构可能会面临的挑战。在大模型时代，架构师的角色和职责可能会发生变化，但他们的核心价值和重要性仍然不变。在有限的资源下最大化经济价值的重要性。虽然不敢说 100% 肯定，但我对此有很高的信心。毕竟，企业需要盈利和承担支出，我们的目标始终是最大化企业的经济价值。此外，软件架构必须适应环境的需求，这一点不会因为大模型的出现而改变。

　　接下来，我想强调的是设定唯一且正确的目标，这是架构师生存法则的第一步。在大模型时。