feat(docs): restructure API design guide with interactive demos and practical examples

refactor(components): replace static API design components with interactive demos - Add ApiRequestDemo, RestfulUrlDemo, StatusCodeDemo, ErrorHandlingDemo, and ApiVersioningDemo - Remove outdated ResourceAnalogy, RequestStructureDemo, and VersioningStrategyDemo docs(api-design): completely rewrite API design chapter with restaurant analogy - Add clear problem scenarios and solutions - Include practical e-commerce API examples - Add terminology glossary - Improve error handling and versioning sections style(ai-history): enhance FoundationDemo with better visual hierarchy - Add section blocks for core theories and early breakthroughs - Improve typography and highlighting chore: remove unused components (CpuArchitectureDemo, EvolutionFlowDemo)
2026-02-22 23:20:27 +08:00
parent e5a5b9df5b
commit 5b622800b8
26 changed files with 3217 additions and 4784 deletions
@@ -193,7 +193,16 @@

 ### 4.1 CPU 的核心组件

-<CpuArchitectureDemo />
+CPU 不是单一部件，而是多个功能单元协作工作：
+
+| 组件         | 做什么                         | 类比                     |
+| ------------ | ------------------------------ | ------------------------ |
+| **控制器**   | 取指、解码、发出控制信号       | 像指挥员，安排谁何时工作 |
+| **ALU**      | 加减、与、或、比较等运算       | 像计算器，做算术与逻辑   |
+| **寄存器组** | 保存最常用的数据和中间结果     | 像桌面便签，比内存更快   |
+| **内部总线** | 在模块间传数据、地址、控制信息 | 像高速通道，把组件连成整体 |
+
+一句话：控制器负责调度，ALU 负责计算，寄存器负责高速暂存，总线负责连接与传输。

 ### 4.2 CPU 是如何执行指令的？

@@ -231,9 +240,29 @@ CPU 执行一条指令，需要经过四个阶段：

 ## 5. 总结：从沙子到智能

-让我们回顾一下从晶体管到 CPU 的完整路径：
+每一层都是对下一层的抽象封装，从沙子到可运行软件的完整路径如下：

-<EvolutionFlowDemo />
+1. **沙子（硅）** — 原材料：地球上最丰富的元素之一，提炼出高纯度硅。  
+   ↓ 提纯 → 切割成晶圆
+
+2. **硅晶圆** — 基底：直径约 30cm 的单晶硅片，表面极其光滑。  
+   ↓ 光刻 → 蚀刻 → 掺杂
+
+3. **晶体管（开关）** — 数百亿个/芯片：Gate=1 导通，Gate=0 断开，用电压控制电流。  
+   ↓ 组合成逻辑电路
+
+4. **逻辑门** — 数十亿个：AND / OR / NOT / XOR，实现基本布尔运算。  
+   ↓ 组合成功能模块
+
+5. **功能单元** — 数百个：加法器、寄存器、多路选择器……各司其职。  
+   ↓ 集成为完整处理器
+
+6. **CPU 核心** — 1～128 核：ALU + 控制器 + 寄存器组，执行取指→解码→执行→写回。  
+   ↓ 软件编程
+
+7. **软件应用** — 无限可能：操作系统 / AI 模型 / 游戏 / 网页……一切皆指令。
+
+计算机的本质是「开关的组合」：通过一层层抽象封装，最底层的物理材料最终变成能执行任意逻辑的通用计算平台。

 ::: tip 核心启示
 **计算机的本质是"开关的组合"**。
@@ -1,124 +1,309 @@
-# API 设计：前后端的通用语言
+# API 设计：前后端的"对话协议"

-> 💡 **学习指南**：这一章我们聊聊前后端如何高效对话。如果你被后端接口的命名搞晕过，或者不知道该返回 200 还是 404，这篇文章就是为你准备的。我们将通过一个交互式 Demo，带你理解 RESTful API 的设计精髓。
+::: tip 🎯 核心问题
+**前后端如何高效对话？** 这就像问：餐厅的菜单怎么设计，客人一看就懂？服务员怎么记单，不会出错？上菜怎么规范，客人满意？API 设计解决的就是"对话规则"的问题。
+:::

 ---

 ## 0. 先问一个问题：你有没有经历过这些噩梦？

-**场景一：接口猜谜**
+**场景一：接口命名随心所欲**

-后端给你一个接口 `/getUser`，你调用了，返回 `null`。
-你是传错了参数？还是数据库没数据？还是服务器崩了？完全不知道。
+```
+GET /getUserData
+GET /fetchUserInfo
+GET /queryUserById
+GET /users/query
+```

