一次量化迭代 + 复测

阶段: B16 · 治理一页纸 + AI 原型 + 可用性（Day 151-160） 标签: #usability-metrics #controlled-iteration #ab-discipline #nng

今日导引（由浅入深）

Day 159 聚出 top-3 痛点并锁定 top-1。今天闭环 B16：只改 top-1、复测同一批任务、对比改前→改后的成功率 Δ——把可用性从「主观吐槽」升级成「可验证的 outcome 数字」。在 B1→B18 曲线上，这是 B16 的收口，也是通向 B17（outcome 指标仪表盘 + A/B）的桥：同样的「改前/改后受控对比 + 小样本只示方向」纪律，B17 会放大到模型层面的 V4-Pro vs V4-Flash A/B。今天的最小可判定产出：改前后任务成功率 Δ（例：60%→85%, n=5）+ 迭代记录写入 docs/AML_GOVERNANCE_MAP.md。仍是「待用户测试」状态——对比指标与迭代闭环已就绪。

1. 机理精读

量化可用性迭代的核心是「预先定义改前/改后对比指标」。 不能改完凭感觉说「好像顺了」。最常用的两个客观指标：

• 任务成功率：成功完成任务的被试比例（接 Day 158 的三标签编码）。
• 平均完成步数 / 时间：完成任务需要多少操作或多长时间。

两者一个测「能不能做成」、一个测「做成有多费劲」，互补。改动若让成功率升 + 步数降，才是真改进。只看一个指标会误判：成功率升了但步数也涨了，可能是「能做成但更绕了」——这不算干净的改进，要追问为什么。

为什么要「预先」定义指标，而不是改完再挑。 若改完才选「哪个指标变好了就报哪个」，就掉进了 HARKing（事后假设、p-hacking 的近亲）：总能找到一个看起来变好的指标。预先锁定「任务成功率」为主指标、「完成步数」为辅指标，是把迭代从「自我安慰」变成「可证伪假设」的关键——改之前就说清「我预期 top-1 任务成功率从 X 升到 Y」，改完用同一指标验。

为什么「只改 top-1」——隔离变量。 这是受控实验的根本纪律。如果一次同时改 top-1、top-2、top-3 三个痛点，复测成功率即使上升，你也无法归因到底是哪个改动起的作用（confounding）。只改一个变量，Δ 才能干净地归因到这个改动。这正是科学迭代与「一把梭重构」的分界。

为什么复测「同一批任务」。 对比要在相同任务、相同成功判据下做，否则改的是衡量尺而非界面。改前用任务集 T 测出基线，改后必须用同一个 T 复测——变的只能是界面，不能是题目。

新被试 vs 原被试的取舍。 复测该招新被试还是用原班人马？用原被试有学习效应（learning effect）——他们第二次更熟练，成功率天然偏高，会把界面改进和「练熟了」混在一起。所以受控复测应招新的对等被试，让「改前 5 人」与「改后 5 人」是可比的独立组，唯一系统差异是界面。这与 A/B 测试用不同用户分流同理。代价是又要招人，但这是隔离效应的必要成本。

小样本只示方向、不证显著（本日内核纪律）。 n=5 的 Δ（如 60%→85%）说明的是「这个方向对了」，不是「统计上显著」。这与 B17 的 A/B 完全同理：那里 V4-Pro vs V4-Flash 的 Δ+10.3pp，95% CI[0,20.7]，N=29 仍 not-sig——连 N=29 的模型对比都跨 0、不显著，n=5 的可用性 Δ 更不能宣称显著。它的价值是为「该不该保留这个改动」提供方向证据，配合定性观察（被试不再在该处卡壳）共同决策。

为什么是「改一个、复测」而不是「攒一堆改动一起上」。 工程直觉常想「既然都要重测，不如把 top-1/2/3 一起改了省事」。但可用性迭代的目的不只是「让产品变好」，更是「学到哪个设计假设成立」。一起改无法学习——你不知道是哪个改动起的作用，下次遇到类似问题没有可复用的知识。单变量迭代慢，但每轮都沉淀一条「X 改成 Y 让成功率升了 Δ」的可迁移经验。这是「迭代即学习」与「迭代即堆功能」的分野。

与 outcome 思维的衔接。 把可用性 Δ 当作一个 outcome 指标，正是 B17 仪表盘要系统化的事——FPR、SAR 质量、cost-per-case、p95 也都遵循「定义指标 → 受控对比 → 看 Δ」的同一套方法论。今天是这套方法论在可用性维度的一次小试，明天（Day 161）会把它升格成系统化的 M7 outcome 指标定义。

