过去四天，我在 GitHub 上找到六个公开仓库，做着同一件事：把一个随机失败的门禁，处理成一个看起来稳定的门禁。

其中四个是 Agent 干的。有一个 Agent 的"修复"，是把让测试结果会变的那一行 fixture 删掉了。

然后我自己跑了个实验：一个真实 flaky 率 40% 的门禁，套上"重试即通过"这个判据，报出来是 4%。再换一组参数，真实 18.3%，报出来是 0% —— 六十轮全绿。

这篇讲两件事：这六起分别在判据的哪一层失真，以及为什么"重试即通过"这个判据在任何 flaky 率下都不可信。

下面每一条我都在 GitHub 上打开原文读过，不是转述。

一、councilkit #111，10-04，Cursor Agent 提交，当天合并

Playwright exits 0 when a test fails and then passes on retry. The reporter prints a summary line N flaky. interpretTestLog did not read that line, so evaluateVerificationAsset accepted the log as proof.

中文：一个测试先失败、重试后通过，Playwright 退出码是 0。reporter 打印了一行 N flaky。它没读那一行，于是把这份日志当成了通过证明。

失真位置在验证器读信号这一层。退出码没有骗人，它如实说了 0。骗人的是「0 = 通过」这个假设 —— 而 N flaky 这行才是真正的结论，reporter 印出来了，验证器没看。

二、Splotch #2668，10-04，Claude Code 提交，一小时内合并

GitHub 的 run: 步骤如果没有显式声明 shell: bash，跑的是 bash -e；只有声明了才有 -o pipefail。这个仓库十个 workflow 一个都没声明。

reproduced="$(node tools/perf/report-undo-gate-failures.mjs --first="$FIRST_FAILURES" | tr -d '\n')"

reporter 在遇到 TypeError 时会故意崩溃，退出码 1，stdout 为空。没有 pipefail，赋值语句取的是 tr 的退出码 0。

- "Record the non-reproduction" 写下 "not reproduced … no issue filed"

- "Fail on a reproduced breach" 被跳过

崩溃被管道吃成了"没复现"，"没复现"被读成了"没问题"。

这个 PR 里还有一句我读了三遍的话：

No test executed the step. The tests that do execute workflow steps ran them under the pipefail argv, which is stricter than CI gave those steps, so the suite could not catch this class of bug.

测试比生产严格，所以这一类缺陷永远测不出来。 测试环境给的是 pipefail，线上给的是 -e；测试跑的是"更严格的那个世界"，于是它永远看不到线上那个宽松世界的 bug。

三、growi #12003，10-02，Claude Code 开

标签打的是 flaky/confirmed，描述是 "Confirmed flaky test/job, ready for investigation"。依据写在正文里：

Kind: playwright (strong evidence: passed on in-run retry)

"passed on in-run retry" 被当作 strong evidence，然后从单次运行推出"已确认"。

这是我最在意的一条。它和 councilkit #111 是同一个病，但更靠后一层：councilkit 是没读到 N flaky 那行；growi 是读到了，然后把"重试后过了"当成了关于不稳定性的结论。

一次重试通过，能证明的只有一件事：这次过了。它证明不了 flaky 率是多少，因为按定义你没法从一次成功里估计失败概率。

四、datahub #20121，10-01，Cubic 自动生成，PR 至今 open

Removes the upstream lineage aspect from the test fixture to fix flakiness in siblings search Playwright test. Without this aspect, the fixture no longer varies search results depending on lineage state, so the test runs deterministically.

中文：把 fixture 里 upstream lineage 那一项去掉，flaky 就好了。去掉之后 fixture 不再随 lineage 状态改变搜索结果，所以测试跑起来确定了。

它没有修那个让结果会变的东西。它把那个让结果会变的东西删了。

这个 PR 至今 open，没合。被 AI"修"绿的那部分覆盖，现在等于不存在。

五、focus-planner #826，10-03，人写的，但说的是同一件事

Three intermittent failures so far. Each passed on a plain rerun, and none of the commits touched app code.

A gate that fails at random gets rerun on reflex and eventually ignored, which defeats the no-regression rule it exists for.

