AI做架构设计到底行不行?我拿一个真实场景试了试

上周有个朋友问我一个问题：他们公司的核心系统要从单体架构拆微服务，团队吵了三周没吵出结论，问我有没有什么建议。

我没法给建议。不是客气，是真的给不了。每家公司的业务边界、数据耦合程度、团队能力、历史包袱都不一样。我连他们的核心表有几张都不知道，随口给的建议大概率是害人。

但挂完电话之后我做了一件事——我把他描述的场景、约束条件和纠结点整理了一下，丢给了AI。两个小时后，我手上已经有一份完整度不低的架构方案初稿，里面的很多取舍维度，是我凭自己的经验未必能第一时间想到的。

这件事让我再次确认了一个这两年越来越强烈的感受：大多数人对 AI 的使用，放错了位置。

AI 被放在了价值链的末端

如果你观察身边的同事怎么用AI，大概率是这样的画面：写一个函数、补全一段代码、生成一段SQL、重构一个方法。这些当然有用，但它们有一个共同特征——都发生在研发流程的最后一个环节。

然而带过团队的人都有体感：真正决定项目成败的，往往不是代码写不出来，而是方案没想清楚。

需求到底应该怎么拆？边界应该画在哪里？技术选型到底用A还是B？这些问题如果在前期没有收敛清楚，后面写再多代码都是在错误的方向上狂奔。

在我有限的观察里，一个项目如果出了问题，80%的原因都可以追溯到方案设计阶段的某个决策。但现在绝大多数团队让AI参与的，恰恰只是剩下那20%的编码工作。

这就像你雇了一个见过上万份建筑图纸的顾问，结果只让他帮你搬砖。

为什么 AI 反而适合做架构设计

很多人对此的直觉反应是：架构设计需要经验和判断力，这不是AI擅长的事吧？

这个直觉对了一半。架构设计的最终决策确实需要结合业务理解、团队能力、组织架构这些只有人才掌握的信息。但架构设计的前期工作——信息收集、模式归纳、方案比较、约束梳理——这些恰恰是大语言模型极其擅长的事情。

想想看，一个架构师在做技术选型时真正在做什么？他在脑子里检索自己接触过的项目、读过的文章、踩过的坑，然后在这些经验的基础上做比较和判断。

问题在于，一个人的经验再丰富，能接触到的案例也是有限的。而AI训练数据里包含的论文、开源项目、技术博客、架构案例的数量，远远超过任何一个人一辈子能读完的。当你把你的具体约束告诉它，它可以迅速把这些积累映射到你的场景上。

在你不精通的领域，这种信息优势尤其明显。 我自己做后端出身，对前端架构了解有限。但当我把一个前端技术选型的问题交给AI，它给出的候选方案和比较维度，比我硬着头皮查三天资料要系统得多。

一个实际的例子：微服务拆分方案

回到开头那个朋友的问题。我把他的情况整理了一下，核心是这样的：一个跑了五年的电商单体系统，日订单量开始逼近瓶颈，团队想拆微服务，但在怎么拆、先拆哪块、拆到什么粒度上吵得不可开交。

我没有直接问AI给我一个微服务拆分方案。这么问只会得到一个泛泛的、教科书式的回答。

我做的是把场景讲清楚：系统的核心模块有哪些、哪些模块之间数据耦合最重、目前的性能瓶颈出现在哪个环节、团队有多少人、技术栈是什么。

AI的反应很有意思。它没有马上给方案，而是先反问了一串问题——这串问题本身就很有价值：

你们的数据库是共享的还是各模块有独立数据源？现有的模块间调用是同步还是异步？拆分的主要驱动力是性能瓶颈、团队独立交付，还是两者兼有？对服务间一致性的要求是强一致还是最终一致？

这些问题不是随便问的。每一个问题的答案，都会把架构方案引向完全不同的方向。共享数据库和独立数据源，决定了你是走数据库先拆还是服务先拆的路线。驱动力是性能还是团队独立性，决定了拆分的粒度和优先级。

在核心系统领域摸爬滚打多年的人都清楚，这种识别关键分叉点的能力，过去至少需要一个做过两三次类似项目的资深架构师才具备。

几轮对话之后，AI整理出了一份需求规格，把前面的回答归纳成了几个维度：拆分驱动力、数据耦合热力图、团队结构约束、一致性要求、运维成熟度。同时它还标出了几个没定清楚的问题——比如监控体系是否就绪、CI/CD 管线能否支撑多服务部署、团队对分布式调试的经验如何。

