开发日志

采集链路的基础修整：listing.js 与 qa.py。

pipeline.py 与 repair_prices.py。

import_csv.py、serve.sh、install_web.sh：把采集结果导入库并起站。

check_access.sh、set_web_auth.sh。

把分析做成可注册、可激活的清单，而不是写死一堆函数。

自动流程跑的审计：763 个商品待补详情、生成次日预测、清理过期缓存。

审计/自修复/激活分析/给昨日预测打分/生成明日预测。

同一批还修了「品牌攻防改为比排名质量」、标记疑似变体合并的评论跳变。

integrity 抽检先报不一致、再报通过，触发了我后面的排查。

维表字段混进快照事实层，会污染所有基于快照的结论。同批修了「品牌被解析成评分」。

16 个类目逐个看内部结构，10→12 个维度。同时修了顶栏变高导致的吸顶错位。

系数符号反了会把「越贵名次越好」读成相反结论。同批去掉模板里的无条件断言。

含品牌采集器 collect_brand.py（榜单 + 旗舰店两条渠道），并修了三处计数/口径错误。

品牌情报的「每天变化」需要历史留痕，做成独立表和命令行入口。

run_daily.sh 采集后立刻刷新；loop_improve.py 每 3 小时兜底。

原脚本每个选择器只取第一个元素，表格里的涨跌配色从没被检查过；改为遍历全部元素后，检查数 235→325。

每条建议强制带「触发数字 / 前提 / 失效条件」，拒绝模板话。

当日变化、新款信号、价格活动、竞争对抗、薄弱环节、新款建议、行动清单、历史留痕。

子代理写的「两边口径一致」是错的：拿全站中位和类目内中位直接比。改为同时给出两个口径并说明不可相减。

价格曾从维表取（当日 $28 记成 $32）；建议的门槛曾一律用主战场类目，把跑步类目商品算成 49%（真实 20%）。

原说明让人以为机制上不会有推断品牌；加 inferred_brand_rows() 守卫，出现 slug 推断位次时在页面显式披露。

月历热力图 + 逐小时时间轴。actor 区分「我」和「定时任务」，没干活的小时如实显示空白，不用自动产出冒充我的工作。

排查「CRZ YOGA 全商品采集」进度时发现：collect_brand.py 第 284 行无条件写 last_discover，导致 12:39 那次 --dry-run 预演（一个商品都没抓）把 CRZ YOGA 锁进 BRAND_REVISIT=6 小时冷却。已改为 dry-run 完全不写状态。

16 个重点品牌的榜单位次全部覆盖、商品详情 100% 有；但旗舰店渠道只成功 2 个品牌（G Gradual 43 个、Hanes 12 个），而 find_store_url 其实能为全部 16 个品牌定位到旗舰店地址——卡在路径级限流(503/429)，不是代码问题。

按你的更正把板块从「开放日志」改名为「开发日志」（导航、页面标题、CLI、首页卡片共 12 处）。同时修掉巡检报出的真问题：日历最深一档用白字配 #3d84e0 只有 3.77:1，lvl3/lvl4 的副文字更是 3.96/2.60；改为整格统一深色字、色阶最深到 #4a90e2（5.03:1）。

store_skip_until 是 45 分钟，而品牌 last_discover 冷却 BRAND_REVISIT 是 6 小时。旗舰店被限流时照常推进 6 小时，会出现「店 45 分钟后就能开、品牌却要等 6 小时才再轮到」的空转。已把两个时钟对齐：旗舰店没拿到时把 last_discover 回拨，使品牌在旗舰店冷却结束时即可再入选。

旗舰店连续 429 触发 45 分钟长退避。已挂 bin/wait_store.py：等到冷却结束再试，最多 8 轮，失败按脚本自带退避再等，不并发、不绕过限流。

work_log 表建在 data/tracker.sqlite，含 log_date/ts 两个索引，条目不随进程重启丢失；页面每次访问直接读库，不缓存。

