第 1 周 · D5约 4 小时

自验证：端到端闸门、谎报完成与打转的自动干预

无人值守最贵的两种失败是谎报完成和原地打转。今天给 harness 装上端到端闸门与停滞检测，并且把重点放在发现之后怎么办：换任务、回滚、停机报警三者各有判据。

今日目标 0/3

能解释为什么模型自己说完成了不能作为翻状态的依据，并说出端到端验证该验什么、不该验什么
能说出本课端到端验证走 HTTP 层而不是浏览器的取舍，并指出它测不到哪一类缺陷
能描述停滞检测的三种干预方式与各自的判据，并说清为什么只发现不干预在无人值守场景等于没做

登录后可以勾选并保存进度。

今日目标

能解释为什么模型自己说完成了不能作为翻状态的依据，并说出端到端验证该验什么、不该验什么
能说出本课端到端验证走 HTTP 层而不是浏览器的取舍，并指出它测不到哪一类缺陷
能描述停滞检测的三种干预方式与各自的判据，并说清为什么只发现不干预在无人值守场景等于没做

D1 到 D4 留了一个明摆着的破洞：验证只是浅检查，补丁写进去就算过。今天补上它，然后处理补上之后必然出现的新问题。读完回到页面顶部把三条目标勾掉。

小白版讲解

监理不看施工队的自我评价

装修到一半，你问工长「水电做完了吗」。他说做完了。

你信吗？

你不是怀疑他的人品。你只是知道一件事：他说的是「我做完了我以为要做的事」，而你要的是「这套水电真的能用」。 这两句话之间隔着一个监理——一个不问工长、只去开闸放水的人。

Agent 也一样。它回报「已实现 F07」的时候，它说的是「我按我的理解写了一段代码」。它没有跑过那个服务，它凭什么知道自己写的东西 work？

所以今天这一天的前提是一句很朴素的话：模型自己说完成了，不能作为翻状态的依据。 依据只能是一次独立的、去环境里取证的验证。

浅检查只能证明「写了」，证明不了「对」

D1 到 D4 的 verifyShallow 做的是：补丁写进 server.mjs 了吗？写进去了就算过。

这个破洞对应 Anthropic 那篇点名的一种失败模式——feature 被标记完成但根本没真测。它拦不住的东西，今天的剧本里准备了三种样本：

缺陷	长什么样	浅检查为什么看不出来
字段名写错的筛选器	代码写得很像对的	补丁确实写进去了
返回 200 却没做事的路由	返回值长得对，副作用没发生	补丁确实写进去了
对所有取值都放行的「校验器」	代码里明明有一个校验函数	补丁确实写进去了

三种的共同点是：看代码很难发现，跑一下立刻现形。 而这正是「验终态不验过程」这条判据的含义——不要去查它说了什么、写了多少行，去查它产生了什么：起服务，发请求，看响应。

数字更好看的那一趟，现实更差

实验跑两遍，同一份代码、同一个模型、同一份剧本，唯一的差是拿什么当验证。

TextText

                    浅检查      端到端闸门
清单声称完成          33 条        20 条
实测真的能用          24 条        20 条
清单里的谎报条数        9 条         0 条

请盯住第一行：浅检查那趟的清单数字更大。 早上你打开进度，先看到的是一个更好看的数字，然后才发现服务的行为是错的——而清单上没有任何一条写着「可疑」。

这是无人值守场景最危险的一类结果：它不报错，而且往你希望的方向偏。 一个会崩的 bug 是运气，一个让你更自信的 bug 才是灾难。

一条坏补丁能连累八条做对的

那九条谎报里，只有两条是剧本里真正的不完整补丁。另外七条本来都是做对的。

罪魁是 F07。它的形态很反直觉：标签筛选忘了「没传 tag 就原样放行」那个守卫，于是传了 tag 时它筛得好好的，没传 tag 时它把整张列表过滤成空——而绝大多数请求都不传 tag。

结果是：

它自己的验收用例是过的（F07 的用例就是带着 tag 查的）， 被它弄坏的是别人——列表、搜索、分页、排序、计数、排除归档，实测八条。

两种失败，形态完全不同

装上闸门之后，「没通过」会分成两种，而它们需要的处理完全不一样。

