已收集清单与第三方共享清单：两张表要随版本自己长出来｜洹拓科技
一、两张表的内容要从调用面反推，不能从问卷里填
把这件事当法律文书来写的团队很多，把它当工程交付物来写的很少。要求把个人信息保护拆成两张清单的那份行业服务提升文件（发文字号为工信部信管函〔2021〕292 号），把任务归成几组，双清单是其中一组：一张是已收集个人信息清单，一张是与第三方共享个人信息清单，要求在应用内以次级页面的方式展示，展示范围覆盖应用内嵌的第三方组件。
一旦承认它们是交付物，第一个问题就变成：这两张表里的内容从哪儿来。最常见的做法是发一份问卷给业务与法务，问每个功能采了什么、给了谁，再把答案誊成对外页面。这条路在第一个版本走得通，到第三个版本必然失真，因为答案的来源是人的记忆，而采集行为的存在理由是代码。
可靠的取数来源只有三类，而且必须并用。第一类是构建期静态扫描调用点，在编译阶段扫出网络出网目标、本地存储读写、系统权限申请与埋点上报的调用位置，产出的是这一版代码有可能采什么。第二类是运行时观测，在真实环境里记录实际发生的出站请求与其携带的参数，产出的是这一版实际采了什么、发给了哪一方。第三类是按权限使用记录反查，把系统侧记录的权限调用与功能入口对上，专门兜住那种自家代码里没有直接调用、却由内嵌组件代为完成的情形。
三类来源不能互相替代。静态扫描看得见自家代码，看不见组件在运行时拼出来的目标地址；运行时观测看得见真实发生的流量，看不见这一版没被触发的分支；权限记录看得见调用确实发生了，看不见这次调用服务于哪个功能目的。缺任何一类，清单上就会留下一格空白，而对外材料里的空白在争议中通常按最不利的方式解释。
二、内嵌组件那一格为什么总是空的
清单要求覆盖内嵌的第三方组件，恰恰是这一格最容易空着。原因不在疏忽，在结构：组件由依赖清单引入，版本随构建自动升级，它的采集行为不在我们的代码里，也不写进它自己的版本说明。于是最常见的状态是，清单上列了组件与用途，行为却跟着一次小版本更新悄悄变了，没有人负责再看第二遍。
对策是一本组件准入台账，字段固定成五栏：来源与版本、组件自己声明的采集项、我们运行时观测到的采集项、两者的差异说明、末次复核日期。台账的重心在第三栏与第四栏，声明与实际观测必须并排放着看，差异说明不许留空。
处置规则要提前定死，不能每次现场判断。第一条是，声明与实际观测不符时按最保守口径登记，也就是按观测到的那一项写进对外清单，同时把差异提交给组件提供方核对。反过来按声明登记，等于把我们的对外承诺建立在别人的文档质量上。第二条是版本闸门：清单复核没有走完的组件版本，不允许进入发布分支。第三条是升级即复核，组件版本号变化本身就触发一次观测比对，而不是等到年度检查才想起来。这三条写在流程文档里没有用，必须写在合入检查的自动化规则里。
三、条目要写成能被核验的四元组
被点名的字段是四个：信息种类、使用目的、使用场景，共享清单在其之上再加一项共享方式。四元组看着简单，写起来最容易塌的是后两项。
| 清单 | 必备字段 | 最常缺的一栏 | 补齐依据 |
|---|---|---|---|
| 已收集个人信息清单 | 信息种类、使用目的、使用场景 | 使用场景，常被功能名代替 | 运行时观测到的触发条件 |
| 与第三方共享个人信息清单 | 上述三项，再加共享方式 | 共享方式与触发条件 | 出网目标与请求参数记录 |
一条失效写法就能说明问题：使用目的写“提升用户体验”。这句话无法核验，因为它不指向任何具体行为，既不能证明我们只做了这件事，也不能证明我们没有多做别的事。一旦进入争议，这类条目会整体失去证明力，连带把旁边写得还算老实的条目一起拖下去。可用的写法要能回答三件事：采的是哪一项数据，在用户做哪个动作的时候采，用户不做这个动作时对应功能会怎样退化。
同一套口径还要覆盖敏感权限的调用告知。调用相册、通讯录、位置这类权限时要告知调用目的，而弹窗里那句话必须与清单条目同源，改一处就要改两处。否则就会出现调用时写着“用于推荐附近的门店”、清单上却写着“用于提供基础服务”的两套说法。两套说法并存，等于告诉核查方我们的对外材料不是同一份数据生成的。
四、清单要有版本，钩子挂在发布流程上
清单不是一次性文档，它是随代码演进的产物，所以它需要自己的版本与差异记录：哪个版本新增了哪一类信息字段、哪个组件换到了哪个版本、新增的出网目标从哪一版开始生效。没有这份记录，对外页面就永远只有“当前态”，无法回答任何“当时看到的是什么”。
要挂两处钩子，位置在发布流程上而不是在文档目录里。第一处在合入前：改动命中了采集面（新增出网目标、新增权限申请、新增本地存储读写、升级了某个组件）时，检查是否同时提交了清单条目的更新，没有就拦下。第二处在打包时：发布包内记录当次清单版本号，让对外展示的页面与包内版本能对上。
两处钩子各解决一类事故。前者防的是“改了代码忘了改表”，这是清单长期失真的主要来源；后者防的是取证困难，出问题时能明确指认用户当时看到的那一版写了什么，而不是把当时的页面重新拼一遍。第二处钩子的成本极低，收益要等到争议那天才显出来，所以最容易被省掉，省掉之后前面所有的认真都会被质疑。
五、次级页面这一层，验收要给出能判的三条
要求写在应用内的二级菜单展示，产品工程的含义不是文案，而是层级、路径与一致性。“藏在多级设置深处”和“在次级页面集中展示”的差别，得能被验收而不是被感觉。我们的自查判据固定三条。
第一条看入口深度：从首页与应用内常规设置入口出发，到达两张清单所需的点击次数应当落在同一层级上，且不允许出现某一张表被单独挪到更深的位置。第二条看路径同源：个人中心、设置、关于页里可能存在的多个入口，指向的是不是同一份内容，如果每个入口各自维护一份，就已经违反了这个要求的本意。第三条看并列可发现性：撤回入口与卸载相关的入口，是否在同一层级能够被发现，而不是被拆到更深的角落。
第三条要说清边界：本篇只判入口能否被找到、多条路径是否同源，用户同意状态本身怎样判定与回显是另一层问题，不在这里展开。这三条判据的好处是它们都可以被截图取证，核查方不必听解释，翻几张按路径顺序截下的图就有结论。
六、带数字的服务红线，口径要比阈值先定
这份文件里还有一组直接给了数字的服务红线，最容易踩的坑不是达不到，而是把指标算成了对自己最有利的那种口径。
以月均响应时限最长三十秒为例。要先写清三件事：分子是排队等待到首次接起的时长，还是全部会话时长的合计；分母按会话计还是按用户计；统计窗口是自然月还是滚动区间。按月平均会把单日爆表摊平，一个月的达标读数之下可以藏着几天彻底的失守。可用的监控口径是月值、日值与分位值三件同报，告警挂在日值与高分位上，月值只用于对外报送。
人工服务应答率超过百分之八十五这一条，失真点更隐蔽。按会话计数与按用户计数得到的结果不同，一个用户反复进线会被算成多次还是一个人。最难定的是起点：机器人先接一段再转人工时，“人工应答”从进入人工队列那一刻算，还是从人工实际接起那一刻算；转接后放弃等待的会话是否计入分母；机器人自助解决的会话要不要算作已应答。这几个选择任何一个换一边站，读数就能差出很多。因此指标名里必须把口径写全，取数脚本与指标定义同批交付，否则这个读数没有对外价值。为特定人群保留人工直连的那条路径，其读数要单列，混进整体均值里就等于把它抹平了。
合同类的量化承诺同理。带宽业务的合同要写明上行与下行的理论速率并承诺达标，还要告知硬件与环境条件对速率的影响。交付文档里应当四件同列：理论值、承诺值、实测得到的分位值、影响条件清单。只写理论值在投诉处理中必然处于不利，因为理论值是链路能力上限，而用户拿到的从来不是上限；把这一项单独摆出来，等于把举证材料留给对方去补。网络存储类产品要明示存储空间、传输速率、功能权益与资费，免费用户的最低速率还要满足基本下载需求，这类“基本需求”的表述同样只能靠可复算的读数落地，靠形容词是不行的。
最后是报送与“回头看”的留痕。把每一项任务映射到内部的责任对象与证据类型，界面截图、清单导出版本、指标读数连同取数脚本、对外公示页面地址，四类证据各有归属人。文件对多数任务给出的完成时点是发布后的一个季度内，客服响应能力这一项留到更晚一档，因此内部排期上不能把清单展示改造与客服口径改造压在同一时点。这些材料要能长期供核查方独立复算，跟踪、约谈、排名、公示与“回头看”这一套机制认的是复算结果，不是承诺本身。洹拓把这两张表的生成与复核纳入了发布流程与数据看板，验收当天交出去的是脚本和读数，而不是两份看起来整洁的页面。