开发日志

每小时一轮、6 小时轮转一圈，本轮专题是「目录扩量 + 详情补采」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 50 条。⚠ AI 已 39.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「多平台趋势全量采集」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 52 条。本轮跑掉：品牌名录补采、分析冒烟测试、数据质量门禁、快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 18 分钟）。⚠ AI 已 40.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「新品榜刷新 + 完整性 + 自我改进」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 5 条。失败：全站死链审计(rc=1)，下一轮会重试。⚠ AI 已 41.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「品牌补采 + 情报留痕」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 7 条。本轮跑掉：快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 23 分钟）。⚠ AI 已 42.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

失败步骤：bin/check_links.py（退出码 1）。其余步骤已正常完成，下一轮会自动重试。

过去 2 小时工作记录 9 条。本轮跑掉：分析冒烟测试、数据质量门禁（约 2 分钟）。⚠ AI 已 43.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

失败步骤：-m tracker.cli analyze（退出码 2）。其余步骤已正常完成，下一轮会自动重试。

过去 2 小时工作记录 11 条。本轮跑掉：完整性抽检、品牌目录扩量、补采商品详情、快信号采集（工厂+社媒）（约 17 分钟）。⚠ AI 已 44.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「目录扩量 + 详情补采」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 13 条。⚠ AI 已 45.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「多平台趋势全量采集」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

16 个类目 Top100 采集 + 详情补齐 + QA 门禁

每小时一轮、6 小时轮转一圈，本轮专题是「新品榜刷新 + 完整性 + 自我改进」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 15 条。本轮跑掉：品牌名录补采、分析冒烟测试、数据质量门禁、快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 33 分钟）。⚠ AI 已 46.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

过去 2 小时工作记录 18 条。本轮跑掉：阈值自我改进、新品榜刷新、完整性抽检、品牌情报留痕（约 5 分钟）。失败：全站死链审计(rc=1)，下一轮会重试。⚠ AI 已 47.8 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

用户反馈页面打开非常慢。先测不猜：TTFB 38.8 秒，第二次请求直接超时。cProfile 定位到 reference_products 占 39.8s/42.8s（93%），flatten 被调用 51,595 次，re.search 跑了 734 万次。根因是典型的 O(n²)：63 条建议各配一次参考商品图，每条建议都遍历 799 个新品标题做款式属性解析，于是同一批标题被反复解析 5 万多次。标题是天然适合缓存的对象，按标题字符串做 key 就能把 5 万次降到 799 次。

1) 给 flatten 加 lru_cache：42.87s → 1.32s，缓存命中 50,858 次、仅 737 次未命中，正好是那 5 万次重复调用。缓存返回 frozenset 而不是 set——共享对象被任何调用方原地修改（.add/.discard）都会污染后续所有调用且极难排查，frozenset 让这种错误直接变异常而不是静默的错误结果。2) generate_recipes 的 stats() 改成倒排索引：加完缓存后它成了新热点，1643 个候选组合 × 799 个商品 = 131 万次属性比对占 1.5s。改成按属性建倒排索引、从最稀有的属性起步筛，候选量立刻降下来。最终：首次 0.82s、热缓存 0.14s，3 个并发请求合计 0.47s。

性能优化改错结果比慢更严重，所以单独验证了一遍：把「扫全量」的旧实现和「倒排索引」的新实现并排跑，对生成器会枚举的全部 1643 个属性组合逐个比对命中数，结果完全一致。倒排索引只用来缩小候选范围，最终判定仍是原来的 all(x in a for x in attrs)，不会漏项。

服务器用的是 ThreadingHTTPServer，但第二次请求照样超时，一开始以为是单线程瓶颈。真因是 Python 的 GIL：38 秒的纯 Python 正则渲染会把 GIL 一直占着，线程切换根本没机会，所以多线程对 CPU 密集的渲染毫无帮助，一个慢页面会阻塞所有其他请求。这也说明「慢页面」不只是它自己慢，而是会拖垮整站——优化到 0.14 秒后并发 3 个请求合计 0.47 秒，问题自然消失。

