"我们应该将软件的复杂度从垂直转为水平……通过增加链路的多样性，来实现链路的深度降低。"
延伸阅读：用户故事如何作为水平复杂度的天然切分单位，参见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. 接下来应该怎么做
如果你想让自己的系统从垂直到水平演进，可以考虑几条实践路径：
识别深链路：
找出那些“从前端一路打到底层”的关键链路，看看它们是不是已经超出了一个 AI session 的可理解范围。拆分展示与功能：
像 shad-expo-studio 一样，把 UI 和业务逻辑物理拆开，并为 UI 层建立可回归的场景（如 Storybook）。用 user story 做切分单位：
尝试让一个 user story 自己就带着它的“完整说明书”和“完整测试”，而不是依赖一大堆共享的隐式状态。