我从来没写过小程序，用 WorkBuddy 把它做上线了

家人长辈的生日、结婚纪念日，还有一堆考试和出发日期，我脑子从来存不住。

这些东西以前散在手机日历、备忘录和几个 App 里。每次想看一眼“最近还有什么安排”，都得挨个翻一遍。

我也找过现成的小程序，功能都比我需要的多，还带着签到、积分和广告。

干脆自己写一个。麻烦在于，我从来没写过小程序。

现在，时刻小助理已经在线上跑了。整个过程我的主力工具是 WorkBuddy，下面按四步说清楚我到底做了什么。

01 先画原型，把“我想做个啥”讲明白

我做的第一件事不是建项目，是想用途。

想完之后砍到四件事：

• 纪念日、生日、倒数日记下来，自动算还有多少天
• 支持农历，记长辈生日不用每年翻日历
• 能设置提前几天、几点提醒
• 顺带做经期记录

然后我用 Ardot 画了 21 屏原型，把首页、添加、详情、空状态、未登录状态都摆出来，每屏正下方标好点哪个元素跳哪一页。

早期原型里的时刻首页

很多人觉得个人项目不用画原型，我不同意。AI 写代码非常快，快到你自己还没想清楚就让它开工，它会还你一堆能跑但完全不是你要的东西。 原型的作用，是让你在动手之前先想明白，把“我要什么”变成能指着说“就这个”的东西。

02 定框架：访问量就那点，别给自己加戏

我对这个项目的用户量预期非常清楚：自己和家人朋友用，访问量注定很小。上线之后也确实如此。

想明白这一点，技术选型就没什么可纠结的了。后端就一个服务，不做微服务、不上集群；一台服务器跑一个容器就够；登录和定时提醒都按单机最省事的方案写，不为了“以后可能要扩容”提前上分布式那套；数据库七张表，不分库分表。技术上也没挑新的，都是最保守的那套：后端用 Java，小程序端用原生框架配 TypeScript。

凡是用不上、只是为了“以后可能”提前引入的东西，一律不加。 如果一开始就按“高并发”来设计，我会得到一套消息队列、缓存集群、分库分表齐备的架构，然后为这套东西付出一到两倍的维护成本，换来的扩展性自己根本用不上。小项目的最优解是能跑、能改、自己看得懂，不是能扛百万并发。

最后落地的规模：后端 200 个 Java 文件、一万两千多行，小程序端业务代码 137 个文件、八千八百多行，一共 16 个页面——主包 4 个，其余分到 3 个分包里。

03 照着原型写代码

这一步的关键不是“让 AI 写得多快”，而是先给 AI 立规矩。

我在项目里放了几个文件：前后端各一份 AGENTS.md 写死编码约束，一份设计文档记录产品规则和表结构，一份项目上下文写清当前代码到底做到哪一步、哪些只是设计目标。

原因很简单：AI 每次对话都是从零开始，这些文件是它唯一的记忆。 规矩写清楚之后，它写出来的目录结构、命名和分层才是稳定的，不会这次一个写法、下次一个写法。

关于 AI 编程，我的判断是：它让“写代码”变便宜了，但让“验证代码”变得更贵，因为代码产出速度已经远超人工审查速度。

所以我给每一步都配了能自动跑的检查：代码格式、明显错误、能不能构建，都交给工具自己判；重复规则和日期换算这类容易算错的逻辑，单独补了自动化测试，提交后自动跑一遍。在我这儿，检查跑不过就不算做完。

照着原型做出来的时刻首页

添加纪念日的表单页

这样一路推下来是 96 次提交。中间踩得最深的坑全在日期上：农历生日怎么换算成本年的公历、2 月 29 日这种日期怎么办、重复提醒的口径前后端必须一致。这些不难在写代码，难在规则本身要先想清楚。

04 备案、上线

代码写完不等于能用，这一步全是平台规则。

小程序现在要求备案，域名也要 ICP 备案，而且小程序调用线上接口必须是 HTTPS。所以顺序是：先把域名和服务器准备好，再让代码上线，反过来做只会卡在半路。

小程序端的代码走命令行上传，不用手动点开发者工具。

然后就是提交审核。这一步卡人的往往不是代码，而是小程序名称、简介、服务类目、备案备注和实际功能要对得上。我做的账号注销入口、用户协议和隐私说明，都是这一步的必要材料，不是可选项。

审核通过后发布。当前线上版本是 V1.2.1。

备案和审核的后台界面涉及账号信息，这里就不放图了。

最后说点实在的

回头看，真正起作用的是三件事：先想清楚要什么、按实际访问量定架构、写代码之前先立规范。 至于用哪个 AI 工具，反而是最不重要的一环。

这套做法适合有明确小需求、愿意先把文档写清楚、并且能自己跑验证的人。如果需求本身还没想清楚，AI 只会把你的混乱加速一遍。

如果你也一直想做个小工具，但卡在“不会写”，我的建议很具体：先去把原型画出来，21 屏也好 3 屏也好，画到你能对自己说清楚为止。 剩下的部分，比你想的要容易。