跑 think-aloud 第 2 批 + 痛点聚合

阶段: B16 · 治理一页纸 + AI 原型 + 可用性（Day 151-160） 标签: #severity-rating #usability #pain-points #nng

今日导引（由浅入深）

Day 158 跑了首批 3 人、抖出高危点。今天补测 2 人凑齐 5 人，并把两批编码合并、按「频次 × 严重度」聚类成 top-3 痛点——这是从「散乱的成功率表」收敛到「可排优先级的待修清单」的一步。在 B1→B18 曲线上，这一步是把「散乱观察 → 排序决策」的收敛器，给即将到来的迭代（Day 160 只改 top-1）提供决策依据：改哪个、为什么先改它。它也是 B16 从「发现问题」转向「修复问题」的枢纽。今天的最小可判定产出：5 人聚合的 top-3 痛点清单，每条带 NN/g 0-4 严重度评级，写入 docs/AML_GOVERNANCE_MAP.md。仍是「待用户测试」状态——聚合方法与评级量表已就绪。

1. 机理精读

NN/g 严重度评级 0-4 是给可用性问题排优先级的标准量表。 它把「这个问题有多痛」量化成五档：

• 0 = 不算问题（在该界面语境下不构成可用性障碍）。
• 1 = 装饰性问题（不影响完成任务，时间充裕再修）。
• 2 = 小可用性问题（低优先级）。
• 3 = 大可用性问题（高优先级，应尽快修）。
• 4 = 灾难性问题（必修，否则产品不可发布）。

严重度不是单维度，它由三个因子合成判断：

• 频率（frequency）：多少用户撞上（常见还是罕见）。
• 影响（impact）：撞上后多难克服（能自己绕过，还是直接卡死）。
• 持续性（persistence）：一次性踩坑后能否记住绕开，还是每次都反复受困。

三因子里，影响 + 持续性往往比频率更决定严重度——一个「罕见但一旦触发就卡死且无法绕过」的问题（高影响 + 高持续性），严重度可达 4，即便频率只有 1/5。这就是下面要警告的反模式根源。

为什么要「频次 × 严重度」双轴聚类，而不是单按频次排序。 这是本日的核心反模式警告。频次高 ≠ 该先修。一个高频小毛刺（如某标签文案略绕，5 人都嘟囔但都能完成）严重度可能只有 2；而一个低频灾难性问题（如某条件下 SAR 出现可被误当作「自动报送」的入口，只有 1 人撞到但一旦触发是合规事故）严重度是 4。低频灾难性问题必须优先于高频小毛刺。 单按频次排序会把 4 级灾难压在 2 级毛刺之下，正好排反。

为什么 5 人累计能覆盖大多数高严重度问题。 接 Day 156 的 1−(1−L)^n 模型：高严重度问题通常 L 较高（人人都会撞），5 人累计发现率达 ~85%。低频但高严重度的问题虽然 5 人未必都撞到，但只要有 1 人撞到、严重度评级机制就会把它顶到清单顶部——这正是「频次低不等于优先级低」的制度化保障。

严重度评级要由多人独立打、再调和。 单人给严重度等于主观吐槽。规范做法是：让几名评估者各自对每个痛点独立打 0-4，再对比分歧、讨论调和（calibration）。分歧本身有信息——若一个痛点有人打 4、有人打 1，说明大家对「它有多痛」理解不一致，需要回看转录证据。这与 Day 155「评测独立性」、Day 158「编码避免单人自评」一脉相承：从模型评测到可用性评级，本项目一律拒绝单人闭环自评。

严重度 ≠ 修复成本。 NN/g 明确区分：严重度回答「该不该修」，修复成本回答「修起来多贵」。两者独立。理想迭代顺序是「高严重度 + 低成本」先修（性价比最高），但「高严重度 + 高成本」也不能因为贵就拖——尤其 4 级灾难（如 SAR 误自动报送入口）必须修，无论成本。Day 160 只改 top-1，选的就是 top-3 里严重度最高的那个，成本是次要约束。

