我们到底在争论什么：技术讨论如何从工程分歧变成身份冲突

Yoimiya2026/9/2大约 52 分钟

导读：我原本以为自己在讨论技术

这篇文章来自一次失败的写作。

最早那版 snap.md 的第一句是“一个被情绪放大的标签”。它从一开始就在同时做两件事：核查 Ubuntu 与 Snap 的事实，同时纠正社区对这件事的舆论。写到后来，文章里长出了“社区偏见从何而来”这样一整章，桌面中心主义、自利归因、回声室被放进一项打包格式的技术论证里。结语同时承担“总结 Snap”和“劝社区理性”两个任务。

这两个话题之所以被混在一起，是因为讨论 Snap 的人确实会互相贴标签。但研究的问题不同：软件该如何分发、维护责任如何分配，需要核查实现与发布记录；一项工程分歧怎样变成人与阵营之间的冲突，则需要观察讨论中的判断和回应。分开之后，snap.md 处理前一项，本文处理后一项。

我自己的写作也在这个问题里。第一版有“你又有什么资格一口咬定”“这种批评本身失去了成立基础”这类句子。写这些话时，屏幕上没有具体的对话者，我是在回应一个想象中的反方。于是，我也开始用人的资格代替对论据的检查。仅仅把语气改温和，仍会留下这层意思；真正需要调整的是我在质疑什么，以及希望对方回答什么。

本文因此关注自己的判断与参与方式：怎样核查技术分歧，怎样理解不同选择，又怎样识别一段对话已经转向身份。文中的案例用来说明某种行为如何发生；判断它在整个社区中有多常见，还需要另外的证据。

全文依次讨论五个问题：

目标与约束：双方认可同一组事实，为什么仍会选择不同方案？
证据：个人体验能说明什么，怎样比较不同条件下的结果？
身份：讨论什么时候从技术问题转向人的资格与阵营？
可见性：少数冲突为什么会变成我们眼中的“整个社区”？
参与方式：怎样核查判断，什么时候接受分歧，什么时候结束对话？

文中的公式用于区分这些问题涉及的变量。它们是帮助推理的简化表达，具体例子和文字解释承担主要论证；符号索引与较长推导放在附录 B、C。

1 不同的目标与约束：为什么会选出相反的方案

两个人都熟悉自己的机器，也认可同一组测试结果，最后仍可能选择不同方案。他们要完成的任务、必须满足的条件，以及愿意承担的成本不同，选择也就可能不同。分析这种分歧之前，需要先确认双方究竟在回答什么问题。

1.1 先分清是在比较事实，还是做选择

“macOS 与 Windows 的 HDR 色彩管理和显示链路有什么差异”，问的是技术属性，需要靠文档、实现和测试回答。“哪套系统更适合自己的 HDR 工作流”，问的是选择，还要考虑软件兼容性、使用习惯和维护成本。一个人可以不在意 HDR，但两个系统的实现差异仍然存在。

这两类问题经常出现在同一段对话里。“我不会用这个平台”说明了一项选择，却没有回答它的 HDR 实现有什么特点。如果讨论从技术差异转到个人选型，就需要把用途和条件补上，才能知道双方的结论是否真的冲突。

“Flatpak 到底好不好用”“Arch 和 Ubuntu 哪个更好”也是如此。用它们询问如何选择时，还要说明希望达成什么、必须满足哪些条件，以及后果由谁承担。给家人使用、需要自己远程维护的电脑选系统，与给自己的开发机选系统，就可能得到不同答案。

这些条件可以把一个笼统的问题变成几个具体问题。技术事实仍然需要核查，而选择结论从此有了适用范围。

1.2 一个技术对象包含哪些属性

讨论一种技术时，我们往往在同时评价兼容性、启动时间、控制权和维护成本。可以把这些属性记作一组量：

\mathbf v(x) = (\text{兼容性},\ \text{启动时间},\ \text{磁盘占用},\ \text{控制权},\ \text{维护成本},\ \text{更新速度},\ \text{隔离性},\ \text{生态规模},\ \dots)

这里的 $x$ 是被比较的方案， $\mathbf v(x)$ 是它的属性向量，也就是这份可以逐项展开的属性清单。不同属性可能需要不同的测量方法，其中一些还依赖使用条件。

我在 Windows 上的体验就有这种区别：Unreal Engine 的工具链、Windows Terminal、PowerToys 都是好用的，同一系统里某些 UI 决策和某些硬件上的睡眠唤醒体验则很差。这些判断针对不同属性，可以同时成立。

把评价写到这一步，读者就能继续追问具体依据。如果只留下“好”或“差”一个总评，哪些表现支持了这个结论、哪些代价被接受了，都会变得不清楚。

1.3 相同的属性，怎样形成不同的排序

一个人可能把软件新鲜度看得很重，并愿意承担较多维护工作；另一个人希望升级后的行为可预测，愿意接受较旧的软件版本。即使两人认可同一组数据，他们也可能分别选择 Arch 和 Debian。

这里可以区分两个量： $\hat{\mathbf v}_i(x)$ 表示第 $i$ 个人对方案属性的认识， $\mathbf w_i$ 表示他对各项属性的重视程度。用一个简化的加权式表示个人评价：

U_i(x) = \mathbf w_i^\top \hat{\mathbf v}_i(x)

这个式子把“我认为它表现怎样”和“我有多在意这种表现”分开了。属性值需要先约定可比较的尺度和方向，再按权重形成评分；分数相同的方案可以并列。现实选择还会涉及阈值和属性交互，本文只借这个表达说明两类差异：事实认识不同，或者对相同事实的评价不同。

$\hat{\mathbf v}$ 上的帽子表示估计。读错源码、看错版本号，都会使估计偏离实际属性 $\mathbf v$ 。即使一个人按自己的估计和权重得出了自洽的排序，依据仍可能有错，需要由证据纠正。第 2 部分讨论这类问题。

而在事实认识相同的情况下，权重不同就足以产生不同排序。有人比较 Snap 与 Flatpak 时主要关心 CLI、IDE 打包和上游发布；有人更关心启动时间、桌面集成或打包来源的可审计性。他们需要先核对各项实际表现，再说明自己为什么更在意其中一些属性。

个人排序由此有了明确的适用条件。把这组条件一并交代，别人才能判断它对自己的选择有什么参考价值。

1.4 先找到分歧，再决定怎样处理

“更在意什么”只是分歧的一种来源。实际讨论中，还可能存在以下差别：

