docs: fundamentals - classify engineering method docs

assets/documents/AGENTS.md

@@ -9,12 +9,13 @@
 ```
 assets/documents/
 ├── principles/          # 原则与思想（fundamentals + philosophy）
-│   ├── fundamentals/    # 原 00-基础指南
+│   ├── fundamentals/    # 基础原则、问题求解、工程范式与代码质量
 │   └── philosophy/      # 原 05-哲学与方法论
 ├── guides/              # 入门与方法（getting-started + playbook）
 │   ├── getting-started/ # 原 01-入门指南
 │   └── playbook/        # 原 02-方法论
-└── case-studies/        # 原 03-实战
+├── case-studies/        # 原 03-实战
+└── workflow/            # 可复用工作流模板
 ```
 
 ## 操作规范

assets/documents/README.md

@@ -27,14 +27,17 @@ assets/documents/
 
 ## 📖 推荐学习路径
 
-1. **思维** → [philosophy](./principles/philosophy/README.md)
-2. **理念** → [胶水编程](./principles/fundamentals/胶水编程.md)
-3. **入门** → [Vibe Coding 哲学原理](./guides/getting-started/Vibe%20Coding%20哲学原理.md)
-4. **配置** → [开发环境搭建](./guides/getting-started/开发环境搭建.md)
-5. **工具** → [tmux 快捷键](./guides/playbook/tmux快捷键大全.md)
-6. **远程** → [VS Code Remote Tunnel（WSL）](./guides/playbook/REMOTE_TUNNEL_GUIDE.md)
-7. **实践** → [项目实战经验](./case-studies/)
-8. **流程** → [工作流模板](./workflow/)
+1. **问题** → [问题求解能力](./principles/fundamentals/问题求解能力.md)
+2. **工程** → [问题分析与系统构建方法](./principles/fundamentals/问题分析与系统构建方法.md)
+3. **范式** → [软件开发范式演进](./principles/fundamentals/软件开发范式演进.md)
+4. **思维** → [philosophy](./principles/philosophy/README.md)
+5. **理念** → [胶水编程](./principles/fundamentals/胶水编程.md)
+6. **入门** → [Vibe Coding 哲学原理](./guides/getting-started/Vibe%20Coding%20哲学原理.md)
+7. **配置** → [开发环境搭建](./guides/getting-started/开发环境搭建.md)
+8. **工具** → [tmux 快捷键](./guides/playbook/tmux快捷键大全.md)
+9. **远程** → [VS Code Remote Tunnel（WSL）](./guides/playbook/REMOTE_TUNNEL_GUIDE.md)
+10. **实践** → [项目实战经验](./case-studies/)
+11. **流程** → [工作流模板](./workflow/)
 
 ## 🔗 相关资源
 

assets/documents/principles/fundamentals/README.md

@@ -12,6 +12,11 @@
 - [递归自优化系统形式化](./A%20Formalization%20of%20Recursive%20Self-Optimizing%20Generative%20Systems.md) - 元方法论
 - [编程之道](./编程之道.md) - 编程哲学
 
+### 软件工程基础
+- [问题求解能力](./问题求解能力.md) - 目标、现状、差距、标准与反馈迭代的底层能力
+- [问题分析与系统构建方法](./问题分析与系统构建方法.md) - 自顶向下、自底向上与分而治之的组合使用
+- [软件开发范式演进](./软件开发范式演进.md) - 从面向过程到云原生的工程组织方式演进
+
 ### 提示词工程
 - [系统提示词构建原则](./系统提示词构建原则.md) - 构建高效 AI 系统提示词
 

assets/documents/principles/fundamentals/软件开发范式演进.md

@@ -0,0 +1,22 @@
+# 软件开发范式演进
+
+软件开发范式的演进可以概括为一组随工程复杂度提升而逐步形成的设计思想与组织方式，而非严格的历史线性阶段或全球统一的标准分期。
+
+## 主要演进方向
+
+1. 面向过程编程
+以执行流程为核心，将代码按照步骤、函数和过程进行组织，强调程序逻辑的顺序性与可执行性。
+
+2. 面向对象编程
+将数据与行为封装为对象，通过类、对象、继承、多态等机制组织系统结构，提高代码的封装性、复用性和可维护性。
+
+3. 面向接口与抽象编程
+强调模块应依赖接口或抽象，而非直接依赖具体实现类，以降低模块间耦合度，提升系统的扩展性与可替换性。
+
+4. 组件化、分层架构与依赖注入
+将系统拆分为职责明确、边界清晰、可组合和可替换的模块或组件，并通过分层设计和依赖注入机制管理模块间关系，增强系统的结构化程度和可维护性。
+
+5. 服务化、微服务与云原生架构
+在模块化基础上，将系统进一步拆分为可独立开发、部署、扩展和运维的服务单元，并结合云原生理念提升系统的弹性、可扩展性和工程协作效率。
+
+上述内容并不表示软件开发存在固定、统一或严格递进的阶段划分。不同范式和架构思想往往并存，并会根据项目规模、业务复杂度、团队协作方式和技术环境被组合使用。

assets/documents/principles/fundamentals/问题分析与系统构建方法.md

