目录
- 一、为什么现在需要刻意提升"工程能力"？
- 二、需要提升的能力到底是什么？
- [三、AI 编程时代最重要的思维转变](#三、AI 编程时代最重要的思维转变)
- [3.1 不要把 AI 当成"程序员"](#3.1 不要把 AI 当成“程序员”)
- [四、正确的方式：让 AI 成为"施工队"](#四、正确的方式：让 AI 成为“施工队”)
- 五、一个非常重要的能力：软件设计
- 六、工程能力的核心概念
- [6.1 高内聚](#6.1 高内聚)
- [6.2 低耦合](#6.2 低耦合)
- [6.3 接口与抽象](#6.3 接口与抽象)
- [6.4 可扩展性](#6.4 可扩展性)
- [七、AI 编程时应该建立固定工作流](#七、AI 编程时应该建立固定工作流)
- [Step 1：先让 AI 分析需求](#Step 1：先让 AI 分析需求)
- [Step 2：让 AI 给出技术方案](#Step 2：让 AI 给出技术方案)
- [Step 3：确定模块边界](#Step 3：确定模块边界)
- [Step 4：定义接口](#Step 4：定义接口)
- [Step 5：让 AI 编写代码](#Step 5：让 AI 编写代码)
- [Step 6：让 AI 做 Code Review](#Step 6：让 AI 做 Code Review)
- [Step 7：测试](#Step 7：测试)
- [Step 8：重构](#Step 8：重构)
- [八、结合 GIS + Electron 项目进行训练](#八、结合 GIS + Electron 项目进行训练)
- 九、学习过程中不要追求"设计得越复杂越好"
- 十、五个核心学习资源
- [第一阶段 ⭐⭐⭐⭐⭐](#第一阶段 ⭐⭐⭐⭐⭐)
- [1. MIT Software Construction](#1. MIT Software Construction)
- [第二阶段 ⭐⭐⭐⭐⭐](#第二阶段 ⭐⭐⭐⭐⭐)
- [2. 《重构》（Refactoring）](#2. 《重构》（Refactoring）)
- [第三阶段 ⭐⭐⭐⭐](#第三阶段 ⭐⭐⭐⭐)
- [3. 《设计模式》](#3. 《设计模式》)
- [第四阶段 ⭐⭐⭐⭐](#第四阶段 ⭐⭐⭐⭐)
- [4. Clean Architecture](#4. Clean Architecture)
- [第五阶段 ⭐⭐⭐⭐](#第五阶段 ⭐⭐⭐⭐)
- [5. Designing Data-Intensive Applications](#5. Designing Data-Intensive Applications)
- 十一、最终学习顺序
- 十二、最重要的学习原则
- 十三、最终目标
- 十四、最终路线总结
一、为什么现在需要刻意提升"工程能力"？
随着 AI 编程工具越来越强，写代码本身正在变得越来越容易。
现在很多功能都可以通过：
描述需求 → AI 生成代码 → 运行 → 修 Bug
快速完成。
但在实际开发过程中，会逐渐发现另外一个问题：
功能虽然实现了，但是代码可能越来越难维护，Bug 越来越多，模块之间耦合严重，后续需求一变化就需要大面积修改。
这说明问题已经不再单纯是"编程能力不足"，而是开始涉及：
- 软件工程能力
- 软件设计能力
- 产品设计能力
- 架构设计能力
- 重构能力
- 测试能力
- 系统设计能力
因此，AI 编程时代真正需要提升的，并不是单纯的"写代码速度"，而是：
从"会写代码"逐渐提升到"会构建软件"。
二、需要提升的能力到底是什么？
很多时候会把这些能力统称为"架构能力"，但实际上它们是一个逐层递进的体系。
text
软件工程能力
│
├── 需求分析 / 产品设计
│
├── 软件设计
│ ├── 模块划分
│ ├── 抽象
│ ├── 接口设计
│ ├── 解耦
│ └── 设计模式
│
├── 工程质量
│ ├── 测试
│ ├── Debug
│ ├── Code Review
│ ├── Git
│ ├── 日志
│ └── 错误处理
│
├── 架构设计
│ ├── 分层
│ ├── 模块边界
│ ├── 数据流
│ ├── 状态管理
│ ├── 系统通信
│ └── 可扩展性
│
└── 软件演进
├── 重构
├── 维护
├── 性能优化
└── 需求变化因此，目标并不是单纯学习"架构"。
真正应该建立的是：
软件工程 → 软件设计 → 架构设计 → 系统设计
这一整套能力。
三、AI 编程时代最重要的思维转变
3.1 不要把 AI 当成"程序员"
传统的 AI 编程方式很容易变成：
text
我想实现 XXX
↓
告诉 AI
↓
AI 写代码
↓
运行
↓
出现 Bug
↓
让 AI 修 Bug
↓
继续增加功能
↓
代码越来越复杂短期看效率非常高。
但是长期容易出现：
text
功能 A
↓
功能 B
↓
功能 C
↓
功能 D
↓
模块之间开始互相依赖
↓
修改 A 影响 B
↓
修改 B 影响 C
↓
AI 开始不断打补丁
↓
项目越来越难维护四、正确的方式：让 AI 成为"施工队"
更合理的模式应该是：
人负责设计和决策，AI 负责实现和辅助分析。
也就是说：
text
需求
↓
需求分析
↓
方案设计
↓
模块划分
↓
接口设计
↓
数据流设计
↓
异常场景分析
↓
测试方案
↓
AI 实现
↓
Code Review
↓
测试
↓
重构AI 可以帮助：
- 写代码
- 查 Bug
- 生成测试
- 分析代码
- 重构
- 生成文档
- Code Review
- 分析技术方案
但是最终应该由开发者负责：
- 需求理解
- 架构决策
- 模块边界
- 技术选型
- 数据结构
- 接口设计
- 代码质量
- 软件整体结构
五、一个非常重要的能力：软件设计
例如现在需要实现一个 GIS 模型加载功能。
最简单的思考方式：
text
点击按钮
↓
选择文件
↓
加载模型但是工程化之后，需要考虑：
text
用户选择文件
↓
文件格式检查
↓
文件存在性检查
↓
模型解析
↓
坐标系检查
↓
坐标转换
↓
模型加载
↓
加载进度反馈
↓
加载成功 / 失败
↓
资源管理
↓
场景管理进一步还需要考虑：
- 如果文件不存在怎么办？
- 如果文件格式错误怎么办？
- 如果模型非常大怎么办？
- 如果用户中途取消怎么办？
- 如果加载失败怎么办？
- 如果模型已经加载过怎么办？
- 如果坐标系错误怎么办？
- 如果同时加载多个模型怎么办？
- 如果关闭项目怎么办？
- 下次打开项目是否需要重新加载？
这就是：
从"实现功能"转向"设计软件"。
六、工程能力的核心概念
在学习过程中，需要逐渐掌握以下概念。
6.1 高内聚
一个模块应该尽量只负责一类相关事情。
例如：
text
ModelService主要负责模型相关业务，而不是同时负责：
text
ModelService
├── 模型加载
├── UI DOM 操作
├── 文件选择框
├── 日志输出
├── 数据库操作
└── 用户权限6.2 低耦合
模块之间应该尽量减少直接依赖。
例如：
text
业务代码
↓
内部接口
↓
具体实现而不是：
text
业务代码
↓
直接调用第三方 GIS SDK
↓
直接操作 Electron API
↓
直接操作文件系统这样以后更换技术方案时，会容易很多。
6.3 接口与抽象
例如模型加载：
text
ModelLoader
│
├── OSGBLoader
├── Tiles3DLoader
├── GLTFLoader
└── OBJLoader业务层只关心：
text
load()而不需要知道具体实现。
6.4 可扩展性
好的设计应该尽量做到：
增加新功能时，主要是增加代码，而不是大量修改旧代码。
例如：
text
ModelLoader
│
├── OSGB
├── 3DTiles
├── GLTF
└── 新格式以后增加新格式时，不应该把整个系统重新修改一遍。
七、AI 编程时应该建立固定工作流
以后可以逐渐形成自己的 AI Coding Workflow。
Step 1：先让 AI 分析需求
不要直接让 AI 写代码。
先问：
text
请先分析这个需求涉及哪些模块，
不要写代码。
请告诉我：
1. 功能边界
2. 模块划分
3. 数据流
4. 状态变化
5. 异常情况
6. 潜在风险Step 2：让 AI 给出技术方案
text
请给出两个或三个实现方案，
分析它们的优缺点。
不要直接写代码。Step 3：确定模块边界
例如：
text
UI
│
↓
ModelService
│
├── ModelLoader
├── CoordinateService
└── SceneServiceStep 4：定义接口
先确定：
text
ModelLoader
↓
load()
cancel()
getProgress()
dispose()然后再写具体实现。
Step 5：让 AI 编写代码
这时候 AI 才开始真正进入"施工阶段"。
Step 6：让 AI 做 Code Review
可以固定询问：
text
请从以下方面 Review 这段代码：
1. 是否存在高耦合？
2. 是否违反单一职责？
3. 是否存在重复代码？
4. 是否存在隐藏状态？
5. 是否存在资源泄漏？
6. 是否存在异常处理缺失？
7. 是否容易测试？
8. 如果需求发生变化，哪里最难修改？
9. 是否存在过度设计？
10. 是否存在潜在 Bug？Step 7：测试
至少考虑：
text
正常情况
异常情况
边界情况
并发情况
用户取消
资源释放
重复操作Step 8：重构
最终形成：
text
需求
↓
设计
↓
AI 实现
↓
测试
↓
Review
↓
重构而不是：
text
需求
↓
AI 写代码
↓
不断打补丁八、结合 GIS + Electron 项目进行训练
目前正在接触的技术栈非常适合训练软件工程能力。
例如：
text
Electron
│
├── Renderer
│
├── Main Process
│
└── IPC
│
↓
GIS Engine
│
├── 3D Tiles
├── OSGB
├── GLTF
└── Terrain如果进一步涉及：
text
ZMQ
↓
后台服务
↓
GIS
↓
AI还可以进一步训练：
- 进程间通信
- 消息通信
- 异步任务
- 状态管理
- 错误处理
- 资源管理
- 网络通信
- 并发
- 服务拆分
这些都属于非常有价值的软件工程训练。
九、学习过程中不要追求"设计得越复杂越好"
这是非常重要的一点。
学习架构以后，很容易产生一个误区：
text
interface
factory
service
repository
adapter
facade
controller
...然后一个简单功能写成几百行代码。
这并不是好的架构。
真正应该追求的是：
合适的复杂度。
也就是说：
text
简单需求
↓
简单设计
复杂需求
↓
复杂设计而不是：
text
简单需求
↓
复杂设计因此学习架构的目的不是：
"把项目设计得高级。"
而是：
在面对复杂度时，有能力控制复杂度。
十、五个核心学习资源
下面按照推荐学习顺序排列。
第一阶段 ⭐⭐⭐⭐⭐
1. MIT Software Construction
目标
建立真正的软件工程基本功。
重点学习：
- Specification
- Testing
- Debugging
- Code Review
- Git
- Abstract Data Types
- Interface
- Immutability
- Design Patterns
- Concurrency
- Thread Safety
- Networking
核心目标：
让代码安全、容易理解、容易修改。
这门课特别适合作为第一阶段，因为它不是单纯教"怎么写代码"，而是在训练：
如何构建能够长期维护的软件。
建议学习方式：
text
学习一个概念
↓
理解概念
↓
在自己的 GIS 项目中寻找对应场景
↓
让 AI 帮你实现
↓
自己 Review
↓
重构第二阶段 ⭐⭐⭐⭐⭐
2. 《重构》（Refactoring）
作者：Martin Fowler
目标
解决：
代码已经能运行，但是越来越难维护怎么办？
重点学习：
- Code Smell
- Extract Method
- Extract Class
- Rename
- Move Method
- Replace Conditional
- Simplify Conditional
- Remove Duplication
- Encapsulation
- Safe Refactoring
真正需要理解的是：
为什么代码需要重构？
以及：
什么时候应该重构？
例如：
text
一个函数 300 行
↓
为什么有问题？
↓
职责是否太多？
↓
哪些部分可以独立？
↓
拆分
↓
测试
↓
继续观察这本书对于 AI 编程尤其重要。
因为 AI 很容易快速生成大量代码，而重构能力决定了你能不能把这些代码逐渐整理成一个长期可维护的系统。
第三阶段 ⭐⭐⭐⭐
3. 《设计模式》
目标
学习如何解决反复出现的软件设计问题。
重点理解：
- Strategy
- Factory
- Observer
- Adapter
- Facade
- Command
- State
- Dependency Injection
- Composition
不要把重点放在：
"背 23 种设计模式。"
而应该放在：
为什么这个问题需要这种设计？
例如 GIS 模型加载：
text
ModelLoader
│
├── OSGBLoader
├── Tiles3DLoader
├── GLTFLoader
└── OBJLoader这里可以学习：
- Strategy
- Factory
- Interface
- Dependency Injection
第四阶段 ⭐⭐⭐⭐
4. Clean Architecture
目标
开始建立真正的架构思维。
重点理解：
text
UI
↓
Application
↓
Domain
↓
Infrastructure以及：
- Dependency Rule
- Boundary
- Separation of Concerns
- Dependency Inversion
- Use Case
- Entity
- Adapter
需要特别注意：
Clean Architecture 是帮助你理解架构原则的工具，而不是要求所有项目都严格按照固定模板实现。
不要为了"架构"而架构。
应该根据项目复杂度决定：
text
小项目
↓
简单模块化
中型项目
↓
分层 + 明确边界
大型项目
↓
进一步考虑领域、基础设施、系统边界第五阶段 ⭐⭐⭐⭐
5. Designing Data-Intensive Applications
作者：Martin Kleppmann
简称：
DDIA
这是从"软件工程 / 软件设计"继续向"系统设计"发展的重要一步。
重点学习：
- Database
- Storage
- Replication
- Partitioning
- Distributed Systems
- Transactions
- Consistency
- Batch Processing
- Stream Processing
- Message Systems
- Data Models
它解决的是更大规模的问题：
text
一个程序
↓
多个模块
↓
多个进程
↓
多个服务
↓
多个机器
↓
大量数据
↓
分布式系统对于以后接触：
- GIS 数据平台
- 遥感数据处理
- 超算
- AI 服务
- ZMQ
- 消息队列
- 大规模空间数据
都会非常有价值。
十一、最终学习顺序
按照这个顺序学习：
text
AI 编程
│
↓
┌──────────────────────────┐
│ 1. MIT Software │
│ Construction │
│ │
│ 软件工程基本功 │
└────────────┬─────────────┘
↓
┌──────────────────────────┐
│ 2. Refactoring │
│ 《重构》 │
│ │
│ 代码质量 / 可维护性 │
└────────────┬─────────────┘
↓
┌──────────────────────────┐
│ 3. Design Patterns │
│ 《设计模式》 │
│ │
│ 软件设计 / 抽象 / 解耦 │
└────────────┬─────────────┘
↓
┌──────────────────────────┐
│ 4. Clean Architecture │
│ │
│ 系统架构 / 模块边界 │
└────────────┬─────────────┘
↓
┌──────────────────────────┐
│ 5. DDIA │
│ Designing Data- │
│ Intensive Applications│
│ │
│ 系统设计 / 分布式系统 │
└──────────────────────────┘最终形成：
text
写代码
↓
软件工程
↓
软件设计
↓
架构设计
↓
系统设计十二、最重要的学习原则
不要采用：
text
看书
↓
记笔记
↓
看下一本书
↓
继续记笔记而应该采用：
text
学习概念
↓
寻找真实项目中的问题
↓
用概念分析问题
↓
修改项目
↓
让 AI 辅助实现
↓
Review
↓
测试
↓
重构也就是说：
用项目学习，而不是用书本学习。
十三、最终目标
最终不是为了成为：
"最懂设计模式的人。"
也不是为了成为：
"最懂架构的人。"
而是为了成为：
一个能够利用 AI 高效率构建、维护和演进软件的人。
理想状态应该是：
text
你
│
├── 理解需求
├── 做产品判断
├── 设计系统
├── 划分模块
├── 定义接口
├── 控制复杂度
└── 做技术决策
│
↓
AI
│
├── 生成代码
├── 生成测试
├── 分析 Bug
├── Code Review
├── 重构
└── 生成文档
│
↓
最终软件这样，AI 越强，你的生产力反而越高。
因为你不再只是：
"让 AI 帮我写代码。"
而是：
"我知道我要构建什么，也知道应该怎样构建，让 AI 帮我把它快速实现出来。"
这才是 AI 编程时代真正值得培养的核心能力。
十四、最终路线总结
| 阶段 | 学习资源 | 核心能力 | 最终解决的问题 |
|---|---|---|---|
| 1 | MIT Software Construction | 软件工程 | 怎么写出可靠、可维护的代码 |
| 2 | 《重构》 | 代码质量 | 代码越来越乱怎么办 |
| 3 | 《设计模式》 | 软件设计 | 模块怎么组织、怎么解耦 |
| 4 | Clean Architecture | 架构 | 大型项目怎么划分边界 |
| 5 | DDIA | 系统设计 | 大规模数据和分布式系统怎么设计 |
最终形成：
软件工程 → 重构 → 软件设计 → 架构 → 系统设计
而 AI 则贯穿整个过程，成为你的：
编码助手 + 测试助手 + Review 助手 + 重构助手 + 架构讨论伙伴。
核心思想：不要和 AI 比谁写代码快，而要提升自己"设计和构建软件"的能力。
最后经过提炼，把这五步按照工程学和架构知识进行提炼，总结了五篇文档如下：
1.MIT Software Construction：软件工程核心知识提炼