争议对象	典型表述	需要弄清什么	处理方式
必须满足的约束 $C$	必须无 root、离线运行或通过合规要求	哪些方案在各自条件下可用	明确约束；必要时按不同场景分别讨论
属性估计 $\hat{\mathbf v}$	这个设计增加维护成本；启动慢约 300 ms	比较条件与依据是否可靠	核对文档、实现和测量
对未来的预测	Wayland 三年后能否满足某项工作流	判断标准、时间范围和预测依据是什么	记录假设，约定后续观察
权重 $\mathbf w$	我更在意启动时间	对事实的认识接近后，各自仍在意什么	说明取舍，接受个人选择不同

约束集 $C$ 用于筛选可行方案。例如，某个必需软件必须可用，就应先作为条件筛选，而不能靠其他优点补偿。明确约束也不要求双方改用同一套条件；有时只是确认他们面对的本来就是两个选择问题。

我会先核对与当前结论有关的条件和证据，再讨论偏好。一个人说“Snap 启动慢”，另一个人回答“这是你的偏好”，就跳过了启动时间究竟是多少这个可测量的问题。等双方接受同一组测量结果后，一个人仍认为这个等待时间不可接受，另一个人并不介意，才有理由把这部分分歧归到权重上。

这是一种排查次序，并不要求穷尽全部事实以后才允许谈偏好。实际讨论可以来回修正条件和依据；需要避免的是过早用“偏好不同”结束尚未核查的事实问题。如果选择还会让别人承担成本，就需要进一步讨论责任分配。

1.5 成本由谁承担，也会影响选择

技术方案的收益和代价，可能分别落在用户、维护者、上游、厂商和管理员身上。同样一项更新，对上游是减少维护分支，对用户却可能是适应行为变化。直接把这些影响合成一个“总成本”，需要先说明怎样比较工时、费用、风险和控制权。

Ubuntu 把 Firefox 从 deb 换成 Snap 是一个具体例子：Mozilla 可以直接发布更新，Ubuntu 维护者减少了跨发行版维护软件包的工作，用户则要适应首次启动性能和 apt 安装结果的变化。^[1] 双方都在面对真实后果，只是获得的收益和承担的工作不同。

当决策者与成本承担者不是同一批人时，后者还可能缺少参与决定的机会。这时，分歧除了“方案是否有效”，也包括“这项工作为什么由我承担”。

不过，技术改进也可能同时减少多个参与者的负担。包管理器相对逐个源码编译、容器镜像相对手工配置环境，都可能减少重复工作。因此，既要看成本如何分配，也要看哪些成本确实降低了。

“X 不好”有时是在表达“不愿承担这项成本”。确认对方的意思以后，讨论就可以落到具体责任：成本来自哪里，由谁承担更合理，在什么条件下能够接受。

1.6 小结

选择不同，可能来自用途、约束、事实认识、预测或偏好不同。先把分歧定位到其中某一项，才知道需要补充什么：事实问题需要证据，预测需要说明假设，个人取舍可以不同，涉及其他人的成本还要讨论责任。接下来先看证据怎样影响我们对技术的认识。

2 有限的证据：个人体验能说明什么

两个人可能掌握了不同数据，也可能从一开始就在谈不同属性。只有把各自的依据展开，才能知道分歧来自事实认识，还是对相同事实的评价。

2.1 把一次体验放回发生条件

社区排查挂起恢复问题时，经常同时记录驱动和内核版本。同一个用户升级内核或驱动之后，故障可能消失，也可能在后续更新中再次出现。于是，“这台机器无法恢复”还需要附带配置、操作步骤和发生时间，才能与别人的报告比较。

可以把记录到的条件写成：

Z = (\text{发行版},\ \text{内核},\ \text{驱动},\ \text{固件},\ \text{OEM},\ \text{硬件型号},\ \text{桌面环境},\ \text{文件系统},\ \text{负载},\ \text{时间},\ \dots)

$Z$ 表示我们观察和记录到的环境。负载时序、固件内部状态等因素可能没有被完整记录，因此两份看起来相同的配置记录，也可能对应不同的运行条件。复现时需要继续排查这些差别。

2.2 一次经历能告诉我们什么

一个人遇到了故障，另一个人没有遇到，两份报告可以同时真实。他们可能使用不同配置；即使记录的配置相同，一次成功和一次失败也不足以说明谁的报告有误。

这里需要区分“这一次发生了什么”和“在这些条件下有多容易发生”。前者是一项观察，后者是条件概率 $P(\text{故障}\mid Z=z)$ ，通常需要一组有明确条件和取样方式的观测来估计。

单个案例仍然有价值。它能提供触发步骤、错误信息和一个可继续调查的入口；经核实后，也可能成为推翻“在这些条件下从不发生故障”的反例。不过，仅凭这个案例，还无法可靠地估计发生率，也无法判断另一组配置的故障概率是否更低。对应的概率表达见附录 C.1。

2.3 发生过、没有发生过与发生率

报告	可以支持的判断	尚不足以支持的判断
我遇到了	在所报告的条件下，至少有一次发生了这种情况	多数用户都会遇到
我没遇到	在所报告的尝试中，没有触发这种情况	该配置始终不会触发，或其他人的问题不存在

“我无法复现”有助于比较触发条件。它说明某次尝试得到了不同结果，接下来可以核对步骤、环境和日志。只有确认报告针对同一条件和同一问题，才能进一步讨论它们之间的关系。

许多个案也需要同样的检查。要估计某个群体中的发生率，除了知道用户遇到了什么，还需要知道哪些用户被纳入、哪些没有，以及每份报告记录了多少次尝试。第 4 部分会说明，评论区通常缺少这些信息。

2.4 双方可能在检查不同属性

一个人主要用 Flatpak 安装桌面 GUI 应用，测试过文件选择、屏幕捕获和权限调整；另一个人尝试用它运行 CLI 工具和 IDE，检查的是命令入口和访问宿主工具链的方式。两人的依据都可能可靠，但回答的问题不同。桌面集成的测试结果不能直接代替开发工具的测试，反过来也一样。

这种差别可以称为证据覆盖范围不同。讨论时，先列出双方已经核查了哪些属性，就能发现哪些结果可以直接比较，哪些还需要补充材料。

如果用记号表示， $m_{ik}=1$ 表示第 $i$ 个人在第 $k$ 项属性上有原则上可核查的依据， $m_{ik}=0$ 表示目前没有。它只记录依据是否存在，不决定依据是否正确。“有源码但读错了”和“尚未找到依据”都需要修正认识，只是下一步应做的检查不同。

