跑 think-aloud 第 1 批

阶段: B16 · 治理一页纸 + AI 原型 + 可用性（Day 151-160） 标签: #think-aloud #usability-testing #coding-scheme #nng

今日导引（由浅入深）

Day 156 定方法、Day 157 定 IA 与任务脚本，今天进入执行：把原型摆到真人面前跑第一批 think-aloud。在 B1→B18 曲线上，这是第一次让外部真人接触本项目的作品并产生可编码的行为数据——从「我认为面板清晰」跨到「3 个真人的逐任务成功率」。首批只招 3 人，目的不是统计显著，而是抖出最严重的结构性坑。今天的最小可判定产出：3 份转录 + 一张 n=3 的逐任务成功率表（三标签编码：成功 / 求助 / 错误）+ 关键事件清单。这是「待用户测试」状态——方法与编码标签已锁定，一旦招到被试即可执行。明天 Day 159 会把这批结果与第二批合并，按严重度聚出 top-3 痛点。

1. 机理精读

出声协议（think-aloud protocol）的记录纪律：主持人最小干预。 唯一允许的介入是在被试沉默超过几秒时轻提「请继续说」，绝不能问引导性问题（「你是不是觉得这里难找？」会直接污染数据）。被试的自然挣扎才是信号，主持人一插嘴就把信号染成了主持人的预设。

三标签编码（成功 / 求助 / 错误）是把出声转录变成数字的桥。 转录是非结构化文本，无法直接比较。对每个任务、每个被试打一个标签：

• 成功（success）：被试独立完成任务，得到正确结果，无需提示。
• 求助（assist）：被试卡住、需要主持人提示或自己费力试错后才完成——能做但费劲。
• 错误（error）：被试以为完成了但结果是错的，或最终放弃——根本做不出。

据此算每任务成功率 = 成功人数 / 总人数。三态比二态（成功/失败）多出「求助」这一中间档，能区分「能做但费劲」和「根本做不出」——前者是体验问题（优化交互），后者是阻断问题（重做 IA），优先级不同。

编码判据要预先写死、不能临场拍脑袋。 每个任务在 Day 157 已附「成功判据」，编码时严格对照：达到判据=成功；靠提示/试错达到=求助；偏离判据或放弃=错误。预先写死判据是为了让两名编码者（理想情况）对同一份转录打出一致标签——否则编码本身就成了主观吐槽，违反 Day 155 确立的评测独立性。

为什么首批 3 人就够暴露最严重问题。 接 Day 156 的 1−(1−L)^n 模型：n=3 时对单个问题的发现率已达 ~67%。对「最严重」的那一类问题（几乎人人都会撞上，L 接近 1），3 人几乎必然全部撞到——成功率会直接掉到 0% 或 33%，一眼可见。首批的价值是定性定位高危点，不是定量下结论。

为什么先跑 3 人、再补 2 人（Day 159），而不是一次 5 人。 多轮的意义在于：第一批发现的致命坑若不改，第二批会重复撞同一个坑、浪费样本。但本批次为了凑齐 5 人聚合（Day 159 做 top-3），采取「3 + 2 累计」而非「改完再测」——这是在「快速聚合」与「迭代改进」之间的折中，留到 Day 160 才做改后复测。

主持人三件不能做、一件必须做。

• 不能做之一：问引导性问题（「这里是不是不好找？」）。
• 不能做之二：在被试卡住时直接给答案（要让他自己挣扎，记录他怎么绕）。
• 不能做之三：表露失望或惊讶的表情/语气（会让被试自我审查、不敢出声）。
• 必须做：沉默超过约 5-10 秒时，中性提示「请继续说出你在想什么」。

两块原型同 session 测的顺序效应。 本批让被试同时测 harness 面板与 AML 面板两块原型。要注意顺序效应（order effect）：先测的那块被试更生疏、后测的更熟练。缓解办法是在 3 人间轮换先后顺序（如 1 号先 harness、2 号先 AML），避免某一块系统性地「被生疏惩罚」。n=3 难完全平衡，但至少不让顺序固定偏向一边。

资源主线：NN/g "Thinking Aloud"（2024-09 复核版）。

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

