逃生舱设计原则

Escape hatch（逃生舱口）：这个概念源自 React 的系统设计——当组件系统无法完美建模你的问题时，React 提供一个"没有护栏"的出口（例如 dangerouslySetInnerHTML），明确告诉开发者"你现在进入未知领域了，我们把控制权还给你"。这是一种深层的系统设计原则：抽象要尽量帮用户搞定 80% 的情况，但必须给剩下 20% 留一扇能逃出去的门，而不是假装抽象无所不能。

Guillermo 把这个原则搬到了 AI 产品设计上，v0 的做法是典型例子：

• 可见、可编辑的代码：v0 生成 UI 后，用户始终能看到底层生成的 Next.js/React 代码，可以直接修改，也可以把这段代码交给别的专家或别的模型处理。
• 跨模型会诊作为逃生舱口：真实案例——Lumalabs 的设计工程师在 v0 里迭代了 120 多轮卡住了，直接把 v0 生成的代码复制给 ChatGPT o1 做诊断，解决了问题。这印证了 Facebook 内部"别卡住，去找人帮忙解锁"的原则在 AI 时代的新形态：卡住时，向另一个 AI 求助，而不是在同一个工具里死磕。
• 从纯 prompt 到混合工程模式的门：v0 保留"切换到 Git，把项目变成一半 prompt、一半传统软件工程"的路径，允许用户按需从"全自动"降级到"有代码控制权"。