2.5 新证据怎样改变选择

假设两个人原本都认为某个方案启动较慢，新测试表明它在目标环境中已经明显改善。这个结果会改变对启动时间的估计。不过，一个很在意启动时间的人可能因此改选，另一个主要受软件兼容性限制的人则可能继续使用原方案。

先考察用途、约束和权重暂时不变，只更新事实估计的情形。设 $D^{\text{前}}$ 为原来两个方案的评分差， $\Delta$ 为新证据引起的差值变化，那么：

D^{\text{后}} = D^{\text{前}} + \Delta

证据能改变多少评分，取决于它修正了哪些属性、修正幅度有多大，以及这些属性在当前选择中有多重要。排序是否反转，还要看更新后的差值是否越过零。如果原来 $D^{\text{前}}=0$ ，表示两方案在当前评价下并列；证据可能打破并列，这与已有偏好发生反转是两种情况。详细推导见附录 C.2。

这里比较的是两个方案的差别。如果一条信息改变了对两者的评价，却没有改变它们之间的评分差，排序也可以保持原样。排序不变，因此不能单独证明对方没有接受新信息。

同一条证据被重复转述，也不会因此变成多份独立观测。在已经理解并纳入它的前提下，没有新增内容的重复转述通常不会继续修正估计；独立的复现实验则可能提供新的信息。讨论中值得追问的是这次发言增加了什么，而不只是同一种说法出现了多少次。

2.6 共同核查可以改变认识，结论仍可能不同

对方提出自己遗漏的属性、提供更准确的测量，或者指出自己读错了源码，都可能改变判断。讨论的直接收益，是让双方更清楚依据是什么、哪些认识需要修正。最终是否选择同一方案，还取决于各自的约束与权重。

这里需要分清提出问题和给出证据。“你没有考虑可维护性”提出了一项值得检查的属性，后面还应说明具体是哪部分维护、由谁承担，以及有哪些可核查材料。属性清单可以在讨论中扩展，相关依据则需要继续检查。

因此，共同核查的范围可以扩大，而结论既可能靠近，也可能保持不同。5.2 节会把这个过程整理成具体做法。

2.7 依据的数量、质量和重要程度

设想一个选择主要取决于第十项属性：有人对前九项都有可靠认识，却没有核查第十项；另一个人恰好掌握第十项。仅仅比较“了解九项”和“了解一项”，就很难判断谁的依据更能支持当前选择。

需要一起看的，是依据覆盖了什么、认识是否准确，以及这项属性怎样影响结论。没有依据的人也可能持有很强的估计；找到来源以后，仍要检查来源是否被正确理解。

专业经验在这里很有用。长期维护 Mesa 的开发者通常能提供更准确的线索，也更容易识别问题出在哪里；具体判断仍可继续通过源码、日志和 issue 核查。这个要求同样适用于我：核查过 snapd 的沙箱模型，并不意味着我也熟悉 systemd 的每项行为。在只有二手认识的问题上，仍需要补上当前命题的依据。

2.8 把相反报告变成可比较的问题

面对相反报告，可以先问：两次运行的条件有什么不同？双方检查的是同一项属性吗？新材料修正了哪部分认识？这些问题把讨论带回具体的配置、测量和推断，也给出了下一步能够做的事。

2.9 小结

个人体验提供了调查线索，发生率和普遍性则需要更完整的样本。双方也可能掌握不同属性的依据，尚未形成可以直接比较的结论。补充证据能够修正认识，但选择不一定随之改变。还有一些争论会在举证后转向人的身份，这就需要另一种处理。

3 身份：分歧什么时候不再关于技术

有些争论在补充材料后能够继续：双方发现配置不同，或修正了对实现的理解。另一些争论却会换掉对象：日志贴了，复现步骤给了，上游 issue 引了，回应变成了“你是什么人”。这里关注的是这种变化。

3.1 技术投入可能成为身份的一部分

一个人花了几百小时配置 Arch，读过 systemd 的文档，也能在邮件列表里回答问题。这些投入提高了他处理问题的能力，并可能帮助他在社群中获得认可。如果技术熟练度与社群归属逐渐联系起来，别人对工具的批评，也可能被他理解为对自己能力或地位的质疑。

这种联系可以从两个方向形成：投入带来熟练度与归属感，已有的归属感也会影响后来的技术选择和解释方式。在成员缺少长期相互了解的场合，工具选择、术语和内部规则还可能成为识别“内行”的捷径。

我自己的反应也受这种投入影响。写 snap.md 时，我查阅了 snapd 的打包配置、confinement 文档和一批 issue。这让我在相关问题上有了更多可核查的依据，也让我对“Snap 就是垃圾”的反应强于对普通技术批评的反应。经验帮助我判断，也可能让我更不愿意重新检查熟悉的解释。

这里提出的是一种可能的联系。具体争论中是否存在这种影响，还应看参与者怎样回应材料，不能仅凭他投入过多少时间就推断动机。

3.2 敌意怎样在互动中被维持

如果批评被理解为身份威胁，回应就可能变得更有敌意。敌意发言又可能获得更多互动和可见性，让旁观者更容易记住“对面都是这种人”。这个印象进一步强化群体边界，使下一次批评更容易被当作敌意。它可以概括为：

技术投入与群体认同 → 批评被理解为身份威胁 → 敌意回应 → 冲突获得可见性 → 对另一群体的负面印象增强 → 群体认同进一步强化

第 4 部分的研究支持其中关于内容可见性的部分。其余连接是本文根据前述现象提出的机制假设，用来说明这些反应可能怎样相互加强，不表示整条链已经得到因果验证。

双方还可能把彼此的语气当作自己态度的理由：我认为你先挑衅，你认为我的回应证明了恶意。即使某个技术事实已经澄清，这种对人的解释仍可能继续维持。如果缓和还会被身边的支持者理解为认输，退出敌意互动就会变得更难。

所以，补充技术证据能否推进对话，还取决于双方是否继续用它检验原来的技术判断。

3.3 看什么结果能让判断被撤回

对于“这个设计在配置 Z 下容易出问题”，双方可以核查日志和复现步骤，调整对故障原因与发生条件的判断。这里存在能够支持或削弱原解释的材料。

有些身份标签则使用封闭的解释方式。比如，提出者已经认定对方是“厂商的盲目拥护者”：举证被解释为急着洗地，沉默被解释为被戳穿，认错被解释为被迫让步，语气平和又被解释为掩饰。几种不同回应都被当作同一个结论的证明，对方也就很难通过材料纠正这个判断。

我会用一个问题检查这种情况：

什么可观察的结果，会让提出者修改或撤回这个判断？

“支持某厂商”“长期使用某系统”可以是一个人对自己经历或偏好的描述。问题在于，它是否被用来预先否定对方的论据，以及提出者是否允许自己的解释被事实修正。

如果任何回应都被解释成同一个标签，继续补充技术材料就很难检验这项指控。这个判断可以帮助决定是否继续对话，见 5.3 节。

3.4 一句话正在陈述什么

下面几类句子需要不同的回应：

陈述类型	例子	怎样继续
事实	snapd 以 GPLv3 发布	核查来源与适用范围
经验样本	我的笔记本无法休眠	补全环境、步骤和结果
工程评价	这种设计维护成本太高，不值得采用	先核查成本，再讨论用途、约束和取舍
偏好	我更喜欢 KDE	了解使用习惯，无须证明别人也应喜欢
身份判断	真正懂 Linux 的都用 X	检查它是否在用群体归属代替技术依据

工程评价通常同时包含事实与取舍。“维护成本高”需要说明工作量来自哪里，“不值得采用”还需要说明预期收益和用途。把两部分拆开，才能知道争论是在核查成本，还是在评价是否值得承担。

讨论中常见的跳跃也可以据此辨认：

由样本推总体：从一次体验，直接概括整项技术的表现。
由偏好推义务：自己愿意折腾系统，便要求其他使用者承担同样的工作。
由评价推身份：回应“这个设计有问题”时，开始判断批评者属于哪类人。
由解释推立场：某人说明设计产生的约束，被理解为他在为某一方辩护。

“这 API 是垃圾”也需要追问。它可能在表达一次受挫的经验，也可能在概括一组工程代价。先问清是哪项行为、哪种用途和哪些后果，才能决定核查什么；仅凭句式，很难知道说话者希望讨论哪一层。

3.5 话题换成了人的资格

当对话开始出现下面的回应时，我会留意讨论对象是否已经改变：

用对方所属群体代替对当前论据的检查。
用他人对这个人的评价，直接裁决当前技术命题。
把“你用什么系统”当作结论成立与否的依据。
要求对方先证明立场正确，才回应他提供的材料。

不过，身份和经验信息也有合理用途。长期维护某个驱动，可以说明判断来自怎样的工作，也有助于追问具体依据。它提供的是核查线索。当前结论仍要看相应的源码、日志、文档或实验，而不能只由说话者的资格决定。

3.6 小结

技术投入可能影响归属感，对批评的反应也可能因此带上身份意味。真正让技术讨论难以继续的，是论据被人的标签替代，而且这个标签不再接受反证。判断时应看具体回应如何使用证据，而不再凭群体归属猜测动机。

4 可见性：为什么少数冲突会变成我们眼中的“整个社区”

假设一篇文章有几千人读过，留下几十条评论。只看评论区，我们对“大家都在说什么”的印象就来自这些发言；没有评论的人怎样看这个话题，仍然不知道。观察整个社区时，需要把这个缺口算进去。

4.1 从持有观点，到发言，再到被看见

一种观点进入视野，至少经过两次筛选：持有它的人是否愿意发言，已经发表的内容又是否被我们看到。遇到故障的人可能更愿意求助，容易引起回应的发言又可能获得更多展示。这样形成的评论区，与全部用户的经历分布就可能不同。

在固定的问题、人群和时间范围内，用 $o$ 表示一种回答， $P_{\text{pop}}(o)$ 表示它在成员中的比例。先把每人的参与简化为一次表达机会，可见分布可以写成：

P_{\text{obs}}(o) \propto P_{\text{pop}}(o) \cdot s(o) \cdot r(o)

其中， $s(o)$ 是持有这种回答的人发言的概率， $r(o)$ 是发言以后被看到的概率。某种回答越容易被说出、越容易被展示，它在可见内容中的比例就越可能高于在成员中的比例。

这个式子只描述一轮筛选。一个人反复发帖、内容被多次转发，以及可见内容反过来影响下一轮表达，都需要进一步考虑，见附录 C.3。用于技术故障讨论时，还应按第 2 部分的环境条件 $Z$ 区分报告，以免把不同配置下的结果混在一起。

关于鸿蒙 PC 的争议给了我一个具体观察：支持与反对两侧都有人使用标签回应技术问题，旁观者也容易据此形成“对面全是这种人”的印象。这个观察能说明一种讨论形态；要判断两侧分别有多少人这样表达，还需要知道没有进入视野的成员是什么样。

4.2 谁进入了样本，以及样本是否彼此独立

选择偏差问的是谁更容易进入样本。机器正常的人可能没有发帖的动机，遇到故障的人则可能专门来求助。因此，随机询问一百位用户，与收集一百条故障帖子，回答的并不是同一个问题。

筛选也可能发生在观察者一侧。长期关注某个平台的人，会记住批评者受到攻击的案例；关注其他品牌争议的人，也会记住另一批相似事件。这些事件可以都是真的，但只从自己熟悉的话题取样，仍不足以比较不同群体中这类行为的比例。

样本相关问的是已有观察之间共享了多少来源。一百条看过同一视频以后发表的相似评论，可能受到相同内容、传播链和社群环境影响。若忽略这些共同来源，直接按独立观测统计，就可能高估其中包含的独立信息，低估推断的不确定性。

两者可以同时出现。增加评论数量，有助于观察更多表达，但不能自动补上缺失的人群和共同来源。要估计故障发生率，还需要说明总共有多少用户或尝试、怎样选取样本，以及哪些条件可能影响结果。

所以，“评论区里全是抱怨”首先描述的是可见样本。它可能来自总体故障较多，也可能来自故障用户更愿意发言、抱怨更容易被展示，或几种机制共同作用。仅凭评论区，通常无法分清各自贡献了多少。

4.3 研究分别支持了哪些判断

关于表达与可见性，可以把两类研究放在一起读：一类观察技术协作中发生了什么，另一类实验改变内容排序，观察用户接触到什么。它们回答不同问题，提供的证据也不同。

