AI 时代的软件架构

在 AI 时代，软件架构应优先追求低认知负担、低上下文成本与强局部可修改性，而不是为抽象而抽象。

从“规范优先”到“理解优先”

过去很多架构优化，本质上是为大规模人类协作服务的：严格分层、提前抽象、统一模板化拆分、复杂扩展点设计。 这些方法在特定团队规模下当然有价值，但副作用也很明显：一个本来直接的问题，被拉成长链路理解任务。

改一个字段，你要先穿过 controller、service、assembler、domain、repository、dto、mapper、converter、facade。 每一层都“看起来合理”，但把它们串起来，你会发现实际修改路径越来越长，信息损耗越来越多。

AI 最怕的不是复杂问题，而是“理解链过长”。

不同模型、上下文窗口、检索工具和任务类型的表现差异很大，不能把 AI 当成一种固定的人格。但在实际协作中，一个规律很实用：边界清晰、相关上下文能在一次任务中闭合的改动，更容易被人和 Agent 一起正确完成。

所以这里说的“理解优先”不是宣布可扩展性失效，而是要求每一层抽象都能减少真实的理解或修改成本。修改路径短，不等于把所有代码塞进一个文件；它意味着读者不必靠猜测跨越无关层级，仍能找到边界、验证结果并理解影响范围。

四个判断标准

1）需求能否在少量文件内闭环

看一个需求，AI 是否能在少量文件内完成从理解到修改再到验证的闭环。 如果每次改动都要横跨十几个文件和多个概念层级，这个结构天然会拖慢 AI，也会拖慢人。

真正的高效架构，不是“层数齐全”，而是相关路径可达、可测试、可解释。

2）目录与模块名是否直接表达业务

auth、order、invoice、comment 这类命名对 AI 非常友好，因为语义密度高、歧义低。 common、base、shared、engine、support、ext 这类命名通常信息密度低，需要额外解释，理解成本会迅速上升。

命名不是美学问题，是检索效率问题，也是修改成功率问题。

3）中间层是否有真实价值

很多项目不是“层多”有问题，而是“空转层”太多：只做调用转发、参数包装、换个名字继续传递。 这些层在图纸上看起来整齐，对 AI 来说却几乎全是噪音。

每一层都应该回答同一个问题：我减少了什么真实复杂性？ 如果答不上来，这一层大概率不该存在。

4）是否允许局部理解后安全修改

如果一个模块内部高度自洽、输入输出清楚、隐式约定少，人和 AI 都更容易稳定工作。反过来，如果任何改动都可能通过隐含规则影响全局，任何协作者都只能变得保守，也更容易误改。

所谓“可维护”，在 AI 时代很大程度上等于“局部可验证”。

防止走向另一个极端

这套原则不是“越简单越好”，而是“在满足演化需求前提下，尽量简单”。

有些复杂性并不是架构师凭空发明的，而是业务天然存在的。例如：

• 多租户隔离
• 插件化扩展
• 多端共享协议
• 大规模并行开发
• 独立部署和版本治理

这些场景下，模块化、边界控制、分层治理依然必要。 区别在于：它们应该服务于降低真实复杂性，而不是服务于“看起来专业”。

一个更实用的架构提问法

每做一个架构决策，都可以先问三件事：

• 这个设计能不能缩短一次真实需求的修改路径？
• 这个抽象能不能减少认知负担，而不是制造新术语？
• 这个边界能不能让 AI 在局部范围内稳定完成任务？

如果答案都是否定的，那它很可能只是形式主义，而不是工程能力。

做决定时，还可以把这三问落到一次真实需求上：需要读哪些文件、修改哪些文件、哪些测试能证明没有越界、失败后从哪里定位。记录几次之后，项目会告诉你问题到底是层数太多、命名太空，还是测试和边界根本没有闭合。

尾声

AI 并不会自动消灭复杂系统，它只会放大结构设计的后果。 结构清晰，AI 就是倍增器；结构混乱，AI 就是噪音放大器。

未来的软件架构竞争，不再只是“谁更会设计扩展点”，而是“谁更能把系统组织成可理解、可修改、可验证的局部单元”。

这不是向工程妥协。 这恰恰是更高水平的工程：让复杂性待在它该待的地方，不要让它扩散到每一次日常修改里。