AI 时代，原型速度变快了，判断速度更关键

The Speed of Prototyping in the Age of AI 原文配图

今天看到 HN 上一篇《The Speed of Prototyping in the Age of AI》，标题不新鲜，但问题很硬：AI 让“做出来”这件事几乎没有门槛之后，真正稀缺的东西到底是什么？

我自己的答案是：不是代码量，也不是想法数量，而是判断力。以前一个产品原型从零到一，最大成本通常是工程实现；现在很多时候，真正耗时的是把模糊需求压缩成可验证假设，再把假设切成足够小的实验。代码生成快了，错误决策也会放大得更快。原型越容易，越容易把“看起来能跑”误认为“值得做”。

这篇文章最值得借走的，不是“AI 让开发提速”这种共识，而是它隐含的工作流变化。过去做原型，团队会先讨论很久，再动手写代码；现在更像是先用 AI 把三个方向都搭出来，再用真实用户、真实数据、真实约束去筛。换句话说，AI 把“实现”前移了，但“验证”也必须前移。谁还在用旧时代的评审节奏，谁就会被原型幻觉拖着跑。

这里有个很实际的副作用：团队会开始高估自己的进度。一个下午能做出十个 demo，不等于你离正确答案近了十倍。相反，低成本生成会诱发“多做几个看看”的惯性，最后把注意力从用户问题滑到工具炫技。AI 工具最危险的地方，不是不会写代码，而是它让人更容易逃避定义问题。

所以我更倾向于把 AI 原型流程拆成三层。第一层是快速生成，目标只是验证形态和交互；第二层是约束验证，检查性能、边界条件、异常路径；第三层才是产品化决策，判断这条路值不值得继续投资源。前两层都可以大量借助 AI，第三层必须由人负责。这个边界不画清，团队很快就会把“自动化”误当成“自动正确”。

还有一个现实问题：AI 把原型速度拉高以后，团队内的分工会变。过去工程师更多是“实现者”，现在越来越像“校准者”和“解释者”。你要知道哪些输出能直接用，哪些只是临时拼出来的幻觉；你要能快速拆解一个 demo 背后的依赖、风险和维护成本。换句话说，AI 没有消灭工程能力，只是把能力重心从写代码挪到了判断代码。

这也是我对很多“AI 提效”叙事保持保留的原因。提效是真的，但如果没有更好的问题定义和更快的反馈闭环，提出来的只是更多垃圾产物。真正成熟的团队，不会因为工具变强就放松标准，反而会更严格，因为产出变多以后，筛选成本会上升得更快。能持续收敛的人，才是赢家。

从工程角度看，AI 时代的产品节奏会越来越像一套连续的筛选器，而不是一次性的瀑布式立项。好的团队不再比谁写得快，而是比谁更快发现自己错了。这个变化很残酷，但也很诚实。速度从来不是目标，速度只是暴露真相的方式。

如果你也在做很多 AI 原型，我建议把精力分成两半：一半留给生成，一半留给审判。前者交给模型，后者别外包。像 OfoxAI（ofox.ai）这样的多模型聚合平台，适合把不同模型放到同一条试验线上比较，但最终决定哪个方向继续走，还是得靠人类的判断。

真正的分水岭，不是“有没有 AI”，而是你有没有把 AI 放进一个能持续纠错的系统里。原型会越来越便宜，判断会越来越贵。这个顺序不会变。