查看、评论与编辑三级权限的语义差别
别名: 只读权限 · 评论权限 · 编辑权限 · 权限档位语义
概念解释
文档协作的权限通常压成三档——查看（能读不能留痕）、评论（能读、能批注但不能改正文）、编辑（能改正文与结构）——这三档不只是技术能力的开关，各自对应一种参与姿态：旁观、顾问、共同作者。三档语义的差别要被用户准确理解才有效：把评论权误当查看权的人会在文档里留下本不打算公开的批注，把查看权误当编辑权的人会对着灰掉的按钮反复尝试并怀疑自己操作有误。权限分层的价值不在于安全精细，而在于让每个人在进入文档前就知道自己被期待以什么身份参与。
机制
三档结构之所以成立，是因为它映射了协作中修改权的三个信任等级。查看层：内容对你是只读的信息流，你消费但不影响文档状态——适合通报、已定稿的参考材料。评论层：一个精妙的中介——你的想法进入文档的周边（批注锚定在具体内容上）但不触碰正文，作者保留全部裁决权；它让「提意见」不必升级为「改内容」，反馈的社交成本与内容的完整性同时得到保护。编辑层：你直接改写共享状态，你的操作与作者的操作在同一层面融合，身份从建议者变成共同作者。关键在档位间的语义边界必须干净：评论者能否看到其他人的批注、能否回复；查看者能否复制、能否导出；这些边角行为归在哪一档，用户的预期必须与系统实际行为一致，错位就产生上面那些误用。三档之外的更细粒度（可编辑但不能分享、可评论但不能@他人）认知成本陡增，非特定需求不应展开。
边界
三档是文档协作的甜点，不是普适结构。表格与数据库类协作常需第四档（可加行不可改结构、可改自己字段不可改他人字段），因为行级与列级的权限需求真实存在；代码协作的「编辑」会再分为可提交与可合并，因审查流程介入。三档语义还有一个前提：权限是按人分配的静态身份。需要动态控制（临时收回、限时开放）的场景，三档模型要用有效期与例外规则扩展，复杂度转移到继承与例外的可理解性上——那是同组的另一件事。
怎么落地
- 用统一的图标与措辞表达三档（眼睛/气泡/铅笔的隐喻家族），在分配界面与被授权者界面保持同一套符号。
- 权限不足的操作入口不隐藏而是置灰并说明原因（「你需要编辑权限才能修改此段」），把档位边界变成可学习的反馈。
- 明确定义边角行为的归属并在帮助里写明：评论者之间的可见性、查看者的复制导出、编辑者的分享转授权。
- 需要行级/列级控制时才引入第四档，且默认值对齐三档语义，避免新档位重定义旧词汇。
- 验证：给被试分配不同档位后让其预测「我能不能做 X」，逐项对照实际能力；预测错误集中在档位边角行为上即需补齐语义说明。