货憨憨的 getPage 响应里带有商品质量诊断。其中「缺少视频」直接标出了 哪些商品才需要去淘宝找视频，能把工作量从「全店商品」缩小到真正需要处理的那部分。 现在这个字段被完全丢弃了。
getPage
字段名是 diagnosisInfo，不是 diagnoses。它是记录里的一个对象， 真实结构比负责人贴出的多一层：
diagnosisInfo
diagnoses
"diagnosisInfo": { "itemId": "53115620137", "qualityLevel": "1", "diagnoses": [ { "field": "ALL", "diagnosisResults": [ {"type": "缺少视频", "solution": "上传相应的视频"}, {"type": "缺少品牌信息", "solution": "填写品牌信息"} ] } ] }
500 条样本里出现过的全部诊断类型：
field 实测只出现过 "ALL"；qualityLevel 出现过 "1" 和 "2"。
field
"ALL"
qualityLevel
"1"
"2"
itemStatus
SOLD_OUT
BANNED
500 条样本里 293 条 diagnosisInfo 为 null；另一个店铺一页 50 条里只有 10 条有诊断。 比例因店铺而异。
null
null 不等于「有视频」：可能是货憨憨没诊断过、诊断还没跑完，或该商品不参与诊断。 若把 null 当成「有视频」，这些商品会被永久排除在处理范围外且无人察觉。
因此 video_diagnosis 取三个值：
video_diagnosis
missing
ok
unknown
products
quality_level
product_diagnoses
采集成本为零（同一份响应里已经有了），但另外 5 种类型对将来的商品质量优化同样有价值。 现在丢掉，将来要用就得重新全量拉一遍。
internal/store/store.go
internal/store/product.go
internal/store/diagnosis.go
diagnosis_test.go
internal/huohanhan/product.go
internal/huohanhan/product_test.go
app.go
frontend/src/views/ProductListView.vue
go vet ./... go test ./... cd frontend; npx vite build
本工单由本机 Codex CLI（模型 gpt-5.6-sol）实施，由 Claude 审核。
gpt-5.6-sol
Codex 必须遵守：
AGENTS.md
main.go
internal/
go test
go vet ./...
go build ./...
go test ./...
docs/
我曾建议存三态，理由是 500 条样本里 293 条 diagnosisInfo 为 null， 而 null 可能表示「尚未诊断」而非「已有视频」；按两态处理时， 这部分商品会被归入「有视频」，从而不会进入淘宝搜索的处理范围。
负责人已知悉该顾虑并明确选择两态，措辞为「初定」，属于阶段性决定。 按此实施，不再保留 unknown。
若后续发现有商品实际缺少视频却被归为「有视频」，重新评估是否恢复三态。
No dependencies set.
The note is not visible to the blocked user.
基本信息
依赖与并行
原始需求
页面上可以筛选『缺少视频』的，因为缺少视频的商品才需要用图片去淘宝搜商品视频」
要解决什么
货憨憨的
getPage响应里带有商品质量诊断。其中「缺少视频」直接标出了哪些商品才需要去淘宝找视频，能把工作量从「全店商品」缩小到真正需要处理的那部分。
现在这个字段被完全丢弃了。
真实数据（Claude 已用负责人抓包和线上只读验证核对）
字段名是
diagnosisInfo，不是diagnoses。它是记录里的一个对象，真实结构比负责人贴出的多一层：
500 条样本里出现过的全部诊断类型：
field实测只出现过"ALL"；qualityLevel出现过"1"和"2"。已线上验证的两点
itemStatus不影响诊断：实测三个店铺的 NORMAL 与 UNLIST 均正常返回诊断。SOLD_OUT与BANNED查询返回 0 条，这是货憨憨自身的已知现象，与本工单无关。关键设计：必须存三态，不能存布尔
500 条样本里 293 条
diagnosisInfo为null；另一个店铺一页 50 条里只有 10 条有诊断。比例因店铺而异。
null不等于「有视频」：可能是货憨憨没诊断过、诊断还没跑完，或该商品不参与诊断。若把
null当成「有视频」，这些商品会被永久排除在处理范围外且无人察觉。因此
video_diagnosis取三个值：missingokunknowndiagnosisInfo为 null做什么 / 不做什么
diagnosisInfo；products表加video_diagnosis和quality_level；新增
product_diagnoses表保存全部诊断类型；界面加诊断筛选；「视频」列显示诊断结果。
为什么要存全部诊断类型而不只存「缺少视频」
采集成本为零（同一份响应里已经有了），但另外 5 种类型对将来的商品质量优化同样有价值。
现在丢掉，将来要用就得重新全量拉一遍。
预计修改文件
internal/store/store.go（只在 migrations 末尾追加，不得修改已有条目）internal/store/product.go（Product 加字段、查询条件加诊断筛选）internal/store/diagnosis.go、diagnosis_test.go（新建）internal/huohanhan/product.go（解析 diagnosisInfo）internal/huohanhan/product_test.goapp.gofrontend/src/views/ProductListView.vue验收标准
diagnosisInfo为 null 时存unknown，不得当成okmissing，有诊断但没报的存ok验证方式
交给 Codex 实施的约定
本工单由本机 Codex CLI（模型
gpt-5.6-sol）实施，由 Claude 审核。Codex 必须遵守：
AGENTS.md，第 10 节「项目专用规则」是不可违反的红线。main.go和app.go；internal/不许 import wails。go test覆盖；不能联网的部分用假数据测，不要写需要真实账号才能跑的测试。go vet ./...、go build ./...、go test ./...。docs/下的任何文件（那是 Wiki 镜像）。需求变化记录（2026-09-02，负责人决定）
diagnosisInfo为 null）一律按有视频处理我此前提出的顾虑与处理
我曾建议存三态，理由是 500 条样本里 293 条
diagnosisInfo为null，而
null可能表示「尚未诊断」而非「已有视频」；按两态处理时，这部分商品会被归入「有视频」，从而不会进入淘宝搜索的处理范围。
负责人已知悉该顾虑并明确选择两态，措辞为「初定」，属于阶段性决定。
按此实施，不再保留
unknown。若后续发现有商品实际缺少视频却被归为「有视频」，重新评估是否恢复三态。
因此变更的实现约定
video_diagnosis只有两个取值：missing（诊断含「缺少视频」）与ok（其余全部情况，含 null）ok下次「下载数据」会整体刷新
不变的部分
product_diagnoses表，不只保存「缺少视频」。采集成本为零，另外 5 种对后续商品质量优化有价值。
qualityLevel。