cmroubao/docs/tasks/T-212.md

---
id: T-212
title: 修复 Top 5 候选 ordinal 与证据映射
phase: 2
deps:
  - T-211
status: DOING
created: 2026-07-27
context_ref: edfee2c
work_branch: null
write_paths:
  - docs/tasks/T-212.md
  - docs/current-state.md
  - android-buyer/app/src/main/java/com/roubao/autopilot/MainActivity.kt
  - android-buyer/app/src/main/java/com/roubao/autopilot/procurement/**
  - android-buyer/app/src/main/java/com/roubao/autopilot/vlm/**
  - android-buyer/app/src/test/java/com/roubao/autopilot/procurement/**
  - android-buyer/app/src/test/java/com/roubao/autopilot/vlm/**
---

## 问题 / 背景

T-211 对通过 SKU 硬约束的候选重新排序并生成连续回传 ordinal，但人工接受仍使用
VLM 原始候选 ordinal 查找已经重排的 `ExecutionCandidateDraft`。当原始候选 3 得分
最高并被重排为回传候选 1 时，现有查找可能错误选择回传候选 3，导致人工结论与推荐、
截图证据不一致。

## 关联需求与交互

- 功能：F-007、F-008、F-009。
- 用户故事：US-005、US-008。
- 交互：IX-007、IX-009 的建议候选接受、拒绝和结果回传。
- 架构/API：不修改后端 candidate batch schema；修复 Android 本地从原始曝光
  ordinal 到回传 ordinal、证据和人工终态候选的映射。

## 方案

1. 增加纯 Kotlin 的候选重排结果模型，同时保存 `source_ordinal`、连续
   `ranked_ordinal`、评估结果和证据 SHA-256，不再靠两个列表的位置或相同整数隐式关联。
2. 候选批次、推荐项和人工接受结果从同一份重排结果生成。非空批次推荐固定指向排序
   后的候选 1；人工接受候选也必须使用该候选及其同源证据。
3. 拒绝、无匹配和空候选路径不携带候选；不得回退到“找不到就取第一个”掩盖映射错误。
4. 保持 T-211 的 `0..5`、颜色/尺码硬约束、阈值和排序规则不变。

## 验收要点

- [ ] 原始候选 3 得分最高时，回传候选 1、推荐项和人工接受终态都引用原候选 3 的证据。
- [ ] 过滤后只剩原始候选 2、5 时，回传 ordinal 为 1、2，证据分别保持 2、5 的来源。
- [ ] 相同分数按置信度和原始曝光顺序稳定排序，重试不会改变映射。
- [ ] 空候选、单候选、拒绝和无匹配路径不产生越界或错误 fallback。
- [ ] 后端 schema v2 的推荐首项、连续 ordinal 和证据资产校验继续通过。
- [ ] Android 单元测试和 Debug 构建通过；人工接受仍保持
  `order_submitted=false`。

## 边界

- 不改变拼多多页面自动化、VLM prompt 或 SKU 匹配含义。
- 不增加候选数量，不实现 T-208 人工标签数据集。
- 不加入购物车、不选择规格、不提交订单或支付。

## 执行记录

- 2026-07-27：从 T-211 完成后的代码审查登记。先修复结果身份映射，再扩展规格弹窗
  采集，避免把错误候选写入后续优化数据。
- 2026-07-27：基于 `1d9dd08` 领取任务，先建立可单测的显式映射模型，再接入候选
  批次和人工接受路径。