我用 Vibe Coding，做了一个会打电话提醒你的待办小程序

QUOTE

AI 把写代码变快了，却没有让把产品做上线变简单。

上一篇，我介绍了「准点响」是什么。这一篇，聊聊它是怎么真正做上线的。

有些事情，我们嘴上说着“千万别忘”，最后却只设了一个很容易被划掉的提醒。

父母下周要复诊，发过微信了，还是不放心；明早要赶高铁，设了三个闹钟，睡前仍要反复确认；一笔重要费用月底到期，日历早就记下了，通知弹出来时却顺手清掉了。

我想做一个更直接的提醒工具：你说一句话，它帮你记成待办；到了时间，不只弹一条通知，而是打来一通真实的电话。

这个想法后来变成了微信小程序「准点响」。

从第一行项目代码，到能够真实微信登录、真实发送提醒、真实接入支付链路，前后不到一个月。大部分设计、代码、测试和排错，都是我通过不断和 AI 对话完成的。

这听起来像一个标准的 Vibe Coding 故事。

但真正做完以后，我最大的感受是：

「AI 把写代码变快了，却没有让‘把产品做上线’变简单。」

本文看点

「准点响」最早的核心流程很简单：

长按说一句“明天上午九点提醒我去医院”，AI 把它整理成待办，用户确认后保存，到时间触发提醒。

第一版很快就跑起来了。标题、时间、备注，都能从一句自然语言里拆出来。那一刻很容易产生一种错觉：产品已经完成了八成。

真正测试起来，问题马上出现。

“明天九点”究竟是上午还是晚上？“今天九点提醒我开会”，如果现在已经十点，用户说的是今晚九点，还是说错了时间？“过会儿提醒我拿快递”里的“过会儿”，到底应该落在哪个时刻？一句话里同时说三件事时，备注和提醒时间又属于哪一条？

大模型会给答案，但它给出的答案不一定稳定，更不能直接当作产品规则。

后来，我把这条链路拆成了两层：AI 负责理解语言，后端规则负责校验和补全。对“今天、明天、后天”“上午、下午、晚上”和容易歧义的裸钟点分别处理；解析结果不会直接入库，而是先交给用户确认，时间不完整就必须手动补上。

这也是我遇到的第一个 Vibe Coding 误区：

「模型输出不是产品契约。AI 可以猜，但产品必须知道什么时候不能猜。」

待办保存成功，并不等于提醒一定会发生。

用户创建一条“下周三提醒我去复诊”，随后关掉小程序。几天后，服务器可能重启过，任务可能执行失败，用户也可能修改、完成或删除了这条待办。

如果只是写一个“到时间就执行”的定时器，Demo 看上去没有问题，真实环境却经不起任何意外。

于是，提醒必须变成一条由服务端持久保存的延迟任务：创建待办时安排任务，修改时间时重建任务，完成或删除时取消任务；真正触发前，还要再次检查待办状态和当前接收人。外部接口偶发失败，需要重试；部分联系人发送失败，也不能阻塞其他人的提醒。

这部分工作在界面上几乎看不见，却决定了「准点响」究竟是一个待办页面，还是一个真的能够在未来某个时刻行动的产品。

我开始理解，所谓“重要的事，万无一失”，不是一句首页文案，而是一连串很笨、很具体的工程判断。

我原本以为，接入电话提醒就是找一家服务商、申请一个接口，然后在任务触发时调用它。

真实情况是：电话和短信都有审核模板，发送内容要严格匹配已经审批的变量；账号、签名、模板和环境配置必须一致；手机号和日志需要脱敏；待办备注不应该被无边界地发送给外部服务；接口返回的“受理成功”，也不等于用户一定接听了电话。

最后，「准点响」把电话和短信统一成一套克制的提醒内容：称呼、待办标题、待办时间。备注留在产品内部，不进入外部通知模板。

电话是主要提醒方式，因为它比普通推送更难被忽略；短信则是一条免费的备用通道。当用户不想消耗电话提醒次数，或者次数不足时，可以切换为短信提醒。

这里还有一条我刻意保留的事实边界：

FACT CHECK

现在的产品不会承诺“电话没接就一定自动补发短信”，也不会把服务商接受请求写成“用户已经收到”。

真实产品不能靠模糊措辞制造可靠感。可靠感只能来自清楚地告诉用户：系统做了什么，又没有做什么。

