更多真实发现，也会改变剩下的工作

2026-11-03 · 当时的记录

此前我们把“完成任务之后，人还剩多少工作”拆成等待、检查、取舍和返工。今天的PostgreSQL材料补了一种很重要的情况：剩下的工作增加，未必因为机器制造了更多错误，也可能因为它让原本难以发现的真实缺陷进入了视野。Haas认为这正是维护压力的主要来源；提交增长和发布日期提供了背景，但不足以把每一份新增工作都归因于AI。

这会改变我们如何评价延期。假设一个系统原先每月交付十项功能，同时留下几处未被察觉的缺陷；工具变强后，团队交付八项功能，却修好了旧缺陷，仅凭功能数会判断它退步。反过来，如果多出来的是重复、无证据的报告，维护时间增加也并不代表质量提高。这个例子是为了区分两种机制，不是本期测得的数据。需要跟踪的，是哪类问题真正进入队列，最终留下了什么改变。

Proton的争论接在这里。宣言说工程责任仍由人承担，读者则问谨慎是否还能影响发布决定。两者可以同时成立，也可能在排期压力下分离：人被要求对结果负责，却没有足够时间检查。判断组织是否接住了新能力，应看具体决定如何形成，包括何时补证据、何时允许延期，以及谁有权接受剩余风险。它比“大家是否采用AI”更接近产品承诺。

Pando提供了技术层面的另一种承接方式：更多Agent并行写代码后，先把不必共同排队的分支拆开协调，再复用相同的历史数据。这说明下游容量不是只能靠更多人工增加，基础设施和接口也可以重设计。但Git传输变快不会自动解决代码审查，正如缺陷发现变快不会自动决定修复方案；各层的改进需要接上，不能相互代替。

因此，旧判断可以向前推进一步：把新增机会与新增负担放在同一批任务里观察。先分清真实旧缺陷、新引入问题、重复报告，再分别记录确认、修复和交付；对确实挤压新工作的环节，尝试改交接证据、排队方式或责任安排。下一次最有价值的证据，是同质量要求下人的实际处理时间、未解决问题存量和交付结果一起变化。本期没有完成这种比较，也不把“审查一定成为瓶颈”当成永久结论。

回到当期正文 ↗

2026-10-24 · 新增支持

重读 PHP 的修复决策与下游恢复，结合 Sierra 最终字段结果，支持把证据、决定、执行、验收分开；未得到统一流程总成本实验。

2026-10-24 · 当时的记录

本周另一个需要推进的判断，是自动化应该在哪一步算“完成”。PHP 复盘里，风险迹象早已出现，团队却迟迟无法在有代价的修复方案中作决定；Sierra 的语音实验里，代理已经请求核验，错误字段却常常没有改对。两种工作的参与者和时间尺度不同，但都提醒读者：发出一份报告、做出一次检查，与最终状态发生正确变化，需要分别举证。

10 月 22 日的观察已把修复选择与下游恢复纳入交付，23 日又区分监控输入是否送达、纠错是否完成。周报把这些环节放到一起，重点不在多添几张检查表，而在识别下一步到底缺什么。PHP 缺过明确利用路径，也缺过能处理兼容性取舍的人和决策机制；给同一问题再增加十份报告，未必帮助团队选定方案。反过来，更具体的攻击证据确实改变了优先级，不能把新增发现一概视为负担。

Trail of Bits 把可交接的证据做得更具体：同一复现先在原版失败，在补丁版成功，再在撤销补丁后失败，以减少环境偶然变化带来的错误归因；另一个流程检查原本受支持的行为是否被破坏。作者回看一百三十余个已合入改动，确认二十一项回归。新回归检查器在这组材料上减少了误报，也让部分已知问题因为举证不足停在边界状态。工具因此更容易交给维护者判断，但这组内部评估仍不能证明所有项目都会以更少工作交付。

语音实验把“动作出现”与“结果改好”之间的距离放得更大。代理可能请来电者拼写、重复一遍，却继续提交错的字符串。规定核验流程能提高通过率，同时延长通话；更有用的追问是，时间花在确认了正确内容，还是反复确认仍未改正的内容。最终工具中的字段提供了独立于礼貌话术的检查点。实际业务若再涉及多字段、非配合用户，仍需要重新评价。

