# TASK · Jev 意图 v2 修复单：gold 争议复核（2026-09-27）

- 类型：研究单修复（离线；**不需要再调任何模型 API**，全部从已提交 JSON 重算）
- 基线：`origin/codex/jev-intent-v2-20260927` @ `0b68fa97`（其上游 `origin/staging` @ `fdb7087b`）
- 执行分支：继续在 `codex/jev-intent-v2-20260927` 上提交；**验收前不推 staging**
- 原单：`TASK-rectification-jev-intent-classifier-research-v2-20260927.md`；报告 `docs/research/jev_intent_2026_09_27.md`

## 1. 验收结论（对照原单逐条）

| 项 | 结论 | 证据 |
| --- | --- | --- |
| T1 重抽来源 B（带上一轮） | **通过** | 715 条 / 有上一轮 634；`git ls-tree` 无原文；JSON `rows` 无任何用户文本字段 |
| T2 三变体 + 测试 | **通过** | `python3 -m unittest tests.test_jev_intent_research` 16 passed（staging 基线 15，任务书起点 11）；V0 state 未动 |
| T3 跑数、`--from-report` 可重算 | **通过** | 本机 `--from-report` 重算 verdict=缺数据、intent 79.44%、n=715，与报告一致；md 无 diff |
| T3 结论归因 | **未通过** | 报告把「缺数据」归因于 B/C 同层差 > 10pp、把「过不了门」归因于 Jev 置信度——两者都建立在一批有争议的 gold 上，见 §2 |
| 红线 4（不得模型代标 gold） | **存疑** | `executor_read` 565 条由 coding agent 阅读写入；09-19 同样做法，但这次与两个独立模型的分歧达 133 条，不能再当人工真值用 |
| 交付纪律 | **提醒** | 首轮 `e3bd3930` 把 `scripts/**`、`tests/**` 直接推上 staging（触发门禁并部署，staging 现跑 `e3bd3930`，其后两笔纯文档）。原单写的是执行分支实现、验收后再进 staging。本修复单**验收前不推 staging** |

## 2. 事故实证（全部可由 `docs/research/jev_intent_2026_09_27.json` 的 `rows` 重算）

1. **gold=unclear 占比反常**：点选层 269 条里 gold=unclear **104 条（39%）**；采集层 336 里 52；无焦点 110 里 46。真人对着四个选项答题、四成「语义不清」，不合常理。
2. **两个独立模型一致反对 gold**：Jev V0 判错 147 条，其中 **135 条 Flash（线上生产提示）与 Jev 判成同一个标签**，且 133 条都是 `gold=unclear → 两模型=answer_current_focus`（点选 67 / 无焦点 40 / 采集 26）。
3. **门槛数完全由这批争议行决定**：Jev V0 高置信错误 86 条，**86/86** 是 `gold=unclear→answer` 且 Flash 同判；V2 链式 41 条里 40 条同模式。
4. **敏感性（把 133 条争议行按两模型一致标签计）**：

| 变体 | 报告 intent | 敏感性 intent | 报告高置信错误 | 敏感性高置信错误 |
| --- | ---: | ---: | ---: | ---: |
| Jev V0 | 79.4% | **98.0%** | 12.9% | **0.0%** |
| Jev V2 链式 | 75.9% | 93.1% | 8.0% | 0.1% |
| Flash V0 | 75.7% | 94.3% | — | — |

   两种读法下结论相反：按执行方 gold，Jev 过不了门；按两模型一致标签，Jev V0 三项门槛全过。**没有人看过原文之前，两边都不能写。**
5. **与 gold 无关、可先落的发现**：无论哪种读法，V1/V2 都比 V0 差（无焦点层 gold=provide_new_evidence 被改判 answer 13–15 条；承接分中位 0.16、最大 0.86、≥0.9 为 0，沿用规则一次未触发）。Magpie 的喂法在我们的数据上没有收益——用户几乎不发「继续」这类纯承接句。
6. 延迟：Jev 中位 1178 ms vs Flash 705 ms，比 09-19 更慢。

## 3. 根因

标注者（coding agent）对「unclear」的口径与生产提示不一致：生产提示里「没有 / 记不清 / 用带年月的经历直接答」都是 `answer_current_focus`，只有「既没否定、也没说记不清、也没给带年月经历」才是 `unclear`。133 条争议行中两个模型都给出了合法 answer_class 且高置信，更像是标注把「答得短 / 答得偏」写成了 unclear。B/C 同层差 23.7 pp、38.8 pp 是同一根因的另一面：来源 C 的 gold 经过独立复核，来源 B 没有。

