docs: correct L3 — it is the largest single lever (3.35x), not a workaround

Author: speak-agent

.agents/docs/2026-08-13-build-optimization-status.md

@@ -65,7 +65,32 @@ L3 指的是**改 mcpp 自己的 138 个模块**——把定义从接口单元
 **可以做的**:拉一个临时分支/PR,只为**量出具体收益**(推算是链 74.6s → ~10.4s),
 测完即弃,不合入。收益数字回填到本文。
 
-### L3 的收益已经量出来了 —— 而且它和 L2 治的是同一个病
+### ⚠️ 更正:L3 是单项收益最大的杠杆,不是"绕行方案"
+
+下面那段用**未标定的旧 fixture**得出"L3 只值 +8%",**那个数字不可信** ——
+那份 fixture 每个 TU 有 74% 是编译器启动、`weight` 旋钮推不动成本(见 bench/README §1a)。
+用标定后的 fixture(`--preset standard`)重测的 2×2:
+
+| | `modules`(定义在接口) | `modules-impl`(定义移到实现单元) |
+|---|---|---|
+| **schedule=off** | 17.76s | **5.30s** |
+| **schedule=on** | 12.45s | **5.00s** |
+
+* **L3 单独:3.35×** · **L2 单独:1.43×** · **L2+L3:3.55×**
+
+**它们叠加,但只叠一点点**,因为**两者治的是同一份浪费、只是从两头下手**:
+L3 把 codegen 从接口单元搬走,L2 是不等那份 codegen。做了任何一个,
+另一个就没多少可买。而**单项收益 L3 远大于 L2**。
+
+⚠️ 注意 L2 在这里只有 1.43×,而在 mcpp 真实源码上是 2.30× ——
+fixture 单元的 codegen/parse 比例与真实模块不同,**不要跨工作负载搬运比值**。
+
+**所以"极致性能"的答案是:引擎侧 L2 + 工程侧 L3,而 L3 是更大的那一半。**
+L3 仍然不进这个 PR(它改的是被构建工程的写法),但它的定位从
+"给没有 L2 的引擎准备的绕行方案"更正为**最有效的单项优化**,
+文档提示应当据此改写。
+
+### 旧的分析(基于未标定 fixture,保留作为对照)
 
 不用拉分支:bench 的 `modules-impl` 变体测的**正是** L3(定义写在接口单元 vs 移到实现
 单元),数据已经在 `bench/results/five-way-20260812/` 里。同一 fixture、同一编译器: