我们到底在争论什么:技术讨论如何从工程分歧变成身份冲突
导读:我原本以为自己在讨论技术
这篇文章来自一次失败的写作。
最早那版 snap.md 的第一句是"一个被情绪放大的标签"。它从一开始就在同时做两件事:核查 Ubuntu 与 Snap 的事实,同时纠正社区对这件事的舆论。写到后来,文章里长出了"社区偏见从何而来"这样一整章,桌面中心主义、自利归因、回声室被放进一项打包格式的技术论证里。结语同时承担"总结 Snap"和"劝社区理性"两个任务。
两个话题被杂糅在一起,是因为它们看起来是同一个话题:讨论 Snap 的人确实在互相贴标签。但研究对象不同。一个是软件该如何分发、维护责任如何分配;另一个是为什么对责任分配的不满,会被表达成"这个技术客观上很垃圾"。前者可以核查,后者需要另一套工具。分开之后,snap.md 只做前者,本文只做后者。
写这篇文章的人也是本文的案例,因此需要先交代作者自己的位置。第一版里有"你又有什么资格一口咬定""这种批评本身失去了成立基础"这类句子。它们不指向任何具体的对话者:写的时候屏幕上没有对方,句子是在跟一个想象中的反方说话。也就是说,那篇文章正在批评的机制,在它自己的句子里运行了一遍。把这类句子改温和不能解决这个问题,机制仍然在,只是换了一种措辞。所以本文不设"社区应当如何"的建议对象,它只处理自己的判断与参与方式。
本文的研究对象是一句话:
一个原本可以讨论约束、证据和工程取舍的问题,通过哪些机制开始围绕阵营和人的身份运转。
这里还有一个比约束和证据更早的前提:双方至少要知道当前正在回答什么问题。这个问题可以是事实比较,例如"macOS 与 Windows 的 HDR 实现有什么差异";也可以是工程选择,例如"主要做 HDR 工作时,应该选择 Mac 还是 Windows"。事实比较可以为工程选择提供依据,但两类问题的答案不能互相替代。
如果讨论的是 HDR 实现,"我不会使用 Mac"只说明个人选择,没有回答 HDR 本身。如果讨论的是选择哪套系统,软件兼容性、使用习惯和维护成本才可以作为约束或权重进入比较。后文的效用函数主要处理后一类评价与决策问题;事实命题是否成立,不取决于个人给相关属性分配了多大权重。回答从前一种问题跳到后一种问题时,需要先把话题的变化说清楚。如果双方连当前问题都无法对齐,也就没有必要继续排查后面的条件、证据和权重。
不讨论以下几类问题:
- Linux、Windows、Snap、Arch、鸿蒙谁更好,不作评价;
- 不把任何社区整体作为被告;
- 文中的案例只证明行为存在,不证明比例;
- 不讨论如何改造网友。
关于文中的记号:
本文中的记号用于明确变量、作用域、逻辑关系和推断边界。它们不是对技术社区进行参数估计的经验模型,除特别注明外不代入数值。
五章的顺序是这样安排的。第 1 章先区分事实比较与工程选择,再说明为什么两个熟悉各自场景的人会选出相反的方案:约束与权重不同就够了,不需要任何一方出错。第 2 章处理证据,说明"我的机器就是这样"给出的是一次条件实现,不是系统的固有常数,双方看到的是各自那几次实现。第 3 章处理身份,说明分歧在什么时候不再关于技术,以及为什么身份判断无法被证据更新。第 4 章处理可见性,说明少数冲突为什么会变成我们眼中的"整个社区"。第 5 章把前四章合成一套处理顺序:先确认当前问题,再核查能核查的项,剩下的要么接受,要么停止。
1 不同的目标与约束:为什么两个熟悉各自场景的人会选出相反的方案
两个人都熟悉自己的机器,都能读懂上游的 issue,引用的数据也没有出入,最后仍然选了相反的方案。这一章要说明这种情况为什么不需要任何一方出错。
1.1 先分清是在比较事实,还是做选择
技术讨论先要区分两件事:是在比较对象的技术属性,还是根据这些属性做选择。前者问"两个系统的 HDR 色彩管理和显示链路有什么差异",答案要靠文档、实现和测试来确定;后者问"哪套系统更适合自己的 HDR 工作流",除了技术属性,还要考虑软件兼容性、使用习惯和维护成本。把"我不会用这个平台"拿来回答前一种问题,就是用选择结论代替了属性比较。
后文用 表示对象的属性,用 表示一个人对这些属性的估计。到了评价和选择问题,才需要引入权重 ,并用 表示个人在一组约束下形成的排序。一个人可以把 HDR 的权重设得很低,但这不会改变两个系统的 HDR 实现有什么差异。
技术社区里最常见的一类提问是"Flatpak 到底好不好用"、"Arch 和 Ubuntu 哪个更好"。如果这些句子是在询问如何选择,它们还缺少三个参数:要达成什么、在什么约束下、后果由谁承担。
把参数补上,同一个问题会分化成若干个不同的问题。给父母使用、需要自己远程维护的电脑选系统,与给自己的开发机选系统,本来就是两个问题。提问者把它们合并成一个问题,回答者各自默认了一组参数,争论于是发生在一个没有被明说的分歧上。
补齐这三个参数不改变任何技术事实,只改变问题的答案。它也是成本最低的一步。
1.2 一个技术对象是一组属性,不是一个分数
可以先把被讨论的对象写成一组属性:
用这个写法看,一个对象在不同属性上表现不同是常态。我在 Windows 上的体验就属于这种:Unreal Engine 的工具链、Windows Terminal、PowerToys 都是好用的,同一系统里某些 UI 决策和某些硬件上的睡眠唤醒体验则很差。这些判断落在 的不同分量上,彼此并不冲突。
把对象压缩成一个总分会丢掉两样东西:它好在哪、差在哪。而这两样恰恰是讨论能够推进的部分。剩下的只有一个名次,名次上的分歧无法再往下拆。
1.3 每个人都完成了自己的排序
有了属性向量,还需要一套权重才能选出方案。设第 i 个人在各个属性上的权重为 ,他对方案 x 的评价写作:
本文使用线性加权,是为了把属性估计与评价权重明确分开。这个写法把各项属性放在可比较的尺度上,并近似认为它们对评价的影响可以相加;真实决策还可能存在阈值、属性交互和非线性关系。后文真正使用的是"对事实的认识"和"怎样评价这些事实"之间的区别,换成带阈值或交互项的模型,结论仍然成立。像"必须支持某个软件"这样不能由其他优点补偿的条件,应当放入下一节的约束集 。
这里 是第 i 个人对属性向量的估计,不是真值。必须把两者分开:一个人读错了源码、看错了版本号、把别人的测试当成自己的测试,他的 就会偏离 ,而他排出来的序仍然可以自洽。第 2 章再处理估计偏差,本章暂时假定估计无误。
每个人用自己的 乘上属性向量,就得到一个数。数与数之间可以比大小,所以每个人内部都有一个完整排序;给定他自己的权重和估计,这个排序通常没有算错。
出问题的是下一步:把自己在 下得到的私人排序,当成所有人应有的排序。
与 不同时,两个人可以在全部技术事实上没有分歧、都没有逻辑错误、都熟悉自己的场景,最后仍然选得不同。这种情况不需要任何一方出错,也不需要任何一方不诚实。
Arch 与 Debian 是一组典型的例子。看重软件新鲜度、愿意自己承担维护责任的人会选 Arch;看重 ABI 稳定性、希望升级窗口内行为可预测的人会选 Debian。两人对这两个发行版的实测属性可以没有出入,排序相反的原因是新鲜度与稳定性在各自 上的分量不同。
Snap 与 Flatpak 也是。看重 CLI 与 IDE 打包、上游直接发布的人,与看重启动时间、主题一致性、打包来源可审计的人,可以在实测数据上达成一致,仍然选得不同。把可审计性放在很高的权重上,本身是一项权重选择,它不构成对"更在意启动时间"的反驳。
1.4 四类分歧,以及为什么权重排在最后
权重不同只是分歧的一种来源。按可核查程度排列,有四类:
| 争议对象 | 典型表述 | 识别方式 | 处理方式 |
|---|---|---|---|
| 约束集 | 环境必须无 root / 必须离线 / 必须过合规 | 可行域不同,不是权重大小 | 先对齐约束,否则不必继续 |
| 属性估计 | 这个设计增加维护成本;启动慢约 300 ms | 有事实答案,可以核查 | 核对证据 |
| 对未来的预测 | Wayland 三年后会不会成熟 | 当前不可判定 | 约定检验时点与依据 |
| 权重 | 我更在意启动时间 | 统一估计后排序仍然相反 | 说明偏好,接受分歧 |
约束可以对齐,估计可以核查,预测可以约定检验时点,前三类都能借助双方之外的资料或后续观察继续处理;权重没有对错,只能说明。因此,排查要按上表自上而下进行。只有排除另外三类原因之后,才能把剩下的差异归结为"我们只是偏好不同",不能一开始就作出这个判断。
如果先谈权重、后核查属性估计,事实分歧就会被误判为偏好分歧。一个人说"Snap 启动慢",另一个人回"这是你的偏好"。启动时间可以测量,属于估计层面的分歧。只有把启动时间测准、两人都接受同一个数字之后,如果一个人仍然认为三秒的启动不可接受而另一个人不介意,分歧才落到权重上。
1.5 技术选择改变的是成本的分布
技术选择还改变一件事:成本由谁承担。用户、维护者、上游、厂商、管理员各自承担的部分会随选择变化。在没有共同度量和权重时,直接把这些成本相加得不到可比较的"总成本";即使把工时、费用和风险换算到同一尺度,换算方式本身也包含一组权重。因此这里先比较成本如何分布,再说明不同主体如何评价这项分布。
让人不满的主要来自决策权与成本承担的错配:做决定的人不承担后果,承担后果的人做不了决定。
Ubuntu 把 Firefox 从 deb 换成 Snap 是一个可以直接观察的例子:Mozilla 可以直接发布更新,Ubuntu 维护者减少了跨发行版维护软件包的工作,用户则要适应首次启动性能和 apt 安装结果的变化[1]。收益和成本都真实存在,落在不同的主体上。
不过,并非所有技术选择都只是在重新分配成本。包管理器相对源码编译、容器镜像相对手工配置环境,都可能在多个重要属性上同时改善。这类选择的争议也小得多。争议激烈的技术选择多为再分配型。
成本重新分配还会造成一类常见的表述错位。多数"X 不好"的实际内容是"我不想承担这项成本",但被表述成一个关于技术对象的客观判断。把这层意思说清之后,争论会从"这个技术是不是更差"变成"这项成本应该由谁付"。后一个问题有具体的答案,也可以谈条件。
1.6 小结
两个人可以在技术事实上没有分歧、估计都正确、推理都没有错误,仍然选出相反的方案,原因是权重与约束不同。只有排除约束分歧、估计分歧与预测分歧之后,才能把剩下的差异归因于权重。技术选择还会重新分配成本,多数"X 不好"表达的是成本归属上的不满。下一章处理一个更常见的困难:双方连属性估计都还没有对齐。
2 有限的证据:为什么"我的机器就是这样"结束不了争论
第 1 章假定双方的属性估计都准确。实际讨论中这个假定通常不成立。两个人给出相反的技术判断,常常与排序方式无关:他们手上的数字本来就不同,或者他们没有在比较同一批属性。这一章处理这两种情况。
2.1 一次体验是条件量,不是系统的固有常数
故障是否发生,取决于一批配置:
是能被观察到的那部分配置,不是完整的因果变量集。微码版本、负载时序、固件内部状态通常没有被记录,它们构成残余随机性。所以即使 全部给定,故障也不是确定的。
下文用 表示一次尝试的结果: 表示发生故障, 表示没有发生。
社区排查挂起恢复问题时,经常把 NVIDIA 驱动版本和内核版本放在一起记录。同一个用户在升级内核或驱动之后,挂起恢复可能从失败变为正常,也可能在下一次升级后又失败。因此,比较不同用户的体验时,需要把故障报告放回具体的 。
2.2 每个人只看到自己那次实现
两个人报告相反的结果,常常与诚实程度无关,他们抽到的是不同的条件:
与 是两组条件下单次尝试的二值随机变量。一个人能观察到的是它们的一次或少数几次实现,不是整个条件分布。所以"我的机器就是这样"给出的是一个样本,不是一个概率。
比"n = 1 没有信息"更准确的说法是:一个个案携带的信息非零。在 下观察到故障这件事本身能区分两组条件,证据强度是两种条件下出现该结果的似然之比。问题在方差:一次实现无法把一个条件概率估计到有用的精度。
由此有一条实际含义:推翻一个全称判断所需的信息,远少于刻画一个问题所需的信息。说明"它确实会发生",一个个案就够;说明它有多常见,个案做不到。
2.3 个案能证明存在性,通常不能证明发生率
| 陈述 | 能推出 | 不能推出 |
|---|---|---|
| 我遇到了 | 这种情况至少可以发生 | 多数人都会遇到 |
| 我没遇到 | 至少存在不触发它的配置 | 它不存在 |
"我无法复现"与"你的问题不存在"是两个命题。前者是关于一组配置的陈述,后者是关于全部配置的陈述。把前者当作后者的证据,是技术讨论里最常见的一步跳跃。
那么把许多个案合起来,能否估计发生率?这里至少有两个关键条件: 被记录且组内同质,以及抽样与结果无关。第二个条件通常不成立,原因在第 4 章说明。
2.4 没有在看同一批维度
前两节处理的是双方在同一批属性上看到了不同环境下的结果。还有另一种情况:双方没有在比较同一批属性,于是连"结果不同"都谈不上。
记 表示第 i 个人在维度 k 上有一个有依据、原则上可核查的认识,依据可来自自己复现、官方文档、源码、issue 或测试。 表示这个维度目前没有可核查依据; 仍然需要一个输入,所以 中可能保留着未经核查的估计。
不进入 的表达式,只标记哪些分量目前已有可核查依据。这样"有依据但读错了源码"和"没有依据"能区分开:两种情况下 都可能偏离真值,也都可以被新证据更新,区别在于更新之前是否已有依据可供检查。
例如,一个人主要用 Flatpak 安装桌面 GUI 应用,实际测试过文件选择、屏幕捕获和权限调整;另一个人尝试用 Flatpak 运行 CLI 工具和 IDE,核查的是命令入口以及访问宿主工具链的方式。两人掌握的都是 Flatpak 的实际表现,但证据落在不同维度。前者的 GUI 使用经验不能回答 CLI 与开发工具的问题,后者的经验也不能代替桌面集成测试。如果双方都没有检查对方所谈的维度,他们的分歧只是证据覆盖不同,还不是同一维度上的证据冲突。
2.5 一条证据只有在更新估计时才起作用
这一节单独考察证据对属性估计的影响:更新过程中保持约束 与权重 不变,只让 随证据变化。如果新信息同时改变了约束或权重,评价的总变化还要计入那部分影响,不能只用下面的 表示。
把两个方案的评分差写成 ,第 i 个人的判断可以写成:
其中 是更新前的差值, 是这条证据更新到的维度集合,, 是更新后的值。未被这条证据更新的维度估计不变,即 时 ,因此更新只通过 中的项进入 。翻转条件由 展开得到。
理解这个式子时,需要分清维度差值、证据推力和判断翻转各自指什么。
是两个方案在同一维度上的差,不是该维度的水平。告诉对方某个维度的绝对读数,不改变 ,也就不产生推力。
是推力,不是判据。翻转还要看 :原先的立场越强,把它推过去需要的 越大。同一条证据能说服一个本来就在摇摆的人,说服不了一个立场很强的人。
的情形是从无意见到有意见,不属于翻转。
这个式子的关键在于, 取决于估计发生了多少更新,而不是同一条证据出现了多少次。由此可以推出三个与讨论直接相关的结果。
同一条证据被转述 n 次,第一次纳入估计后,后续转述没有增加信息内容,因而不会继续产生 。这里的"重复"专指信息内容没有增加的重复转述,不包括彼此独立的复现实验。独立实验会提供新的观测,可能改变我们对测量误差或发生率的判断,仍然属于新证据。
证据指向的维度若 , 也是 0。对方的排序不变,未必是态度问题,那个维度在他的权重里本来就是 0。
如果一个没有可核查依据的维度此前被近似为"两个方案差别不大",也就是 ,那么一组有区分力的新数据会补上这一维的差值,产生较大的 。这是讨论最容易改变排序的一种情形。没有依据的人也可能持有很强的先验或错误估计,因此 本身并不推出 。
不过,覆盖维度较少并不必然增加判断误差。如果一个人掌握的恰好是主导维度,他的排序仍然可能是对的。
2.6 讨论能扩大的是共同核查范围
讨论能推动的是 与 :发现遗漏的维度、核查彼此的依据、修正读错的属性值。它不要求 ,也不要求 。
讨论能做的是扩大双方共同核查过的事实范围;权重和结论不必相同。
"权重和结论不必相同"只说明讨论不以统一立场为目标,并不意味着结论一定不会改变。对齐估计之后,排序可能翻转,也可能不翻转;2.5 的式子给出了两种结果各自的条件,两者都是正常结果。
这里所说的"共同核查"并不是把双方提出的维度直接合并。双方各自提出的维度先构成一个候选集,经过证据检查之后才成为共同核查范围,后者是前者的子集。一个人提出一个维度,另一个人仍然需要核查它,提出这个动作本身不构成证据。
维度清单本身是开放的。"你根本没有考虑可维护性"是在提出一个新维度,这是合法动作:与当前问题相关的那批维度,常常是在讨论过程中才变清楚。
2.7 掌握的维度多,不等于判断更正确
前面的分析还可能引出一个错误推论:掌握的维度越多,判断就越正确。这个推论不成立,原因有三个。
第一,自称掌握了更多维度,本身仍是一项待验证的陈述,提出时同样需要给出来源。
第二,掌握维度的数量、估计的准确程度、维度在权重中的重要程度,是三个不同的变量。
掌握维度的数量不能单独决定判断误差。
反例可以自己构造:一个人在九个影响很小的维度上都有可靠依据,权重却全压在他没有依据的第十个维度上;另一个人只掌握第十个维度,判断误差反而更小。
第三,专业经验能提高一个人的来源可信度,不能代替当前命题的证据。长期维护 Mesa 的开发者谈 Mesa,比刚接触 Linux 两天的人更值得作为信息源。但技术问题通常允许查源码、给日志、引 issue、做实验,核查命题本身优先于核查提出者的身份。
专业经验不能代替当前命题的证据,这个限制对本文同样适用。我核查过 snapd 的沙箱模型,但这不代表我也熟悉 systemd 的每一项具体行为;如果在只有二手认识的问题上与人争论,过去积累的其他知识不能补上当前证据的缺口。
2.8 从反驳转向比较
把前面几节合起来看,遇到相反的技术报告时,可以问三个问题:我们的 有何不同?你在哪些维度上有可核查的依据?这份证据会更新哪个估计值?这些问题都有具体答案,也都能核查,比"我的没问题"、"你根本不懂"、"这系统就是垃圾"更能推动讨论。
2.9 小结
一个个案能证明某件事可以发生,通常不能证明它有多常见;两个人的分歧也可能来自他们没有在比较同一批属性。讨论能推动的是估计与可核查依据,权重和结论不必随之统一。但如果分歧在证据给足之后仍然不收敛,起作用的就不再是信息问题。下一章处理这种情况。
3 身份:分歧什么时候不再关于技术
第 2 章处理的是信息不足。信息补足之后,双方的事实估计应当靠拢,结论仍然可以因为权重不同而相反。还有一部分争论既不再核查事实,也不再说明权重:日志贴了,复现步骤给了,上游 issue 引了,话题却换成了你是什么人。这一章处理这部分。
3.1 技术投入可能逐渐成为身份的一部分
一个人花了几百小时配置 Arch,读过 systemd 的文档,能在邮件列表里回答别人的问题。这些投入既提高了他处理实际问题的能力,也帮助他在社群中获得一个被承认的位置。当能力与社群位置绑在一起,别人批评这项技术时,他也更容易觉得自己的能力和地位同时受到质疑。
学习投入会提高熟练度和自我效能,也会帮助一个人形成社群归属,技术选择由此可能成为身份的一部分。这个过程也可能反向发生:一个人先接受某个社群位置,再按照这个位置挑选技术立场和解释方式。本文只用这组关系说明技术投入与身份如何相互加强,不比较各环节的效应大小。
社群规模扩大后,成员之间往往缺少持续的相互了解,技术知识也可能成为判断圈内地位的捷径。掌握更多内部规则的人可能获得更多话语权,工具选择也更容易被用来区分"内行"和"外行"。这时,对工具的批评就可能被理解为对使用者能力和位置的否定。
技术投入既提高认识,也会影响一个人面对批评时的反应,这在本文的写作过程中同样存在。写 snap.md 时,我查阅了 snapd 的打包配置、confinement 文档和一批 issue。这些投入让我在相关技术问题上有了更多可核查的依据,也让我对"Snap 就是垃圾"这类话的反应强于对普通技术批评的反应。这种影响本身不能决定判断对错,却会影响我更新置信度的速度。
3.2 回路跑起来之后,身份会自己维持
把上一节的机制与可见性结合起来,可以得到一条回路:
技术投入 → 身份绑定 → 批评被感知为对身份的威胁 → 敌意表达增加 → 高互动内容获得更多可见性 → "对面都是这种人"的印象增强 → 群体边界强化 → 回到身份绑定
这张机制图把本文各部分连了起来。第 4 章的研究为"可见性"这一环提供了经验依据;其余连接是根据前文现象提出的机制假设,用来解释反馈方向,不比较效应大小。
身份在这条回路中是一个状态变量。前两章讨论的 与 可以随新证据变化。事实证据直接更新的是属性估计与证据覆盖;它也可能影响偏好,但核查事实并不保证 随之改变。
身份判断遵循另一套解释规则。关于技术命题的证据通常只能检验技术命题,不能自动说明一个人属于哪类群体。身份判断缺少这种更新关系时,原来的分类可以在没有新依据的情况下继续维持。这解释了事实估计靠拢之后,为什么有些争论仍然不收敛。
这条回路能够自我维持,还有一个原因:双方会把彼此的敌意当作支持自身态度的证据。我看到你的语气恶劣,你认为我先挑衅,各自都把对方的行为当作自己态度的辩护。此时一方单方面降低敌意要付额外成本,因为在这一方所属的群体内部,缓和会被读成认输。
3.3 身份判断的问题在于缺少反证条件
技术判断可以检验。"这个设计在配置 Z 下容易出问题"有反证条件:给出配置、日志、复现步骤,置信度会移动。
身份判断往往缺少这样的条件。"对方是孝子"这类判断之所以很难被证据推翻,不是证据还不够强,而是解释规则可以随时追加:你举证,解释为急着洗地;你沉默,解释为被戳穿了;你承认部分错误,解释为被迫让步;你语气平和,解释为在装。每一种新观察都被吸收到原来的结论里,提出者也就不必修改判断。
先看有没有一个可观察结果会让提出者撤回这项判断;找不到,这项判断就不进入事实讨论。
这个检查不需要估计概率,只要设想一个可能出现的结果,再看它是否会使判断失效。Windows 讨论里的"Microsoft 孝子"、鸿蒙 PC 讨论里的"支持"与"'爱'国",都属于这一类。
这个撤回条件也构成第 5 章的停止判据:如果解释规则让任何观察结果都无法推翻原判断,那么继续补充技术证据也不会改变它。5.3 节把它改写成可以直接使用的判断,附录 C 再给出对应的信息论记号。
3.4 五层陈述
技术讨论里的句子可以按它们承担的内容分层:
| 层级 | 例子 | 处理方式 |
|---|---|---|
| 事实 | snapd 以 GPLv3 发布 | 核查 |
| 经验样本 | 我的笔记本无法休眠 | 补全条件 |
| 工程评价 | 这种设计的维护成本太高,不值得采用 | 先核查成本,再比较约束与权重 |
| 偏好 | 我更喜欢 KDE | 不必举证 |
| 身份判断 | 真正懂 Linux 的都用 X | 几乎不含可核查的技术信息 |
前四层在第 1、2 章都有对应的处理动作,第五层没有。事实要核查来源,答案与提出者的身份无关;经验样本要补全条件,一次实现不能单独推断发生率;工程评价要先拆出其中可核查的属性判断,再确认约束并比较权重;偏好只需说明,不必证明。身份判断则要追问:什么可观察结果会让提出者撤回?找不到这样的结果,它就不进入事实讨论。
分层是为了找出争论在哪一步换了对象。多数冲突来自跨层跳跃,四类最常见:
- 由样本推总体:从一次体验推出某种技术整体的性质,错在把 条件下的一次抽样当成总体结论。
- 由偏好推规范:从自己的偏好推出别人应当如何。操作系统可以是工具,也可以是玩具,两种用法都成立;把自己的玩法升级成别人的义务则不成立。
- 由评价推身份:从"这个设计有问题"推出提出者属于某一类人,结论的对象已经从设计换成了人。
- 由解释推忠诚:从某人正在解释一项技术的约束,推出他站在哪一边,把关于事实的陈述读成了站队声明。
还有一类很常见,也不属于上面四类:评价伪装成事实。"这 API 是垃圾"在语法上是关于对象的陈述,实际内容是一项工程评价。它被当作可核查陈述提出,对方按事实去核查,一方在表达评价,另一方却在核查事实,双方实际回答的是不同问题。
这时应先确认是在核查 API 的可观察属性,还是讨论它是否适合某个用途,再决定继续检查证据还是比较权重。
3.5 话题已经换掉的几个信号
分歧从技术层面转到身份层面,有一些可以直接观察的信号:
- 开始统计对方的身份,而不是对方的论据。
- 开始引用第三方对某人过往言行的评价,作为当前命题的证据。
- 把"你用什么系统"当作一项论据。
- 要求对方先自证立场,才允许他发言。
讨论换了题的标志,是对象从命题是否成立变成你是什么人。
不过,并非所有身份信息都与技术讨论无关。一个人自称 Arch 用户、长期维护某个驱动,是在交代自己的条件与经验范围,可以提示我们追问他在哪些维度上有依据。真正让某个 的,仍然是他在相应维度上能够给出的复现、文档、源码、issue 或测试。区别在身份信息的用途:用来说明判断来自哪些经验,还是用来判定对方的资格。
3.6 小结
技术投入可能逐渐成为身份的一部分。身份进入反馈回路后,即使没有新的技术证据,原有判断也可能继续维持。这是事实估计靠拢之后分歧仍然不收敛的原因之一。身份判断之所以常常不随技术证据更新,是因为解释规则可以被临时追加。识别这种情况,可以问:什么可观察结果会让提出者撤回?
4 可见性:为什么少数冲突会变成我们眼中的"整个社区"
一篇文章有几千人读过,留下几十条评论。读者对这个话题"大家都在说什么"的印象来自那几十条;剩下几千人读过、想过、没有说话,不构成任何印象。这个比例不需要测量,打开任意一个热门讨论都能看到。
前几章处理的是两个人之间为什么谈不拢。这一章处理另一件事:即便只有一小部分人谈不拢,我们也可以获得"整个社区都这样"的印象。
4.1 能看到的内容是筛过的
记 为一条观点或一次发言,它在某个社群里的实际分布写作 。你看到的分布与它之间差了两个因子:
是持有这个观点的人把它说出来的概率, 是它说出来之后被你看到的概率。两个因子都随 变化,所以 与 可以是两个形状不同的分布。
这个式子描述的是一轮观察,使用时还要把三件事放回具体场景。
第一,它是一张单轮快照。真实社群里 与 会互相塑造:3.2 那条回路里,高互动内容获得更多可见性,可见性又改变下一轮的表达分布。连续多轮观察时,需要把这种反馈也算进去。
第二,只有不同观点或经历对应不同的发言意愿时, 才会改变分布的形状。故障讨论就是这样:机器正常的人通常没有发帖的动机,机器坏了的人却有,于是负面个案在已发表内容中的占比会高于总体。
第三, 与 要在固定 下理解。发言意愿本身依赖环境,2.1 那批配置里谁的机器刚好出问题,谁就更可能发帖。把不同配置下的人汇总到同一个分布里,会同时引入两种偏差。
于是你采样到的是 ,不是 。
近两年关于鸿蒙 PC 的讨论是一个可见度很高的例子。参与者在两个方向上互相贴标签,技术论证的密度低于标签的密度。这个例子在本文中用来观察讨论形态:无论哪一边的读者,看到的都是被 筛过的样本,两边都据此认为"对面全是这种人"。
4.2 选择偏差与样本相关是两个机制
选择偏差与样本相关经常被混为一谈,但它们问的是两个不同的问题:一条观察为什么进入样本,以及已经进入样本的观察之间是否独立。
选择偏差改变分布的形状。在故障和投诉类话题中,是否遇到问题会影响发言动机,因此个案进入评论区的概率可能与结果相关。少数遇到问题而且愿意发言的人,可能贡献评论区里的大部分故障叙述。评论区由此不能直接视为总体的随机样本;随机抽取一百位用户询问同一个问题,可能得到不同的分布。
选择也可能发生在观察者一侧。如果一位技术评测者因批评某个平台而受到支持者攻击,长期关注这个平台的人容易把它记作该社群的特征;关注其他系统或品牌争议的人,也更容易记住另一批相似案例。这些事件都可能真实,但观察者若只从自己熟悉的对象取样,仍然无法比较不同群体中这类行为的比例。
样本相关会使似然无法按独立观测直接分解。一百条看同一个视频后发出的相似评论,可能共享内容刺激、传播链和社群环境等因素。在没有处理这些聚类结构之前,不能直接把它们当成一百个彼此独立、可以等量用于总体推断的观测;否则会低估判断中的不确定性。
两种机制可以单独出现,也可以同时出现。高度正相关的一百条观察,其有效信息量通常低于一百条相互独立的观察;存在选择偏差时,原始样本即使很大,也不会自动具有总体代表性。
这也回答了 2.3 留下的问题:要把一百份个案合起来估计发生率,除了记录 ,还要知道个案进入样本的方式。4.1 中的 会让发言概率随经历变化, 又会继续改变哪些发言能够被看到。
评论区只给出已经发表并且可见的内容,通常没有提供全部用户这个分母。分母需要通过遥测、随机调查等其他渠道获得。
所以"评论区里全是抱怨"只能说明可见样本偏向抱怨。仅凭评论区,无法区分总体中的故障本来就多、遇到故障的人更愿意发言、平台提高了抱怨的可见性,还是三种情况同时存在。4.1 的式子直接说明了这个限制:只观察 ,不能分别求出 、 与 。
4.3 表达端与可见性端都有经验依据
4.1 的式子把总体观点、发言意愿 与内容可见性 分开。现有研究还没有为技术社区里的这几个量给出一组可以直接代入的参数,但已经为机制的两端提供了经验依据:GitHub 数据说明敌意表达确实存在于开源协作中,Bluesky 实验则说明排序方式会改变敌意内容的暴露量。
第一项在开源社区。Sarker、Turzo 与 Bosu 对 2828 个分层抽样的 GitHub 项目做了大规模分析,覆盖约 1.015 亿条 pull request 评论,用 ToxiCR 自动分类后,从判为毒性的评论中随机抽取 600 条进行人工校验[2]。辱骂性语言(profanity)最常见,其次是引战(trolling)与侮辱(insult)。回归分析还发现,项目热度与毒性流行率正相关,issue 解决率与之负相关;企业赞助项目更可能属于低毒性组。在回归模型中,游戏项目被归入高毒性组(相对于低毒性组)的优势比约为非游戏项目的 7.26 倍。过去发过毒性评论的人也显著更可能再次发出同类评论,并成为毒性评论的目标。这些统计关联说明,敌意表达在开源协作中具有可以重复观察的结构,并非几条偶然被挑出来的评论;各项关联的因果方向则需要另行研究。
第二项在社交平台。Brady、Doyle、Elnakouri 等人在 Bluesky 上做了一项预注册的大规模实验:2000 名美国两党活跃用户,跨 2024 年大选的八周,约 2000 万条帖子,随机分入三种排序(互动优先、逆时序、以及研究者设计的"极端度分散"排序)[3]。相对逆时序基线,互动优先排序放大了群体间敌意、道德化、情绪化与毒性政治内容,其中放大幅度最大的两项是道德愤怒与政治内容:相对逆时序基线的增幅,选前约 37%,选后接近 80%。替代排序降低了这类内容的暴露量,平台享受度保持相当。
这项研究还发现,改变排序没有显著改变用户自己的发帖、点赞与转发行为。排序先改变了用户看到什么,却没有在实验期内改变用户自己怎样发帖和互动。这把两个经常混在一起的过程分开了:平台可以先改变一个社群看起来是什么样,再谈这种暴露是否会改变参与者本身。
把两项研究放在一起,本文据此作出一个机制判断:技术协作场景中本来就存在敌意表达,分发机制又能改变这类内容获得的可见性,因此我们看到的敌意是表达端与可见性端共同作用的结果。把它全部归因于社区成员的整体态度,会漏掉可见性筛选;把它全部归因于算法,也会漏掉已经发生的表达。GitHub 研究没有观察未发言者,Bluesky 实验的对象也不是技术社区,所以这个判断用于确定机制方向和拆分问题,不用于估计 、 各自贡献了多少。
对 Twitter 的预注册算法审计同样发现,互动排序会放大情绪化与外群体敌意内容,同时也提醒我们替代排序可能强化同立场内容[4]。Miller 等人对 100 条开源社区毒性讨论的定性分析提供了类型上的证据:开源协作中的敌意有自己的表达形态,这项研究回答的是"怎样出现",不是"多常见"[5]。把 Facebook 与 Instagram 的 feed 改为逆时序排列,在三个月的实验期内没有显著改变研究测量的关键政治态度[6];它与 Bluesky 的阴性结果一起说明,改变暴露和改变人的态度或行为是两步,不宜直接合并。
Brady 参与的两项研究还说明,可见发言不是群体态度的透明窗口。2023 年研究比较观察者的判断与作者自报,发现观察者往往高估发帖者的道德愤怒程度[7];2026 年研究则发现,用户低估了其他人认为毒性帖不恰当的程度[3:1]。前者测量对发帖者情绪的推断,后者测量对旁观者规范判断的估计。放在一起看,结论不是一项"高估"抵消另一项"低估",而是线上可见内容会在不同方向上扭曲我们对他人的认识。这也为 4.1 中 不能直接代表 提供了另一层证据。
4.4 为什么不同社群的体验差异巨大
同样是技术讨论,邮件列表、GitHub issue、论坛、视频评论区给人的体验差别很大。这种差别不需要用"某平台的用户素质更高"来解释,它来自一组结构性变量:
- 群体规模与重复相遇:一个二十人的邮件列表与一个二十万人的子版块,声誉的作用差别很大。
- 声誉能否累积:用过即走的场景里,一次发言不会留下记录;用户名与历史发言长期绑定的地方,记录会跟着人走。
- 上下文是否连续:邮件列表里一段讨论可以延续几个月,前情不必重述;短视频评论区每次都是新的一批人,上一轮已经澄清过的事情会被重新争论一遍。
- 内容发现方式:按时间、按热度或由推荐系统分发,会直接决定 的形状。
- 管理与规范:行为准则是否明确,以及是否被实际执行。
- 发言的社会成本:实名、半实名与匿名会带来不同的表达成本。
- 隔离程度:内容是否会被推送给社群之外的人。一个内部讨论与一个被推上热门的讨论,参与者的构成差别很大。
这些变量共同决定了 与 的形状,也就决定了你在那个地方看到的内容。社群文化是成员构成与媒介结构共同产生的结果。
这一组变量也解释了鸿蒙 PC 那个例子。在我的观察中,这些讨论大量发生在推荐流主导的平台上,社群边界不封闭,许多参与者只是一次性路过,声誉不累积,上下文也不连续。这些条件会改变谁更愿意发言、哪些内容更容易被看见。换成上下文连续、声誉可以累积的邮件列表,需要重新判断 与 ;现有观察无法预言同一批人会怎样表达。
4.5 最可见的声音不能代表整个社区
把前面几节合起来,本章的核心判断是:我们对一个社群的印象,往往主要来自其中最可见的那部分成员。哪些成员更愿意发言、哪些发言又能获得更多曝光,都会影响最后进入视野的内容。因此,一个社群最醒目的声音不能直接代表其成员及观点的整体分布。
因此,判断"某个社区是什么样"之前,要先问这个印象来自多少个样本,又是通过什么渠道形成的。
可见性筛选也影响了我自己的写作。snap.md 的传播主要来自其中的论战性内容,真正梳理打包格式的部分带来的传播很少。我的文章也从这种机制中获得过关注,因此不能只把它当作解释别人行为的工具。
4.6 小结
我们看到的观点分布经过了发言意愿与平台可见性两道筛选,与社群的实际分布形状不同。选择偏差会改变样本分布,样本相关会减少独立信息量。GitHub 研究让"开源协作中存在敌意表达"不再只是轶事,排序实验则为"分发机制改变暴露"提供了因果证据。两端合起来,足以支持本章的判断:要判断社群整体的观点分布,需要有分母、有代表性的样本,不能直接依据最可见的声音。最后一章因此先处理自己的输入源,再讨论什么时候参与、什么时候退出。
5 参与而不被消耗
前四章讨论了约束不同、证据有限、身份卷入和可见性放大。在进入这些层次之前,还要先确认双方是否在回答同一个问题。这一章把它们合成一套处理顺序:先确认当前问题,再排查能核查的项,剩下的部分要么接受,要么停止。
前面的分析处理的是"为什么会谈不拢",这一章处理"接下来做什么"。下面这张表给出排查顺序。
| 先排查 | 问什么 | 若成立 | 处理 |
|---|---|---|---|
| 当前问题 | 我们正在回答同一个问题吗 | 否 | 说明各自在回答什么;无法对齐就结束当前话题 |
| 约束 | 在同一个选择问题中,双方的可行条件是否不同 | 是 | 对齐约束,或按各自条件分别讨论 |
| 条件 | 我们的环境可比吗 | 否 | 逐维度比对配置、复现步骤、日志 |
| 覆盖 | 对方是否掌握了自己尚未核查、且可能影响结论的维度 | 是 | 提出并核查遗漏维度 |
| 估计 | 同一维度上我们的读数一致吗 | 否 | 核对证据:源码、issue、实验 |
| 权重 | 统一估计后排序仍相反吗 | 是 | 说明偏好,接受分歧,停止 |
| 身份判断 | 什么可观察结果会让对方撤回 | 不存在 | 停止技术讨论 |
使用这张表时,还需要注意五点。
第一,"当前问题"是整套流程的入口,不属于约束 。讨论技术属性与讨论如何选择方案,可以涉及同一个对象,却在回答不同的问题。前者先核查属性,后者才进入约束和权重;双方的问题不一致时,应先说明各自在回答什么。
第二,这张表按排除顺序排列,与 1.4 的分歧分类作用不同。它增加了"当前问题"这个入口,也纳入了第 2 章单独处理的条件 与覆盖 。当前问题可以澄清,约束、条件、覆盖和估计可以核查;只有对齐当前问题并排除后四类差异之后,才需要把分歧归因于 。身份判断若没有撤回条件,就无法进入这条核查路径。
第三,覆盖 不能直接观察,只能问出来。第四行的问法因此是"对方是否掌握了……",而不是"我们的覆盖是否不同"。
第四, 排在 之前。"这个维度有多严重"是事实问题,"这个维度有多重要"才是偏好问题。顺序颠倒会把事实分歧误判成口味分歧,然后过早地说"我们只是偏好不同"。
第五,掩码不可自证。对于没有依据的维度,无法区分"没有覆盖到"与"这个维度不存在或不重要",两种情形产生一样的数据。所以只能对自己有依据的维度举证,标准是对方原则上可以复现。这是 2.4 中 的定义决定的:掩码只标记哪些分量可核查,不判断未覆盖的分量是否重要,与姿态无关。
5.1 给结论加作用域
把作用域写进结论,一部分分歧不需要解决就消失了。
"Arch 更好"是一个没有作用域的判断,读者只能拿自己那组约束去套,套不上就反对。写成"在重视软件新鲜度、愿意承担维护责任的条件下,Arch 更合适",读者即使不接受这组权重,也能看到结论依赖的是哪几个属性,可以照自己的情况重算一遍。给出带条件的结论,即使没有说服任何人改变权重,也能把信息传递清楚。
给结论标明作用域的要求也适用于写这篇文章的人。写 snap.md 时,有一部分结论是按当时的配置得出的,落笔时没有逐条标注作用域。后来收到的反馈里,相当一部分是在报告另一组配置下的读数不一样。那些反馈更正的是作用域,不是事实,当时却有一部分被当作反驳处理。把作用域写出来,那部分往返可以省掉。
同一类情况有三种位置,回应的写法各不同:
- 对方报告故障时,"我的没问题,你瞎说"换成"没复现;内核、驱动、OEM、复现步骤、日志分别是?"
- 对方说体验正常时,"我遇到了,所以你在洗地"换成"这边稳定复现,配置是 X,能否对照"
- 自己报告故障时,"这系统就是垃圾"换成"在配置 X 下,操作 Y 触发 Z,日志见附件"
三种改写都把针对对方人格的判断换成了可以执行的核查步骤。
5.2 扩展覆盖
如果分歧来自覆盖不同,处理方式是扩展覆盖:把对方有依据而自己没有的维度补上,或者把自己有依据的维度连同来源一起展示出来。形式是给出来源、配置、日志、复现步骤,让对方原则上可以复现。
扩展覆盖不是机械合并双方列出的所有维度。开始之前,需要明确它怎样运作。
第一,属性空间需要先协商。提出一个此前没有人列出的维度本身是合法动作,它不自动被接受,也不自动被驳回,进入讨论的条件与其他维度相同:可核查。
第二,取并集没有方向,合并双方提出的维度时,不需要比较谁覆盖得更多,也不是让一方追上另一方。双方只需在同一组维度上比较;对齐之后,排序可能翻转,也可能不翻转。
第三,掩码不可自证,原因见 2.4 节。
如果只问对方的新信息能否在当前属性空间和权重不变的情况下直接改变自己的排序,可以写出一个必要条件。记 为对方有依据的维度, 为权重不为零的维度,这个条件是 。交集非空,说明对方掌握的信息里至少有一项可能影响当前排序;交集为空,只说明这些信息无法通过当前权重直接改变排序。它们仍可能补充一个以后会用到的属性、促使自己修改约束或权重,也可以用于教学,因此这个交集不能单独决定整场讨论是否值得投入。
即使交集非空,它也只是直接改变当前排序的必要条件,不是充分条件:新信息最终能否改变排序,还取决于更新的方向和大小。
实际决定是否投入时,可以依次问四个问题:
对方是否掌握了自己没有考虑、而且可能影响结论的维度?
这些信息能否核查?
是否愿意重新检查自己的估计?
继续下去的时间成本是否合理?
这四个问题用于判断是否值得开始。讨论开始之后是否还值得继续,要看新发言是否仍在更新我们对命题的判断,下一节处理这个问题。
这里保留问句而不写成"信息价值减去时间成本"的算式,是因为双方之间存在无法消除的信息不对称。"你在哪些维度上有依据"可以廉价地问出来;"这些信息值多少"却要在知道内容之后才能估价。在决策时刻为未知量填上数字只会制造精确的假象。
互补性也不是唯一判据。覆盖高度重叠而权重不同,或者同一维度在不同 下读数不同,同样是有价值的讨论。还有一种常见情形:一方的覆盖包含另一方,讨论变成单向传输。这不是失败,那是文档与教学,是技术社区里性价比最高的内容形态,只是双方的时间投入不对称,最好在开始时说清楚。
5.3 判断讨论是否还在传递信息
确认当前问题之后,投入时间之前还要看双方是否默认同一组前提:
- 存在可以核查的事实;
- 新证据可能改变判断;
- 一个对象可以同时有优点和缺点;
- 不同意见不自动推出对方的身份;
- 讨论指向命题,不指向人。
这五条共同保证发言还能更新我们对命题的判断。它们不是对他人的要求;判断它们是否成立,也不看口头承诺,而看对方怎样回应具体证据。举一个对照:
- "snapd 是 GPLv3,Snap Store 的服务端不是开源的,两者需要区分"换来"对,我说得不准确,我真正反感的是 Store",前提一致。
- 同一句话换来"急了,Canonical 孝子",话题已经转向身份,继续核查技术事实也不会推进原命题。
失效模式可以列成四类:扣帽子、读心术、移动球门、绝对化。这四类的共同点是发言与命题无关。语气不是判据:措辞激烈的发言可以携带信息,措辞克制的发言也可以不携带信息。
判断标准是新发言能否帮助区分当前命题的不同可能。如果它让某些解释变得更可信、另一些解释变得更不可信,讨论仍在推进。新发言即使揭示了第三种可能,让问题暂时变得更复杂,也仍然提供了信息。相反,如果无论事实怎样都只重复同一个身份标签,它就没有更新我们对命题的判断。
如果连续若干轮只出现同一个标签、同一个立场,或者每次举证之后都移动球门,我们能够直接判断的是这些发言没有提供新的区分依据。此时停止投入,是因为这条渠道不再更新任何一方对命题的估计。一个身份判断如果吸收了所有可能的观察结果,就无法帮助我们区分命题的不同取值。附录 C 给出这个判断的信息论表达。
5.4 管理输入源
可见性会筛选我们对社区的印象,因此需要主动管理自己的输入源。按能回答的问题分,输入源有三类:
- 事实源:上游文档、源码、issue、release notes。能回答"技术事实是什么"。
- 高上下文讨论源:邮件列表、长期社群、维护良好的论坛。能回答"权衡如何被讨论"。
- 态度观察源:视频评论、热帖、短内容。能回答"人们在表达什么"。
视频评论、热帖和短内容可以用来观察人们怎样表达态度。把它们当作"技术事实是什么"的来源,会同时引入 4.1 的 与 4.2 的样本相关:能看到的发言已经过发言意愿筛选,同一批发言还可能共享内容刺激、传播链和社群环境。snap.md 的附录 B 因此把评论区原声单列,不与事实陈述混排。这样既保留了它们作为态度样本的价值,也避免读者把它们当成技术证据。
5.5 留下一份可核查的记录
在公开讨论中,我们无法控制对方是否更新观点,但可以把自己的论证整理成一份可核查的记录。
一篇文章可以把相关属性、来源、配置条件和反例放在一起,读者能核查其中与自己判断有关的部分。但文章无法保证某个读者改变想法,因为作者控制不了这件事。
为旁观者写是有理由的。公开讨论的读者远多于参与者,其中多数不发言,也不会留下痕迹。有来源、有条件、有边界的回答,未来任何路过的人都能核查;缺少这些信息的回答,只对已经同意的人有说服力,而那部分人不需要被说服。
5.6 小结
处理分歧时,先确认双方正在回答同一个问题。事实比较先核查属性;工程选择还要依次检查约束、条件、覆盖与估计,最后再谈权重。权重相反时说明偏好并接受分歧;当前问题无法对齐、前提不一致,或者新发言不再携带关于命题的信息时,停止。这里的停止只针对这一次对话:它不表示已经证明对方错误,也不表示以后拒绝讨论。对话无法继续提供关于原命题的新信息时,可以先结束;有新的证据、条件或问题出现,讨论仍然可以重新开始。在公开讨论中,至少可以控制自己是否留下一份可核查的记录。
结语:我想退出的是什么
我不想退出技术社区,也不希望停止技术争论。技术争论里有大量真实的分歧,值得花时间。
想退出的是一种把技术选择和人的身份绑在一起的讨论方式。长期使用一个系统、投入时间学习它,往往会形成经验和偏好。问题出现在这些经验被用来判断别人属于哪一类人,或者个人愿意承担的成本被改写成别人也应当承担的义务。
个人体验需要带上发生条件,才能说明它对其他环境有多大参考价值;工程评价针对的是设计,不能直接推出使用者是什么人;解释一项设计为什么存在,是在补充因果关系,并不等于认同它。有人愿意花时间维护 Arch,有人只希望 Debian Stable 多年保持可预测;同一个人也可以喜欢 Windows 的开发工具,同时批评它的某些设计。这些判断可以同时成立,选择也可以不同,不必先把人分进阵营再讨论技术。
回到导读里那句"你又有什么资格一口咬定"。它把讨论对象从命题换成了人,要求对方先自证资格,才允许发言。如果保留对依据的质疑、去掉资格判断,可以改成"这个结论的依据是什么,这边测到的读数不一样"。两句话都在质疑结论,后者却给出了可以回答的问题。
前面的分析也改变了我获取技术评价的方式:
不要把反复主动搜索负面评论当成口碑调查。这样得到的输入样本会持续偏向负面评价,无法回答一项技术的实际表现如何。
反复搜索看起来像在做调研,实际是在持续收集同一方向的输入:样本已经被 筛过一遍,主动寻找负面评论又让后续样本继续偏向负面评价。最后得到的是"这项技术的口碑很差"这个印象,不是对这项技术的判断。
一次讨论最好的结果也不一定是某一方改变选择。双方可能补上了遗漏的维度,修正了错误的属性估计,对事实的认识比之前更接近,却仍然因为约束和权重不同而选择不同的方案。只要双方更清楚分歧落在哪里,这次讨论就已经产生了信息。
我希望一次技术争论结束以后,我们对问题的模型比开始时更准确了一点。
附录 A:对称性检查
把文中的 Windows 与 Linux、Snap 与 Flatpak、支持者与反对者全部互换,检查论证是否仍成立。成立,说明它在描述机制;不成立,说明论证偷偷引用了阵营标签。
例如"Snap 用户被强制接受更新"与"Flatpak 用户需要自己处理运行时与权限",分别强调了两种分发方案给用户带来的限制和责任:前者强调更新控制权,后者强调运行时与权限管理成本。换成"Snap 用户总能拿到最新版本"与"Flatpak 用户可以自行决定更新时机",同一组事实就换了评价。措辞变化不改变机制,这时检查通过。
不过,对称性检查不能抹平真实差异。安装基数不同,迁移成本不同,批评的方向也会不同;对默认项的批评与对可选项的批评,承载的现实成本也不一样。忽略这些差异,检查就会退化成"两边一样糟",失去分析作用。
附录 B:符号与用途索引
按首次出现的顺序列出全文记号,以及它们在论证中负责哪一步。
- :对象 的属性向量。1.2。把笼统的"好不好"拆成可以分别讨论的属性,清单可以随问题继续补充。
- :第 i 个人在各属性上的权重。1.3。描述同一个人怎样衡量不同属性的重要程度。
- :排序值。1.3。用于比较同一个人面对的不同方案。
- :第 i 个人对属性向量的估计。1.3。它会随文档、源码、日志和实验等证据更新。
- :约束集。1.4、第 5 章表格。用于划定一次决策中的可行方案。
- :条件配置。2.1。把个案放回发行版、内核、驱动、硬件和时间等具体环境。
- :一次尝试是否发生故障的二值随机变量。、 分别服从两组配置对应的伯努利分布。2.1、2.2。用于说明相反个案可以同时成立。
- :覆盖掩码。2.4。标记第 i 个人在维度 k 上是否有原则上可以核查的依据。
- 、、翻转条件:评分差、证据推力与翻转判据。2.5。在约束和权重保持不变时,三者把"提供新证据"与"新证据足以改变排序"分开。
- :维度集合。2.5 指一条证据更新到的维度,5.2 指一方有依据的维度;两处都用于确定信息实际覆盖了哪些属性。
- 、、:可见分布、发言意愿、平台可见性。4.1。把总体观点经过表达与分发形成可见样本的过程拆开。
- 、、:命题取值、新证据、互信息。附录 C。互信息描述一类发言平均具有多少区分能力;5.3 节把它转成一个实际判断:这条发言能否区分命题的不同取值。
附录 C:如何串起全文的数学
本附录把正文中的记号放回同一条论证路径:一条路径描述个人如何在条件中形成并更新技术判断,另一条路径描述哪些材料更容易成为可见输入;第 5 章把两条路径合并为讨论顺序。
总图与读法
这里用 表示进入判断的新证据,用 表示当前命题可能的取值。整套关系可以压缩为:
读图时,先看第一行:当前问题是事实比较,还是工程选择。事实比较通过 、 与 核查属性及其估计,不需要用个人权重决定真假;工程选择还要由 划定可行方案,再由 形成排序。另一条路径从 经过 和 得到更可能进入视野的 ,提醒我们检查"看见的材料是怎样来的"。证据只有在改变估计时才会产生推力,排序是否改变取决于 与 的关系;信息内容没有增加的重复发言不会继续产生推力。
两条路径都经过 :可见性决定哪些材料更可能进入判断,证据更新决定这些材料能否改变属性估计和排序。最后用 检查是否应当停止:如果发言不能区分命题的不同取值,只剩身份标签或立场重复,讨论就不再提供可用于更新的输入。
5.3 节的停止条件可以写成互信息:
表示在 的各种可能取值上取平均后,新证据能减少多少关于 的不确定性。它描述的是一类发言平均具有多少区分能力,不是给某条消息或一段聊天记录计算的分数。某条具体发言可能揭示第三种解释,让人暂时更不确定;这与公式并不冲突,因为条件熵已经对 的各种取值取了平均。正文因此保留可直接使用的问法:新发言能否帮助区分当前命题的不同可能。
附录 C 汇总正文中的公式,展示它们如何共同构成一条从输入材料到技术判断的路径。沿着这张图回到第 5 章,实际顺序就是:先确认当前问题及其类型;事实比较检查 、 与 ,工程选择还要比较 并说明 。与此同时检查输入是否经过 、 的筛选,最后判断新的 是否还能更新 。
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 条,得到 88.8% 的精确率(precision),不是准确率(accuracy)。论文明确把项目属性、pull request 上下文和参与者特征的结果表述为统计关联,不作因果推断。"毒性形态与一般社交平台不同"不属本研究的结论,见 [5: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。 ↩︎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 讨论的定性分析,属非代表性抽样,不能据此推断流行率。 ↩︎ ↩︎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 数据指标的处理与定义,不影响本文引用的实验效应结论。 ↩︎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 现场调查比较作者自报与观察者判断,并用预注册实验检验这种偏差的后果;观察者系统性高估了发帖者的道德愤怒程度。 ↩︎