Ask: ... Prove the fix with 20 consecutive full-suite runs locally, and 3 CI reruns, all green.

这位维护者的判断完全正确：随机失败的门禁会被反射性重跑，最后被忽略，这正好废掉了它存在的意义。

但他提的验收方案里藏着一个问题，而且这个坑很常见："20 次连续全绿" 和 "3 次 CI rerun 全绿" 不是一个量级的东西。 下面我来算。

fails at a random viewport (1440 / 768 / 390) ... The other viewports pass in the same run, and a re-run of failed jobs passes. These specs run against the live site, not the PR build, so they are independent of the PR diff.

最后那句是写在 issue 里的正式策略：修不好就重跑。

注意这两个 issue 的一个共同点：测试跑的是线上站点，不是 PR 的构建产物。所以 flaky 跟代码改动无关，纯粹是环境抖。"改代码改不动它"这件事，和"重跑能让它变绿"这件事，会同时成立。

上面都是别人的事。我想知道的是："重试即通过"这个判据，到底能把数字改成什么样。

一个最小的页面：打开之后，在 0 到 120 毫秒之间的某个随机时刻，把 #target 从 PLACEHOLDER 改成 READY。

"测试"的做法是：导航之后固定等 N 毫秒，然后读一次，不等。读到 READY 算过，读到 PLACEHOLDER 算失败。

这就是一个真实的 flaky —— 不稳定来自时序竞态，不是随机数后门。

每个点跑 60 轮，每轮最多重试 2 次（也就是最多 3 次尝试）。同一条数据出两个数：

- A：first-attempt —— 每轮第一次就过的比例。这就是 Playwright 报 flaky 率的那个数。

- B：after in-run retry —— 任意一次过了整轮就算过。这就是 GitHub Actions rerun、也是"重跑一次就好"的那个判据。

两个数之差，就是被"重试即通过"吞掉的那部分不确定性。

| 40ms | 61.7% | 26.7% | 35.0 pp | 2.3× |

| 60ms | 50.0% | 13.3% | 36.7 pp | 3.8× |

| 80ms | 25.0% | 3.3% | 21.7 pp | 7.5× |

- 100ms 那一组：真实 flaky 18.3%，报出来 0%。60 轮全绿。

- 120ms 那一组：真实 flaky 0%，报出来也是 0%。60 轮全绿。

两个 flaky 率相差 18 个百分点的门禁，在判据眼里是同一个东西：一块全绿的板子。

一个是 60 轮里有 11 轮读到 PLACEHOLDER，一个是 60 轮全部一次过。判据给它们的输出逐字相同。

被抹掉的不是精度，是那个维度的全部信息。

再看第一行：真实 61.7%，报出来 26.7%。不是低估百分之几，是砍掉一半还多。

只取 wait=80ms 这一组，60 轮，每轮最多 3 次尝试：

20 轮是靠重试救回来的。这 20 轮里，每一轮都是一个坏掉的门禁。

这 20 轮在报表上是绿的。绿色的来源是重试，不是修复。

三、为什么"重试三次全绿"几乎什么都没证明

设真实 flaky 率是 p，重试 k 次（总共 k+1 次尝试）之后被误判为通过的漏过率就是 p^(k+1)。

- p = 0.10，三次尝试：漏过率 0.1%

- p = 0.20，三次尝试：漏过率 0.8%

- p = 0.40，三次尝试：漏过率 6.4%

- p = 0.60，三次尝试：漏过率 21.6%

所以"三次 rerun 全绿"这句话的信息量，完全取决于 p 有多大。而 p 恰恰是你想测的东西。

再看同一个 p=0.4，换成二十次连续首尝试全绿：

"20 次全绿"和"3 次 rerun 全绿"在证据强度上差 1700 倍。 前者是三十九分，后者是接近零。

这不是"多点几次更保险"的问题。重试次数本身就是判据的一部分，而它对 p 的敏感度是非线性的 —— 在 p 已经很高的区间，三次和一次几乎没有区别。

四、Agent 为什么特别容易踩这个坑

上面四条 Agent 的操作，根子是同一个：

