「我估摸着60到70小时，一个月周末搞定。」结果：165小时。一个创始人用计时器戳破了MVP的幻觉。
「最小」是个安慰词
问任何创始人MVP做了多久。三个月。五个月。八个月加一次转型。Syra的创始人发现，"最小"这个词已经被拉得失去原意——它现在是个心理缓冲垫，让范围膨胀时不那么难堪。
他记录每一次工作会话：类别、时长、备注。结果让他不适到必须写下来。
Syra是个什么产品？AI驱动的创意验证工具。核心卖点：创始人常选错方向，埋头开发数月后才发现没真实需求。Syra给出一个「做/放弃/观望」的判定，背后有真实的48小时验证测试，不是猜测，不是感觉。
原计划很简单：后端、前端、调几个大语言模型接口。应该很快。
实际呢？前端 alone 超过9000行代码。纯手写，没用组件库。每个交互都经过设计。这不在原计划里——但它变成了计划，因为「 shipping 一个感觉不对的东西」无法接受。
这就是计时器揭示的第一层真相：锁定的不是功能列表，是「完成」的标准。
功能没膨胀，标准膨胀了
大家谈范围蔓延，总以为是功能偷偷溜进需求池。Syra创始人说，他的功能列表是锁死的。
膨胀的是他对「完成」的定义。那些额外的工时，没花在加功能上，花在让已有的东西「对味」。
没人告诉他这一点：MVP里的「最小」是个移动靶，锚定的是你的品味。
他提出一个检验标准，后悔没从第一天就用：
「删掉这个，会破坏产品的核心承诺吗？」
是——保留。否——砍掉，或者延后。
Syra的核心承诺是什么？「给创始人一个清晰的判定，快速，且有真实测试支撑。」
按这个标准复盘：
那个随判定结果变色的反应式配色系统？删掉不破坏承诺。本可以没有。
那个并行异步管道，把响应时间砍半？删掉就破坏承诺。必需。
那个精心撰写的About页面叙事？很美。但那是第二周的事，不是第一周。
165小时里的大部分，花在了不破坏核心承诺的事情上。它们让产品更好——但不是最小。
我建了个1.5版，叫它MVP
他列出实际交付物，问自己：这些单独看有必要吗？没有。
集体看呢？「我建了个V1.5，叫它MVP。」
给自己的判决：有罪。
这个自我审判引出四条具体建议，每条都指向同一个问题——如何用外部约束对抗内部品味的无限扩张。
第一，写代码前先写一句核心承诺。他的版本：「两分钟内返回带真实测试的做/放弃/观望判定。」一切不服务这句话的，都排进发布后。
第二，设硬性的时间预算，而非功能列表。功能列表会膨胀，时间预算强迫你做减法。
第三，先给一个人 ship 丑陋版。不是Product Hunt。一个创始人。观察哪里卡住了。从「哪里坏了」建，而非从「哪里看着不舒服」建。
第四，把品味当技术债务处理。它是真实的，重要的，但应该在迭代周期里逐步偿还——而不是前置到发布前。
165小时的镜像
这个数据点本身值得玩味。60-70小时的预估，165小时的实际，偏差2.4倍。
创始人没有解释偏差来源，但时间日志的结构说明了一切：「类别、时长、备注」——他追踪的不是功能完成度，是注意力的流向。
9000行前端代码，手写，无组件库。这个数字在原文里很突兀，像是不小心说漏嘴。它暗示了什么？
一个AI工具的核心价值在后端（大语言模型调用、48小时验证逻辑），但165小时里有显著比例耗在「每个交互都经过设计」的前端。这不是技术必要性，是审美必要性。
「不能 ship 感觉不对的东西」——这句话在原文出现两次，一次解释前端膨胀，一次解释整体超时。它是理解这165小时的关键线索。
但这里有个未被追问的问题：谁的感觉？
创始人的感觉，还是用户的感觉？计时器显示，大量时间花在创始人自己验证才能 ship 的环节，而非用户验证需要的环节。第三条建议（先给一个人 ship 丑陋版）之所以有力，正是因为它试图用外部反馈替换内部标准。
「最小」的重新定义
这篇复盘最尖锐的地方，是把MVP从「功能最少」重新定义为「承诺最纯」。
不是列表短，是列表上的每件事都直接支撑那句核心承诺。不是做得糙，是做的每件事都经得起「删掉会破坏承诺吗」的拷问。
这个框架把品味从敌人变成了可管理的债务。你可以有品味，可以偿还品味，但不能让品味在发布前无限透支你的时间预算。
Syra最终 ship 了。原文没提发布后的数据——用户反馈、留存、转化，这些都没有。计时器在发布那一刻停止，故事停在自我审判的节点。
这或许是最诚实的部分。MVP的教训往往在 ship 前就已完整， ship 后的数据是另一堂课。
165小时，2.4倍预估偏差，9000行手写前端代码，一个「有罪」的自我判决。这组数据勾勒出一个常见但少被量化的创始人困境：我们知道该做最小，但「最小」的边界由我们的品味绘制，而品味从不自我设限。
计时器是廉价的约束工具。它不负责告诉你该做什么，只负责记录你实际做了什么。当165小时摆在面前，「最小」这个词的安慰属性就失效了——数字不会配合你的自我说服。
创始人最后把Syra的发布日期写在文档里，像是一个句点。但日期后面没有故事，没有「然后用户增长了X%」或「然后我发现」。只有一个空白，和四条给下一个人的建议。
这个结构本身在说：MVP的教训属于 ship 前的黑暗森林， ship 后是另一片地形。别用后者的成功或失败，来合理化前者的超时。165小时就是165小时，一个需要被直视的数字。
热门跟贴