-**场景二：状态码撒谎**
+四个接口，功能一样，命名风格完全不同。新人入职一脸懵：我该用哪个？
+
+**场景二：错误处理五花八门**
+
+```json
+// 有的返回 HTTP 状态码
+HTTP/1.1 404 Not Found
+
+// 有的返回 200 + code
+HTTP/1.1 200 OK
+{ "code": 404, "message": "用户不存在" }
+
+// 有的直接抛异常
+HTTP/1.1 200 OK
+{ "error": "出错了" }
+```
+
+前端不知道该怎么判断请求是否成功。
+
+**场景三：响应结构千人千面**
+
+```json
+// 接口 A
+{ "data": { ... } }
+
+// 接口 B
+{ "result": { ... } }
+
+// 接口 C
+{ "content": { ... } }
+```
+
+每个接口返回格式都不一样，前端需要针对每个接口单独处理。
+
+---
+
+**好的 API 设计就像餐厅的点餐系统**——菜单清晰、流程规范、出错有提示。
+
+---
+
+## 1. 什么是 API？
+
+**API**（Application Programming Interface，应用程序编程接口）就是"程序之间对话的约定"。
+
+### 1.1 用餐厅来类比
+
+| 餐厅角色 | 对应概念 | 说明 |
+| :--- | :--- | :--- |
+| 菜单 | API 文档 | 告诉你有哪些"菜"可以点 |
+| 服务员 | HTTP 协议 | 标准化的"对话方式" |
+| 后厨 | 服务端 | 按"订单"处理请求 |
+| 上菜 | 响应 | 把结果返回给"客人" |
+
+### 1.2 一个完整的 API 请求
+
+👇 **动手试试看**：点击下方按钮，观察一次完整的 API 请求-响应流程：
+
+<ApiRequestDemo />
+
+---
+
+## 2. RESTful 设计：让 URL 会说话
+
+**REST**（Representational State Transfer）是一种架构风格，核心思想是：
+
+- 把网络上的事物抽象为"资源"（Resource）
+- 用 URL 标识资源
+- 用 HTTP 方法操作资源
+
+### 2.1 用仓库来类比
+
+| 仓库概念 | REST 对应 | 示例 |
+| :--- | :--- | :--- |
+| 货架地址 | URL | `/users`、`/orders` |
+| 操作方式 | HTTP 方法 | GET（查看）、POST（入库） |
+| 货物 | 资源 | 用户数据、订单数据 |
+
+**关键原则**：URL 是名词，不是动词。
+
+### 2.2 URL 设计规则
+
+👇 **动手试试看**：点击下方按钮，查看 RESTful URL 的正确与错误写法对比：
+
+<RestfulUrlDemo />
+
+### 2.3 HTTP 方法选择
+
+| 方法 | 用途 | 幂等性 | 安全性 | 典型场景 |
+| :--- | :--- | :--- | :--- | :--- |
+| **GET** | 获取资源 | 是 | 是 | 查询列表、查看详情 |
+| **POST** | 创建资源 | 否 | 否 | 新增用户、提交订单 |
+| **PUT** | 全量更新 | 是 | 否 | 替换整个用户资料 |
+| **PATCH** | 部分更新 | 否 | 否 | 只修改昵称 |
+| **DELETE** | 删除资源 | 是 | 否 | 删除用户、取消订单 |
+
+::: tip 💡 什么是幂等性？
+**幂等性**：多次执行结果相同。
+
+- **幂等的操作**（GET/PUT/DELETE）：点 10 次和点 1 次，结果一样
+- **不幂等的操作**（POST）：点 10 次，可能创建 10 个订单
+
+**解决方案**：POST 操作用唯一 ID 校验，避免重复处理。
+:::
+
+---
+
+## 3. 状态码：让错误"会说话"
+
+HTTP 状态码是服务器告诉客户端"发生了什么"的标准方式。
+
+### 3.1 状态码分类
+
+| 分类 | 含义 | 典型状态码 |
+| :--- | :--- | :--- |
+| **2xx** | 成功 | 200 OK、201 Created、204 No Content |
+| **3xx** | 重定向 | 301 永久移动、304 未修改 |
+| **4xx** | 客户端错误 | 400 参数错误、401 未认证、404 不存在 |
+| **5xx** | 服务端错误 | 500 内部错误、503 服务不可用 |
+
+### 3.2 常用状态码演示
+
+👇 **动手试试看**：点击下方按钮，了解常见状态码的含义：
+
+<StatusCodeDemo />
+
+---
+
+## 4. 错误处理：优雅地"拒绝"
+
+好的错误处理能让客户端"看状态码就知道怎么回事"，而不是去猜。
+
+### 4.1 错误处理的"避坑指南"
+
+**坑 1：所有错误都返回 200**
+
+```json
+// ❌ 错误做法
+HTTP/1.1 200 OK
+{ "error": "出错了" }
+```
+
+问题：缓存层会缓存这个"成功"响应，监控系统发现不了问题。
+
+**坑 2：错误信息太笼统**
+
+```json
+// ❌ 错误做法
+HTTP/1.1 400 Bad Request
+{ "message": "参数错误" }
+```
+
+问题：客户端不知道哪个参数错了、为什么错。
+
+**坑 3：暴露敏感信息**
+
+```json
+// ❌ 危险做法
+HTTP/1.1 500 Internal Server Error
+{ "stack": "at UserService.login...", "sql": "SELECT * FROM..." }
+```
+
+危险：暴露了代码结构、数据库查询，攻击者可以利用这些信息。
+
+### 4.2 正确的错误处理演示
+
+👇 **动手试试看**：对比"好的"和"差的"错误响应设计：
+
+<ErrorHandlingDemo />
+
+---
+
+## 5. 版本控制：API 的"向后兼容"
+
+### 5.1 为什么要版本控制？
+
+场景：你的 App 有 100 万用户，需要修改订单接口。
+
+**如果不做版本控制**：
+- 新 App 调用新接口 → 正常
+- 旧 App 调用新接口 → 字段缺失，崩溃！
+
+**正确的做法**：
+- `/v1/orders` - 旧接口，继续服务旧 App
+- `/v2/orders` - 新接口，新功能在这里
+
+### 5.2 版本控制策略
+
+| 策略 | 示例 | 优点 | 缺点 |
+| :--- | :--- | :--- | :--- |
+| **URL 路径** | `/v1/users` | 直观、易缓存 | URL 变长 |
+| **请求头** | `Accept: vnd.api.v2+json` | URL 干净 | 不便调试 |
+| **查询参数** | `/users?version=2` | 简单 | 不够标准 |
+
+### 5.3 版本控制演示
+
+👇 **动手试试看**：了解 API 版本控制的策略和最佳实践：
+
+<ApiVersioningDemo />
+
+---
+
+## 6. 响应结构：标准化的"数据契约"
+
+无论成功还是失败，响应结构应该保持一致：
+
+### 6.1 标准响应格式

