第 13 节：v2.2 到 v2.3，一次真实产品版本升级

版本号不是为了显得正式。

它应该记录产品真的发生了什么变化。

蜡笔小账本从 v2.2 到 v2.3，不是简单改一个数字。它背后有飞书绑定体验、安全加固、HTTPS、快捷安装、打卡修复、后台能力和正式上线准备。

这些事情单独看都不大。

但放在一起，就代表产品从“能跑”往“能公开”迈了一步。

v2.2 更像体验打磨

v2.2 的重点，主要围绕飞书记账。

这时候功能已经能跑，但用户不一定能顺利走完。

所以很多迭代都不是“大功能”，而是体验修补。

比如：

飞书弹窗里补充怎么找到机器人。

说明同一个飞书组织的限制。

把技术词改成更口语的步骤。

完善绑定码流程。

让用户发纯 6 位数字也能完成绑定。

这些改动听起来很细，但它们很真实。

产品往往不是靠一个大功能变好，而是靠这些小摩擦一点点被磨掉。

v2.3 更像上线整理

v2.3 的气质不一样。

它更接近正式上线前的整理。

包括全站 HTTPS。

敏感文件防护。

定时任务 token 更新。

自动备份。

App 快捷配置。

打卡天数修复。

后台导出和昵称显示。

这些不是为了让产品看起来更酷。

而是为了让它更适合给别人用。

一个产品能公开，不只是功能可用。

还要让账号、安全、备份、后台和版本信息都站得住。

更新日志要写给用户看

很多独立开发者会忽略更新日志。

觉得用户不看，写了也没用。

但更新日志不只是公告。

它也是一种信号：这个产品还在被维护。

用户看到版本更新，会知道问题有人修，功能有人继续推进。

对小产品来说，这种“有人在认真打理”的感觉很重要。

更新日志不需要写得很技术。

不要只写“修复若干 bug”。

可以写用户能理解的变化：

飞书绑定更清楚了。

小报更稳定了。

数据安全加强了。

可以添加到手机桌面了。

这比一堆代码提交记录更有意义。

版本升级也是一次复盘

每次升版本时，都适合回头问几个问题：

这次解决了哪些真实问题？

哪些是用户反馈带来的？

哪些是上线前必须补的？

哪些只是我自己想做，但不一定重要？

如果一个版本号背后没有这些答案，它就只是数字。

如果有，它就能帮助你看清产品是怎么长出来的。

蜡笔小账本这次升级，最重要的不是 v2.3 这个名字。

而是产品开始从“我自己能用”转向“别人也能更安心地用”。

本节小结

v2.2 到 v2.3，不是一次华丽升级。

它更像一次产品收拾：把能用的功能磨顺，把公开前的安全补上，把版本变化写清楚。

小产品的成长，经常就是这样。

不是每次都轰轰烈烈，但每次都把一个真实问题往前推一点。

下一节，我们会讲最后一步：怎么把这些真实产品过程写成 Blog，让 Google 和 LLM 都能更容易理解和抓取。

FAQ

版本号什么时候值得升级？

当产品发生了用户可感知的变化，或者完成了一组上线、安全、体验修复时，就适合升级版本号。

v2.2 的重点是什么？

v2.2 更偏飞书记账体验打磨，包括绑定流程、机器人搜索说明、同组织限制和绑定容错。

v2.3 的重点是什么？

v2.3 更偏正式上线准备，包括 HTTPS、安全防护、token、备份、快捷配置、打卡修复和后台能力。

更新日志要写得多技术吗？

不需要。更新日志应该让用户看懂这次对他有什么影响，而不是复制代码提交记录。

为什么版本升级也算产品复盘？

因为它能把一段时间内的真实反馈、修复和取舍整理出来，帮助你看清产品方向。