我很早就想把待办共享给家人。

比如，子女创建一条“周五上午十点，妈妈去医院复诊”，不仅自己收到提醒，也让妈妈在同一时间收到电话或短信。

看起来只是增加一个接收号码，真正实现时却冒出一连串问题：谁有权修改这条待办？共享人能不能把它删掉？电话次数由谁承担？共享人退出后，未来的提醒还应不应该发给他？创建人修改时间时，所有人的提醒如何一起更新？

最后确定下来的规则是：创建人负责配置待办和通知方式，共享人可以查看并接收提醒，但不能修改创建人的内容；共享人可以退出尚未完成通知的共享关系；电话次数由创建人承担；提醒真正发送前，系统会重新读取当前共享人，而不是沿用创建时的一份旧名单。

为了避免“界面上不能改，换个请求却能改”，权限不只做在小程序页面里，也必须由后端再次判断。

这让我意识到：

「共享不是一个按钮，而是一套关于责任、权限和退出方式的产品规则。」

技术只是把规则执行下去。真正困难的是先把规则想清楚。

产品跑在浏览器里，和真正跑进微信里，是两件不同的事。

最开始，未登录用户一打开小程序就被送去登录页。他还不知道「准点响」能做什么，先要授权手机号，体验自然很差。后来我把首页和引导先开放给游客，只有当用户真的开始录入待办、查看清单或添加联系人时，才要求登录。

语音输入也踩过很具体的坑：手机微信、开发者工具和电脑端微信产生的录音格式并不完全一样。电脑端传来的 WebM 音频，服务器如果没有转码能力，语音识别就会直接失败。最终，生产镜像里不得不加入音频转换工具，才能让不同入口的录音走进同一条识别链路。

支付更是一次完整返工。

我最初接的是普通微信支付，接口、订单、回调和验签都已经做完。后来才确认，“电话提醒次数”属于小程序里的虚拟商品，必须走小程序虚拟支付。于是原来的支付链路不能将就使用，只能整体迁移：开发环境和生产环境分开，道具价格要和微信后台一致，支付成功后的权益发放要能防止重复，退款也要正确回退次数。

还有更多不会出现在产品宣传页上的细节：真实微信登录替换开发期模拟账号；用户协议和隐私指引补上 AI 解析、电话提醒与防骚扰规则；部署时先执行数据库迁移，再做健康检查，失败就自动回滚；生产镜像少复制一个静态目录，网页图片就会全部变成 404。

这些问题没有一个适合写进“十分钟做出一个 AI 应用”的教程里。

但它们才是上线本身。

它确实帮了很多。

我可以先把一个模糊想法讲给 AI，让它帮我拆产品规则、写设计文档、生成前后端代码、补测试，再根据真机反馈不断修改。过去可能要在几个角色之间来回传递的工作，现在可以由一个人快速推进。

在「准点响」的开发过程中，AI 尤其擅长三件事：

但 AI 不能替我决定：遇到模糊时间时应该猜，还是让用户确认；共享人应该拥有多大权限；电话次数不足时，是阻止创建，还是允许改用短信；为了平台合规，已经写完的支付链路要不要推倒重来。

AI 也不能替我拿起手机，真的走一遍授权、录音、创建待办、等待电话、切换账号、购买次数，再确认每个环节是不是符合预期。

所以，如果要用一句话总结这次经历，我会说：

「Vibe Coding 降低了‘把想法写成代码’的门槛，却抬高了‘你究竟想做什么’的重要性。」

代码生成得越快，产品判断越不能含糊。

今天的「准点响」，已经不是一个只能在电脑上演示的 Demo。

你可以用语音或文字说出一件事，让 AI 帮你整理成待办，确认时间和内容后保存；保存时可以选择电话提醒，或者使用免费的短信提醒，系统会在设定的时间发送通知；你也可以把待办共享给家人，让重要事项不再只装在一个人的脑子里。

它还不完美，我也不会把一次接口受理说成百分之百送达。

但它已经完成了我最开始想验证的那件事：能不能让一个普通的待办，在真正重要的时候，以更直接的方式找到你和你在乎的人。

答案是，可以。

先为你最怕忘记的一件事，建一条待办。

下一篇，我会不谈开发，专门讲清楚「准点响」到底能做什么，以及为什么我认为重要提醒不应该只依赖一条普通推送。