-你收到了一个 HTTP 200 OK 的响应，心想“稳了”。
-结果打开 Body 一看：
 ```json
 {
-  "code": 500,
-  "msg": "系统内部错误",
-  "data": null
+  "code": 0,
+  "message": "success",
+  "data": { ... },
+  "request_id": "req-550e8400",
+  "timestamp": "2024-01-15T09:30:00.000Z"
 }
 ```
-浏览器缓存了它，监控系统认为它成功了，只有你的前端代码在风中凌乱。

-**场景三：版本地狱**
+| 字段 | 类型 | 说明 |
+| :--- | :--- | :--- |
+| `code` | number | 业务状态码，0 表示成功 |
+| `message` | string | 状态描述 |
+| `data` | any | 业务数据 |
+| `request_id` | string | 请求唯一标识，用于问题追踪 |
+| `timestamp` | string | 响应时间戳 |

-项目迭代了三年，你的代码里充满了这样的 URL：
- `/api/v1/user/update`
- `/api/v2/user/update_new`
- `/api/user/update_final_real`
+### 6.2 分页响应格式
+
+```json
+{
+  "code": 0,
+  "data": {
+    "items": [...],
+    "pagination": {
+      "page": 1,
+      "page_size": 20,
+      "total": 156,
+      "total_pages": 8
+    }
+  }
+}
+```
+
+::: tip 💡 为什么要 request_id？
+**request_id** 是问题追踪的关键：
+
+1. 用户反馈："支付失败，错误 ID 是 abc123"
+2. 技术人员直接在日志里搜索 abc123，立即定位问题
+3. 分布式系统中，每个服务都记录相同的 request_id，可以把所有相关日志聚合起来
+:::

 ---

-**API 设计就是为了解决这些问题。**
+## 7. 实战：电商系统 API 设计示例

-它就像餐厅的菜单和点餐流程：规定了我们**怎么点菜（请求）**、**怎么上菜（响应）**、**没菜了怎么办（错误处理）**。
+```
+# 用户模块
+GET    /v1/users                    # 获取用户列表
+POST   /v1/users                    # 创建新用户
+GET    /v1/users/{id}               # 获取用户详情
+PUT    /v1/users/{id}               # 全量更新用户
+PATCH  /v1/users/{id}               # 部分更新用户
+DELETE /v1/users/{id}               # 删除用户

-目前最流行的设计风格是 **RESTful**。
+# 订单模块
+GET    /v1/users/{id}/orders        # 获取某用户的订单
+POST   /v1/orders                   # 创建订单
+GET    /v1/orders/{id}              # 获取订单详情
+PATCH  /v1/orders/{id}/status       # 更新订单状态
+
+# 商品模块（复杂过滤用查询参数）
+GET    /v1/products?category=phone&price_max=5000&sort=price_desc&page=1
+```

 ---

-## 1. 核心概念：RESTful 是什么？
+## 名词速查表

-REST (Representational State Transfer) 听起来很学术，其实核心就三句话：
-
-1.  **资源 (Resource)**：网络上的所有东西都是资源（用户、订单、商品）。
-2.  **统一接口 (Uniform Interface)**：用标准的 HTTP 方法（GET, POST, DELETE）来操作这些资源。
-3.  **无状态 (Stateless)**：每次请求都包含所有必要信息，服务器不记“你是谁”（除非你带了 Token）。
-
-### 比喻：餐厅点餐
-
- **URL 是桌号**：`/tables/5` (资源地址)
- **HTTP 方法是动作**：
-    - `GET`：看菜单
-    - `POST`：下单
-    - `PUT`：换一桌菜
-    - `DELETE`：吃完走人
-
---
-
-## 2. 交互演示：RESTful API 全流程
-
-别光听概念，我们来动手玩一下。
-下面是一个模拟的“用户管理系统”。试着点击不同的场景，观察 **客户端发出了什么** 以及 **服务端返回了什么**。
-
-<RestfulApiFlow />
-
-### 💡 观察重点
-
-1.  **URL 是名词**：注意看 URL 都是 `/users` 或者 `/users/1`，没有动词（如 `/getUsers`）。因为 HTTP 方法（GET/POST）已经表示了动作。
-2.  **状态码会说话**：
-    - 创建成功返回 `201 Created`，而不是 200。
-    - 删除成功返回 `204 No Content`（没有 Body）。
-    - 找不到返回 `404 Not Found`。
-3.  **复数形式**：通常使用 `/users` 而不是 `/user`，表示这是“用户集合”下的资源。
-
---
-
-## 3. 设计黄金法则
-
-### 3.1 URL 设计：让路径清晰
-
-| 法则 | 正确 ✅ | 错误 ❌ | 原因 |
-| :--- | :--- | :--- | :--- |
-| **用名词，不用动词** | `GET /products` | `GET /getProducts` | HTTP 方法已经是动词了 |
-| **用复数** | `/users/1` | `/user/1` | 保持一致性，`/users` 代表集合 |
-| **层级不要太深** | `/users/1/orders` | `/users/1/orders/2/items/3` | 超过 3 层建议拆分或用查询参数 |
-| **使用连字符** | `/user-profiles` | `/userProfiles` | URL 对大小写敏感，连字符更易读 |
-
-### 3.2 HTTP 方法：动作要有语义
-
- **GET** (查)：**安全且幂等**。不管调用多少次，服务器状态不变。
- **POST** (增)：**不安全，不幂等**。调用 10 次可能创建 10 个用户。
- **PUT** (改-全量)：**幂等**。把 ID=1 的用户替换为新数据，替换 10 次结果一样。
- **PATCH** (改-局部)：通常用于只修改一个字段（如只改密码）。
- **DELETE** (删)：**幂等**。删除 ID=1 的用户，删 1 次和删 10 次，结果都是“用户没了”。
-
-### 3.3 状态码：别只用 200
-
-| 类别 | 状态码 | 含义 | 场景 |
-| :--- | :--- | :--- | :--- |
-| **2xx 成功** | 200 OK | 通用成功 | GET, PUT |
-| | 201 Created | 创建成功 | POST |
-| | 204 No Content | 成功但无返回 | DELETE |
-| **4xx 客户端错** | 400 Bad Request | 参数错 | 必填项没填，格式不对 |
-| | 401 Unauthorized | 未登录 | 没有 Token 或 Token 过期 |
-| | 403 Forbidden | 无权限 | 普通用户想删管理员 |
-| | 404 Not Found | 找不到 | URL 错了或 ID 不存在 |
-| **5xx 服务端错** | 500 Internal Error | 崩了 | 代码抛异常了，数据库挂了 |
-
---
-
-## 4. 总结
-
-好的 API 设计是**“自解释”**的。
-当你的前端同事看到 `DELETE /api/orders/123`，他不需要问你，就应该知道：
-1.  这是一个删除操作。
-2.  操作对象是 ID 为 123 的订单。
-3.  如果成功，应该收到 204 或 200。
-4.  如果失败，应该去看状态码是 4xx 还是 5xx。
-
-这就是**约定优于配置**的力量。
+| 名词 | 英文 | 解释 |
+| :--- | :--- | :--- |
+| **API** | Application Programming Interface | 程序之间对话的约定 |
+| **REST** | Representational State Transfer | 一种架构风格，用 URL 标识资源 |
+| **资源** | Resource | REST 架构的核心概念，有唯一标识（URL） |
+| **幂等性** | Idempotency | 多次执行结果相同 |
+| **状态码** | Status Code | HTTP 协议定义的响应状态 |
+| **版本控制** | Versioning | 让新旧 API 并存，平滑升级 |
+| **请求体** | Request Body | POST/PUT/PATCH 请求携带的数据 |
+| **响应体** | Response Body | 服务器返回的数据 |
+| **Header** | Header | 请求/响应的元数据（如 Content-Type） |
+| **认证** | Authentication | 验证"你是谁"（登录、Token） |
+| **授权** | Authorization | 验证"你能做什么"（权限） |
@@ -5,150 +5,189 @@ description: 'AI 发展 70 年，经历了三次浪潮、两次寒冬，最终

 # AI 简史：从符号逻辑到千亿参数大模型