接下来是关键一步。我没有问应该用哪个方案，而是让它给出多个候选方案并比较。

它给了三套方案。不是三个名字，是三套从拆分策略到数据迁移路径到团队分工都拆清楚的方案：

一套是绞杀者模式，在外层搭一个API网关，逐步把流量从单体切到新服务，适合风险敏感、希望平滑过渡的团队。优势是回滚容易，劣势是过渡期要维护两套代码。

一套是领域优先拆分，先按DDD的方式重新划分限界上下文，把耦合最少的模块先切出来。适合数据耦合不算严重、团队对领域建模有一定基础的情况。

还有一套更激进的——数据先行，先把共享数据库按领域拆成独立数据源，服务拆分跟在后面。适合数据耦合是核心痛点、但团队有足够的数据库运维能力的场景。

每套方案都附带了适用条件、典型风险、团队投入估算，甚至在每个候选方案里都引用了对应的开源实现和行业案例——比如哪些公司在类似规模下用了哪种路线、踩了什么坑。

最后它没有说选A或者选B，而是给了一条条件化的决策路径：如果数据耦合是主要瓶颈且DBA团队成熟，偏向数据先行；如果团队对微服务运维经验不足、更看重稳定过渡，走绞杀者模式；如果领域边界本身就比较清晰，领域优先拆分的投入产出比最高。

说实话，这个输出的完整度让我吃惊。不是说它的每一个判断都一定对——最终拍板当然还是要结合内部那些AI看不到的信息。但作为一份方案讨论的起点，它已经比很多真实项目中花两三周调研出来的初稿要好了。

让 AI 进入架构设计的几个要领

从这个例子往回看，我自己摸索出了一些让AI在架构设计中发挥更大价值的做法。

场景信息的完整度，直接决定了AI输出的质量。 很多人对AI的输出不满意，根源其实是自己的输入太模糊。你问它我应该用什么架构，它只能给你一个不痛不痒的回答。但当你把业务场景、数据规模、技术约束、团队能力这些信息交待清楚，它的输出精度会有一个质的飞跃。

不要一上来就让它给唯一答案。 如果你直接问最优解，AI往往会给你一个看起来四平八稳但没什么特别的方案。更好的做法是让它先铺开方案空间——给我两到三套候选方案，把各自的适用条件和权衡说清楚。这样你拿到的不是一个答案，而是一张决策地图。

让它主动补充行业实践和开源实现。 这一步非常关键。当讨论从我觉得应该这样做变成业界在类似场景下是怎么做的，方案的可信度和深度都会上一个台阶。AI接触过的案例数量远超个人经验，这是它最大的杠杆所在。

围绕具体的取舍维度逐轮收敛。 成本、复杂度、可维护性、团队学习曲线——每一轮对话都围绕一个具体的 trade-off 展开，让方案从发散逐步走向收敛。这个过程有点像你面对一个经验丰富但并不了解你业务的外部顾问，你在和他一起把问题想清楚。

真正变化的，不只是写代码的速度

说到这里，我真正想表达的判断其实只有一个。

现在行业里讨论AI对研发效率的影响，关注点大多还在编码速度提升了多少倍、代码补全准确率到了多少这些指标上。这些当然重要，但它们衡量的只是价值链末端那一小段的效率。

真正开始松动的，是研发流程中更靠前的那些环节。 从需求澄清，到技术选型，到架构设计，到方案比较——这些过去高度依赖资深架构师的个人经验、需要耗费大量时间做调研和讨论的工作，现在已经可以由人和AI协作完成。

而且在很多个人并不精通的领域，AI的参与反而能让方案质量更高。这不是因为AI比人聪明，而是因为它见过的案例数量实在太多了，它能把你没接触过的方案空间铺开给你看。

这让我想到一个类比。工业革命时代，最先拉开差距的工厂不是那些用蒸汽机驱动更多纺锤的——那只是把旧流程加速了。真正拉开差距的，是那些用蒸汽机重新设计了整条生产线的。

AI对研发流程的改变，可能也是类似的逻辑。把它放在编码环节，你得到的是一个更快的程序员。把它推到架构设计环节，你得到的是一个不一样的研发流程。

未来真正稀缺的，不是写代码的能力——这个在AI时代正在快速贬值。稀缺的是问对问题的能力：知道该收集什么信息、该比较哪些维度、该在哪些分叉点上做取舍。而这恰恰就是架构设计的本质。