谎报完成：补丁写进去了、服务起得来、端到端是红的。它把工作区弄脏了——那段错代码留在文件里，不清掉会一直影响后面。

打转：模型交出一段空代码，或者反复交出同样改不动的东西。服务没有任何变化，清单也不动。它不弄脏工作区，但会让运行原地消耗预算。

一个脏、一个不脏。这个区别决定了干预方式，下一节讲。

发现之后怎么办：三种干预与它们的判据

如果你学过手搓 Coding Agent 那门课，会记得那里有一个「停滞信号：清单十轮不动」。那门课只做发现——因为人就坐在旁边，发现了你会接手。

本课人不在场。发现而不干预等于白发现：报警报给谁看？所以今天真正难的不是检测，是检测之后那个自动决定。

情况	干预	为什么
还没到重试上限	再试一次（脏了先退干净）	偶发失败值得再来一次
到了上限，工作区是干净的	换一条	退了会把好的工作一起丢掉，而这条的难度不会因为回退变低
到了上限，工作区被弄脏了	先退到上一个绿点，再换一条	先修地基，再绕开这条
被换掉的条数超过阈值	停机报警	一直在换说明前提出了问题，继续跑只是烧钱

这张表里有两个判断值得单独拎出来。

第一，判据是「工作区脏不脏」，不是「失败了几次」。 空补丁失败三次，工作区仍然是干净的，那就不该回退——退了会把旁边已经验证过的工作一起丢掉。回退不是对失败的惩罚，是对地基的修复。地基没坏就不该退。

第二，重试必须有上限，而且不该大。 同一条输入喂给同一个模型，凭什么第二次会不一样？重试有意义的前提是这次的输入和上次不同（上下文里多了一条失败原因）。无限重试就是 D1 那个「一夜八小时烧在同一条上」的场景，只是这次是 harness 自己造成的。

这个取舍测不到什么

本课的端到端验证走 HTTP 层（fetch），不开浏览器。这是本仓库的硬约束：lab 必须离线可跑、不依赖读者装 docker 或浏览器驱动。

代价必须说在明处：测不到渲染类缺陷。 页面白屏、样式塌了、按钮点不动——这些在 HTTP 层全部看不见，接口照样返回 200，用例照样全绿。Anthropic 原文用的是浏览器自动化（Puppeteer），正是为了盖住这一层。

但请注意这个取舍影响的是用例的执行方式，不是闸门的结构。如果你的靶子有界面，把第三道门换成浏览器驱动就行，这一天讲的其余部分一个字都不用改：起环境、跑用例、只有过了才允许翻状态。

源码导读

今天新增两个模块，三个位置值得细读。

第一个位置：三道门，顺序不能换。

verify-e2e.js

async function verifyE2E(repoDir, doneIds, featureId) {
  // 第一道门：语法。它最便宜，坏了就没必要再去起进程。
  // 而且「语法坏了」和「行为不对」在报告里是两件事，不能混成一个错误。
  try {
    execFileSync('node', ['--check', join(repoDir, 'server.mjs')])
  } catch (err) {
    return { featureId, passed: false, detail: `语法不通过：${String(err).slice(0, 160)}` }
  }
 
  // 跑的是「已通过的全部 + 这一条」，不是只跑当前这一条。
  // 这多出来的部分就是回归套件——新改动弄坏旧功能会当场被抓住。
  const wanted = new Set([...doneIds, featureId])
  const suite = PROBES.filter((p) => wanted.has(p.featureId))
 
  // 一条用例都没覆盖到这条 feature 时，不能算通过。
  // 没有证据不等于通过——这一天讲的就是这件事。
  if (suite.length === 0) {
    return { featureId, passed: false, detail: `没有任何验收用例覆盖 ${featureId}，这条不算通过` }
  }
  // 第二道门起服务、第三道门跑用例，见 lab
}

verify_e2e.py

