产品上线的那一天，不是结束，而是真正开始。
更新太快和太慢都有问题。
更新太快，用户会疲惫——他们刚适应新界面，又变了。频繁更新容易引入新 Bug，产品难以保持稳定，文档也跟不上。更新太慢，用户的需求得不到满足，他们会失去兴趣，竞争者可能趁机超越你，而且你也缺少了反馈循环——改得慢意味着学得慢。
好的更新节奏是既能快速响应用户需求，又能保持产品稳定。怎么做到？老师傅教了小明一个方法：分层。
小明问："新功能直接全量上线不行吗？"
老师傅说："你刚吃过亏。新功能先给一小部分用户用，没问题再全量。这叫灰度发布。"
灰度发布的好处很直接：问题只影响部分用户，降低了风险；在真实环境中验证功能，比测试环境更可靠；稳定后再逐步放量，全量发布时你已经有信心了。
具体怎么做？最简单的是白名单——指定几个友好用户先用，适合内部测试。进阶一点是百分比——随机让 10% 的用户看到新功能，适合大规模验证。还可以做随机分桶，本质上就是 A/B 测试。或者条件触发——满足特定条件才显示新功能，适合风险控制。
功能开关（Feature Flag）是实现灰度发布的常用方式。告诉 Claude Code 你需要一个功能开关系统，描述清楚白名单和百分比逻辑就行——具体实现取决于你的技术栈。
不同阶段适合不同的节奏。
早期是快速迭代阶段——一周一个小版本，关注核心功能，快速验证假设，不过度优化。这个阶段的目标是找到方向，速度比完美更重要。
成长期是稳定节奏阶段——两周一个小版本，每月一个大版本，质量和速度并重。这个阶段你已经知道方向了，开始扩张功能，同时注重稳定性。
成熟期是持续优化阶段——节奏放慢，重点从"加功能"转向"优体验"，深耕价值。
小明的产品还在早期，所以他选择了快速迭代。
老师傅给了一个简单的原则：80% 精力在稳定性和 Bug 修复，20% 精力在新功能开发。
这个比例可能让你意外——"80% 修 Bug？那新功能什么时候做？"但道理很简单：用户宁愿用一个稳定的简单产品，也不愿用一个功能丰富但经常崩溃的产品。稳定是一切的基础。
资源有限，要把精力放在用户真正喜欢的地方。
怎么识别受欢迎的功能？看四个信号：使用率高（功能使用频率高）、正面反馈多（用户主动提及）、留存贡献大（使用该功能的用户留存更好）、付费意愿强（用户愿意为此付费）。
识别出来后，怎么加强？可以深化功能——做得更强大、更完善。可以相关扩展——添加相关功能，让核心体验更完整。可以优化体验——让功能更好用、更顺滑。也可以宣传推广——让更多用户知道这个功能的存在。
小明回顾这几个月的经历，发现一个规律：每次改动越小，效果越好。
小改动降低风险——每次改动小，出了问题容易定位。小改动带来快速反馈——更快知道方向对不对，不用等一个月才发现走错了。小改动心理轻松——不需要"憋大招"，每天都有进步的感觉。小改动积少成多——一周改一个小问题，一年就是 52 个改进。
这就是"小步快跑"的核心：不要追求一次性的大突破，而是追求持续的小改进。
老师傅最后跟小明聊了一个更大的话题：长期主义。
短期思维追求爆款，长期思维追求持续改进。短期思维想快速扩张，长期思维追求稳健增长。短期思维想取悦所有人，长期思维专注服务核心用户。短期思维期待一夜成功，长期思维相信日积月累。
"你看到的那些成功产品，"老师傅说，"它们不是一夜之间变成那样的。它们都经历了无数次迭代，无数次失败，无数次调整。你现在做的每一个小改进，都在为未来积累。"
小明回头看看自己走过的路。
从第一章搭环境开始，他学会了用 Claude Code 写代码、用 PRD 定义需求、用组件库搭界面、用数据库存数据、用 API 连前后端、用认证保护用户、用测试保证质量、用 Git 管理代码、用 Vercel 部署上线、用 Umami 看数据、用 SEO 让人找到他。
现在，他有了一个真实的产品，有真实的用户，有真实的反馈。他知道怎么收集反馈、怎么排优先级、怎么理解用户、怎么持续迭代。
产品还很小，用户还不多。但它在成长，他也在成长。
产品上线不是结束，而是真正的开始。去做吧。