通常我们开始一个项目时，会先开启 Plan 模式，让 AI 帮我们写一份比较完整的 PRD 或技术方案。这个流程本身没有问题，它可以帮助我们快速梳理功能边界、页面结构、数据流和实现路径。但如果遇到一些“特别爱思考”的模型，比如 MiniMax-M3 这类模型，它可能不只是帮你规划产品功能，而是把每个模块、每个函数，甚至异常处理和 fallback 方案都提前写得非常细。

乍一看，这种文档非常专业，也很符合工程实践。它会考虑接口调用失败怎么办，AI 内容生成超时怎么办，返回内容不符合预期怎么办，甚至会提前设计一套 mock 数据或默认逻辑，保证页面始终可以展示出一个“看起来合理”的结果。

从工程角度来说，这当然是好事。稳定性、容错性、用户体验，这些都是一个成熟产品应该考虑的问题。

但问题在于，我们此时做的可能并不是一个成熟产品，而是一个 AI 应用原型。

原型的意义，不是让它在任何情况下都“看起来能跑”，而是验证一个核心假设是否真的成立。尤其是当我们做的是 AI 原生功能时，最需要验证的往往不是页面能不能渲染、按钮能不能点击，而是 AI 能力本身是否真的参与了这个体验，并且是否带来了不可替代的价值。

一个例子

举个例子，假设我想做一个 AI Web 应用：它可以根据我和 AI 的聊天内容分析我的情绪，然后动态修改网页背景。这个项目最重要的部分显然是“AI 是否真的能理解聊天中的情绪，并将这种理解转化成合适的视觉反馈”。

但如果在一开始，为了让功能看起来稳定，我硬编码了一些情绪解析规则，比如看到“开心”就切换成明亮背景，看到“难过”就切换成冷色背景；然后再加上一套 fallback：一旦 AI 调用失败，就走默认规则。最后这个项目可能确实看起来效果不错，也能顺利演示。

可这时就会出现一个很微妙的问题：如果主要效果来自硬编码规则，而不是 AI 的理解能力，那我为什么不直接做一个基于关键词规则切换背景的项目呢？

这并不是说 fallback、mock 数据或规则逻辑不重要。它们在真实产品中非常重要，甚至是不可或缺的。但在原型阶段，如果过早引入这些“让系统看起来合理”的工程化保护层，就很容易掩盖真正需要暴露的问题，比如调用不稳定、理解不准确、输出不可控，这些都是问题。

但这些问题恰恰是 AI 应用原型最应该帮助我们发现的东西。如果所有失败路径都被提前包装成了“合理结果”，我们可能会误以为这个 AI 功能已经跑通了，实际上只是一个被规则和 mock 数据支撑起来的交互幻觉。

给 Coding Agent 的约束

所以现在我会更倾向于在做 AI 应用原型时，对 Coding Agent 做更明确的约束：

1. 不要过早设计复杂 fallback。
2. 不要在核心 AI 能力上使用 mock 数据伪装成功。
3. 不要为了演示效果，硬编码过多规则。

更重要的是，要区分“工程上的可用”和“原型上的有效”。工程上的可用，强调稳定、兜底和体验完整；原型上的有效，则强调核心假设是否被真实验证。

如果一个 AI 功能失败了，我宁愿它在原型阶段直接失败，让我看到问题在哪里，也不希望它悄悄退化成一个规则系统，这也是我最近使用 Coding Agent 最大的感受之一：AI 不仅会帮我们写代码，也会帮我们“过度工程化”。它很擅长把一个想法包装成完整项目，但有时候，我们需要主动提醒它——现在不是在做一个完美产品，而是在验证一个不确定的想法。

对于 AI 应用开发来说，原型阶段最重要的不是把每条路都铺平，而是让真正关键的那条路暴露出来。如果 AI 能力是这个项目的核心，那就不要太早给它准备一条可以绕开的路。