多人协作与社会交互设计规范

面向设计师与工程师：当两个以上的人在同一份东西上共事，让每个人知道别人在做什么而不至于被监视，让每个人的输入不被别人的操作静默吃掉，并且让"我撤销"永远只撤销我做的那一步。

多人协作产品做的事，是让一份东西同时属于好几个人：一份文档、一块画布、一条任务、一个空间。这件事一旦发生，单人产品不需要回答的问题就全部出现了——别人现在在不在、在看哪儿、正在改哪一块；这份东西现在谁能看见、下一秒谁又能看见了；两个人同时改同一处算谁的；我按下撤销，撤掉的是我刚才那一步还是别人刚才那一步；这件事现在归谁负责，那个人离职之后又归谁；以及，在一个所有人都看得见的地方，我还有没有地方可以先试一下。本规范从"同一个对象上出现了第二个人"这一刻开始管辖。

这个领域最常见的设计错误，是把它当成一张实时协作编辑的功能清单：把多人光标、头像栏、评论气泡、修改历史逐个做出来，就认为协作做完了。这些是机制，不是承诺。真正会伤到人的地方不在机制清单上——是"谁看过这份文档"被做成了一个没人能关的默认功能，是有人把分享范围从三个人改成了链接可见而已经在里面的三个人毫不知情，是自动合并把两个人的修改拼成了含义错误却已生效的结果，是一个新人按了两次 Ctrl+Z 把资深同事十分钟的工作退回去了，是负责人离职之后他名下的三十个任务既没有转移也没有报错、只是安静地不再有人看。这些失败都不是缺功能，是缺对后果的规定。

本规范由六条原则和 40 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（C3-2 就是第三条原则下的第二条规则）。六条原则按规范对象切分：协作中的感知信息、内容的可见范围、并发修改的裁决、共享操作的作用与结果、责任与决定的归属、私人状态与参与选择。

范围声明本规范约束产品在多人共事能力上对用户作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不指定同步算法、数据模型或权限模型。它适用于文档、白板、任务看板、评审与围绕共享对象的讨论，不要求所有产品提供全部能力。采用本规范不能替代下列专项评估与合规判定：隐私与个人信息保护（成员活动记录可能涉及个人信息处理，须按目标市场与功能评估）、劳动与雇佣相关的监控合规、企业信息安全与访问控制的技术审计、数据保留与电子取证要求，以及完整的无障碍符合性评估；本文直接规定协作过程特有的无障碍要求。明确不在本规范范围内的三件事：开放社交平台的内容审核与推荐排序（本文只规定协作空间内的参与、免打扰及求助边界）；组织的岗位、汇报关系与绩效管理制度（本规范只管产品里的责任字段怎么表达，不管组织怎么分工）；端到端加密的密码学实现与密钥管理（本文要求访问控制实际生效，不规定密码学方案）。

正文从第 0 章任务与事实入口开始，第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；验证清单与论据说明见附录 A、B，组合场景与验收记录见附录 C，完整来源见 reference.md，可配置项见《多人协作与社会交互 Design Token》。

---

0. 从一个协作任务开始¶

先选一个真实任务，列出发起者、协作者、裁决者、外部成员及会受到影响的人，再决定需要哪些能力。纯只读共享不必实现编辑锁；普通评论不必实现正式投票。

状态文案必须有证据。以下是运行事实，不是可配置的 Token 值；“未知”与“失败”分别呈现，不能用旧事实填补缺失。

对界面上每一个“已……”分别记录对象、证据来源、观察时点和有效边界。无法提供这些证据时，应使用“正在核对”“已在本机保存”“等待承接”等与事实相称的表达。

1. 六条原则¶

六条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。对象不同，原则就不会互相替代——这是切分的依据，也是检验切分的方式。

同一个场景可以触及多条原则——一位成员在共享看板上把某列的筛选条件改掉、顺手把三张卡片批量指派给了刚离职同事的账号，然后按了撤销：产品同时面对这次筛选改动是个人视图还是共享视图（C6-3）、批量指派是否在执行前说明了作用范围与打扰后果（C4-4、C4-6）、被指派方已不在组织内时责任的去向（C5-3）、以及这次撤销撤掉的是他自己的三次指派还是包含了别人在这期间的改动（C4-1、C4-2）。这不是分类错误：这些规则约束的是不同规范对象上的义务，一个是个人状态的默认归属，一个是操作的作用范围，一个是责任的去向，一个是撤销的作用域。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的两处边界，在此明示：C1 与 C2——C1 管"关于人的信息给谁看"，C2 管"关于内容的可见范围"。"谁看过这份文档"两边都沾，归属依据是它的直接规范对象是一个人的阅读行为这项关于人的信息，因此归 C1；而"这份文档现在对谁可见"的直接规范对象是内容的可见范围，归 C2。C4 与 C6——C4 管"我的操作对别人产生了什么效果"，C6 管"我的状态什么时候开始对别人可见"。同一次"改了但还没想好"，若问题是这次改动已经生效并波及了他人的工作，归 C4；若问题是产品根本没给出一条不影响他人的尝试路径、逼着人直接改共享态，归 C6。这两处若在实践中反复出现归属争议，应当调整原则而不是增设中间层。

原则用于理解规则与裁决归属，本身不作为单独的判定条目。当原则与具体条款的解读出现冲突时，以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。一套"变更记录"既是操作归属的依据（C4-3）、也是冲突裁决的证据（C3-4）、还是责任交接后历史不被改写的保障（C5-4）；一套"主体解析"既决定可见范围能不能被查明（C2-1）、也决定在场信息给谁看（C1-4）、还决定离职后内容归谁（C5-3）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

一句话概括各部分的效力：规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

规则写行为性质、不写实现方式：两个人同时改同一段落之后谁的输入都还在、并且都能认出哪部分是自己写的，这是产品行为；用操作转换、无冲突复制数据类型、悲观锁还是三方合并实现，是工程方案——两者必须对得上，但不是同一份交付物。本规范因此不指定同步协议、数据结构或一致性模型。

2.2 约束词¶

规则正文使用三级约束词：

• 必须：不满足即不符合本规范。缺了它，某条对用户的承诺会在可预见的情境下失效——这是标「必须」的唯一依据。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（C2-6、C3-6、C4-6、C5-5、C6-5 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述，不表达义务。

强度表示约束力，不表示重要性。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而把协作做成了报批流程。多人协作被做坏的方式在两端都很密集：一端是把所有人的一举一动实时广播给所有人、把工作区变成监控室，另一端是为了保护每个人而给每次改动都加一道审核、让两个人改一句话要走三次通知。让人能一起干活，与让人不被互相伤害，是同一件事的两面；只顾一面都算没做对。

特别提示一处最容易做过头的地方：冲突提示不是越多越好。把任何两个人先后动过同一份文件都判成冲突、每天弹十几次合并界面，与静默丢弃输入一样，都会导致人不再看提示。

2.4 规则速查：40 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（C2-6、C3-6、C4-6、C5-5、C6-5），判定以正文为准（见 2.2）。

C1 感知他人有边界

C2 可见性是内容的属性

C3 并发修改不吞输入

C4 个人操作有明确作用范围

C5 责任有归属且可交接

C6 共享空间里有私人余地

3. 规则详解¶

本章按六条原则展开全部 40 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件，也不要求新增独立交付文档。

3.1 C1 感知他人有边界¶

协作需要知道别人在做什么：知道同事已经在改第三节，我就不去改第三节；知道方案没人看过，我就再催一次。这类信息是协作效率的来源，也是这个领域最早被做过头的地方——同一份信息，粒度粗一点是协作，细一点就是监控。这条原则管的是关于其他人的信息怎么产生、给到什么粒度、给谁看，以及被感知的那个人有没有说话的余地。它不管内容本身的可见范围，那是 C2。

C1-1在场状态来自当前判定必须¶

一句话：头像亮着，就该是真的在；不确定就写不确定。

适用向用户呈现其他成员是否在线、是否在当前对象上、是否可被立即联系的产品。

规则呈现给用户的他人在场状态必须来自当前有效的判定（连接、近期交互、显式设置之一以上），并明确该判定的有效期。有效心跳指属于当前连接世代、顺序有效且未被判过期的证据；延迟到达的缓冲包不得在重连后重新延长旧会话的在线声明。接收时刻只用于本端计时，不替代来源身份与时效检查。判定过期后必须呈现为状态未知或离线，禁止把最后一次活跃时间直接呈现为当前在场（见 collab.presence.freshness.ttl）。用户显式设置的在场状态（忙碌、勿扰、隐身）优先于系统探测结果，系统禁止以探测结果覆盖或"纠正"用户的显式设置。在场状态不可得时，必须呈现为未知，不得以默认在线填补。

边界条件本条不要求实时探测，也不禁止把探测做成用户触发的刷新；它约束的是呈现与实际判定之间的一致性。查看头像本身不续期；当前在场也不证明具体的人正在关注。

设计应用把"离线""状态未知""最后活跃于某时"设计成三种可分辨的呈现，而不是把后两者都画成灰色圆点。给"正在此对象上"和"在产品内但不在此对象上"分别的表达，前者的时效通常远短于后者。

验证示例

• 用户侧：让一名成员关闭客户端或断网，观察其他成员看到的状态在多长时间内变化，以及是否会据此发起一次注定无人应答的联系。
• 实现侧：检查在场判定的信号来源与有效期配置；验证过期状态不被缓存复用，且用户显式设置不被探测结果覆盖。

反例做不到——同事三小时前关了电脑，协作者列表里他的头像仍然亮着绿点，别人在文档里 @ 他等回复；做过头——为了状态精确，每两秒向所有成员广播一次心跳，把在场做成了活跃度直播。

C1-2账号在场不等于本人在场必须¶

一句话：那个头像后面不一定是那个人。

适用以在场状态作为联系、指派、审批或权限判断依据的产品。

规则系统禁止把账号的在场状态作为本人在场的证据向其他成员断言。共享设备、共享账号、会议室终端、代理登录与自动化会话产生的在场，必须与个人在场可区分（见 collab.presence.identity.mode）。需要本人确认的操作禁止仅以在场状态作为已获知的依据；由 Agent 或自动化代表某人产生的活动，其呈现必须可被识别为非本人操作。

边界条件本条不要求产品实现身份核验，也不禁止把在场作为"值得一试"的联系提示；它禁止的是把在场当成"这个人已经知道了"或"这个人同意了"。

设计应用把共享终端上的会话呈现为设备而非人；把由自动化维持的长连接排除在人的在场判定之外，否则一台永不休眠的服务器会让一个人永远在线。

验证示例

• 用户侧：在共享会议室终端上以某人账号登录，观察其他成员看到的是"某人在线"还是"某设备在线"。
• 实现侧：核查在场信号的来源分类；验证自动化会话不计入个人在场。