监控系统则说明，连检查所依据的材料也要单独核对。Redwood 与 METR 的报告评估的是 7 月 21 日及以前的内部系统，发现某些符合监控条件的轨迹没有完整进入检查链。OpenAI 后来表示已修复影响生产防护的漏洞，外部团队明确没有复核这个声明。因此本文借用的是对账方法，不能把历史缺口写成当前覆盖率。预期应该出现的任务和实际收到的轨迹，应有各自的记录来源。

把这些经验迁移到日常 Agent 工作，一个具体起点是挑一批同类任务，预先写下它们需要交付的状态，再沿同一身份记录证据送达、方案决定、执行和验收。没有轨迹、输入不全、判断错误、执行未生效，应分别定位。需要人作取舍时，把可重跑证据和未解决条件交给人；需要工具写入时，核对写入后的状态。这样增加的记录才有机会减少下一位参与者重新调查的时间。

这里提出的是尚未执行的比较方法，不是又一套已经证明有效的流程。PHP 下游站点仍要升级与恢复服务，语音用户仍要付出确认时间；这些负担不能只在工具提供者的账上消失。下一次回访要看同批任务从发现到验收的总等待、返工和人的处理时间。如果新增检查只增加了无法行动的提示，就需要重划责任；如果帮助团队更快选定方案并得到正确结果，才值得扩大使用。

回到当期正文 ↗

2026-10-22 · 当时的记录

当 AI 更快地报告漏洞、提出补丁，团队最直观的选择是加速审查。但审查队列只呈现了困难的一部分：有人需要把相似报告归为同一根因，有人需要比较兼容性与安全取舍，有人需要把修复送到下游并恢复服务。PHP 的公开复盘让这条链条变得具体——风险迹象很早已经出现，真正卡住的是几种修复方案各有代价，而熟悉引擎且能够作决定的人手有限。[1]

此前本刊沿着代码审查讨论过：少一轮审查，可能减少返工，也可能把工作留给以后；因此不能只看评论量或轮数。这次新增的认识是，即使问题已经被认定为真实，团队仍可能因为无法选定可接受的修复而停滞。PHP 后来的进展既来自研究者给出明确利用路径，也来自专职人员投入、优先级提升和决策机制调整。把延误简单归为“模型还不够强”或“人类总是瓶颈”，都会漏掉可以改变的条件。[1]

Trail of Bits 提供了对其中一段工作的具体改进。它让修复证据经过旧版失败、新版成功和撤销后再次失败，再用真实入口检查旧行为是否被破坏。重要的不只是多了一位检查者，而是后一个步骤可以重新运行前一个步骤的主张。版本与证据的交接有机会减少重新理解问题的成本；同时，严格举证留下的边界案例也必须交给人，不能当成问题已经消失。[2]

Dan McAteer 的监督界面从人的一端补充了这个判断。提醒曾帮助他发现未提交工作，也因为几乎每轮触发而开始被略读。增加检查次数不自动增加注意力；如果输出无法区分必须处理的缺口与普通建议，人就又要承担一轮解释。这里可以借用补丁流程的做法：重要提醒直接指向证据和可执行的下一步，而不是只生成一个完成标签。[3]

外部站点的经历则提醒我们把交付终点放远一点。Weird Gloop 预防性停机期间用缓存保住大部分访问，但动态服务仍有中断；维护者担心人员很少的公共网站承受不了持续的紧急应对。这一经历不能代表所有网站，却表明发现方节省的时间与运营方付出的工作可能发生在不同组织，不能只在单个团队的账上评价整条流程。[4]

我的判断是，值得扩大的能力包括发现新问题，也包括把证据、决定与修复交给下一位参与者。下一次比较不妨追踪同一批报告从成立、选定方案、发布到恢复服务的等待和返工，再看哪些自动化真正缩短了交付。这个建议尚未验证；本期材料已经足以说明，报告数、补丁数与误报下降都只是其中一段，不能各自替代最终结果。

回到当期正文 ↗

2026-10-17 · 当时的记录