Sarker、Turzo 与 Bosu 分析了 2828 个 GitHub 项目、约 1.015 亿条 pull request 评论，并对自动分类结果抽样进行人工校验。研究记录了辱骂性语言、引战和侮辱等表达，也发现它们与项目热度、问题解决率和参与者过往行为存在统计关联。^[2] 这说明开源协作中的不友好表达可以被系统观察；关联的因果方向，以及怎样推广到其他技术社区，还需要分别研究。抽样、分类校验和回归结果的细节保留在脚注中。

Brady、Doyle、Elnakouri 等人的 Bluesky 实验则改变了用户看到内容的方式。研究将 2000 名美国两党活跃用户随机分入三种排序，在跨越 2024 年大选的八周里观察结果。相对逆时序排序，互动优先排序增加了群体间敌意、道德化、情绪化和毒性政治内容的暴露；研究者设计的替代排序则比互动优先排序减少了这类内容的暴露，整体平台享受度保持相当。^[3]

不过，研究没有检出参与者自身发帖、点赞和转发行为的显著变化。这个结果限定在所测指标和实验期间，不能直接解释成行为完全没有变化。它说明，改变“用户看到什么”和改变“用户自己怎样行动”，需要分别检验。

Twitter 的算法审计也发现互动排序会放大情绪化和外群体敌意内容，同时提醒替代排序也可能增加同立场内容。^[4] Facebook 与 Instagram 的三个月实验则没有检出所测关键政治态度的显著变化。^[5] 这些结果进一步说明，内容暴露、态度与行为之间不能省略中间的证据。

对技术社区本身，Miller 等人对 100 条毒性讨论的定性分析补充了“这些表达怎样出现”的材料，但其抽样不用于估计普遍程度。^[6] 因此，本文据研究作出的判断是：已有表达与分发方式都值得考察；它们并未给出技术社区中发言意愿 $s$ 和可见性 $r$ 的一组现成参数。

观察者对内容的理解也会引入偏差。2023 年研究发现，观察者往往高估发帖者自报的道德愤怒；Bluesky 研究又发现，用户低估了其他人认为毒性帖不恰当的程度。^[7]^[3:1] 前者涉及对作者情绪的推断，后者涉及对旁观者态度的估计。这是阅读内容之后的解释问题，与“哪些内容进入视野”有所区别，却同样会影响我们对群体的印象。

4.4 讨论环境怎样改变体验

邮件列表、GitHub issue、论坛和视频评论区给人的体验差别很大。除了参与者本身，交流方式也会影响谁愿意发言、什么内容容易留下来：

规模与重复相遇：二十人的长期邮件列表，与二十万人的公共论坛，成员反复遇见彼此的机会不同。
声誉能否累积：固定用户名和可追溯的历史，能让后续参与者了解此前的发言；临时账号和一次性参与会削弱这种连续性。
上下文是否连贯：长期讨论可以引用已经确认的前提；推荐流不断带入新参与者时，前情往往需要重新解释。
发现内容的方式：按时间、按热度或依赖推荐，影响哪些发言更容易被看到。
管理与规范：行为准则是否明确，执行是否持续，会影响参与者对回应后果的预期。
发言的社会成本：实名、半实名与匿名，使发言与现实关系的联系程度不同。
社群边界：内部讨论被推向更大人群以后，参与者构成和彼此了解的程度也会变化。

这些条件会与成员构成共同影响讨论。它们提供了可以观察的解释方向，也提醒我们谨慎地把某次体验归结为整个群体的特征。

在我观察到的鸿蒙 PC 争议中，不少讨论发生在推荐流主导的平台上，一次性参与者较多，上下文也不连续。换成长期交流的邮件列表后，需要重新观察发言方式和传播条件；现有案例不足以预言同一批人会怎样回应。

4.5 检查自己看见了什么

形成“某个社区就是这样”的印象时，我会先检查它来自哪些渠道：看到了多少不同来源，是否反复看到同一场冲突，哪些成员始终没有进入视野。

这也适用于我自己的写作。snap.md 的传播主要来自其中的论战性内容，梳理打包格式的部分带来的传播较少。读者看到并转述哪些部分，也会影响我对反馈的印象，因此可见性筛选同样需要用来检查自己的判断。

4.6 小结

评论区记录了已经说出、又被看到的内容。发言意愿、分发方式、样本之间的共同来源，以及观察者怎样理解这些话，都会影响最终印象。研究可以分别检验这些过程，但由局部观察推断整个群体时，仍需要清楚的人群范围、取样方式和分母。

5 参与而不被消耗

前面的分析最终要帮助我决定怎样参与：哪些分歧值得继续核查，哪些需要承认条件不同，哪些已经换成了无法回应的身份指控。实际使用时，可以按下面的问题寻找分歧所在。

检查什么	可以问什么	下一步
当前问题	我们在比较事实，还是在选择方案？	先说明各自希望回答的问题
可行条件	必需软件、权限或部署条件是否不同？	列出约束，必要时按各自场景讨论
运行环境	两份报告的配置和步骤是否可比？	对照版本、硬件、操作步骤与日志
依据覆盖	双方检查的是同一项属性吗？	补充尚未讨论的相关属性和材料
事实估计	对同一属性的认识为什么不同？	核查文档、源码、测量和解释
未来预测	预测依赖什么假设，何时能够检验？	说明不确定性和后续观察标准
个人取舍	接受同一组事实后，各自仍在意什么？	说明权重与愿意承担的成本
对话对象	回应仍在检查论据，还是只在判定人的资格？	尝试回到命题；无法继续时停止投入

这张表用于定位问题。比较技术事实时，重点是条件和依据；决定采用哪个方案时，再结合约束与偏好。若对话已经只剩资格指控，也可以直接结束，无须先完成表里的全部检查。

5.1 把适用条件写进结论

“Arch 更好”省去了评价所依赖的条件，读者只能用自己的需求理解。写成“在重视软件新鲜度、愿意承担维护责任的条件下，Arch 更合适”，就能说明结论适用于谁。即使读者不接受这组取舍，也知道哪些属性值得按自己的情况重新比较。

这也适用于我。写 snap.md 时，有些结论来自当时的配置，却没有逐条写清适用范围。后来收到不同配置下的反馈，就需要重新检查：原结论是否写得过宽，还是对技术行为本身的理解也需要修正。把不同读数先当作调查材料，比立刻把它当作对立立场更有帮助。

回应或报告故障时，可以把想问的内容写具体：

对方报告故障：说明自己尚未复现，再询问内核、驱动、硬件、步骤和日志。
对方报告正常体验：给出自己能够复现的配置，请对方帮助比较差别。
自己报告故障：说明在什么环境下执行了什么操作、出现什么结果，并附上可核查材料。

