用AI做小程序：难的不是代码而是判断

从一个真实痛点出发

很多技术项目都有着宏大的立项愿景，但这位B站UP主分享的「做久起身小技」小程序，起点却朴素得让人共鸣——长时间久坐后，他的左肩会有些酸痛。他知道久坐不利健康，也在微信里找过同类工具，但要么不能自定义提醒间隔，要么需要填写一堆信息。

而他真正想要的功能极其简单：选一个时间，点击开始，到点提醒起身，起身后点一下「已起身」重新计时。既然没有找到完全合适的，他决定自己动手。

这个起点看似普通，却隐含了整个项目最核心的方法论——先认清真正需要解决的那个问题。在AI大幅降低开发门槛的今天，这篇分享的价值恰恰在于揭示了一个反直觉的事实：写代码这件事本身，反而成了最不困难的部分。

不必等所有知识学完再开始

作为一个从未做过微信小程序的人，UP主最初的做法是去B站等平台找教程。但完整教程动辄十几个小时起步，还冒出认证、备案、云函数这些陌生概念。看得越多，反而越觉得复杂，想法也因此拖延了一段时间。

转机出现在他看到一些AI开发小程序的案例之后。他意识到：自己不需要先把整套知识全部学完，可以先从描述清楚需求开始，做一个最小可实现的版本（MVP）。

这是AI时代开发范式的一个重要转变。过去，技术门槛意味着必须先系统性掌握知识才能动手；而现在，注册一个小程序、验证一次订阅消息、让一条提醒真正送达，这些微小的实践启动，往往比看完十几个小时教程更有效。行动本身成了最好的学习路径。

做减法比做加法更难

在产品设计阶段，UP主最初的设想相当丰富：不仅想记录久坐时间，还想区分「站立」和「起身活动」，甚至支持升降桌的坐站切换。但和AI讨论之后他发现，这些功能虽然都有使用场景，却会让最常用的操作变得复杂。

对普通用户来说，收到提醒后离开椅子活动一下就够了。于是第一版只保留了一个核心动作——「已起身」，它同时代表一次起身活动和重置计时器，其他非核心功能全部推迟实现。

「做产品并不是把想到的所有功能都加上去，有时候删掉什么功能比增加什么功能更加重要。」

这句话点出了产品设计的本质。AI可以帮你快速实现任何功能，但正因为实现变得如此容易，克制的判断力反而变得更加稀缺和宝贵。

AI能加速执行但不能替你理解系统

技术方案上，UP主最早考虑过Spring Boot、MySQL、Redis加独立服务器的重型架构，后来结合实际改成了微信原生小程序加腾讯云CloudBase，这样不用先准备服务器和域名，能更快验证想法。

但真正把小程序跑起来后，最让他困惑的不是某一行代码，而是前端小程序、云函数、触发器三者之间如何配合。他一度发布了前端、部署了云函数，却始终收不到后台的微信提醒。排查后才发现：触发器需要单独上传——上传小程序代码不等于部署云函数，部署云函数也不等于上传触发器，少了最后一步，云函数就不会按固定时间扫描，自然也不会发送提醒。

梳理清楚后，整个提醒链路变得清晰：小程序在前台时，页面直接计时并弹出提醒；退到后台后，前端无法可靠运行，就靠云函数定时扫描再调用微信接口发送服务通知。两条链路共用云端保存的时间状态，但各自负责不同场景。

这段经历带来的启示很关键：即使使用AI开发，也不能只盯着代码有没有生成。具体代码可以让AI实现，但开发者至少要知道系统由哪些部分组成、数据从哪里来、每一步如何衔接。AI能加速执行，但不能替你理解整个系统，更不能替你承担判断。

在平台规则内优化用户体验

微信订阅消息有一个绕不开的限制：一次性订阅授权通常只能发送有限几条消息，小程序不能在用户同意一次后就无限发送提醒。

最初UP主想让用户每次点击「开始」和「已起身」时都显示确认授权，逻辑很清楚，但本来只需点一次的动作变成了两步。后来他改成：第一次点击「开始」时申请授权，用户可以在微信授权框里勾选「默认允许」，之后再操作时，如果已默认允许，微信会自动完成，无需反复操作。

「我不能绕过微信的规则，但是可以尽量把规则解释清楚，并且降低用户操作时候的负担。」

这里要解决的已经不再是代码问题，而是如何让用户理解发生了什么，同时又不被一堆技术名词困扰——这是产品设计中最考验同理心的部分。

资源约束下的取舍艺术

上线测试暴露出多设备同步问题：手机、电脑、平板同时打开时，一个设备点「已起身」，其他设备不会马上同步。为了同步，他一度让前端每5秒向云端拉取一次状态，效果虽好，代价却明显——前端不断读取几乎没变化的数据。

更严重的是后台触发器。旧版每30秒执行一次，即使没人计时也照常空扫描，这样每天固定调用2880次，30天就是86400次。改为每分钟执行一次后，降到每天1440次、30天43200次。按每月20万次调用额度估算，定时触发器的固定占用从43.2%降到了21.6%——而这还没算用户操作产生的调用。

重新权衡后，他决定把核心体验放在前面：小程序打开或操作后，只在15秒内以5秒间隔做短暂同步，最多追加三次请求随后停止，前台弹窗继续在本地运行，另一台设备重新进入前台时再向云端校准。

代价是多设备不再保持秒级同步，后台提醒也可能多等几十秒。但多设备使用本身是低频功能，为它持续消耗大量资源、甚至危及最核心的提醒功能，显然不值得。

「尽善尽美不等于要把所有用户体验都做到最好。在资源有限时，需要先保证核心功能的稳定性。」

四条超越代码的心得

回头看，这个小程序的起点很普通，但做出来后留下的不只是一个提醒工具，还有四条极具参考价值的心得：

1. 想法可以从真实生活需求里自然生长——一个东西先对自己有用，才可能对别人有用；
2. 不必等所有知识都学完——让一条提醒真正送达，比看完十几个小时教程更有效；
3. 即使用AI也要理解整体架构——AI帮你更快执行，但不能替你承担判断；
4. 分清核心与非核心功能——资源有限时，取舍本身就是产品的一部分。

在AI让「写出能运行的代码」变得越来越容易的今天，真正稀缺的能力，正是这位UP主一次次强调的那件事——认清什么是眼下真正重要的。这或许才是AI辅助开发时代，开发者最应该保留和锤炼的核心竞争力。