架构师会被 AI 秒了吗？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

接下来，我想强调的是设定唯一且正确的目标，这是架构师生存法则的第一步。在大模型时代，这一点变得更加重要。我给它打了 5 分，表明其重要性。在大模型时代，目标的精确性至关重要。一旦更改目标，就会产生后验成本。大模型的开发涉及大量的训练成本，尤其是生成大量训练数据的成本，这可能非常高昂，有时甚至超过训练本身的成本。在启动大模型项目之前，必须明确你想要解决的问题和目标，清晰定义目标，并确定衡量成功与否的指标。对这些问题的深入思考和明确定义是架构师最大的贡献。

在我们会场中，可能有超过一半的人参与了大模型相关的工作，而大约有三分之一的人可能从事与大模型相关的工作。这表明，大模型领域的参与度相对较高。在进行大模型相关工作时，最重要的是必须设定一个清晰、可量化、可观测且可持续优化的目标。这一点不仅适用于大模型，也适用于任何算法密集型的工作。然而，对于大模型来说，这一点尤其重要。我自己在参与大模型项目的过程中发现，为公司创造最大价值的关键在于清晰地定义目标。我回顾过去可能不够明智的决策时，往往发现问题出在目标设定不够精确上。因此，明确目标是最重要的事情。

法则 3 是在在有限资源下最大化经济价值。在大模型的开发和应用中，成本是一个不可忽视的重要因素。首先，定义目标是至关重要的第一步，因为在大模型的尝试中，成本是非常高昂的。大模型不仅在实施阶段成本不菲，而且在训练样本的准备上也需要大量的投入。此外，训练过程本身的成本也不低。除了训练成本，线上计算成本，也就是进行推理的成本，也会因公司和应用场景的不同而有所差异，但通常来说这也是一个不小的开支。持续运维的成本同样不可小觑，因为随着场景的变化，模型可能会逐渐失效，需要重新训练。在某些情况下，这种情况可能会好一些，但成本仍然是一个需要考虑的因素。

作为架构师，在进行架构设计时，还需要考虑迁移成本。如果你的公司之前没有使用大模型，或者使用的是小模型，甚至是完全基于规则和代码的场景，那么向大模型场景的迁移将涉及巨大的成本。迁移成本包括了从旧系统到新系统的转换，可能还包括了人员培训和重新设计架构等方面的投入。

随着大模型的到来，它们有潜力带来增量收入，这意味着在考虑成本的同时，我们也需要考虑收入。通过与国内外做大模型的朋友们交流，我发现许多公司在投入大模型时并没有充分考虑其经济价值。他们往往是因为看到其他人在做，就跟风投入，而没有深思熟虑大模型究竟能为企业带来什么具体价值，以及这些价值是如何通过大模型创造的，更不用说如何在商业模式和成本结构中实现这些价值了。很多人在没有想清楚这些问题的情况下就进行了投入，这可能导致作为架构师的你在一个错误的决策中浪费了大量的时间和资源，从而未能创造真正的价值。这是架构师在决策时需要深思熟虑的问题。

如果我们作为架构师要考虑投入大模型的决策，我们必须考虑到实施成本、训练成本、计算运维成本以及迁移成本等所有相关成本。在我看来，多数企业应该考虑在大模型上进行投入，因为这些成本随着时间的推移，按照摩尔定律逐渐降低。特别是训练样本的生成成本，由于在许多场景中可以与其他大模型共享，因此训练样本的成本也有可能大幅降低。

从竞争的角度来看，我认为大多数场景下，企业应该对大模型进行投入。原因在于，更大的模型可能对训练样本的数量要求更低，企业可以在较少的数据基础上训练出有效的模型。此外，考虑到潜在的竞争优势，如果你的竞争对手不需要投入大量成本就能实现大模型的价值，而你却因为规模或其他原因无法做到，这将使你处于不利地位。

具体如何实施大模型的投入是一个需要深思的问题。在开始使用大模型时，我们可能会面临诸如“为什么我们需要做这个？”或者“我们的企业规模太小，如何投入大模型？”等问题。在当前的投资环境中，投资者可能对大模型的投入持谨慎态度，这进一步增加了决策的复杂性。