资源主线：NN/g 可用性度量方法（2024-09）。

2. 推导 / 手算 / 代码走读

今天主要是用户测试 + 迭代日；先给改前/改后 Δ 的手算骨架（数字为方法演示占位，真值待跑），再走读 B17 将复用的统计基座 stats.ts。

设 top-1 痛点为「SAR 证据链默认折叠，调查员看不到 AI 结论凭据」（呼应 Day 157 的「类型学比对凭据是否可见」高危点）。改动：把折叠改为默认展开。

待验证假设（Day 159 第 6 步已预写）：把证据链默认展开后，任务 2「说出 AI 判定的类型学及其证据」的成功率会上升，因为调查员不再需要先发现「展开」入口。主指标=该任务成功率；辅指标=完成该任务的点击步数。预期方向：成功率↑、步数↓。

复测同一任务集 T（n=5），任务「说出 AI 判定的类型学及其证据」的成功率：

• 改前：成功 a/5 → a/5
• 改后：成功 b/5 → b/5
• Δ = b/5 − a/5（例：3/5=60% → 4.25/5 不可能取小数，故 n=5 的 Δ 只能跳 20pp 一格——这本身就提醒样本太小、Δ 颗粒度粗，是「只示方向」的另一面）

为什么 n=5 的 Δ 颗粒度是 20 个百分点一格：成功率 = 整数/5，可能取值只有 {0,20,40,60,80,100}%。所以 60%→85% 这种带 5 的数字在 n=5 下不成立，真实只能是 60%→80%（多 1 人成功）。这恰恰量化地说明「小样本只示方向」——连分辨率都不够支撑显著性主张。Day 160 seed 给的「60%→85%」是示意级表述，真跑时按 n=5 的整数格记录。

改前/改后对比表（待真跑回填，结构固定）：

最后一行是隐藏的健康检查：因为只改了 top-1，其它任务的成功率应该基本不变。若它们也大幅波动，说明要么改动有副作用、要么样本噪声太大——两种都提示这轮 Δ 不可信。

把这套迭代记成一条「实验日志」而非「改了就忘」：记录 (1) 假设、(2) 改了什么、(3) 主/辅指标改前改后值、(4) 健康检查结论、(5) 是否保留该改动。这五项写进 docs/AML_GOVERNANCE_MAP.md，就把可用性迭代变成可审计、可复盘的工程记录——和 B15 的审计轨迹、B17 的 eval 报告同属一类「可外部验证的过程证据」，而非主观「我觉得好多了」。

与 B17 A/B 的纪律对照表（方法同源）：

src/agent/eval/stats.ts 关键符号走读（B17 复用的统计基座，也解释了今天「只示方向」的代价）：

• pairedBootstrap(a, b, {iters})：对配对差值 a[i]−b[i] 重采样 iters 次（默认 2000），输出 deltaMean + 百分位 95% CI。配对的意义（文件头注释）：在同一任务集上对比，消除任务难度方差，让 Δ 的 CI 更紧——这正是 V4-Pro/Flash A/B 在同一套任务上跑的原因。
• requiredNForDelta(delta, sdDiff)：正态近似算「要检出某 Δ 需多少配对样本」（α=.05 双侧、power=.8），公式 n = ((z_{α/2}+z_{β})·sd/|delta|)²。把 Δ+10.3pp 和实测配对 SD 代入，就能算出「要让 CI 不跨 0 大约需要多少 N」——这量化解释了 N=29 为何 not-sig，以及 n=5 的可用性 Δ 离显著有多远。
• summarizeLatency(samplesMs)：出 p50/p95/p99——注释「p95/p99 surface the tail that the mean hides」，正是 B17 仪表盘 p95 指标（Day 161）的来源函数。

今天的可用性迭代不调用这些代码（人工记录 n=5 成功率即可），但它与这套统计基座共享同一纪律：配对对比、报 CI / 算 required-N、小样本只示方向。

3. 今日实战

