每日花园开发复盘思维导图

摘要

每日花园 最初只是一个给孩子做日常习惯打卡的小网页，目标很简单：降低家长每天催促的成本，让孩子对“完成任务”有更直接的反馈。

但在持续使用过程中，这个项目逐步从一个“能勾选的页面”，演化成了一套更完整的家庭成长工具。它后来具备了这些能力：

这篇文章不是教程，而是一篇开发复盘。重点不是“代码怎么写”，而是这款软件在产品和工程上是如何一步步成型的，以及哪些决定真正影响了它能不能长期使用。

一、项目背景

这个项目不是从完整需求文档开始的，而是从一个非常具体的家庭场景开始的：

这个背景直接决定了产品的第一版方向：不做账号系统、不依赖服务器、不要求下载 App，先解决“今天能不能顺利打卡”这个核心问题。

二、产品定位

如果从产品类型来看，每日花园 其实不是传统意义上的“习惯打卡 App”，更接近一个面向家庭内部使用的轻量成长系统。

它最终要同时满足三类需求：孩子的任务执行、家长的长期管理，以及工具本身在手机端低负担、可离线、可长期维护的现实约束。

它到底是一个页面，还是一个能长期被家庭使用的产品？后面所有功能和重构，基本都围绕这个问题展开。

三、技术路线：为什么一开始选择本地 Web App

这个项目的第一个关键决策，不是视觉，也不是交互，而是技术路线。最终选择本地 Web App，原因非常务实：

从复盘角度看，这是正确的起点。它让产品先跑起来，再逐渐长出工程化能力。

四、第一阶段：先把打卡闭环跑通

第一阶段的目标非常单纯：让用户能把一天的任务打完，并感受到反馈。

这一阶段的核心闭环包括：

从产品层面看，这一阶段解决的是任务驱动。从工程层面看，这一阶段优先交付，不优先抽象。

五、第二阶段：从“能跑”到“能继续迭代”

随着模块增多，第一版写法开始暴露问题，最典型的是多孩子面板的重复结构。

后面做了几件关键的工程改进：

这一步没有改变产品的大形态，但明显降低了后续改动的成本和回归风险。

六、第三阶段：把存储和备份做成产品能力

一个家庭工具能不能长期用，取决于两个问题：数据会不会丢，改过的内容能不能回来。

所以项目后面逐步补上了：

这一步之后，软件才真正具备了长期使用的底座。

七、第四阶段：从“今天完成了吗”走向“历史如何被理解”

真正把它往成长工具方向推了一步的，是后面加入的历史理解能力。

这里面最关键的是每日快照 dailySnapshots。有了它，系统才开始真正“记住每一天”，热力图、月报和昨日回顾这些功能才站得住。

热力图这块后来也做了几轮重构：

同时，为了满足“第二天就知道昨天漏了什么”的真实需求，首页任务区顶部又增加了“昨日小回顾”卡片，把历史能力直接拉回到今天的行动里。

八、第五阶段：移动端兼容性，才是项目真正变复杂的地方

这个项目只要进入真实手机使用，就一定会面对移动端兼容，尤其是老设备。iPhone 7 Plus 是最典型的验证对象。

这里踩过几类很典型的坑：

最后形成的思路非常务实：统一正式入口、保留旧入口兼容、收紧缓存策略、素材播放失败时明确降级，不强求所有设备体验完全一致。

九、几个关键产品判断

十、如果重新做一次，我会更早做什么

十一、结论

回头看，这个项目并不是靠一次大设计完成的，而是靠一系列很小、但都很贴近真实使用的判断堆出来的。

它的发展路径大致可以概括为：

  1. 先解决今天能不能打卡
  2. 再解决多个孩子能不能长期共用
  3. 再解决数据能不能留下来
  4. 再解决历史能不能被看懂
  5. 最后解决它在真实手机环境里能不能稳定存在
一个家庭工具不是靠功能堆砌变成熟的，而是靠任务、数据、入口、兼容性这几条关键链路一点点变稳。
返回记录页