06-服务器与三系统边界
服务器：入口系统如何与业务、网络两系统接边界
服务器不是「业务之上多了一层通信层」。服务器本身是一个完整的入口系统——长期运行、并发调度、解析分发。它落在三系统边界的上端：入口系统（服务器）+ 业务系统 + 网络系统。这一篇讲服务器如何进入这个边界，以及它和 CLI、业务库、网络系统的分工。
一、服务器 vs CLI：都是入口，但形态完全不同CLI 的核心是「一次任务的执行入口」，服务器的核心是「长期运行的服务入口 + 并发请求调度」。
12345678CLI： 启动 → 解析参数 → 执行任务 → 输出结果 → 退出 （一次执行，一个任务，顺序执行）Server： 启动 → 初始化 → 监听端口 → 等待请求 → 收到请求 → 解析请求 → 调用业务 → 生成响应 → 继续等待请求 → …… （长期运行，大量请求，并发处理）
CLI 的「命令」变成了 Server 的「请求处理器」：
12345CLI：mytool process --pid 1234 ProcessCommand → ProcessService → ProcessManagerHTTP：POST ...
05-基础设施与角色全图
基础设施与角色全图
三大系统类型（入口/通信/业务）之外，还有基础设施——平台能力（文件/网络/内存/系统 API）。完整看，程序由四类角色组成：入口、通信、业务、基础设施，外加一个组装者（入口：main / Server / Application）。这一篇补上基础设施，画出角色全图。
一、基础设施：第四类角色基础设施提供平台能力，被其他角色调用：
1234567基础设施├── 文件系统 read / write / open├── 网络 socket / connect / send / recv├── 内存 分配 / 映射 / 释放├── 进程/线程 create / join / 同步├── 平台 API Win32 / Linux / 系统调用└── 第三方库 加密 / 压缩 / 图形
它与三大系统类型的区别：
1234入口系统：输入 → 调用（面向用户）通信系统：通信 → 消息（面向网络）业务系统：问题 → 解决（面向业务）基 ...
04-通信系统
通信系统：把外部通信转换成内部消息
通信系统是程序的第三个角色——把外部通信（字节/数据报）转换成系统内部消息，并把结果转换回通信数据。通信系统按组件组织（不是按模块，也不是分层），组件内部再按数据/算法/接口组织。网络系统是通信系统的组件组织实例。
通信系统不是和「服务器」并列的第四个系统。 cli / gui / 服务器都是入口系统；通信系统是可选第三角色——只有需要对外通信的程序才有（服务器、联网客户端），纯 CLI / 纯 GUI 没有。「通信系统」就是「网络系统」：通信系统是角色（抽象），网络系统是它的组件组织实例（具体形态）。
一、通信系统是什么通信系统的职责一句话：
把外部通信转换成系统内部消息，并把结果转换回通信数据。
123456789外部通信（字节流/数据报） ↓通信系统 ↓系统内部消息 ↓ 业务处理完通信系统 ↓外部通信（响应）
它与入口系统的区别：
12入口系统：用户输入 → 系统调用（用户操作）通信系统：外部通信 → 内部消息（网络数据）
什么样的程序有通信系统？
1234CLI（ ...
03-业务系统
业务系统：真正完成程序要解决的问题
业务系统是程序的第二个角色——它真正完成程序要解决的问题。其他角色（入口、通信）都是围绕它转的：入口把输入送进来，通信把消息送进来，业务系统把问题解决掉。业务系统按模块组织，模块 = 数据结构 + 算法 + 接口。
一、业务系统是什么业务系统的职责一句话：
真正完成程序要解决的问题。
123入口系统：输入怎么进来 → 调用业务通信系统：消息怎么收发 → 调用业务业务系统：问题怎么解决 ← 被调用
其他角色都是「围绕业务转」的——业务系统才是程序存在的理由。
二、业务系统的组织单位：模块业务系统的核心组织单位是模块：
1234业务系统├── Service 业务任务组织├── Domain 业务数据结构（ProcessInfo 等业务对象）└── Algorithm 业务算法
模块内部：
1234模块├── 原子接口 （怎么被调用）├── 数据结构 （数据怎么表示）└── 算法 （怎么计算）
业务系统的核心组织单位就是模块，模块内部再由接口、数据结构、算 ...
02-入口系统
入口系统：把外部输入转换成系统调用
入口系统是程序的第一个角色——它不解决业务问题，它负责「外部输入怎么进来、怎么找到对应的功能、怎么调用」。CLI 入口按命令组织，GUI 入口按页面组织，Server 入口按请求组织。入口系统的形态决定程序对外的样子。
一、入口系统是什么入口系统的职责一句话：
把外部输入转换成系统调用。
12345外部输入（命令/点击/请求） ↓入口系统 ↓系统调用（调用业务接口）
它不关心业务怎么实现，只关心「输入怎么进来、怎么找到功能、怎么返回结果」。
二、入口的骨架所有入口共享同一个骨架（从指令到系统主线的结论）：
1接受 → 解析 → 分发 → 调用 → 业务
1234接受：外部输入进来了解析：输入是什么意思（命令名？页面？请求路径？）分发：这个输入对应哪个功能调用：调用业务接口
三、三种入口形态CLI 入口：按命令组织12345CLI 入口系统├── 参数解析 parse(argc, argv)├── 命令解析 输入的是什么命令├── 分发 找到对应的 Command└── 调用 调用业务接 ...
01-三大系统类型
三大系统类型：入口 / 通信 / 业务
程序可以按角色分成三大系统类型：入口系统（把外部输入转换成系统调用）、通信系统（把外部通信转换成内部消息）、业务系统（真正完成程序要解决的问题）。三种角色职责完全不同，内部组织方式不同，设计路线也不同。这是系统角色组成的核心。
一、程序的三分结构12345678910111213141516171819程序│├── 入口系统│ ├── CLI入口│ ├── GUI入口│ └── Server入口│├── 通信系统│ ├── 网络组件│ ├── 传输组件│ ├── 会话组件│ ├── 协议组件│ ├── 编解码组件│ └── 通信调度组件│└── 业务系统 ├── Service 任务组织 ├── Domain 业务数据结构 └── Algorithm 业务算法
三种角色的职责：
123入口系统：把外部输入转换成系统调用通信系统：把外部通信转换成系统内部消息，并把结果转换回通信数据业务系统：真正完成程序要解决的问题
二、入口系统 v ...
06-知识体系文章的生成机制
知识体系文章的生成机制
前几篇解决了「模型怎么产生、怎么应用、怎么循环」。这一篇解决下一个问题：这些模型怎么组织成一套知识体系文章？ 答案是两类文章：正向建模文章（从具体事物不断形成更大的模型）与逆向应用文章（用已有模型解构陌生但同类的事物）；文章之间层层递进，下一篇因为上一层模型「不够用」而产生更大建模——由此形成「知识模型演化树」。最后要区分：知识体系是底层结构，知识体系文章只是对这个结构的一种叙事展开。
一、两条主线：正向建模与逆向应用「知识体系文章」的生成机制，可以分成两条主线。
1. 正向：从具体事物不断形成更大的模型文章不是一篇篇孤立的知识点，而应该形成一个模型演化链：
123456789101112131415161718192021具体事物 A ↓观察 / 演示 ↓总结共同结构 ↓模型 M1 ↓遇到具体事物 B ↓发现 M1 无法完整解释 ↓扩展 / 修正 ↓模型 M2 ↓遇到具体事物 C ↓再次扩展 ↓模型 M3
所以文章之间可以表现成：
123456789第1篇：从具体现象得到模型 M1 ↓第2篇：M1 解释新的具体现象，但出现边界 ↓ ...
05-建模的完整机制
建模的完整机制——从解构到可用的模型
正向建模回答「模型从哪里来」（观察→比较→抽象→命名）。但一次完整的建模，细节远比四步多：解构要找到的是稳定关系，抽象不是删除细节而是保留重要关系，模型是有目的的结构，分类也是建模，概念与模型不同，模型可以组合、有层级，具体化是建模的反方向，而验证让模型逐渐接近现实。 本篇是正向建模（03-建模与逆向/01）的完整展开。
一、具体事物不是模型三个不同的游戏：平台跳跃、射击、解谜。
直接记忆每个游戏的所有细节，得到的是「三个游戏的清单」。但它们有共同结构：
1234567玩家 ↓操作角色 ↓影响世界状态 ↓达成目标
模型不是某一个具体事物，而是多个具体事物共有的结构。 单独一个例子无法建模——建模需要多个实例，才能分辨「哪些是巧合、哪些是结构」。
二、解构不是简单地「拆东西」把汽车拆成零件：发动机、车轮、方向盘……这只是罗列。
解构真正的重点是：找到部分之间稳定的关系。
123方向盘 → 控制 → 车轮转向油门 → 控制 → 发动机转速发动机 → 驱动 → 车轮
同样的零件，如果关系不同，就是不同的系统。解构 = 拆出对象 + ...
04-模型转为流程
模型转为流程：把模型展开成一步步可执行的步骤
正向建模得到模型，逆向应用用模型解构事物。但「用模型解决问题」在真实工程里还有一个必经环节：模型本身还不是步骤——要把模型转成流程（步骤序列），才能一步步去解析事物或解决问题。这一条线讲：模型怎么被展开成流程（依赖 → 拓扑排序 → 实现步骤），步骤的单位是什么（可验证的步骤），以及步骤的三种顺序（架构/实现/验证）怎么区分。
一、模型不是步骤模型是「对一类事物的压缩描述」，它不是「一步步怎么做」：
12345模型（循环）：重复执行某个过程 → 知道「是什么」，不知道「先做什么后做什么」模型（ECS）：Entity + Component + System → 知道「由什么组成」，不知道「从 0 到 1 先写哪个文件」
正向建模回答「事物由什么构成」，逆向应用回答「用模型怎么识别事物」，模型转为流程回答「按什么步骤把模型落地」。 前两者解决「理解」，后者解决「执行」。
二、为什么需要把模型转成流程模型给出了结构，但执行需要顺序：
12345模型：Vector2 → Entity → Component → R ...
03-双向循环
双向循环：正向与逆向不断交替
正向建模和逆向应用不是两个独立阶段，而是一个循环。模型建立后用于解决新问题（逆向），新问题暴露模型的不足，反过来修正模型（正向）。模型不是最终答案，而是当前阶段对一类具体事物的压缩描述——它一直在被使用、被挑战、被修正。
一、它不是单向的最朴素的误解是：先正向（学模型），后逆向（用模型），然后结束。
实际是循环：
12345678910111213141516171819┌──────────────┐│ 具体问题 │└──────┬───────┘ ↓ 观察 比较 ↓ 提取共同性 ↓ 抽象模型 ↓ 用模型预测 ↓ 应用于新问题 ↓ 发现模型不够 ↓ 修正模型 │ └──────────→ 再次抽象
正向产生模型，逆向使用模型，使用中发现问题，又回到正向修正模型。
二、循环的每一步都会发生以「游戏 = 输入 → 更新 → 渲染」为例：
123456789101112131415正向：做了几个小 ...