# Bottleneck Pattern: 为什么 ReqForge 这样设计

> 框架的设计决策看起来是"技术选择"。其实是**对"真正瓶颈在哪里"的判断**。
> 三个来自完全不同领域的案例指向同一个结论。

---

## 案例 A：HBM 高带宽内存

**背景**。SK hynix 去年四季度营业利润同比涨 10 倍。驱动不是手机，不是 PC——是 HBM，塞在每一块 H100 里的高带宽内存。

**表面叙事**。三家内存厂在打一场对称的战争——谁的 HBM 更快谁赢。

**真正瓶颈**。定价权不在内存厂那里——在**封装良率**那里。谁的 12 层堆叠良率先跑稳，谁就有议价权。

**表层 vs 深层**：

| 表面 | 深层 |
|------|------|
| 谁的 HBM 更快 | 谁的 12 层堆叠良率先跑稳 |
| 技术指标竞赛 | 工艺工程 + 良率爬坡 |
| SK hynix 领先 / Samsung 追赶 / Micron 跟跑 | 三家公司打的不是同一场战争：SK hynix 在讲"AI Memory"，Micron 在讲供应链安全，Samsung 在讲下一代反超——他们的官网话术暴露了各自在防守 / 进攻 / 讲一个还没发生的故事 |

**来源**：Thea 的 HBM 行业研究（domain-mapper L2 实战案例）。

---

## 案例 B：公众号 8 赛道 + AI 指令包

**背景**。一篇流传很广的文章拆了"8 赛道 + AI 指令包"清单——号称给每个赛道配一段 AI 指令，丢进去就能直出正文。结论：照抄这套打法，公众号 30 天内必死。

**表面叙事**。问题在"指令不够好"——换个更好 prompt 就能爆。

**真正瓶颈**。不在 AI 写正文。在：

1. **同源指令查重**：几百个新号用同一段指令 → 被平台识别为同一条生产线 → 限流
2. **缺作者人设**：同一赛道 50 个号产出的文章互相像 → 读者记不住
3. **钩子标题 + 私域承接没被 AI 解决**：70% 精力放在 AI 写正文，30% 放在标题和钩子——正好反了

**精力分配真相**：

```
改前（新手直觉）              改后（老手分配）
70% AI 写正文                 10% 打磨标题模板
30% 标题 + 开头               20% 打磨开头钩子
                              70% 私域 4 件套（文末钩子 / 菜单栏 / 关注话术 / 私域 SOP）
```

**核心洞察**：AI 能做的事（写正文）和真正卡脖子的（私域承接 + 人设积累）不是同一件事。把 70% 精力投在 AI 正文字数上，恰好是反向分配。

**来源**：公众号 8 赛道分析文，2026 年 6 月。

---

## 案例 C：ReqForge 框架

**背景**。一个"AI 辅助产品开发框架"。12 个 Skill，10 个 Agent，4 端适配器，机器门禁，进化引擎——看起来是技术工具。

**表面叙事**。功能对比：Skill 数量 / 适配器数量 / 支持什么 LLM。

**真正瓶颈**。不在于"AI 能不能写出好代码"。在于：

| 表面 | 深层 |
|------|------|
| AI 写代码快不快 | Spec 门禁之前有没有想清楚要写什么 |
| 审查能不能自动跑 | Phase 过渡有没有遵守纪律 |
| 上下文够不够长 | 跨 session memory 丢没丢 |
| prompt 调得好不好 | feedback → evolution 闭环跑没跑通 |

**新手精力分配直觉**：

```
改前（新手直觉）                改后（老手分配）
50% 理解 SKILL.md 内容          10% 装好 gate + memory hook
30% 跑一次 pipeline             30% 跑完 Phase 写 handoff.md
20% 看完 CLAUDE.md              60% 跑通第一个验证循环直到全绿
```

**框架真正的门槛**不是"会不会用 Skill"，是**能不能熬过前 3 个 Phase 看到纪律的价值**。

---

## 模式识别：三个案例的共性

| 维度 | HBM | 公众号 | ReqForge |
|------|-----|--------|----------|
| 表面瓶颈 | 内存带宽 | AI 生成正文 | AI 写代码速度 |
| 真正瓶颈 | 封装良率 | 私域承接 | 纪律闭环 |
| 投入方向偏差 | 追规格参数 | 追 prompt 质量 | 追功能数量 |
| 杠杆所在 | 工艺工程 | 人设 + 私域路径 | gate + memory + evolution |
| 验证方式 | 谁先跑稳良率 | 私域承接转化率 | 验证循环通过率 |

**共同结构**：

1. 大家都盯着显眼的地方（技术指标 / 正文产出 / 代码量）
2. 真正的杠杆在不显眼的地方（良率 / 私域 / 纪律）
3. 没有第二条，第一条产生的边际收益递减极快

---

## 对 ReqForge 的意义

**问"要不要加这个功能"之前，先问"真正卡脖子的是什么"**。

- 用户说"指令不够好" → 核一下他的 gate 是不是跳过了，是不是没跑验证循环
- 用户说"Agent 总犯错" → 核一下他的 memory 是不是空的，handoff 写了没有
- 用户说"框架太复杂" → 核一下他是不是把 70% 精力花在了看 SKILL.md 上

**框架的设计方向不是"加更多 Skill"，是让"真正瓶颈"的解决路径变短**：

- spec-before-code gate 不让无图纸开干 → 强迫想清楚
- 善刀而藏之不让 Phase 烂尾 → 强迫纪律闭环
- evolution engine 不让同样的错反复犯 → 强迫积累
- handoff.md 不让上下文随 session 消失 → 强迫记忆

这些设计的共同特征：**它们都在"不显眼的地方"加杠杆。**