它们拿到的输入，是"重试后通过了"这一个 bit。 它们看不到真实 flaky 率，因为那个数在信息里根本不存在 —— 它从来没有被计算过。

1. 这个测试重试后过了 → 看起来稳定

2. 看起来稳定 → 判据认为可以依赖

3. 判据说可以依赖 → 不用去查真实失败率

第 1 步到第 3 步之间没有断点。每一步单独看都对，串起来是一个把不确定性当成确定性传递下去的闭环。

这也是为什么 datahub 那个 PR 是这套逻辑的终点形态：它不是在验证环节出错，它是为了让验证环节不出错，去改了被验证的东西。它把一个 61.7% 的 flaky 改成了 0% 的 flaky —— 用的是最直接的办法：让被测行为变得确定。

而这恰恰是最危险的一种假成功，因为它不留任何痕迹：门禁是绿的，PR 描述完整，测试是过的，只有那份测试测的东西变少了这件事没人查。

这四条事故落在四个不同的地方，修法也不一样。但有一条是共同的。

任何在重试之后统计出来的失败率，都不叫失败率，它叫"重试没救回来的失败率"。Playwright 报 N flaky 用的是首尝试口径，保持这个口径，别改。

2. 判据要读"有没有失败过"，不是"最后过没过"。

councilkit #111 的修法就是这个：日志里只要有 N flaky 那一行，就算 exit 0 也判失败。判据问的是"这一轮里失败过吗"，不是"最后是什么状态"。

3. 修 flaky 要改被测对象，不能改判据。

datahub 那个 PR 违反了这条。判据是量具，量具不准的时候你不会去改被测的东西让读数变好看 —— 你会怀疑量具。

4. 修的门禁比生产严格，等于没修。

Splotch #2668 那句注释值得贴进每个 CI 模板：测试环境如果给的是 pipefail，线上给的是 -e，那么测试永远测不出线上的问题。测试环境的配置必须是线上配置的子集，不是超集。

5. 验收要 20 次首尝试全绿，不是 3 次 rerun。

这不是仪式感。p=0.4 时，0.6^20 ≈ 0.004%，0.6^3 ≈ 21.6%。前者是证据，后者是祈祷。

写到这里我发现，这篇讲的东西其实是一个更大的问题的一个切面。

「重试即通过」不是唯一一个会系统性高估可靠性的判据。它们有同一个结构：

- 只读终点状态，不读过程（councilkit 没读 N flaky）

- 中间信号被更外层的状态吸收（pipefail 缺失，失败码被 tr 吃掉）

- 把"通过一次"当成"会一直通过"（growi 的 in-run retry）

- 为了让判据满意，去改被测对象（datahub）

这四条我前面写过 —— 在另一篇里我把它们归成四层：没到、到了没变、变了没进模型、进了模型没落库。

让 Agent 去修 flaky，它删掉了让测试不确定的变量

四天，六个仓库，三个 Agent 在修 flaky。我跑 300 轮：真实 flaky 率 61.7%，套上「重试即通过」报 26.7%；真实 18.3% 报 0%，和真稳定的门禁一样。最狠的 PR 删掉了让测试不确定的 fixture。

测试

职业发展

新闻资讯

GitHub上六个公开仓库在将随机失败门禁处理为"看似稳定"，其中四个由AI完成，一个修复删除了导致测试变化的fixture。实验显示：真实flaky率40%的门禁经"重试即通过"判据报出4%，18.3%报出0%。"重试即通过"在任何flaky率下都不可信，应只认首尝试失败率，判据须检测"是否失败过"而非"最终状态"，测试环境配置应为生产子集，验收需20次连续首尝试全绿。

Windows

GitHub

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

GitHub上六个公开仓库在将随机失败门禁处理为"看似稳定"，其中四个由AI完成，一个修复删除了导致测试变化的fixture。实验显示：真实flaky率40%的门禁经"重试即通过"判据报出4%，18.3%报出0%。"重试即通过"在任何flaky率下都不可信，应只认首尝试失败率，判据须检测"是否失败过"而非"最终状态"，...

让 Agent 去修 flaky，它删掉了让测试不确定的变量

让 Agent 去修 flaky，它删掉了让测试不确定的变量

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