这一系列文章，我们讨论了前后端分离、DDD（Domain-Driven Design，领域驱动设计）、分层架构、DI（Dependency Injection，依赖注入）、RESTful（Representational State Transfer，表现层状态转移）、异步并发、SSE（Server-Sent Events，服务器发送事件）、插件化以及 Project Rules（项目规则）等一系列工程方法。

看起来讲了很多技术，但它们最终都指向同一个问题：

当 AI 已经能够大量生成代码，程序员最重要的能力还是什么？

答案正在从：

“如何把代码写出来”

转向：

“如何设计一个让 AI 能够正确写代码的系统”。

一、代码越来越便宜，设计越来越贵

过去的软件开发流程大致是：

理解需求
   ↓
设计方案
   ↓
编写代码
   ↓
测试调试

其中，编码占据了大量时间。现在，AI 已经可以快速完成：

CRUD
API
SQL
数据模型
单元测试
业务模块

AI 越擅长写代码，一个问题就越重要：

应该写什么，以及这些代码应该放在哪里？

二、建立边界

回头看前面的内容，会发现它们背后有一个共同主题：

前后端分离
→ 系统边界

DDD
→ 业务边界

分层架构
→ 职责边界

Repository
→ 数据访问边界

DI
→ 依赖边界

RESTful + 契约优先
→ 接口边界

异步与并发
→ 执行模型边界

SSE / WebSocket
→ 实时通信边界

Plugin / Extension Point
→ 功能扩展边界

Project Rules
→ 把这些边界告诉 AI

所以架构的目的并不是增加复杂度。

恰恰相反：

架构是在复杂度出现之前，先规定复杂度应该被关在哪里。

三、AI 正在改变程序员的工作重心

传统开发模式更接近：

需求
 ↓
程序员设计
 ↓
程序员编码
 ↓
程序员调试

AI 编程则越来越接近：

需求
 ↓
架构设计
 ↓
定义边界和契约
 ↓
AI 实现
 ↓
自动验证
 ↓
人工验收

程序员并不是从开发流程中消失了，而是逐渐向更上游移动。

以前，我们更像：

施工人员。

以后，越来越像：

建筑师 + 项目经理 + 验收工程师。

不一定亲手砌每一块砖，但必须知道：

房子怎么设计
承重墙在哪里
不同模块如何连接
施工队应该遵守什么规范
最后按照什么标准验收

AI 负责提高施工速度。

人负责确保：

施工方向是对的。

四、从“写代码”升级到“设计系统”

可以把开发者能力简单理解成几个层次：

Level 1
会写代码
   ↓
Level 2
会实现功能
   ↓
Level 3
会设计模块
   ↓
Level 4
会设计系统
   ↓
Level 5
会设计规则，让 AI 持续构建系统

AI 对底层编码工作的替代能力最强。

但越往上，需要解决的问题越不同：

领域应该怎样划分？

模块边界在哪里？

哪些能力应该抽象？

哪些地方应该插件化？

数据应该由谁负责？

模块之间应该如何依赖？

未来增加十倍功能还能不能维护？

这些问题并不是“代码生成”问题。

而是：

Architecture：架构问题。

所以 AI 并没有削弱架构能力的价值。

恰恰相反：

AI 把架构能力变成了更大的生产力杠杆。

五、未来更高效的模式：人设计，AI 实现

未来的软件开发流程，很可能越来越接近：

flowchart LR A["Business Requirement
业务需求"] --> B["Architecture
架构设计"] B --> C["Rules & Contracts
规则与契约"] C --> D["AI Coding Agent
AI 编程智能体"] D --> E["Implementation
代码实现"] E --> F["Test / CI
自动验证"] F --> G["Human Review
人工验收"] G --> H["Production"]

人的工作重心逐渐从：

Implementation：实现

转向：

Design + Constrain + Validate：设计 + 约束 + 验证。

这也是整个系列一直强调 Project Rules 的原因。

过去，架构规范可能只是文档。现在可以变成：

Architecture
     ↓
Project Rules
     ↓
AI Context
     ↓
Generated Code

也就是说：

架构规范第一次可以直接参与代码生产。

六、好的架构，是给 AI 铺轨道

AI 的优势是速度，架构的作用则是方向。

没有架构：

需求
 ↓
AI 自由发挥
 ↓
代码越来越多
 ↓
结构越来越乱

有架构：

需求
 ↓
Architecture
 ↓
Rules / Contracts
 ↓
AI
 ↓
符合边界的实现

所以好的架构并不是限制 AI 的能力，而是：

把 AI 的高速执行能力限制在正确的轨道上。

就像高铁真正需要的不是更自由地行驶，而是一套清晰、稳定的轨道系统。

七、miniagent 也是一次这样的实践

这一系列文章一直以 miniagent 作为案例，并不是为了给出所谓“标准架构”。

它更像一个实验：

能不能先建立清晰的架构边界，再让 AI 在这些边界内持续开发？

例如 miniagent 通过 ServiceContainer 组织数据库、Repository、Service、Registry 和 Factory 等核心组件，并在应用启动阶段初始化相关能力。

真正值得关注的不是这些具体类名，而是背后的开发方式：

先设计
   ↓
再约束
   ↓
让 AI 实现
   ↓
测试和 Review
   ↓
继续演进

这套循环才是 AI 编程真正值得建立的工程能力。

八、从“码农”到“系统指挥官”

AI 时代，继续和 AI 比：

谁写代码更快？

意义已经越来越小。

开发者更值得提升的是：

理解业务
   ↓
抽象领域
   ↓
设计架构
   ↓
定义边界
   ↓
制定规则
   ↓
拆解任务
   ↓
指挥 AI
   ↓
验证结果

角色也因此从：

Coder：编码者

逐渐转向：

System Orchestrator：系统编排者 / 系统指挥者。

未来优秀的开发者，未必是团队里写代码最多的人。

更可能是那个能够：

把复杂业务设计成清晰系统，把系统变成明确规则，再让 AI 按照这些规则持续工作的那个人。

结语

如果把整个系列压缩成一句话，就是：

不要只学习如何让 AI 帮你写代码，更要学习如何设计一个值得让 AI 去写的系统。

当关注点从：

“这个函数应该怎么写？”

逐渐转向：

“这个模块应该存在吗？边界在哪里？接口是什么？谁依赖谁？哪里允许扩展？AI 应该遵守什么规则？”

角色就已经开始发生变化：

Coder
  ↓
Architect
  ↓
AI Orchestrator

从代码的生产者，

走向系统的指挥官。

开源代码

🪐祝您好运🪐