Skip to content

bottleneck-pattern.md

Latest commit

 

History

History
116 lines (76 loc) · 5.06 KB

bottleneck-pattern.md

File metadata and controls

116 lines (76 loc) · 5.06 KB
Raw

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 消失 → 强迫记忆

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