第 6 章：从垂直复杂度到水平复杂度

"我们应该将软件的复杂度从垂直转为水平……通过增加链路的多样性，来实现链路的深度降低。"

延伸阅读：用户故事如何作为水平复杂度的天然切分单位，参见AI Coding 的五个等级与 User Story Driven 终局。小团队在实施这一转型时的优势，参见AI-Native 小团队的结构性优势。

1. 什么是“垂直复杂度”和“水平复杂度”

传统的软件系统喜欢往“垂直”方向长：

• 一条主线很深，经历很多层抽象、很多层调用、很多隐含状态
• 一旦出问题，debug 的时候必须从最上层一路跟到最底层，中间任何一层都可能藏着坑

在 AI-native 的世界里，这样的深链路有一个致命问题：

一个非常深入的链路，AI 很难 debug。

反过来，如果我们把复杂度“摊平”，让系统变成：

• 有更多条链路，每一条都更短、更浅、更独立
• 每一条的逻辑都可以被 AI 在一个 context window 之内完整理解

这就是所谓“从垂直到水平”的复杂度转型。

2. 为什么水平复杂度更适合 AI-native 系统

AI 的上下文窗口是有限的，这一点在AI 的无状态性与 Context Window中已经展开。结合这一点来看复杂度：

• 深度很深的单一链路：

  • 上下文跨越太多模块、文件、历史决策
  • AI 很难在一个 session 里把所有前因后果都“装进去”
  • debug 时容易出现“看到了局部，理解不了整体”的情况

• 多条相似但独立的浅链路：

  • 每条链路所需的上下文更短
  • AI 更容易在一个 session 内做完理解、修改、验证
  • 比较两条相近但相互独立的链路，是 AI 特别擅长的事情

“一个非常深入的链路 AI 很难 debug，但 AI 可以处理两条非常相近的链路，只要这两条链路相互独立即可。”

3. shad-expo-studio：降低垂直复杂度的一个尝试

https://github.com/ge-limin/shad-expo-studio 是一个降低垂直复杂度的具体尝试：

• 把前端展示层和功能层的功能彻底隔离
• 用 Storybook 做强制性的回归测试，确保展示层不随着业务迭代而“悄悄漂移”

这样做的本质，就是把“一个纵向集成的前端页面”拆成几条更水平的链路：

• 展示层：样式、组件结构、交互细节
• 功能层：数据流、业务规则、API 调用

对于 AI 来说：

• 展示层的改动可以在 Storybook 场景里被局部理解和测试
• 功能层的改动可以在测试代码里被局部理解和测试
• 避免了一次性在一个 session 里“理解整个页面从 UI 到业务到后端”的深度链路

4. story-ops：把复杂度压到“用户故事”

https://github.com/ge-limin/story-ops 则是另一个更进一步的探索，目标是：

“user story = PRD = E2E test cases”

也就是说：

• 复杂度的单位不再是“模块”或者“子系统”，而是一个一个独立的 user story
• 每个 story 本身就包含了：需求描述、行为预期、端到端测试

从复杂度的角度看，这相当于：

• 把过去那种“大而全”的纵向系统，拆成很多“平行的 user story”
• 每一个 story 都有自己的输入、输出和验证方式
• AI 可以在一个 story 的范围内完成理解和修改，而不必一次性吞下整个系统

5. 接下来应该怎么做

如果你想让自己的系统从垂直到水平演进，可以考虑几条实践路径：

1. 识别深链路：
   找出那些“从前端一路打到底层”的关键链路，看看它们是不是已经超出了一个 AI session 的可理解范围。

2. 拆分展示与功能：
   像 shad-expo-studio 一样，把 UI 和业务逻辑物理拆开，并为 UI 层建立可回归的场景（如 Storybook）。

3. 用 user story 做切分单位：
   尝试让一个 user story 自己就带着它的“完整说明书”和“完整测试”，而不是依赖一大堆共享的隐式状态。

4. 容忍适度的代码重复：
   为了让每条链路足够独立、足够短，必须接受一部分“看上去重复”的实现。这一点在“500 函数 vs 5000 小函数”的讨论中已经点过。

复杂度不会消失，只会换一种形态存在。
在 AI-native 的时代，我们要做的，是把复杂度从“AI 和人类都难以掌控的垂直深链路”，转移成“AI 能够一条条吃掉的水平浅链路”。