一个月 140 个版本

一个不太正常的数据

Alice 从第一个公开版本到写下这篇文章，33 天，140 个版本。

5 月 11 号这一天，发了 8 个版本。5 月 10 号，7 个。5 月 8 号，8 个。不是每个版本都是大更新，有些是一个 bug 修复，有些是一个小功能。但每一个版本都是用户可以感知到的真实变化。

很多人问：你怎么做到发版这么频繁、这么快的？

标准答案是 Vibe Coding 本来就快。AI 辅助编码让任何人写代码都变快了。但这只回答了”写代码”这一环。从”想到要做什么”到”所有用户都拿到了更新”，中间还有大段的路。

快的不只是写代码。快的是整条链路。

知道该做什么

发版快的前提是知道该发什么。

独立开发者最容易掉进的坑是闭门造车。自己用自己的产品，觉得挺好的，哪里需要改也是自己的判断。但一个人的视角是有盲区的，你习惯了的怪异之处，新用户第一分钟就会碰到。

Alice 的需求来源有两条管线，汇聚到同一个地方——许愿池。

第一条：用户直接提交。 用户可以在 Web 端提交想法，也可以在 Alice 客户端里跟 Alice 说一句”帮我提个需求”，Alice 就会把想法整理好提交上去。截图、投票、评论、状态追踪，一条龙。

不需要注册登录。打开页面就能用。对早期产品来说，注册流程是用户流失的最大杀手。

第二条：AI 自己提需求。 Alice 在帮用户做事的过程中，如果发现产品可以改进的地方，会主动提交建议。AI 给 AI 产品提需求，这件事本身就挺有意思。但更实际的价值是：Alice 能从用户视角发现很多我自己用不到的痛点。

两条管线汇聚后，投票排序。票高的需求浮到顶部，比开发者拍脑袋判断优先级更客观。

需求不是想出来的，是涌进来的。我要做的只是处理它们。

处理得够快

需求涌进来了，但用户提交的需求大多是模糊的。”希望支持 XX”“某个功能有点卡”“界面不太对”。

传统做法是开发者一条一条阅读，理解用户意图，对照代码分析问题，判断是 bug 还是功能请求，写需求澄清文档。一条需求的澄清可能需要半小时。

我的做法是把这个过程交给 Cursor。

从许愿池后台拉取所有待处理的需求列表，贴给 Cursor，给一条指令：挨条澄清，一定要看源代码之后再澄清。每条需求都可以开一个子任务。

Cursor 同时开了 20 多个子任务并行处理。每个子任务先读项目源代码理解当前实现，然后分析用户的问题到底是 bug 还是功能请求。如果是 bug，直接定位到具体文件和代码行，分析根因，修复。如果是功能请求，写出结构化的需求澄清文档，通过 API 直接写回许愿池。

一次操作，20 多条需求全部处理完。总共十几分钟。

以前一条需求澄清要花半小时，20 条是 10 个小时。现在 20 条一起处理，我花在审阅上的时间是十几分钟。AI 做了读代码、分析问题、写文档这些重复性高但思维密度低的工作，我做最终的判断和确认。

这是需求处理速度从”个位数每天”到”两位数每天”的关键。

发出去够快

代码写好了。然后呢？

传统的发版流程：手动升版本号 → 手动写更新日志 → 手动打包 → 手动签名 → 手动公证 → 手动上传 → 手动刷新缓存 → 手动更新官网。一套走下来，即使一切顺利，也要 40 分钟到一个小时。

这个流程足以让你从”想到就发”变成”攒一批再发”。一旦开始攒，用户等待的时间就变长了，反馈循环就慢了。

Alice 的发版被做成了一个 AI 技能。我说”推个热更”或者”打个包”，AI 会自主判断应该走哪条路。

如果只改了界面、逻辑或提示词，走增量热更新——只重新打包前端产物，上传到云存储，写入后台数据库，刷新缓存。用户下次启动时自动下载几 MB 的更新包，校验通过后替换，提示重启。全程 30 秒。

