AI提效这笔账：同一批 246 个 issue 能同时读出 19% 与 24%

开头：同一周出现的两个相反信号

2026 年 10 月 25 日，Apollo 全球首席经济学家给出一份不客气的判断：剔除七家科技巨头之后，标普 493 的利润率与人均收入都是平的，看不到人工智能在改善生产率的证据。TechCrunch 转述时的措辞是「对科技行业之外的美国企业来说，这项技术的财务回报是零」。我核对过这条转述的口径，它针对的是宏观行业样本，本文只作背景，不作结论（来源：TechCrunch 2026-10-25 转述）。

三天之后，2026 年 10 月 28 日，Anthropic 上线了一套面向企业客户的报表工具：依托内部分析与员工调查，让管理者按日期范围查看团队做了什么、产出了什么、花了多少钱、流程在哪里断掉。同一篇报道里还给出两个数——第二季度录得经营利润，净收入留存率 900%（来源：TechCrunch 2026-10-28 报道）。

一边是看不出回报，一边是厂商开始卖「回报报表」。这两件事并不矛盾，但它们把同一个问题推到了台面上：所谓 AI提效：AI提效这笔账，到底该怎么记？

我先把口径交代清楚。谈 AI提效之前必须声明一件事：下面所有数字来自预印本摘要与公开报道，预印本未经同行评议，我未做复现；厂商报表的功能描述来自媒体报道，我未实测该产品。数字与限定条件我会一并列出，供参考，不作选型结论。

AI提效的两种算法：秒表视角与台账视角

2026 年 10 月 23 日提交到 arXiv 的一篇论文，题目就叫《数绷带：论测量人工智能省下的时间》。作者做的事是把「省时间」这件事拆成两种互不兼容的算法，我认为这是本周最值得读的一篇（原文见 arXiv 2610.35942 论文页）。

秒表视角：时钟记下多少，AI提效就是多少

秒表视角最接近直觉。同一件事，用工具之前花 30 分钟，用工具之后花 18 分钟，那么省下 12 分钟。它的优点是简单、可自动化、不需要任何建模；缺点是它只记录时钟，不记录这一次工作放过去了什么。

台账视角：省下的时间是一个反事实

台账视角认为「省下的时间」本身是一个反事实量，必须和「这次工作漏过去的缺陷」并排读才有意义。作者给出一对不依赖模型的量——省下的时间与超额逃逸缺陷——以及一个由两者合成的决策数字：盈亏平衡缺陷成本。

我在这里停了一下。这两个视角的差别不是学术细节，它决定了你会不会在报表上看到一个永远为正的数——按这个视角，AI提效天然为正：只要时钟变短，秒表视角下的 AI提效就是正的，而台账视角要求你同时回答「漏掉的那一个后来花了多少」。

AI提效的测量为什么难：同一批 246 个 issue 读出两个数

论文里最锋利的一段，是作者用 METR 开发者研究的公开数据做了一次复现。结论是：同一批 246 个 issue，可以支持 19% 的减速估计，也可以支持 24% 的减速估计，取决于你把估计目标定成什么；如果不校正一次机会性不平衡，这个数会变成 34%。

这不是数据出错，而是估计目标不同，也说明任何一个点估计都带着未声明的前提。同一份数据里，AI 起作用的 issue 比例在 3% 到 82% 之间——区间宽到几乎不能用于任何决策。

我把这一段放在靠前位置，是因为它解释了为什么「别人家的数字」无法直接搬用：你看到的每一个提效百分比，都绑定了一个你没被告知的估计目标。

19%、24%、34% 分别对应什么

下表把这几个数放在一起。需要说明的是，三个减速估计都指向同一个方向——在这批数据上，使用工具之后完成时间变长了——差别只在幅度与口径。

3% 到 82% 这个区间意味着什么

论文还重述了已发表记录里的另一组观察：在 GDPval 自己那套「每一条产出都要复核」的工作流里，光是复核时间一项，就把 GPT-5 的加速上限压到 3.6 倍；而处在前沿之外的顾问做得更快，同时也更常出错。

我在这里看到了与秒表视角的直接冲突：AI提效在秒表上可以很漂亮：复核时间不算入账面，AI提效看起来就是净收益；一旦把复核时间放回账本，加速上限立刻变成一个有限数。

复核成本：检查时间随错误率对数增长

论文给出的基线模型有三条结论，我认为每一条都值得工程团队抄进自己的流程文档，因为它们把收益的边界画了出来。

三条结论与盈亏平衡缺陷成本

• 在模型好到不必检查之前，一个经过校准的执行者，其逃逸缺陷率与模型好坏无关；
• 检查时间随模型错误率的对数增长，而非线性增长；
• 过度信任在时钟上买来几分钟，代价是总分钟数上更大的支出。

三条合起来得到一个可操作的数：盈亏平衡缺陷成本。它的含义是，当省下的时间价值超过多漏掉的缺陷所造成的成本时，这次提速才真正成立；这个临界点由你自己的缺陷成本决定，不能从别人的报告里抄。