这些信息会把一次体验变成可以继续排查的问题，也让别人知道结论的适用范围。

5.2 补充自己尚未核查的依据

如果分歧来自双方检查的属性不同，可以先请对方说明遗漏了什么，再看有什么材料能帮助核查。我也可以提供自己的来源和复现条件，让对方检查。

这个过程包括三个动作：先确认新提出的属性与当前问题有关，再核查具体依据，最后判断它怎样影响原结论。双方可以在不同环节补充材料，也可能各自修正一部分认识。

新信息能否改变当前排序，还受用途和权重影响。不过，交流的价值也包括解释一个暂时用不到的属性、修正未来会用到的认识，或者帮助对方完成学习。这些收益很难只用“是否改变了选择”衡量。直接影响评分的数学条件放在附录 C.2。

决定是否投入时，我会问：

这份信息可能修正什么认识？
依据能否核查？
我是否愿意重新检查自己的判断？
继续交流需要多少时间？

这些问题帮助估计交流可能带来的收益，也保留了选择不继续的余地。一方已经掌握较多相关知识时，交流还可能主要成为单向讲解。在我看来，这类工作很值得投入；只是时间投入不对称，开始时说明期待会更合适。

5.3 判断回应是否还在处理原问题

我会从对方怎样回应具体材料，判断这段交流能否继续。例如：

“snapd 是 GPLv3，Snap Store 的服务端不是开源的，两者需要区分”，得到的回应是“我说得不准确，我真正反感的是 Store”。双方已经修正了争议对象，可以继续讨论。
同样的材料，只得到“你不过是 Canonical 的维护者”。如果随后仍只围绕身份展开，就没有继续检查原来的开源范围问题。

措辞的激烈程度不是充分判据。一段语气很重的回应，也可能给出日志或指出推理漏洞；措辞克制的回复，也可能反复避开证据。扣帽子、读心术、不断更换要求等现象值得留意，具体仍要看它们是否替代了对当前问题的回应。“所有配置都不会出错”这种绝对判断虽然可能错误，却仍可以通过反例检验。

新发言如果让某种解释更可信、暴露了一个遗漏条件，或提出新的可检验可能，讨论就还有内容可以继续。反过来，若连续几轮都只重复标签、回避已经提供的材料，我会停止当前投入。这里判断的是眼前对话有没有可继续处理的问题，而不是断言对方心里永远不会改变。

停止交流也不需要先给聊天计算一个“信息量”。附录 C.4 用互信息解释区分能力这个概念；具体对话中，更实用的依据是回应是否增加了可核查的内容，以及继续下去是否值得。

5.4 按用途选择输入源

可见性会影响我对社区的印象，因此选择输入源时，我会先看自己希望得到什么：

当前用途	优先查看的材料	需要注意什么
核查技术行为	上游文档、源码、issue、release notes、可复现实验	版本、配置与材料是否支持具体结论
理解工程取舍	上下文连续的邮件列表、长期社群和维护良好的论坛	参与者面对的约束、责任和前情
观察态度与表达	视频评论、热帖和短内容	谁愿意发言，哪些内容更容易被看到

这些用途可以出现在同一个平台上。评论里也可能有日志或一手材料，仍可继续核查；问题在于，不能把筛选后的态度样本直接当作技术表现或群体比例的证据。

snap.md 的附录 B 将评论区原声单列，就是为了让读者看清它们在文中的作用：保存真实表达，同时交代这些材料能说明什么、尚不能说明什么。

5.5 留下一份可核查的记录

公开讨论还有旁观者和后来的读者。有些人只阅读，不发言；有些人会在几个月后遇到相似问题。因此，即使对话双方没有改变选择，整理来源、配置、论证和反例仍然有用。

我能够负责的是把这份记录写清楚，让读者检查与自己有关的部分，也让后续反馈有机会修正其中的错误。它比要求每个对话者当场承认结论，更接近我愿意持续投入的工作。

5.6 小结

我会先确认问题，再核查条件和依据，最后说明取舍。能补充信息的分歧值得继续，清楚的偏好差异可以接受，持续回避命题的对话则可以结束。停止某次交流不等于证明对方错误；出现新材料或新问题时，也仍可重新讨论。

结语：我想退出的是什么

我不想退出技术社区，也不希望停止技术争论。技术争论里有大量真实的分歧，值得花时间。

我想退出的是一种把技术选择与人的资格绑在一起的讨论方式。长期使用和学习一个系统，会形成经验与偏好；当这些经验被用来裁决谁有资格发言，或者个人愿意承担的成本被改写成别人的义务，讨论就很难继续围绕原问题展开。

个人体验需要附带发生条件，工程评价需要说明用途和代价，解释一项设计为何存在也可以与批评它的实现同时进行。有人愿意维护 Arch，有人希望 Debian Stable 的行为更可预测；同一个人也可以喜欢 Windows 的开发工具，同时批评它的某些设计。这些判断能够具体讨论，无须先把人分进阵营。

回到导读里的“你又有什么资格一口咬定”。它要求对方先证明资格，却没有说清结论哪里缺少依据。改成“这个结论的依据是什么？我在这组条件下测到的结果不同”，就保留了质疑，也给出了能够回答的问题。

这次写作还让我更谨慎地获取技术评价。反复主动搜索负面评论，会在已经筛选过的发言中再次挑选同一方向的材料。这样积累的印象可以促使我调查某个问题，却不足以判断整项技术的表现或全部用户的态度。

我希望一次讨论结束以后，双方更清楚哪些事实已经核查、哪些认识仍不确定，以及选择为何不同。结论可能改变，也可能不变；只要我们对问题的理解比开始时更准确，讨论就有值得保留的成果。

附录 A：检查自己是否采用了同一标准

对称性检查可以用来检查自己的举证标准：在相关条件和证据质量相当时，如果换成自己更喜欢或更不喜欢的对象，是否还会接受同一种推断？

例如，面对一条批评 Snap 的故障报告，我要求版本、配置、复现步骤和日志；面对一条批评 Flatpak 的报告，也应考虑相同的信息。若仅因更喜欢其中一个，就对一侧要求完整复现、对另一侧接受一句抱怨，需要重新检查自己的标准。

这里比较的是怎样使用证据。技术对象本身的差异仍然要保留：默认项和可选项、安装规模、迁移成本和维护责任不同，都可能支持不同评价。把 Windows 与 Linux 的名字直接对调，原有技术事实当然可能不再成立，这本身不能证明论证带有偏见。

