八月那篇 I Write Less Code Than I Used To，我当天就读完了，一个字没写。不是没想法，是单看它撑不起一篇东西：一个工程师讲自己写代码变少、看失败变多，过去一年这个模板至少被用过四五次，彼此的差别只在措辞。三个星期之后我才坐下来，是因为把那三十一条评论、作者在回复区来回拉出来的那条线，跟正文拼在一起之后，形状变了。正文讲的是一个人的角色转变，评论讲的是一个资产以什么速度折旧；前一半是感慨，后一半才是结构。
作者在巴塞罗那，做可解释 AI 十年，自己的工具叫 OrKa，所以他对"信任"这件事比一般工程师敏感，这一点不奇怪。他那套论证也很干净：实现这一环的价格在往下走，端点、数据迁移、转换、测试骨架，把问题描述清楚再给点上下文，很快就能拿到一份看起来能跑的东西；真正贵的是实现之后，这段东西在团队真正在意的那些情形下行为对不对。一年前他花更多时间想怎么实现，现在花更多时间想它会怎么坏，比如模型收到没预料过的输入、两个组件给出互相矛盾的结论、看起来很漂亮的答案里塞着错证据、回退路径静默地换了供应商或者区域或者延迟、所有请求都返回 200 而整个系统仍然是错的。他落脚在一句话上：他从生产实现的人，变成追问实现必须证明什么才值得信任的人。
到这里为止，这是个舒服的故事：老岗位在退，新岗位接上，人从搬砖变成定标准，尊严保住了。这个模板我去年也用过。问题是作者自己给出的那个循环，比他的落脚句走得远得多。他在回复区说，人类判断一旦发现并理解某个失败模式，这个判断本身也可以被部分自动化，所以有价值的部分持续前移；今天设计评估器，明天评估器变成基础设施，注意力转向它仍然看不见的东西。
这句话展开一点就不是台阶，是跑步机。台阶走完了你站在高处，跑步机的意思是不跑就被甩下去。而跑步机的速度不在正文里，在评论区被量出来的那一条。
有个叫 Sergei Parfenov 的评论者说了一件我认为是整页最狠的事：评估器一旦成为生产工件，实现就会开始针对它优化，有意也好、通过反复调优也好；每把一个已知失败编码进去，那个案例就变便宜了，但同时评估器与被它评分的那个系统之间就变得更不独立。所以他建议把冻结的留出集、评估器的版本、以及每一个守卫是在事故之前还是之后写下的，都记录成结果的一部分，否则一个今天看起来价值很大的小守卫，会随着它每塑造一次下一个实现，作为证据慢慢贬值。
同一条线程里还有两条应该并排看。一条是 Reid Marlow 的：评估器最贵的地方在于它可能被欺骗，两个号称独立的检查如果复用了同一份理想答案或者同一个损失信号，就会一起失败，而且往往要等到一次糟糕的发布之后才被发现。另一条是 Jonathan Murray 把这条说成了更锋利的形式，独立性关乎来源，不关乎数量，两个评估器不会因为数量是二就独立；他顺手给了一个我认为应该被抄进很多团队流程里的操作，falsifier 必须写在它要捕获的对象存在之前，每个功能在设计阶段用一句话写明哪种具体的错误行为会导致这个功能被撤回，通过的意思是那个特定事项被主动排除了，不是没人反对。
把这几条摆在一起，形状就出来了。判断力确实在变贵，这点没什么可争的；但判断力不是一个能长期持有的位置，因为判断一旦被说出来就变成了工件，工件会进入下一代实现和下一代模型的上下文，然后回过头来让做出那次判断的人贬值。真正该问的不是"我要不要去学写评估器"。
把这件事放回三层棋盘。模型层生产原始的能力，壳层把能力包装成能用的工作流，场景层是真实流量、真实失败、真实用户习惯沉淀的地方。评估这件事我此前是归错的：去年我把它放进壳层，理由是它看起来像工作流整合，写几段检查、接几个信号、塞进 CI，形态上确实像壳层的活。这个格子后来证明分错了。壳层的护城河按我自己那套判断标准，是能不能锁住开发者的项目历史和协作习惯；评估资产完全不满足这一条，它锁住的是失败分布（一家公司真实的输入场景，和它真实的失败清单），而失败分布只有在你手里真的跑着流量的时候才会长出来。也就是说，评估天然是场景层的资产。这一个格子分错，连带的方向也跟着偏了：我当时对"评估工具能不能独立成一个品类"的判断偏乐观，以为那是一层能立住的东西，实际上它更像一个迟早会被两侧之一吃掉的功能。
按重新归过的格子往下推，那台跑步机的速度就有了来源。个人的评估能力会随着模型能力上涨而贬值，因为写评估器这件事本身可以被生成，作者自己也说难点从来不在写，在于决定它该测什么；而拥有失败分布的组织资产不贬值，因为分布只能从运行里长出来，不能从推理里推出来。所以"评估工程师"这个岗位（作者说他找不到一个标签能盖住自己这几年的转变，有人给他补了一个更准的名字叫证据工程师），我倾向认为这不是一个能长期持有的位置，它是个过渡名称。历史给出的形状很清楚：监控、告警、runbook、linter、类型检查，每一个都曾经是某个具体的人的专业判断，后来变成流水线里默认的一步；原来那个岗位没有被消灭，只是从"拥有这项能力的人"转成了"拥有被这套东西覆盖的生产面的那一方"。做到那一步之后，岗位上的人不再重要，手里拿着流量接入权的一方变得重要。
顺手把类比收一下：把评估类比成监控是最顺手的路，但这两件事有一个不一样的地方，监控吃的是确定性的输入，评估吃的是概率性的输入，所以监控那套"阈值定好就能自动化"的经验没法整套搬过来，评估的自动化永远带着一个前提，就是你对失败的定义在那个时刻恰好是对的。这个类比到这里不宜再走远。
有一处我想再往下压一层。Nitish Kumar 在评论里把失败分类法的价值讲得最清楚：一旦能精确命名一个失败模式，通常就能把它转成评估器、确定性的守卫或者自动回归测试；所以真正难的是识别当前评估系统还看不见的那些失败，作者也认这一条。我同意，但这条有个副作用很少有人接着说：分类法一旦写出来就是文档，文档会进入下一代模型的上下文，等于你把一个曾经很难的判断，免费交给一个每季度变强一次的对手。你越勤快地把未知问题变成已知问题，你现在的位置消失得越快。这不是阴谋，把判断产品化的必然代价就是这个。
正文之外还有个小东西值得看一眼。那篇讲判断比实现更值钱的文章，末尾署着一句，概念来自人类，文字由 AI 撰写。这个分工本身就是它整篇论证的一个样本：判断留给人，实现外包出去，看上去各得其所。可它同时说明另一件事，把判断和实现分开的那个动作本身是可以被协议化的，一旦协议化，就不需要每篇文章末尾都提醒一次。这句话我写在这里，三年后大概也没人需要再说。
往后看，三条路径我都能想得出机制来。
一条是评估能力被模型厂商吸收。理由很直接，训练需要的失败样本，最大来源就是生成侧本身，谁生成的量最大，谁积累已知失败的目录最快；这条路走通，独立评估工具就退化成模型 API 的一个参数，跟今天按 token 计数差不多。
一条是被场景方内部的平台团队吸收，评估工程师变成那个团队里的一个职能。这条对大部分手里有真实流量的公司来说最自然，因为失败分布本来就是他们最不肯往外拿的东西。
第三条是评估留在独立厂商手里，前提是跨客户的失败分布能够合成、而且客户愿意共享 trace。这条我压得最轻。失败分布是一家公司最接近"它到底怎么赚钱、会在哪里翻车"的那部分信息，比代码难外流得多。可观测性那一批公司做到今天，也没能真正把这一层标准化掉，多数情况下拿到的是接入权，不是分布本身。
所以我压前两条的合流：评估这件事会落到拥有生产分布的那一层，可能是模型厂商，也可能是场景方自己的平台团队，但不会独立成一层；对个人来说，证据工程师在未来两三年是值得做的事，但不是值得押注的位置。值得押注的是把自己绑在真实流量上，去一个有生产面、有真实失败的地方，而不是去一个专门做评估工具的团队。工具能力会跟着模型能力一起贬值，流量接入权不会。这一注我压得比上次重，上次那个判断方向对了，但我下得太轻，事后看应该更笃定。
这条什么时候该扔掉？如果出现一个客户主动往里交下游 trace 的共享失败库，那独立评估层就有了立足点，上面这一整套推论都得推翻；高合规行业是我认为最可能先长出这种东西的地方，也是最不容易长出来的地方，这两件事同时成立。