家长管控是硬件决定，不只是设置页

儿童 AI 玩具的隐私页面，通常由市场部最后写，写的是 App。而产品真正的隐私，早在几个月前的一张原理图上就定了：当时有人选择了麦克风要不要和常开的唤醒引擎共用一路供电。

举三个我们从救火现场拿来的例子。

那个不是静音的静音

一个产品，App 里有静音按钮，机身上有开关。原理图上，麦克风偏置和唤醒引擎共用一路电，开关切换的是一个寄存器。于是板子醒着的时候麦克风一直在采样，「静音」控制的只是采样发不发出去。用户看不出区别；拿示波器的评审看得出：电路任何时候都在听。修法——麦克风供电串一个开关，编解码器加一个掐断数字通路的静音脚——花了半天布线、一小块板区的第二次改版。它本该是需求，而不是补丁。

云端的唤醒词

关键词检测最便宜的硅片是不放硅片：把音频流到服务器，在云端检测唤醒词。准确率极好。但品牌从此要辩护的命题变成：在被问任何问题之前，儿童卧室的音频先到了数据中心。对某些成人产品这可以辩护；对一只睡前毛绒通常不行，而事后补一个本地唤醒引擎意味着换板，不是发固件。唤醒架构要在产品还是框图的时候定——它是唯一一个补不进来的决定。

那个音频字段

一个后端，为了「改进质量」给原始音频留了一个字段。每个孩子房间的每段对话，躺在一张表里。给出的辩护是文档里的一条留存政策。修法是改表结构：转写带过期时间、识别一返回就从缓冲释放音频、孩子档案只存昵称。数据最小化不是政策里的一段话。它在数据库里是真的，才可能在别处是真的。

对开发项目意味着什么

把管控作为硬件项写上需求单，而不是 App 项：断电路的静音开关、本地运行的唤醒词、没有原始音频字段的数据模型、家长可读可删的转写。然后用家长的语言把那句话印在包装上——「它只等自己的名字，等到之后才开始听」——因为这句话要经得起一个不信任你的人拆机核对。

这些在需求单阶段都不贵。开完模之后全都贵。