@@ -0,0 +1,142 @@
+# 问题分析与系统构建方法
+
+软件工程中的自顶向下、自底向上和分而治之，是三种经典的问题分析与系统构建方法。
+
+## 一、自顶向下：先看整体，再拆细节
+
+**自顶向下**的核心思路是：先明确系统整体要做什么，再逐层拆分成子系统、模块、类、函数，最后落实到具体代码实现。
+
+比如要开发一个在线购物系统，采用自顶向下的方法时，通常会先问：
+
+这个系统的总体目标是什么？
+它需要支持哪些核心业务？
+整体架构应该如何划分？
+
+然后再逐步拆解：
+
+在线购物系统
+→ 用户模块、商品模块、购物车模块、订单模块、支付模块、物流模块
+→ 订单模块
+→ 创建订单、取消订单、查询订单、订单状态流转
+→ 创建订单函数
+→ 参数校验、库存检查、价格计算、订单保存、消息通知
+
+这种方法的优势是**全局结构清晰**。系统从一开始就有比较明确的架构边界，模块之间的关系也更容易统一规划。对于需求比较明确、规模较大的系统，例如银行核心系统、企业 ERP 系统、政务平台、基础设施平台等，自顶向下非常常见。
+
+它的缺点是，如果一开始对需求理解不准确，高层设计可能会出现偏差，后续细节实现时就会频繁返工。因此，自顶向下适合需求相对清楚、业务边界比较稳定的场景。
+
+## 二、自底向上：先做组件，再组系统
+
+**自底向上**的核心思路是：先从基础能力、底层组件、工具模块开始建设，再逐步组合成更大的功能和完整系统。
+
+比如还是开发在线购物系统，采用自底向上的方法时，可能会先实现：
+
+日志组件
+配置管理组件
+数据库访问组件
+缓存组件
+权限校验组件
+消息队列封装
+通用异常处理模块
+支付 SDK 封装
+
+当这些基础组件逐渐稳定后，再用它们组合出商品服务、订单服务、支付服务等业务模块，最终形成完整系统。
+
+这种方法的优势是**复用性强、基础能力扎实**。团队可以不断沉淀通用模块，后续开发新功能时就不需要重复造轮子。对于已有技术平台、组件库、框架体系的团队来说，自底向上很自然。
+
+它也适合需求还在演化的项目。因为业务目标可能一开始并不完全清楚，但团队可以先建设确定性较高的底层能力，等需求逐渐明确后再组合成业务系统。
+
+它的风险是，如果只关注底层组件而缺乏整体目标，可能会出现“组件很多，但系统拼不起来”的问题。也就是说，自底向上容易造成局部能力很强，但整体架构不够统一。
+
+## 三、分而治之：把复杂问题拆成小问题
+
+**分而治之**的核心思想是：面对复杂问题时，不直接一次性解决整体，而是把它拆成若干相对独立、规模更小的问题，分别解决后再组合起来。
+
+它更像是一种通用的问题处理原则，不只是软件工程中的系统构建方法，也广泛存在于算法设计、项目管理、组织协作中。
+
+比如开发一个推荐系统，可以把问题拆成：
+
+数据采集
+用户画像
+商品画像
+召回算法
+排序算法
+特征工程
+模型训练
+在线推理
+效果评估
+
+每个部分都可以由不同团队或不同模块独立推进，最后再集成为完整的推荐系统。
+
+分而治之的优点是**降低复杂度**。一个大问题往往难以直接理解和实现，但拆成多个小问题后，每个小问题的目标更清晰、测试更容易、维护成本也更低。
+
+不过，分而治之的关键在于“如何拆”。如果拆分边界不合理，就会导致模块之间耦合严重、接口混乱、集成困难。好的拆分应该尽量做到高内聚、低耦合：每个模块内部职责集中，模块之间通过清晰接口协作。
+
+## 四、三者之间的关系
+
+这三种方法并不是完全独立的。
+
+**自顶向下**强调从整体到局部，通常会用到分而治之。因为从系统目标拆到模块、从模块拆到函数，本质上就是在分解问题。
+
+**自底向上**强调从局部到整体，也可以结合分而治之。先分别解决多个基础能力或局部问题，再逐步组合成更复杂的系统。
+
+**分而治之**则更像是底层思想，它既可以服务于自顶向下，也可以服务于自底向上。
+
+可以简单理解为：
+
+自顶向下回答的是：**从哪里开始设计？**
+自底向上回答的是：**从哪里开始实现？**
+分而治之回答的是：**如何降低复杂度？**
+
+## 五、举一个综合例子
+
+假设要开发一个企业内部审批系统。
+
+采用自顶向下时，团队会先定义系统整体架构：
+
+审批系统
+→ 表单管理
+→ 流程管理
+→ 权限管理
+→ 通知管理
+→ 审批记录
+→ 数据报表
+
+然后继续拆解流程管理：
+
+流程定义
+流程发起
+节点审批
+流程转交
+流程撤回
+流程归档
+
+采用自底向上时，团队可能会先建设一些基础能力：
+
+用户身份认证
+角色权限模型
+表单渲染引擎
+消息通知组件
+流程状态机
+审计日志组件
+数据库访问层
+
+这些组件稳定后，再组合成完整的审批业务。
+
+而分而治之贯穿整个过程：无论是把审批系统拆成表单、流程、权限、通知，还是把流程引擎拆成状态流转、节点规则、审批人计算、超时处理，都是在通过拆分降低复杂度。
+
+## 六、实际项目中如何选择
+
+如果项目目标清晰、业务边界稳定、系统规模较大，可以优先采用**自顶向下**，先做好架构设计和模块划分。
+
+如果团队已有大量基础组件，或者项目需求还在逐步演化，可以更多采用**自底向上**，先沉淀稳定的底层能力，再支撑业务扩展。
+
+如果问题本身很复杂，无论采用哪种方向，都应该使用**分而治之**，把复杂系统拆成更容易理解、开发、测试和维护的部分。
+
+在真实软件工程中，最常见的做法是：
+先用**自顶向下**明确系统目标和架构边界；
+再用**分而治之**拆分模块和任务；
+同时用**自底向上**建设可复用组件和基础能力；
+最后通过迭代开发不断调整设计。
+
+所以，这三种方法不是“选一个、排斥另外两个”，而是从不同角度帮助我们管理复杂度、组织代码和构建系统。