当每一个小改动都有 blast radius

Vibe coding 的前半段会让人觉得效率离谱地高。Cursor 和 Claude Code 能飞快生成 login、dashboard、settings、push notifications，快到一个 solo founder 几天内就能把 MVP 推上线。

问题往往出在第二轮或第三轮修改。settings 里一个小 tweak 会把 auth 打坏，一次 profile update 会连带影响 notifications。bug 看上去互不相关，但代码里没有被强制执行的 boundary，所以 app 的任何一部分都可能影响其他部分。

遗留从第一天开始

每一行代码在提交的那一刻就成了遗留。真正的问题从来不是代码会不会变成遗留，而是这份遗留是可导航的，还是像雷区一样难以靠近。

传统团队靠代码评审、架构决策记录，以及会说“不”的资深工程师来解决这个问题。但当你用 AI 以 10 倍速度交付时，你不可能把人放在每一个验证环节里。

声明式约束才是答案

真正有效的是 O(1) 护栏：用毫秒级运行的、确定性的、声明式检查。

  • 类型系统 在编译期发现接口违规
  • dependency-cruiser 规则 强制模块边界
  • JSON Schema 校验 保证契约被满足
  • pre-commit hooks 在代码落地前跑完所有检查

这些不是建议，而是不可协商的门禁。无论写代码的是人还是 AI，只要没有通过，就不能发。

为什么不要把 LLM 放进验证环节

让 LLM 参与验证听起来很聪明，但在实践里会失败：

  1. 不确定性：同一段代码，这次可能通过，下次可能不通过
  2. 上下文窗口压力：代码库一大，审查器就会丢失背景信息
  3. 速度：LLM 审查按秒计，确定性检查按毫秒计
  4. 成本：每一次审查都消耗 token 和现金

护栏就该是无聊的。它应该每次都一样。这不是缺点，而是优点。

如何开始

Autotomy 的 Expo Starter 已经把这套护栏配好了。每个模块都有明确接口，依赖规则在 pre-commit 阶段执行，类型覆盖率也是强制项。你拿到的是 AI 的速度，加上架构层面的安全。