企业官网建设流程全解析

目录

• 一、为什么现在需要刻意提升“工程能力”？
• 二、需要提升的能力到底是什么？
• 三、AI 编程时代最重要的思维转变
  • 3.1 不要把 AI 当成“程序员”
• 四、正确的方式：让 AI 成为“施工队”
• 五、一个非常重要的能力：软件设计
• 六、工程能力的核心概念
  • 6.1 高内聚
  • 6.2 低耦合
  • 6.3 接口与抽象
  • 6.4 可扩展性
• 七、AI 编程时应该建立固定工作流
  • Step 1：先让 AI 分析需求
  • Step 2：让 AI 给出技术方案
  • Step 3：确定模块边界
  • Step 4：定义接口
  • Step 5：让 AI 编写代码
  • Step 6：让 AI 做 Code Review
  • Step 7：测试
  • Step 8：重构
• 八、结合 GIS + Electron 项目进行训练
• 九、学习过程中不要追求“设计得越复杂越好”
• 十、五个核心学习资源
  • 第一阶段 ⭐⭐⭐⭐⭐
  • 1. MIT Software Construction
  • 第二阶段 ⭐⭐⭐⭐⭐
  • 2. 《重构》（Refactoring）
  • 第三阶段 ⭐⭐⭐⭐
  • 3. 《设计模式》
  • 第四阶段 ⭐⭐⭐⭐
  • 4. Clean Architecture
  • 第五阶段 ⭐⭐⭐⭐
  • 5. Designing Data-Intensive Applications
• 十一、最终学习顺序
• 十二、最重要的学习原则
• 十三、最终目标
• 十四、最终路线总结

一、为什么现在需要刻意提升“工程能力”？

随着 AI 编程工具越来越强，写代码本身正在变得越来越容易。

现在很多功能都可以通过：

描述需求 → AI 生成代码 → 运行 → 修 Bug

快速完成。

但在实际开发过程中，会逐渐发现另外一个问题：

功能虽然实现了，但是代码可能越来越难维护，Bug 越来越多，模块之间耦合严重，后续需求一变化就需要大面积修改。

这说明问题已经不再单纯是“编程能力不足”，而是开始涉及：

• 软件工程能力
• 软件设计能力
• 产品设计能力
• 架构设计能力
• 重构能力
• 测试能力
• 系统设计能力

因此，AI 编程时代真正需要提升的，并不是单纯的“写代码速度”，而是：

从“会写代码”逐渐提升到“会构建软件”。

二、需要提升的能力到底是什么？

很多时候会把这些能力统称为“架构能力”，但实际上它们是一个逐层递进的体系。

软件工程能力 │ ├── 需求分析 / 产品设计 │ ├── 软件设计 │ ├── 模块划分 │ ├── 抽象 │ ├── 接口设计 │ ├── 解耦 │ └── 设计模式 │ ├── 工程质量 │ ├── 测试 │ ├── Debug │ ├── Code Review │ ├── Git │ ├── 日志 │ └── 错误处理 │ ├── 架构设计 │ ├── 分层 │ ├── 模块边界 │ ├── 数据流 │ ├── 状态管理 │ ├── 系统通信 │ └── 可扩展性 │ └── 软件演进 ├── 重构 ├── 维护 ├── 性能优化 └── 需求变化

因此，目标并不是单纯学习“架构”。

真正应该建立的是：

软件工程 → 软件设计 → 架构设计 → 系统设计

这一整套能力。

三、AI 编程时代最重要的思维转变

3.1 不要把 AI 当成“程序员”

传统的 AI 编程方式很容易变成：

我想实现 XXX ↓ 告诉 AI ↓ AI 写代码 ↓ 运行 ↓ 出现 Bug ↓ 让 AI 修 Bug ↓ 继续增加功能 ↓ 代码越来越复杂

短期看效率非常高。

但是长期容易出现：

功能 A ↓ 功能 B ↓ 功能 C ↓ 功能 D ↓ 模块之间开始互相依赖 ↓ 修改 A 影响 B ↓ 修改 B 影响 C ↓ AI 开始不断打补丁 ↓ 项目越来越难维护

