AI 越强,架构思维越值钱

写给一类人:想法多、手速不够快,不想当码农,想当指挥 AI 写代码的架构师。 你是将军,AI 是你的兵。这篇文章告诉你将军要学什么。

核心认知:为什么 AI 越强,架构思维越值钱?

先说一个反直觉的事:AI 写代码的能力越强,你的实现能力反而越不重要,但你脑子里那些“上层的判断”不仅没贬值,还升值了。

为什么?因为代码生成的瓶颈已经不在”打字”上了,在”需求清楚不清楚”和”架构合理不合理”上。一句话说不清的需求,AI 写出来一定跑偏;一个乱糟糟的架构,AI 再聪明也只能在烂地基上盖歪楼。

打一个比方。AI 是一个执行力极强但没有战略判断力的士兵。你告诉他”把那个山头拿下来”,他能迅速冲锋;但如果你连”哪个山头”“为什么要拿”“拿下来之后守不守”都没想清楚,他冲得越快,全军覆没得越快。

所以你的核心竞争力变成了三样东西:

1. 拆解能力:把一个大目标拆成一连串没有歧义的小任务。
2. 判断能力:看懂 AI 产出的东西,知道它在什么场景下是对的、什么场景下是错的。
3. 兜底能力:当系统出问题时,你有排查的方向感,不至于完全依赖 AI 去”猜”。

下面七层知识,就是围绕这三样东西展开的。

第一层:系统思维与问题分解(你最该练的内功)

这是整篇文章里最值钱的部分。能不能当好将军,关键看你能不能把一场仗拆成几次战斗。

1.1 什么是”系统思维”

系统思维就是:看到一个需求,你脑子里自动浮现的是模块、边界、数据流向,而不是”先写哪个函数”。

举个例子,有人跟你说”做一个博客系统”。不懂架构的人会直接开始写页面。懂架构的人脑子里先过一遍:

• 谁在用? 作者(写文章)、读者(看文章)、管理员(审核)。
• 核心数据是什么? 文章、评论、用户、标签。
• 数据怎么流动? 作者创建文章 → 草稿 → 发布 → 读者看到 → 评论产生 → 通知推送。
• 边界在哪? “发布”这个动作,意味着从”草稿状态”变成”公开状态”,这就是一个业务边界。

这种能力不是靠背书来的,是靠反复练习”看到任何东西,先画分解图”练出来的。

1.2 怎么练分解能力

给你一个实操方法,叫“输入-处理-输出”拆解法。拿到任何需求,强迫自己回答三个问题:

1. 输入:这个系统/功能接收什么信息?来自谁?格式是什么?
2. 处理:拿到这些信息后,系统要做哪些事情?有哪几步?每一步的规则是什么?
3. 输出:处理完之后,产出什么?给谁?以什么形式给?

只要你能把这三件事说清楚,你就能把任务交代给 AI,而且 AI 大概率不会跑偏。

1.3 一个判断标准:你拆得够不够好?

好的分解有一个特征——每一个小任务都是可以独立验证的。也就是说,AI 做完这一小块,你能单独测它对不对,不需要等整个系统拼起来才知道。

如果你发现某个任务”做完了也不知道对不对,要等别的部分也好了才能看”,说明你拆得还不够细,或者模块之间的耦合太紧了。这本身就是一个信号,提醒你重新划边界。

第二层:架构模式与设计原则(你和 AI 之间的”通用语言”)

你不需要能从零手写出每一种设计模式,但你必须能听懂、能选择、能判断。因为这些概念是你和 AI 沟通的”术语表”。

2.1 为什么这一层对你特别重要

想象两种指挥方式。第一种:“你帮我做一个东西,用户登录以后能看到自己的订单,还能搜索。”第二种:“这个系统分认证模块和订单模块,认证用 JWT,订单模块对外提供 REST 接口,搜索走独立服务,认证和业务之间用中间件解耦。”

同样的意思,第二种方式 AI 产出的质量会高一个量级。因为你用了精确的架构语言,消除了大部分歧义。AI 不用猜你想要什么,它可以把精力花在实现上。