-AI 发展 70 年，经历了**三次浪潮、两次寒冬**，从符号主义的逻辑推演，到连接主义的神经网络，再到行为主义的强化学习，最终融合为今天的大模型时代。以下是清晰的发展脉络与关键里程碑。
+AI 发展 70 年，经历了**三次浪潮、两次寒冬**，从符号主义的逻辑推演，到连接主义的神经网络，再到行为主义的强化学习，最终融合为今天的大模型时代。了解 AI 的历史，能帮助我们看清今天大模型"智能"的本质来源。

 <AiEvolutionDemo />
+<DiscriminativeVsGenerativeDemo />

 ---

 ## 一、理论奠基与符号主义的诞生（1940s-1950s）

-### 核心人物与理论
+在计算机真正普及之前，先驱者们就开始思考"机器能否像人一样思考"。这个时期的研究主要集中在脑神经的数学建模、计算理论的探讨以及逻辑推理的自动化。1956 年的达特茅斯会议，正式宣告了"人工智能"（Artificial Intelligence）作为一个独立学科的诞生。

- **1943 年**：沃伦・麦卡洛克与沃尔特・皮茨提出 **MP 神经元模型**，首次用数学描述神经网络
- **1950 年**：艾伦・图灵发表《计算机器与智能》，提出**图灵测试**，定义机器智能标准
- **1956 年**：**达特茅斯会议**，约翰・麦卡锡首次提出"人工智能"概念，标志 AI 学科正式诞生
+<FoundationDemo />

-::: tip 符号主义兴起
-**符号主义**（逻辑主义/计算机学派）主张 **智能 = 符号推理**，将知识编码为符号，通过逻辑规则推导解决问题，是**自上而下**的智能模拟路径。
+### 1.1 核心理论与里程碑事件
+ 
+- **神经网络的最初设想（1943）**：神经生理学家沃伦·麦卡洛克（Warren McCulloch）和数学家沃尔特·皮茨（Walter Pitts）提出了 **MP 神经元模型**。他们首次尝试用简单的数学公式抽象人类大脑神经元的工作机制，证明了"神经元网络是可以计算的"，这成为了今天所有深度网络的老祖宗。
+- **图灵的终极追问（1950）**：计算机科学之父艾伦·图灵（Alan Turing）发表了一篇改变历史的论文《计算机器与智能》，提出了著名的**图灵测试**。他避开了"什么是智能"的哲学争论，给出了一个务实的操作标准：如果一台机器在对话中能让人类无法分辨它是人还是机器，它就具备了智能。
+- **学科的正式确立（1956）**：在达特茅斯的夏季研讨会上，约翰·麦卡锡（John McCarthy）、马文·明斯基（Marvin Minsky）等年轻学者齐聚一堂。麦卡锡在提案中首次使用了"Artificial Intelligence"这一术语，这一年因此被称为 AI 元年。
+
+::: tip 符号主义（Symbolism）的兴起
+在早期的 AI 研究中，**符号主义**占据了绝对的主导地位。由于当时的计算机主要依靠逻辑电路运行，学者们自然地认为：**智能的本质就是符号的推演**。
+只要我们把世界上的知识变成计算机能看懂的符号（如概念、规则），再用逻辑推理引擎（如 IF-THEN 规则）去处理这些符号，机器就能像人一样思考。这是一种**自上而下**的路径，高度依赖人类专家的知识输入。
 :::

