上周末花了两天做完一个 AI 小应用，叫 RenameWiz。功能简单到不好意思发推：拖一堆文件进去，AI 帮你统一改名。
周日晚上 11 点部署上去，发了一条推。睡前以为它会无声无息消失。
第二天醒来，58 个用户用过，留言里一半在抱怨同一个问题 —— 它会把后缀名一起改了。
我在本地测的时候根本没注意到这事。因为我测试的方式是手动选三个文件、说"改成 xxx"，看输出对不对。从来没有人在 prompt 里写"保留扩展名"，而模型也从来没主动想到要保留。
这种 bug 你是测不出来的。不是因为它技术上多难发现，而是你预设的使用场景里根本没这个动作。
在键盘上想不出来的东西
我以前总以为，独立开发者最大的优势是"做事快"。两天上线，敏捷得像猫。
现在我觉得不是。最大的优势是「ship 之后能立刻看到真实使用」。
实验室里你怎么自言自语都行。部署上去，30 个陌生人用 30 种你没想过的方式戳它，半小时之内你能学到的东西，比自己在屋子里想一周还多。
这不是 "用户调研"。用户调研是你提问，他们回答 —— 中间过了一层语言的损耗。真实使用是他们直接戳，你直接看 log，没有任何修辞，问题摆在那里。
ship 的代价比你想象的小
我知道很多人卡在"再打磨一下就上线"。
我以前也这样。MatrixGPT 第一版我藏了三个月，每天都在修 UI 边距。直到有一天我看了下 git log —— 三个月写了 47 个 commit，没有一个改了核心功能，全是 padding 从 12 改到 14、从 14 改到 16。
那种状态下，每多藏一天都是负价值。因为你 ship 之前的所有判断都是猜的。猜对的概率不高于扔硬币，但你为每个猜测付出的时间是确定的。
后来我给自己定了一条规矩：做完核心功能 + 一个能用的 UI，就发。
"能用"的标准很低：不崩溃，不丢数据，不丢人。三条满足就发。padding 不对、字号不对、首屏没有动画 —— 全都不是不发的理由。
发完的第一周才是真开始
发布不是终点，是数据采集开始的起点。
RenameWiz 那个扩展名 bug 我当晚就修了。第二天又有人反馈"中文文件名乱码"，第三天有人问"能不能批量"。这些我事先一个都没想到，但每一个我都在 24 小时内修了或加了。
第一周用户给我的反馈密度，相当于我自己闭门造车一个月能想到的东西。
而且更关键的是 —— 会反馈的人就是会留下来的人。他给你提 bug 不是骂你，是在投资你。这种关系是闭门造车永远换不来的。
一个有点反直觉的结论
做独立产品久了，我越来越觉得：做出来的过程，没有 ship 之后改的过程重要。
第一版的代码可以写得烂，可以漏功能，可以有 bug。这些都能补。但你判断"什么值得补"的依据，必须来自真实使用 —— 而真实使用要先 ship 才能开始。
所以下次你又想"再打磨一下"的时候，问自己一句：这个打磨，是不是一种昂贵的拖延？
我猜十次有九次答案是是。