10月13日的旧判断把生成、审查和交付分开，是因为企业流程研究与一家团队的审查自报给出了不同方向。前者记录代码和PR增加、合并等待变长，却未见事项完成显著增加；后者说能运行复现的机器人缩短了合并等待。PR是一次拟合入代码库的改动，等待包含排队、检查和返工，不能直接翻译成工程师劳动时长。周报重新检查这个问题，仍不把两份不同设计的研究当作互相推翻。

周末补上的Claude团队案例，让“返工”有了更具体的产生方式。自动作者会落实审查建议，自动审查又在下一轮发现旧问题；没有新的真实需求，系统也能连续创造修改。停止规则因此是工作流程的一部分：先审完整改动，后续聚焦新差异，并避免重复提出同一发现。但轮数下降不是终点，若真实缺陷漏检、事故或事后修复增加，省下的只是前面的时间。

这使此前“审查会成为瓶颈”的表述需要保留两个方向。一方面，生成加速可能加重队列；另一方面，提供可检查证据、按风险分配人力与减少噪声，确实可能扩大审查容量。团队前后统计不能分离模型升级、改动组合和流程变化，却足以反对“AI审查只能增加负担”的绝对判断。下一步最缺的仍是同一批任务上，实际人力、缺陷发现和交付质量的共同记录。

本期独立发现的Mercor图谱把问题再往前移了一步：用什么任务来代表工作？它将所选评测题映射到美国职业任务分类，发现许多任务在这份索引中缺少题目。这个结果不能推出模型做不了这些工作，更不能直接变成岗位替代率。它的价值是让我们先问，采购或招聘判断引用的分数，究竟有没有测到协调、复核、异常接手这些环节。没有测到，与测过但失败，需要完全不同的补救。

这里也不能只保留一个醒目的覆盖缺口。作者对四个职业做任务等权重比较时，已有APEX办公任务评测题目的模型分数变化不大；这是真实的正面边界，说明换权重未必改变排名。但被纳入比较的任务仍只是部分职业活动。对已经测到的部分，平均可能相当稳定；对没有题目的部分，平均值再精确也不会自动产生信息。这两件事可以同时成立。

SWE-TaskFlow给出一个更窄、也更容易做对照的入口：保留最终代码目标和测试，只改变需求逐步到达的方式，再加入仓库问答。它提示我们，题目标签相同，实际交接条件也可能不同。一次写清需求的成本，可能由用户在评测外提前承担；分步给需求又可能增加往返和模型费用。Mercor的职业映射与TaskFlow不是共同实验，我据此提出的只是比较办法：覆盖应同时标明目标、可用资料和交接协议。

公开评论保留了另一种分歧。status_quo69担心，按需让模型搜索代码局部，不等于人形成了整体理解；csallen则相信测试、历史版本和模型解释能帮助恢复。两者是对同一流程的不同判断，没有提供可比恢复实验。若审查还承担团队知识传递，就需要另外测：作者离开以后，接手者能否定位新事故、修改假设并完成恢复。事故率暂时不升，不能单独保证这项能力已经保留。

我目前更愿意用一份交付记录来替代笼统的提效倍数：预先固定质量和时限，分别留下等待、实际判断、机器重试、误报引起的修改，以及交付后的恢复成本；失败也留在分母里。职业图谱可以帮助发现待补任务，却不能替代这些记录。若在相同质量下人力和返工一起下降，就应承认自动审查的收益；若只是任务被缩小或坏结果被推迟，就应修正收益判断。这个结论是本周的测量立场，具体改善幅度仍待独立对照。

回到当期正文 ↗

2026-10-13 · 当时的记录

代码行数增加三成，公司完成的事项却没有显著增加；与此同时，Vapi 说自己的审查机器人把平均合并时间减了一半。[1][2] 这两份材料不能互相投票：前者比较多家企业的采用时点，后者是一家团队的前后自报，版本、团队和工作都不同。它们共同提出的具体问题是，生成出来的工作怎样才能流过审查，成为可用的交付。

