Vibe coding 之后，我开始重新想：做出来的是产品，还是产品的形状？

这是 Eval Design 系列的第一篇。

不过在讲 Eval Design 之前，我想先记录一个更前置的问题。

最近这一段时间，我自己也在做一些 AI demo / 小产品。过程中有一个感受越来越强：AI coding / vibe coding 确实让“做出来”变容易了，但也让我更频繁地问自己：

我现在做出来的东西，到底已经是产品，还是只是产品的形状？

这不是为了否定 demo。

相反，我越来越觉得 demo 很重要。它让一个想法不再只是停在脑子里，而是真的可以被点开、被操作、被验证。

但也正因为现在“做出来”越来越快，我反而开始更在意另一个问题：

什么东西，才算真正开始接近产品？

Demo 很有价值，但它证明的是“可能性”

以前一个想法要变成能交互的东西，需要设计、前端、后端、数据库、部署、调试，一层层往前推。现在一个人用 AI coding 工具、现成 API、模板和托管服务，几天甚至几个小时就能做出一个看起来挺完整的东西。

它有页面，有按钮，有登录，有数据库，甚至还能接支付。

从外观看，它已经很像产品。

这当然是很大的进步。

但我现在会把 demo 和产品稍微分开看。

Demo 更像是在证明：

这个 workflow 大概可行。这个模型能处理这类输入。这个交互方式有机会成立。这个自动化流程至少能跑通一遍。

这已经很有价值。

但 demo 通常证明的是：在一组相对理想的条件下，事情可以发生。

真正进入产品状态之后，要面对的就不是“能不能跑通一遍”，而是：

当输入变乱、场景变复杂、用户不按我预期使用时，它还能不能稳定地产生价值？

这两件事好像很接近，但其实不是同一个问题。

一个东西上线了，也不等于它已经成为产品。上线只是说明别人可以访问它。

产品要再往前一步：用户在真实场景里反复遇到同一个问题时，会不会自然想到它，愿不愿意回来用它，能不能放心把一部分判断交给它。

这部分，对我来说才是更难的地方。

AI 产品尤其容易让人误判

AI 产品有一个很迷人的地方：它很会“看起来有用”。

你给它几条干净输入，它能总结。你问几个问题，它能回答。你让它输出结构化内容，它也能写得像模像样。

一开始我也很容易被这种顺滑感鼓励到。

但慢慢会发现，AI 不是不会产出。AI 太会产出了。

真正的问题是：

这些产出能不能进入真实工作流。

比如一个 AI feedback 工具，demo 时给它 10 条干净的用户反馈，它可以总结成 3 个问题：

用户觉得 onboarding 复杂。用户希望导出功能更好。用户对价格有疑问。

看起来不错。

但真实反馈通常更脏：bug、抱怨、重复、付费信号和没说清楚的需求会混在一起。

如果 AI 最后只总结一句：

“用户希望体验更流畅。”

这当然像一个结论。

但如果我是 PM，我还是没法直接用它。

我还是不知道：

到底哪里不流畅？这是 bug、信息架构问题，还是新功能需求？有多少人提到？是不是高价值用户提到？证据来自哪几条原始反馈？下一步应该修、问、观察，还是暂时不做？

这也是我后来才慢慢意识到的差别：

“会生成”不等于“能被使用”。

所以这里真正缺的，可能不是再多一个总结模板，而是一套判断标准：

什么叫分对类？什么叫保留了证据？什么叫输出能进入 PM 的下一步动作？什么情况必须标记为不确定，而不是让 AI 继续自信地总结？

这也是我开始关注 Eval Design 的地方。

它不是为了让 AI 输出更好看，而是为了判断：这个输出到底能不能被用。

产品的难度没有消失，只是后移了

以前做产品，很多难度在“搭出来”。

现在 AI 把这部分成本压低了。这很好。

但我越来越觉得，产品的难度没有消失，只是后移了。

它从“能不能做出来”，后移到了：