四、正确的方式：让 AI 成为“施工队”

更合理的模式应该是：

人负责设计和决策，AI 负责实现和辅助分析。

也就是说：

需求 ↓ 需求分析 ↓ 方案设计 ↓ 模块划分 ↓ 接口设计 ↓ 数据流设计 ↓ 异常场景分析 ↓ 测试方案 ↓ AI 实现 ↓ Code Review ↓ 测试 ↓ 重构

AI 可以帮助：

• 写代码
• 查 Bug
• 生成测试
• 分析代码
• 重构
• 生成文档
• Code Review
• 分析技术方案

但是最终应该由开发者负责：

• 需求理解
• 架构决策
• 模块边界
• 技术选型
• 数据结构
• 接口设计
• 代码质量
• 软件整体结构

五、一个非常重要的能力：软件设计

例如现在需要实现一个 GIS 模型加载功能。

最简单的思考方式：

点击按钮 ↓ 选择文件 ↓ 加载模型

但是工程化之后，需要考虑：

用户选择文件 ↓ 文件格式检查 ↓ 文件存在性检查 ↓ 模型解析 ↓ 坐标系检查 ↓ 坐标转换 ↓ 模型加载 ↓ 加载进度反馈 ↓ 加载成功 / 失败 ↓ 资源管理 ↓ 场景管理

进一步还需要考虑：

• 如果文件不存在怎么办？
• 如果文件格式错误怎么办？
• 如果模型非常大怎么办？
• 如果用户中途取消怎么办？
• 如果加载失败怎么办？
• 如果模型已经加载过怎么办？
• 如果坐标系错误怎么办？
• 如果同时加载多个模型怎么办？
• 如果关闭项目怎么办？
• 下次打开项目是否需要重新加载？

这就是：

从“实现功能”转向“设计软件”。

六、工程能力的核心概念

在学习过程中，需要逐渐掌握以下概念。

6.1 高内聚

一个模块应该尽量只负责一类相关事情。

例如：

ModelService

主要负责模型相关业务，而不是同时负责：

ModelService ├── 模型加载 ├── UI DOM 操作 ├── 文件选择框 ├── 日志输出 ├── 数据库操作 └── 用户权限

6.2 低耦合

模块之间应该尽量减少直接依赖。

例如：

业务代码 ↓ 内部接口 ↓ 具体实现

而不是：

业务代码 ↓ 直接调用第三方 GIS SDK ↓ 直接操作 Electron API ↓ 直接操作文件系统

这样以后更换技术方案时，会容易很多。

6.3 接口与抽象

例如模型加载：

ModelLoader │ ├── OSGBLoader ├── Tiles3DLoader ├── GLTFLoader └── OBJLoader

业务层只关心：

load()

而不需要知道具体实现。

6.4 可扩展性

好的设计应该尽量做到：

增加新功能时，主要是增加代码，而不是大量修改旧代码。

例如：

ModelLoader │ ├── OSGB ├── 3DTiles ├── GLTF └── 新格式

以后增加新格式时，不应该把整个系统重新修改一遍。

七、AI 编程时应该建立固定工作流

以后可以逐渐形成自己的 AI Coding Workflow。

Step 1：先让 AI 分析需求

不要直接让 AI 写代码。

先问：

请先分析这个需求涉及哪些模块， 不要写代码。 请告诉我： 1. 功能边界 2. 模块划分 3. 数据流 4. 状态变化 5. 异常情况 6. 潜在风险

Step 2：让 AI 给出技术方案

请给出两个或三个实现方案， 分析它们的优缺点。 不要直接写代码。

Step 3：确定模块边界

例如：

UI │ ↓ ModelService │ ├── ModelLoader ├── CoordinateService └── SceneService

Step 4：定义接口

先确定：

ModelLoader ↓ load() cancel() getProgress() dispose()

然后再写具体实现。

Step 5：让 AI 编写代码

这时候 AI 才开始真正进入“施工阶段”。

Step 6：让 AI 做 Code Review

可以固定询问：