聚合的操作内核。 把两批 5 人、跨两块原型（harness + AML）的全部编码事件合并，按「同一根因」聚类（不同被试在同一处的不同表述归为一类），统计每类的出现频次，再对每类独立打 0-4 严重度，最后取「严重度优先、频次次之」的排序输出 top-3。

一个为什么「频次优先」会酿成合规事故的具体场景。 设想痛点 D：某条件下「报送 FinCEN」按钮在 pending_review 态意外可点（实现 bug，违反 hitl.ts 的 file() 守卫）。5 人里只有 1 人在特定路径下撞到（频次 1/5）。若按频次排序，它排最末、几乎不会被修。但它的影响是「可能把未经人审的 SAR 误报给 FinCEN」——这是合规灾难，严重度 4。频次优先会把这个 4 级灾难压在一堆 2 级文案毛刺之下，正是 NN/g 严重度量表要防止的最坏后果。这也解释了为什么本项目把 canAutoFile() 做成 typed false：在代码层就堵死这类「低频高危」入口，而不是指望可用性测试去抓。

资源主线：NN/g "Severity Ratings for Usability Problems"（2024-09 复核版）。

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

今天是用户测试 + 聚合日（非代码日）。给一个「频次 × 严重度」排序的手算示例（数字为方法演示占位，非真实测量）：

设合并 5 人编码后聚出三类痛点候选：

• 候选 A：频次 5/5，严重度 2（高频小毛刺，如某标签略绕）
• 候选 B：频次 2/5，严重度 4（低频灾难，如证据链折叠导致调查员误读 AI 结论）
• 候选 C：频次 3/5，严重度 3（中频大问题，如 SAR 草稿改动是否入审计不明显）

错误排序（仅按频次）：A(5) > C(3) > B(2) —— 把 4 级灾难 B 排到末位，错。

正确排序（严重度优先）：B(sev4) > C(sev3) > A(sev2) —— top-1 = B，正是 Day 160 要优先改的那一个。

输出的 top-3 痛点表（待真跑回填，结构固定）：

注意 top-3（κ 卡混淆）频次最高（5/5）却排末位——因为它严重度只有 2（被试虽嘟囔但都能完成）。这张表用「严重度列」而非「频次列」做主排序键，是本日方法的核心体现。

排序键的形式化：以 (severity, frequency) 字典序降序排。即先比 severity，severity 相同再比 frequency。这保证任何 4 级问题都排在所有 3 级之前，4 级内部再按频次细分。用 SQL 直觉就是 ORDER BY severity DESC, frequency DESC——把严重度放在 ORDER BY 第一位，正是「频次低不等于优先级低」的代码级表达。

这套排序逻辑与 B17 的 A/B 统计纪律同源：小样本只示方向、不证显著。本批 top-3 是「该先修哪个」的优先级判断，不是「这些痛点在总体中占比多少」的统计推断。

聚类的操作细节（手工，无需代码）：

1. 把 5 人、两块原型的全部「关键事件」（Day 158 记录）摊平成一张事件列表。
2. 按「同一根因」归并——不同被试在同一处的不同表述（「找不到证据」「不知道凭哪笔交易」）归为一类。
3. 数每类的命中被试数（频次，注意去重：同一被试在一类里多次受困只计 1）。
4. 每类由多名评估者独立打 0-4 严重度，调和分歧。
5. 按「严重度降序、频次降序」取前三。

可用性严重度评级若由多人独立打分，仍可用 src/agent/eval/cohensKappa.ts 的 cohensKappa(a, b)（或对有序评级用加权 κ 的近似）核对评估者间一致性（n 小仅作演示，CI 会很宽）。

3. 今日实战