反例做不到——同事的账号在办公室公用大屏上登着，看板显示他一整天在线，任务全被指派给他；做过头——为了确保是本人，每次查看协作者列表都要求所有成员重新验证身份。

C1-3感知粒度只够协作用必须¶

一句话：够我知道别人在改哪块就行，不必知道他敲了几下键。

适用向成员呈现其他成员活动信息的产品。

规则每一类感知信息必须绑定它要解决的协作问题，其粒度不得超过解决该问题所需（见 collab.presence.awareness.granularity）。禁止把逐次输入、停留时长、光标空闲时间、切窗行为、单位时间操作次数等过程数据作为面向其他成员的常规感知信息呈现。需要更细粒度的场景（如同步演示、结对操作、事故排查）必须是被感知方显式开启的一次性或有期限的状态，不得作为默认。感知信息的呈现范围必须与该协作问题的相关方一致，不得向与该对象无关的成员广播。

边界条件本条不禁止呈现"某人正在编辑这一段""某人在此文档中"这类定位到对象与区块的信息——那正是协作所需的粒度。它也不约束被感知方自己看到的自身数据。审计与安全日志按各自的合规要求处理，不属于本条所指的面向成员的感知信息，但它们同样受 C1-6 的用途约束。

设计应用先写出"这条感知信息帮别人避免了什么具体麻烦"，写不出来的就删掉。同一个信号可以有两个粒度：给协作者看"正在第三节"，给本人看"你在此停留了四十分钟"，后者不外发。

验证示例

• 用户侧：列出产品中所有会被其他成员看到的活动信息，逐条问"少了它，协作会出什么具体问题"。
• 实现侧：核对面向成员的感知字段清单与内部埋点清单是否被混用；检查是否存在未声明的细粒度活动被前端消费。

反例做不到——协作侧栏实时显示"张三已闲置 12 分钟""李四今日编辑 47 次"；做过头——为了避免监控嫌疑，连"有人正在编辑这一段"也不显示，两个人反复覆盖对方的修改。

C1-4被感知方可知可控必须¶

一句话：我的行踪被谁看着，我要知道，并且能收起来。

适用产生并向他人呈现成员活动信息的产品。

规则每个成员必须能查明自己的哪些活动信息正在被呈现给谁（见 collab.presence.subject.view）。产品必须提供收敛自身可见性的档位（至少含一档不向其他成员呈现实时在场与位置的取值），且采用该档位禁止导致核心协作功能不可用或产生功能性惩罚（见 collab.presence.visibility.self）。当某成员的活动信息被呈现给此前不在范围内的主体时（新成员加入、范围扩大、导出到外部），必须遵循 C2-2 的告知要求。

边界条件不呈现实时在场与位置不等于匿名协作：成员仍可看见共享贡献的作者、有效锁的持有人和当前责任人。组织策略可规定受控审计，但不能取消正文要求的实时感知收敛档位，或把使用该档位标为异常。本条不豁免记录本身的合规义务：安全审计所需的记录不因成员收敛可见性而免于保存，它们只是不向其他成员呈现。

设计应用把"我看得见谁"与"谁看得见我"做成两份可分别查看的清单——多数产品只做了前者。收敛档位的措辞要说明代价（"其他人将无法看到你是否在线，也无法知道你在看这份文档"），让人在知情下选择。

验证示例

• 用户侧：让一名成员尝试回答"公司里谁能看到我现在在读哪份文档"，记录他需要多少步、是否能得到确定答案。
• 实现侧：开启收敛档位后，核查所有面向他人的接口是否确实不再返回该成员的实时位置与在场。

反例做不到——阅读记录默认对全部有权访问者可见，产品里找不到任何入口说明这件事，也关不掉；做过头——把可见性做成每次打开文档都要选一次的弹窗，选完还要确认。

C1-5"谁看过"与"谁在线"分别决定必须¶

一句话：在线是此刻的暴露，看过是回溯的暴露，不能一个开关捆了。

适用同时提供实时在场信息与阅读、查看、已读记录的产品。

规则实时在场信息与回溯性的查看记录必须作为两类信息分别管理：其开启与关闭、可见受众、保留期限必须可分别决定（见 collab.presence.seen.mode、collab.record.retention.ttl）。禁止以单一开关同时决定两者，也禁止在关闭其一时以另一类信息重建等价结论（如关闭已读回执后，用在场时间与文档打开次数拼出等价的已读列表）。查看记录的保留期限必须明确并可查；超期后禁止继续向其他成员呈现。查看记录的存在本身必须在成员首次可能被记录之前可获知，不得仅存在于条款。

边界条件本条不禁止提供已读回执或查看记录——它们在很多协作场景中确有价值。它要求的是这两类暴露被分别决定。法定或合同要求的送达证明（如正式通知的签收）不受本条"可关闭"要求约束，但仍须遵守可获知与保留期限的要求。

设计应用把两者的差别写进设置项本身的措辞——"其他人可以看到你现在是否在线"与"其他人可以看到你在什么时候看过哪些内容"是两句不同的话，写在一起就等于没写。已读记录的默认受众通常应当限于内容的责任主体，而非全部有权访问者。

验证示例

• 用户侧：关闭查看记录后，检查其他成员是否仍能通过在场历史、通知已读、评论浏览位置等旁路推断出等价信息。
• 实现侧：核对两类信息的开关、受众与保留期是否为独立配置；验证超期记录不再对外返回。

反例做不到——一个"协作可见性"开关同时管在线状态与阅读记录，关掉之后连自己的在线状态也没了，于是没人敢关；做过头——每次打开一份共享文档都先弹一次"是否允许记录本次查看"。

C1-6感知信息不反向用于评价必须¶

一句话：在线时长、阅读记录、改动条数，不许拿去打分。

适用采集成员在场、查看或操作信息的产品。

规则为协作感知目的产生的信息，禁止用于对成员的绩效评价、能力评分、任务分配优先级、排序权重、准入判定或差别定价（见 collab.presence.purpose.scope）。每一类感知信息必须绑定明确用途与下游消费方，未列出的模块不得读取；禁止以聚合、排名或"团队活跃度"等形式对个人产生同等效果的呈现。将协作活动数据用于管理用途的场景（如工时统计），须由该场景自身的合规依据支撑并对被采集者明示，不得以本产品的协作功能为由默认开启。

边界条件本条不禁止面向成员本人的自我统计，也不禁止不指向个人的容量与性能度量。它约束的是把感知信息变成对人的判定。组织出于安全或审计目的的日志访问按各自制度处理，不属于本条所指的评价用途，但其访问同样须有依据与记录。

设计应用把感知字段的下游消费方写成显式清单并定期核对——这类越界通常不是有意设计的，是某个报表模块直接读了协作库。给"团队仪表盘"类功能设一条硬约束：可以显示对象的进展，不显示人的活跃度排名。

验证示例

• 用户侧：检查产品中是否存在按成员排序的活跃度、编辑量或响应速度榜单。
• 实现侧：审计在场与查看记录的下游读取方清单是否与声明一致；有无旁路导出到人事或绩效系统。

反例做不到——协作平台给管理者提供"成员在线时长与文档编辑次数周报"，并按此排名；做过头——为避免被用于评价，连"这份文档最近三十天无人查看"这类对象级信息也不提供，导致过期内容无法被识别。

C1-7协作变化可被平等感知必须¶

一句话：不看颜色、不用鼠标，也能跟上变化并完成协作。

适用呈现在场、变更、评论、冲突或权限变化的产品。

规则

1. 系统必须提供不依赖颜色、头像或瞬时动画的辨识方式；姓名或可访问名称、对象位置、变化类型与可执行入口必须能被辅助技术获取，且不得超过成员当前获准查看的范围。
2. 评论、差异、冲突与处理入口必须可由键盘定位和操作，关联内容被移动或删除时必须说明定位变化，不把焦点移到无关内容。
3. 远端编辑不得无提示地抢走本人的输入焦点。产品必须提供控制非关键活动播报的方式，并保留主动查询变化的入口；暂停播报不等于暂停同步，也不关闭输入保护。
4. 提供跟随他人视角时，必须由跟随者主动进入，持续呈现跟随状态并允许随时退出；发起方不能替他人同意跟随。

相关配置：collab.presence.presentation。

边界条件本条要求信息与操作可达，不要求每次光标移动都播报，也不要求提供跟随功能。

验证示例用屏幕阅读器和键盘完成“定位评论—阅读所指内容—回复—返回原编辑处”；并发插入内容时检查焦点、选区及输入是否保留；暂停活动播报后仍可查到关键冲突。

反例做不到——只用红绿光标区分成员，评论只能鼠标悬停查看。做过头——逐次朗读所有远端按键，用户无法完成自己的句子。

3.2 C2 可见性是内容的属性¶

谁能看到什么，是内容自己带着的属性：它跟着内容走，被复制时跟着复制品走，被嵌入时跟着嵌入关系走，被导出时决定能不能导出。它不是界面上的一个开关——把菜单项藏起来、把按钮置灰、把搜索结果过滤掉，这些都不是可见性，只是可见性的呈现。这条原则管的是可见范围本身怎么被定义、怎么被查明、变更时谁有权知道，以及"看不到"这件事在机制上成不成立。它不管关于人的感知信息，那是 C1。

C2-1可见范围可解析到主体必须¶

一句话："已共享"不是答案，"谁"才是答案。

适用提供内容共享能力的产品。

规则任何共享对象在任何时刻，其可见范围必须能被有权查看该范围的成员解析到具体主体类别：具名个人、可枚举的群组、链接持有者、外部访客、组织内全体（见 collab.visibility.audience）。禁止仅以"已共享""公开""团队可见"作为可见范围的完整表述而不提供其解析结果。群组作为主体时，其当前成员必须可展开或至少可知其规模与来源；不可枚举的受众（如链接持有者）必须被明确标注为不可枚举（见 C2-3）。可见范围与编辑权限是两个维度，必须分别表达，禁止用单一等级同时表示两者。

边界条件本条不要求向所有成员公开完整的访问者名单——查看范围本身也可能是敏感信息；它要求的是有权者能得到确定答案，以及无权者得到的是明确的"你无权查看此信息"而不是一个看似完整实则被过滤过的名单。大规模组织中的"全体可见"不要求逐人枚举。

设计应用把共享面板的默认答案从状态词改成主体列表。对嵌套结构（文件夹内的文件、页面内的子页面），要能回答"这一份"的实际范围，而不只回答父级的设置。

验证示例

• 用户侧：随机取十个共享对象，让所有者在三十秒内说出各自的确切可见范围，记录答不出的比例与原因。
• 实现侧：核对界面呈现的范围与后端实际授权列表是否一致，特别是群组嵌套与继承叠加之后。

反例做不到——分享面板只显示"已开启共享"和一个复制链接按钮，谁能打开这份文档无从得知；做过头——把每一次访问都做成需要所有者逐个批准的申请，团队日常协作被卡住。