async def verify_e2e(repo_dir, done_ids, feature_id):
    # 第一道门：语法。它最便宜，坏了就没必要再去起进程。
    # 而且「语法坏了」和「行为不对」在报告里是两件事，不能混成一个错误。
    ok, err = syntax_check(os.path.join(repo_dir, "server.mjs"))
    if not ok:
        return VerifyResult(feature_id, False, f"语法不通过：{err[:160]}")
 
    # 跑的是「已通过的全部 + 这一条」，不是只跑当前这一条。
    # 这多出来的部分就是回归套件——新改动弄坏旧功能会当场被抓住。
    wanted = set(done_ids) | {feature_id}
    suite = [p for p in PROBES if p.feature_id in wanted]
 
    # 一条用例都没覆盖到这条 feature 时，不能算通过。
    # 没有证据不等于通过——这一天讲的就是这件事。
    if not suite:
        return VerifyResult(feature_id, False, f"没有任何验收用例覆盖 {feature_id}，这条不算通过")
    # 第二道门起服务、第三道门跑用例，见 lab

那条「没有用例覆盖就不算通过」看起来很小，它其实是全课纪律的一个具体化：没有证据不等于通过。 一个漏掉了用例的 feature 被判通过，和一个谎报完成的 feature 被判通过，后果一模一样。

第二个位置：干预的判据。

stall.js

function decideIntervention(features, state, featureId, dirty, policy) {
  const attempts = state.attempts[featureId] ?? 0
 
  // 还没到上限：再试一次。dirty 由调用方拿去决定退不退。
  if (attempts < policy.attemptLimit) return { kind: 'retry', featureId, dirty }
 
  // 到上限了。先看换掉之后会不会超过停机阈值。
  const skipped = skippedIds(features, state, policy)
  if (skipped.length >= policy.skipLimit) {
    return { kind: 'halt', reason: `已经有 ${skipped.length} 条被换掉，说明前提出了问题`, skipped }
  }
  return { kind: 'skip', featureId, dirty, attempts }
}
 
// 调用方：脏了才退。判据是工作区脏不脏，不是失败了几次。
if (decision.kind !== 'halt' && decision.dirty) {
  rollbackTo(repoDir, lastGreen(repoDir)?.sha ?? headSha(repoDir))
}

stall.py

def decide_intervention(features, state, feature_id, dirty, policy):
    attempts = state.attempts.get(feature_id, 0)
 
    # 还没到上限：再试一次。dirty 由调用方拿去决定退不退。
    if attempts < policy.attempt_limit:
        return Retry(feature_id, dirty)
 
    # 到上限了。先看换掉之后会不会超过停机阈值。
    skipped = skipped_ids(features, state, policy)
    if len(skipped) >= policy.skip_limit:
        return Halt(f"已经有 {len(skipped)} 条被换掉，说明前提出了问题", skipped)
    return Skip(feature_id, dirty, attempts)
 
 
# 调用方：脏了才退。判据是工作区脏不脏，不是失败了几次。
if decision.kind != "halt" and decision.dirty:
    rollback_to(repo_dir, last_green(repo_dir) or head_sha(repo_dir))

注意「被换掉的条数」是从 state.attempts 推导出来的，没有另开一个字段。理由与 D4 那条「绿点查 git log 不另存一份」完全一样：能让现成的权威记录回答的问题，不要另建一套记录。 而且这样它天然跟着状态一起落盘，D6 的崩溃续跑不用再补一份。

第三个位置：每条验收用例必须自给自足。

闸门按已完成集合筛选后跑一个子集，顺序与子集都不固定：今天跑 F01 到 F07，明天从崩溃处续跑可能只跑 F03 加 F12。所以任何「上一条用例给我留了数据」的假设，都会在某个子集里变成偶发的假红。

动手实验

🧪 D5 实验：自验证——端到端闸门、谎报完成与打转的自动干预

代码位置：labs/agent-harness-7days/day-05-self-verify

四十条验收用例已经给全了（src/verify/probes.ts，它自己还带一个体检脚本）。练习有三处：端到端闸门的三道门、被换掉集合的推导、干预的决定。

先读 src/model/script-verify.ts 顶部那段，看清楚 F07 为什么自己的用例是过的、弄坏的却是别人。
补上 verifyE2E 的三道门，注意顺序、注意跑的是回归套件、注意没有用例覆盖时不能算通过。
补上 skippedIds 与 decideIntervention，判据是工作区脏不脏而不是失败了几次。
跑 MOCK=1 pnpm selftest 到七十一项全绿，再跑 probe-check 确认四十条用例本身没问题。
跑 MOCK=1 pnpm start，看两种验证方式的清单数字与实测数字各是多少。

今天的变异检验是把失败后那段回退注释掉，其它一个字不动。端到端那趟会变成这样。