已经不知道唠叨多少次了，Demo 是 Demo，产品是产品。

在推特上，见过不少这样的评论。

某个产品发布后，时间线上就会有人说：「这有什么难的，两三天就能 Vibe 一个出来。」

或是，市井里常有的传说，某某全栈工程师半天手搓一个 App。

每次看到这类评论都会停一下。不是因为他说的是假话，而是认可他说的可能是真的，只是说的不是同一件事。他能做出来的，是一个理想环境下能跑起来的东西，那个叫 Demo。但「能跑起来」，只是回答了「这件事能不能做出来」，而不是「一个用户是否愿意长期使用的产品」。

这两个状态之间，隔着一条鸿沟。

Vibe Coding 让「从零到跑起来」的成本大幅降低，但也带来了一种隐蔽的认知风险：Demo 跑通的那一刻，很容易低估后续真正需要投入的时间和系统性工作。

长尾里的时间

因为工作，被迫关注笔记与文档编辑器有些年头了，有个暴论：一个文档编辑器，即使是简单的 Markdown，不经过一年半的打磨，也是无法满足大批量用户使用的，只能算是个玩具。也就是说，如果你有做笔记或者文档产品的想法，最好的时机是一年半前，其次是现在。

对这件事感受比较深。Demo 跑起来的时候，所有条件都是理想的：用户按预期路径走，数据是全新的，环境是干净的。这些隐性假设，我们在做的时候完全不会注意到，因为它们从没被打破过。

但用户量和数据量一旦上来，这些假设就会逐一崩塌。复制粘贴、撤销重做、跨端同步、数据越来越多、状态越来越脏、历史兼容性的问题开始冒出来。还有一类更难处理的，是用户行为本身，他们会以各种我们根本没预料到的方式使用产品。

我记得有一段时间，感觉每天都在修一类问题：不是新功能，就是各种「理论上不应该发生」的边界情况。这个时间跨度是无法取巧跨越的，因为有太多的长尾场景和异常状态，只能靠真实的用户使用和时间一点点磨出来。那段时间很枯燥，说不清在做什么，也很难有什么成就感，就是把不确定性一点一点磨平。这就是长尾的本质，它不是一个可以规划的阶段，而是只能靠真实的使用和时间慢慢磨出来的过程。

我以前也以为从 Demo 到产品，是在原有基础上往上加东西：加引导、加帮助文档、加错误提示。加着加着就成产品了。后来发现这个理解是偏的，产品和 Demo 的差异，不是功能多了几个，而是解决的问题性质变了。

Demo 回答的是：这条链路能不能跑通。产品回答的是：在大多数真实的、混乱的、你没预料到的情况下，它能不能稳定地帮用户完成任务，并且可以持续迭代下去。这两件事，看起来只差一步，实际上是两种不同的战场。

从 60 分到 95 分发生了什么？

比较喜欢用这个刻度来衡量这件事。

60 分是主链路跑通，Demo 算是接近这个分数。80 分是核心用户在相对理想的条件下能稳定完成任务，看起来已经很完整了，达到了可用性的级别。95 分是另一种维度，完成从可用性到易用性的越级。它意味着大量人长期用，在真实世界的脏数据、复杂输入、各种长尾情况下，依然稳定交付价值，用户遇到问题也不慌，因为他们知道产品能带他们回来。到了这个程度，产品本身的体验也成为了壁垒。

从 60 到 80，不是一件很难的事，初期的投入基本可以实现。但从 80 到 95，每进一步需要的代价都在成倍增加，而且问题的性质已经悄然变了。

越往后，系统越来越脆。每多兼顾一个场景，藏在角落里的边界情况就会随之增多，每一次改动都可能牵动意料之外的地方，比如，你的产品有 50 个功能，计划增加的第 51 个功能，可能要考虑和前 50 个功能的交集。而脆的系统更容易出错，用户信任偏偏最经不起折腾，需要很长时间不出大问题，才能慢慢积累，一次出错就可能把这份积累清零。

想控制这种局面，直觉上应该做减法，但这恰恰又是最难的事。功能越积越多，每一次裁剪都牵连着既有的用户习惯、系统依赖和历史决策，取舍的代价越来越高，越到后面越难下手。

在 80 到 95 分里，可见的优化越来越少，更多的投入落在那些不起眼的体验上。跨端同步的流畅感，数据量庞大时依然保持的轻盈，这些用户说不清楚却能感受到的东西，往往需要先拆解成细分的维度，再一层一层打磨扎实。这类工作很难被看见，也很难有成就感，就是把一个看起来没什么问题的地方，磨得更结实一些。

跨越鸿沟的最小 MVP

老实说，面对满目疮痍的产品，几乎是每天工作的日常，甚至会遇到那种无从下手的残次品。

但不管写代码的方式怎么变，产品的打磨逻辑其实没怎么变，就是想办法让它先跑起来，哪怕很粗糙，跑在自己手里，或者一小撮用户手里。

于是，我们的工作就变成了剪刀手爱德华，将一个完整计划的产品裁剪成看上去有点丑但最小的 MVP。

以前在开发环境里点点鼠标，只要主流程能通，就容易产生一种「差不多可以了」的错觉。一旦我们开始强迫自己把半成品当主力工具用，带着乱七八糟的真实数据去跑每天的任务，漏洞百出，这个就是俗称的 dog fooding。

但自己吃自己的狗粮，有一点特别好，就是你既是那个踩坑的倒霉用户，又是那个能直接填坑的修理工。碰到用得不顺手的地方，不用记在什么反馈文档里，当场就改了。改完接着用，接着发现新问题。这种感觉，就像是把本来需要放到真实用户那里去绕的漫长圈子，硬生生在自己的工位上提前转完了。

现在有了 AI Coding，这个节奏变得有点夸张。以前哪怕自己发现了问题，想到改代码的成本，可能也会拖一拖。现在，从「感觉不对劲」到「把它修好」，这段距离被极度压缩了。每天自己用产品的时候，都像是在进行一场开了快进的高速磨合。

等它真的被推到外部用户面前时，至少，已经不再是一台刚拼装好的毛坯机器了。

写在最后

这里有个更悲惨的事实，前面写的这些，从长尾的打磨，到 Dog fooding，到 AI 加速迭代的循环，说到底都在回答同一个问题：怎么把产品做好。但做好产品，只是能上场的前提。

决定一个产品能走多远的，很多是产品之外的事。它怎么被人发现，怎么在某个渠道里找到自己的立足点，怎么让用户愿意留下来，怎么在口碑里慢慢扩散出去。这些事情，没有一件能仅靠写代码解决，也没有一件能靠「产品再打磨一下」来回避……

不过，我也没有要贬低产品经理的工作，说到底，把产品做好这件事，本来就不是某一个角色能独自完成的。