L 层概念页升格范式
一句话
L 层概念页是 wiki 的正文——它是"业务问题 + 控制论视角 + 工程实践"的完整文档。 本范式定义 L 层概念页的结构、深度、写作风格。
触发条件（什么时候用本范式）
- 升格 L 层 stub → 完整概念页时
- 新建 L 层概念页时
- 检查 L 层概念页质量时
L 层概念页的 6 段结构
1. 业务问题 （读者面对的问题）
2. 控制论视角 （控制论怎么解决这个问题）
3. 核心概念 （具体的概念 + 形式化）
4. 工程实践 （具体怎么落地）
5. 性能指标 （怎么衡量）
6. 边界判断 （什么时候不用）1. 业务问题
目的：让读者立即看到"这跟我有什么关系"。
写法：
markdown
## 业务问题
> 解决什么问题：[一句话核心问题]
### 真实场景
[2-3 个具体场景，描述读者会遇到的痛点]
### 失败的典型做法
[列举常见的错误做法，说明为什么不可行]2. 控制论视角
目的：展示这个问题在控制论中如何被解决——业务问题的数学原型。
写法：
markdown
## 控制论视角
### 数学原型
[钱学森工程控制论 Ch X §Y 的核心定理/原话]
### 控制论解法
[控制论如何解决这个问题的核心思想]
### 与业务的对应
[表格：控制论概念 ↔ 软件工程概念]3. 核心概念
目的：形式化核心概念——让读者能精确讨论。
写法：
markdown
## 核心概念
### 定义
[严格定义]
### 关键属性
[表格：属性 + 含义 + 软件工程对位]
### 关键公式 / 决策树
[如果适用]4. 工程实践
目的：具体怎么落地——可执行的步骤。
写法：
markdown
## 工程实践
### 步骤 1 / 步骤 2 / 步骤 3 / ...
[每个步骤的具体做法 + 输入 + 输出]
### 常见反模式
[列举 3-5 个常见错误做法 + 后果]
### 工程实例
[真实项目中的案例，最好带代码或架构图]5. 性能指标
目的：怎么衡量做得好不好——可量化的标准。
写法：
markdown
## 性能指标
| 指标 | 设计目标 | 实际值 | 偏差 |
|---|---|---|---|
### 监控设计
[关键指标的监控 + 告警阈值]
### 调优策略
[当指标偏离时怎么调]6. 边界判断
目的：什么时候不用这个方法论——避免滥用。
写法：
markdown
## 边界判断
### 何时不用
[列举 3-5 个不适用的场景]
### 与其他方法论的边界
[说明与相邻方法论的区别]
### 何时升级
[什么情况下应该用更复杂的方法论]frontmatter 标准
yaml
---
title: 概念名（业务语言，不要用控制论术语）
type: concept
layer: L1 / L2 / L3 / L4 / L5
group: <group 名>
status: mature / stub / draft
confidence: ★★★★★（一般情况）
last_updated: YYYY-MM-DD
related:
- <相关 L 层概念页 1>
- <相关 L 层概念页 2>
- <相关 L 层概念页 3>
---写作原则
原则 1：用业务语言，不用控制论术语
✗ 错：使用"互不影响原则（钱学森 Ch 6 §6.3）"
✓ 对：使用"BC 边界划分原则"
理由：读者是工程师，不需要知道控制论术语。
控制论的引用放在"控制论视角"小节。原则 2：业务问题在前，控制论视角在后
✗ 错：先讲控制论怎么解决这个问题，再讲业务问题
✓ 对：先讲业务问题（读者痛点），再讲控制论视角（数学原型）
理由：读者先看到"这跟我有什么关系"，才有动力读下去。原则 3：工程实践必须可执行
✗ 错："应该考虑业务的并发性"
✓ 对："步骤 1：用 ThreadPool 创建 N 个 worker 线程..."
理由：读者要的是"怎么做"，不是"应该考虑什么"。原则 4：性能指标必须可量化
✗ 错："系统应该稳定"
✓ 对："可用率 > 99.95%，错误率 < 0.1%"
理由：不可量化的指标 = 不可考核 = 无意义。原则 5：边界判断必须明确
✗ 错："此方法论有局限性"
✓ 对："当 X < Y 时不要用；当业务规模 < Z 时不要用"
理由：读者要的是"什么时候不用"，不是"有局限性"。原则 6：交叉链接至少 3 条
related 至少 3 条：
- 同 group 的相关概念
- 上一个 / 下一个 group 的相关概念
- L 概览（让读者随时回到上一层）与 meta/source/ 的关系
L 层概念页不直接引用 meta/source/cybernetics/。
原因：
- meta/source/ 是 AI 工作台，不在 wiki 上
- 读者看到的 L 层概念页是"业务语言版"
- 控制论引用可以放在 L 层概念页的"控制论视角"小节中，但用"钱学森 Ch X §Y"形式，不是链接
示例：
markdown
## 控制论视角
### 数学原型
> 钱学森《工程控制论》Ch 6 §6.3：
> "设法确定控制矩阵的元素...才能使规定的控制信号...只影响和它们相应的受控量..."
### 与业务的对应
| 控制论 | 软件工程 |
|---|---|
| 互不影响子系统 | Bounded Context |
| 矩阵对角化 | BC 边界划分 |绝对不要：
markdown
✗ 详见 [互不影响](/meta/source/cybernetics/non-interaction/)升格 checklist
把 stub 升级为完整概念页时：
- [ ] 业务问题清晰（读者痛点 + 失败案例）
- [ ] 控制论视角准确（Ch X §Y + 数学原型）
- [ ] 核心概念形式化（定义 + 关键属性 + 公式）
- [ ] 工程实践可执行（步骤 + 输入 + 输出）
- [ ] 性能指标可量化（设计目标 + 实际值）
- [ ] 边界判断明确（何时不用 + 何时升级）
- [ ] 至少 3 条 related
- [ ] frontmatter 完整
- [ ] build 通过（无死链）
- [ ] git commit（细粒度）
反例（不合格的概念页）
反例 1：纯控制论术语
markdown
✗ 错：
# 互不影响原则
## 来源
钱学森 Ch 6 §6.3：...
## 数学形式
传递函数矩阵对角化...
问题：读者看到的是控制论术语，不是业务问题。
没有"业务问题"段落，读者不知道这跟自己有什么关系。反例 2：纯业务描述
markdown
✗ 错：
# 限界上下文
## 是什么
限界上下文是 DDD 的核心概念...
## 怎么做
识别业务边界，划分 BC...
问题：没有控制论视角，失去了"数学原型"的深度。
没有性能指标，无法衡量做得好不好。反例 3：无可执行的步骤
markdown
✗ 错：
# 告警分级
## 原则
- 严重告警立即处理
- 一般告警按优先级处理
...
问题：全是"原则"，没有可执行步骤。
没有边界判断，不知道什么时候用哪一级。哲学依据
本范式的哲学根基：钱学森《工程控制论》§1.1"工程控制论是技术科学"——L 层概念页的 6 段结构就是把"技术科学"应用到软件工程的产物。
核心原则：
- 原则 1：模型是工具不是现实（业务视角在前）
- 原则 2：性能有内在限制（性能指标可量化）
- 原则 3：反馈是控制的核心（工程实践可执行）
以及三种指导：
- 指导 1：方法论必须可证伪（边界判断）
- 指导 2：方法论必须有边界（何时不用）
- 指导 3：方法论必须可组合（交叉链接）