今天主要是用户测试日，核心是编码方案与成功率算法；末尾附一段编码一致性的真实代码走读。给一个 n=3、对 Day 157 五任务的成功率手算骨架（数字为待回填占位，方法固定）：

逐任务成功率 = (标为「成功」的被试数) / 3。n=3 下每任务成功率只能取 {0, 33%, 67%, 100%} 四档，颗粒度很粗——这本身提醒首批是定性工具：

（表中 x..v 为待回填的真实被试计数，方法固定、数字待跑。）

解读规则：哪一行成功率掉到 0/3 或 1/3，就是结构性高危点——比如若任务 2「类型学凭据」全员失败，说明证据链在 IA 上根本没暴露出来（呼应 Day 157 的「凭据可见性」高危点），这正是 Day 159 会聚成 top 痛点、Day 160 优先改的候选。

另一个解读维度是「求助 vs 错误」的比例：同样未独立成功，全是「求助」（最终靠提示做出来）说明问题在交互层（可优化）；出现「错误」（做错还自以为对）说明问题在理解层，更危险——尤其在 AML 场景，「自以为报送成功实则没报」或「误读 AI 结论」是合规风险，错误标签的权重应高于求助。

编码一致性的小注：理想做法是两名编码者独立打标签，再用 Cohen's κ（本仓 src/agent/eval/cohensKappa.ts 的 cohensKappa(a, b)）核对一致性——这呼应 Day 155 的评测独立性原则：连可用性编码都该避免单人自评。

cohensKappa.ts 关键行为走读（这里只作编码一致性演示，非模型评测）：

• cohensKappa(a, b)：输入两名编码者的等长标签数组，输出 { kappa, po, pe }——po 是观测一致率、pe 是偶然一致率、kappa = (po−pe)/(1−pe) 是扣除偶然后的净一致。
• 退化分支：当两编码者都只用了同一个标签（pe==1）时，κ 约定为：完全一致记 1，否则记 0（注释「kappa is conventionally undefined」）。
• cohensKappaWithCI(a, b, {bootstrap})：对 N 对观测重采样 B 次（默认 2000）出百分位 bootstrap 95% CI——N 小则 CI 宽，这正是「P1 想要 N>=50」的量化理由（文件头注释明写）。

本批 n=3 样本太小，κ 与其 CI 仅作方法演示、不下结论——CI 会宽到几乎无信息，恰好印证「小样本只示方向」。

一个关键事件记录的样例格式（待真跑回填，此处示意结构）：

[被试 2 / 任务 2 / 00:03:12 / 标签=错误]
原话引用：「这个 79.3 应该就是一致性吧……所以达标了？」
根因推断：把 V4-Flash 通过率(79.3%)误当成 judge-human κ。
关联高危点：Day 156 任务 1 的「数字混淆」失败信号 + Day 157「可理解性」维度。

这种结构化关键事件比一句「成功率 2/3」信息量大得多：它直接点名「κ 卡与通过率卡视觉上分不清」这个 IA 缺陷，是 Day 159 聚类、Day 160 优先改的精确线索。

转录处理流程（手工步骤，无需代码）：

1. 录屏 + 录音 → 转文字（保留时间戳，便于定位「卡在第几秒」）。
2. 按任务切分转录段（每任务一段，对齐 Day 157 的 5 个脚本）。
3. 每段对照预写成功判据打三标签之一（成功/求助/错误）。
4. 标注「关键事件」（critical incidents）：被试明显困惑、走错、读错标签的瞬间，附原话引用——这是定性洞察的金矿，比成功率数字更能定位根因。
5. 汇总成 n=3 成功率表 + 关键事件清单，落 docs/AML_GOVERNANCE_MAP.md。

3. 今日实战

