AI时代,架构师的角色定位

现在让 AI 根据需求生成一张系统架构图，很快就能得到初稿。方框、箭头、分层、配色都有，再补一份设计说明，看起来也像那么回事。

到了评审会上，问题才变得具体：“这个服务为什么要独立拆出来？”“接口的并发量是怎么估算的？”“这部分需求，我们到底做还是不做？”图上有一个组件，和知道为什么需要它，是两回事。

架构设计说到底，是为了满足特定需求，把系统拆分成部件，并约定它们怎样协作。AI 可以参与分析、提出方案，也可以帮忙画图。方案是否合适，还得放回业务和团队的实际情况里判断。

定义系统、做技术取舍、推动方案落地，一直都是架构师的工作。AI 带来的变化，是方案和代码生成得更快了。设计依据、验收标准和验证方法如果没有跟上，未经确认的假设也会更快地进入实现。

在这种工作方式下，架构师需要把以下四个方面的工作做得更扎实。

AI 可以参与整个过程，架构师需要确认依据、取舍和验证方式

AI 很擅长生成一份看起来完整的设计规格：系统怎么划分、接口长什么样、数据用什么结构，都能写出来。但架构师仍然要回答一个问题：这条边界凭什么划在这里？

一份能落地的设计，至少要说清五件事：系统如何切分、接口如何约定、数据如何定义、规模按多大来设计，以及哪些需求明确不做。

最后的“不做清单”往往最考验判断。业务方不断增加需求，如果没有明确范围，系统就可能被迫承担越来越多的职责。哪些当前不做，哪些交给其他系统，最好在设计时就谈清楚。

边界同时说明系统承担什么，以及当前不承担什么。

AI 可以帮忙比较不同的划分方式，但“这个模块要不要独立成服务”“峰值流量按十万还是百万估”，都需要真实依据。架构师要分清哪些条件已经确认，哪些仍是假设，再通过评审、实验和实际运行检查方案。

划清边界也离不开与业务方沟通。业务方希望功能上线，架构师需要解释：为了支撑这个功能，系统要付出什么代价？团队有多少人，积累了哪些技术债，运维能不能兜住，都会影响最后的选择。AI 可以协助分析，前提是这些信息被准确地提供出来。

这也是使用 AI 时容易忽略的地方。条件没有交代清楚，它可能自行补齐，再据此生成一整套实现。架构师需要尽早把这些假设找出来，别等代码写完，才发现双方想的根本不是一回事。

做架构设计，大致要走四步：吃透需求并划定范围、找同类系统做参考、定下顶层结构、抓住主要矛盾反复迭代。其中容易被轻视的，是找参考这一步。

以前，搜集资料要花不少时间。现在 AI 能很快列出技术路线和参考案例，但回答里也可能混入不存在的中间件版本、查无实据的性能数据，或者听起来合理却未经验证的架构模式。说得笃定，未必就有依据。

核验信息本来就是架构师的职责。候选方案和参考结论可以成批生成以后，这项工作需要做得更细：哪些是查到的事实，哪些是推断，哪些还要验证？

关键选型结论，要追到一手来源，例如官方文档、源码或案例团队的原始记录。性能数字要问清测试条件。拿不准的关键假设，先做针对性的最小验证，再决定是否投入完整实现。

来源可信，还要检查条件是否适用。

查证还不够，得看适用条件。一个真实存在、成功运行过的方案，也未必适合自己的项目。业务规模、团队配置和可靠性要求不同，采用同一种技术，可能要承担完全不同的成本。

AI 可以协助查证和实验。架构师要判断的是，现有证据是否足够支持选型。搜集资料省下来的时间，正好可以用来把这些依据查扎实。

AI 时代，总体设计文档还要不要写？要。尤其不能漏掉决策依据。

一份设计文档，除了需求，技术部分至少要讲清四件事：设计意图、整体结构、部件职责，以及做过哪些权衡。AI 可以协助整理，但权衡的来由，需要真实的讨论和验证记录来支撑。

为什么选了 A 方案而不是 B？放弃 B 的代价是什么？这个决策依赖哪些假设，又留了什么退路？这些“为什么”，需要参与决策的人提供或确认。

