---
id: T-676
title: 三个工作流商品状态筛选默认值优化
status: DONE
phase: 7
deps: [T-669, T-671, T-672]
created: 2026-07-20
---

# T-676 三个工作流商品状态筛选默认值优化

## 问题 / 背景

①②③都已提供商品状态筛选，但当前新打开页面时均默认「全部商品状态」。这会让②AI生成和③更新蝦皮先展示未上架、审核中、状态未知等默认不能处理的记录，增加误操作和点数/线上更新范围判断的负担。

三者不能机械统一为「架上商品」：①新导入任务通常仍是「待检测」，若默认筛到架上商品，运营会看不到刚导入的数据，容易误以为导入失败或没有待采集任务。

## 方案

- ①导入采集的商品状态筛选初始默认保持「全部商品状态」，让待检测的新导入记录可见；点击采集后的范围确认仍默认「采集架上商品」，由真实商品页检测结果决定是否继续采集。
- ②AI生成的新页面初始默认选择「架上商品」，只先展示正常商品，降低异常商品误入生成范围和消耗点数的风险。
- ③更新蝦皮的新页面初始默认选择「架上商品」，只先展示可能进入更新预检的正常商品，减少用户先看到大量必然被拦截记录的困惑。
- 这仅是界面初始筛选值：用户主动选择「全部商品状态」或任一异常状态后，刷新、切换批次/店铺、输入商品ID和处理/生成/更新状态筛选时继续沿用既有的有效选择保留逻辑，不得每次刷新强制改回默认值。
- ①②③的实际执行边界不变：①仍在商品详情页实时检测后由范围确认控制；②仍需范围确认，默认只生成 `normal`；③仍通过 `build_apply_plan()` 和 Worker 再次拒绝非 `normal` 或内容不完整任务。商品状态下拉只缩小当前列表和候选范围，不能成为绕过安全检查的授权。

## 验收标准

- [x] 新打开①时商品状态筛选为「全部商品状态」，待检测的新导入行可见；采集范围确认默认策略不变。
- [x] 新打开②和③时商品状态筛选为「架上商品」，列表仅展示原始状态为 `normal` 的记录。
- [x] ②③主动改选全部、未上架、审核中、状态未知或待检测后，刷新或切换其他筛选条件不会无故重置为架上商品。
- [x] ②默认架上商品时开始生成、③默认架上商品时检查/开始更新，只以当前筛选结果构建候选；异常商品即使用户手动筛出，仍不能绕过既有范围确认、状态预检和内容预检。
- [x] 不修改 SQLite schema、历史商品状态迁移、Chrome/CDP、AI 调用、Excel 回写或线上更新逻辑。
- [x] `tests/test_gui.py` 覆盖三个页面的新建默认值、待检测可见性、用户选择保留及②③安全边界不回归。

## 测试与文档

- 更新 `docs/routes.md` 和 `docs/api.md` 中①②③商品状态筛选的默认值与“筛选不等于授权”说明。
- 运行：

```bash
py -3.10 -m unittest discover -s tests -p "test_gui.py"
py -3.10 -m unittest discover -s tests
py -3.10 -m ruff check app tests main.py
py -3.10 -m compileall app main.py
git diff --check
```

## 非目标

- 不新增商品状态字段、状态重检入口、批量状态修复或新的状态选项。
- 不改变①采集、②生成、③更新的商品状态判定和安全拦截规则。
- 不强制把用户当前主动选择的筛选值改回默认值。

## 执行记录

- 2026-07-20：② `GenerateTab`、③ `ApplyTab` 初始化商品状态下拉为 `normal`；①保持原有 `all` 默认值。刷新任务列表不会重置用户主动选择的商品状态。
- 2026-07-20：补充 GUI 覆盖：①待检测行初始可见；②③初始仅显示架上商品；②③切换到异常状态后刷新仍保留选择；②③原有生成范围确认、更新状态/内容预检继续生效。依赖旧“默认全部”展示前提的历史用例显式选择“全部商品状态”。
- 验证通过：`py -3.10 -m unittest discover -s tests -p "test_gui.py"`（209 项）、`py -3.10 -m unittest discover -s tests`（633 项）、`py -3.10 -m ruff check app tests main.py`、`py -3.10 -m compileall app main.py`、`git diff --check`。