C2-2范围变更告知在其中的人必须¶

一句话：房间里多了人、或者门开了，屋里的人有权知道。

适用允许在内容创建后变更其可见范围的产品。

规则共享对象的可见范围扩大时，已在该范围内的成员必须能获知这一变更（见 collab.visibility.change.notice）。扩大包括：新增具名主体、加入新群组、从具名共享转为链接可见、从内部转为对外、被复制或嵌入到范围更大的对象中。告知必须说明变更后的范围而不只是"权限已更新"，变更记录与告知待办必须不晚于新主体取得访问时生成；在线贡献者继续提交前必须得到新受众提示，离线者在恢复提交前先核对。可见范围缩小时，被移除的主体必须获知其访问已终止，或产品必须确保其界面不再呈现该对象为可访问——联网界面禁止继续显示可提交状态；离线界面必须说明权限未能核验，重连不得凭缓存权限提交。范围变更必须记录变更主体与时间，并在保留期内可查（见 collab.record.categories）。

边界条件本条不要求逐次实时打扰：告知待办与变更记录在权限生效时点生成，其呈现可以聚合、可以延后到成员下次进入该对象时——在线且正在贡献的成员应在继续输入前看到，离线成员在下次进入时先看到新范围再继续贡献；产品选择延迟通知的，须记录该策略。它不要求把变更告知给内容的全部历史访问者，只要求告知变更时仍在范围内的成员。安全事件处置中的紧急撤权可以先执行后告知，但事后告知不可省略。本条要求的是界面送达或拦截新提交的可验证回执，不承诺证明任何人在心理上已经知道（见 C5-2 的证据分级）。

设计应用把"范围扩大"与"权限调整"在告知上分开——前者改变了谁能看见，后者可能只是把某人从可评论改成可编辑。对"转为链接可见"这一步单独设计提示，因为它是范围变更中不可逆性最强的一种（见 C2-3）。

验证示例

• 用户侧：在一份三人共享的文档上打开链接共享，观察原有三人是否、何时、以何种形式得知。
• 实现侧：核查每一类范围扩大动作是否都触发了告知；验证告知内容包含变更后的范围而非仅"设置已更改"。

反例做不到——文档所有者把内部文档改成"知道链接的任何人可编辑"，其他协作者毫不知情，继续在里面写内部信息；做过头——每次新增一名协作者都给全部现有成员推送一条即时通知，十人协作的文档一天几十条。

C2-3链接分享的传播性显式必须¶

一句话：链接会被转发，受众从此点不完也收不回。

适用提供以链接作为访问凭证的共享方式的产品。

规则创建以链接为凭证的共享时，必须在创建动作发生处说明其受众是不可枚举且可被转发的，而不仅说明当前的权限等级（见 collab.visibility.link.mode）。链接共享必须提供撤销手段，并声明有效期与附加访问限制；限定域或需登录不能替代撤销。撤销后，已建立的会话与此前取得的直接资源地址不得继续获得新的服务端访问（见 C2-4、C2-7）。已下载到终端的副本不因此被远程擦除。产品禁止把链接共享设为新建对象的默认可见范围。已通过链接访问过的主体，其访问记录的可获知性按 C1-5 与 C2-1 处理；不得以"链接是私密的"表述暗示受众可控。

边界条件本条不否定链接共享的价值——它常常是与外部协作唯一可行的方式。它约束的是这一选择的后果被如实说明。对已经离开产品边界的内容（他人另存的副本、截图、导出文件），撤销链接不构成对这些副本的控制，这一限制必须在撤销动作处说明，不得让用户以为撤销等于收回。

设计应用把"任何知道链接的人"这句话写在开关旁边，而不是写在帮助文档里；给链接共享一个非永久的默认有效期，让不作为的结果是收紧而不是放开。

验证示例

• 用户侧：让用户在开启链接共享后回答"现在有多少人能打开它"，记录有多少人给出了具体数字（这说明说明文案没起作用）。
• 实现侧：撤销链接后，用此前已获取的直接资源地址与已建立的会话重试访问，验证确实被拒绝。

反例做不到——一键"复制链接"默认生成组织外可访问的编辑链接，界面只写"链接已复制"；做过头——每次通过链接访问都要求访问者填写身份与用途表单，外部协作实际不可用。

C2-4权限在机制层生效必须¶

一句话：藏起来的按钮不是权限，取不到才是。

适用对不同主体呈现不同内容或不同操作能力的产品。

规则可见性与操作权限必须在数据与接口层强制，界面上的隐藏、置灰、过滤只作为呈现，禁止作为唯一的实施手段。无权主体禁止通过接口、导出、搜索索引、缩略图、预览、通知摘要、引用卡片或错误信息取得受限内容或其片段。部分可见的对象必须明确其部分性：当一个人看到的是被过滤后的列表、被截断的历史或被隐藏了若干条目的视图时，该事实必须可被知道（见 collab.visibility.partial.disclosure），否则他会把不完整当成完整并据此决策。

边界条件本条不要求对存在性本身保密——是否隐藏对象的存在是产品决定，见 C2-6 的两种取值。它不要求为每类内容实现独立的鉴权服务，只要求实际的取得路径都受同一套判定约束。存在性敏感时采用稳定的“仅显示你有权访问的范围”说明，不暴露隐藏条目的数量或是否存在。

设计应用把"这里还有 3 条你无权查看的评论"作为一种正常呈现，而不是把它们悄悄抹掉——抹掉会让人误以为讨论已经结束。对搜索与通知这两个最常见的泄露口，单独做越权用例。

验证示例

• 用户侧：以无权成员身份检查搜索结果、通知摘要、引用预览与导出文件中是否出现受限内容片段。
• 实现侧：绕过前端直接调用列表、详情、导出与索引接口，验证返回结果与权限判定一致。

反例做不到——评论区对无权成员隐藏了三条讨论，但通知摘要把其中一条的前两行原文推送了出去；做过头——为了绝对隔离，连"该内容存在但你无权访问"也不返回，用户收到的链接永远打不开也不知道为什么（见 C2-6）。

C2-5继承与例外可追溯必须¶

一句话：他为什么能看见这一份，要答得出来。

适用可见范围存在层级继承、群组授权或规则派生的产品。

规则当某主体对某对象的可见性来自继承、群组成员身份或规则派生时，该来源必须可被查明（见 collab.visibility.inheritance.trace）：是从哪一层继承的、经由哪个群组、被哪条例外放宽或收紧。禁止只呈现最终结果而无法追溯其成因。在层级上单独设置的例外必须在父层级发生变更时仍然可被发现，不得静默失效或静默扩大。收紧与放宽的叠加规则必须显式定义并与实际行为一致（取最严、取最宽或按层级优先之一以上），产品不得在不同入口采用不同的叠加结果。

边界条件本条不要求向所有成员展示完整的授权拓扑；查明的权利与查看范围本身的权限一致。它不规定采用哪种叠加规则，只要求这一选择被写明并被一致执行。

设计应用在权限面板里给每个主体加一行来源说明（"经由『产品组』继承自上级文件夹"），这一行常常比整套权限模型更能防止误配。移动对象到新父级时，把继承结果的变化在移动前呈现出来。

验证示例

• 用户侧：对一个继承层级较深的对象，让管理员说明某位成员的访问来源，记录是否需要跨多个界面拼凑。
• 实现侧：修改父层级权限后，核对子层级的例外是否按声明的叠加规则生效；检查不同入口（界面、接口、导出）的判定是否一致。

反例做不到——某人能编辑一份财务文档，权限面板只显示"可编辑"，无人知道这是三层之前某个群组带来的；做过头——把每个对象的完整授权推导树默认展开在共享面板上，日常共享变成阅读理解。

C2-6无权访问给出正常路径应当¶

一句话：让人知道该找谁要，而不是撞上一堵白墙。

适用成员可能访问到自身权限之外对象的产品。

规则成员访问无权对象时，产品应当给出可执行的下一步：说明访问被拒绝的性质、指出可申请的对象或责任主体、提供申请入口（见 collab.visibility.request.mode）。申请必须有明确的接收方与结果回执，禁止发出后无任何状态。当对象的存在本身属于受限信息时，产品可以采用不透露存在性的应答；此时禁止以模糊应答掩盖可授权而未授权的普通情形——两种应答的适用条件必须预先定义，不得逐次由实现随意决定。

边界条件本条不要求所有产品都提供访问申请功能；不提供时应当至少给出责任主体或联系路径。安全敏感场景采用不透露存在性的应答是正当的，其适用范围须被记录。

设计应用把"你没有权限"与"此内容不存在"的选择做成对象类别上的策略而不是逐条判断。申请入口里预填对象标识，让接收方不必反问"你说的是哪一份"。

验证示例

• 用户侧：点开一条同事转发的无权链接，记录用户能否在不另外发消息询问的情况下知道该找谁。
• 实现侧：核对两类应答的适用条件是否按预定义策略执行；验证申请提交后存在可查询的状态与结果回执。

反例做不到——点开链接只显示"403"，既不说是谁的，也不说能不能申请；做过头——对所有无权访问一律返回"内容不存在"，包括本可以一键申请的普通团队文档，导致成员反复怀疑链接发错了。

C2-7撤权覆盖在途动作与派生内容必须¶

一句话：门关上以后，旧页面和待发消息也不能继续放行。

适用权限可能在编辑、排队通知或外部集成运行期间变化的产品。

规则

1. 撤权生效后，服务端必须拒绝受影响主体的新读取与新提交；长连接、旧页面、后台队列和重连请求必须重新核对权限。客户端保留的旧授权不得作为继续写入的凭据。
2. 搜索、缩略图、评论摘录、摘要及待发送通知必须依据当前接收方权限过滤；生成时有权不代表发送时仍有权。
3. 产品必须分别表达撤权已受理、机制已生效及哪些外部副本无法收回。无法确认完成时保留处理中或未知，并阻止受影响的新动作，禁止先显示“全部收回”。
4. 被拒绝的本次输入必须按既定保存边界保护；恢复、导出与移交路径不得重新授予已失去的访问权。

相关配置：collab.visibility.revocation.policy。

边界条件无法远程抹除已被合法下载的副本；仍须阻断后续服务端访问，并明确本地缓存及离线访问的实际控制边界。

验证示例乙离线编辑期间撤销乙的权限，同时保留一条待发摘要；乙重连不得提交，摘要投递不得泄露内容，甲能查到撤权是否生效。

反例做不到——分享面板已显示移除成员，旧 WebSocket 仍接受其写入。做过头——为收回截图而要求管理员等待所有离线终端确认，撤权迟迟不生效。

3.3 C3 并发修改不吞输入¶

两个人同时改同一处，在多人产品里不是异常分支，是日常。这条原则管的是这件事发生时的裁决：策略是什么、发生前能不能看见、自动合并到哪儿为止、合不了时交给谁。冲突双方有各自的意图、权限与责任；裁决必须遵守预先声明的策略并保留贡献，不能仅用时间戳掩盖输入丢失。