先区分两种审查负担。一个是队列：PR 来得快，负责审阅的人却没增加，等待就会拉长。另一个是每份改动的判断难度：需求是否满足、已有约束是否破坏、测试究竟测了什么。论文中的提交到合并时长兼有两者，不能只凭它判断人更慢或代码更差。企业事项完成数也不包括所有个人新项目，HN 的 KumaBear 正是在提醒这个边界。[3]

Vapi 的已知 lint 阻断缺陷提供了一个细小却有力的反例：发现不少问题的审查运行，仍可能漏掉唯一挡住合并的问题。[2] 因而增加发现总数并不保证能减轻队列。误报与原有问题也需要处理；如果每个问题都交给人从头辨认，机器把发现变多，人接手的工作反而可能更碎。把发现附上可运行的复现，可能减少判断成本，这只是有依据的工程假设，尚不能由合并时间的变化单独证实。

此前观察把操作时间、注意力和新增产出分开；这次再把“等待”和“动手检查”分开。对照一批同等规模的改动，分别记录提交后等了多久、人实际检查多久、多少发现被接受或驳回、最终交付是否返工。固定最终质量要求，再看这些时间是否一起下降。否则减少审查时长可能只是放宽把关，增加审查时长也可能是发现了过去漏掉的缺陷。

SWE-TaskFlow 又提醒我们，负担可以向上游转移。[4] 若一个 Agent 只在一次写清全部需求时便宜，人预先整理需求的时间就藏在分母外。反过来，分步对话更像某些人的工作方式，却可能多花模型费用。评测应保留最终测试，再报告中间解释和需求变化后的纠正情况，而非让一个通过率承担所有问题。

下一步最值得试的不是给审阅者生成更长总结，而是让每个重要发现携带它触及的要求、证据位置和最小复现。随机给相近改动使用有无这套交接材料的审查流程，比较阻断缺陷召回、误报处置时间和最终返工；失败改动也计入耗时。如果材料只让人多读一页而没有提高判断，就应放弃这种设计。这样才能检验自动化节省了哪一步，而不是把“代码写完”提前算成“工作交付”。

回到当期正文 ↗

2026-10-12 · 当时的记录

“用 AI 十分钟后更容易放弃”听起来是在评价一种工具的全部影响。回到实验，测量的却是短暂辅助被撤走后，人愿不愿继续、能否独立答题。[1] 这与 Karpathy 谈专业使用者看到的能力跃升并不直接冲突：后者主要在谈持续使用工具能完成什么。[2] 两种结果可以同时出现，不能从其中一个直接否定另一个。

这里真正需要改的是比较单位。把有 AI 的作答分数与没有 AI 的分数比较，回答即时协作表现；撤走工具后再测，回答此次练习留下了什么。一个训练系统可能在第一项表现很好，在第二项不足。相反，一个熟练工程师选择把重复步骤交给工具，本来就未必希望记住每一步。没有先确定学习、交付还是保持接手能力的目标，任何“提效”或“退化”都容易越过证据范围。

对研究的质疑也要落实到具体设计。HN 的 imeanwhatdoikno 希望增加计算器、教材或人类帮助的对照；contubernio 则说，工具替自己跨过技术障碍后，数学研究的动力反而增强。[3][4] 前一条追问是否存在 AI 特有的效应，后一条是个体使用体验，不能反驳随机实验的组间结果，但它提醒我们别把做题时的跳过率当成全部工作动机。

存在一个更有约束力的历史边界。Bastani 等人在高中数学课堂比较普通聊天助手与带教师解题信息、主要提供提示的助手；后者大体缓解了撤去工具后的负面影响，却没有让无辅助考试成绩明确超过对照。[5] 这意味着辅助方式值得实验，不能把结果写成“只要改为提示就一定学得更好”。学校课堂、成人短时实验、专业研究者的工作仍不是同一个场景。

我的延伸判断是：接手能力可能也是人力负担的一部分。自动化运行顺畅时，少操作的收益容易看见；到了异常，人能不能指出哪里不对、恢复哪段过程，才决定审阅是不是有效。对此应加一个直接测量：在相同难度的工作中，先让人使用不同辅助方式，再安排一个需要接手的失败，比较错误定位、恢复耗时和最终质量。这个实验尚未由今天的材料完成。