-### 早期突破
-
- **1956 年**：纽厄尔和西蒙开发**逻辑理论家**（Logic Theorist），首个能证明数学定理的 AI 程序
- **1958 年**：麦卡锡发明 **LISP 语言**，成为 AI 研究的重要工具
- **1959 年**：乔治・德沃尔与约瑟夫・恩格尔伯格开发首台**工业机器人**，标志 AI 从理论走向应用
-
 ---

 ## 二、符号主义黄金时代与第一次 AI 浪潮（1960s-1970s）

-### 专家系统的辉煌
+在诞生后的最初十几年里，AI 迎来了一段盲目乐观的黄金时期。研究者们相信，既然机器已经能证明数学定理，那写出能够解决任何人类问题的程序指日可待。

-符号主义在**专家系统**领域取得巨大成功，通过将领域专家知识编码为规则库，解决特定领域复杂问题。
+<ExpertSystemWaveDemo />

-| 时间 | 标志性成果 | 意义 |
+### 2.1 专家系统的光辉岁月
+
+符号主义的集大成者是**专家系统（Expert Systems）**。通过向计算机输入各个领域顶级专家的"经验法则（Rule）"，系统就能在某些特定垂直领域执行高水平的诊断或决策。
+
+| 专家系统 | 诞生年份 | 历史意义与实际价值 |
 | --- | --- | --- |
-| **1965 年** | Dendral 系统 | 首个专家系统，用于化学分子结构分析 |
-| **1977 年** | MYCIN 系统 | 诊断血液感染的专家系统，准确率达 69% |
-| **1980 年** | XCON 系统 | 为 DEC 公司配置计算机，节省 4000 万美元/年 |
+| **Dendral** | 1965 年 | **首个专家系统**，它能根据质谱数据推断化学分子结构，性能比肩人类化学专家。 |
+| **MYCIN** | 1977 年 | 用于诊断血液感染并推荐抗生素，准确率高达 69%，甚至超过了当时的许多非专业医生。 |
+| **XCON** | 1980 年 | 早期最成功的商用专家系统，用于帮助数字设备公司（DEC）根据客户需求自动配置计算机系统，每年为公司节省了 4000 万美元。 |

-### 第一次 AI 寒冬（1974-1980）
+然而，专家系统风光的背后，隐藏着无法逾越的鸿沟。

-::: warning ❄️ 第一次 AI 寒冬
-符号主义局限性显现：
- **知识获取瓶颈**：规则需人工编写，无法自动获取
- **脆性问题**：难以处理例外情况，稍微偏离规则就崩溃
- **计算能力不足**：当时的硬件无法支撑复杂推理
+### 2.2 第一次 AI 寒冬（1974-1980）

-美国 DARPA 削减 AI 研究经费，AI 进入第一次低谷期。
+随着时间推移，人们发现"把人类知识写成规则"这条路越走越窄。
+
+::: warning ❄️ 第一次 AI 寒冬的爆发原因
+符号主义的三大致命局限，最终导致了研究经费被全面撤销：
+1. **知识获取瓶颈（Knowledge Acquisition Bottleneck）**：有些知识人类也说不清（比如怎么认出一只猫），这被称为"波兰尼悖论"。专家系统只能硬编码那些能被清晰表达的规则，无法自动学习。
+2. **"常识"的匮乏与脆性（Brittleness）**：当遇到规则库之外的边缘情况时，哪怕只是稍微偏离预期，系统就会表现出错乱，完全没有人类的"常识"底线。
+3. **组合爆炸（Combinatorial Explosion）**：现实世界的变量太多，当涉及复杂现实时，穷举规则所需的计算量会呈指数级爆炸，当时的硬件根本无法支撑。
 :::

 ---

-## 三、专家系统复兴与第二次 AI 浪潮（1980s）
+## 三、专家系统（把人类经验翻译成代码的程序）与第二次 AI 浪潮（1980s）

-### 商业应用爆发
+到了 80 年代，随着微型计算机和专业 LISP 机器的普及，专家系统再次受到商业界的追捧。日本政府甚至抛出了雄心勃勃的"第五代计算机计划"，试图打造能听懂自然语言的智能机器，引发了全球范围内的恐慌性跟投。

- 日本"**第五代计算机计划**"（1982）推动全球 AI 投资热潮
- 美国 DEC、IBM 等公司推出商用专家系统开发工具
- 符号主义达到巅峰，成为 AI 领域绝对主流
+### 3.1 商业应用的爆发与破灭

-### 连接主义的早期尝试
+在这个时代，几乎每家大型跨国公司都在研发自己的**专家系统（一种把人类专家的经验翻译成成千上万条 IF-THEN 代码的程序）**。然而，维护这些系统变得极其折磨人。规则库突破几万条后，修改一条新规则经常会导致另外十条旧规则产生冲突。随着 80 年代末通用个人电脑（PC）性能的爆发，昂贵且封闭的专用 AI 机器变得毫无竞争力。
+
+::: warning ❄️ 第二次 AI 寒冬（1987-1993）
+1987 年，AI 硬件市场彻底崩盘。"第五代计算机计划"因为过度脱离实际硬件架构而最终烂尾。企业在专家系统上砸的钱打了水漂，AI 研究再次跌入底谷，"人工智能"这个词甚至在学术界成了骗经费的贬义词。
+:::
+
+### 3.2 黑暗中蛰伏的连接主义
+
+在这两次起伏中，其实还存在着另一套完全不同的思路——**连接主义（Connectionism）**，也就是我们今天所说的**神经网络**。

 <PerceptronDemo />

