夜雨聆风
女儿满月了,我在给她做的育儿APP里记下了第800条记录
我也在给她做的育儿记录 App 里，记下了第一条记录：
不知不觉，一个月过去了。
女儿满月了。吃的多了，体重长了，老父亲的生物钟，也彻底乱了…
我们这个小 App 里，也多出了将近 800 条记录：
当然，除了这些正常的记录，也还有：
“喷射状吐了3大口奶。”
“刚躺10分钟，黑豆眼又睁了。”
“凌晨3点，胀气，一直哼唧没睡。”
…
就在这些普通又不普通的记录里，一个新的生命旺盛生长起来，我们也顺带完成了父母身份的切换。
在这个过程中，我既是参与者，也是记录者，还是这个记录工具的产品经理。这种感觉还是挺神奇的。
因此，借着女儿满月这个小里程碑，也记录下build这个小app的一些感悟。
缘起
这个App的起点，是还在孕期中的某一天。
老婆给我看了一个小红书帖子，大概是讲“用 Kimi 做了一个育儿嫂 agent”。她说，你最近天天学习琢磨AI，能不能也给咱们女儿做一个出来。
现在回头看，那个帖子里应该是个one-shot搓出来的demo，但还是给了我很大启发。
那段时间，我处于刚开始学习AI上手各种agent的阶段，但整体上还是输入为主、没太输出。
可能也只有“给自己女儿做一个 App”能让人有动力下班后坐到电脑前继续肝了… 于是开始筹备。
思考的第一个问题：我们用这个app到底做什么？
请教了身边的朋友，学习了各种经验，也讨论了几轮后，我们觉得，第一版还是应该做得非常克制：
就做记录。
具体到新生儿，就是吃、睡、拉。
因为最重要和高频的也就是这三件事了。
事实证明我们在养育过程中最常关注的也的确就是：奶量长到多少了？睡眠咋样？正不正常？
这些信息如果只靠脑子记，可能很快就会乱掉。
但也还有第二个问题：真的需要自己做一个吗？
我去下载了一圈市面上已有的各种育儿记录 App。
国内、国外的，包括 Huckleberry 这类比较成熟的产品，都试了试。
如果有能完全满足我们需求的现成app，也许没必要非得做？
但试了一圈后，反而更确定要做了。
一些app，要么广告太多，要么界面复杂。当然也有做得不错的，但非付费版几乎啥也做不了，也不太符合我们想要用它的方式。
更重要的原因是，我发现我和这些APP缺乏“连接”。
记录本身是一件枯燥的事。
因此我更希望这个我们接下来每天会打开的app，能有一点专属感，有一些温度，让记录不那么枯燥。
另外，新生儿照护也很少是一个人的事。
可能夜班是我，白班是家人，未来还要交接给育儿嫂。不同人在接手宝宝的时候，如何能快速“交接”？
这些都是我觉得我们的需求还没解决好的地方。
基于此，我们把宝葫芦的第一版产品定位收敛为：
做一个一家人能共同使用的新生儿记录App。
围绕吃睡拉，把记录做好，数据做好，家人协作做好。其他暂时不管。
开做之后，发现它不是一个可以one-shot的APP
从功能上看，宝葫芦第一版设定并不复杂。主要就是：
结构化的记录宝宝的日常，支持多人一起编辑，有基础的数据分析功能。
但真正开做后，我发现它和code一些其他小工具不太一样。
最大区别是：我对它的视觉品质是有要求的。
我希望它的页面、色系、宝宝形象，都能传递一点温暖可爱的感觉，像一个小绘本。
这就让它变成了一个 taste-heavy 的项目。
而这类项目，很难用零帧起手出demo的方式来做。
这算是我在这个项目里踩到的第一个坑 ——
“该长什么样”这件事，没有先被定义清楚。
而从定义一个app应该长什么样，到把这个“样子”完整落到code，真的比我想的难很多…（至少目前的agent都还做的不好）
需要给不同流程找到“对的平台”，甚至更重要的是找到“对的流程”本身。
所以，这个项目也让我重新认识了传统产品开发流程的价值。
一个经典链条里，要有产品经理把用户怎么用给抽象好，设计师把设计系统定义清楚（而不只是几张视觉稿），最后才是工程师再把这些东西落到可运行的代码里。
而因为早期前两个“角色”的缺位，导致我在打磨设计和在像素级code这个设计的过程，耗费了巨量精力和token…
当然，作为一名个人builder，也不需要把这套流程做得太重。
但如果做的是一个有审美要求的项目，那么引入一些产品经理和设计师的工具、思维、流程，还是绕不过开的。
不然agent干活越快，返工也可能越快。
这个不是本篇的重点。不过这个痛苦的过程也让我对跨agent工作模式有了很多思考，以后可以单独写一篇。
用起来后，手感是最大的Context
第一版上线前我其实挺满意的，甚至想过一步到位做成正式APP。
但宝宝出生以及每天真的用起来后，才发现来自“手感”的反馈更重要。
手感，不是用户访谈，也不是数据分析得到的东西，只来自于作为产品的第一user，在每天使用中形成的感觉。
比如，最开始我参考一些育儿App，做了一个用来指导“哄睡窗口”的 sweetspot 功能。
听着挺合理。
但用起来发现，前一两个月宝宝大部分时间都在睡觉，根本没啥“窗口”。可能对更大月龄宝宝才有意义。
再比如，最开始我设定的睡眠记录逻辑，是手动点击开始和结束，然后统计每天的睡眠时长。
但新生儿的睡眠状态有时候很难清晰划分。
夜里可能闭着眼把奶喝完了，白天可能刚放下 10 分钟又醒了，算醒还是睡？
后来我发现相比睡觉本身，我们更关注照护cycle：也就是这一轮奶-拍嗝-尿布-入睡大概多久，之后又睡了多久。
这些东西，产品上线前一般很难想清楚。
它们往往是在真实使用里一点点浮现出来的。
这也是为什么我越来越觉得，AI时代给自己build的是效率最高的（工作场景也适用）。
因为手感是最大的上下文。
手感几乎无法外包，手感很多时候就是taste。
什么地方不对，什么地方多余，用着用着就有感觉了。
如果你恰好又是它的builder，这些手感又可以很快落到下一版代码里。
其他任何反馈链条，效率都低太多。
记到800条后，新需求出现了
第一版宝葫芦的核心，到现在依然是记录。
但当记录逐渐积累到几百条之后，我发现很难再去翻之前的记录了。
也开始经常会有一些很具体的问题：
15 天月龄宝宝，最近奶量xx，上一顿喂到90ml了还一直找奶，闹着不睡，怎么办？
这类问题丢给general的AI，通常会得到一个general的回答。
但当我让agent直接去取宝葫芦数据库最近7天的记录，先分析再说话之后：
我发现答案变得有用了。agent还捕捉到了我们都没看到的数据pattern。
这就有了AI能力的用武之地。
也成为了我正在给下一版宝葫芦做的一个小agent runtime的主要灵感来源。
并没有一上来就做个育儿agent，还是因为记录这件事先成立了，这些记录慢慢变成了高价值的“context”，所以长出了新的需求。
这种需求也让人做起来信心更足。
边带娃边迭代
目前这个小应用还很早期，还跑在H5上。
不过，新的一版宝葫芦也已经在开发中了。
视觉、功能模块、AI能力上，做了不少升级。
也许再养两个月娃，我的需求和判断又会变化。
宝宝在长大，照护方式在变，家庭协作方式在变，产品手感也在变。
但这也正是我觉得它值得记录的原因。
这是一个从真实生活里长出来的小工具，在一个小家庭内被高频使用，解决我们自己的痛点。
它的迭代本身，也是我们作为父母的成长过程。
有空时会再分享后面的迭代历程。