同样，把“必须接受更新”改说成“能持续获得更新”，是在改变对同一行为的评价角度；它可以帮助发现取舍，却没有完成举证标准的对称性检查。两项检查分别有用，不能互相替代。

附录 B：符号与用途索引

正文先使用例子解释问题，下面汇总需要进一步推导时使用的记号。

记号	含义	主要位置
$\mathbf v(x)$	方案 $x$ 的属性向量，即逐项讨论的属性清单	1.2 节
$\hat{\mathbf v}_i(x)$	第 $i$ 个人对属性的估计，可能与实际表现不同	1.3 节
$\mathbf w_i$	第 $i$ 个人对各属性的权重	1.3 节
$U_i(x)$	给定估计与权重后形成的个人评分	1.3 节
$C$	必须满足的约束，用于筛选可行方案	1.4 节
$Z$	记录到的运行环境与条件	2.1 节
$m_{ik}$	第 $i$ 个人在第 $k$ 项属性上是否有可核查依据	2.4 节
$D^{\text{前}}$ 、 $D^{\text{后}}$ 、 $\Delta$	更新前后的评分差，以及差值的变化量	2.5 节、附录 C.2
$P_{\text{pop}}(o)$ 、 $P_{\text{obs}}(o)$	某种回答在人群中及可见样本中的分布	4.1 节、附录 C.3
$s(o)$ 、 $r(o)$	发言概率，以及发言后被看到的概率	4.1 节、附录 C.3
$Y$ 、 $p(z)$	一次尝试是否发生故障，以及给定条件下的故障概率	附录 C.1
$\hat\delta_{ik}$ 、 $S_E$	两方案在一项属性上的估计差值，以及本次证据更新的属性集合	附录 C.2
$K_j$ 、 $W_i$	对方有可核查依据的属性集合，以及自己的非零权重集合	附录 C.2
$\Theta$ 、 $E$ 、 $I(\Theta;E)$	命题可能的取值、证据，以及两者的互信息	附录 C.4

附录 C：数学表达及其适用范围

这些表达用于检查推理关系。它们各有前提，不能仅凭一份聊天记录就给其中的量赋值，也不要求读者在参与讨论时逐项计算。

C.1 一次观察与条件概率

用 $Y=1$ 表示发生故障， $Y=0$ 表示没有发生。在记录到的条件 $Z=z$ 下，可以写成：

Y\mid Z=z\sim\operatorname{Bernoulli}(p(z)),\qquad p(z)=P(Y=1\mid Z=z)

两个人分别使用 $z_A$ 和 $z_B$ ，于是可能对应不同的条件概率 $p(z_A)$ 和 $p(z_B)$ 。但即使两个概率相同，也可能观察到一次成功和一次失败。观察值不同，不足以单独证明条件概率不同。

一个经核实的故障案例，可以反驳覆盖其条件的“从不发生”判断。若要进一步比较发生率，则需要观测次数、取样方式和可比条件。使用似然比讨论一项观察有多大区分力，也需要先说明正在比较哪些假设，以及各假设给出的结果概率；一个案例本身并不提供这些概率。

C.2 证据更新与排序变化

固定约束、属性集合和权重，设两个方案在第 $k$ 项属性上的估计差值为：

\hat\delta_{ik}=\hat v_{ik}(x)-\hat v_{ik}(y)

$S_E$ 表示本次证据 $E$ 更新到的属性集合，撇号表示更新后的估计。若其他属性的估计不变，则：