C3-1并发策略事先声明并与行为一致必须¶

一句话：同时改会怎么样，是设计决定，不是运气。

适用同一对象可能被两名及以上成员同时修改的产品。

规则产品必须为每类可共同编辑的对象预先定义并发策略（独占锁定、先提交生效且保留被拒输入、后写覆盖并保留被覆盖内容且告知、按语义自动合并、保留双方输入交由裁决之一以上），并使实际行为与声明一致（见 collab.concurrency.policy）。任何策略下都禁止静默丢弃任一成员已被其本人认可的输入：采用先提交生效时，被拒绝的一方必须保有其内容并能重新应用；采用后写覆盖时，被覆盖的一方必须能发现差异并取回原贡献；采用自动合并时，合并结果按 C3-3 处理。策略在同一产品内因对象类型而异是允许的，但同一类对象上禁止出现不可预期的策略切换。

边界条件本条不规定应当选择哪种策略——不同内容类型的正确答案不同（结构化表单与自由文本的合适策略通常不同）。它不要求所有对象都支持同时编辑；选择独占锁定是合法策略，其要求见 C3-5。

设计应用按内容的语义而不是按技术便利决定策略：不同段落的新增通常可以合并，同一个数值字段、同一个收款方、删除与编辑的组合通常不能。短内容不天然比长内容安全——两个人同时改一个金额，比同时改两千字更危险。

验证示例

• 用户侧：让两名成员在同一对象上同时作出修改，观察结果是否与产品声明的策略一致，以及双方是否都能理解发生了什么。
• 实现侧：注入并发写入与时钟偏差，验证不出现静默丢失；核对各对象类型的实际策略与声明清单。

反例做不到——两人同时保存表单，后保存者覆盖前者，前者不知道自己的修改没了；做过头——为求稳妥对所有对象一律独占锁定，两个人连改不同段落都要排队。

C3-2正在被改的部分事先可见必须¶

一句话：别等我写完了才告诉我这块有人在写。

适用支持多人同时编辑同一对象的产品。

规则在已取得有效且获准呈现的占用事实时，该事实必须在其他成员开始修改该区块之前可被察觉（见 collab.concurrency.editing.indicator）。提示的定位粒度必须足以让人避开——定位到对象而不定位到区块，在长内容上不满足本条。

占用事实未知、或因隐私设置不可展示时，禁止呈现为"无人编辑"；此时产品仍须以 C3-1 声明的并发策略保护输入。感知提示不构成互斥：产品若承诺"不会发生同时编辑"，必须采用真实的互斥准入（见 C3-5），不得由提示推导互斥。匿名化的占用提示同样须评估可推断的身份暴露——在两人空间里，"有人正在改第三段"就是指名道姓。采用独占锁定的对象，锁定状态与持有人必须在尝试编辑前可见，禁止在用户输入完成后才告知内容已被锁定。本条呈现的是编辑活动的存在与位置，其粒度上限受 C1-3 约束。

边界条件本条不要求实时精确到字符位置；它要求的是提示出现的时机早于冲突产生。本条不要求消除传播竞态：两人几乎同时开始编辑而提示尚未传播到位，不构成本条的违反——该情形由并发策略承接。网络中断、对端信息不可得，或成员已按 C1-4 收敛自身可见性时，产品应当呈现该信息为未知而非无人编辑（见 C3-6）；隐私限制下不展示占用事实是合法边界，但必须如实呈现未知并继续保护输入；不得一面不提供有效提示，一面声称“已保证避开他人的编辑”。

设计应用把提示放在编辑入口而不是内容旁边——人是先点击再输入的，提示出现在点击的位置才来得及。对表单类对象，字段级的占用提示比整表的协作者列表有用得多。

验证示例

• 用户侧：让一名成员在长文档中段编辑，另一名成员从文档顶部滚动至该处并开始输入，记录后者在何时得知该处有人在改。
• 实现侧：验证编辑活动信息的传播延迟与提示时机；核对定位粒度是否达到可避让的程度。

反例做不到——两人各写了一段，保存时才弹出"检测到冲突"，此时两段都已经写完；做过头——只要有人的光标落在同一屏内就锁死输入框，正常协作被判为冲突。

C3-3自动合并有边界且结果可识别必须¶

一句话：合得拢不等于合得对。

适用采用自动合并策略的产品。

规则自动合并的适用范围必须按内容语义预先定义，禁止把"技术上能收敛"直接当作"业务上可合并"（见 collab.concurrency.merge.scope）。落在自动合并范围内的变更，其合并结果必须能被识别为合并产物：参与合并的各方必须能看出结果与自己提交的内容有何差异，并能更正（见 C3-4）。自动合并必须定义业务风险单元与可检测的不相容组合：同一原子值的并发修改、删除与依赖该内容的编辑、以及已定义的关联字段组，禁止未经既定裁决直接提交为权威结果。自由文本若不能可靠判定语义不相容，产品必须保留各方的原始贡献、使合并差异可被发现，并按用途在正式发布或提交之前进行相称的核对；禁止承诺"自动保证所有语义正确"。

"最终句子不是任何一方单独写过的"本身不构成违例——多人协作的正常产物往往就是新组合；本条禁止的是产生新的有害业务含义且未经裁决即成为权威结果。合并的发生必须被记录并可追溯到各方的原始贡献（见 C4-3）。

边界条件本条不要求把每次合并都呈现给用户确认——那会使实时协同编辑无法使用。它要求的是合并结果可被事后识别与更正，以及高风险组合被排除在自动范围之外。收敛性算法保证的是各副本最终一致，它不保证一致的那个结果是任何一方想要的，这一区别不得在产品文案中被混淆。

设计应用把自动合并范围写成一份显式清单（可合并：不同段落的新增、不同字段的填写、两人分别补充不同的背景事实而组合成此前无人完整写过的一段话；不可自动合并：同一原子值的并发修改、删除与编辑的组合、有依赖关系的字段组）。配置记录含对象类型、风险单元、检测依据、允许的组合、清单外的处理路径、正式生效点与验证用例。给合并产物一个可回看的差异视图，而不只是一条"已同步"。

验证示例

• 用户侧：构造两人分别修改同一句话不同部分的场景，检查结果是否成为一句谁都没写过的话，以及双方能否发现。
• 实现侧：核对自动合并范围清单与实际合并行为；验证合并记录能还原各方原始贡献。

反例做不到——两人分别把"下周三上线"改成"下周五上线"和"本周三上线"，系统合并出"本周五上线"并显示同步完成；做过头——任何两人先后编辑同一文档都进入人工合并界面，实时协作退化为逐次审批。

C3-4冲突交给能裁决的人必须¶

一句话：冲突不该由最后一个提交的倒霉蛋独自决定。

适用可能产生需要人工裁决的冲突的产品。

规则无法自动裁决的冲突必须保留各方内容，并交由对该内容有权限且有责任的主体处理（见 collab.concurrency.arbiter）。禁止默认把裁决责任分配给最后一个提交的人，除非该人正是责任主体；裁决者不具备判断依据时（不了解另一方的意图、无权查看另一方的内容），产品必须提供联系或转交路径，而不是要求其在无依据的情况下二选一。裁决结果必须让被影响的各方可知，禁止让贡献被否决的一方在无告知的情况下发现自己的内容消失。冲突处于待裁决状态期间，各方内容必须均可访问，不得只保留其中一份。

边界条件本条不要求产品实现审批流程或指派仲裁人；在无明确责任主体的对象上，把裁决交给发起方并同时告知另一方是可接受的。它禁止的是把裁决伪装成一次普通的保存冲突提示。

设计应用把裁决界面做成"两份内容并列 + 各自作者 + 可联系"，而不是"保留我的／保留他的"两个按钮——后者在裁决者不了解对方意图时是无效选择。责任主体的解析见 C5-1。

验证示例

• 用户侧：制造一次真实冲突，观察裁决界面出现在谁那里、他是否具备作出选择的信息、另一方在多久之后得知结果。
• 实现侧：核对裁决者的解析规则与责任主体字段是否一致；验证待裁决期间双方内容均可取回。

反例做不到——实习生最后一个保存，系统弹出"保留你的内容还是服务器内容"，他选了自己的，架构师两小时的修改就此消失且无人被告知；做过头——每次冲突都强制走一轮跨部门确认，简单的文字冲突要等两天。

C3-5独占锁定有持有人有期限必须¶

一句话：锁上的人下班了，文件不能就此锁死。

适用采用独占锁定或签出机制的产品。

规则每一个锁必须有可见的持有人、获取时间与有效期（见 collab.concurrency.lock.ttl）。禁止存在无期限且无解除路径的锁：产品必须提供至少一条强制解除路径，其触发条件（超时、持有人离线、责任主体或管理员操作）必须预先定义并对成员可知。强制解除不得删除已经持久化的草稿或主动清空持有人的本地输入。产品必须说明草稿保存的位置、保留边界与取回条件；仅存于离线终端的输入不得被宣称已由服务器备份。持有人重连后先验证当前编辑权与锁凭据，再把原输入作为待处理草稿恢复，禁止以过期锁覆盖他人成果。取回仍受当前权限约束，撤权后不得借恢复草稿重新读取受限源内容。锁的获取与解除必须被记录并可追溯。持有人所在账号被停用或移出（见 C5-3）时，其持有的锁必须进入可解除状态。

边界条件本条不要求锁具备短超时——长有效期在某些工作流中是正确的；它要求期限存在、可见且有解除路径。它不适用于毫秒级的内部并发控制，只适用于对用户可见、会阻止他人工作的锁定状态。

设计应用把"谁锁的、什么时候锁的、还剩多久、怎么联系他"四件事放在同一处呈现。解除前提示影响；可连接时通知持有人，离线时保留可查事件。在权限允许范围内保留已保存的私有草稿，不能声称已取回只存在于离线终端的内容。

验证示例

• 用户侧：让持有人在锁定状态下关机，观察其他成员在多久之后能继续工作，以及需要走什么路径。
• 实现侧：执行强制解除后，核对原持有人在权限允许范围内取回已保存草稿；检查离线终端未备份输入的限制已说明；核对锁记录的完整性。

反例做不到——同事签出了一份设计源文件然后休了两周年假，团队只能新建一份副本重来；做过头——锁在五分钟无操作后自动释放，正在思考的人一回神发现内容已被别人改了。

C3-6收敛承诺与他人可见分开表述应当¶

一句话："我看到的是最新的"和"我改的别人看到了"是两件事。

适用存在同步延迟或离线编辑能力的多人产品。

