回到本篇开篇 [68讲] 的一句话：软件工程只有约 60 年的历史。相比动辄跨世纪的自然科学，它太年轻了。正因为年轻，我们对它的认知仍然肤浅。
但正因如此，才需要思考未来。软件工程会走向何方？它的成熟标志是什么？哪些东西正在发生根本性的变化？
交叉参考：[06讲 - 操作系统演进] 和 [14讲 - 图形与图像] 讨论了基础软件的演进历史，本节聚焦软件工程方法论本身的未来走向。[68讲] 提出的核心矛盾——"在不确定性中寻找确定性"——是理解未来走向的钥匙。
软件工程的未来，从三个维度展开：
软件工程是高度设计驱动的工程活动。设计范式的沉淀是走向成熟的第一个标志：
| 层次 | 说明 | 成熟度 |
|---|---|---|
| 架构范式 | MVC、微服务、事件驱动、CQRS | 较成熟 |
| 设计模式 | GoF 23 种设计模式 | 成熟 |
| 并发范式 | Actor、CSP、响应式 | 较成熟 |
| 数据范式 | 关系型、文档型、时序型、图 | 较成熟 |
| 业务范式 | 领域驱动设计、Event Sourcing | 发展中 |
| AI 辅助设计 | LLM 辅助架构决策、代码生成 | 快速发展期（代码生成已较成熟，架构决策辅助仍在早期） |
关键判断：设计范式的沉淀不是让设计变成机械化的套公式，而是让"套路"成为默认起点，把创造力释放到真正需要创新的地方。
从 [68讲] 到 [75讲]，我们反复讨论的核心主题：在不确定性中找到确定性。工程手段的确定性提升贯穿了：
[74讲] 讨论了云服务作为"基础能力社会化"的本质。这一趋势只会加速：
设计范式提供的是"套路"，是默认起点。但它不替代创造力：
类比：围棋的定式不是让对局机械化，而是让棋手不必在每一个局部重新发明——把思考力留给真正需要创造力的局面。
AI 在软件工程中的角色：
架构师的核心竞争力不是写代码的速度，而是：
这些能力在 AI 时代反而更加重要。
云化的边界始终存在：
| 维度 | AI 生成 | 人类编写 |
|---|---|---|
| 速度 | 极快 | 慢 |
| 一致性 | 高 | 取决于个体 |
| 创造力 | 低——基于已有模式 | 高——突破性创新 |
| 可审查性 | 需要人类审查 | 可追溯思考过程 |
| 长期维护 | 不确定性高 | 可控性高 |
最佳实践：AI 生成模板代码和重复性代码，人类负责架构决策和创新性设计。AI 生成的代码必须经过与人类代码同等严格的质量检查。
| 维度 | 全盘云化 | 核心自建 |
|---|---|---|
| 前期效率 | 极高 | 较低 |
| 长期成本 | 高——按用量付费 | 低——固定投入 |
| 自主可控 | 低 | 高 |
| 竞争优势 | 同质化 | 差异化 |
最佳实践：非核心能力云化，核心能力自建。随着规模增长，部分云化能力可逐步自建以降低成本。
Go 语言本身就是设计范式沉淀的典型案例：
云原生架构（Kubernetes + Service Mesh + Serverless）正在系统性地提升工程确定性：
GitHub Copilot 等 AI 工具已经在以下场景展现了显著效果：
但 AI 在以下场景仍然受限：
AI 生成的代码可能包含：
核心原则：AI 生成的代码必须经过与人类代码同等严格的质量检查——单元测试、代码审查、集成测试，一项不能少。
设计范式是默认起点，不是终极答案。过度追求范式导致：
无论技术如何进步，软件工程的核心矛盾——不确定性 vs 确定性——不会消失。AI 和云化是缓解手段，不是终极解决方案。忽视这一本质，会导致：
软件工程正在从手艺走向工程：三个演进方向——设计范式沉淀、工程手段确定性提升、基础能力云化。共同目标：降低不确定性。
设计范式沉淀不等于设计机械化：范式提供默认起点，把创造力释放到真正需要创新的地方。类比围棋定式。
AI 辅助不替代架构师：AI 提升编码效率和代码质量，但架构师的核心竞争力——业务判断力、权衡决策力、协同影响力——反而更加重要。
云化深化不等于全盘云化：核心业务逻辑和合规敏感数据始终需要自研和私有化。云化的边界是竞争优势所在。
核心矛盾不会消失：无论技术如何进步，"在不确定性中寻找确定性"始终是软件工程的核心命题。AI 和云化是缓解手段，不是终极解决方案。
软件工程的成熟标志：当设计范式足够丰富、工程手段足够确定、基础能力足够标准化时，软件工程将从"手艺"真正走向"工程"。但这条路还很长。
下一篇将进入"画图程序"的整体架构实战，把前面各讲的方法论在实践中融会贯通。