1. 取 Day 159 的 top-1 痛点，只改这一处（例：SAR 证据链折叠 → 默认展开），其余原型保持不变。
2. 复测 2 名被试（用同一批任务 T、同一成功判据），与 Day 158-159 的改前基线对比。
3. 算改前→改后任务成功率 Δ，按 n=5 的整数格如实记录（不强凑带小数的百分比）。
4. 把改前后对比 + 迭代记录（改了什么、为什么、Δ 多少）写入 docs/AML_GOVERNANCE_MAP.md，并明标「n=5 只示方向，未证显著」。
5. 跑一次「健康检查」：确认其它未改任务的成功率基本不变，排除副作用与样本噪声。
6. 留一句衔接 B17：这套「定义指标 → 受控对比 → 看 Δ」将放大到模型 outcome 指标（FPR/SAR 质量/cost/p95）。

4. 今日实测 / 产出

• 改前后对比图（成功率 Δ 数字）+ 迭代记录入 GOVERNANCE_MAP — 待用户测试（user-gated / 外部动作）。
• 产出 改前→改后任务成功率 Δ（例：60%→85%，n=5）——示意值，真跑时按 n=5 整数格记录。
• 对比指标（成功率 / 完成步数）已定义，迭代闭环就绪——不臆造真实 Δ 数字。

5. 常见误区 / 陷阱

• 同时改多个痛点导致无法归因 Δ。 一次只改一个变量，否则 confounding，Δ 归因不到任何单一改动。
• 用 n=5 的 Δ 宣称统计显著。 与 B17 A/B（V4-Pro vs Flash Δ+10.3pp，CI[0,20.7]，N=29 仍 not-sig）同理，小样本只示方向不证显著。
• 复测换了任务或成功判据。 变的必须只是界面，不能是题目；否则改的是衡量尺。
• 强凑带小数的成功率。 n=5 下成功率只能取 20pp 一格，硬写「85%」是伪精度——颗粒度本身就是样本太小的证据。
• 改完才挑「变好了的指标」来报（HARKing）。 主指标必须改前预先锁定，否则总能找到一个看起来变好的指标自我安慰。
• 一起改 top-1/2/3 图省事。 省了重测次数，却丢了「哪个改动起作用」的可迁移知识；迭代是为了学习，不只是堆功能。
• 只看成功率不看完成步数。 成功率升但步数也涨 = 能做成但更绕，不是干净改进。

6. 学习资源（每条带 YYYY-MM）

• NN/g, "Measuring Usability: From the Lab to the Field"（2024-09 复核版）— 任务成功率/完成步数度量主线。
• NN/g, "Usability Metrics"（2024 复核版）— 改前/改后受控对比方法。
• NN/g, "Iterative Design"（2024 复核版）— 单变量迭代即学习的方法论。
• 本仓代码：src/agent/eval/stats.ts（pairedBootstrap / requiredNForDelta / summarizeLatency）、src/agent/eval/abCompare.ts（2026 当前实现）— B17 将复用的 CI / A/B 统计基座。
• 本仓文档：docs/AML_GOVERNANCE_MAP.md（2026 当前版本）— 迭代记录落地处。

SOTA检查 (2026-06 更新)

• 当前主流：改前/改后受控对比 + 任务成功率为 NN/g（2024-09）量化迭代标准，current；单变量隔离是受控实验通行纪律。
• 是否仍 SOTA：是。该方法学多年稳定；与 B17 的统计 A/B 共享同一套「定义指标 → 受控对比 → 报 CI / 只示方向」内核。
• 过时黑名单：
  • AVOID 同时改多个痛点导致无法归因 Δ。
  • AVOID 用 n=5 的 Δ 宣称统计显著——与 V4-Pro/Flash Δ+10.3pp CI[0,20.7] N=29 仍 not-sig 同理。
  • AVOID 强凑带小数的伪精度成功率（n=5 只能取 20pp 一格）。
  • AVOID 改完才挑变好的指标报（HARKing）——主指标须改前锁定。
• 下次复查点：B17（Day 161+）把可用性 Δ 升级为系统化 outcome 仪表盘（FPR/SAR 质量/cost/p95）时，复查这里的配对对比 + 报 CI 纪律是否一致迁移；复查 stats.ts 的 requiredNForDelta 是否被用来规划达到显著所需的样本量。

衔接

• 昨天：Day 159 — 跑 think-aloud 第 2 批 + 痛点聚合，5 人聚出 top-3、锁定 top-1。
• 今天：只改 top-1、复测同一批任务、报改前后成功率 Δ（n=5 只示方向），收口 B16。
• 明天：Day 161 — M7 outcome 指标定义（B17 起点），把 SAR 数量重述为 FPR/质量/cost/p95 四个 outcome 指标。