AI给了我们无限可能，但架构师的职责是做“减法”

嗨，大家好，我是技术老金。

最近的技术圈，弥漫着一种“AI功能狂热”。似乎任何产品，如果不加上点“大模型赋能”的标签，就好像落后了一个时代。

在之前的几篇文章里，我们聊了很多关于个体开发者如何应对的话题：从AI如何重塑我们的开发流程，到老程序员的经验和“代码品味”为何变得更加重要，再到我们该如何与AI这个“虚拟实习生”高效协作。可以说，我们基本解决了个人层面“如何用AI”的问题。

AI代码生成：是解放生产力的“银弹”，还是架构师的“新噩梦”？

你的AI“实习生”为何总是带不动？我们犯了3个“管理”上的致命错误

但一个新的、更棘手的问题，已经摆在了所有架构师的面前：当AI给了我们几乎无限的可能性时，我们到底该做什么？

我最近和好几个一线团队的技术负责人聊天，发现一个非常普遍的现象：团队开始陷入一种“AI功能的狂-热”之中。很多团队把一个原本清晰的系统，硬生生堆砌成了一个功能冗余、成本飙升、难以维护的“缝合怪”。

这让我开始思考一个更深层次的问题：当AI给了我们几乎无限的“可能性”时，我们架构师的核心职责，到底是什么？

今天，老金想聊聊我的看法：在AI时代，架构师最重要的职责，不是“做什么”，而是“不做什么”。我们的核心价值，正在从“加法”转向“减法”。

一、警惕AI时代的“自助餐陷阱”

AI技术，就像一场极其丰盛的自助餐，各种“山珍海味”（GPT-4, Claude 3, Sora, …）琳琅满目，每一样看起来都很好吃，都想尝一尝。但如果你毫无节制地把它们都装进盘子，最终只会导致消化不良。

在架构设计中，盲目地做“加法”，会让我们掉进至少三个陷阱：

1. 成本陷阱：你以为的“免费午餐”，背后都是昂贵的账单

最顶级的LLM调用，成本是极其高昂的。很多团队在项目初期，为了快速验证一个“酷炫”的demo，直接调用最强的模型。功能上线时看起来很美，但当用户量一上来，看到后台的API账单时，脸都绿了。

这就好比，你为了解决“最后一公里”的通勤问题，选择天天打专车。虽然体验好，但成本完全不可持续。一个理性的架构师，会先评估一下，我这个问题，是不是用“公交车”（传统的算法）或者“共享单车”（小模型、规则引擎）就能解决？而不是无脑地把所有问题都抛给最昂贵的“专车”。

2. 复杂性陷阱：每多一个AI模块，系统就多一个“薛定谔的猫”

传统的软件模块，输入是确定的，输出也是确定的。但LLM不一样，它的输出具有“不确定性”。它可能会有“幻觉”，会一本正经地胡说八道；它的响应延迟，可能忽高忽低。

你每在系统里增加一个AI节点，就等于增加了一个“黑盒”。当系统里这样的“黑盒”越来越多时，整个系统的行为就变得难以预测。出了问题，你甚至都不知道是哪个环节的“幻觉”导致的。运维和调试的难度，呈指数级上升。

3. 价值陷阱：你做的功能，到底是“刚需”还是“鸡肋”？

这是最致命的陷阱。很多团队做的所谓“AI功能”，脱离了业务的核心价值，纯粹是为了“AI而AI”。比如，为一个内部的文档编辑器，增加一个“用莎士比亚的风格润色”的功能。这听起来很有趣，但它真的为用户创造了不可或缺的价值吗？还是只是一个能让产品经理在发布会上吹嘘两分钟的“痒点功能”？

“脱离业务谈架构都是耍流氓”，这句话在AI时代，比任何时候都更加重要。

二、架构师的“减法”心法：如何保持清醒？

既然盲目做“加法”如此危险，那我们作为架构师，该如何修炼“减法”的内功？老金认为，要从三个层面入手。

1. 减掉“可能性”的噪音，回归问题本质

AI给了我们100种解决问题的可能性，但架构师的职责，是找到那个唯一值得被解决的问题。

在立项之初，我们就要反复追问自己和团队：

• 我们要解决的，究竟是一个真实存在的、高价值的业务痛点，还是一个我们臆想出来的“伪需求”？
• 引入AI，是能带来10倍的效率提升，还是仅仅提升了10%？如果只是10%，那这个投入产出比是否值得？

学会对那些酷炫但非核心的“可能性”说“不”，是架构师走向成熟的第一步。

2. 减掉“技术”的傲慢，选择合适的“武器”

我们很容易陷入一种“技术迷恋”，觉得最新的、最复杂的，才是最好的。但一个资深架构师的标志，恰恰是懂得“杀鸡焉用牛刀”。

• 需要从文本中提取固定格式的信息？一个正则表达式，可能比LLM快100倍，还便宜1000倍。
• 需要做一个简单的意图分类？一个传统的、经过良好训练的机器学习模型，可能比通用大模型更准确、更可靠。

架构师的工具箱里，不能只有LLM这把“锤子”。我们的价值，在于拥有一个丰富的“武器库”，并能根据战场环境，选择最合适的那一件。

3. 减掉“黑盒”的恐惧，设计可控的系统

对于那些我们评估后，确实必须引入的AI模块，我们也不能任由其成为一个完全失控的“黑盒”。架构师必须通过设计，来为它套上“缰绳”。

• 隔离： 将AI模块封装在独立的微服务里，与其他核心业务逻辑解耦。即便它出了问题，也不会“污染”整个系统。
• 监控： 对AI模块的输入、输出、成本、延迟建立起完善的监控和告警体系。
• 熔断与降级： 当AI服务出现故障或响应超时，系统能自动熔断，并降级到一个基础的、可靠的（甚至可以是人工的）处理逻辑上，保证核心业务不受影响。
• 人工介入环路： 对于高风险的决策，必须设计一个“人工审核”的环节，让AI的建议，成为人类专家的“副驾驶”，而不是“自动驾驶”。

老金总结

在软件开发的早期，架构师的价值，体现在用“加法”构建起复杂的系统。但在AI时代，当技术本身变得空前强大和唾手可得时，架构师的核心价值，正在悄然转变。

我们的角色，正从一个“技术方案的实现者”，转变为一个“商业与技术风险的评估者”，一个“系统复杂度的控制者”。

AI给了我们一片洋洋大海，但我们的船，装不下所有的鱼。学会“减法”，懂得取舍，知道自己该驶向何方，不该驶向何方，这，或许才是未来架构师，最稀缺，也最宝贵的价值所在。