- **1958 年**：罗森布拉特发明**感知机**，首个可学习的神经网络模型
- **1969 年**：明斯基与佩珀特出版《感知机》，指出单层感知机无法解决**异或问题**，导致连接主义研究陷入停滞
-
-### 第二次 AI 寒冬（1987-1993）
-
-::: warning ❄️ 第二次 AI 寒冬
- 专家系统**维护成本高昂**，难以扩展到复杂领域
- 个人电脑崛起，第五代计算机计划失败
- AI 市场崩盘，研究经费再次大幅削减
-:::
+连接主义早在 1958 年就由罗森布拉特（Frank Rosenblatt）以**感知机（Perceptron）**的形式提出。它模拟大脑通过调整神经元之间连接的权重来进行学习。与其教给机器明确的"规则"，不如给机器看大量的"例子"，让它自己归纳。不过，1969 年明斯基在《感知机》一书中用严密的数学证明了当时单层网络的局限（无法解决简单的异或问题）。这使得连接主义在符号主义的黄金时代一直坐冷板凳。直到历史的车轮前进到 90 年代。

 ---

 ## 四、机器学习兴起与连接主义复苏（1990s-2000s）

-### 符号主义衰落，机器学习崛起
+进入 90 年代后，AI 领域出现了一个重要的务实转向。大家不再天天谈论如何实现"像人类一样的魔法智能"，而是把重心放在了如何利用**严密的数据统计方法**，解决现实生活中的分类和预测问题。这也就是传统**机器学习（Machine Learning）**的兴起。

- **1997 年**：IBM **深蓝** 击败国际象棋世界冠军卡斯帕罗夫，是符号主义最后的辉煌
- 同时，**统计机器学习**开始取代基于规则的方法，支持向量机（SVM）、决策树等算法成为主流
+### 4.1 从死板规则到"寻找数学边界"

-### 连接主义的重生
+1997 年，虽然 IBM 的"深蓝（Deep Blue）"击败了国际象棋世界冠军卡斯帕罗夫，为符号主义拿下了举世瞩目的荣光，但学术界立刻意识到，这只是一次"算力+海量硬编码"的胜利，深蓝并没有真正理解什么是下棋。
+
+与此同时，以**支持向量机（SVM）**、决策树、随机森林为代表的经典机器学习算法异军突起，成为了接下来长达十余年的绝对主流。
+
+如果说以前的专家系统是教电脑："如果邮件里包含'中奖'，那么就是垃圾邮件"，那么**机器学习的思路就是：人类先设定好几个核心特征（特征工程）**，比如"邮件长度"、"特殊词汇频率"、"发件人可信度"，然后把上万封标注好的邮件输入给电脑。在这个多维空间里，**支持向量机（SVM）**就像是一个拿着尺子的数学家，它会利用严密的核函数推演，在正常的邮件和垃圾邮件之间，精准地画出一条"最宽、最安全的数学分界线"。
+
+尽管支持向量机在许多任务上大获成功，但它存在一个致命弱点：**特征工程（Feature Engineering）高度依赖人类。** 比如要识别一张猫的图片，人类科学家必须教机器"先提取边缘"、"再寻找三角形的耳朵"，机器自己是找不出猫的样子的！这导致了模型能力的上限被人类的认知牢牢锁住。
+
+### 4.2 反向传播让神经网络重见天日
+
+深度学习的真正基础在这个时期被打下：

 <BackpropagationDemo />

- **1986 年**：鲁梅尔哈特等人提出**反向传播算法**，解决多层神经网络训练难题
- **1997 年**：李飞飞创立 **ImageNet 数据集**，为后续深度学习提供数据基础
- **2006 年**：杰弗里・辛顿提出**深度信念网络**，通过逐层预训练解决梯度消失问题，开启深度学习时代
+在这段蛰伏期，杰弗里·辛顿（Geoffrey Hinton）等人进一步明确了**反向传播（Backpropagation）**的核心价值：当多层神经网络得出错误预测时，能够将这种误差像水波一样，一层层倒推回去，告诉每一个隐藏层的老神经元："你在这次错误中到底需要承担多大责任，下次赶紧改过来！" 
+
+这最终打破了 60 年代对神经网络的禁锢，使得具有隐藏层的网络成为可能。但由于当时数据太少，硬件太弱（连好点的显卡都没有），神经网络还无法全面战胜 SVM 等传统机器学习模型。直到 **三大引爆点** 的齐聚。

 ---

 ## 五、深度学习革命与连接主义主导（2010s）

-### 关键技术突破
+2010 年代，随着**大数据（如 ImageNet 项目）的成熟**、**算力爆发（GPU 大规模应用于并行计算）**以及**算法上的改良（解决梯度消失难题）**，"深度学习"轰轰烈烈地拉开了第三次 AI 浪潮的序幕。
+
+**什么是深度学习与传统机器学习的本质区别？标志就是：特征自动提取（表征学习）。** 只要网络层数足够深（几十层到上百层），神经网络能够直接吃进最原始的像素，它的底层自己学会了识别线条，中层学会了识别毛发纹理，高层直接认出了这是一只"猫"。在这场革命中，傲慢的人类终于放权，让网络自己去寻找最重要的视觉、语音和文本特征。
+
+### 5.1 图像与竞技的全面突破
+
+2012 年，由辛顿带领团队研发的 **AlexNet（经典的卷积神经网络 CNN）** 参加了著名的 ImageNet 图像分类比赛。在别人还在苦苦用传统方法提取手工视觉特征时，AlexNet 直接暴力降维打击，将错误率从 26% 瞬间腰斩到 15.3%，震惊了整个传统计算机视觉学界。由于这种绝对统治力，在往后的几年里，几乎没有任何一篇不使用深度学习的论文能被顶级会议录用！
+
+随后几年，AI 技术每分每秒都在狂飙：

 <NeuralNetworkVisualizationDemo />

-| 时间 | 突破 | 影响 |
+| 突破年份 | 标志性成就 | 深远影响 |
 | --- | --- | --- |
