名称AI阶途现在有一种越来越流行的观点代码都可以让 AI 写了系统没必要再做那么复杂的分层。反正 AI 写的代码AI 自己也能理解。这个观点听起来很有道理。既然写代码的主体正在从人逐渐变成 AI那么过去为了方便程序员阅读、维护和协作而设计的软件架构似乎也应该被弱化。甚至有人认为未来的代码只要能运行就够了至于 Controller、Service、Domain、Repository 这些分层不过是传统软件工程时代遗留下来的形式主义。但这个判断忽略了一个关键问题AI 会写代码不等于 AI 可以无成本地理解任意代码。AI 同样受到上下文窗口、Token 成本、注意力分配、信息噪声和推理稳定性的限制。更重要的是AI 降低的是“生成代码”的成本而不是“理解复杂系统”的成本。恰恰相反当代码生成速度大幅提升后结构混乱、边界模糊和技术债失控的速度也会同步提升。所以AI 时代不是不需要架构而是更需要架构。架构设计正在从过去的“人类协作规范”逐渐变成人与 AI 共同遵守的“系统协作协议”。一、AI 降低了写代码的成本却放大了结构混乱的代价过去一个开发人员一天可能只能完成几百行有效代码。因此即使项目架构不够合理技术债的积累速度通常也是有限的。开发人员在写代码的过程中还会自然地进行思考、重构和调整。AI 改变了这一点。今天一个开发人员借助 AI可以在很短时间内生成几千行甚至上万行代码。这意味着原本需要几个月才会形成的结构问题现在可能几天就会出现。AI 很擅长解决明确、局部、边界清晰的问题例如实现一个接口编写一个数据转换函数完成一个查询方法补充测试用例根据现有模式扩展一个功能。但当任务涉及多个模块和多个层次时如果没有明确的架构约束AI 很容易选择“当前最省事”的实现方式。例如在 Controller 中直接查询数据库在 Repository 中加入业务判断在工具类中保存业务状态在接口层直接调用第三方服务为了完成一个功能顺手修改多个无关模块将大量逻辑堆积在单个文件中重复实现已经存在的能力为了解决局部问题破坏全局设计。这些代码通常可以运行甚至短期内看起来开发效率很高。但随着 AI 不断生成新代码系统会迅速变成一种“高速增长的意大利面结构”。所以AI 时代真正的风险不是 AI 写不出代码而是AI 写代码太快而系统缺少足够强的约束。过去没有架构规范技术债是缓慢积累。现在没有架构规范技术债可能是指数级增长。二、架构分层首先是一套给 AI 使用的约束机制软件架构过去主要用于解决人的问题让团队成员理解系统明确不同模块的职责降低协作冲突控制修改范围方便测试和维护。AI 时代这些价值依然存在但又多了一层新的意义架构是约束 AI 行为的护栏。例如一个系统明确规定Controller 只负责协议转换、参数校验和响应组装Application Service 负责编排业务用例Domain 层负责业务规则Repository 只负责数据访问Infrastructure 负责数据库、消息队列和第三方系统跨模块调用必须通过公开接口禁止业务层直接依赖具体数据库实现。那么 AI 在生成代码时就有了明确的行为边界。我们可以直接告诉 AI在 Application 层实现创建订单用例不允许直接访问数据库。业务规则放入 Domain 层。数据持久化通过 OrderRepository 接口完成。不得修改其他模块的内部实现。这样的任务对 AI 来说是清晰的。相反如果系统没有层次、没有模块边界、没有依赖约束那么每次让 AI 修改代码都需要重新解释整个系统。而且即使解释了AI 也可能因为上下文不足或者注意力偏移选择一个局部合理、全局错误的实现。因此规范化架构并不是用来限制 AI 的能力而是让 AI 的能力能够稳定、可控地释放。三、分层能够显著降低 Token 成本在 AI 编程时代软件架构不仅是一个技术问题还是一个直接的经济问题。高质量模型的调用成本依然不低。模型能力越强输入和输出 Token 的价格通常也越高。企业一旦大规模使用 AI 编程代码上下文将成为持续性成本。如果一个系统大量功能集中在少数几个巨型文件中例如OrderService.java 5000 行 UserController.java 3000 行 CommonUtils.java 8000 行 DatabaseHelper.java 4000 行那么即使只修改一个很小的功能AI 也可能需要读取大量无关代码。例如用户只是要求修改订单取消时的退款判断规则。但因为退款判断、订单状态、数据库访问、日志记录和第三方支付逻辑全部混在一个文件里AI 可能需要读取几千行内容才能判断修改位置。这些上下文中的大部分内容与当前任务没有直接关系。但它们依然会消耗 Token。更严重的是AI 编程工具经常会在多轮对话中重复提交上下文。同一个巨型文件可能在一次任务中被多次发送给模型第一次分析问题时发送生成修改方案时再次发送修复编译错误时再次发送补测试时再次发送Code Review 时再次发送。一个原本只需要理解几十行代码的任务最终可能消耗数万甚至数十万 Token。而规范化分层可以大幅减少这种浪费。例如订单系统拆分为order/ ├── api/ │ └── OrderController.java ├── application/ │ └── CancelOrderService.java ├── domain/ │ ├── Order.java │ └── RefundPolicy.java ├── repository/ │ └── OrderRepository.java └── infrastructure/ └── JpaOrderRepository.java修改退款规则时AI 通常只需要读取CancelOrderServiceOrderRefundPolicy相关测试这样输入上下文更小Token 消耗更低模型注意力也更加集中。所以分层并不只是为了“代码好看”。它实际上决定了 AI 编程的单位任务成本。架构越清晰AI 完成一个功能所需加载的上下文越少。上下文越少Token 成本越低响应速度越快结果也越稳定。这是一笔非常现实的企业级经济账。四、上下文窗口再大也不能替代良好的架构有人会说现在模型上下文窗口已经很大了几十万甚至上百万 Token将来整个项目都可以一次性交给 AI。这个判断容易混淆两个概念AI 能不能读取这些代码AI 能不能稳定理解这些代码。上下文窗口变大只代表模型可以接收更多信息不代表模型可以对所有信息保持同样精确的注意力。当上下文越来越大时会出现几个问题。1. 有效信息被无关信息稀释一个任务真正相关的代码可能只有 200 行但上下文中包含了 2 万行代码。模型需要从大量噪声中找到真正相关的部分。信息越多不一定越准确。很多时候模型不是因为“看不到代码”而出错而是因为“看到的无关代码太多”。2. 跨文件关系更容易判断错误当模块边界不清晰时AI 需要自己推断哪个方法才是正确入口哪段逻辑是真正的业务规则哪个字段是权威数据哪些代码是历史遗留哪些代码可以修改哪些代码虽然相似但不属于当前业务。上下文再大也无法弥补系统语义不清晰的问题。3. 多轮任务仍然会重复消耗上下文即使一个模型拥有百万 Token 上下文AI 编程也不是一次性问答。真实开发过程通常包括理解需求分析代码制定方案修改代码运行测试分析错误修复问题进行评审。每一轮都可能重新加载相关代码。因此架构的价值不只是“让代码能放进上下文窗口”而是让每一个开发步骤都只需要最小必要上下文。五、分层让 AI 可以局部理解、局部修改AI 编程最大的优势之一是可以高效完成局部任务。但前提是系统本身能够被局部理解。一个好的模块应该具备以下特点职责明确输入输出清晰依赖关系有限修改边界明确可以独立测试不需要理解整个系统才能修改。例如一个订单价格计算模块如果拥有清晰的接口public interface PricingService { Money calculate(Order order, PricingContext context); }AI 在修改价格规则时只需要理解OrderPricingContextPricingService当前价格实现相关测试它不需要了解用户登录逻辑消息推送逻辑数据库连接配置HTTP 请求解析页面展示其他无关业务。这就是“可局部理解”。而如果价格计算逻辑分散在 Controller、SQL、工具类和配置文件中那么任何一次修改都可能变成全局分析。分层清晰时我们可以把 AI 任务限制在一个明确范围内只修改退款策略模块。不修改订单创建流程。不调整数据库表结构。不改变现有接口。所有新增规则必须通过现有测试并补充新测试。任务范围越明确AI 的结果越可预测。这也降低了 AI 修改无关代码的风险。六、AI 时代仍然需要人工代码评审“代码由 AI 生成”并不意味着“代码可以自动上线”。至少在当前阶段大多数企业都不会放心让 AI 生成的生产代码跳过人工评审直接部署到线上。原因很简单。AI 生成的代码可能存在边界条件遗漏权限漏洞数据越权并发问题事务问题性能问题安全隐患业务规则误解异常处理不完整日志泄露敏感信息与现有设计不一致修改范围失控。这些问题很多并不是编译器或者单元测试可以完全发现的。因此生产级开发仍然需要人工 Review。而代码是否具备清晰的层次会直接影响 Review 的效率和质量。如果一个 AI 提交的功能修改涉及20 个文件3000 行改动多处重复逻辑Controller 中加入 SQLRepository 中加入状态判断公共工具类中加入业务规则那么审查者很难判断修改是否完整是否影响其他功能业务规则是否一致是否隐藏了副作用哪些改动是必须的哪些改动只是 AI 顺手重构的。相反如果架构边界清晰一个业务需求可能只修改一个用例服务一个领域策略一个仓储接口实现两组测试。审查者可以快速聚焦于真正的业务变化。所以架构设计不是为了让 AI 看懂代码而是为了让人能够审查 AI 写出的代码。在未来很长一段时间里软件开发很可能形成这样的协作方式架构师或高级开发设计边界和契约AI 与普通开发人员完成实现高级开发人员负责评审和最终责任。在这种协作模式下架构就是最重要的人机协作协议。七、AI 初级开发人员会让架构约束更加重要过去团队中的初级开发人员通常由高级开发人员带领。高级开发人员会通过代码评审架构讲解结对编程开发规范示例代码逐渐帮助初级开发人员理解系统。AI 出现之后团队协作模式发生了变化。未来越来越常见的模式可能是高级开发人员设计系统初级开发人员通过 AI 快速完成大量实现高级开发人员集中负责架构和评审。这会极大提升代码产出速度但也带来新的风险。初级开发人员可能并不完全理解 AI 生成的代码。当 AI 给出一个“能运行”的方案时他们往往倾向于直接接受。如果系统没有明确的架构规范那么 AI 可能持续生成局部合理但全局错误的代码而初级开发人员缺乏足够能力发现问题。最后高级开发人员面对的将不是少量代码而是大量已经写完、已经耦合、甚至已经上线的技术债。因此AI 时代的架构规范必须比过去更加明确。不能只写一句请遵循良好的软件设计原则。而应该给出可以执行和检查的规则例如API 层禁止直接访问数据库领域层禁止依赖基础设施层跨模块只能调用公开接口一个功能只能拥有一个权威业务规则实现新增外部依赖必须封装适配器单个文件不得超过合理规模禁止在公共工具类中加入业务逻辑修改必须附带对应测试AI 不得修改任务范围外的模块发现架构冲突时先提出方案不得自行绕过。这些规则既是给开发人员看的也是给 AI 看的。八、架构能够降低 AI 误改无关代码的风险AI 修改代码时一个常见问题是修改范围扩大。例如用户只是要求给订单增加一个取消原因字段。但 AI 可能同时修改数据库实体修改订单 DTO调整接口参数修改前端展示重构订单状态枚举顺便统一命名删除它认为没有使用的字段修改多个测试更改异常处理方式。其中一些改动可能是必要的但另一些可能是 AI 自己推断出来的。如果代码结构混乱AI 很难判断真正的边界。因为所有代码互相依赖一个小修改天然会扩散到多个位置。清晰架构则可以提供明确的变化路径。例如API DTO ↓ Application Command ↓ Domain Entity ↓ RepositoryAI 可以沿着固定路径进行修改。而其他模块如果没有直接依赖就不应该被影响。架构实际上帮助 AI回答了三个问题这个需求应该修改哪里这个需求不应该修改哪里修改后需要验证哪些范围这三个问题比“代码能不能写出来”更重要。九、AI 让重写代码更便宜但前提是边界足够干净AI 的确降低了重构和重写的成本。例如我们可以让 AI将 JDBC 实现改为 JPA将 REST 接口改为 gRPC将某个模块从 Java 迁移到 Kotlin将同步调用改为事件驱动将本地缓存替换为 Redis将旧版 SDK 替换为新版 SDK将单体中的某个模块拆分成独立服务。但这些工作的难度取决于现有系统是否拥有清晰边界。如果数据库访问全部封装在 Infrastructure 层那么更换数据库实现相对简单。如果外部支付服务通过适配器调用那么更换支付渠道也相对简单。如果核心业务规则位于 Domain 层那么接口协议和存储方式变化时业务逻辑可以保持稳定。相反如果 SQL、业务逻辑、接口转换和第三方调用混合在一起那么 AI 所谓的“快速重写”并不会真的轻松。它仍然需要阅读大量代码推断隐含关系识别重复逻辑判断哪些行为不能改变处理隐藏副作用修复大量回归问题。AI 可以降低机械性改写成本但不能自动消除糟糕架构带来的复杂性。换句话说AI 让可替换的模块更容易替换但无法让原本不可替换的代码自动变得可替换。十、架构是为测试和验证服务的AI 生成代码后如何证明它是正确的不能只看代码写得是否漂亮也不能只看能否编译。必须依赖验证体系单元测试集成测试契约测试回归测试静态检查安全扫描性能测试架构规则检查。而一个系统是否容易测试与分层质量直接相关。如果业务逻辑依赖数据库HTTP 请求全局变量静态工具类当前时间第三方接口消息队列那么测试一个简单规则也可能需要启动整套系统。AI 虽然可以帮助生成测试但无法改变代码本身难以测试的事实。清晰分层能够将业务逻辑与基础设施隔离。例如一个退款规则public RefundResult calculateRefund( Order order, CancellationReason reason, LocalDateTime cancelTime )这样的代码可以被 AI 快速生成测试也可以被人快速审查。如果退款规则隐藏在 Controller 中并且同时依赖数据库、用户上下文和第三方接口那么测试成本会高得多。AI 时代会生成更多代码因此也必须建立更强的自动验证体系。而架构分层是自动验证能够成立的基础。十一、架构还是系统知识的压缩方式一个大型软件系统包含大量业务知识。如果这些知识只存在于具体代码细节中那么每次理解系统都必须重新阅读大量实现。好的架构可以把系统知识压缩到几个稳定概念中。例如一个电商系统可以被描述为订单模块负责交易生命周期库存模块负责库存锁定与扣减支付模块负责支付与退款履约模块负责发货和交付营销模块负责优惠计算各模块通过事件或公开接口协作。这样的模块划分本身就是一张系统认知地图。无论是新员工还是 AI都可以先理解地图再进入局部代码。如果没有架构AI 每次都要从代码中重新推断系统结构。这会产生两个问题每次推断结果可能不同AI 推断出来的结构未必符合真实业务。因此架构不只是代码组织方式也是对业务知识的显式表达。对 AI 来说明确的架构文档、模块说明、领域词汇和依赖规则相当于高密度、高质量的上下文。它比直接给 AI 喂几万行代码有效得多。十二、AI 时代不只是需要代码分层还需要上下文分层传统软件架构主要关注代码结构。AI 编程还需要关注另一种结构上下文结构。未来一个 AI 友好的项目不应该让 AI 每次都从整个仓库中自行寻找信息而应该提供分层的上下文。例如项目级上下文说明项目目标技术栈总体架构模块关系全局约束安全要求禁止事项。模块级上下文说明模块职责对外接口依赖关系核心领域概念常见扩展方式测试方式。任务级上下文说明本次需求修改范围禁止修改范围验收标准相关文件需要执行的测试。这种上下文分层会比单纯扩大上下文窗口更加有效。因为 AI 真正需要的不是“更多信息”而是“正确的信息”。从这个角度看未来的软件架构文档不仅服务于人也将直接服务于 AI。十三、架构规范应该能够自动执行而不只是写在文档里过去很多项目都有架构文档但实际代码并不遵守。原因是文档只是一种软约束。AI 时代单纯依赖文档更加危险。因为 AI 每次生成代码时都可能选择最直接的实现路径。因此架构规范需要尽可能转化为机器可执行规则。例如使用 ArchUnit 检查 Java 分层依赖使用依赖规则禁止 Domain 引用 Infrastructure使用 lint 规则限制 Controller 中出现数据库调用使用目录权限限制 AI 修改范围在 CI 中检查循环依赖限制单文件规模和函数复杂度检查跨模块调用是否通过公开接口为外部服务定义契约测试要求每次 AI 修改都生成影响范围说明要求 CI 自动检测越层调用。例如可以定义规则domain 不得依赖 application domain 不得依赖 infrastructure application 可以依赖 domain infrastructure 可以实现 domain 中的接口 api 只能调用 application这样即使 AI 生成了违反架构的代码也无法通过 CI。真正可靠的架构不是“希望 AI 遵守”而是“AI 不遵守就无法合并”。十四、但是规范化不等于过度设计讨论到这里很容易走向另一个极端既然 AI 时代需要架构那是不是所有项目都应该使用完整 DDD、六边形架构、CQRS、事件溯源和微服务答案是否定的。AI 时代需要的是清晰边界而不是更多形式。过度分层同样会增加 AI 成本。例如一个简单的查询功能如果被拆成Controller Request DTO Command Command Handler Application Service Domain Service Repository Interface Repository Adapter Entity Aggregate Mapper Assembler Response DTO那么 AI 每次修改一个字段都可能需要同步修改十几个文件。这不仅增加 Token 消耗也增加理解和维护成本。一些项目为了形式上的“解耦”为每一个类都创建接口为每一个调用都增加一层代理为每一个对象都创建多个 DTO。结果是系统看起来很规范实际却充满样板代码。AI 可以快速生成这些样板但样板代码依然会消耗上下文增加文件数量增加修改范围增加评审负担隐藏真正的业务逻辑。因此AI 时代的合理原则不是“分层越多越好”而是刚在边界柔在内部。所谓“刚在边界”是指这些位置需要严格约束核心业务与数据库之间核心业务与第三方服务之间模块与模块之间内部系统与外部 API 之间稳定业务规则与易变技术实现之间高风险权限操作与普通逻辑之间。所谓“柔在内部”是指模块内部不必机械地套用所有设计模式简单逻辑可以保持扁平没有替换需求时不必为每个类创建接口不要为未来可能永远不会发生的变化提前抽象小型项目不需要复制大型企业架构能用三个清晰文件解决的问题不要拆成十五个文件。架构的目标是降低复杂度而不是制造复杂度。十五、AI 友好的架构应该具备什么特征一个真正适合 AI 编程的系统至少应该具备以下特征。1. 模块职责明确每个模块都能用一句话解释清楚。例如用户模块负责身份和账户订单模块负责交易状态支付模块负责支付和退款消息模块负责通知发送。如果一个模块需要用一大段话才能解释通常说明边界还不够清晰。2. 修改路径清晰一个需求进入系统后应该能够快速判断需要修改哪些位置。例如接口参数变化 → API 层 业务规则变化 → Domain 层 流程编排变化 → Application 层 存储方式变化 → Infrastructure 层3. 依赖方向稳定AI 最容易在依赖方向不清晰的系统中产生错误。因此依赖方向应该明确最好可以自动验证。4. 文件规模适中不是文件越小越好而是一个文件应该承载一个相对完整的概念。巨型文件会增加 Token 成本。过度碎片化则会增加跨文件跳转成本。5. 契约明确模块之间通过稳定接口协作。输入、输出、异常和副作用应该清晰。6. 测试靠近业务规则核心业务逻辑应该能够脱离数据库和网络独立测试。7. 架构文档与代码同步架构说明不能只是一次性文档。它应该与目录结构、依赖规则和 CI 检查保持一致。8. 给 AI 明确的禁止事项很多时候告诉 AI“不允许做什么”比告诉它“请写好代码”更有效。例如不允许绕过应用层不允许新增全局状态不允许修改公开接口不允许引入新框架不允许复制已有业务逻辑不允许删除看似未使用但无法确认用途的代码。十六、AI 时代架构师的价值不会下降反而会提高当 AI 能够快速编写代码后单纯“把需求翻译成代码”的价值会下降。但以下能力会变得更加重要定义系统边界拆分问题识别核心业务规则设计模块契约控制依赖方向判断哪些变化需要抽象判断哪些地方不应该抽象设计可验证的架构规则控制 AI 的修改范围评估长期演进成本。AI 可以快速实现一个方案但它不天然知道哪个方案最适合这个组织、这个业务和这个系统的未来。它也不真正承担系统上线后的责任。因此未来架构师的工作可能不再是亲自编写大量基础代码而是设计 AI 可以安全工作的空间。架构师需要为 AI 明确哪里可以自由生成哪里必须严格遵守契约哪些模块可以重写哪些接口必须保持稳定哪些数据属于高风险哪些决策必须由人确认。这不是架构师价值的削弱而是架构职责的升级。十七、代码可以由 AI 写但系统责任仍然由人承担“AI 写的代码AI 自己能理解”还有一个根本问题AI 并不承担软件系统的最终责任。当系统出现以下问题时用户数据泄露资金计算错误库存被重复扣减权限控制失效服务大面积不可用合规要求未满足订单状态异常生产数据被误删除最终负责的仍然是企业、团队和工程师。只要责任仍然由人承担人就必须能够理解系统审查修改定位问题判断风险回滚变更解释行为验证正确性。因此软件架构不会因为代码由 AI 生成而消失。只要软件仍然影响真实用户、真实资金和真实业务架构就仍然是责任体系的一部分。十八、真正应该被淘汰的不是架构而是无价值的架构形式主义AI 时代确实会淘汰一部分传统开发方式。例如为了写代码而写代码重复生产样板代码只会套用设计模式为每个类机械创建接口不考虑实际变化却提前抽象为了“看起来专业”强行增加层次架构文档和实际代码完全脱节。但这不代表架构本身会消失。真正有价值的架构能力会变得更重要边界设计复杂度控制系统演进风险隔离上下文管理人机协作自动验证。AI 可以帮助我们减少无意义的样板代码但不能替代对系统结构的判断。结语AI 时代架构是人机协作的基础设施AI 降低了代码生成成本但没有消除软件复杂度。它甚至会让复杂度增长得更快。没有架构约束时AI 可以在极短时间内生成大量能运行、难维护、难审查、难测试、难演进的代码。有清晰架构时AI 才能使用更少的上下文消耗更少的 Token更准确地理解任务在更小范围内修改代码减少误改无关模块生成更容易测试的实现让人工评审更加高效支持系统持续重构和演进。所以AI 时代的正确结论不是代码都由 AI 写了因此不需要架构。而应该是正因为代码可以被 AI 快速生成所以我们更需要架构来约束代码的增长方式。AI 降低了“写代码”的成本却放大了“结构混乱”的代价。规范化分层不是传统软件工程留下来的洁癖也不是为了与 AI 对抗。它是控制 Token 成本、提升生成质量、保障人工评审、限制修改范围、支持自动验证和实现长期演进的基础设施。未来最好的软件系统未必是分层最多的系统也未必是设计模式使用最多的系统。它应该是一个边界清晰、上下文可控、修改局部、规则可验证并且人和 AI 都能够准确理解的系统。一句话总结AI 可以帮我们更快地写代码但架构决定了这些代码最终会成为生产力还是成为更快堆积的技术债。