## 4. 决策记录

1. **gold 复核由产品本人做**（2026-09-27 产品拍板前先按此写；产品若改派，改这一行）。原因：执行方是模型，红线 4 下它的标注不能自证；09-19 的 157 条也是同一做法，只是当时没有第二个模型来暴露分歧。
2. 复核**只看争议行 + 对照行**，不重标全量：争议行 133（选择规则 `gold.intent=unclear ∧ jev_v0_1.intent=answer_current_focus ∧ flash_v0.intent=answer_current_focus`）全部，另从「三方一致」行分层随机抽 20 条做对照，防止复核者只顺着模型改。
3. 复核后**不再调 API**：所有变体原始输出已在 `rows`，改 gold 后 `--from-report` 重算即可，费用 0。
4. 门槛、变体、模型版本一律不变。
5. 原单「不接管、不影子双跑」维持；即使复核后 V0 过门，是否接入另开产品决策。

## 5. 硬红线

1. 复核表只落本机 `.cache/jev_intent/`（gitignore），**不进仓库**；报告只提交计数与两种读法的对照表。
2. 改 gold 只允许改被复核过的行；每行记 `gold_source = product_review`，原 `executor_read` 标签保留在 `gold_prev` 字段供审计。
3. 不得用规则、关键词、模型输出批量改 gold；「敏感性」那一列只能叫敏感性，不得写成结果。
4. 不改 `frontend/src/**`；不推 staging；不升 SDK。
5. `scripts/research/jev_intent_cache.py` 里的 `G:\Ferti\...` 硬路径改为只认 `JEV_INTENT_CACHE` 环境变量与仓库 `.cache/`（P3，顺手做，不单独立单）。

## 6. 任务分解

### F0 · 出复核表（执行方，本机）

- 新脚本或 `jev_intent_source_b_v2.py` 子命令：从本机 `source_b_v2.jsonl` + 报告 JSON 选出 133 争议行 + 20 对照行，写本机 markdown：`序号 | 层 | 当前题（含选项）| 上一轮助手句 | 用户这句 | 执行方 gold | Jev V0 | Flash V0 | 产品判定（留空）`。
- **验收**：表在 `.cache/jev_intent/review_2026_09_27.md`；`git status` 干净；行数 153；对照行随机种子写进 PROGRESS。

### F1 · 产品复核（产品本人）

- 只按生产提示口径填「产品判定」列：`answer_current_focus`（含 no / unsure / yes / weak_yes）、`provide_new_evidence`、`ask_about_result`、`stop_rectification`、`unclear`。
- **验收**：153 行全部有判定；对照 20 行里产品与执行方 gold 一致数写进报告（一致 < 16 则说明标注口径整体漂移，触发让步 1）。

### F2 · 回写与重算（执行方）

- 按 F1 改 gold（`gold_source=product_review`、保留 `gold_prev`），`--from-report` 重算全部表；报告新增「gold 复核」一节：争议行数、产品改判数（按层 × 原标签 × 新标签计数）、对照行一致率。
- 结论重写为三选一（过门 / 未过门 / 缺数据），并加一句「V1/V2 相对 V0 无收益，承接规则未触发」作为与 gold 无关的独立发现。
- **验收**：`--from-report` 输出与 md 一致；`unittest` ≥16；README 状态板与 PROGRESS 同步；BLOCKED.md 若无新阻塞不动。

## 7. 让步顺序

1. 对照 20 行产品与执行方一致 < 16 → 全量 715 条标注口径不可信，结论写 `blocked: 需重标全量`，不得用 133 行的复核结果外推。
2. 产品没时间复核 133 行 → 先复核点选层 67 行（争议最集中、最易判）；报告只对点选层下结论，其余层写 `blocked`。
3. F0 脚本出不来 → 产品直接读 `source_b_v2.jsonl`，执行方把 133 行的 `turn_id` 列表写到本机文件（**不进仓库**）。

## 8. 开工前置命令

```bash
git fetch origin --prune
cd .worktrees/jev-intent-v2-20260927 && git checkout codex/jev-intent-v2-20260927 && git pull --ff-only
PYTHONPATH=. python3 -m unittest tests.test_jev_intent_research        # 16 passed
python3 scripts/research/jev_intent_probe_v2.py --from-report           # verdict=缺数据, intent 0.7944, n=715
```

## 9. BUG 编号起点

`docs/BUG_HISTORY.md` 最大号 **BUG-1059**，本单起 **BUG-1060**（只在研究脚本自身缺陷时使用）。