1. 再招 2 名真实被试（累计 5），对两块原型重复 Day 158 的 think-aloud 流程，编码标准对齐首批避免漂移。
2. 合并两批共 5 人的全部编码事件，按「同一根因」聚类去重。
3. 对每个聚类由多名评估者独立打 NN/g 0-4 严重度（综合频率/影响/持续性三因子），对比分歧后调和成共识分。
4. 按「严重度优先、频次次之」排序，输出 top-3 痛点，每条标频次 + 0-4 严重度分。
5. top-3 清单写入 docs/AML_GOVERNANCE_MAP.md 可用性章节，标出 top-1（供 Day 160 改），并附每条的关联高危点与代表性被试原话引用。
6. 对 top-1 预写「假设性修复方向 + 改后预期指标」，让 Day 160 的受控迭代有明确的待验证假设（而非临场拍脑袋改）。

4. 今日实测 / 产出

• 痛点清单（5 人聚合，top-3 带严重度分）— 待用户测试（user-gated / 外部动作）。
• 产出 top-3 痛点 + 各自 0-4 严重度评级。
• 聚合方法与评级量表已就绪——不臆造任何痛点或严重度数字。

5. 常见误区 / 陷阱

• 仅按频次排序、忽略严重度。 低频灾难性问题（如 SAR 误自动报送入口）必须优先于高频小毛刺；单按频次会把 4 级灾难排反到末位。
• 两批编码标准漂移。 第二批换了打标签的尺度，会让合并后的频次失真；须与首批严格对齐。
• 把不同根因的表述混算成一类。 聚类要按根因合并，而不是按字面相似——否则频次虚高、严重度评错。
• 把 top-3 当总体占比的统计结论。 5 人聚合只给优先级，不给比例推断。
• 单人给严重度。 严重度该多人独立打分再调和；单人闭环违反本项目一贯的评测独立性原则。
• 把严重度和修复成本混为一谈。 严重度回答「该不该修」，成本回答「多贵」；4 级灾难再贵也得修。
• 同一被试在一类痛点里多次受困却计多次频次。 频次按被试去重，否则虚高。

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

• NN/g, "Severity Ratings for Usability Problems"（2024-09 复核版）— 0-4 量表与三因子主线。
• NN/g, "How to Prioritize Usability Problems"（2024 复核版）— 频次 × 严重度排序。
• NN/g, "Calibrating Severity Ratings Across Evaluators"（2024 复核版）— 多人评级调和。
• 本仓代码：src/agent/eval/cohensKappa.ts（2026 当前实现）— 编码一致性核对（演示用）。
• NN/g, "Severity Ratings vs. Fix Cost"（2024 复核版）— 严重度与修复成本分离。
• 本仓文档：docs/AML_GOVERNANCE_MAP.md（2026 当前版本）— 痛点清单落地处。

SOTA检查 (2026-06 更新)

• 当前主流：NN/g 0-4 严重度量表为长期稳定标准（2024-09 复核仍适用），current；频次 × 严重度双轴排序、多评估者调和是行业通行做法。
• 是否仍 SOTA：是。该量表多年稳定，未被新方法取代；AI 不改变「真人受困事件 → 人工评级」的判断内核。LLM 至多辅助转录摘要，最终严重度评级仍须人工调和。
• 过时黑名单：
  • AVOID 仅按频次排序忽略严重度——低频灾难（SAR 误自动报送）必须优先于高频小毛刺。
  • AVOID 两批编码/评级标准漂移——第二批换尺度会让合并数据失真。
  • AVOID 把 5 人聚合当统计显著占比——只给优先级，不给比例推断。
  • AVOID 单人给严重度——多人独立打分再调和。
• 下次复查点：Day 160 改 top-1 复测时，复查严重度评级是否在改后下降（验证迭代有效）；2026-08-02 EU AI Act Art.50 生效后，复查披露类痛点的严重度是否需上调。

衔接

• 昨天：Day 158 — 跑 think-aloud 第 1 批，3 人三标签编码出 n=3 逐任务成功率。
• 今天：补到 5 人，按频次 × 严重度聚出 top-3 痛点并打 0-4 评级，锁定 top-1。
• 明天：Day 160 — 一次量化迭代 + 复测，只改 top-1 隔离效果、复测算改前后成功率 Δ。