为把 CRZ YOGA 从 18 个商品扩到全量，系统测了 6 条枚举路径：桌面搜索 / 搜索+类目 / 品牌筛选 rh=p_4 / 移动搜索 gp/aw / field-keywords 全部 503，唯一的 200 是反爬验证页。结论：只有品牌旗舰店可枚举。同时发现详情页 carousel 只有 69% 是本品（16 个里 5 个是 BMJL/PINSPARK/THE GYM PEOPLE 等竞品），所以不能拿 carousel 当品牌商品来源，否则会把竞品写进自家目录。

旧版只打开旗舰店首页滚动一次，这是「一个品牌只能拿几十个商品」的直接原因——品牌店商品分散在多个 pageId（导航分类 tab / Shop all），只爬首页等于只看了目录第一页。新版 tracker/brand_store_full.js：拦截 XHR 找服务端商品 JSON、抽取店内所有 /stores/page/<id> 链接逐个访问、每页内部滚动展开，仍不绕过限流。

榜单每类目只 100 名，所以只看榜单严重低估品牌体量。新脚本从已知商品出发，沿商品页关联模块（carousel id_list）逐层向外走，每个候选都抓页面读 byline 核对归属，对得上才登记。实测首批 10 个候选 10/10 命中；竞品 EZRUN / THE GYM PEOPLE / BMJL 等被正确挡掉。候选与结论写进 catalog_expand 表，可断点续跑、不重复请求。

collect_brand.known_asins 只从 snapshots（Top-100 榜单）取 ASIN，所以旗舰店/图遍历发现的商品会被登记进目录，却永远不会进入详情采集队列——等于编了目录没编内容。已拆成 list_asins（只看榜单）与 known_asins（合并 brand_discovery），日志也改成分别报两个数。

扩量进 loop_improve（每轮最多 2 个重点品牌、每品牌 60 个预算），让目录在无人干预下持续变大；/intel 新增「商品目录覆盖」卡，把榜单内/已登记/已有详情/待补详情/已核对候选五个数直接摆出来，进度可核对。

用户要求新板块，推荐 CRZ YOGA 该开发的款式，款式数据自己去网上找。先实测 20 个平台源，确认哪些真的拿得到（搜索端点 /s?k= 恒定 503 已确认；Pinterest Trends、TikTok Creative Center、AliExpress、Gymshark、Vuori、Beyond Yoga、Alo、Shein、Bing Shopping 可用；lululemon/Reddit/Etsy/Google Trends 被拦）。建 tracker/style_lexicon.py（6 维度 60+ 款式属性词表）、tracker/sources.js（多平台采集）、bin/collect_trends.py（入库）、tracker/new_styles.py（缺口分析 + 开发建议）、/newstyles 页面。

同一个商品在 products（详情采集）和 snapshots（榜单采集）各存一份标题，榜单那份常带「| 营销后缀」，变体商品还附 28"/30"/32"。不归一化的话，自家分母从 19 被灌到 32，「普及率」被系统性低估，会把其实已经有的款式判成缺口，直接导致重复开版。已加标题归一化（切掉 | 后缀、去长度数字、去标点小写）。修后如实发现：CRZ YOGA 其实有一款 Softretch 宽腿裤，相关建议已改成「补功能」而非「从零开版」。

亚马逊 /gp/new-releases/fashion/<node>/ 实测返回 200（与 /s?k= 不同路径），每类目 50 个「新上架且卖得动」的商品，带真实名次/价格/评论数，是判断什么款式正在起量最硬的证据。已接 run_daily.sh（每日）与 loop_improve.py（3 小时，只跑竞品官网那部分）。趋势变化检测已就位：两个时点后会开始输出「正在变多的款式」，用来领先市场而不是追已经做出来的结果。

品牌补采 60 个 + 品牌深潜 2 个品牌/40 个详情 + 完整性抽检 + 自我改进 + 情报留痕