所以这一层的核心不是”会写”,而是”会说”。

2.2 必须掌握的几组概念

下面这些是你脑子里必须有的”词汇表”,按重要性排序:

分层架构(最基础) 一个系统通常分三层或四层:表现层(界面/API)、业务逻辑层、数据访问层。每一层只和相邻的层打交道。这个概念能帮你判断 AI 给的代码”是不是把数据库操作直接写在页面逻辑里了”——这是新手最常见的错误。

关注点分离(Separation of Concerns) 一个模块只做一件事。认证的归认证,发邮件的归发邮件,别搅在一起。这个原则帮你判断 AI 的产出”是否合理地分了模块”。

SOLID 原则(五个字母,一个核心思想) SOLID 不需要你背全名,你只需要记住它的灵魂:“代码要写得容易扩展、容易修改,而不是每次加功能都要大改”。具体来说,当你 review AI 的代码时,问自己一个问题——“如果下周要加一个类似的新功能,这套代码是能平滑扩展,还是要推翻重来?”如果答案是后者,说明设计不够好。

单体 vs 微服务 这个你目录里那篇微服务文章讲得很细。你只需要记住一句话:别一上来就拆微服务,单体能扛就先用单体。微服务是用来解决”团队太大、模块太复杂”的问题的,不是用来解决”技术更先进”的问题的。一个人或者小团队,微服务带来的运维负担远大于收益。

2.3 常见架构风格,知道有哪几样就行

你的目标是:看到任何业务场景,能快速判断”这大概该用什么风格”,并且能跟 AI 说清楚。

第三层:技术选型与判断力(选什么、为什么选它)

将军不用亲自造枪,但要知道什么枪适合什么战场。

3.1 选型的底层逻辑

技术选型不是”选最新的、最流行的”,而是要回答四个问题:

1. 这个技术解决的问题,和我的需求匹配吗? 很多时候一个流行框架是为特定场景设计的,你的场景未必一样。
2. 它的学习成本和维护成本我能承受吗? 一个你不熟悉的技术,AI 能帮你写,但你出问题的时候排查不了,这就是隐患。
3. 生态成熟吗? 有没有文档、社区、插件?出问题能不能搜到答案?冷门技术 AI 生成的代码质量也差,因为训练数据少。
4. 它会不会被淘汰? 选一个三年后还在维护的技术,降低长期风险。

3.2 你要有判断力的几个关键决策点

语言/运行时:选一个”AI 最擅长、生态最成熟”的。目前 AI 生成质量最高的是 TypeScript/JavaScript 和 Python,因为训练数据最多。如果你没有特殊理由,优先选这两个,你出问题时也更容易在网上找到答案。

数据库:绝大多数业务场景,关系型数据库(MySQL/PostgreSQL)就够了。不要被”大数据”“NoSQL”带跑偏——你的博客、订单系统、管理后台,根本到不了需要分库分表的数据量。PostgreSQL 是一个很好的默认选择,功能全、可靠、AI 也很熟。

前端框架:React 和 Vue 是两大主流,生态都足够成熟。选哪个不重要,重要的是别频繁换。选定了就深挖,别这个项目用 React 下个项目用 Vue,你的精力有限。

部署方式:初期用最简单的——一个云服务器跑起来就行。不要一上来就搞 K8s、Docker Swarm 那一套复杂编排。等你真的需要伸缩、需要多环境的时候再升级。

3.3 一个反模式:过度选型

vibecoding 的人最容易犯的错:看到什么技术都觉得”好酷,我要用”,于是项目里塞了一堆新技术,结果每个都用不深,出问题的时候哪个都查不动。

记住:你的技术栈越精简,你的掌控力越强。 三个技术用到极致,好过十个技术都用皮毛。

第四层:需求规格化与精准表达(指挥 AI 的核心技能)

这一层是你和传统架构师最大的区别,也是你的”杀手锏”。

传统架构师写代码,所以他们对”怎么表达需求”没那么讲究,反正自己写。你靠 AI 写,所以你表达需求的能力,直接决定了 AI 产出的质量上限。

