一次个人采集，怎样形成新原型
从 App 选择动作开始，沿开始、筛选、累加、结束或取消的顺序读代码。每个条件都对应一项数据质量或业务要求。
1 · 先确定用户想更新哪一类
App Session 选择活动，向手表发送开始命令与类别编号。proto_session_start 清空本次累加器、数量，记录目标类别并进入活动状态。类别编号必须与基础模型和原型表一致，不能只按界面文字位置猜测。
原型更新使用每次成功推理产生的新特征，一份 128 维特征是一个有效推理样本，不是一个原始加速度点。窗口之间可能高度重叠，也不等于采到了同样数量的独立动作。
2 · 为什么不是每份特征都收下
当前 proto_session_feed_if 的筛选顺序
if (!g_session_active) return;
if (har_class != (int)g_session_class) return;
if (har_conf < 0.7f) return;
proto_session_feed(embedding);先看是否在采集，再看基础类别是否匹配目标，最后看基础置信度。被接纳的特征逐坐标累加，数量增加。这些默认条件用于减少过渡动作污染，但并不自动给出正确人工标签。
若基础模型经常把目标动作认错，最需要改善的样本可能被筛掉。采集记录要同时统计尝试数量、通过数量、拒绝原因与独立人工动作，不能只看最后通过了多少。
3 · 结束时究竟更新了什么
当前门槛为 50。有效次数不足会丢弃本次累加，不更新原型。达到条件后求均值、归一化，再替换对应类别。不要沿用旧注释中的固定分钟数推算所有采集时长，实际推理间隔和拒绝比例会改变耗时。
4 · 版本与计数怎样解释
版本增加表示原型发生更新，不表示识别效果已经更好。数量反映曾接纳的推理样本，不能代替人员覆盖或独立样本量。UI 应把“正在记录”“有效样本足够”“版本已改变”区分开。
会话 abort 只取消本次收集，保留旧原型。重复开始、断开连接和无有效特征等路径应有明确结果。测试可模拟筛选条件，但最终佩戴效果需另外采集验证。
5 · 把采集记录留给后面的比较
保存基础模型版本、目标类别、人员、场次、更新前原型、通过比例和更新后原型。原型平均方法很短，真正需要解释的是输入从哪里来、是否受到系统性筛选。
模拟 49 次、50 次、类别不匹配和置信度不足的会话，说明哪些情况更新。把一次长时间但低通过率记录与一次短时间高通过率记录比较，避免只用持续时间评价采集量。