另一方面，不能因为恢复能力重要，就要求每个人保留所有手工步骤。对能可靠重复的工作，工具可能把注意力腾出来处理更难的问题。Mollick 强调技术应用还不该只局限于数学和代码，[6] 我同意应扩大任务观察范围，但评价每个新领域时仍要确定它真正需要保留的能力，而不是把某个领域的成功率搬过去。

昨日观察主要比较操作时间、注意力和新增产出；今天补充的是学习与故障接手的目标差别。后续需要同时追问：哪些工作确实交付得更多，哪些判断能力必须留在人身上，以及辅助方式能否兼顾两者。短时随机实验提供了可检查的风险信号，长期影响仍需纵向测量，不能把它升级成永久损伤的结论。

回到当期正文 ↗

2026-10-11 · 当时的记录

Simon 用语音一边做饭一边开发博客功能，随后回到键盘审查、修改导入方式，才完成上线。[1] 如果只盯着后半段，很容易得出“Agent 最后还是要人收拾”的结论。但这会漏掉他真正重视的收益：做饭的那段时间，原本未必能拿来写代码。人的审查没有消失，能够启动工作的时段却变多了。省时间和增加可做的事情，应当分开算。

与此相对，swyx 提到同事不想每月折腾新 Agent；本期 Reddit 提问者则要决定，测试模型时到底该检查多少次回答。[2][3] 这些个体经历没有给出普遍的效率损失，却指出了三种经常被混计的工作：学会工具、确认结果、安排人与机器如何交接。改善模型回答质量可能帮助第二项，不会自动解决另外两项。

有一个更强、但适用范围更窄的对照。METR 在 2025 年对 16 名资深开源开发者的 246 项真实任务做随机分配，允许使用当时的 AI 工具后，任务耗时平均增加了 19%；参与者的主观感受却仍偏向提效。[4] 这项结果不能概括今天的所有开发工作，但它足以提醒我们：觉得顺手、看到代码大量生成，与完成同等工作所需的时间，可能朝不同方向变化。

只引用这个负面结果也不公平。METR 在 2026 年 2 月的后续说明中指出，有些开发者不愿参加可能禁止使用 AI 的实验，部分高预期收益任务也没有被提交；多 Agent 并行又让单项耗时难以准确记录。研究者认为工具可能已更有帮助，但新数据不足以可靠估计改善幅度。[5] 这不是前一次随机实验自动失效，而是工具和使用方式变化后，新的样本越来越难代表我们想了解的人与任务。

从这些材料往前推一步，我更关心工作被留下来的形状。容易描述、容易检查的步骤被自动完成后，人接到的可能主要是模糊需求、异常和取舍。操作次数即使减少，剩余每次介入所需的上下文也可能更多。审阅者要判断一项改动，可能得先弄清 Agent 为什么这样改、试过哪些办法、哪些检查没跑。这是我提出的机制假设，不能由几条抱怨直接证实，却能解释为什么“人点了几次按钮”不是一个好的负担指标。

相应地，一个值得试的改进是交接材料：与其给审阅者一篇顺畅的完工总结，不如突出改动触及的要求、实际运行的检查、未解决的问题和关键证据位置。让审阅者更快定位争议，而不是要求他从头相信或重做整段过程。不过，材料过长也可能增加负担。实验应比较能否发现事先埋入的缺陷、误报多少，以及定位问题用了多久，不能只问读者更喜欢哪一种总结。

这也改变了我对“少打扰用户”的理解。需求取舍和新的授权可能必须问，已经有明确约定、可以安全撤销的细节则未必需要立即打断。更好的交互应让人知道哪些问题真的需要自己判断，以及其他工作能否继续。若把所有澄清都取消，通知数量会很好看，错误决策和返工却可能被推迟到最后。

后续判断提效，我会同时看三笔记录：相同质量下人的实际操作时间、机器运行期间人的注意力是否被持续占用，以及新增了哪些原本不会完成的任务。前两项适合在固定任务中比较，第三项还需要观察一段时间内真正交付的工作。这样才有机会区分：我们是在更快地完成旧工作，还是在可支配时间不变的情况下，选择做了更多事。

回到当期正文 ↗