从 AI 编程到 AI 自动模块化组装：下一代软件工程的可能形态的设想

值得一提的是, 过去两年，AI 编程的进步主要体现在“让 AI 写更多代码”。

但一个更值得思考的方向正在出现：

AI 编程的下一阶段，也许不是生成更多代码，而是让 AI 组合更多已经存在的软件能力。

如果这一趋势成立，软件开发的核心竞争力将从“代码生成”逐渐转向“模块设计、能力组合与系统编排(软件层面)”。

一、从“AI 写代码”到“AI 组装软件”

今天让 AI 构建一个 RAG 产品，通常还是：

需求 → AI → 生成代码 → 调试 → 测试

但实际上，用户真正需要的并不是几千行代码，而是一套完整能力：

用户
+ 身份认证
+ 权限
+ 数据库
+ Session
+ Billing
+ RAG
+ Chat
+ UI

这些能力并不需要每次从零实现。

更合理的方式可能是：

需求
 ↓
寻找成熟模块
 ↓
组合模块
 ↓
配置接口、权限与事件
 ↓
验证系统

于是 AI 的角色发生变化：

从 Code Generator，转向 Software Composer。

代码依然存在，只是越来越多地隐藏在模块内部。

二、软件工程正在从“代码”走向“能力”

软件工程一直在做一件事情：封装复杂性。

从函数、类，到框架、组件、微服务，再到云 API，本质都是把重复能力抽象出来。

AI 出现之后，这种抽象可能进一步向上移动。

过去我们复用的是：

Library、SDK、Service。

未来复用的可能是：

Capability。

例如，一个 AI 可调用的 Auth 模块，不只是几份代码，而应该同时描述：

API
Schema
Permission
State
Event
Error
Cost
Security
Version

这样 AI 才能理解：

“这个模块能做什么、怎么调用、什么时候不能调用，以及出了问题怎么办。”

因此，未来真正有价值的，不只是代码仓库，而可能是：

可被 AI 理解和组合的软件能力库。

三、Graph Engineer：AI 编程正在从“生成”走向“编排”

这也是最近 Graph-based AI Engineering 思想值得关注的原因。

传统 Agent 更像：

Prompt
 ↓
LLM
 ↓
Tool
 ↓
LLM

复杂系统却更接近：

Requirement
 ↓
Plan
 ↓
Select
 ↓
Compose
 ↓
Execute
 ↓
Evaluate
 ↓
Retry / Refactor
 ↓
Verify

这本质上已经不是一条 Chain，而是一张 Graph。

近期一些 Graph Engineering 实践，也开始把软件开发过程显式组织成 Spec、Implementation、Quality Gate、Critique、Refactor、Verify 等节点，并通过状态、路由和反馈回路让 Agent 处理复杂工程任务。

与此同时，一些新的 Coding Agent 研究也开始强调“代码导航”和“结构理解”：Agent 不只是生成代码，而需要理解代码库中模块、依赖和调用关系。

这意味着 AI 编程正在发生一个重要变化：

AI 不只是生成代码，而是在软件图谱上进行决策。

四、未来真正需要设计的，可能是“模块之间的关系”

模块化看起来会降低复杂度，但它也会产生新的问题。

因为：

模块越多
→ 连接关系越多
→ 状态越复杂
→ 权限越复杂
→ 故障边界越复杂

过去我们担心：

Code Complexity。

未来可能更需要担心：

Composition Complexity。

一个优秀模块本身并不意味着优秀的软件系统。

真正困难的问题会变成：

• 哪个模块应该被选中？
• 两个模块的状态如何连接？
• 权限如何传递？
• 出错后谁负责恢复？
• 如何验证组合之后仍然可靠？

所以：

模块化不会消灭复杂性，只会把复杂性从“实现层”转移到“组合层”。

五、这也是一种新的软件工程分工

如果 AI 越来越擅长写 CRUD、API、测试和基础设施，那么开发者的角色必然发生变化。

过去关注：

如何实现？

未来越来越关注：

应该有哪些能力？
能力边界在哪里？
哪些应该复用？
模块如何连接？
如何验证？

也就是说，开发者可能逐渐从：

Coder

变成：

Architect → System Designer → Graph Engineer

未来真正稀缺的能力，可能不是“写代码最快”，而是：

把复杂问题拆成 AI 可以理解、选择、组合和验证的能力网络。

六、但“模块化一切”并不是答案

这条路线同样存在反面。

如果所有东西都依赖模块：

Auth Module
Billing Module
RAG Module
Search Module
Agent Module
...

系统可能逐渐出现新的平台依赖和生态锁定。

过去我们担心 Cloud Lock-in。

未来可能出现：

Capability Lock-in。

另外，如果 AI 只会调用模块，却不了解模块内部原理，也可能形成新的“认知债务”。

因此，未来的软件工程并不是：

“不要写代码了。”

而应该是：

重复能力尽量模块化，核心差异保持可编程，关键系统保持可理解、可验证。

模块与代码不是替代关系，而是新的分层关系。

七、最终可能出现“AI 软件装配线”

如果把这些趋势放在一起，未来的软件开发可能越来越像一条自动化装配线：

业务需求
   ↓
AI 理解意图
   ↓
Capability Graph
   ↓
选择模块
   ↓
组合 Workflow
   ↓
生成必要代码
   ↓
自动测试与验证
   ↓
部署运行

这时，代码只是最后的实现结果之一。

真正的核心对象变成了：

能力、关系、工作流、约束与验证。

所以未来的 AI IDE 也许不再只是一个“代码编辑器”，而更像一个：

System Composer。

像我们这样的开发者面对的也不再只是文件和函数，而是一张可以被 AI 理解和修改的软件系统图。

总结：从 AI Programming 到 AI Software Assembly

如果要把这个趋势浓缩成一句话：

过去 AI 帮我们写软件，未来 AI 可能直接帮我们组装软件。

这并不意味着代码消失，而意味着代码逐渐退居为模块内部的实现细节。

软件工程的抽象层正在继续上移：

写代码
 ↓
设计系统
 ↓
设计模块
 ↓
组合能力
 ↓
编排软件图

而 Graph Engineer 的价值，就在于理解这张“图”：

什么能力存在、能力如何连接、工作如何流动、系统如何验证。

启发

真正值得思考的，也许已经不是：

谁拥有最强的 Coding AI？

而是：

谁拥有最多高质量、可组合、可验证的软件能力？

未来的软件竞争，很可能从“模型竞争”逐渐走向：

模型 + 模块 + Graph + Verification 的综合竞争。

而对于开发者来说，一个更值得提前布局的方向是：

不要只想着让 AI 写得更快，也要开始思考：有哪些软件能力值得被做成模块，并让未来的 AI 可以无限复用？

这可能才是从 AI 编程 走向 AI 自动模块化组装 最重要的一步。