规则产品应当分别表达入站（本人所见是否已包含他人的最新变更）与出站（本人的变更是否已持久化、是否已被服务端接受、是否已分发到目标范围）这两组状态，不以单一的"已同步"同时承担两者（见 collab.concurrency.convergence.presentation）。本人的提交被接受不证明本人已收到他人的并发或较早变更——这两件事由不同证据支撑。各维度均须有"未知"与"失效"语义；对端接收回执只能证明相应客户端接收，禁止据此表述为“所有人都已看到”。本人的查看证据仅按 C1-5 获准的记录提供，不从分发回执推断。某次同步的对象快照、更新时间、回执与目标成员集合是运行事实，不由配置写入。他人变更不可得时（网络中断、对端离线），禁止把此状态呈现为无人编辑或内容为最新（见 C3-2）。离线期间作出的修改在重新连接时的处理方式必须与 C3-1 声明的策略一致，且禁止把离线期间未见到的他人变更静默覆盖。

边界条件本条不要求为每次按键呈现两种状态；聚合到区块级或会话级是可接受的。它不要求给出延迟的具体数值承诺——那由产品按其架构测定并记录依据。"收敛"是各副本执行同一组操作后最终一致这一技术性质，不是任何人已经读到的保证，两者不得在文案中混用。

设计应用给"未连接"设计一个明确的编辑态提示，而不是让界面看起来一切正常。重新连接后，把"你离线期间他人做了什么"作为一次可回看的呈现，而不是直接把结果合并进来了事。

验证示例

• 用户侧：断网后继续编辑，恢复连接，记录用户能否说出哪些是自己的改动、哪些是别人在这期间的改动。
• 实现侧：验证断连状态下的编辑活动指示不呈现为"无人编辑"；核对离线变更的合并路径与声明策略一致。

反例做不到——离线两小时后重连，界面只显示"已同步"，用户不知道自己覆盖了别人的三处修改；做过头——每一次微小延迟都弹出同步状态提示，编辑过程被状态条淹没。

3.4 C4 个人操作有明确作用范围¶

在单人产品里，一次操作的后果只落在操作者自己身上；在共享空间里，同一个动作有别人在承受。这条原则管的是一个人的一次操作在共享对象上产生的效果、这个效果的边界，以及它归谁。本领域最容易做错的一条在这里：撤销在单人产品里等于"回到上一个状态"，在多人产品里这个等式不成立——上一个状态里有别人的工作。

C4-1撤销撤的是自己那一步必须¶

一句话：撤销是"撤销我做的"，不是"撤销最后一步"。

适用在共享对象上提供撤销能力的产品。

规则共享对象上的撤销必须解析为撤销执行撤销的这名成员在该对象上的上一步（或指定的某一步）操作，禁止实现为回退该对象的全局最后一次变更（见 collab.action.undo.scope）。撤销必须选中执行者本人在已声明撤销上下文中的贡献，禁止选中他人的全局最近变更；实现方式不限——按成员隔离的撤销历史、按操作来源过滤或等价机制均可，本条不规定数据结构或存储键。产品必须预先声明"本人"这一操作来源的边界：同一成员的多个标签页、代为执行的操作与 Agent 后续改写各自是否计入。撤销的作用对象与作用范围必须在执行前可解析。当本人没有可撤销的操作时，撤销必须无效果并如实说明，禁止改为撤销他人的最近变更。

边界条件本条不规定撤销栈的深度，也不要求撤销跨会话保持。它不排除产品另行提供"回退到某个历史快照"的能力——那是历史恢复，不是撤销，两者禁止共用同一入口与同一快捷键。本人的某一步无法在不影响他人的前提下单独撤销时，按 C4-2 处理。

设计应用先写清"什么算本人的这一步"——是按成员、按会话、还是按操作来源过滤；这是本条在实现上的核心，具体用哪种机制由产品决定。对结构性操作（移动、重排、批量指派），要能回答"撤销它会把哪些人的后续动作一起带走"，答不出来就先按 C4-2 呈现范围。

验证示例

• 用户侧：成员甲作出一次编辑，成员乙随后在同一对象作出编辑，然后甲按撤销，检查被撤销的是甲的编辑还是乙的编辑。
• 实现侧：核对撤销的选择规则是否以执行者本人的贡献为对象、上下文边界是否已声明；验证无自身可撤销操作时的行为是"无效果并说明"。另构造甲乙交错编辑、本人无历史、同一人两个标签页、代为执行、Agent 后续改写五种情形，逐一核对取回结果。

反例做不到——新人在共享白板上按了两次撤销，把资深同事刚画完的整块流程图撤没了，而且没人知道是谁干的；做过头——为了绝对不影响他人，任何在他人有后续操作之后的撤销一律禁止，用户连自己刚打错的字都退不回去。

C4-2撤销不静默回退他人成果必须¶

一句话：要连别人的改动一起退，先说清楚再退。

适用共享对象上的撤销可能影响他人后续变更的产品。

规则当本人的某一步操作与他人的后续变更存在依赖，使得撤销该步必然影响他人变更时，产品必须在执行前说明将被影响的范围（涉及哪些变更、来自哪些成员），并取得执行者的确认；禁止静默连带回退（见 collab.action.undo.cascade）。发生连带回退后，被影响成员必须能获知这一事实并取回其被回退的内容。产品选择不支持此类撤销时，必须如实说明不支持的原因与可行的替代路径，禁止表现为已撤销但实际未生效。

边界条件仅在撤销目标存在他人后续依赖、或无法排除该依赖时提示影响；不能以对象曾有他人编辑为由拦截所有撤销。没有连带影响时直接执行。实现不能安全撤销时，保留当前成果并提供更正或取回路径，不要求采用某种依赖分析算法。

设计应用把提示写成后果而不是术语——"撤销这一步会同时移除李四之后添加的两条评论"，而不是"存在依赖冲突"。被回退方的取回入口应当出现在其自己的变更记录里，而不是要求其到回收站里翻找。

验证示例

• 用户侧：构造甲的操作被乙的后续操作依赖的场景，让甲执行撤销，检查提示是否说明了影响范围，乙是否得知。
• 实现侧：验证连带回退的内容可由被影响成员取回；核对无他人后续变更时不产生多余确认。

反例做不到——撤销一次表格结构调整，把别人在新列里填的二十行数据一并清空，界面只显示"已撤销"；做过头——只要对象上有过任何他人操作，每次撤销都弹出一段冗长的影响分析让用户勾选确认。

C4-3每次变更有可解析的作者必须¶

一句话：这行字是谁写的、是人写的还是 Agent 写的，查得到。

适用多名成员可修改同一对象的产品。

规则共享对象上的每一次变更必须可解析到作者主体，并在声明的保留期内可查（见 collab.record.authorship、collab.record.retention.ttl）。作者主体必须区分至少三类：成员本人操作、由他人代为执行的操作（代理、模拟登录、管理员代操作）、由自动化或 Agent 执行的操作；自动化或 Agent 产物必须标示其执行来源，代为执行的操作必须同时记录实际执行者与被代表者。作者的主体归属禁止在责任交接、成员改名或账号停用时被改写（见 C5-4）。保留期届满后不再可查是允许的，但该期限必须预先声明，不得表现为"从未记录"。

边界条件本条不要求向所有成员展示完整变更历史——查看历史的权限按 C2 判定。它不要求记录每一次按键：记录的粒度应当与撤销单位和裁决需要相称，与 C1-3 的感知粒度上限并行适用（变更记录是给内容用的，不是给评价人用的，用途约束见 C1-6）。

设计应用把"某某（通过自动化）"和"某某（由管理员代操作）"做成与普通署名可区分的呈现，而不是都显示成同一个名字——事后追查时，这个区别常常就是全部问题所在。

验证示例

• 用户侧：让管理员代某成员执行一次修改，检查其他成员看到的作者是谁，能否看出这是代操作。
• 实现侧：核对三类作者主体是否分别记录；验证成员改名或停用后历史作者的主体归属未被改写。

反例做不到——集成机器人以某个共用账号的名义批量修改了两百条记录，历史里全部显示为该账号，无从知道是哪次自动化触发的；做过头——把每一次光标移动与选中都写入变更历史，历史面板长到无法使用（这同时违反 C1-3）。

C4-4作用范围在执行前显式必须¶

一句话：按下去之前就知道这是改我自己的还是改所有人的。

适用存在不同成员作用范围的操作的产品。

规则一次操作是仅对本人、指定成员还是全体成员生效，必须在执行前可被操作者知道（见 collab.action.effect.scope）。共享视图与个人视图的默认归属必须显式定义：改变筛选、排序、分组、折叠、显示密度、列宽等呈现状态时，产品必须明确该改动落在何处，禁止让两类改动共用同一入口而结果不同（个人状态的默认归属见 C6-3）。影响全体的结构性操作（重命名、移动、改变层级、批量修改、套用模板、变更工作流状态）必须在执行前给出其作用对象数量与影响范围。禁止以"操作后可撤销"为由省略作用范围的说明——撤销在多人场景下不是无代价的（见 C4-2）。

边界条件本条不要求为每次操作弹出确认；说明可以是入口处的常驻标识（"正在编辑共享视图"），确认的分级要求见 C4-5。它不要求列出受影响的全部对象，给出数量与类别即可。

设计应用把"共享视图"与"我的视图"做成两个可见的、始终显示当前所在位置的状态，而不是一个隐藏在菜单深处的开关——大部分误改共享视图的事故，都是因为人不知道自己此刻在哪一边。

验证示例

• 用户侧：让成员在看板上调整筛选条件，记录他是否知道其他人的看板是否也变了，以及他从哪里得知。
• 实现侧：核对每类呈现状态的归属定义与实际存储位置一致；验证结构性操作在执行前给出影响数量。

反例做不到——成员为了找一张卡片改了筛选器，全组三十个人的看板一起变了，他自己也不知道；做过头——每次调整列宽都弹窗询问"这次改动应用于你自己还是所有人"。

C4-5共享对象的破坏性操作加严必须¶

一句话：删自己的东西和删大家的东西，不是一回事。

适用允许删除、归档或使他人正在使用的对象失效的产品。

规则破坏性操作的后果分级必须把该对象是否对他人可见、是否被他人引用、是否有他人正在其中工作作为分级输入（见 collab.action.destructive.level）。删除或归档存在他人贡献的对象时，必须在执行前说明将影响到哪些成员的内容；禁止把他人的贡献随对象一并不可恢复地移除而不给出该贡献的保留或导出路径。被删除对象的引用方（链接、嵌入、任务依赖）必须能得知该对象已不可用，禁止呈现为空白或静默失效。对他人正在编辑的对象执行删除，必须先向可连接的编辑界面呈现失效提示并保护输入；未确认界面送达的会话必须停止接受其后续共享写入，重连时先核对状态再继续。送达不证明本人已经阅读；紧急撤权不等待用户确认。

边界条件本条不要求禁止删除共享对象，也不要求所有删除都走审批。它不改变对无他人贡献、无他人引用对象的一般处理。数据保留与合规删除请求（如个人信息删除）按其自身规则执行，其与本条的"贡献保留"冲突时以适用法规为准。