\begin{aligned} D^{\text{前}} &= U_i(x)-U_i(y)=\sum_k w_{ik}\hat\delta_{ik} \\ \Delta &= \sum_{k\in S_E}w_{ik}\big(\hat\delta'_{ik}-\hat\delta_{ik}\big) \\ D^{\text{后}} &= D^{\text{前}}+\Delta \end{aligned}

对于 $D^{\text{前}}\ne0$ 的情况，严格翻转排序要求：

D^{\text{前}}D^{\text{后}}<0 \quad\Longleftrightarrow\quad D^{\text{前}}\Delta<0 \quad\text{且}\quad |\Delta|>|D^{\text{前}}|

也就是变化方向与原来的评分差相反，并且变化量足以越过零。若更新后恰好为零，两方案变成并列；若原来为零，则更新可能打破并列。评分并列本身不表示这个人没有认识或没有意见。

这里还可以区分两个集合：

K_j=\{k:m_{jk}=1\},\qquad W_i=\{k:w_{ik}\ne0\}

$K_j$ 记录对方在哪些属性上有可核查依据， $W_i$ 记录自己当前赋予非零权重的属性。真正进入评分更新的是 $S_E$ 。若 $S_E\cap W_i=\varnothing$ ，则 $\Delta=0$ ；交集非空时，仍要看更新幅度、方向以及不同项是否相互抵消。

只有在这次证据的影响局限于 $K_j$ 、即 $S_E\subseteq K_j$ 的前提下， $K_j\cap W_i\ne\varnothing$ 才是评分差可能改变的必要条件。证据也可能通过关联推断影响其他属性，或者促使人重新考虑约束与权重；这些情形要另外处理。因此，这个交集不能单独决定一场交流是否值得投入。

C.3 可见样本怎样形成

4.1 节先把每人的参与简化为一次表达机会，并固定讨论问题、人群与时间范围。令 $o$ 表示一种回答， $s(o)$ 表示持有该回答时发言的概率， $r(o)$ 表示已经发言后被观察到的概率。可见分布是归一化后的：

P_{\text{obs}}(o)= \frac{P_{\text{pop}}(o)s(o)r(o)} {\sum_{o'}P_{\text{pop}}(o')s(o')r(o')}

这里假定分母非零。仅观察 $P_{\text{obs}}$ ，通常无法分别还原总体分布、发言意愿与可见性；不同的组合可能产生相同的可见结果。

如果按帖子而不是按成员统计，还需考虑同一人多次发言的频率。连续多轮讨论中，可见内容也可能改变后续观点和表达方式，不能再把这个单轮表达直接当作完整的动态模型。技术故障报告还应考虑环境条件 $Z$ ，以免把配置差异和发言选择混为一项影响。

C.4 区分能力与互信息

用 $\Theta$ 表示当前命题可能的取值，用 $E$ 表示可能收到的证据。给定两者的联合分布，互信息可以写作：

I(\Theta;E)=H(\Theta)-H(\Theta\mid E)\ge0

$H$ 表示熵，用来描述分布中的不确定性。互信息衡量的是：在各种可能的证据上取平均后，知道 $E$ 能减少多少关于 $\Theta$ 的不确定性。某条具体消息可能揭示新的解释，使人暂时更不确定，这与平均意义上的非负性并不冲突。

这个公式需要明确的命题与概率模型，不能仅凭一句身份标签就断言互信息为零，也不能直接给一段对话判定“毫无价值”。正文 5.3 节采用的是可观察的判断：新回应有没有增加能够核查、比较或继续追问的内容，以及继续交流的成本是否值得。

C.5 这些记号如何配合

前面的关系可以概括为两条相交的过程：

\begin{aligned} P_{\text{pop}},\ s,\ r &\longrightarrow P_{\text{obs}} \longrightarrow \text{更可能接触到的 }E \\ C &\longrightarrow \text{可行方案} \\ Z,\ E &\longrightarrow \hat{\mathbf v}_i\text{ 的形成与更新} \\ \hat{\mathbf v}_i,\ \mathbf w_i &\longrightarrow U_i \longrightarrow D^{\text{前}},\ D^{\text{后}} \end{aligned}

一条过程说明材料怎样进入视野，另一条说明人在约束下怎样根据认识和偏好作出选择。 $m$ 记录哪些属性已有可核查依据，帮助定位需要继续检查的地方；它不直接进入评分公式。这里的箭头表示分析上的联系，并不宣称这些关系已经被统一估计为一个经验模型。

Feature Freeze Exception: Seeding the official Firefox snap in Ubuntu Desktop，Ubuntu Desktop Team 官方公告（Ubuntu Discourse），2021-09-16，访问于 2026-09-02。公告说明 Mozilla 主动联系 Canonical，并计划在 22.04 开发周期完成从 deb 到 Snap 的过渡。Ubuntu 22.04 LTS release notes 随后确认 Firefox 在 Ubuntu 中只以 Snap 提供；Canonical 的 Firefox Snap 性能说明说明了跨发行版更新与维护方面的收益，也记录了首次启动的性能代价。后两项访问于 2026-09-03。 ↩︎
Sarker, J., Turzo, A. K., Bosu, A. The Landscape of Toxicity: An Empirical Investigation of Toxicity on GitHub, Proc. ACM Softw. Eng. 2(FSE), Article FSE029 (2025), 24 pages，DOI 10.1145/3715744，作者公开全文。研究覆盖 2828 个分层抽样项目和约 1.015 亿条 pull request 评论。从 ToxiCR 判为毒性的评论中随机抽取 600 条，人工确认 532 条，精确率（precision，而非 accuracy）为 88.8%。辱骂性语言最常见，其次是引战和侮辱。回归分析中，项目热度与毒性流行率正相关，issue 解决率与之负相关，企业赞助项目更可能属于低毒性组。表 4 中，控制模型内其他变量后，游戏项目相对非游戏项目进入高毒性组而非低毒性组的优势比为 7.259，约 7.26；这不是毒性评论发生概率的倍数。既往毒性表达也与再次发表同类评论、成为攻击目标相关。论文将这些结果表述为统计关联，不作因果推断。研究分类包含面向人、自己和软件对象的表达，不能全部等同为对他人的敌意。“毒性形态与一般社交平台不同”不属本研究的结论，见 ^[6:1]。 ↩︎
Brady, W. J., Doyle, M., Elnakouri, A., et al. Redesigning algorithms to intervene on social norm misperceptions during a national election，Nature 655(8124): 942–956 (2026)，2026-05-27 在线，DOI 10.1038/s41586-026-10536-1。预注册 Registered Report（stage 1 protocol: https://osf.io/c9a3m）。Bluesky 平台，n = 2000 美国两党活跃用户，跨 2024 年大选八周，约 2000 万条帖子，三条件随机分配。文中 37% 与 80% 是道德愤怒与政治内容相对逆时序基线的增幅，Northwestern 新闻稿中的表述为 increased by roughly 37 percent before the 2024 election and nearly 80 percent after it；它们是放大幅度，不是这两类内容的占比水平，也不是整体内容的放大幅度。平台享受度原文为 comparable。阴性结果原文：the engagement-based feed did not significantly change participants' own posting, liking or sharing behavior。该研究还发现，用户低估了其他人认为毒性帖不恰当的程度。 ↩︎ ↩︎
Milli, S., Carroll, M., Wang, Y., Pandey, S., Zhao, S., Dragan, A. D. Engagement, user satisfaction, and the amplification of divisive content on social media，PNAS Nexus 4(3): pgaf062 (2025)，DOI 10.1093/pnasnexus/pgaf062。Twitter 预注册算法审计，n = 806。 ↩︎
Guess, A. M., et al. How do social media feed algorithms affect attitudes and behavior in an election campaign?，Science 381: 398–404 (2023)，DOI 10.1126/science.abp9364。实验把 Facebook 与 Instagram 的 feed 改为逆时序排列；虽然参与者看到的内容和平台内行为发生变化，但在三个月的实验期内，议题极化（issue polarization）、情感极化（affective polarization）、政治知识及其他关键态度没有显著改变。同批另有 10.1126/science.add8424、10.1126/science.ade7138、10.1038/s41586-023-06297-w。原论文另有两次勘误：10.1126/science.adu8261（2024）与 10.1126/science.aeh2575（2026）；涉及 Instagram 数据指标的处理与定义，不影响本文引用的实验效应结论。 ↩︎
Miller, C., Cohen, S., Klug, D., Vasilescu, B., Kästner, C. "Did You Miss My Comment or What?" Understanding Toxicity in Open Source Discussions，ICSE'22, pp. 710–722，DOI 10.1145/3510003.3510111。对 100 条毒性 issue 讨论的定性分析，属非代表性抽样，不能据此推断流行率。 ↩︎ ↩︎
Brady, W. J., McLoughlin, K. L., Torres, M., Luo, K. F., Gendron, M., Crockett, M. J. Overperception of moral outrage in online social networks inflates beliefs about intergroup hostility，Nature Human Behaviour 7(6): 917–927 (2023)，DOI 10.1038/s41562-023-01582-0。研究通过 Twitter 现场调查比较作者自报与观察者判断，并用预注册实验检验这种偏差的后果；观察者系统性高估了发帖者的道德愤怒程度。 ↩︎