小程序家庭协作设计：爸妈记录/长辈查看/医生看数据

小程序家庭协作设计：爸妈记录/长辈查看/医生看数据 ---------------------------

带娃不是一个人的事，是全家+医生的事。一个好的宝宝记录工具，得同时服务三类完全不同诉求的人。这篇讲讲我怎么用「三角色画像」来设计家庭协作，以及它在技术上怎么落地。

一、三个角色，三种完全不同的诉求

设计协作前，我先把「谁会用」拆成三个角色：

角色	是谁	核心诉求	使用频率
记录者	爸妈	快速记、随手记，别打断带娃	高频，每天多次
查看者	长辈	看得懂、看得清，别让我学	中频，想看时看
数据消费者	医生	要准确、要完整，看病时快速调出来	低频，但很关键

这三类人的诉求经常冲突：记录者要「快」，查看者要「简」，医生要「全」。一套界面想同时讨好所有人，结果就是谁都不满意。

三个角色三种诉求

二、设计：一个数据底座，三种视图

解法是底层共享同一份数据，上层给不同角色不同的「视图」。

数据只有一份（这就是为什么第②篇要按「家庭」建模），但呈现方式按角色分：

给记录者：首页大按钮，单手秒记，路径最短。喂奶/睡眠/尿布，点一下就完事。
给查看者：只读的「今日概览」和成长图，字大图清，没有任何需要学习成本的操作。长辈打开就是看，不用记。
给医生：证件夹 + 完整记录。就医时，出生信息、证件号、喂养睡眠史，一翻就出来，帮医生快速判断。

「我的」页把这三件事收在同一处：宝宝卡给查看者看日龄，证件夹给医生，添加宝宝给二宝三宝一起记。

我的页：档案给全家看

一份数据三种看法

三、技术上：家庭模型 + 权限收口

这个协作能成立，全靠两件事打底：

**1. 家庭模型（第②篇讲过）。**所有数据通过 familyId 归属到一个家庭，成员在 memberOpenids 数组里。爸妈、长辈都是成员，共享同一份数据，天然不用「同步」。

**2. 权限收口到云函数（第③篇讲过）。**谁能看哪个家庭的数据，在云函数端校验 openid 是否在该家庭的成员列表里。默认谁都看不了，显式加入才能看——既实现了协作，又守住了隐私。

<span>// 云函数端：校验调用者是否为该家庭成员</span>
<span>async</span> <span>function</span> <span>assertMember</span>(<span>familyId, openid</span>) {
  <span>const</span> fam = <span>await</span> db.<span>collection</span>(<span>'families'</span>).<span>doc</span>(familyId).<span>get</span>()
  <span>if</span> (!fam.<span>data</span>.<span>memberOpenids</span>.<span>includes</span>(openid)) {
    <span>throw</span> <span>new</span> <span>Error</span>(<span>'非家庭成员，无权访问'</span>)
  }
}

四、协作设计的三条心得

**1. 先分角色，再谈功能。**别急着做「共享」功能，先搞清楚有几类人、各自要什么。角色分清了，视图自然就出来了。

**2. 一个数据底座，多种呈现。**协作的本质不是「把数据复制给多个人」，而是「让多个人看同一份数据的不同切面」。数据冗余越少，一致性越好。

**3. 协作和隐私是一体两面。**能让家人方便地看，和能让外人看不了，是同一套权限机制的两个面。把权限收口到一处，两者同时成立。

权限收口在一处

五、这套思路不只适用于带娃

「记录者/查看者/数据消费者」这个三角色模型，其实适用于很多家庭协作场景：记账、健康、日程、相册……凡是「一群人围绕一份共同数据」的产品，都可以套这个框架——先分角色，共享底座，各给视图，权限收口。

带娃只是我的切入点，这套协作设计的思路，你可以拿去用在任何「全家共用」的工具上。

全家都能看娃的今天

如果这篇对你有用，欢迎关注看「AI 工具人 PM 实战」系列更新；你家带娃是怎么分工的，有没有为「谁来看记录」纠结过，评论聊聊；觉得有用就收藏备用。

这个系列到这里收官了：从总览、建模、踩坑、测试、决策、上架、工具，到产品、学习和三个用户视角。希望它能帮你用 AI 做出属于自己的东西。