在这个大模型时代，作为架构师，我们需要思考如何创造价值并确保自己不被时代淘汰。我在《架构思维，从程序员到 CTO》一书中提到了一个重要的概念——原子架构，或者说原子价值单元。意思是我们应该从最基本的价值创造单元出发来考虑大模型的投入。原子价值单元首先应该是可识别的功能。在大模型的背景下，这很容易理解，例如一个用户可交互的代理。用户使用这个功能后，我们能够获得一个精确的反馈值。如果无法度量出这样的反馈值，那么这个功能就不是用户可识别的。

最重要的是，我们需要明确大模型能为企业或项目真正创造什么价值。很多人在大模型项目中工作了很长时间，但仍然没有弄清楚这个问题。我们需要识别出大模型项目中最小的原子价值单元，即那些只能通过大模型才能带来的核心能力。只有找到了这个最基本的价值单元，我们才能确保大模型的投入能够为企业带来实质性的价值。在审视许多声称与大模型相关的应用场景时，如果你仔细研究，会发现它们实际上与大模型并没有太大关联。包括我们之前讨论的一些案例，很多场景并不真正涉及大模型，它们可能是基于传统的小模型，或者是传统的其他类型的模型，如 Transformer 架构等。如果你真正意识到大模型可能成为下一代的生产力，那么关键是要在企业中找到能够利用大模型突破的场景。如果选错了场景，再多的努力也可能是徒劳，因为你可能无法找到正确的目标和反馈链路，从而无法实现能力的提升。首先要做的是清晰地认识到，你的企业能通过大模型创造出什么样的独特能力，以及为什么这种能力只能由大模型带来。如果不是非大模型不可，那么很可能有其他成本更低或训练时间更短的途径。

一旦你找到了正确的场景，你可以迅速进行闭环实验。在国内，这是一种很常见的做法。实验不一定非要从头开始自己做，你可以利用现有的 API，比如 OpenAI 的 ChatGPT 或其他模型的 API，先进行尝试，看看是否可行。如果实验结果是肯定的，那么接下来你可以投入到特征工程中，确保你的模型能够最大限度地发挥作用。我们的经验表明，大模型对特征工程特别敏感，因此在这一环节需要做到最好。

接下来，你需要找到最小的原子价值单元，即在最小的场景中使用模型，以最小化总成本。在大模型中，合规性挑战也是一个需要考虑的因素，尤其是在国际上，对大模型的正确性和合规性的挑战可能会更加严峻，这可能是国内外在大模型应用上的一个重要差异。

在当前阶段，进行迁移的成本过高，因此在这个阶段进行迁移并不合理。如果你真的想要实施大模型，最好是在一个全新的场景中开始，而不是尝试将大模型应用到已经存在的场景中。这是因为传统的模型或非模型驱动的场景，如那些基于规则的系统或已经优化很久的小模型，迁移到大模型的成本可能非常高，而且成功的可能性不大。如果你尝试在这些场景中应用大模型，很可能会失败。因此，更明智的做法是寻找一个全新的场景来开发和应用大模型。

对于程序员和架构师而言，大模型时代已经到来。作为架构师，我们的任务是弥补大模型的盲区，并确保它们能够在企业中发挥最大的价值。为了实现这一目标，我们需要关注以下三件事情。

确保有正确的目标：明确你希望通过大模型实现什么，以及这些目标如何与企业的整体战略相匹配。

找出大模型真正能创造的价值：理解大模型的优势和潜力，并确定它们如何为企业带来具体的益处。

找到企业应用场景中的最小价值单元：识别出大模型能够带来的最小且最有价值的功能单元，从这个点开始构建和实施。

从这个基础出发，我们可以更有效地将大模型融入到企业的架构实践中，确保它们能够为企业带来真正的价值。这是我自己的思考，并且我们已经在一定程度上实践了这些理念，认为这是将大模型成功引入企业的最佳路径。