用户要求数据源要非常广。写了 bin/probe_broad.js 真浏览器实测 66 个平台，只有 35 个拿得到（lululemon 的 HTTP2 握手直接断连、Reddit/Etsy/ASOS/H&M/Zara/Uniqlo/Macy/eBay/Adidas 是 403、Google Trends 429、Under Armour 418）。可用源覆盖 5 类：工厂批发 3 个（Made-in-China/FashionGo/AliExpress）、社媒搜索 4 个（Pinterest Trends/TikTok Creative/YouTube/小红书）、竞品官网 14 家（Gymshark/Vuori/Beyond Yoga/Alo/Athleta/Sweaty Betty/Outdoor Voices/Girlfriend Collective/Tala/Halara/Skims/Varley/Nike/Puma）、零售 6 个（Bing Shopping/Shein/Temu/Walmart/Target/Old Navy）、时尚媒体 7 个（Who What Wear/Vogue/Harper Bazaar/Refinery29/PopSugar/WWD/Highsnobiety）。全部接进 tracker/sources.js，并支持分组：3 小时循环只跑快信号组（工厂+社媒），每日跑全量。

Temu/Walmart/Target/Shein 的商品全在前端异步加载，滚动到底 DOM 里也没有：Walmart 只有 11 个 alt、Target 的 __NEXT_DATA__ 里全是类目不是商品，通用 DOM 抽取抽到 0 条。改为监听网络响应、从 JSON 响应体里捞「像服装商品名的字符串」。第一版关键词太松（top 命中了 CSS 的 top:0），抓回 57 条全是 JS/CSS 垃圾；加结构过滤（代码里必有 { } ( ) ; = : 等符号）+ 日志词黑名单后，离线验证：垃圾挡 4/5、真商品名收 5/5。修后 Shein 18、Target 20、Old Navy 24、Walmart 10 条，这些源从「采到页面但零数据」变成可用。

有了 30 个源之后，sources 字段从「竞品里有几个品牌提到」改成「多少个独立平台提到」——这是广域采样真正的价值：单平台词频可能只是它的选品偏好，多平台同时出现才是市场信号。同时发现排序错误：原来按来源数排序，导致「紧身裤」「高腰」这些最普及、也恰恰是 CRZ YOGA 已经做透的品类排在最前面，把真空白挤下去。改成按缺口强度排序、来源数只作次级排序；并加了单源噪音过滤（只被一个平台提到的属性不进缺口表）。

用户报的 bug。原因：图链到了本站 /product/<ASIN>，但新品榜的 ASIN 只存在于 new_releases 表，没进 products/snapshots（那两张表只收做过详情采集的商品），所以点进去一律显示「没有这个商品」。改为图直接指向 https://www.amazon.com/dp/<ASIN> 并加 target=_blank，新标签页打开亚马逊原商品页；只有本地确实有详情的商品才额外给「本站数据」小链接（本地有历史价格与名次曲线，亚马逊页面上看不到）。真浏览器实测：点击后标签数 1→2，新标签 URL 为 amazon.com/dp/...，标题为真实商品名 COPYLEAF Flared Leggings。

参考款图只是症状，同类链接在品牌情报、品牌报告等多处都有，而目录扩量后库里出现大量只有列表信息的 ASIN（CRZ YOGA 18→300+，外加新品榜 799 个），逐个审计调用点不现实，所以直接改 view_product：没有详情时改为显示「我们知道的一切」（标题/品牌/类目/名次/价格/评分/数据日期）+ 数据来源 + 亚马逊原页链接，并明确写出「还没有做过详情采集」——用户必须能分清「商品不存在」和「我们还没采它」，这两件事含义完全不同。同时新增 bin/check_links.py 全站死链审计，爬 14 个页面共 364 个内部链接，现在 0 死链。

