4.2 KiB
4.2 KiB
id, title, status, phase, deps, created
| id | title | status | phase | deps | created | |||
|---|---|---|---|---|---|---|---|---|
| T-676 | 三个工作流商品状态筛选默认值优化 | DONE | 7 |
|
2026-07-20 |
T-676 三个工作流商品状态筛选默认值优化
问题 / 背景
①②③都已提供商品状态筛选，但当前新打开页面时均默认「全部商品状态」。这会让②AI生成和③更新蝦皮先展示未上架、审核中、状态未知等默认不能处理的记录，增加误操作和点数/线上更新范围判断的负担。
三者不能机械统一为「架上商品」：①新导入任务通常仍是「待检测」，若默认筛到架上商品，运营会看不到刚导入的数据，容易误以为导入失败或没有待采集任务。
方案
- ①导入采集的商品状态筛选初始默认保持「全部商品状态」，让待检测的新导入记录可见；点击采集后的范围确认仍默认「采集架上商品」，由真实商品页检测结果决定是否继续采集。
- ②AI生成的新页面初始默认选择「架上商品」，只先展示正常商品，降低异常商品误入生成范围和消耗点数的风险。
- ③更新蝦皮的新页面初始默认选择「架上商品」，只先展示可能进入更新预检的正常商品，减少用户先看到大量必然被拦截记录的困惑。
- 这仅是界面初始筛选值：用户主动选择「全部商品状态」或任一异常状态后，刷新、切换批次/店铺、输入商品ID和处理/生成/更新状态筛选时继续沿用既有的有效选择保留逻辑，不得每次刷新强制改回默认值。
- ①②③的实际执行边界不变：①仍在商品详情页实时检测后由范围确认控制；②仍需范围确认，默认只生成
normal；③仍通过build_apply_plan()和 Worker 再次拒绝非normal或内容不完整任务。商品状态下拉只缩小当前列表和候选范围，不能成为绕过安全检查的授权。
验收标准
- 新打开①时商品状态筛选为「全部商品状态」，待检测的新导入行可见；采集范围确认默认策略不变。
- 新打开②和③时商品状态筛选为「架上商品」，列表仅展示原始状态为
normal的记录。 - ②③主动改选全部、未上架、审核中、状态未知或待检测后，刷新或切换其他筛选条件不会无故重置为架上商品。
- ②默认架上商品时开始生成、③默认架上商品时检查/开始更新，只以当前筛选结果构建候选；异常商品即使用户手动筛出，仍不能绕过既有范围确认、状态预检和内容预检。
- 不修改 SQLite schema、历史商品状态迁移、Chrome/CDP、AI 调用、Excel 回写或线上更新逻辑。
tests/test_gui.py覆盖三个页面的新建默认值、待检测可见性、用户选择保留及②③安全边界不回归。
测试与文档
- 更新
docs/routes.md和docs/api.md中①②③商品状态筛选的默认值与“筛选不等于授权”说明。 - 运行：
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。