请从以下方面 Review 这段代码： 1. 是否存在高耦合？ 2. 是否违反单一职责？ 3. 是否存在重复代码？ 4. 是否存在隐藏状态？ 5. 是否存在资源泄漏？ 6. 是否存在异常处理缺失？ 7. 是否容易测试？ 8. 如果需求发生变化，哪里最难修改？ 9. 是否存在过度设计？ 10. 是否存在潜在 Bug？

Step 7：测试

至少考虑：

正常情况 异常情况 边界情况 并发情况 用户取消 资源释放 重复操作

Step 8：重构

最终形成：

需求 ↓ 设计 ↓ AI 实现 ↓ 测试 ↓ Review ↓ 重构

而不是：

需求 ↓ AI 写代码 ↓ 不断打补丁

八、结合 GIS + Electron 项目进行训练

目前正在接触的技术栈非常适合训练软件工程能力。

例如：

Electron │ ├── Renderer │ ├── Main Process │ └── IPC │ ↓ GIS Engine │ ├── 3D Tiles ├── OSGB ├── GLTF └── Terrain

如果进一步涉及：

ZMQ ↓ 后台服务 ↓ GIS ↓ AI

还可以进一步训练：

• 进程间通信
• 消息通信
• 异步任务
• 状态管理
• 错误处理
• 资源管理
• 网络通信
• 并发
• 服务拆分

这些都属于非常有价值的软件工程训练。

九、学习过程中不要追求“设计得越复杂越好”

这是非常重要的一点。

学习架构以后，很容易产生一个误区：

interface factory service repository adapter facade controller ...

然后一个简单功能写成几百行代码。

这并不是好的架构。

真正应该追求的是：

合适的复杂度。

也就是说：

简单需求 ↓ 简单设计 复杂需求 ↓ 复杂设计

而不是：

简单需求 ↓ 复杂设计

因此学习架构的目的不是：

“把项目设计得高级。”

而是：

在面对复杂度时，有能力控制复杂度。

十、五个核心学习资源

下面按照推荐学习顺序排列。

第一阶段 ⭐⭐⭐⭐⭐

1. MIT Software Construction

目标

建立真正的软件工程基本功。

重点学习：

• Specification
• Testing
• Debugging
• Code Review
• Git
• Abstract Data Types
• Interface
• Immutability
• Design Patterns
• Concurrency
• Thread Safety
• Networking

核心目标：

让代码安全、容易理解、容易修改。

这门课特别适合作为第一阶段，因为它不是单纯教“怎么写代码”，而是在训练：

如何构建能够长期维护的软件。

建议学习方式：

学习一个概念 ↓ 理解概念 ↓ 在自己的 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

真正需要理解的是：

为什么代码需要重构？

以及：

什么时候应该重构？

例如：

一个函数 300 行 ↓ 为什么有问题？ ↓ 职责是否太多？ ↓ 哪些部分可以独立？ ↓ 拆分 ↓ 测试 ↓ 继续观察

这本书对于 AI 编程尤其重要。

因为 AI 很容易快速生成大量代码，而重构能力决定了你能不能把这些代码逐渐整理成一个长期可维护的系统。

第三阶段 ⭐⭐⭐⭐

3. 《设计模式》

目标

学习如何解决反复出现的软件设计问题。

重点理解：

• Strategy
• Factory
• Observer
• Adapter
• Facade
• Command
• State
• Dependency Injection
• Composition

不要把重点放在：

“背 23 种设计模式。”

而应该放在：

为什么这个问题需要这种设计？

例如 GIS 模型加载：

ModelLoader │ ├── OSGBLoader ├── Tiles3DLoader ├── GLTFLoader └── OBJLoader

这里可以学习：

• Strategy
• Factory
• Interface
• Dependency Injection

第四阶段 ⭐⭐⭐⭐

4. Clean Architecture

目标

开始建立真正的架构思维。

重点理解：

UI ↓ Application ↓ Domain ↓ Infrastructure

以及：

• Dependency Rule
• Boundary
• Separation of Concerns
• Dependency Inversion
• Use Case
• Entity
• Adapter

需要特别注意：

Clean Architecture 是帮助你理解架构原则的工具，而不是要求所有项目都严格按照固定模板实现。

不要为了“架构”而架构。

应该根据项目复杂度决定：