1) fallback 里查 new_releases 时多写了 brand 列（该表没有这一列），SQL 直接报错，却被外层 except sqlite3.Error 吞掉，导致 fallback 静默失效、页面仍旧显示「没有这个商品」——修完第一次验证才发现。2) 新写的死链审计第一版用纯文本匹配「没有这个商品」，结果把 /newstyles 自己说明文案里的这几个字报成死链（误报）。两处都已修正：列名改正；审计改为只匹配页面级标记 <h1>没有这个商品。

看门狗巡检发现自主循环异常。这类问题不会让页面报错、也不会产生任何日志条目，只能靠主动巡检发现，否则表现就是「开发日志长时间空白」。

用户看开发日志问「你已经很长时间没有干活了」。查证属实：18:00 那轮 3 小时循环跑到 `node tracker/sources.js` 时抛 FileNotFoundError——cron 的 PATH 是 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin，而 node 装在 /home/ubuntu/.local/node/bin。run() 只捕了 TimeoutExpired、没捕 OSError，异常直接冒到顶层把整轮弄死，后面 5 个步骤（趋势入库/死链审计/情报留痕/记账/心跳）全部跳过；又因为崩在记账之前，开发日志里一条记录都没有。这比崩溃本身更严重：系统对自己的失败保持沉默，只能靠人翻日志发现。

按重要性排序：1) 失败必须可见——每个步骤失败都登记，循环结束写进开发日志（有失败就记「N 个步骤失败」并列出是哪几步）；2) run() 捕获 OSError，缺可执行文件只算「这一步失败」，不再弄死整轮；3) PATH 自举——脚本自己找 node（含 nvm 路径），不依赖 cron/systemd/手工的 PATH，已在模拟 cron 环境下验证通过；4) 顶层兜底——连 main 都崩了也写一条「循环崩溃」进开发日志。另外心跳增加 started_at 与 finished：只看「上次完成时间」分不清「没跑」和「跑一半崩了」，这两种情况含义完全不同。

看门狗原来只检查「今天的每日快照有没有生成」，完全不看循环心跳，所以对这次崩溃毫无反应。现在同时查循环：超过 4 小时没完成、或「开始了但没标记完成」（跑一半崩了）、或有失败步骤，都会报警并写进开发日志，三种情况分开表述。另外在开发日志页顶部加了「系统健康」卡，直接列出每项自动化的期望周期、上次成功时间与状态，超期标红——用户不该靠翻日志去猜「是系统停了还是我没干活」。

品牌补采 60 个 + 品牌深潜 2 个品牌/40 个详情 + 完整性抽检 + 自我改进 + 情报留痕 + 多平台采集 + 死链审计

原来 63 条建议按证据强度平铺，看完不知道先做哪条——全都重要等于全都不重要。第一版分层阈值（6/4/2）是拍脑袋定的，结果 P0 一条都没有：因为广度只看「新增属性」，而它天然是小众词，实测分布只有 2/3/4。按真实分布重定为 4/3/2。更关键的是把两个不同的问题拆开了：广度=改动被多少平台验证（可信度），体量=市场已有多少同类（拥挤度）。「广度4+体量6」与「广度4+体量151」含义完全相反——前者多平台在讲、市场还没起来（早期机会），后者所有人都已进场（红海）。混在一起排会把两者当成同一件事。现在标成 P0优先/P1本季/P2计划，并单列「早期机会/正在起量/已进红海」。

在模拟 cron 的 PATH 下重跑自主循环，从 19:59:50 跑到 20:26:42 完整结束，心跳 failures=[]、ok=true、finished=true。关键验证点：sources.js 这个之前崩掉的步骤在 20:24:01 正常执行，多平台趋势源从 30 个涨到 34 个平台。死链审计同步接入循环，本轮检查 369 个内部链接、0 死链。

品牌补采 60 个 + 品牌深潜 2 个品牌/40 个详情 + 完整性抽检 + 自我改进 + 情报留痕 + 多平台采集 + 死链审计