被告知错误率低十倍之后，复核少查了七个数字

论文最后给了一个小样本预登记实验，用的是训练数据截止之后发布的 SEC 文件生成的简报，让 AI 复核者去查 AI 起草的同类简报。

结果分两组。被告知起草方真实错误率的那一组，复核量随错误率上升而增加，但增加方式是全有或全无——在提示成本达到盈亏平衡的附近整体切换，而不是渐进调整。

被告知起草方的出错频率低十倍的那一组，表现是：9 个数字里少查了 7 个，放过一个错数字的简报比例从 0 变成 22.5%。作者的总结是「更快，也更差，而且完全是通过减少投入实现的」。

这条我读了两遍。它说明复核强度不是一个由理性计算持续调节的旋钮，而是一个受信任度触发的开关——你告诉它风险低，它就关掉。

两张对照表：秒表与台账的差别

两张表合起来给出一个判断：讨论这类数字时，先问对方用的是哪一张表。两张表的结论可以相差一个符号。

我按这两张表回头看了一遍自己过去三个月的周报，发现一个规律：凡是只报时钟数的周，数字都好看；凡是同时报返工条数的周，数字都要打一次折。这个折不是工具的问题，而是口径的问题——前一种报法默认了返工为零。

厂商开始卖 AI提效报表：Anthropic 给出了什么

2026 年 10 月 28 日上线的这套报表，是厂商第一次把「你花的钱买到了什么」做成产品，也是 AI提效第一次有了商业化的度量工具。按报道的描述，它包含四类信息：给定日期范围内团队的工作、团队产出了什么、花了多少成本、以及工作流在哪里断掉。报道还提到两条限定：这些数据默认不用于模型训练，报表还会给出改进建议。

报表里有哪几栏，以及它不覆盖什么

我把这四栏与台账视角做了对照。前三栏（做了什么、产出什么、花了多少）是台账的第一栏，也就是成本与产出；第四栏（流程在哪断掉）开始接近第二栏，但它描述的是流程断点，不是逃逸缺陷。

差别在于：逃逸缺陷是事后才现形的量，流程断点是当时就能观测的量。用断点去近似逃逸缺陷，在缺陷潜伏期短的场景里尚可，在长周期场景里会系统性低估。这一点是我的推断，不是论文的结论，供参考。

三处需要注意的局限

• 报表口径由厂商定义，跨厂商不可比，也不保证与你的内部口径一致；
• 员工调查是主观输入，会混入团队情绪与汇报动机；
• 「产出了什么」仍是产出侧指标，不含事后被撤回或被返工的比例。

还有一处容易被忽略：报道里提到的 900% 净收入留存，衡量的是同一批客户一年后的支出变化，它说明的是客户在加大使用，并不直接说明单位产出提高。把这两个数放在同一张幻灯片上，容易读成因果关系，而报道本身并没有这么断言。

社区在补的那一栏：给每一次提交开一张收据

学术侧在问「怎么测」，厂商侧在卖「报表」，而开源社区在过去几天里做的是更朴素的事——给 AI提效补上第二栏——把第二栏记下来。

我按创建时间读过这批仓库的自述：fish2lab/git-tab 给每一次由 AI 参与的提交开一张收据，记录 token、模型与成本，覆盖 Claude Code、Codex、pi、OpenCode 等来源；Jfri3ss/token-economy 是一个 Claude Code 插件，做法是模型路由加一道输出守卫，再加一段定长的收尾检查；schelmi1/vsc-codex-session-observer 是本地优先的 VS Code 扩展，观察 Codex 会话、子智能体、工具活动与 token 用量；Dynesshely/dsh-plugin-wakatime 把与 AI 一起写代码的时间报给 WakaTime，标记为 ai coding 心跳；HTMLGuyLLC/NoActually 则是一个本地优先的计分卡，记的是你抓到 AI 出错的次数。

这批工具的另一个共同点是粒度：它们都把记录绑到单次提交或单次会话，而不是绑到周或月。我认为这个选择是对的，因为逃逸缺陷只能回溯到具体某一次改动，按月聚合的数据无法支撑归因。

需要说明两点：星数是 2026 年 10 月 29 日的快照值，不作能力证明；这些仓库自述的功能我没有实测，只作存在性证据，不推荐替代自建埋点。

我在自己的流程里怎么记这本账

按上面的材料，我把自己的做法整理成四步。它不追求精确，只求这本账最后能对得上。它不保证你的团队适用，但每一步都有公开来源支撑。

四步记账法：把 AI提效记成两栏

第一步，先声明口径。写清楚你报的是秒表数还是台账数，两者不要混在同一张报表里。

第二步，把账本设成两栏。左边是省下的分钟，右边是逃逸缺陷的条数与后续处置成本。只记左边那一栏，等于默认右边为零。

