AI 提效的熵账本：熵不会减少，它只会搬家
有个说法很吸引人：AI 提效的本质是熵减。代码库天然腐烂，团队是耗散结构， 你付的订阅费买的是"负熵"——一股有序的信息流，注进你那个正在退化的系统里。
这个说法讲得通。我一开始也信。
但把 Landauer 和 Bennett 的原话拿准了再推一遍，它推出的结论是反的： AI 不生产负熵，它是一台把熵搬到你没装仪表的那一侧去的机器。 而 2026 年那批被反复引用的"AI 没提效"数据，正好是这个推论的形状。
结论先放这里
- "熵"在这个论证里有三层，可信度递减：信息熵层是恒等式（LLM 的训练目标 就是压缩目标），热力学层只有结构成立、数值差 25 个数量级， 软件熵层是没有测度的隐喻。人们论证时习惯倒着用——拿最硬的那层给最软的那层背书。
- Landauer 收费的对象是擦除，不是计算。AI 把生成成本压到接近零， 擦除成本没动。所以瓶颈移到验证侧不是意外，是这个框架的预测。
- 四个直觉上的"熵减指标"（圈复杂度、单位行缺陷率、需求返工次数、周期标准差） 全部落选，各有具体的失效方式。其中圈复杂度那条最有意思： 同一个动作在两个尺度上符号相反。
- 换成五个能过筛的角度：验证器覆盖率、一次通过率、 发现→确认时长、可复现性、知识留存。两组的分水岭不是"能不能被刷" （肯定组里四个也能刷），而是刷它比真做它更贵还是更便宜。
- 一条工程判据：决定一个任务交不交给 agent，看它多容易验，不看它多难写。 按验证成本排序会把任务顺序整个颠倒过来。
- 明天就能做的四步，第一步半小时： 把一个任务的生成侧和擦除侧分开计时——多数人从没单独量过后者。 最该投的方向是补验证器，不是补审查人力。
三层熵：哪一层是数学，哪一层是修辞
把"熵"当一个词用，是这类论证最早出错的地方。它在下面三层里指的是三样不同的东西， 量纲不同、能不能测不同，可信度差一个量级。
| 层 | 它到底是什么 | 这一层的地位 |
|---|---|---|
| 信息熵 | 一个概率分布的期望编码长度，单位 bit | 恒等式，可推导可实测 |
| 热力学熵 | 状态数的对数乘玻尔兹曼常数，单位 J/K | 结构成立，数值不成立 |
| 软件熵 | "代码会腐烂"这个观察 | 隐喻，没有测度 |
信息熵层：这一层不是类比，是等号
先说最硬的那层，因为它常被当成比喻，而它其实是个等式。
Shannon 的源编码定理给出：最小期望码长等于分布的熵。算术编码逼近这个下界。 而语言模型的训练目标——最小化 log-loss——就是最小化用它当模型时的算术编码长度。 不是"类似于"，是同一个目标函数。DeepMind 那篇 Language Modeling Is Compression 把这层等价写清了，顺手拿它当压缩器实测：Chinchilla 70B 只训过文本， 压 ImageNet 图块到 43.4%（PNG 是 58.5%）、压 LibriSpeech 到 16.4%（FLAC 是 30.3%）。
所以"LLM 是个压缩器"这句话不需要打引号。训练一个语言模型和训练一个压缩器 是同一件事的两种说法。
这一层还解释了 AI 在代码上为什么格外好用，而这个解释也是可测的。 Hindle 等人那篇 On the Naturalness of Software （ICSE 2012，这里链的是 2016 年的 CACM 版）量过： 英语 unigram 交叉熵约 10 bit，加到 10-gram 才降到 8 bit 以下； 而 Java 项目的交叉熵有些能掉到 2 bit 以下。后续工作按 perplexity 口径算， 代码比英语可预测 8 到 16 倍。代码本身就是低熵的——它的语法冗余、命名惯例、 样板结构，全是可压缩的规律。
一句诚实的补充，回到 DeepMind 那篇——它自己给了个口径警告： 把模型参数量也算进压缩体积（adjusted compression rate）， 压缩优势就随模型变大而边际递减。"压缩得好"不等于"总账划算"， 这个提醒到文章最后还要用一次。
热力学层：结构成立，数值差 25 个数量级
第二层是这套论证真正的力量来源，也是它最容易被滥用的地方。
Landauer 1961 年给出的结论很具体：擦除一个 bit 至少要向环境耗散 kT·ln2 的能量。Bennett 后来把它推广到所有逻辑不可逆操作——擦除、 以及计算路径的合并。反过来，逻辑可逆的变换原则上可以做到热力学可逆， 也就是原则上不收费。
这里有个必须点破的事，因为它决定了这个框架能给什么、不能给什么。
室温下 kT·ln2 ≈ 2.9e-21 J。而一次 30 分钟的人工代码审查， 按人脑 20 W 估，耗能约 3.6e4 J。两者相差约 10²⁵ 倍。
这个数字是我这篇里最好卖的东西的反面，所以我自己先把它拆掉： 物理下界在软件工程里完全不是约束，差 25 个数量级的量在任何工程决策里都是零。 凡是拿 kT·ln2 去算"AI 省了多少熵"的论证，无论包装多严谨，都是在 拿物理学的可信度给一段修辞背书。
那这一层还剩下什么？剩下记账结构：
- 收费的对象是擦除，不是计算。做多少运算不重要，丢弃多少可能性才重要。
- 局部有序必须由环境的无序来支付。看起来免费，就是账没记全。
- Bennett 处理 Maxwell 恶魔的方式是：把恶魔的记忆复位成本算进来， 违反第二定律的假象就消失了。
第三条是本文后面全部推导的模板。先记住它的形状：一个看起来违反守恒的收益， 通常是漏记了某个复位成本。
一个必须正面接住的反驳
写到这里有个洞，不补上后面全都站不住：
你刚说物理下界差 25 个数量级、完全不是约束。 那凭什么它的"记账结构"还能用？数值不适用，结构凭什么适用？
这个反驳是对的，而且很难回答。老实说：Landauer 在本文里不提供任何强制力。 它不是"软件工程必须服从的定律"，它是一个已经被验证过的记账范式—— 在一个完全不同的领域里，人们曾经以为可以白拿一份有序（Maxwell 恶魔）， 后来发现是漏记了一笔擦除成本。
所以它给的是类比的方向，不是推论的依据。这意味着两件事：
- 我不能说"因为 Landauer，所以软件的验证成本必然上升"。这一步不成立。
- 我能说"Maxwell 恶魔那个案例提示了一种典型的记账错误， 值得回去检查软件这边有没有犯同一种错"——然后这个检查的结论， 必须由软件领域自己的数据来支撑，而不是由物理定律来担保。
下一节做的就是这件事：先按这个提示推出一个可检验的预测， 再看数据是不是那个形状。如果数据不是，框架就该被丢掉—— Landauer 救不了它。
软件熵层：能用，但不能当证据
第三层是"技术债""软件腐烂"那套说法。它有真实的经验支撑—— Lehman 的软件演化定律 里第二条（复杂度递增）和第七条（质量表观下降）说的正是这件事， 而且两条都带一个前提从句：除非投入明确的工作去对抗它。
但这一层没有测度。"这段代码的熵是多少"没有答案，因为没有定义"可能的程序" 这个集合上的概率分布。所以它能提供的是候选代理指标，不是证据。 每一个代理指标都得单独接受检验，而下文会证明大多数过不了。
这三层的关系，就是这类论证出错的地方
可信度是递减的：恒等式 > 结构类比 > 无测度隐喻。
而典型的论证顺序是反的——先讲"代码会腐烂"（第三层）， 再引"耗散结构需要负熵流"（第二层）给它撑腰，最后提一句"LLM 本质是压缩" （第一层）作为收尾权威。三层一叠，读起来像物理学证明了 AI 能提效。
实际上第一层管的只是"模型能不能预测得准"，第二层管的只是"账该怎么记"， 两者都没有、也不可能推出"你的交付更快了"。中间缺的那一步， 就是下一节要拆的东西。
从"注入负熵"到"熵搬家"：把恒等式补上
现在做那步推导。结论会和开头那个吸引人的说法相反，但它是被约束逼出来的。
第一步：把系统边界画对
"AI 向开发系统注入负熵"这句话有个隐含的边界：系统 = 你的代码库 + 你的团队。 在这个边界里，AI 是外部的负熵源。
这个边界画得太小了，而且小得刚好把成本挡在外面。耗散结构理论的原话 （Prigogine 的记法）是把总熵变化拆成两项：
dS = dS_internal + dS_exchange
↑ 恒 ≥ 0 ↑ 可正可负系统要维持有序，需要交换项足够负，负到能盖住内部产生的那一项。
关键在于：交换项为负，意味着环境那边有一个等量或更大的正项。 生命体靠进食维持有序，代价是把熵排到环境里。这不是"生命违反第二定律"， 是"生命是个把熵搬出去的泵"。
所以"AI 注入负熵"这句话本身没错，错在它只说了一半。 另一半——那个正项落在哪——才是工程上唯一有意义的问题。
第二步：AI 压缩的是生成，不是擦除
把 Landauer 那条记账规则套上来。软件开发里的信息处理可以粗分两类：
| 干什么 | AI 的作用 | |
|---|---|---|
| 生成 | 从需求的可能空间里取出一个实现 | 成本压到接近零 |
| 擦除 | 从若干候选里丢掉错的、把不确定性归零 | 几乎没动 |
第一类是"这个函数该怎么写"——AI 一秒给出一个高确定性的答案，这是真的， 且第一层的恒等式解释了它为什么能做到。
第二类是"这个答案对不对""它有没有悄悄改掉别的行为""这段能不能上生产"。 这一类的本质是丢弃可能性：读代码、跑测试、审查、灰度、复盘。 每一步都在把"它可能是错的"这个分支删掉。
Landauer 收费的是第二类。 AI 把第一类压到接近零，第二类的量却随第一类的 产出线性增长——生成得越多，要擦除的候选就越多。
于是那个正项的落点就确定了：它落在验证侧。
一句必要的坦白：这个顺序在我脑子里其实是倒的——我先看到了那些难看的数据， 才回头去找一个能解释它们的记账方式。所以下面不是"预测被验证"的故事。 它的价值在于另一件事：这个框架给出了一个本来可以不这样的形态， 而数据恰好落在那个形态上。判断它有没有用的标准， 不是它解释得通，而是它是否排除了别的可能——下一节先把那个形态写死， 再去对数据。
第三步：这个预测长什么样，以及数据是不是这个形状
先把形态写死，免得事后怎么都能圆回来。如果熵只是搬家而没有减少， 那么生成量上升、验证吞吐不变时，应该同时看到三件事：
- 单位产出的通过率下降（生成得多，但过关的比例掉）
- 验证环节出现堆积（等待被审的时间变长）
- 擦除性动作的占比下降（重构、合并、删除这类"丢弃可能性"的操作变少）
反过来说，能推翻它的形态也很具体：如果生成量大涨而通过率、 等待时间、重构占比三者都没动，那说明擦除侧的成本并没有跟着生成量走， 这个框架就错了。三份数据里任何一份给出这个结果，我都得回来改这篇。
三份 2026 年的数据，各有各的问题，但形状一致。
LinearB 的 2026 基准 （8.1M PR / 4,800 组织 / 42 国）把 PR 按三类分开算—— 这个区分是它自己反复强调的，合起来算会得到一个谁都不描述的数字：
| 指标 | 无辅助 | AI 辅助 | agentic |
|---|---|---|---|
| 30 天合并率 | 84.4% | 32.7%（AI 合计） | — |
| 被拿起来审前的等待（P75） | 3.4 小时 | 8.3 小时 | 17.6 小时 |
| P75 体积 | 157 行 | 408 行 | 293 行 |
| 重构率（P75） | 0.37 | 0.22 | 0.17 |
有意思的是体积那一行：agentic 的 P75 反而比 AI 辅助小（293 vs 408）， 但等待时间长一倍多。所以"等得久"不能全归给"改得大"—— agentic 的产出即使更小，也依然更难被拿起来审。
GitClear 的 2026 报告 （6.23 亿处代码变更，七个信号，2023–2026）测的是代码结构： 重构性行移动 2022 年 21% → 2023 年 13% → 2026 年至今 3.8%， 同期复制粘贴从 9.4% 升到 15.7%——也就是从"偏好重构 2:1"翻转成 "偏好冗余约 5:1"。另外几个信号（都以 2023 为基准）： 重复代码块密度每百万变更行 40.3 → 73.0（+81%）、 错误掩盖构造 +47%、两周内 churn +15%、跨文件函数调用 -35%。
2025 DORA 则给出组织尺度的读数：AI 采用率越高，交付吞吐和交付不稳定性 同时上升——而且它专门检验过"fail fast, fix fast"这个辩解（速度收益能否 抵掉不稳定的代价），数据不支持。同一份报告里另有一个数： 30% 的开发者对 AI 生成的代码几乎不信任。 DORA 团队后来在一篇解读里 把这件事叫做 "verification tax"——省下的写代码时间，被重新花在审计上。 （这个词出自那篇解读，不是 2025 报告的原文用词。）
把三条预测和数据对一遍：
| 预测 | 数据 | 中没中 |
|---|---|---|
| 通过率下降 | 30 天合并率 32.7% vs 84.4% | 中 |
| 验证环节堆积 | 等待 17.6 / 8.3 vs 3.4 小时 | 中 |
| 擦除性动作占比下降 | 重构率 0.17 / 0.22 vs 0.37；重构性行移动 21% → 3.8% | 中 |
三条都中，而且第三条是最不容易碰巧中的那条—— 它要求的不只是"结果变差"，而是变差的方式特别具体： 擦除类动作（重构、合并、删除）的占比要下降，同时生成类动作 （复制粘贴）的占比要上升。GitClear 那两个数正好是这一对反向运动： 重构性行移动 21% → 3.8%，复制粘贴 9.4% → 15.7%。
一个"AI 只是让人变懒了"或者"AI 生成的代码质量差"的解释， 预测不出这个成对的方向性——它们只预测"结果变差"， 不预测"擦除侧和生成侧朝相反方向走"。这是熵账本比那些解释多给出的东西。
第四步：那 METR 那个 19% 呢
绕不开这个数字，而它需要比通常引用得更小心。
METR 2025 年那个 RCT 的核心结果是：16 名资深开源开发者在自己熟悉的仓库上，用 AI 时完成任务慢 19%； 而他们事前预期加速 24%，事后仍然认为自己快了 20%。这个知觉落差被引用得最多， 也确实是这篇里最有意思的部分。
但要把它当证据用，得先说三件它自己承认的事：
- 时间窗是 2025 年 2–6 月，工具是 "early-2025 AI"。
- 置信区间是 +2% 到 +39%——下界离零很近。
- METR 2026 年 2 月自己发文改了实验设计， 理由是选择偏差：30%–50% 的开发者说他们主动不提交某些任务， 因为不想在没有 AI 的条件下做。这意味着高 AI 收益的任务被系统性地漏掉了。
所以我这篇不拿 19% 当结论。它在这里的作用只是知觉落差那一半—— 主观感受与实测方向相反，说明"我觉得快了"这个信号不能当度量。 这一点恰好和熵账本对上：人只能直接感知生成侧（代码出现得快）， 擦除侧的成本是分散、延迟、且落在别人身上的（审查者、值班的人、三个月后维护的人）。
感受不到的成本，不等于不存在的成本。 这是这个框架给的第一个可操作结论， 它不需要任何数字支撑。
修正后的说法
把前面几步合起来，原来那句话该改成这样：
AI 大幅压缩了生成侧的成本，把等量甚至更多的擦除成本推到了验证侧。 它不是负熵源，是一台熵的搬运泵。提效是否为真， 取决于验证侧能不能吸收得下——而这一侧通常既没有装仪表，也没有扩容。
这个说法有个好处：它可以被证伪。 原来那句"AI 注入负熵"不能—— 你没法设计一个实验来推翻它。而"熵被搬到验证侧"直接给出了该测什么： 测那一侧的堆积。
一处必须自我打断
上面这套推导有个我没法回避的弱点：它论证的是这个记账框架自洽， 不是"AI 提效为假"。三份数据里有两份是观察性的， AI 采用率高的组织可能本来就在做更难的事； METR 那份是 RCT，但作者自己说设计有偏。 框架的价值在于它给出了该测什么，而不在于它已经测过了。
四个候选指标，一个都没活下来
前面那个框架真正的用处不是解释现象，是淘汰指标。
"熵减"最诱人的地方在于它看起来自带一堆可测量的代理：复杂度、缺陷率、 返工次数、周期稳定性。这四个都很像硬指标，都能从工具里直接导出来。 逐个过一遍，四个全部落选——而落选的方式各不相同，这比它们都合格有信息量。
用三个问题筛（下文按名字引用，不编号——后面还有一套四条的筛选器， 两套别混：这三个用来淘汰，那四条用来挑选）：
- 测度：它测的量在数学上定义清楚了吗？
- 符号：它变好，一定意味着系统更有序吗？
- 可刷：把它当目标之后，有没有零成本的作弊路径？
候选一：圈复杂度 —— 同一个动作在两个尺度上符号相反
直觉：AI 重构后代码更整洁，圈复杂度更低，逻辑路径更少，有序度上升。
它的失效方式最有意思，而且是四个里唯一一个符号会翻转的。
把一个 30 分支的巨型函数拆成 10 个 3 分支的小函数。函数级平均圈复杂度 从 30 降到 3——看起来是大幅熵减。但模块间的调用关系多了 10 条边， 理解这段逻辑需要的跨文件跳转从 0 次变成 10 次。
而 GitClear 那份报告刚好量到了这个尺度上的另一侧： 新增代码与既有代码的跨文件函数调用自 2023 年起下降 35%。 新代码越来越"自己站着"——不调用、不复用、不与既有结构咬合。
于是同一个"拆分"动作，在函数尺度上是熵减，在系统尺度上可能是熵增。 一个指标如果在不同尺度上符号相反，它就不能单独当结论。
这条推广开来是个通用陷阱：任何局部聚合指标（平均值、按文件算的比率）都可能 把成本推到聚合边界之外。选指标时问一句"这个量的边界在哪、边界外发生了什么"。
候选二：单位代码行缺陷率 —— 分母被污染了
直觉：bug 是系统行为的意外，是高熵状态。AI 消除拼写、类型、空指针这类低级错误， 缺陷率下降 = 熵减。
失效在分母上。
缺陷率 = 缺陷数 / 代码行数。AI 让分母涨得很快，而且涨的那部分里 重复块的密度在升（每百万变更行 40.3 → 73.0）。同一个逻辑缺陷被复制到 5 处， 按"缺陷数"算是 1 个还是 5 个，取决于你的工具怎么去重—— 而这个选择会让同一份代码得出差 5 倍的缺陷率。
更麻烦的是"错误掩盖构造 +47%"这个数。一个 catch {} 空块会让缺陷 测不出来，缺陷率因此下降。这个方向上，指标改善和系统变差是同一件事。
这就是"可刷"那一筛：它能被零成本地刷。 而且不需要谁刻意作弊—— 模型倾向于生成防御性的 try/catch，这本身就在刷这个指标。
候选三：需求返工次数 —— 测的是承诺，不是兑现
直觉：需求文档是模糊的高熵体，AI 即时把一条需求变成可运行原型， 压缩了从模糊语言到精确实现的不确定性，返工减少。
这条的失效最隐蔽，因为它方向是对的。
问题在"返工"这个事件的定义依赖于"有人发现了偏差"。 而 LinearB 的数据里有一处倒挂：AI 辅助的 PR 体积是无辅助的 2.6 倍 （P75 408 行 vs 157 行），可一旦真被拿起来审，审查耗时反而更短 （3.2 小时 vs 4.2 小时）。注意这里是 review time， 和上面那个 pickup time 是两个不同的指标——等得久，但看得快。 最大的改动拿到了最少的审查时间。
审查得不够细，偏差就不会被记为"返工"。指标下降了， 但下降的原因是检测能力下降，不是质量上升。
这跟候选二是同一个病的两种表现：凡是以"被发现的问题数"为分子的指标， 在检测能力变化时都不可比。
候选四：交付周期标准差 —— 混淆了两种波动
直觉：高熵流程的完成时间极度分散。AI 自动化掉可预测的重复任务， 波动减少，时间熵下降。
失效在于标准差把两种性质完全不同的波动混在一起：
- 任务本身难度不同带来的波动（正常的，不该消除）
- 流程失控带来的波动（要治的）
AI 让简单任务快了很多、难任务没怎么变，结果是分布更分散——标准差上升， 而这恰恰是提效发生时的样子。DORA 那个"吞吐和不稳定性同时上升" 就是同一个现象在组织尺度上的读数。
所以这个指标不只是弱，它在最该报喜的时候报忧。
汇总：四条落选原因不重复
| 候选 | 哪一道筛拦下它 | 落选原因 |
|---|---|---|
| 圈复杂度 | 符号（随尺度翻转） | 局部熵减 = 系统熵增 |
| 单位行缺陷率 | 可刷（极易） | 分母被污染，且掩盖错误反而让它改善 |
| 需求返工次数 | 测度（弱）+ 可刷 | 测的是检测能力，不是质量 |
| 周期标准差 | 符号（可能相反） | 混淆正常波动与失控波动 |
四条原因两两不同，这说明问题不在"选得不够好"， 而在这一整类指标的取法有共同缺陷：它们全都在测生成侧的产出形态。
四条筛选器
从落选原因反推，得到四条筛选器。上一节那三个问题用来淘汰， 这四条用来挑选——下文按括号里的短名引用。
（测哪侧）测擦除侧，不测生成侧。 "生成了多少"永远会因为 AI 而变好， 它不含关于提效的信息。要测的是"丢弃了多少不确定性"。
（用比值）优先用比值，而且分母是生成量。32.7% / 84.4% 那个对比是本文引到的 最合格的指标形态——分母是 PR 总数（生成量），分子是通过验证的数量 （擦除完成量）。生成变便宜时它自动往下走，这正是想要的灵敏度。
（独立检测）检测能力必须独立于被测对象。候选二和三都栽在这。 判据很简单：如果"少查一点"能让指标变好，这个指标不能用。 测试覆盖率也栽在这——它可以用不带断言的测试刷上去。
（跨尺度）符号跨尺度一致。一个指标至少要在函数、模块、系统三个尺度上 方向不冲突。做不到就必须成对使用（例如圈复杂度必须配跨文件连接度一起看， 单看任何一个都会被骗）。
一个反常识的推论
按这四条筛，"AI 写了多少行代码"和"AI 生成占比"这两个业界最常用的指标 是四条全不满足的：测生成侧、分母是自己、没有独立检测、跨尺度无意义。 它们能回答"用了多少 AI"，不能回答"AI 有没有帮上忙"—— 而这两个问题经常被当成一个。
五个通过筛选的角度
上一节淘汰了四个，这一节给五个能过筛的。这样对比才完整—— 否则读者拿到的只是"你说的都不行"，而不知道该换成什么。
这五个不是同一个东西的五种说法，它们分别对应研发流程的不同环节， 且都不在原来那四个候选的射程内——原来那四个全在测代码和流程的产出形态， 这五个测的是不确定性被消除的过程。
角度一：验证器覆盖率 —— 最该建、最没人建的那个
问的是：你的改动里，有多少比例存在一个自动化验证器？
分母是改动总量，分子是"有编译器 / 类型检查 / 测试 / lint 能对它下判决"的那部分。 它过筛的原因很干脆：分母是生成量（用比值），测的是擦除能力（测哪侧）， 而且它没法靠少查来刷——少写测试会让它直接掉下去（独立检测）。
为什么这个角度最值得先建：它是唯一一个既是指标又是待办清单的。 覆盖率低的那部分改动，正好就是 agent 最不该碰、也最该补验证器的地方。 它把"要不要用 AI"这个争论，换成了一件可以立刻动手的工程任务。
角度二：一次通过率 —— 生成便宜之后唯一还稀缺的东西
问的是：agent 交出的东西，有多少不需要返工就能用？
sid-code 这类工具里最直接的形态是"一轮命令是否成功"， 放大到团队尺度就是 LinearB 那个 32.7% / 84.4%。
它过筛得很干净，但真正有意思的是它的方向：当生成成本趋近于零， "生成了多少"就不再是稀缺资源，"一次做对的比例"才是。 这个指标不会因为 AI 变强而自动变好，它只在 agent 真的更可靠时才上升。
配套的口径提醒：小团队样本量不够，单周的一次通过率方差会大到读不出趋势， 一个月的滚动窗口比单周可靠。
角度三：从"发现"到"确认"的时长 —— 擦除侧的真实速度
问的是：一个问题从被怀疑到被确认或排除，要多久？
这个角度是前面推导的直接产物。如果瓶颈在擦除侧，那么擦除侧的速度 就是系统的真实节拍。它测的东西很具体：
- 一个 bug 从报出来到定位到根因的时长
- 一个 PR 从被怀疑有问题到确认没问题的时长
- 一次线上异常从告警到归因的时长
它过筛的关键在"独立检测"那条：你没法靠"少查"让它变短—— 不查就永远停在"未确认"状态， 时长只会更长。这个性质让它比"缺陷数"这类计数型指标可靠得多。
而且它有个实用价值：这条时长如果在涨，说明生成量已经超过了验证能力。 这是该扩容验证侧的信号，而且比任何主观感受都早。
角度四：可复现性 —— 一个被严重低估的角度
问的是：一个现象，你能不能稳定地让它再发生一次？
这个角度容易被忽略，因为它不像个"指标"。但按熵账本看， 它是擦除能力的上限：不能复现的问题，就不能被确定性地排除掉，你只能猜。
这也解释了 sid-code 自己的一个实践为什么值得做—— JIT 上下文那篇里那三个静默缺陷，都是靠构造最小复现 才抓出来的；而缓存那篇里那次数据污染事故， 之所以能定性，靠的是"记录文件行数 → 跑测试 → 再记录"这个可复现的检验手法。 光跑测试看绿是发现不了它的。
可复现性怎么量：把"提交时带最小复现步骤的 issue 占比"当代理指标。 它过筛，且有个额外好处——它是这五个里唯一一个人可以直接改善的， 不需要等工具支持。
角度五：知识留存 —— 唯一能对抗 Lehman 第二定律的那个
问的是：这次改动之后，团队对这块代码的理解是变强还是变弱了？
这是唯一直接对着软件熵那一层的角度。Lehman 第二定律的前提从句是 "除非投入明确的工作去对抗它"——知识留存就是那个"明确的工作"。
GitClear 那个"跨文件函数调用下降 35%"其实是这个角度的反面证据： 新代码不与既有结构咬合，意味着写它的人不需要理解既有结构。 短期看是效率，长期看是理解在流失。
它最难量化，但有可用的代理：改动一个模块时需要读多少个文件才敢动手、 新人接手一个模块到能独立改的时长、"只有某一个人懂"的模块占比。
但要说清一件事，否则我就在做自己批评过的事：这一条单独用是过不了 "跨尺度"那筛的——个人尺度上他理解变强了，团队尺度上却可能因为 只有他理解而更脆弱，符号在两个尺度上冲突。
按前面立的规矩，这种情况不该放行，除非成对使用——就像圈复杂度 必须配跨文件调用一起看那样。所以这一条的正确形态是 "理解深度 + 知识集中度"两个一起看，缺一个就会被骗。
单列它是因为它是唯一直接对着软件熵那一层的角度， 但它是这五个里唯一一个不能单独成立的。
汇总：五个肯定组 vs 四个否定组
| 角度 | 测什么 | 怎么被刷，代价是什么 |
|---|---|---|
| 验证器覆盖率 | 有多少改动能被自动判决 | 只能靠真补验证器；少写测试反而让它掉 |
| 一次通过率 | 多少产出不需返工 | 能刷：只提交有信心的、或把大改动拆小 |
| 发现→确认时长 | 擦除侧的真实速度 | 能刷：草率地"确认没问题"；配抽检可缓解 |
| 可复现性 | 能否稳定重现一个现象 | 能刷：写形式化的假复现步骤 |
| 知识留存 | 理解是在积累还是流失 | 最难量，且必须配知识集中度成对用 |
这里要收回一句话。我原本想写"这五个刷不动"，但逐条过下来不成立—— 除了验证器覆盖率，其余四个都有作弊路径。真实的差别是刷的代价：
| 否定组（四个落选） | 肯定组（五个通过） | |
|---|---|---|
| 测的对象 | 代码与流程的产出形态 | 不确定性被消除的过程 |
| AI 变强时 | 可能自动变好，甚至在变差时变好 | 只在擦除侧真的更强时才变好 |
| 刷它的代价 | 零成本，甚至是模型的默认行为 | 需要人主动地、持续地作假 |
第三行才是真正的分水叉。否定组里那个 catch {} 空块是模型自发生成的—— 没人作弊，指标就自己漂亮了。肯定组要刷得动，得有人每次都刻意 少报、拆分、编造复现步骤。这不是"不可能作弊"，是"作弊需要成本且留下痕迹"。
指标的可靠性从来不是"能不能被刷"，而是"刷它比真做它更贵还是更便宜"。
从记账推到一条工程判据
这个框架还有个副产品，它比任何指标都更能直接改变决策。
如果瓶颈在擦除侧，那么一个任务值不值得交给 agent， 取决于它的验证成本，而不是它的生成难度。
这一点在 LLM 研究里有独立的名字。Jason Wei 把它叫做 verification 的不对称性与 verifier's rule： 训练 AI 解决一个任务的容易程度，与这个任务多容易被验证成正比。 他给了五条属性——客观真值、秒级可验、可并行验、低噪声、连续奖励。
两条线在这里合上了：Wei 从 RL 训练的角度得到"可验证性决定能力边界"， 熵账本从记账的角度得到"擦除侧是瓶颈"。说的是同一件事的两端。
于是有了一条可以当场用的判据：
派活给 agent 之前，先问"我怎么知道它做对了"。 这个问题答不出来，任务再简单也不该交出去； 答得出来（有测试、有对照、有可复现的判据），任务再难都可以试。
这条判据的价值在于它改变了任务的排序。按生成难度排， "写一个复杂算法"比"改 50 个文件的重命名"难；按验证成本排，顺序相反—— 重命名有编译器当验证器，复杂算法的正确性得靠人读。
一个补充，因为这个不对称性不是普适的。有人 反驳过 "验证总比生成容易"，论点是：一旦验证方需要对所有输入成立 （也就是有对抗性输入在），不对称性就可能反过来。 那篇的评论区有个很干净的例子——生成一个半素数只要挑两个素数相乘， 验证一个数是不是半素数却要做因式分解。
软件里的对应物是安全属性："这段代码没有漏洞"要对所有输入成立， 这类命题的验证成本可以远高于生成成本。
所以判据要按任务类型分档，不能一刀切：
| 任务类型 | 验证器 | 该不该交给 agent |
|---|---|---|
| 重命名 / 类型迁移 | 编译器，秒级、客观 | 该，且规模越大越划算 |
| 有明确测试的 bug 修复 | 测试用例 | 该 |
| 新功能实现 | 人读 + 新写的测试（测试本身也要验） | 可以，但成本翻倍要算进来 |
| 安全属性、并发正确性 | 需对全输入成立，无廉价验证器 | 谨慎，agent 产出当草稿而非结论 |
这个视角到底值多少
绕了一圈，该给"熵"一个诚实的估价，因为它既比人们以为的弱，也比人们以为的强。
弱在数值上，而且是彻底地弱。 物理下界差 25 个数量级，软件熵没有测度， "这次改动减少了多少熵"这个问题没有答案——不是工具不够好，是这个量没有定义。 看到有人给出这类数字，那是修辞不是测量。
强在它是个记账结构，而结构给了四样东西：
- 它逼你把系统边界画大。只要边界画在"我的代码库 + 我的团队"， AI 就永远显得是净负熵源。把审查者、值班的人、三个月后的维护者 放进边界内，账才完整。
- 它先验地给出了瓶颈位置。生成侧压缩、擦除侧不动，瓶颈必然移到验证—— 这个推论在看数据之前就能得出，而 2026 年那三份数据是它的形状。
- 它同时提供了淘汰和筛选的能力：三道筛淘汰掉四个直觉指标， 反推出的四条筛选器又放行了五个更靠谱的角度。 一个只能否定的框架价值有限，能给出替代品的才算完整。
- 它解释了知觉落差。人只能感知生成侧，所以 METR 那个 "实测慢 19%、自认快 20%"不是认知偏差的偶然，是账本结构决定的。
Bennett 处理 Maxwell 恶魔的手法是这整篇的模板：一个看起来违反守恒的收益， 通常是漏记了某个复位成本。在软件里，那个复位成本叫"确认它是对的"。
那么，明天可以做什么
前面全是判断，这一节全是动作。按投入从小到大排，第一条今天就能做完。
第一步：给自己算一次账（半小时）
拿最近一个用 agent 完成的任务，把两侧的时间分开记：
生成侧：从提出需求到 agent 交出第一版 → ___ 分钟
擦除侧：从第一版到你真的敢合并进去 → ___ 分钟
（含读代码、跑测试、来回改、请人看）这个动作的价值不在数字，在于它大概是你第一次把擦除侧单独计时。 多数人凭感觉估的是生成侧那一栏，因为那一栏有明确的开始和结束； 擦除侧是碎片化的、被打断的、和别的事交织的，所以感觉上不存在。
如果两栏加起来比不用 agent 更长——这很常见，尤其是不熟悉的模块—— 那不是 agent 没用，是这个任务的验证成本本来就高， 它本来就不该是第一批交出去的任务。
第二步：给任务分档，改变派活顺序（一次性，之后长期受益）
按前面那张表把手上的任务过一遍， 问的不是"这个难不难写"，而是"我怎么知道它做对了"。
- 有编译器 / 测试能下判决的 → 优先交给 agent，且规模越大越划算
- 只能靠人读的 → 交出去也行，但要把审查时间算进预算
- 涉及安全属性、并发正确性的 → agent 产出当草稿，不当结论
这一步的实际效果是任务排序被整个颠倒。 按生成难度排， "改 50 个文件的重命名"是苦活、"写一个复杂算法"是硬活； 按验证成本排，前者反而是 agent 最该干的（编译器全程盯着）， 后者反而最该自己写。
第三步：补验证器，而不是补审查人力（这是最该投的方向）
如果只能从这篇文章带走一件事，我希望是这一条。
瓶颈在擦除侧，扩容擦除侧有两种办法：加人审，或者加自动化验证器。 前者线性扩张且消耗最稀缺的资源（资深工程师的注意力），后者一次投入长期复用。
具体到能立刻动手的：
- 给缺测试的模块补测试——先补 agent 最常改的那几个， 投资回报最高的地方就在这
- 打开更严的类型检查、lint 规则，让机器多担一点判决
- 把手工验证步骤脚本化，让它可复现、可重复跑
- 给关键路径加断言与不变量检查，让错误在测出来时就自报位置
这条也解释了为什么"AI 让测试变得更重要"不是一句口号。 测试是最便宜的擦除器，而擦除侧现在是瓶颈。
第四步：换掉度量口径（需要和团队达成一致）
停止用这几个数汇报提效：AI 生成代码行数、AI 生成占比、 单位行缺陷率、平均圈复杂度。它们全都测生成侧， 或者能被零成本地刷。
换成前面那五个角度里挑一两个开始，从"验证器覆盖率"起步最实用—— 它既是指标也是待办清单：覆盖率低的那部分改动， 正好就是下一步该补验证器的地方。
一条口径提醒：小团队样本量不足时，一次通过率这类比值的单周方差 会大到读不出趋势。用一个月的滚动窗口，或者干脆先不下结论—— 样本不足时该做的是承认测不准，不是换个指标硬看。
一条更通用的教训
这条脱离本文语境也成立：当一个提效方案的收益看起来违反某种守恒时， 不要先怀疑守恒，先去找那个没记账的成本落在谁头上。
它通常落在三个位置：下游、别人身上、延迟发生的时刻。 这三个位置的共同点是当事人感受不到，所以没人去测； 而没人去测的成本，在账面上就等于不存在。
几处必须说清的边界
这篇是方法论，而方法论最容易显得什么都能解释，所以几个弱点得摆出来。
这个框架自洽，但没被验证过。 本文论证的是它内部一致， 不是"AI 提效为假"。四条筛选器和五个角度是从公开数据加推导得出的， 我没有用它们跑过一遍自己的项目。把它当"下次该测什么"的清单用， 别当"已经证明了什么"的结论。
引用的数据证据等级也都不够硬。LinearB 和 GitClear 是观察性数据， 存在选择效应（愿意让 AI 开 PR 的团队和任务本来就不一样）， 而且两家都是卖度量工具的商业机构，结论方向与产品定位一致—— 这不代表数据是假的，但读的时候该知道。METR 那份是 RCT， 可作者 2026 年 2 月自己发文说设计有偏。 所以这三份只能当"现象存在"的证据，不能当"因果成立"的证据。
"擦除 / 生成"这个二分也是粗糙的。真实开发里两者交织—— 写一个测试同时是生成（产出代码）和擦除（消除不确定性）， 而测试本身还需要被验证，这层递归本文没处理。 遇到判不清的情况，退回"独立检测"那条筛（检测能力是否独立于被测对象）， 它比二分法可靠。
最后，全文不涉及成本。讲的是熵搬到哪，没讲这次搬运划不划算—— token 成本、订阅费、验证工时的货币化是另一套账。 （第一层那个 adjusted compression rate 的提醒在这里第二次生效： 压缩得好不等于总账划算。）
参考
理论侧：
- Landauer, R. (1961). Irreversibility and Heat Generation in the Computing Process —— 擦除一个 bit 的能量下界
- Bennett, C. H. (2003). Notes on Landauer's principle, reversible computation, and Maxwell's Demon —— 把 Landauer 推广到所有逻辑不可逆操作，以及记忆复位成本这个记账模板
- Prigogine, I. (1980). From Being to Becoming —— 耗散结构与负熵流，本文第一步那个熵平衡式的来源
- Lehman, M. M. (1974–1996). 软件演化定律 —— 复杂度递增与质量表观下降，以及那个关键的前提从句
- Delétang, G. et al. (2024). Language Modeling Is Compression —— 训练目标与压缩目标的等价性，及跨模态压缩实测
- Hindle, A. et al. ICSE 2012；CACM 59(5), 2016 版. On the Naturalness of Software —— 代码交叉熵远低于英语，AI 在代码上格外好用的量化解释
- Wei, J. (2025). Asymmetry of verification and verifier's law —— 可验证性决定 AI 能力边界，与本文的擦除侧瓶颈是同一件事的两端
- Verification Is Not Easier Than Generation In General —— 对上一条的反驳，说明为什么判据要按任务类型分档
实证侧（读的时候注意上一节点出的证据等级）：
- LinearB 2026 Software Engineering Benchmarks —— 8.1M PR，AI 与无 AI 的 PR 分开算
- GitClear: The Maintainability Gap (2026) —— 6.23 亿处代码变更，七个代码质量信号的四年趋势
- 2025 DORA State of AI-assisted Software Development —— 吞吐与不稳定性同时上升、30% 开发者不信任 AI 代码；及 DORA 团队后来那篇解读（"verification tax" 一词的出处）
- METR: Measuring the Impact of Early-2025 AI (2025) 与 其 2026 年的设计修正 —— 知觉落差，以及作者自己承认的选择偏差
本站相关：
- Prompt Cache：两族协议的分叉，和 4.48 亿 token 的实测账 —— 本文缺的那种一手实测长什么样：303 个会话的账本，含一次让所有测试保持绿色的数据污染事故
- JIT 上下文：让规则在正确的时刻进入上下文 —— 生成侧的一个具体取舍，以及三个只能靠最小复现抓出来的静默缺陷
- 成本与用量 —— 自己的会话账本怎么看，以及为什么"省了多少钱"回答不了"提效了没有"