Type C 案例页
解决什么问题：端到端贯通的真实场景——把多个概念串起来，展示"在真实业务里怎么用"。
它是什么
Type C 文档是 wiki 的"实战剧本"——展示一个具体项目/场景，把 L 层的多个概念串联起来。
典型例子（未来）：
l2-design/06-cases/event-sourcing-order-system/（用事件溯源做订单系统）l3-implementation/06-cases/staged-rollout/（灰度发布的实施）
特征：
- 真实场景（不是 toy example）
- 必须链接到具体概念页（Type B）
- 篇幅 80-150 行
- 一个案例贯穿多个 L 层
结构模板
markdown
---
title: [案例名]
type: case
layer: L2 (or 跨层)
group: cases
status: mature
confidence: ★★★★☆
last_updated: YYYY-MM-DD
related:
- /path/to/concept-1/ # 案例涉及的概念
- /path/to/concept-2/
---
# [案例名]
> 这个案例展示什么：[一句话——通过这个案例你将看到什么概念/方法的应用]
## 场景
[真实业务背景——1-2 段]
- 业务方是谁
- 解决了什么问题
- 为什么用这套方案
## 涉及的 [Layer] 概念
| 概念 | 在本案例的角色 | 链接 |
|---|---|---|
| [概念 1] | [怎么用] | [→](/path/) |
| [概念 2] | [怎么用] | [→](/path/) |
| ... | ... | ... |
## 决策过程
### 阶段 1: [阶段名]
[这个阶段做了什么、为什么、用了什么概念]
### 阶段 2: [阶段名]
...
## 结果
[实施后的数据/反馈——避免空话, 给可量化的结果]
## 复盘
### 什么是对的
[决策正确的部分——为什么]
### 什么可以改进
[下次会怎么改——基于实际数据]
## 相关链接
- [概念 1](/path/)
- [概念 2](/path/)
- [类似案例](/path/)必填 section（5 个）
| section | 作用 | 篇幅 |
|---|---|---|
# 案例名 | 主标题 | 1 行 |
> 这个案例展示什么 | 定位句 | 1 行 |
## 场景 | 真实业务背景 | 1-2 段 |
## 涉及的 [Layer] 概念 | 表格——案例用到的概念及链接 | 5-10 行表格 |
## 决策过程 | 阶段化展示 | 3-5 个阶段 |
## 结果 | 可量化结果 | 1-2 段 |
## 复盘 | 什么对/什么错 | 2 个子段 |
怎么用
新建 Type C 文档：
- 选择一个真实做过/调研过的项目
- 在"涉及的 [Layer] 概念"表里填至少 3 个相关 Type B 文档
- 决策过程按"为什么这么做"而不是"做了什么"
- 结果必须可量化（QPS、延迟、错误率、节省成本等）
常见误区
- 写成"项目介绍"而不是"案例分析"——案例的核心是"为什么这么做"，不是"做了什么"
- 没有量化结果——"提升了" 是空话，"p99 延迟从 500ms 降到 80ms" 才是结果
- 不复盘——只讲成功不讲失败 = 假案例
- 不链接到概念页——案例页的核心价值是"展示概念的应用"，不链接 = 孤立文档
关键洞察
案例 = 概念的"使用说明书"
Type B 概念页告诉读者"什么是 X"，Type C 案例页告诉读者"在真实场景里 X 是这样用的"。没有案例的概念是抽象的，没有概念的案例是孤立的。