最近，我总算下定决心直面体重，买了一台小米体重秤。
米家的产品很擅长把一次测量讲得十分完整。体重、体脂、肌肉率，该有的都有，单看任何一天都像拿到了一份内容翔实的体检报告。可我想比较两天的肌肉率时，事情立刻变得麻烦起来。页面一次只肯展示一天，我只好在两个日期之间反复切换，看一眼这天，再点回那天，努力记住小数点后面的数字。
这些数字各自都很完整，放到时间里却不肯好好说话。
来回切了几轮，我忽然想起豆泡 1.0。那时候每天吃了多少、消耗了多少，至少还能画成一条折线。线长得未必好看，变化倒是一目了然。
那一刻我才承认，一张朴素的折线图，有时比一页华丽的身体报告更能安慰人。
豆泡 1.0 留下的遗产
豆泡 2.0 之所以叫 2.0，原因非常朴素。前面确实有过一个 1.0。
把它称作系统，多少有点抬举。豆泡 1.0 由一个 Hermes 和一张飞书多维表格组成，负责记录两个人的饮食、运动和身体数据。我们平时在飞书里给机器人发消息，机器人把内容写进表格，再从表格里做一点统计。
它笨得很具体。
豆泡经常分不清说话的人，两个人的数据偶尔会被它记混。运动结束以后也没有自动同步，我得先把手表上的记录截一张图，再逐项解释练了什么、练了多久、消耗多少。记录多起来以后，两个人的数据又挤在同一张表里，阅读难度随着行数稳步上升。
我们还是高高兴兴地用了一个月。
每天在飞书里说几句话，看着表格里多出一行，过几天再打开图表瞧瞧，多少有一点养电子盆栽的成就感。那张表记录的不只是热量。它还证明了一件很容易被忽略的事，我们昨天确实做过，今天也没有完全忘记。
后来我接触了薄荷健康。
它的完成度高得多。手表里的运动可以自动同步，拍一张食物照片，营养和热量很快就能识别出来。第一次用时只觉得牛而逼之，豆泡 1.0 那套截图、解释、再检查的流程，顿时显得很有手工业精神。
薄荷健康的功能很多，会员要付钱，社区和广告也相当热闹。我只想安静地记一顿饭，它却很希望我顺便逛点别的。功能做得完整，和一个人愿不愿意每天打开，是两件经常各走各路的事。
我体验了一个月会员，到期后没有续费。就在这段时间里，另一个人留在豆泡 1.0 里孤军奋战，原本由两个人共同维持的习惯就这样断开了。她很快停下，我也没在薄荷健康里坚持多久。
两个软件都还在，我们双双停止记录。
小米体重秤让我重新想起这段往事。我想要的工具其实已经很清楚了。记录要足够顺手，能自动同步的内容就别让人手抄。两个人的数据得各归其位，积累一阵以后，还要能直接看到前后的变化。
于是，复活吧，我的豆泡。
开源造福全人类
决定复活豆泡以后，我先诚实地评估了一下自己的代码能力。
约等于零。
好在代码能力已经不再单独决定一个人能做什么。GLM 5.2 和 KIMI 3 这批模型出来以后，我与代码之间的距离缩短了不少。我依然不会凭空写出一个健康管理系统，至少可以把需求讲清楚，让模型替我找项目、读代码、改配置，出错以后再接着问。
简单来说，AI 的上限暂时就是这个项目的上限。
这两年我还学会了一件事。前人已经造好的轮子，值得先拿来转两圈。于是我把需求交给模型，让它去 GitHub 上找有没有现成的开源项目。
还真有一个，SparkyFitness。
感谢 SparkyFitness 开源。它允许用户自己托管，iOS 端也能读取苹果健康里的数据。源代码摆在那里，后面想改点东西，至少有下手的地方。对于一位代码能力约等于零、手下却拥有多名 AI 员工的老板来说，这已经相当接近理想答案。
SparkyFitness 很看重隐私。按照原本的部署思路，我可以用 Tailscale 组一个虚拟局域网，让手机和服务器只在这个网络里通信。
自己用很优雅，多用户就开始为难。每个使用者都要先装 Tailscale，再加入我的虚拟局域网。人数继续增加还会碰到免费额度。一个人只是想记一下晚饭吃了什么，开场却要先学习虚拟组网，技术上的优雅就这样变成了用户手里的麻烦。
赶巧，前段时间 Hermes 和 OpenClaw 很火，我趁火山云打折买过一台服务器。服务器既然已经在交钱，索性把 SparkyFitness 放到公网上，让大家直接访问。
公网访问又带来了 HTTPS。手机要安全地把数据同步到服务器，最省事的办法是准备一个域名和证书。
更巧的是，我在 Gemini 3 最火的时候跟风做过一个个人博客。文章至今一篇没写，域名倒是在腾讯云老老实实备了案。
废弃博客终于还上了一点债。
域名在腾讯云，服务部署在火山云，我这套配置最后没能顺利走通 443 标准端口，只好退到 8443。有人可能会问，既然用了非标准端口，域名还有什么意义。
当然是好记啊。
部署工作基本交给了头号员工 KIMI。它哼哧哼哧装服务、配环境、接域名，偶尔抛给我一个需要真人处理的步骤。折腾一阵以后，SparkyFitness 总算在服务器上跑了起来。
我依旧没有学会写代码。改变比较明显的，是看到报错以后不必立刻宣布项目结束了。
把 SparkyFitness 养成豆泡
SparkyFitness 跑起来以后，离豆泡还差一点风味。
先得有个自己的 Logo。这件事不难，找豆泡的祖宗豆包生成一个就行。
页面也得换成中文。诞生于伟大城墙内的豆泡，打开以后满眼英文，多少有些数典忘祖。于是首席翻译官 KIMI 上岗，把网页里的主要内容翻了一遍。这个需求的技术含量可能不高，对我却十分必要，毕竟我看不懂。
外表改完以后，豆泡 1.0 那套看数据的办法也得接回来。
我最留恋豆泡 1.0 的地方，是 AI 能看到一段连续的数据。今天多吃一点，明天少动一点，单独看都算小事；把日子连起来，它才有机会告诉我最近究竟发生了什么。此时的 SparkyFitness 已经很会记录，还需要一个能读懂这些记录的角色。
巧巧巧巧巧合的是，SparkyFitness 已经预留了 AI 接口。这年头哪个软件还不给 AI 留个座位。
我给它安排了两个模型。豆包 2.0 Lite 速度快，也能读图，负责识别照片里的食材。GLM 5.2 上下文够长，脑子也更好使，负责读取一段时间的数据，生成汇总报告。
AI 有了，入口还要回到飞书。
记录工具的入口本身就是功能的一部分。一件事偶尔做一次，多点两下无伤大雅；每天都要做，多出来的每一步迟早会变成放弃的理由。飞书本来就在电脑和手机上开着，我发一句“喝了 500 毫升水”，远比打开专门的应用、找到入口、填写数字来得自然。
于是我大手一挥，手指在键盘上敲出残影，最后打出几个大字。
帮我绑一个飞书机器人！
OpenClaw 前段时间的爆火也帮了忙。现在许多 Agent 平台都支持扫码绑定飞书，整套流程已经相当成熟。KIMI 一把抓住，顷刻炼化，过一会儿让我扫个码，机器人便接好了。
它还读懂了我的多用户需求，顺手加上用户绑定和身份识别。不同的人第一次使用时先完成绑定，后面的数据便各归各处，豆泡 1.0 最头疼的记混问题也一起解决了。
我们国模真是站起来了。
一个工具该在哪里停手
到了测试环节，我先在飞书里记了一杯水。
水是生命之源，一天喝得够不够非常重要，所以大家一定要加油喝水。更实际的意义在于，这条记录只花了我一句话。机器人确认以后，数据便进了数据库。
接着试图片。
我发了一张食物照片，豆泡背后的豆包很快认出了里面的食材，并把结果写进数据库。
结果相当 amazing。食材识别得挺全，热量准不准暂时不敢打包票。这一轮测试只能证明整条流程已经跑通，营养估算还得交给后续使用慢慢检验。
后来有用户反馈，拍照记录对食物分量的判断不太准。我又让 KIMI 给飞书卡片加了编辑功能。一盘菜只吃了一半，或者模型认错了分量，用户可以直接改，不必为了维护 AI 的自尊硬吃下那几百大卡。
SparkyFitness 还能把营养数据反向写入苹果健康。现阶段，这项功能最大的作用可能只是展示更好看。它也给数据留了一份手机里的备份，哪天服务器不再运行，过去的记录不至于跟着一起消失。
最后剩下前端。现成的 iOS 页面以英文为主，自己分发修改后的应用又绕不开苹果开发者会员。每年 99 美元的门票不算便宜，免费账户侧载所用的描述文件又只有七天有效期，我最后选择做一个网页看板。
我从 Open Design 找来一套仪表盘模板，再让 KIMI 根据它对项目的理解往里填。经过一番 Vibe，一个能看的网页就出来了。
看板只保留了手动添加饮食的入口。日常输入仍然交给飞书机器人和 SparkyFitness，网页安静地负责展示，数据会实时更新。这里没有社区，也没有广告，更不会隔三岔五冒出一个红点提醒我参与讨论。
够用，好使。
豆泡 2.0 做到这里，我一度还想继续往里加东西。既然已经接了 AI，顺手生成食谱似乎很合理，健身计划也可以安排，过几天甚至还能让它主动催我。
我最后停了手。工具变得臃肿，往往不需要什么错误决定。每次加上去的功能单看都有用，合在一起，最初那件小事就会被挤到越来越远的地方。
豆泡每天要做的事仍然很小。接住一句话，或者认一张照片，手表里的运动则自己同步回来。等记录积累一阵，再把前后的变化好好摆在我面前。
至于更宏大的健康管理，先等我把今天的水喝够再说。
评论