验证页面内容时发现 P0 从 1 条暴涨到 19 条，第一反应是怀疑自己优化改坏了。核对后确认不是：趋势源从 30 个涨到 34 个，各属性广度普遍上升，而阈值写死 P0≥4，等于标准被悄悄放宽了。改成按活跃平台数的比例：P0≥20%、P1≥10%、P2≥5%（34 个源即 7/3/2），这样数据源继续增加时尺子保持一致，分层不会失效。改后 P0 4 条 / P1 20 条 / P2 16 条，重新有区分度。

每小时一轮、6 小时轮转一圈，本轮专题是「品牌补采 + 情报留痕」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 25 条。本轮跑掉：快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 17 分钟）。

用户指出「建议开发的款不少 CRZ YOGA 已经有了，要先全部采集再分析」。查证属实且比预想严重：brand_discovery 登记了 2,156 个 CRZ YOGA 商品，但只有 486 个（22.8%）有标题，剩下 1,670 个从没参与过款式分析。根因在 expand_catalog：它为了确认品牌抓了 2,131 个移动版商品页，只读了 byline 品牌字段就把整页内容丢掉，标题没存。于是「缺中腰」「缺有口袋」这类结论，是在只看了 22.8% 的商品上得出的。实测反证：库里就有 "CRZ YOGA Mid Waisted Running Shorts 3""，自家有 7 个中腰款，却建议开发中腰——正是用户说的那种错。

那 1,665 个缺标题的商品，页面其实都还在磁盘上（cache/brand，3.5G）。所以补齐不需要重抓一次：直接解析本地文件即可。但移动版页面没有 id="productTitle"，原有解析器抽不到标题，新增 extract_title 兼容两种结构，并利用移动版的一个额外好处——它把「商品名」和「卖点描述」分开放在 id="title" 与 .dp-title-differentiators 里，后者恰好含 High Waisted / with Pockets / Fold Over 这类款式信息，正是款式分析要的信号，所以两段都取。结果：CRZ YOGA 覆盖率 22.8% → 100.0%（2156/2156），全品牌 99.8%（2423/2427）。同时改了 expand_catalog，以后抓到就存标题，不再丢。

补齐标题后逐层核对，又挖出三个真 bug：1) 趋势信号跨天累加：trend_signals 每源每天一行，代码用 SUM(n) 把所有天加起来，而分母用单日 MAX——分子分母口径不一致，库里已有 4 天数据，竞品数最高虚高 4 倍（紧身裤 1001，实为 337；宽腿 648，实为 74）。改成每源只取最新一次采集。2) 正则漏了词形变化：mid_rise / low_rise 写成 \\bmid[\\s-]?wais?t\\b，而亚马逊标题普遍写 "Mid Waisted"，多出的 ed 让 \\b 失败，自家 7 个中腰款被判成「没有中腰」。high_waist 当初写了 (ed)? 所以没事。3) 整个 Sports Bra 产品线在词典里不存在（只有 built_in_bra=内置胸垫，那是上衣细节）——CRZ YOGA 有 97 个运动内衣商品，全部落在分析视野之外。已补 sports_bra 廓形。顺带补了 butt_lift 的 (ing)?（"Butt Lifting"）和 buttery_soft 的 "Ultra Soft"。

1) 「自家是否已有」原来用单属性边际判断（own.get(a,0)==0），只要每个属性单独出现过就算有了。但开发新品问的是「有没有一款同时具备」。CRZ YOGA 有 18 个加绒款、12 个宽腿款，却一款「加绒宽腿」都没有，那正是该开发的缺口，用边际判定却被判成「已完成」。改成组合同步判定后，真实缺口从 6 条恢复到 66 条。2) 证据广度原来取各属性 max，强势属性会盖住弱势属性：「抽绳束脚裤」里束脚裤 14 个平台、抽绳只有 2 个，用 max 拿到 12 分直接进 P0，但真正要验证的是「抽绳」这个新增点。改成 min（最弱一环）后，分层恢复：P0 从 55 条降到 5 条，P1 17、P2 25、P3 19。