设计应用把"这份文档里有三位同事的十七条评论"写进删除确认，比"此操作不可撤销"有用得多。给引用方一个明确的失效呈现（"所引用的内容已被删除"），而不是让链接静默失活。

验证示例

• 用户侧：删除一份有多人评论与他人引用的文档，检查删除者是否被告知影响范围，评论者与引用方是否得知。
• 实现侧：核对分级输入是否包含可见性、引用与在线编辑状态；验证他人贡献存在可取回路径。

反例做不到——项目归档时连同五名成员的全部讨论一并清除，成员事后既收不到通知也找不回内容；做过头——删除任何一条自己刚建的空白卡片都要求填写理由并等待管理员审批。

C4-6批量操作不产生等量打扰应当¶

一句话：改一百条不等于给人发一百条通知。

适用提供批量操作且操作会产生对他人的提醒的产品。

规则一次批量操作对每位受影响成员产生的提醒应当被聚合为可理解的整体，而不是按受影响对象数量逐条发出（见 collab.action.batch.notice）。聚合后的提醒仍必须让接收者看出与自己相关的具体项，禁止聚合到"有 47 项更新"这种无法判断是否需要处理的程度。禁止把提醒的产生作为操作的静默副作用：执行批量指派、批量状态变更、批量 @ 时，操作者应当在执行前知道这次操作会打扰到哪些人（见 C4-4）。

边界条件本条不要求抑制个别关键提醒（如被指派了需要立即处理的任务）；紧急例外必须预先定义事件条件、可触发的主体与接收方知情方式。它不禁止提供"不通知本次变更"的选项，但该选项不得成为规避 C2-2 范围变更告知的手段。

设计应用把"这次操作将通知 12 人"放在批量操作的确认里。给受影响者的聚合提醒保留可展开的明细，让人能在一屏内判断哪些需要自己动手。

验证示例

• 用户侧：批量把三十张卡片指派给同一人，记录该人收到几条提醒、能否快速看出哪些需要今天处理。
• 实现侧：核对批量路径是否复用了单条操作的提醒逻辑；验证聚合后的提醒仍包含可判断的明细。

反例做不到——批量调整三十张卡片的截止日期，被指派人收到三十条推送；做过头——把所有变更都聚合成每日一条摘要，紧急指派也要等到第二天早上。

C4-7重复与部分成功有独立结果必须¶

一句话：没收到回执，不等于没做过；做了一部分，要说清哪部分。

适用发送评论、邀请、批量修改、责任转移等可能重试或部分完成的协作操作。

规则

1. 系统必须区分操作请求、实际生效和结果回执。超时或回执丢失不得直接解释为未执行；查询到实际结果后才能判定成功或失败。
2. 重复提交同一操作必须识别其操作标识，或以等效机制防止重复评论、重复邀请、重复责任转移等副作用。结果未知且不能证明安全重试时，必须提供核对或人工处理入口，禁止自动整批重放。
3. 批量操作必须按对象记录成功、失败、未执行与未知，展示有权查看的明细；部分完成不得呈现为全部成功。重试仅处理已确认可重试的项，并重新核对当前权限及对象快照。
4. 同一业务事件的多通道提醒必须关联到同一事件，失败后的补发不得绕过接收方的静音和投递权限。

相关配置：collab.action.retry.policy、collab.action.delivery.policy。

边界条件本条不要求跨所有系统实现绝对一次投递；要求重复可识别、结果不虚报、未知不盲重试。

验证示例批量改派十项，三项成功后断连；重试前查询各项结果，成功项不重复改派或通知，未知项继续核对。

反例做不到——用户见“发送失败”再点一次，评论和邮件各出现两份。做过头——网络稍有延迟就禁止所有协作操作且不提供查结果入口。

3.5 C5 责任有归属且可交接¶

参与不等于负责。一份文档有八个协作者，不回答"这件事现在归谁"；一张任务卡上有五个关注者，不回答"谁在推进它"。这条原则管的是责任与决定的归属，包括讨论结束是否形成有效决定；责任主体这个字段：它必须存在、必须有答案（包括"无人负责"这个合法答案）、必须能在人之间转移，并且必须在人离开时有明确去向。它不管组织怎么分工——那是管理制度，不在本规范范围内；它管的是产品里的责任表达不制造出无人负责却看不出来的状态。

C5-1当前责任主体可解析必须¶

一句话：参与者名单不回答"现在归谁"。

适用存在需要有人推进或维护的对象（任务、审批、内容、空间）的产品。

规则每一个需要有人负责的对象在任何时刻必须能解析出其当前责任主体，或明确解析为无人负责（见 collab.ownership.assignee）。禁止以参与者列表、关注者列表、最近编辑者或创建者代替责任主体。"无人负责"必须是一个可被查询与呈现的显式状态，不得表现为字段为空且无人可见。责任主体为群组时，必须说明该群组内的认领规则（先到先得、轮值、需指定之一以上），否则群组责任等同于无人负责。对象的责任主体与其可见范围是两个维度，禁止相互推定（能看见不等于负责，负责不等于能看见全部）。

边界条件本条不要求所有对象都有责任主体——纯参考性内容记为不适用即可。它不规定责任主体的数量上限，但多主体时必须能回答"其中谁的动作构成推进"。

设计应用把"未指派"做成一个可被筛选、可被统计的正常状态，而不是一个空白。定期让"无人负责且长期未变更"的对象浮现出来——这类对象是协作系统里最常见的静默失效。

验证示例

• 用户侧：随机取二十个进行中的任务，让团队说出各自的当前责任人，记录答案不一致或答不出的比例。
• 实现侧：核对责任主体字段是否独立于参与者与创建者；验证"无人负责"可被查询与筛选。

反例做不到——任务卡上有六个头像，谁都以为别人在做，两周后无人推进也没人发现；做过头——要求每个文档、每条评论都必须指定一名责任人才能创建。

C5-2交接是双方事件必须¶

一句话：派下去不等于接下来。

适用允许把责任从一个主体转移到另一个主体的产品。

规则责任转移必须记录接收方的知悉证据与当前责任的实际生效状态，禁止把单方面的指派动作直接呈现为交接已完成（见 collab.ownership.handoff.mode）。产品必须分别表达四个事实维度：已发起／已送达或可访问／知悉证据状态／是否已承接。送达、客户端展示、阅读回执、本人确认与承接是不同的证据，不得互相代替：未取得有效知悉证据时显示"知悉情况未知"，禁止据此断言"尚未查看"；已知悉也不自动等于已承接。采用不需要接收方确认的指派模型时，必须预先定义责任生效规则，并使"知悉情况未知"可被发起方与责任查询者看到。阅读记录被关闭时（见 C1-5），可由与该次交接绑定的显式确认或履行行为证明承接，禁止为此重建通用的已读记录。接收方拒绝或长时间未取得知悉证据时，责任必须回到明确状态（退回发起方、回到无人负责或按预定义规则转交），禁止停留在既不属于发起方也不属于接收方的悬空状态；该回落要求适用于全部指派模型，含单方指派。拒绝、撤销、被再次改派、到期回落、重复确认与针对已失效请求的确认，其各自的效果必须预先声明；责任的解除只按当前有效的交接请求标识判断，针对已被改派请求的确认不承接新责任。采用需承接的模型时，承接前保留原责任或明确的临时责任人；采用单方指派时按预先声明的时点转移责任，但不得把该生效事实表述为接收方已知悉或已承接。

边界条件本条不要求实现确认式指派——很多团队的工作方式不适合逐次确认；它要求的是知悉证据不足不能被隐藏，也不能被改写成未查看。系统按规则自动分配（轮询、负载均衡）时，同样适用知悉要求。

设计应用把指派后的默认呈现从"已指派给李四"改成"已指派给李四 · 知悉情况未知"——不要写成"尚未查看"：没有回执只说明产品没有拿到证据，不说明人没看。

验证示例

• 用户侧：把一个任务指派给一位当天休假的成员，观察发起方在界面上看到的状态，以及一周后该任务的归属。
• 实现侧：核对四种状态是否分别存储与呈现；验证长时间未取得知悉证据时的回落规则确实执行。另构造：关闭已读记录后从通知获取任务、明确承接、过期后承接、两人同时改派、被停用后确认——任一缺回执的情形都不得显示"尚未查看"，针对已失效请求的确认不得接受新责任。

反例做不到——把任务指派给已经离职半个月的同事，看板上一直显示"进行中 · 负责人张三"；做过头——每次指派都要求接收方点确认，接收方在开会时任务就一直卡在待确认。

C5-3离开与移交对称必须¶

一句话：人走了，他名下的东西不能就地失联。

适用成员可能退出、被移除或账号被停用的产品。

规则成员退出、被移除或账号停用时，其名下的责任、内容与权限必须各自有明确去向：转移给指定主体、转为组织或空间所有、归档、或明确记为无主（见 collab.ownership.offboarding）。禁止在成员消失后使其名下内容不可访问且无处置路径，也禁止由系统静默把所有权转给某个未被告知的主体。处置必须可被查明：谁在何时把哪些对象转给了谁，须在保留期内可查（见 C5-4）。成员被移除时其持有的锁必须进入可解除状态（见 C3-5），其未完成的交接按 C5-2 的回落规则处理。权限终止不得以移交完成为前提；失败对象进入受限且可查询的保管状态，由明确责任人处理。成员本人产生的、属于其个人的内容（私人草稿、私人笔记）与属于共享空间的内容必须分别处置，前者的默认处置不得是并入共享空间（见 C6-1）。

边界条件本条不规定处置的具体归属——那由组织策略与适用法规决定；它要求处置路径存在、被执行且可查。它不豁免个人信息删除等法定义务；这些义务与"内容保留"冲突时，以适用法规为准，冲突的存在应当在产品文档中说明。

设计应用把离开流程做成一份清单而不是一个删除按钮：名下责任 N 项、独占持有 M 项、私人内容 K 项，逐类给出处置选项。正常退出时预先检查可处置的对象；紧急撤权先终止访问。移交失败时保留受限保管状态、处理责任人与下一步，不扩大私人内容受众。

验证示例

• 用户侧：停用一个持有多项任务、多个独占锁与若干私人草稿的账号，检查每一类的实际去向与是否可被查明。
• 实现侧：核对处置记录的完整性；验证移除后不存在既不可访问又无处置入口的对象。

反例做不到——同事离职，他建的十几个共享文档变成无所有者状态，谁都改不了权限也删不掉；做过头——成员一被移出项目组，其全部历史评论与变更记录一并删除，讨论上下文消失。

C5-4责任变更不改写历史归属必须¶

一句话：换了负责人，以前是谁写的还是谁写的。

适用记录变更历史或贡献归属的产品。

