本来昨晚打算扫一眼摘要就睡的。
DeliverBench，2611.03412，11 月 2 号挂的 v1，第二天又修了一版。24 个作者，我一个都不认识。
看到 24 这个数字的时候心里冒出来一句「我连一个 README 都写不利索」，然后手指已经在往右下角划了。
我现在的阅读习惯就是 skim 摘要、翻结论、收藏，然后不看。昨晚本来该是同一个流程。
让我停住的是中间那个审计项目的案例。
7 个系统，都处理了那条审查发现，都给出了东西。只有 1 个保留了可追溯性。
这个词在论文里怎么定义的我还没搞懂。但我大概知道那是什么状态：你交一个结论出去，有人问「这个数哪来的」，你能一步一步指回去。
我指不回去。
上周给玩具项目加导出功能，要动三个地方——读数据那层、格式化那层、还有一个按钮。改到第二个文件的时候发现第一个文件返回的结构跟我以为的不一样，就顺手也改了。
导出通了。列表页打不开了。
我盯着那个列表页看了四十分钟。不是看不懂报错，报错直白得很，某个字段 undefined。是我想不起来我为什么要改第一个文件。diff 拉出来，每一行我都认识，但我当时在想什么，没了。
最后整个 revert 回去重改。重改的时候在旁边开了个 txt，一行一行记。
上个月的我大概会直接骂一句然后把代码全删了重写，这次至少开了个 txt。就这么点进步。
我现在的提交记录长这样：
a1b2c3d 改了一下
9e8f7a6 fix
4c5d6e7 再改
这三个，现在的我自己都看不懂，别说三周后。
回到论文。它不给代理注入参考答案，所以前一阶段产生的错误会被带进后面的任务；150 个子任务串成多阶段流程，中间夹着 2 到 15 轮新材料和客户反馈。
看到这句心里咯噔一下。不是被吓到，是被说中了。
我平时练手全是单轮的：给需求，让它写，跑通，收工。跑不通就把需求再讲一遍。这个过程里没有「上一轮的理解错误」这个东西，因为每一轮都从零开始。
真实的东西不是这样的。需求会改口，你第三步理解偏的地方没人帮你擦掉，它留在那儿，到第七步以另一种形状冒出来——那时候你已经在想别的事了。
我那个导出功能算不算一个家庭手工作坊版的、微缩的同一件事？可能是。也可能我是在硬套，把玩具项目的破事往一篇正经论文上贴。不太确定。
刚写到这儿还觉得挺有道理，现在又有点心虚，我是不是在给自己那四十分钟找台阶。
今天的同桌是 Claude Code。我让它把讲评分那一节讲给我听，讲得条理清楚，我一边看一边点头。合上之后我试着跟自己复述一遍，卡在第二句。
我知道这个讽刺摆得太明显了。但我真不是为了写这个才去问它的，当时就是读不动了。
分数：90 分是子任务通过阈值，最好的系统过了 50%；最终交付物 65 分。65 分在什么水平我没概念，不知道那个量规长什么样，也不知道扣掉的 35 分是零星小错还是整块没做。
但 100 分里拿 65 分，意味着一大半地方是不对的。而这些不对的地方，我猜，大概不是「完全不会」，是「做了一半」、「做偏了」、「前面那一步就埋下去了」。
单项任务的能力不会自然叠加成交付能力。
这句我想抄下来贴在显示器上。
夹生的地方还是得说：「一致性维护」在工程上到底指什么？每轮开始前把之前的假设重新讲一遍？context 一直挂着不关？还是每次改动前先写下动机？我猜都有份，但我说不清楚。先记着。
我本来还想说这基准对初学者没什么用。财务尽调、法律合同起草、药物安全报告，11 个项目，13 位专家拿真实材料重建的，这些场景我可能很久都碰不到。
但又想，它量的东西我其实每天都在量，只是项目小到不需要基准，小到靠脑补就能兜住。兜不住的时候，就是那四十分钟。
而且它好像是我看到的第一个把「过程」也拿来打分的，既看过程检查点也看交付物。我以前的自我评价只有两种：跑通了，没跑通。中间那一大片，我从来没量过。
这个是不是大家都知道啊，可能就我一个人卡在这。
明天想试一件很小的事：每次改之前先写一行为什么要改，别写 fix。我知道这话听起来像被说烂了的建议，我收藏过一堆类似的，一条都没执行。这次也不保证。
论文还剩两节没读完，今天实在读不动了。
评论区蹲一个大佬：有没有人真的在做这种多轮、要自己记着前面所有假设的练习？你们是怎么记的？