拓冰网站定制 
文章目录一、代码越来越便宜设计越来越贵二、建立边界三、AI 正在改变程序员的工作重心四、从“写代码”升级到“设计系统”五、未来更高效的模式人设计AI 实现六、好的架构是给 AI 铺轨道七、[miniagent](https://github.com/liupras/miniagent) 也是一次这样的实践八、从“码农”到“系统指挥官”结语开源代码这一系列文章我们讨论了前后端分离、DDDDomain-Driven Design领域驱动设计、分层架构、DIDependency Injection依赖注入、RESTfulRepresentational State Transfer表现层状态转移、异步并发、SSEServer-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 实现未来的软件开发流程很可能越来越接近Business Requirement业务需求Architecture架构设计Rules Contracts规则与契约AI Coding AgentAI 编程智能体Implementation代码实现Test / CI自动验证Human Review人工验收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从代码的生产者走向系统的指挥官。开源代码githubgitee祝您好运 架构师 + AI：从“码农”到“系统指挥官”的职业跃迁
文章目录一、代码越来越便宜设计越来越贵二、建立边界三、AI 正在改变程序员的工作重心四、从“写代码”升级到“设计系统”五、未来更高效的模式人设计AI 实现六、好的架构是给 AI 铺轨道七、[miniagent](https://github.com/liupras/miniagent) 也是一次这样的实践八、从“码农”到“系统指挥官”结语开源代码这一系列文章我们讨论了前后端分离、DDDDomain-Driven Design领域驱动设计、分层架构、DIDependency Injection依赖注入、RESTfulRepresentational State Transfer表现层状态转移、异步并发、SSEServer-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 实现未来的软件开发流程很可能越来越接近Business Requirement业务需求Architecture架构设计Rules Contracts规则与契约AI Coding AgentAI 编程智能体Implementation代码实现Test / CI自动验证Human Review人工验收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从代码的生产者走向系统的指挥官。开源代码githubgitee祝您好运