用途不明的字段需要解释
别名: 字段用途说明 · 必要性解释 · 采集点告知 · why we ask
概念解释
采集点的字段用途解释（just-in-time field-purpose explanation）在请求信息的位置说明为何需要该字段、它对当前任务是否必要、谁或什么系统会使用它，以及不提供或提供后会发生什么。字段标签即使清楚命名了“身份证号”或“紧急联系人”，也没有自动回答这些问题。解释应支持知情决定，而不是用“为了更好体验”等泛化理由推动填写；敏感字段尤其需要与更完整的隐私告知、权限或同意流程一致。
机制
人们会从字段位置、必填标记和既往经验推断用途，但同一数据可以支持身份核验、履约、推荐、营销或风控等不同处理。缺少解释会使必要性、受众与后果留给猜测，也会让代理填写者不知道是否有权提供他人信息。紧邻说明把数据请求与当前功能建立局部联系：用途说明回答为哪项功能，必要性说明不填能否继续，受众说明谁会看到或接收，保留/后果提示说明何时失效或会触发什么。它不能单独承担所有法律信息，也不应把“显示在采集点”误写成无限授权。
怎么研究
为每个字段建立 data-purpose map，记录数据项、来源、用途、必要/可选、接收角色、保留或删除触发、拒绝结果和后续使用，再与实际数据流核对。让目标用户在输入前回答为何收集、谁会使用、不填会怎样和之后能否控制，测理解、填写决定、虚假输入、求助与信任；对代理或第三方数据单独测试授权判断。比较行内摘要、分层详情与外链时要覆盖触屏、键盘、放大和读屏，不能只测 hover。理解上升不等于处理合法或最小化，法律与隐私审查仍需独立完成。
边界
用途可由任务语境唯一推出且后果普通的字段可以用短说明或不重复解释，但“团队觉得显然”不是用户证据。敏感并不由字段名称单独决定，组合、用途、受众与地区规则都会改变风险。采集点摘要不能替代适用的完整隐私告知、同意、合法性判断、访问/删除权或数据最小化；反过来，一个远端隐私政策也不能替代当前决定所需的就地解释。安全或反滥用场景可以收敛会被规避的检测细节，但仍应诚实说明可披露的目的、必要性和用户后果。
怎么落地
- 为字段维护 purpose、necessity、recipient/audience、retention trigger、omission consequence、owner 和 notice version，并使采集点文案从现行数据处理记录生成或核对。
- 在字段旁给出一句可扫描摘要：为什么现在需要、必填或可选、不提供的功能后果，并用原生描述关系或等价平台语义把摘要与具体控件程序关联。涉及他人、长期保留、外部接收或高风险处理时提供邻近详情；展开控件需暴露名称、展开状态和所控制内容，并验证聚焦、触摸与读屏读取顺序。
- 禁止用模糊收益或夸大必要性换取输入。实际出现新用途、接收方或保留规则时先更新治理与适用告知，再决定是否重新请求，而不是静默复用旧说明。
- 测试填写前理解和拒绝路径，并以数据流审计核对承诺。解释不清则改文案；用途不必要或无法说明则删除字段，不能把内容优化当作继续采集的理由。