1. 招募 3 名真实被试（贴近目标用户：有金融/合规或数据分析背景者优先），分别对 harness 面板原型与 AML 面板原型两块做 think-aloud。
2. 主持人遵守最小干预：仅在沉默时提示「请继续说」，全程录屏 + 录音。
3. 用 Day 157 的 5 个 AML 任务脚本 + Day 156 的 3 个 harness 任务脚本逐一驱动被试操作。
4. 转录后按「成功 / 求助 / 错误」三标签对每任务每人编码，算逐任务成功率。
5. 把 3 份转录摘要 + n=3 成功率表 + 关键事件清单（带被试原话引用）写入 docs/AML_GOVERNANCE_MAP.md 的可用性测试章节，标出成功率掉到 0/3 或 1/3 的高危任务，供 Day 159 聚类。

4. 今日实测 / 产出

• 3 份转录 + 任务成功率表（n=3）— 待用户测试（user-gated / 外部动作）。
• 跑通后产出 n=3 的逐任务成功率百分比。
• 方法与编码标签（成功 / 求助 / 错误）已定，可即时执行一旦招到被试——不臆造任何成功率数字。

5. 常见误区 / 陷阱

• 主持人引导式提问。 「这里是不是不好找？」会把被试行为染成主持人预设，污染自然信号；只允许「请继续说」。
• 把 n=3 的成功率当统计显著结论。 首批仅用于定性发现高危点；显著性留给 B17 的 A/B（且那里 N=29 都还 not-sig）。
• 省略「求助」中间档，只记成功/失败。 会丢掉「能做但费劲」这类体验问题，导致优先级判断失真。
• 不录屏只凭记忆。 出声协议的价值全在实时转录；事后回忆等同问卷，抓不到当时的犹豫。
• 编码判据临场拍脑袋。 判据必须 Day 157 预写、编码时照搬；临场定义会让标签变成主观吐槽，失去可比性。
• 只记成功率、丢掉关键事件原话。 「成功率 1/3」告诉你有问题，被试原话「我以为这个 79.3% 是 κ」才告诉你是什么问题——根因藏在引用里。
• 被试招得太像自己。 招熟悉本项目的同事会高估可用性；要招贴近目标用户（金融/合规背景但首次见此面板）的人。
• 两块原型固定先后顺序。 顺序效应会系统性惩罚先测的那块；3 人间轮换先后以缓解。

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

• NN/g, "Thinking Aloud: The #1 Usability Tool"（2024-09 复核版）— 出声协议记录纪律主线。
• NN/g, "How to Conduct a Usability Test"（2024 复核版）— 主持人最小干预与编码流程。
• 本仓代码：src/agent/eval/cohensKappa.ts（2026 当前实现）— 编码一致性核对方法（演示用）。
• NN/g, "Critical Incidents in Usability Testing"（2024 复核版）— 关键事件记录法。
• NN/g, "Avoid Leading Questions in User Research"（2024 复核版）— 主持人最小干预反引导。
• FIS×Anthropic AML Copilot 模式（2026-05）— 被测原型的任务流来源。

SOTA检查 (2026-06 更新)

• 当前主流：三标签编码 + 出声协议仍是 NN/g（2024-09）标准实践，current；小样本多轮迭代是可用性工程的稳定范式。
• 是否仍 SOTA：是。AI 工具改变了原型生成速度，但「真人出声 + 人工编码」的测试内核未被替代——LLM 不能替真人提供可用性信号。LLM 至多辅助转录与摘要，三标签编码仍须人工对照判据。
• 过时黑名单：
  • AVOID 主持人引导式提问——污染自然行为。
  • AVOID 把 n=3 成功率当统计显著结论——首批仅定性定位高危点。
  • AVOID 用 LLM / 合成假用户扮演被试——5 人指真实人类。
  • AVOID 单人编码不核一致性——可用性编码也该避免单人自评（Day 155 原则）。
• 下次复查点：Day 159 补到 5 人做痛点聚合时，复查首批编码标准是否需对齐（避免两批编码漂移）；若引入第二编码者，跑 cohensKappa.ts 记编码 κ。

衔接

• 昨天：Day 157 — AML 面板信息架构，定四段任务流 IA 与 5 个 think-aloud 任务脚本。
• 今天：招 3 人跑首批 think-aloud，三标签编码出 n=3 逐任务成功率，定性定位高危点。
• 明天：Day 159 — 跑 think-aloud 第 2 批 + 痛点聚合，补到 5 人并按严重度聚出 top-3 痛点。