做出来以后，有没有人真的需要？真实输入变乱以后，还能不能工作？用户第二次还会不会回来？输出能不能支撑行动，而不是只支撑截图？错误会不会被发现？失败以后有没有补救路径？下一版怎么知道真的变好了？

这些问题没有 demo 那么兴奋，但很真实。

一个能跑的界面，只说明它可以被打开。产品还要慢慢证明：有人会在真实场景里反复回来用它。

如果一个东西只能在我准备好的场景里表现很好，它可能是一个不错的 demo。

如果它能在真实场景里反复帮人完成一件具体的事，它才开始接近产品。

AI 的错误更麻烦，因为它常常不像错误

传统软件坏了，很多时候很明显。

按钮点不动。页面报错。数据加载失败。流程卡住。

AI 坏了，经常不是这样。

它会给你一个流畅、完整、语气自然、甚至很有条理的错误答案。

它可能漏掉关键事实。可能把用户没说过的话总结成需求。可能把两个不同问题合并成一个。可能把“不确定”写得像“确定”。可能给出一个看起来很专业、但实际无法执行的结论。

这也是为什么我现在不会只看一个 AI demo 的展示效果。

因为最危险的不是它完全不能用。最危险的是：它看起来已经能用了。

我现在会提醒自己：先别急着加功能

很多 AI 小产品做出来以后，我最自然的冲动也是继续加功能。

加登录。加历史记录。加导出。加更多模型。加更漂亮的页面。加更多自动化。

这些都可能有用，但不一定总是最关键的问题。

有时候更该先问的是：

它什么情况下算做对？什么错误必须拦住？改了一版之后，怎么证明真的变好了？

这就是 Eval Design 对我有吸引力的地方。

它不是在给 AI 考试。它是在帮我们回答一个很朴素的产品问题：

这个 AI 产物，到底靠不靠谱？

或者更具体一点：

它在什么场景下算做对？在什么场景下算做错？错了以后怎么被发现？下一版怎么证明变好？

如果 vibe coding 解决的是“能不能做出来”，Eval Design 关心的是“做出来之后，怎么判断它能不能被真实使用”。

我会用三个问题检查自己的 AI demo

如果你也在做 AI 产品、AI demo，或者正在把一个 vibe coding 作品认真往前推，也许可以先不急着问“还能加什么功能”。

我现在会先问自己三个问题。

第一，它解决的是不是一个会反复出现的问题？

一次性惊艳不够。产品需要重复场景。

用户不是因为好奇打开一次，而是因为下次遇到同类问题时还会回来。

第二，真实输入变乱以后，它还能不能产出可用结果？

不要只测干净样例。

真实用户不会按照 demo 脚本生活。他们会表达混乱、信息缺失、前后矛盾、带着情绪，也会提出我没想到的边界问题。

第三，我怎么知道下一版真的比上一版更好？

这可能是很多 AI 小产品最薄弱的地方，也是我自己还在学习的地方。

如果只是凭感觉调 prompt，很容易陷入一种错觉：

这版看起来更自然，所以它更好。

但也许它只是更会说话。准确性没有变好。幻觉没有减少。错误更不容易被看出来。甚至成本和延迟都变高了。

没有判断标准，迭代很容易变成玄学。

这篇真正想记录的

AI 让“做出来”变便宜了。

这是一件很大的事。它让更多人可以把想法落地，也让个人 builder 的能力边界被放大。

但它没有取消产品的难度。

它只是让我们更早来到下一个问题面前：

做出来以后，怎么被真实使用？被使用以后，怎么知道它可靠？不可靠的时候，怎么发现、修正、迭代？

这也是我想继续写 Eval Design 的原因。

它不是一个为了显得专业的新词，而是在 AI 产品里回答一个很朴素的问题：

这个东西到底有没有做对，以及下一版是不是真的变好了。

当越来越多人能做出产品的形状，真正稀缺的可能会变成判断能力。

下一篇，我会继续整理：Eval Design 到底是什么，以及为什么它不是简单的“给 AI 打分”。