文章目录
- 一、代码越来越便宜，设计越来越贵
- 二、建立边界
- 三、AI 正在改变程序员的工作重心
- 四、从“写代码”升级到“设计系统”
- 五、未来更高效的模式：人设计，AI 实现
- 六、好的架构，是给 AI 铺轨道
- 七、[miniagent](https://github.com/liupras/miniagent) 也是一次这样的实践
- 八、从“码农”到“系统指挥官”
- 结语
- 开源代码
这一系列文章，我们讨论了前后端分离、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 实现
未来的软件开发流程，很可能越来越接近：
人的工作重心逐渐从：
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从代码的生产者，
走向系统的指挥官。
开源代码
- github
- gitee
🪐祝您好运🪐
