V2.03.1Change awareness设计研究
需知道什么被谁改了
别名: 变更感知 · 变更归因 · change attribution
概念解释
共享内容被修改后，协作者需要能回答两个基本问题：改了什么（哪些对象、哪个层面）与被谁改的（归因）。合称变更感知（change awareness）。它跟实时的工作空间感知分工明确：后者服务于「此刻」，前者服务于「我不在的时候发生了什么」。变更信息的最小可用单元是「对象 + 作者 + 时间」三元组，缺任何一角，协作者要么不知道去哪看，要么不知道该去问谁。
机制
异步协作的默认状态是缺席：内容在被改动时你多半不在场，回来面对的是一个「结果状态」。没有变更感知时，你只能把整个结果重读一遍来推测差异——对长文档与复杂画布，这个全量比对的成本随内容规模线性上涨，而其中绝大部分是没变的部分。变更信息的作用是把比对从「人对内容」压缩为「人对差异」：只需增量阅读，成本正比于改动量而非内容量。归因（被谁改的）则有第二层功能：它决定后续协调动作的指向——有疑问时知道找谁、有冲突时知道与谁对齐、评估可信度时知道改动来自谁。共享内容之所以与个人内容需要不同的信息架构，核心就在这条：共享内容的每次修改都是一个社会事件，需要留下可追溯的行动者。缺少归因的变更信息（如匿名的「已更新」）只完成了一半工作，它告诉你去哪看，却不告诉你该信多少、去问谁。
怎么研究
- 范式：基于真实协作仓库（文档版本历史、开源代码库）的日志分析考察变更通知的接收与回访行为；受控实验则操纵变更信息的粒度与归因有无，测量回归任务中的定位时间与遗漏率。
- 变量：自变量为变更信息粒度（对象级 / 属性级 / 全文通知）、是否带作者、推送时机（即时 / 摘要）；因变量为回归后的定位耗时、被遗漏的变更比例、向他人询问的次数。
- 在界面研究里的用途：为版本历史、动态流（activity feed）、文档内变更高亮的设计提供粒度依据。
- 方法论注意点：变更感知的真正考验在「长期、低频」的回归场景，一次性实验任务测出的是短时记忆优势，会高估即时通知的价值、低估沉淀的可检索历史的价值。
边界
变更感知的价值与缺席时长正相关：一直在场的人几乎不需要它（实时感知已覆盖），长期缺席者才重度依赖。高度活跃的对象（每天数百次小改动）会让任何逐条变更信息失去可读性，只能退到摘要层（见同组关于摘要优于逐条的讨论）。涉及敏感协作关系的场景中，逐人的变更归因本身可能成为压力源——每个改动都被公开记名，会让部分贡献者回避修改或过度谨慎，这是归因透明化的代价面。
怎么落地
- 每次共享对象的修改自动记录最小三元组（对象、作者、时间），并在对象旁以最轻方式可及（角标、列表行、内联标记），不需要用户显式查询版本历史。
- 变更信息按对象层级组织而非按时间流平铺：用户回归时的提问是「这份文档/这个区域变了什么」，不是「过去 48 小时发生了什么」。
- 归因信息默认公开于协作者之间，但对群组外可见性单独控制；对细微改动（格式、错字）允许聚合归因以免噪声。
- 验证办法：抽样回归场景，统计「为找出改了什么」而花费的阅读与询问时间；对照变更信息粒度调整前后的差异，并检查被遗漏变更的比例是否下降。