RequestHunt 首页仍未更新：8 条育儿记录需求，都在补「谁、对谁、几点、给谁看」
RequestHunt 首页继续停更，本期从站内 Sleep apps 主题页取出 8 条出自开源自托管育儿记录工具 Baby Buddy 的请求，按「谁记的、对谁、几点、给谁看」四层拆开，说明记录型产品最容易在哪一处裂，并按改动层次给出排期判断。
首页那 30 条没有变化。最新一条的日期停在 2026-06-23，站内 Trending 页仍写着最近 7 天没有新增。1
这一期的入口换成站内按品类汇总的主题页 Sleep apps。这一页列了 10 条需求，其中 8 条来自同一个项目：开源自托管的育儿记录工具 Baby Buddy。2
这个项目 2017 年 10 月建库，现在 2,926 颗星、147 个未关的 issue，BSD-2 许可，跑在 Django 上。3
它记的东西很具体：睡眠、喂奶、换尿布、体温、体重、趴着玩的时间。用的人通常是一家人，外加偶尔来帮忙的保姆或祖父母。
这 8 条需求都在同一个方向上：这个工具原本记的是「做了什么、多少」，用起来之后才发现还缺「谁、对谁、几点、给谁看」。
一、这一簇需求长什么样
8 条里 4 条来自同一位用户 skjdghsdjgsdj，2 条来自 OneCreek，1 条来自 steynru，1 条由维护者 cdubz 自己提出。
最后那条（#914）的正文是维护者从讨论区搬过来的，原样保留了提问者 TaddyJ 的描述。署名不同，份量也不同：使用者写的是「我家现在这样用不了」，维护者写的是「这是我打算怎么做」。
下表每一行的 GitHub 数字是今天读到的评论数与反应数，提出日期取自 issue。页面分另算，来自主题页那次抓取。
| 需求 | 页面分 | 评论 / 反应 | 提出 | 缺的那一处 |
|---|---|---|---|---|
| 体重只记到日期，同一天称三次分不清 | 1 | 1 / 1 | 2024-08-21 | 时刻 4 |
| 选错纸尿裤颜色，改的时候取消不掉 | 0 | 7 / 0 | 2024-08-29 | 空值 5 |
| 站点设置没有接口，外接设备读不到小睡时段 | 0 | 1 / 0 | 2024-09-20 | 对外 6 |
| 两周的睡眠记录要交出去，只能自己画 | 0 | 3 / 0 | 2024-09-27 | 对外 7 |
| 只有一个孩子，录入时仍要选孩子 | 0 | 1 / 0 | 2024-10-23 | 主体 8 |
| 记录里查不到是谁记的 | 1 | 5 / 1 | 2024-11-07 | 归属 9 |
| 计时器起了名字，结束那一屏不显示 | 0 | 1 / 0 | 2024-11-27 | 片段 10 |
| 「parent fed」盖不住保姆与日托 | 2 | 9 / 2 | 2025-01-06 | 称谓 11 |
二、谁记的
skjdghsdjgsdj 翻了数据库表结构，把
core_feeding 的建表语句贴了出来。字段有开始时间、结束时间、时长、类型、方式、奶量、孩子 id 和备注。9里面没有一处写「谁记的」。认证用户只用来登录和判权限，记完的那一行跟记它的人没有关联。
他的实例上有三个账号：他自己、伴侣、家里的照护者。他想知道哪一次换尿布是自己做的。
维护者 cdubz 当天回复，说这件事可以直接做，先从关联用户开始。接着两个人讨论到一个更麻烦的点：计时器由 A 开始、B 结束，这一条算谁的。
讨论里还出现了另一种方案：用 django-auditlog 把增删改全记下来，比只存一个用户 id 更完整。四天后 cdubz 开了 PR #902，标题是「feat: audit log」，写明 fix #900，还挂了一个演示实例。12
到今天这个 PR 仍是 open 状态，没有合并。从开出到现在快两年。
同一处缺口，官方文档写得更直白。照护者（caregiver）这个角色能看能加能改，却不能删任何条目；文档紧接着说，Baby Buddy 不记录一条条目由哪个用户创建，所以照护者记的条目事后没法和其他人区分。13
产品机会（分析假设）：把记录人做成条目上的常驻字段，显示在时间轴和条目角标上，交接班时能按人筛出「这两小时是谁在记」。
落地限制在迁移。老数据没有这一列，只能留空；一条计时器跨了两个人时，创建人与结束人塞不进一个字段；权限还要跟着改，因为照护者本来就能编辑别人记的条目。
第二条讲的是同一个位置的另一种写法。#941 提出，喂食方式里的「parent fed」在亲戚、日托老师、保姆喂的时候都不准。11
提出的人自己给了退路：API 里继续保留 parent，别让老数据读不出来。
cdubz 回得干脆，说他本来就想统一用 caregiver，大概是这里漏了。后面有人建议改翻译文件就够，有人担心内部字段也要跟着改。
这条的走向提供了一个对照。2026 年 9 月 17 日，一位贡献者贴了一份修复总结，判定这个 issue「有歧义、需要产品决策」，于是没有动代码。
9 月 21 日，贡献者 tharunsridhar 认领，方案是只改显示文案：界面写「Caregiver fed」，数据库和 API 仍存
parent fed，不动序列化器和过滤参数。cdubz 同意，同时提到他们刚上线了一个用「Caregiver」一词的新功能。同一个概念，一个改成了字段与审计（#900），一个改成了界面上的两个字（#941）。后者推动了，前者还挂着。
三、记的是谁
#889 的场景很日常：多数人只用它记一个孩子，另一个孩子可能已经大到不需要记了。既然如此，录入表单里那个「孩子」选择栏就是白占一次点击。8
提出者补了一句关键的：界面可以隐藏，API 仍应强制要求 child id，别让接口跟着松。
cdubz 回了一个「有道理」。
官方文档里能读到这处设计的另一面：照护者能访问实例上的每一个孩子，没有按孩子授权这回事。13
产品机会（分析假设）：把「孩子」从必填选择改成默认值加例外，只有一个孩子时不出这一栏，多个孩子时照旧显式选。
落地限制在接口的校验假设。界面靠默认值少一次点击，接口仍要显式传 id，两边得分开表达；将来做批量导入，也不能因为界面简化就放过缺失的 child id。
四、几点、哪一段
#863 的用法是把称重跟着喂奶走。OneCreek 一天量三次以上，早上一次，喂奶前后各一次，但工具只让他存日期。4
他提过用标签凑，随后问：为什么不干脆在日期后面加一个时间。
cdubz 回「欢迎 PR」，并承认一天称多次在有些情况下确实合理。
#914 的场景更急。TaddyJ 和他妻子都喂孩子：一个人称好奶、起一个计时器、把奶量写进计时器名字，然后把孩子交出去；另一个收尾时打开结束那一屏，名字没了。10
夜里喂奶时，两人的选择只剩回去再看一眼，或者凭记忆填。
这条已经关掉了，维护者自己接手，回了一张改法截图。
#870 讲的是选错的字段能不能退回去。用户选了一个纸尿裤的颜色提交，再编辑时颜色取消不掉，只能删掉整条重录。5
有位贡献者提议把按钮组换成默认下拉框，改动很小。cdubz 没同意，他写，主录入区要简单到「凌晨两点喂奶的家长脑子」都能用，下拉框两次点击，按钮一次就到位。
后来的讨论绕开了这个取舍。一位用户 2024 年 11 月说问题仍在，一位贡献者改在通用按钮组件上做取消逻辑，2026 年 4 月又有人提第三条路：没选「固体」时干脆不出现颜色选项。
产品机会（分析假设）：让可选项能再点一次取消，或者让颜色只在选了「固体」之后出现。两种做法都不增加必填步骤。
落地限制落在录入那一刻的点击成本上。主录入区每多一次交互，都是在最累的时候收费；改通用组件又会波及所有表单，测试面比功能本身大。
五、记给谁看
#881 的用户从孩子出生起就用这个工具记录。有人要求他们交一份两周的睡眠记录，需要按天排的时间轴：睡眠、吃、喝、哭。7
他附了一份儿童医院的记录表格作参照，问能不能长这样。
cdubz 回，应用里没有这个视图，用原始数据加标签能凑出来；他反过来问能不能把那份表格译成英文。
另一位用户没等，自己用电子墨水屏做了个仪表盘：蓝橙是换尿布，红是喂奶，绿是睡眠。7
产品机会（分析假设）：把时间轴做成可导出的报告，格式按接收方来定，导出后能直接交出去。
落地限制在格式的碎片化。每家机构都有自己的表格，参照的那份是四小时记录。哭这件事本来就没被记录，报告里只能留白，或者事先约定不填。
#878 来自一个做硬件的人。他给自己做了一个带蜂鸣器的外接设备，希望孩子小睡时扬声器静音，于是想让 Baby Buddy 通过接口告诉他，什么时段算小睡。6
他的理由很实在：时段只该在一个地方定义。他说只读就够，写入接口也许将来才需要。
cdubz 回「这个用例有意思」，说应该做得到，欢迎 PR。
产品机会（分析假设）：把站点设置和时段定义暴露成只读接口，让外设、仪表盘、报表用同一套时间口径。
落地限制在设置的所有权。站点设置是实例级的，多个家庭共用一个部署时得先分清谁能改；一旦开出写接口，配置冲突就要有说法。
六、真正卡住的是录入那一屏
把这 8 条并排看，会发现它们要的东西方向相反。
加时间、加记录人、加称谓、加导出，都是往上添；#870 的讨论和 #889 的诉求，都是往下减。
维护者在 #870 里把这条边界说清楚了：主录入区要简单到半睡半醒也能点。
所以能先动的，多半是不增加录入负担的那一类：把已经存在的数据显示出来（#914 的计时器名字）、把用不上的选项藏起来（#889 的孩子选择栏）、允许事后修正（#870 的取消选中）。
要动数据结构的，就得吃下迁移和回填带来的工期，#900 那个挂了两年的 PR 是现成的工期参照。
七、这 8 条怎么排
第一类，今天能改。三条：#941 只改显示文案、库里继续存旧值；#914 把计时器名字带到结束屏；#889 在孩子只有一个时不显示选择栏。它们的共同点是读已有数据，或者减少一次点击。
第一版交付什么：一条文案、一处显示、一处条件渲染。看什么信号：同类 issue 有没有新的补充，和改完之后录入时长有没有变化。
第二类，要动数据结构。#900 给每条记录加记录人，#863 把体重的时间粒度从日期改到分钟。两条都要加列、回填、改接口 schema，还要处理跨两个人的计时器。
这两条适合放进版本规划，并且先定一个最小的字段集：谁是创建人、谁结束的、时间精确到哪一位。
第三类，动对外接口与导出。#878 的只读设置接口、#881 的可导出时间轴，都依赖外部读者（设备、机构、医生）的格式。先从只读做起，写接口留到有第二个使用方的时候。
8 条合起来是一件事：在这个工具里，记录本身已经做得很细；把它变成两个照护者、一个孩子、半个月的交接凭据，才刚刚开始。
口径与边界
页面分是 RequestHunt 抓取那一刻的记录，8 条落在 0 到 2 分之间。GitHub 的评论数与反应数是今天读到的，评论 1 到 9 条，反应 0 到 2 个。两组数字量级不同，各记各的。2
8 条全部来自同一个项目，因此下面这些判断只在这个项目里被验证过。它显示的是一处缺口：产品内部对「记录给谁用」的共识，已经走到了实现前面。
这一页另外 2 条是 KeepingYouAwake 的菜单栏应用请求，与育儿记录无关，本期没有采用。
首页 30 条与 9 月 27 日以来的历次快照逐条一致，最新一条停在 2026-06-23。本期因此改用主题页取材。1
References
- 1RequestHunt 首页
requesthunt.com
- 2RequestHunt：Sleep apps 主题页
requesthunt.com
- 3babybuddy/babybuddy：育儿记录工具
github.com
- 4issue #863
github.com
- 5issue #870
github.com
- 6issue #878
github.com
- 7issue #881
github.com
- 8issue #889
github.com
- 9issue #900
github.com
- 10issue #914
github.com
- 11issue #941
github.com
- 12PR #902：feat: audit log
github.com
- 13Baby Buddy 文档：用户管理
docs.baby-buddy.net
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.