4.1 为什么精准表达这么重要

AI 不会读心术。你给它的指令有多模糊,它的产出就有多不确定。同一个功能:

• 模糊版:“做一个用户登录。” → AI 会按最通用的方式实现,大概率和你的实际需求有出入。
• 精准版:“做一个用户登录功能,用邮箱+密码,后端用 JWT 签发 token,token 有效期 7 天,登录失败要提示具体原因(邮箱不存在/密码错误),前端要有加载状态和错误提示。”

第二个版本,AI 几乎能一次性给你可用的代码。差别在哪?你把边界、规则、异常情况都交代清楚了。

4.2 一个需求规格模板

以后给 AI 下任务,套这个模板,保证产出质量稳定:

[功能名称] 一句话说清这个功能是什么

目标:这个功能要解决什么问题、给谁用

输入:用户/系统提供什么信息(字段名、类型、约束)

处理逻辑:分步骤描述,每一步的规则写清楚
  1. ...
  2. ...
  3. ...

输出:成功时返回什么、失败时返回什么、界面怎么展示

边界情况:列出你能想到的特殊情况
  - 输入为空怎么办
  - 重复提交怎么办
  - 权限不够怎么办

技术约束:用什么框架、什么数据库、遵循什么规范

你可能会觉得”这么细,写规格的时间都够自己写代码了”。但你不是自己写,你是让 AI 写——你花十分钟写清楚的规格,AI 能在几十秒内给你可用的代码;你省了这十分钟,AI 给你一堆要改十次的代码,你反而要花一个小时来回返工。

4.3 一个关键习惯:先写”验收标准”

在下任务之前,先问自己:“这个功能做成什么样,我才算满意?” 把答案写下来,这就是验收标准。

验收标准的价值在于:它是你和 AI 之间的”合同”。AI 交付后,你拿着验收标准一条条对照,没达到就打回重做。这比”感觉不对”要高效一百倍。

第五层:代码审查与质量判断(AI 写的代码,你得看得懂)

AI 帮你写代码,不代表你可以不看代码。不看代码的指挥官,一定会被战场上的假情报坑死。

5.1 你需要看懂到什么程度

你不需要逐行读懂每一行语法的细节,但你需要能回答这几个问题:

• 结构对不对:代码有没有按层分开?有没有把数据库操作、业务逻辑、界面代码搅在一起?
• 命名清不清楚:变量名、函数名是不是一看就知道在干什么?乱起名字的代码,后面一定出问题。
• 有没有明显的安全隐患:密码明文存储了没有?用户输入有没有做校验?有没有直接拼接 SQL?
• 错误处理到不到位:出了异常,系统是崩溃了,还是优雅地报了个错?
• 有没有重复:同样的逻辑是不是在好几个地方重复出现?如果是,说明该提取成公共函数。

你看的时候不需要纠结语法对不对(语法错了跑不起来,自然会报错),你要盯的是结构和质量。

5.2 几个高频”AI 坑”,特别留意

AI 写代码有几个常见的毛病,你要特别警惕:

1. 过度设计:AI 有时候会给你塞一堆”看起来很专业”的抽象层、接口、设计模式,但其实你的场景根本不需要。简单直接才是好的。
2. 假实现:有时候 AI 会写一个函数,逻辑看着对,但关键步骤是”假装完成了”——比如返回一个写死的数据,而不是真的去查数据库。一定要看它是不是真的实现了。
3. 忽略边界情况:AI 写的”快乐路径”通常没问题,但空值、重复、并发这些边界情况,它经常忘记处理。
4. 用了过时或不存在的 API:AI 会”幻觉”出一些根本不存在的函数或库。代码能跑起来但行为不对的时候,先查这个。

5.3 一个实操技巧:让 AI 自己解释

你看不懂某段代码的时候,不要硬啃。直接问 AI:“这段代码做了什么?为什么这么写?有没有更简单的写法?”让 AI 给你解释,然后你判断它的解释合不合理。这是”用 AI 审查 AI”,比你一个人对着代码发呆高效得多。