系统会演进，写代码的人也会换。三年后有人问“这个设计当时为什么这么做”，如果文档里只有结构和职责，他还是得重新猜一遍。

设计文档一直有保存技术记忆的作用。AI 让文档更容易写得完整，也更需要留意：里面的理由到底来自当时的决策，还是事后补出来的解释。一个理由听起来合理，不代表团队真的按这个理由做过选择。

有了讨论记录、实验结果和备选方案，AI 也能帮助整理“为什么”。架构师要确认记录准确，还要写清什么变化会促使团队重新评估。后来接手的人才能知道，原来的选择什么时候仍然成立，什么时候该调整。

留下当时的依据，后续团队才知道何时沿用、何时调整。

架构师原有的六样本事仍然有用：能写代码能落地、逻辑抽象能力强、紧跟技术前沿、能把业务需求翻译成技术需求、知识面广、会沟通。AI 参与工作以后，要考虑怎样把这些能力用好。

实现能力。 可以让 AI 承担部分编码工作，但架构师仍要看懂实现，判断关键路径是否可靠。质量检查也不能全靠一个人逐项亲审，评审、测试和验收标准都要安排好。必要时，仍然得亲手写原型、查代码、做实验。

逻辑抽象。 类、接口、模块依然需要抽象，现在还要把目标拆成 AI 能执行、结果能检查的任务。每一步完成什么，依赖什么，产出什么，怎样算通过，先说清楚，后面才能安排执行和交接。

跟进新技术。 AI 能帮忙整理更多信息，但选型还是要看项目需要。什么值得用，什么可以再等等，什么只是概念炒作，都得有自己的判断。新名词出现得快，团队没有必要每个都追。

业务需求翻译。 业务说“希望系统更快”，要进一步明确哪些请求慢、慢到什么程度、期望改善多少。问题说清楚，AI 才容易沿着合适的方向工作。结果是否可靠，还要看信息是否充分、实现是否经过验证。

知识面。 要补上对 AI 能力边界的理解：在自己的工作里适合用它做什么，容易在哪些地方出错，哪些结果需要检查。如果项目本身包含 AI 功能，再进一步研究模型选型、检索增强、微调、智能体，以及推理时延和成本。用 AI 辅助开发，与设计 AI 应用，是两个相关但要求不同的场景。

沟通能力。 团队要约定哪些工作交给 AI，哪些结果由谁确认，出了问题怎样交接。业务方的预期也要谈清楚。代码生成得快，不代表测试、集成和上线验证就能省掉，架构师需要把整个交付过程的投入讲明白。

还有两项围绕 AI 的工程能力值得补上。学到什么程度，要看它在项目中承担多少工作。

一是编排 AI 任务流。 任务拆解回答“每一步做什么”，编排则要安排执行顺序、上下文和任务状态的传递、工具失败后的恢复，以及什么时候停止或转人工。设计 AI 应用时，还可能涉及模型选择、智能体的决策范围和降级路径。这些安排要由程序和运行环境执行，不能只写在提示词里。

二是懂数据、会评估。 用 AI 辅助开发，要看究竟节省了多少时间，检查和返工又花了多少。设计 AI 应用，则要考虑业务数据对效果的影响，选择有代表性的样本，检查任务完成情况、错误、时延和成本。一个漂亮的指标还不够，得看样本和评估方法能不能反映实际使用中的问题。

原有能力仍然有用，补哪些 AI 能力，要看项目需要。

划清边界、核验参考依据、记录决策的来由，都不是 AI 出现以后才有的职责。当方案、文档和代码都能快速生成时，架构师更需要确认这些内容是否符合业务需求、团队能力和设计约定。

边界为什么这样划，参考结论适不适用，取舍基于什么，质量怎样验证，这些问题仍然要回答清楚。AI 可以参与分析和执行，架构师要组织团队把依据查实，把验证做完。

还没有确认的假设、已经接受的风险，以及失败后的恢复办法，也要留下记录。以后业务和团队发生变化，大家才能据此调整设计。这样，AI 节省下来的时间，才不会又花在返工上。

AI 探索不迷路，关注我不走弯路