-| **2012 年** | AlexNet 在 ImageNet 竞赛中错误率降至 15.3% | 标志深度学习超越传统方法，引爆计算机视觉革命 |
-| **2014 年** | GAN（生成对抗网络）提出 | AI 具备生成逼真图像、音频能力，推动生成式 AI 发展 |
-| **2015 年** | ResNet（残差网络）解决深层网络训练难题 | 网络层数突破 1000 层，进一步提升模型性能 |
-| **2016 年** | AlphaGo 击败围棋世界冠军李世石 | 结合深度强化学习与蒙特卡洛树搜索，实现复杂决策能力 |
-| **2017 年** | **Transformer 架构**发布 | 基于自注意力机制，解决长距离依赖问题，为大模型奠定基础 |
+| **2014 年** | **GAN（生成对抗网络）**提出 | 两个网络"左右互搏"（一个造假，一个打假），让 AI 开始具备生成惊艳且逼真图像的能力。 |
+| **2015 年** | **ResNet（残差网络）**问世 | 创新性地引入"捷径"结构，解决了网络加深后根本无法正常训练的问题，使神经网络动辄能堆叠几百上千层。 |
+| **2016 年** | **AlphaGo** 击败李世石 | 深度学习与**强化学习**结合的巅峰，打破了"机器永远下不过人类围棋"的断言，轰动全球。 |
+
+::: tip 行为主义（Behaviorism）与强化学习
+AlphaGo 代表了另一个学派——**行为主义**的胜利。它认为智能来源于主体与环境的动态交互，就像训练一只小狗坐下：它做对了给奖励，做错了给惩罚。通过在巨大的虚拟环境中不断自行试错、对弈，AlphaGo 总结出了连人类顶级棋手都不曾发觉的策略。
+:::
+
+### 5.2 Transformer：孕育大模型的摇篮
+
+2017 年，一切的命运齿轮开始转动。Google 在论文《Attention Is All You Need》中提出了一种全新的深度学习架构——**Transformer**。

 <AttentionMechanismDemo />

-::: tip 行为主义的发展
-**行为主义**（进化主义）主张智能来自与环境的互动，通过试错学习优化行为，**强化学习**是其核心技术。AlphaGo 就是深度学习与强化学习结合的代表作。
-:::
+以前处理一句话时（比如 RNN 模型），AI 只能从左到右一个个词看，看完了后面的容易忘了前面的。而 Transformer 的**自注意力机制（Self-Attention）**彻底打破了这个限制：它能让 AI"一眼看全"整句话，并在看到"苹果"这个词时，自动根据上下文判断这是指水果，还是指乔布斯的手机公司。
+
+它天生就适合并行计算，吃得下无限多的数据，也能够被堆叠得无尽庞大。这一刻，大模型（LLM）的地基打完了。

 ---

 ## 六、大模型时代与通用智能曙光（2018 至今）

-### 预训练模型范式确立
+当 Transformer 遇见了不计成本的疯狂算力与海量的数据，AI 开发的历史范式被永远改变了。科学家们发现了一个惊人的现象：基于自注意力的架构好像永远也"喂不饱"。以前的深度学习模型，聪明程度会遇到天花板，但 Transformer 能够完美适配 GPU 的大规模并行计算，只要给它的数据越多、网络层数越深，它的表现就能无限提升。
+
+### 6.1"预训练+微调"范式的确立：从专才到通才
+
+原本我们做 AI，是"一项任务配一个小模型"：做翻译的专门训练翻译模型，聊天的专门训练聊天模型，就像培养一个个只会一门手艺的"专才"。但到了 2018 年，随着 OpenAI 的 **GPT-1** 和 Google 的 **BERT** 的发布，情况变成了**"大力出奇迹"**的新范式。
+
+首先是**预训练（Pre-training）**，这构成了大语言模型 99% 的核心智力。科学家们把全人类在互联网上遗留的数万亿字的文章、名著典籍、计算机代码甚至百科知识，全部倾倒进庞大的 Transformer 网络里。而给它的训练任务，却仅仅是简单的**"文字接龙"（预测下一个词）**。
+
+为了能无比精准地预测人类语言中的各种"下一个词"，模型被迫在其成百上千亿的神经元参数中，自行内化并浓缩了整个世界的运作规律！它不仅彻底掌握了主谓宾语法，知道了"苹果"是一种红色的水果，还能掌握"牛顿因为苹果坠落而发现万有引力"的背后逻辑。这就像一个孩童没有刻意背诵过语法书，却依靠广泛地阅读千万本藏书，自动拥有了理解复杂世界的能力。

 <GPTEvolutionDemo />

- **2018 年**：OpenAI 发布 **GPT-1**（1.17 亿参数），谷歌发布 **BERT**，确立"**预训练 + 微调**"新范式
- **2019 年**：**GPT-2**（15 亿参数）展现惊人的文本生成能力，引发对 AI 伦理的广泛讨论
- **2020 年**：**GPT-3**（1750 亿参数）通过"暴力美学"展现**涌现能力**，无需微调即可完成多种任务
+从 GPT-2（15亿参数）到 GPT-3（1750亿参数），科学家们震撼地发现了**涌现能力（Emergent Abilities）**——当模型足够巨大时，量变引起了可怕的质变。即使未经任何刻意训练，巨量参数的模型自己"悟"出了逻辑推理、代码编写和上下文学习的能力。这根本不需要人类专门通过代码去教它。

-### 生成式 AI 爆发
+### 6.2 生成式 AI 爆发与 ChatGPT 的核爆时刻