今天修的 bug 里有两个是「不报错、只安静地给出错误结论」的类型：正则漏了 ed、词典缺了一整条产品线。这类错误不会被任何现有检查抓到，只能靠断言防。新增 bin/check_lexicon.py：48 条正例（每个属性配一句真实亚马逊标题，必须命中）+ 9 条反例（防止正则写太宽，比如直筒被误判成宽腿、低腰被误判成高腰）。已加入改进待办，每 2 小时自动跑一次。写测试时它还反过来查出我三个以为正常的属性名写错了（stretch / lightweight / skirt_skort / jogger / moisture_wicking）。

每小时一轮、6 小时轮转一圈，本轮专题是「快信号采集 + 死链审计」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 32 条。本轮跑掉：款式词典回归、分析冒烟测试、数据质量门禁（约 3 分钟）。

失败步骤：-m tracker.cli analyze（退出码 2）。其余步骤已正常完成，下一轮会自动重试。

过去 2 小时工作记录 34 条。本轮跑掉：品牌目录扩量、补采商品详情、快信号采集（工厂+社媒）（约 23 分钟）。

每小时一轮、6 小时轮转一圈，本轮专题是「目录扩量 + 详情补采」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 36 条。本轮跑掉：完整性抽检（约 1 分钟）。

每小时一轮、6 小时轮转一圈，本轮专题是「多平台趋势全量采集」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

每小时一轮、6 小时轮转一圈，本轮专题是「新品榜刷新 + 完整性 + 自我改进」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 38 条。本轮跑掉：品牌名录补采、款式词典回归、分析冒烟测试、数据质量门禁、快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 35 分钟）。

过去 2 小时工作记录 40 条。本轮跑掉：阈值自我改进、全站死链审计、品牌情报留痕（约 3 分钟）。

每小时一轮、6 小时轮转一圈，本轮专题是「品牌补采 + 情报留痕」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 42 条。本轮跑掉：新品榜刷新、快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 22 分钟）。

每小时一轮、6 小时轮转一圈，本轮专题是「快信号采集 + 死链审计」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 44 条。本轮跑掉：完整性抽检、款式词典回归、分析冒烟测试、数据质量门禁（约 4 分钟）。⚠ AI 已 6.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

失败步骤：-m tracker.cli analyze（退出码 2）。其余步骤已正常完成，下一轮会自动重试。

过去 2 小时工作记录 46 条。本轮跑掉：品牌目录扩量、补采商品详情、快信号采集（工厂+社媒）（约 21 分钟）。⚠ AI 已 7.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「目录扩量 + 详情补采」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 48 条。⚠ AI 已 8.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「多平台趋势全量采集」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 50 条。本轮跑掉：品牌名录补采、款式词典回归、分析冒烟测试、数据质量门禁、快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 26 分钟）。⚠ AI 已 9.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「新品榜刷新 + 完整性 + 自我改进」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 52 条。本轮跑掉：全站死链审计（约 1 分钟）。⚠ AI 已 10.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「品牌补采 + 情报留痕」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 54 条。本轮跑掉：款式词典回归、快信号采集（工厂+社媒）、品牌目录扩量、补采商品详情（约 23 分钟）。⚠ AI 已 11.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

每小时一轮、6 小时轮转一圈，本轮专题是「快信号采集 + 死链审计」。这样安排是因为全量跑一轮约 25 分钟，每小时都全跑会把各站限流打满、反而拉低数据质量；轮转能保证不同数据源在一天内都被刷新多次。

过去 2 小时工作记录 56 条。本轮跑掉：分析冒烟测试、数据质量门禁（约 2 分钟）。⚠ AI 已 12.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。

失败步骤：-m tracker.cli analyze（退出码 2）。其余步骤已正常完成，下一轮会自动重试。

过去 2 小时工作记录 58 条。本轮跑掉：完整性抽检、款式词典回归、品牌目录扩量、补采商品详情、快信号采集（工厂+社媒）（约 24 分钟）。⚠ AI 已 13.7 小时没有主动记录工作。需要判断力或改代码的改进（新功能、新分析、分析口径调整）脚本不该硬做，标记为待 AI 处理。