规则责任主体变更、成员改名、账号合并或停用时，已发生变更的作者归属禁止被改写为新的责任主体（见 C4-3、collab.record.authorship）。历史记录中的成员标识在其显示名变化后应当解析到同一主体，但禁止把一个人的历史贡献重新署名给另一个人。因法定删除请求或组织策略必须移除历史中的个人标识时，处置方式必须是明确的匿名化或移除，并使该处置本身可被识别，禁止以替换为他人姓名的方式实现。责任交接的时点必须可查，使"这次变更发生在谁负责期间"可以被回答。

边界条件本条不要求永久保留历史——保留期按 collab.record.retention.ttl 声明。它不禁止在界面上突出当前责任主体，只禁止用当前责任主体覆盖历史作者。

设计应用把成员标识与显示名分开存储，这是本条在实现上的前提。给"该成员已离开"设计一个专门的历史呈现，而不是把名字换成空白或换成接手人。

验证示例

• 用户侧：把一个有多人历史贡献的任务转交给新负责人，检查历史记录中此前各次变更的作者是否仍为原作者。
• 实现侧：执行成员改名、账号停用与责任交接后，逐一核对历史作者字段；验证匿名化处置可被识别。

反例做不到——任务转交后，历史里之前所有操作的执行人都显示成了新负责人，追责时完全失真；做过头——为保历史完整，离职成员的姓名与联系方式在系统内永久保留且无任何处置路径，与个人信息处理要求冲突。

C5-5外部与临时成员的边界显式应当¶

一句话：访客什么时候到期，到期后他留下的东西归谁。

适用允许组织外成员、访客或临时权限参与协作的产品。

规则外部与临时成员的参与范围、有效期与到期后的处置应当在授予时被显式定义（见 collab.ownership.guest.policy）。临时权限必须有明确到期点；长期外部授权必须有复核责任人与复核周期。到期或退出后，其此前产生的内容与其对共享内容的贡献必须有明确归属（保留并标注来源、转为组织所有、或按约定移除），且该归属对内部成员可知。外部成员在场时，产品应当使内部成员可察觉该事实——在有外部参与者的空间里，内部成员对"谁能看到这句话"的判断会系统性偏乐观。

边界条件本条不要求区分所有成员类别；不区分内外的产品记为不适用。它不规定有效期的长度——由产品与组织按其风险测定并记录依据。本条内部的强度不一："临时权限到期、长期外部授权复核"与"贡献归属须明确"是不可关闭的底线；"外部参与对内部成员可察觉"是应当级，确有理由偏离时记录理由与替代做法。长期的外部合作身份不因被归入外部主体而一律按临时访客处理——其期限与复核方式按其实际关系声明。

设计应用把外部参与者的标识做成持续可见的呈现（而不只是在成员列表里的一个小标签），尤其在评论、提及与通知的上下文里。到期前给责任主体一次续期或处置的机会，而不是到期直接失联。

验证示例

• 用户侧：邀请一名外部访客加入一个讨论，让内部成员回答"现在这个讨论有谁能看到"，记录答对的比例。
• 实现侧：核对临时权限是否存在有效期与复核；验证到期后其内容的归属按声明执行。

反例做不到——两年前一次外部评审临时开的账号至今有效，仍能打开当时那批文档的当前内容；做过头——外部成员每次发言前都要求内部成员确认，评审会开不下去。

C5-6讨论、解决与决定分别留痕必须¶

一句话：结束讨论不等于大家同意，批准只覆盖当时的内容。

适用提供评论线程、建议、评审、投票或共同决策的产品。

规则

1. 评论必须绑定稳定的对象和内容锚点；锚点失效时保留原有上下文或明确标注无法定位，禁止静默挂到其他内容。保留与取回受当前访问权限约束。
2. 线程必须区分开放、已解决、重新打开、被删除或受限；解决动作必须可追溯到操作者及时间，有权成员必须有重开或提出异议的路径。解决不删除分歧，也不自动证明所有参与者同意。
3. 当批准、投票或确认将触发后续执行时，产品必须定义有资格的决定者、所需条件、所针对的对象快照与范围；无回复、已读、点赞和关闭线程禁止被自行换算成批准。若表态本身就是正式投票，必须在参与前明确其含义。
4. 批准后其覆盖内容或关键条件改变时，必须按预先定义的失效条件重新核验；过期决定不能自动批准新增内容。自动摘要必须标识来源、保留未决事项，且不得把少数意见改写成一致同意。

相关配置：collab.ownership.discussion.policy、collab.ownership.decision.policy。

边界条件不要求所有讨论走投票或审批；普通聊天无需设置决策门槛。需要正式决定时才启用相应规则。

验证示例乙对某段提出异议后甲删除该段，线程仍能说明原目标；甲标记解决不显示全员同意；批准后改动关键内容须重新核验。

反例做不到——任务讨论的三个点赞被自动记为三人批准，原反对意见从摘要消失。做过头——修正一个错字也需要所有评论者重新签字。

3.6 C6 共享空间里有私人余地¶

如果一个人敲下的每一个字立刻对全组可见，他就不会去尝试。这条原则管的是共享工作区里属于个人的那部分状态：还没写完的草稿、还没想好的评论、只想给自己看的筛选条件、以及那句"我先试一下"。它规定这些状态什么时候开始对别人可见，以及成员如何控制自己的注意力、跟随行为和参与范围。它与 C4 的差别在规范对象：C4 管我的操作对别人产生了什么效果，C6 管我的状态什么时候开始被别人看见。

C6-1未定稿默认不外发必须¶

一句话：没写完的东西，别人不该已经看见了。

适用提供内容创作、评论或提交能力的多人产品。

规则未完成的输入必须默认只对本人可见：草稿、未发送的评论、未提交的编辑、未发布的更改（见 collab.private.draft.default）。从未定稿转为共享可见必须是一次显式动作，禁止以自动保存、失焦、超时或页面关闭作为发布动作。产品提供实时协同编辑（内容随输入即时对他人可见）时，该性质必须在进入编辑前可被知道，且必须存在至少一条产出未定稿内容的路径。"私人未定稿"的判据是内容的实际访问范围仅限作者本人：建议、分支或副本只有在其访问范围确实仅作者时才满足本条；共享的建议模式满足"不直接改变正式内容"的需求，不满足私人草稿的需求——它对所有者可见，且可被接受或拒绝。未定稿内容禁止进入面向他人的搜索、通知、摘要与导出（见 C2-4）。

输入保留：产品必须声明私人草稿的保存位置与恢复边界；页面切换、发布失败或权限变化不得主动清空已保存输入。无法持久保存时，必须在离开编辑前提示风险并提供受权限约束的保留路径，禁止用“已保存”掩盖保存失败。

边界条件本条不否定实时协同编辑——它是这类产品的核心价值；它要求的是这一性质被知道，并且不是唯一可用的方式。协作过程中他人可见的编辑活动指示（C3-2）不属于本条所指的内容外发。

设计应用把"草稿"与"已发布"做成内容自身的状态而不是两个不同的存放位置——放在不同位置会导致人把草稿留在原地忘记发布。对评论这类高频未定稿，保留跨会话的本地草稿，并明确它没有被发出去。

验证示例

• 用户侧：在评论框输入一半后关闭页面，检查该内容是否已对他人可见，以及重新打开时是否还在。
• 实现侧：核对未定稿内容是否被排除在搜索索引、通知摘要与导出之外；验证不存在以超时或失焦触发的发布路径。用两个账户逐一检查建议、分支、副本、通知、搜索与导出六条路径：在一个账户写入未发布内容后，另一账户不得由任一路径取得该内容。另取一项可撤销的共享筛选操作，核对它未被判为合格的探索路径。

反例做不到——评论框内容随输入实时对全组可见，一句话说了三遍改了两次全被人看在眼里；做过头——所有编辑都必须先写在私有草稿里再手动发布，实时协作能力形同虚设。

C6-2探索性操作有不影响他人的路径必须¶

一句话：想试一下，不必先惊动所有人。

适用共享对象上的修改会立即对他人生效的产品。

规则产品必须提供至少一条在共享对象上进行探索性修改而不立即影响他人的路径：个人视图、建议模式、分支或副本、沙盒或预览之一以上（见 collab.private.sandbox.mode）。禁止把"直接修改共享态"作为尝试某个改动的唯一可行方式。路径是否合格，按它是否产生他人可见的内容、通知或共享状态变化分别验证；"该操作可被完全撤销"不构成合格的探索路径——可撤销的共享筛选或结构变更在撤销之前已经改变了别人所见。探索性修改转为对他人生效必须是显式动作；探索被放弃时，禁止留下部分生效的结果。探索路径本身的存在必须在共享对象的编辑入口处可被发现，禁止只存在于文档中而在界面上无迹可寻。

边界条件本条不要求实现分支与合并——对多数产品，一个仅自己可见的预览即可满足要求；建议模式只有内容、活动通知和共享状态都不向他人暴露时才满足。它不适用于结构上不可能有私有中间态的对象（如已明确即时公开的实时投票结果），此类对象记为不适用并说明理由。

设计应用按修改的代价选择路径：改一个数字用个人预览就够，改一套模板或一个工作流需要副本。把探索路径的入口放在编辑入口旁边——放进菜单第三层等于没有。

验证示例

• 用户侧：让成员尝试"看看把这一列去掉是什么效果"，记录他实际采用了什么方式、是否影响了别人。
• 实现侧：验证探索性修改在放弃后不残留部分结果；核对探索路径的入口可发现性。

反例做不到——想看看换个分组方式好不好看，只能直接改共享看板，改完发现不好又改回来，全组的界面跳了两次；做过头——任何修改都必须先建分支再发起合并请求，改一个错别字要走三步。

C6-3个人视图不改变他人所见必须¶

一句话：我折叠了一列，不该把别人的屏幕也折了。

适用提供筛选、排序、分组、折叠、缩放或显示密度等呈现控制的多人产品。

规则成员对呈现状态的调整必须默认只作用于其本人（见 collab.private.view.ownership）。改变共享呈现状态必须是与个人调整可区分的显式动作，并按 C4-4 在执行前说明其作用范围。共享呈现状态被改变时，正在查看该视图的其他成员必须能察觉发生了变化，禁止让他人的界面在无任何提示的情况下改变。产品同时提供个人视图与共享视图时，当前所处的视图必须持续可见（见 C4-4 的设计应用）。

边界条件本条不禁止提供共享视图——共享视图在多数团队工具中是必要的；它规定的是默认归属与切换的显式性。因数据本身变化导致的呈现变化（新增了一条记录）不属于本条所指的呈现状态改变。

设计应用把"共享视图"设为需要主动进入的模式，把个人调整设为默认——反过来做的产品，每一次误操作都会波及全组。给共享视图的改动加上作者与时间，让人知道界面为什么变了。

验证示例