小项目 ↓ 简单模块化 中型项目 ↓ 分层 + 明确边界 大型项目 ↓ 进一步考虑领域、基础设施、系统边界

第五阶段 ⭐⭐⭐⭐

5. Designing Data-Intensive Applications

作者：Martin Kleppmann

简称：

DDIA

这是从“软件工程 / 软件设计”继续向“系统设计”发展的重要一步。

重点学习：

• Database
• Storage
• Replication
• Partitioning
• Distributed Systems
• Transactions
• Consistency
• Batch Processing
• Stream Processing
• Message Systems
• Data Models

它解决的是更大规模的问题：

一个程序 ↓ 多个模块 ↓ 多个进程 ↓ 多个服务 ↓ 多个机器 ↓ 大量数据 ↓ 分布式系统

对于以后接触：

• GIS 数据平台
• 遥感数据处理
• 超算
• AI 服务
• ZMQ
• 消息队列
• 大规模空间数据

都会非常有价值。

十一、最终学习顺序

按照这个顺序学习：

AI 编程 │ ↓ ┌──────────────────────────┐ │ 1. MIT Software │ │ Construction │ │ │ │ 软件工程基本功 │ └────────────┬─────────────┘ ↓ ┌──────────────────────────┐ │ 2. Refactoring │ │ 《重构》 │ │ │ │ 代码质量 / 可维护性 │ └────────────┬─────────────┘ ↓ ┌──────────────────────────┐ │ 3. Design Patterns │ │ 《设计模式》 │ │ │ │ 软件设计 / 抽象 / 解耦 │ └────────────┬─────────────┘ ↓ ┌──────────────────────────┐ │ 4. Clean Architecture │ │ │ │ 系统架构 / 模块边界 │ └────────────┬─────────────┘ ↓ ┌──────────────────────────┐ │ 5. DDIA │ │ Designing Data- │ │ Intensive Applications│ │ │ │ 系统设计 / 分布式系统 │ └──────────────────────────┘

最终形成：

写代码 ↓ 软件工程 ↓ 软件设计 ↓ 架构设计 ↓ 系统设计

十二、最重要的学习原则

不要采用：

看书 ↓ 记笔记 ↓ 看下一本书 ↓ 继续记笔记

而应该采用：

学习概念 ↓ 寻找真实项目中的问题 ↓ 用概念分析问题 ↓ 修改项目 ↓ 让 AI 辅助实现 ↓ Review ↓ 测试 ↓ 重构

也就是说：

用项目学习，而不是用书本学习。

十三、最终目标

最终不是为了成为：

“最懂设计模式的人。”

也不是为了成为：

“最懂架构的人。”

而是为了成为：

一个能够利用 AI 高效率构建、维护和演进软件的人。

理想状态应该是：

你 │ ├── 理解需求 ├── 做产品判断 ├── 设计系统 ├── 划分模块 ├── 定义接口 ├── 控制复杂度 └── 做技术决策 │ ↓ AI │ ├── 生成代码 ├── 生成测试 ├── 分析 Bug ├── Code Review ├── 重构 └── 生成文档 │ ↓ 最终软件

这样，AI 越强，你的生产力反而越高。

因为你不再只是：

“让 AI 帮我写代码。”

而是：

“我知道我要构建什么，也知道应该怎样构建，让 AI 帮我把它快速实现出来。”

这才是 AI 编程时代真正值得培养的核心能力。

十四、最终路线总结

最终形成：

软件工程 → 重构 → 软件设计 → 架构 → 系统设计

而 AI 则贯穿整个过程，成为你的：

编码助手 + 测试助手 + Review 助手 + 重构助手 + 架构讨论伙伴。

核心思想：不要和 AI 比谁写代码快，而要提升自己“设计和构建软件”的能力。

最后经过提炼，把这五步按照工程学和架构知识进行提炼，总结了五篇文档如下：
1.MIT Software Construction：软件工程核心知识提炼
2.《重构》：代码质量与持续演进能力提炼
3.《设计模式》：软件设计与解耦能力提炼
4.Clean Architecture：架构与系统边界能力提炼
5.《Designing Data-Intensive Applications》：系统设计与分布式能力提炼