- **2022 年 11 月**：**ChatGPT**（GPT-3.5）发布，通过 RLHF（人类反馈强化学习）大幅提升对话能力，成为现象级产品
- **2023 年 3 月**：**GPT-4** 发布，具备**多模态能力**（文本 + 图像），进一步提升逻辑推理与安全性
- **2023 年**：Stable Diffusion、Midjourney 等图像生成模型兴起，多模态大模型成为主流
- **2024 年**：**Sora** 等视频生成模型发布，AI 生成能力扩展到动态内容领域
+在拥有了一个满腹经纶、藏有世界常识的巨大预训练模型后，距离打造出一个完美的个人 AI 助理还差最后一步：**微调（Fine-tuning）**。因为预训练的模型只习惯盲目地做文字续写，它听懂使用者的"指令"，也不知道该如何规矩地进行一问一答的交互。
+
+2022 年 11 月，OpenAI 巧妙地引入了 **RLHF（基于人类反馈的强化学习）** 技术。他们雇佣了大批专家，对于模型的回答进行打分和纠正。这就好比给一个极其聪慧但口无遮拦的天才，设立了明确的沟通边界与礼仪指引，强行将其塑造成了一个温和、有条理且懂事的对话助手。于是，**ChatGPT** 诞生了。
+
+一夜之间，AI 不再是枯燥的实验室玩具，而是成为了每个普通人手中的通用智慧大脑。
+
+随后开启了波澜壮阔的多模态纪元：
+* **2023 年：多重感官的打通。** 以 Midjourney、Stable Diffusion 为代表的生图模型重塑了数字艺术产业。同年发布的 **GPT-4** 则融合了极高难度的视觉图像理解与长程逻辑关联推理能力系统。
+* **2024 年爆发至今：对物理世界的模拟。** 随着 Sora 等逼真视频生成模型的发布，以及实时端到端语音大模型在情感音色上的全面落地，AI 从单纯处理文本，迅速张开了对包含三维空间、光影流转甚至细腻声调情感的完整世界的全面感知。

 ---

 ## 七、AI 三大学派的融合与未来展望

-<DiscriminativeVsGenerativeDemo />
+回顾这70年，从让机器推理数学定理（符号主义），到寻找统计学边界（传统机器学习），到在试错中下围棋获胜（行为主义/强化学习），再到吞噬海量数据涌现出常识的大模型（连接主义的极致形态），人工智能的发展从未停歇。

-### 未来趋势
+今天的大模型看似放弃了人为编写死板"规则"（符号主义的初衷），但事实上，它在数千层网络隐式的海量参数里，学习并封装了比人类逻辑还要深邃得多的"暗规则"。如今大型预训练模型中的**思维链（Chain of Thought）**长程推理方式，何尝不是曾经符号学派追求逻辑验证与步骤严密的经典思想在神经网络中的重生？

- **多模态融合**：文本、图像、音频、视频等信息的统一处理
- **高效大模型**：降低训练成本，提升推理效率，推动边缘部署
- **可解释 AI**：解决黑箱问题，增强 AI 可信度
- **AGI 探索**：从专用智能向通用人工智能迈进，追求更全面的人类智能模拟
+**站在大模型时代的巅峰往下看，未来的通用人工智能（AGI）正沿着以下几条极其广阔且深刻的探索大道推进：**

+1. **走向原生的统一神经中枢（原生多模态）：** 未来的模型不再是"文本模型+语音模型"拼接而成的弗兰肯斯坦。以 GPT-4o 为代表的架构直接用同一个超级网络同时吞吐、感知且理解文本、图像、视频流和超低延迟的高情感三维波形语音。
+2. **具身智能（Embodied AI）：** 当拥有极高智商的"大脑"只能被囚禁在硅基机房里时，它就无法从物理世界验证真理。通过与波士顿动力、人型机器人的结合，超级 AI 有望长出双手并在摔打磨砺中习得和我们完全相同的物理客观铁律。
+3. **智能体系统（Agentic AI）：** 目前大多数 LLM 依然停留在"一问一答的被动计算文字计算器"阶段。而 AI Agent 时代，大模型被彻底赋予了**独立行动的权力**。只要你下达一句宏观的自然语言指令（例如"帮我调研并规划下周去挪威看极光的所有机票、酒店并生成日历日程"），AI Agent 将凭借长程记忆，自主拆解下达几十个子任务，打开虚拟浏览器调用真实航空公司的检索 API，完成复杂的校验甚至比对确认。它们不再是被动等待敲击的回声壁，而是不知疲倦的数字劳动力集群。

-AI 的发展是一条**螺旋式上升**的道路，每个时代的技术都为后续突破奠定基础。今天的大模型并非完全抛弃符号主义，而是在连接主义框架下，通过海量数据学习到了类似符号推理的能力，实现了**不同学派思想的深度融合**。
+在这螺旋上升的漫长技术征途中，历史总是惊人的相似但绝不重复。我们正亲历从"向算法死硬输入规则"到"由机器自动定义世界法则"的最激动人心的历史横截面。
+
+<AIErasComparisonDemo />
@@ -138,6 +138,13 @@ VS Code 的核心理念是“一切皆插件”。它通过插件机制支持各
 > - 自动生成测试：IDE 可以自动生成针对不同函数和模块的测试代码，方便你进行有针对性的测试。
 > - Agent 式任务执行：智能 Agent 可以自动生成、打包、安装、运行和修改代码，在很多任务上可以部分替代初级软件工程师的工作。

+::: details Antigravity
+
+### [Antigravity](https://antigravity.google/)
+
+Antigravity 是 Google 在 2025 年 11 月与 Gemini 3 一同发布的全新 AI IDE，采用"Agent-First"（智能体优先）开发模式。与传统 AI 辅助编码不同，Antigravity 让 AI 代理成为"主动执行者"，可直接操作编辑器、终端、浏览器等工具，承担更多"执行""策划""验证"的工作。开发者只需提出高层意图，代理便会自动拆分任务、制定计划、执行代码、运行测试、生成成果。它支持多模型切换，包括 Gemini 3 Pro、Claude Sonnet 4.5 等，目前以公开预览形式提供，支持 Windows、macOS、Linux 全平台。
+:::
+
 ::: details Trae

 ### [Trae](https://www.trae.ai/)