cmroubao/docs/tasks/T-212.md

id, title, phase, deps, status, created, context_ref, work_branch, write_paths

id	title	phase	deps	status	created	context_ref	work_branch	write_paths
T-212	修复 Top 5 候选 ordinal 与证据映射	2	T-211	DOING	2026-07-27	edfee2c	null	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 领取任务，先建立可单测的显式映射模型，再接入候选 批次和人工接受路径。