第三步，给复核留固定预算，并让它随观测到的错误率调整，而不是随信任感调整。那组「被告知错误率低十倍就少查七个数字」的实验结果，是我坚持这条的理由。

第四步，每月重算一次盈亏平衡缺陷成本，用它决定下个月是加大复核还是加大自动化。

下面这段是我用来记账的结构，字段刻意保持很少：

# 一次任务的台账记录：左栏省时，右栏逃逸
entry = {
    "task_id": "T-42",
    "minutes_baseline": 30,     # 不用工具时的历史中位数
    "minutes_with_ai": 18,      # 时钟记录
    "review_minutes": 9,        # 复核投入，必须单独记
    "escaped_defects": 1,       # 事后才发现的缺陷
    "defect_cost_minutes": 45,  # 单个缺陷的处置成本，按你自己的历史填
}

saved = entry["minutes_baseline"] - entry["minutes_with_ai"] - entry["review_minutes"]
cost = entry["escaped_defects"] * entry["defect_cost_minutes"]
print("净节省", saved - cost, "分钟")
​

真正难的是最后一个字段。它不能从论文里抄，也不能从厂商报表里读，只能从你自己的工单系统里回溯。

盈亏平衡缺陷成本可以这样算：

# 盈亏平衡：省下的时间刚好抵消逃逸缺陷的成本
def break_even(saved_minutes_per_task, escape_rate, review_minutes):
    net_saved = saved_minutes_per_task - review_minutes
    if escape_rate == 0:
        return None
    return net_saved / escape_rate   # 单位：分钟/每个缺陷

for rate in (0.02, 0.05, 0.10):
    v = break_even(12, rate, 9)
    print("逃逸率", rate, "时，单个缺陷成本的上限是", round(v, 1), "分钟")
​

我按自己的历史数据跑过一遍，得到的上限比预期低不少。这个数的作用不是证明什么，而是把「要不要少查一点」从感觉问题变成算术问题。

常见问题

关于 AI提效，19% 和 24% 到底该信哪一个？

两个都是同一批数据的合法估计，差别来自估计目标的定义。论文把它们并列给出的用意，恰恰是说明单一数字不足以支撑决策。真正需要注意的是第三个 34%——它未校正机会性不平衡，作者明确标为不可直接引用。

既然这批数据显示变慢了，是不是说明这些工具没用？

不能直接这么推。这批数据的场景是有经验的开发者在熟悉仓库上做真实 issue，测量的是完成时间；工具在新代码、陌生领域、文档与脚本类任务上的表现不在这一批的覆盖范围内。论文的贡献是给出测量口径，不是给出能力结论。

台账视角听起来很重，小团队也要为 AI提效做两栏账吗？

看缺陷成本。如果漏一个缺陷的处置成本只有几分钟，秒表数就够用；如果漏一个的代价是线上事故或客户返工，两栏账本的边际成本远低于它的收益。折中做法是先只记「事后被撤回的提交」这一条，成本很低。

厂商报表能不能直接当台账用？

部分可以。报表覆盖了成本与产出，也覆盖流程断点，但流程断点不等于逃逸缺陷，且口径由厂商定义、跨厂商不可比。我的做法是把报表当作第一栏的数据源，第二栏仍然自建。

复核强度到底该怎么定？

不要按信任感定。论文里的观察是检查时间随错误率对数增长，且实际行为表现为全有或全无的切换。可操作的做法是先测出自己场景下的观察错误率，再按盈亏平衡缺陷成本反推复核预算，并写进流程文档固定下来。

那批 GitHub 小工具值得接入吗？

我未实测，不作推荐。它们的共同价值在于示范了一种记账粒度——把 token、模型、成本与复核时间绑到单次提交或单次会话上。如果你的团队已经有埋点，照这个粒度补两栏即可，不必换工具。

有没有可能既省时间又不增加逃逸缺陷？

论文的基线模型给出的答案是：在模型好到不必检查之前，经过校准的执行者其逃逸缺陷率与模型好坏无关。换句话说，靠「模型变强」本身换不来逃逸率下降，能换来的只有检查时间的对数下降。要压逃逸率，得动复核那一栏。

小结：先问是秒表还是台账

AI提效的讨论之所以经常各说各话，是因为两边拿的不是同一张表。秒表表上，只要时钟变短就是赢；台账表上，得先回答漏掉的那一个后来花了多少。

2026 年 10 月下旬这几件事——一篇把 METR 数据读出两个数的论文、一套厂商上线的花费报表、一批把收据绑到单次提交的开源工具——指向同一个动作：把第二栏记下来。我自己的做法是：在团队周报里保留两栏，第一栏写时钟数，第二栏写当周被撤回或被返工的提交条数，两栏都公开。第二栏一旦开始被记录，第一栏的讨论就会自动变得谨慎一些。

在此之前，任何关于 AI提效的数字都只是一个尚未对账的断言。