如果涉及底层框架或依赖变更，走完整发版流程——双平台同时构建，代码签名加公证，上传到多个存储桶，兼容新旧客户端。40~60 分钟。

热更新覆盖了大多数改动场景。5 月 10-11 号那两天的 15 个版本，绝大多数走的是热更新。这就是为什么一天能出 8 个版本：每个版本的发布成本是 30 秒，不是 1 小时。

发版时还有一步自动化：AI 会去许愿池拉取所有用户想法，对比本次发版的功能点，如果某个功能和某条想法匹配，自动更新想法状态为”已发布”，自动发表评论”你的想法已在这个版本实现”，更新日志里自动追加感谢行。

整个过程，我只需要在最后确认一下”发布？”。

本地 F5 的延伸

这个流程的设计灵感来自一个很朴素的类比。

你写代码的时候，按一下 F5，程序就跑起来了，你立刻能看到效果。这个反馈速度是毫秒级的。但这个体验只属于你自己。你的用户看不到。

热更新就是把”我按 F5”延伸成”所有用户感受到变化”的链路。改一行代码，说一句”推个热更”，30 秒后所有用户的下一次启动就能拿到这个变化。

5 月 11 号一天 8 个版本，靠的不是手速快。是这条自动化链路让”从想到做到”的成本趋近于零。

让用户知道

发版快只是一半。另一半是让用户知道：你提的需求已经上线了。

当许愿池里某条想法的状态变成”已发布”，用户的 Alice 客户端会在下次签到时收到弹窗通知——“你的想法有了新进展”。点击可以查看详情，也可以让 Alice 继续跟进。

没有用推送服务，就是复用已有的定时签到通道。基础设施越少越好。

这条链路的价值不在技术上，在心理上。

一个用户今天提了个想法，明天收到通知说”已经上线了”。这种体验让用户觉得自己参与了产品的成长。他下次还会继续提。

反过来，如果用户提了想法，等了两周没有任何回应，他大概率不会再提第二次。你丢失了最有价值的信息来源。

闭环比速度重要。但如果闭环足够快，它本身就是速度的一部分。

真实的例子

140 个版本不是一个抽象的数字。

v0.3.11 修复了 Mac 端命令行工具执行失败的问题，这是许愿池用户反馈的。从反馈到修复到所有用户拿到更新，不到 24 小时。

5 月 10 号的 v0.3.3 和 v0.3.4 都包含工作目录相关的修复，v0.3.5 又做了一次调整。三个版本在同一天发出来。每次修复后能立刻推给用户验证，发现还有问题就再发一个。这种节奏在传统的”攒一批发版”模式下是不可能的。

v0.3.1 上了信件附件功能，v0.3.2 优化了信件写作的效果，v0.3.7 新增了 Alice 自拍工具。每个版本做一件事，做好就推出去。用户不需要等一个月才能看到一个包含 20 个功能的大版本。

发版是一个乘法

把整条链路拆开看：

需求获取速度 × 需求处理速度 × 编码速度 × 发版速度 × 反馈速度 = 迭代频率

大多数人只在”编码速度”这一项上使用 AI。AI 辅助编码确实很快，所有人都快。但如果其他环节没有跟上，编码再快也被瓶颈卡住。

我的做法是在每个环节都加了杠杆：

当每个环节都是几倍到几十倍的加速时，乘在一起就是一个月 140 个版本。

任何一个环节没有自动化，都会成为瓶颈。如果发版要 1 小时，你不会愿意每天发 8 个版本。如果需求澄清要半小时一条，你不会愿意每天处理 20 条需求。如果反馈没有闭环，用户不会持续提交想法，需求源就干涸了。

一句话

发版快不是因为代码写得快。代码写得快是所有人都有的能力。

发版快是因为从”知道该做什么”到”所有用户拿到更新”的整条链路，每一个环节的摩擦都被削到了最低。

许愿池让需求结构化涌入，AI 并行澄清让处理变成批量操作，自动化发版让”推一下”变成 30 秒的事，反馈闭环让用户持续参与。

本地 F5 的体验，延伸成了所有用户的实时体验。

Alice · alice.miyang.cn