• 用户侧：让一名成员调整筛选条件，检查其他成员的界面是否变化；若变化，检查他们是否能看出原因。
• 实现侧：核对每类呈现状态的存储位置（个人级或共享级）与声明一致；验证共享视图变更对在线查看者产生可察觉的呈现。

反例做不到——成员为找一条记录设了个筛选，全组看板同时被筛掉了大半，别人以为数据丢了；做过头——完全不提供共享视图，每次会议前所有人都要手动把筛选条件调成一样。

C6-4私人区与共享区的转移显式且不可假装撤回必须¶

一句话：撤回删得掉内容，删不掉"已经被看见"。

适用提供撤回、删除已发送内容或从共享区移回私人区能力的产品。

规则内容从私人状态转入共享状态是一次显式动作（见 C6-1）；反向转移——撤回、删除已发送内容、从共享区移回私人区——必须如实呈现已经发生的暴露（见 collab.private.recall.disclosure）。产品禁止以"已撤回""对方未读"等表述暗示内容未被看见，除非该判定来自可靠依据且其依据的局限被说明。撤回后，产品必须说明其作用边界：已被他人复制、导出、截图、通过通知摘要送达或已被外部系统接收的内容不在撤回范围内。撤回动作本身对他人的可见性（是否留下"已撤回一条消息"的痕迹）必须预先定义并一致执行，不得逐次由实现决定。

边界条件本条不否定撤回功能的价值；它约束的是对撤回效果的表述不制造错误预期。它不要求产品追踪内容在其边界之外的传播——恰恰相反，正因为做不到，才要求如实说明。

设计应用把撤回后的提示从"已撤回"改成说明性的一句话（"已从对话中移除；若对方已收到通知，内容可能已被看到"）。这一句话的成本很低，它防止的是基于错误预期的后续行为。

验证示例

• 用户侧：发送一条内容触发推送后立即撤回，检查接收方的通知栏是否仍保留内容，撤回方是否被告知这一可能。
• 实现侧：核对撤回的实际作用范围与文案表述一致；验证通知摘要、邮件送达与外部集成中的副本处理方式被说明。

反例做不到——发错了消息点撤回，界面显示"已撤回"，实际上对方的手机推送里原文还在，发送方毫不知情；做过头——因为撤回不彻底就完全不提供撤回，发错内容只能留在那里。

C6-5私下沟通不并入共享记录应当¶

一句话：私聊不因为导出、检索或汇总而变成公开材料。

适用同时提供私下沟通（私信、私有评论、个人笔记）与共享记录的产品。

规则私下沟通的内容不应当因为导出、检索、汇总、摘要生成或跨功能引用而进入更大的可见范围（见 collab.private.channel.scope）。禁止在生成面向共享空间的摘要、报告或知识汇总时纳入未被授权共享的私下内容；由 Agent 或自动化生成此类汇总时，其可读取范围同样受本条约束。私下内容因合规、审计或法定要求被访问时，其访问依据与范围应当被记录；禁止以产品功能的形式把这类访问变成常规可得。私下沟通被转入共享空间时，必须是发起方的显式动作，并使原对话方可知。

边界条件本条不禁止用户自己引用或转发其私下内容——那是用户的处置权。它不改变组织依法定或制度要求进行的合规访问，只要求这类访问不被做成一个日常可用的按钮。

设计应用给汇总与摘要类功能设一条硬性的读取边界，并在生成结果处标明其数据来源范围。把"转发到共享空间"做成有对话方可见痕迹的动作。

验证示例

• 用户侧：在项目里进行一段私信讨论，然后触发项目摘要生成，检查私信内容是否出现在摘要中。
• 实现侧：审计汇总类功能与检索索引的读取范围；验证私下内容不在共享导出结果内。

反例做不到——项目周报自动汇总功能把两名成员关于第三人的私聊一并写进了发给全组的摘要；做过头——为了隔离，私下讨论中的结论无法以任何方式带入共享文档，用户只能手动复制粘贴。

C6-6提醒可收敛且提及不扩权必须¶

一句话：可以少受打扰；被提及不等于被授予访问权。

适用提供提及、订阅、线程通知、邮件摘要或推送的协作产品。

规则

1. 成员必须能按对象或线程停止非必要提醒，并设置个人免打扰时段；跨时区显示截止与静音恢复时间时必须可查时区。静音只改变提醒，不能把已分配责任标为已处理或删除待办。
2. 提及必须在发送前解析接收对象及授权范围；禁止因 @ 某人或群组自动给其新增内容访问权。需要邀请时，必须明确展示授予范围并执行独立的授权动作。
3. 群组提及必须让发送者知道实际通知范围；无权查看成员名单时不暴露名单。紧急突破静音的条件、主体、频率约束与记录必须预先明确，不能以反复 @ 自动突破。
4. 权限变化、责任回落等必要事件必须留在可查询的位置；暂停推送不能丢掉事件，也不能被当作接收方已知悉。

相关配置：collab.private.attention.policy、collab.action.delivery.policy。

边界条件不要求所有通知都可删除；必要事件可以保留在产品内，但外部强打扰必须符合声明的紧急条件。

验证示例静音线程后多次 @，普通推送不恢复；无访问权者被提及时不收到内容摘录，也不自动加入共享范围。

反例做不到——点击 @ 外部同事便把整个项目授予对方。做过头——静音后连权限收紧提示和待处理任务都不再显示。

C6-7参与限制有作用域与退出路径必须¶

一句话：屏蔽、退出和撤权各有后果，限制也要有解除路径。

适用提供共享讨论、定向互动或成员参与限制的产品。

规则

1. 产品必须区分个人静音或屏蔽、限制某人的参与、将人移出空间与撤销其访问权；操作前说明影响哪些互动与内容，禁止用“屏蔽”暗示共享对象已对该人不可见。
2. 成员必须有停止不必要定向互动及向明确责任方求助的路径；求助材料只向获准处理者披露，不能默认广播给全体成员或被求助对象。
3. 有权者限制发言、评论或加入时，必须记录作用范围、生效条件、期限或复核条件及解除路径。受限者必须得到不泄露敏感材料的状态说明与可用的复核入口。
4. 退出空间必须说明责任、内容和权限的后续处理；个人屏蔽与退出不得静默删除他人贡献，成员退出也不表示其历史内容被全部撤回。

相关配置：collab.private.participation.policy。

边界条件本条规定产品中的参与控制，不规定哪些言论违规或组织应如何裁决；紧急限制可以先执行，不能因此省略受控记录与复核路径。

验证示例甲屏蔽乙后核对双方共享文件权限不变；限制评论后测试时限、复核及解除；退出时核对任务交接与私人内容。

反例做不到——屏蔽按钮让人误以为对方再也看不到共享看板。做过头——遭遇反复骚扰时必须先公开说明全部细节才允许静音。

4. 术语和定义¶

本章定义本规范内用于判断行为与结果的词。

4.1 符合性判定¶

按每条适用规则中的独立义务判定“通过 / 不通过 / 不适用 / 未验证”；不适用必须写出能力与情境依据。应当级偏离需说明理由、替代机制及对应验证。示例中的人数、样本数和时长是测试设置，不是通用性能门槛。

文档审查、机制验证和用户理解验证分别留证，不能互相替代。越权、丢失贡献、把未知呈现为成功、把静音或未回复视为同意，任一适用用例失败即不通过，不用平均分抵消。改变受众、并发、保存或通知策略后，重验受影响的组合场景。

附录 A：故障注入验证清单¶

本清单用于检验条款是否真的生效，不新增义务。逐项注入，记录系统的实际行为；记录"不适用"是合格结果，记录"没测"不是。

A.1 感知与可见

A.2 并发与冲突

A.3 操作与责任

A.4 私人余地

A.5 分类检验

用于检验第 1 章的切分是否成立：取 10 至 15 条具体要求（可来自本规范条款，也可来自真实评审意见），让至少三名未参与撰写的评审者独立判断其归属原则。归属分歧集中在某两条原则之间，说明这两条原则的规范对象没有切开——此时应当调整原则，而不是增设中间层或映射说明。已知需要重点检验的两处见第 1 章的明示（C1 与 C2、C4 与 C6）。

附录 B：论据边界与来源类型¶

B.1 约束词的判据

标「必须」的唯一依据是：缺了它，某条对用户的承诺会在可预见的情境下失效。下列三类论据提供不同支持，不是三种独立的强制性来源；实现参考本身不足以决定标「必须」——

标「应当」的五条（C2-6、C3-6、C4-6、C5-5、C6-5）都是取舍问题而非底线问题：偏离可能有正当理由，但要留痕并接受同样的验证。其中 C2-6 的两种应答策略、C4-6 的聚合粒度都依赖产品的具体风险判断，本规范不给统一取值。

B.2 本规范证据最薄的三处

明确列出，不用条款语气掩盖：

1. C3-3 的"可自动合并范围"缺少跨产品的通用判据。什么样的语义组合可以安全自动合并，目前没有可直接引用的公认清单；本规范要求产品声明业务风险单元、不相容组合和范围外路径，并验证原始贡献保留；文中的组合是检查起点，不是穷尽清单。这是本规范中最可能被形式化应付的一条。
2. C1-3 与 C1-6 的粒度界线依赖场景判断。"够协作用"与"够拿来考核"之间没有一条可以写进条款的普适分界；本规范给出的是判据（能否说出它避免了什么具体协作问题、用途是否流向对人的评价），不是字段清单。不同组织文化下的可接受范围差异很大。
3. C4-1 的实现代价未被本规范评估。按成员维护撤销栈、并处理跨成员依赖，在不同数据模型下的实现难度差异很大；本规范只规定行为性质，未评估在何种架构下这一要求的代价可能高到需要另设边界条件。不能安全处理依赖时，可以拒绝该次撤销并说明替代路径；不能因此禁止所有不影响他人的撤销。

B.3 本规范未做的事

不给同步算法（不采用操作转换、无冲突复制数据类型或锁定中的任何一种作为规定），不给权限模型（不规定采用基于角色、基于属性还是访问控制列表），不给组织结构，不给保留期数值，不给冲突提示的频率上限。这些是产品与组织的决定；本规范只规定这些决定必须被作出、必须可被检验，以及哪些取值不被允许。

B.4 来源

完整的来源对照、核验状态与检索记录见 reference.md。规范中的条款不因为某个产品这样做过就成立；产品做法是"这类机制在真实产品中可行"的证据，不是"应当这样要求"的依据。

附录 C：组合场景与验收记录¶

本附录是应用示例，不新增义务。每次验证同时检查发起方、接收方、受影响第三方与实际数据结果；只看一个成功提示不能判定通过。

最小验收记录：任务与对象、适用规则、角色和权限、配置实际值及来源、操作序列、注入故障、各方可见状态、后端或本地结果证据、通过结论、未验证项和处理责任人。用户侧观察再记录是否理解受众、结果与下一步；不能以用户猜对掩盖机制失败。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。