事情是这样的：今年春天我买了一盆多肉，放在显示器旁边，取名“玉露”（因为它是一盆玉露）。养了两周，我发现自己总是忘记浇水——毕竟写起代码来，连饭都会忘，何况一盆植物。
作为一个程序员，遇到“我记不住”的问题，第一反应当然是：写个程序提醒我。
需求分析与“上线”
技术选型零点五秒完成：一个 cron 定时任务 + 企业微信机器人推送。核心逻辑优雅得让我自己都感动：
# 每天 09:00 检查是否该浇水
0 9 * * * /home/tom/check_and_remind.sh
# check_and_remind.sh：距上次浇水 >= 3 天就推送提醒上线第一天，机器人准时在九点发消息：“该给玉露浇水啦。” 我心满意足地浇了水，并把浇水时间记进了脚本的数据文件。一切都很完美，直到第三周。
事故报告
第三周的某一天，我发现玉露的叶子开始发黄变透明。上网一查，多肉浇死的比旱死的多得多——玉露这种十二卷属，两周浇一次都嫌勤，我三天一次，还次次浇透。
我的提醒脚本运行得毫无 bug，推送准时得像闹钟。它唯一的问题是：需求本身是错的。
复盘（职业病发作）
- 需求调研缺失：我没有查过玉露到底几天浇一次水，直接拍脑袋定了个“3 天”。这和产品经理拍脑袋定需求有什么区别？没有区别，甚至更糟——这次我自己就是产品经理；
- 缺少灰度：正确做法是先两周浇一次，观察状态，再调整参数；
- 没有监控反馈闭环：植物的状态就是最真实的监控指标，而我的系统从不看监控，只管执行；
- 教训：代码可以优化，参数可以调整，但方向错了，跑得越快死得越快。
现在那盆玉露的位置换成了一盆假绿萝。脚本我还留着，改成了两周提醒一次——虽然已经没有植物需要它提醒了，但作为事故纪念，它值得一个终身运行。