购买决策对比调研

把"想买 X，纠结这几款"变成一份能直接做决定的对比表：核心关注点一眼可比，参数党信息有处可查，价格和图片有据可依。

产出统一为 一份 xlsx（行=对比维度，列=候选商品），三层分色，链接可点，商品图嵌入。

一、目录约定（强制）

按领域分文件夹，一领域一目录（穿搭调研/、家电调研/、数码调研/…），目录内只允许：

• 对比_YYYYMMDD_品类.xlsx —— 成品（如 对比_20261017_扫地机器人.xlsx）
• XX对比模板.csv —— 该领域的空白模板，仅作复制源
• 商品图片/ —— 引用的商品图
• 使用说明.md —— 目录说明，新增后同步清单

禁止把填充数据的 CSV 留在主目录：一律写入隐藏工作目录 .对比_YYYYMMDD_品类.ref/（放 spec、build 脚本、中间 CSV）。不要问用户"要不要删"，按约定执行。

多维度调研（组合数 ≥ 4，见 §二 Step 0）时，工作目录内再加两个子目录：

• .ref/raw/ —— 主 agent 在分派前批量抓好的原始素材（搜索页截图、DOM 快照、价格清单）。sub-agent 只读不重抓。
• .ref/parts/ —— 各 sub-agent 交回的结构化数据（<sheet名>.json），主 agent 合并后统一出表。

二、执行流程

Step 0 需求对齐（一次问完，把「调研方式」也塞进同一次交互）

用一次 AskUserQuestion（≤4 问）问清：使用场景、预算、硬约束（2-3 问），第 4 问固定是「调研方式」——不额外增加交互轮次：

价位档必须问进问题里，不能只在正文里自己宣布。 档位（做几档、每档上下限）一改，整份表的列结构、候选池、分片数全变；用户答完第 4 问就默认「方案已定」，你再自行缩档等于替他做决定。规则：

• 档位候选写进 AskUserQuestion（如「3 档够 / 要 4 档 / 你定」），或在正文宣布后明确说「档位按这个来，要改说一声」；
• 档位定下后写进 .ref/brief.md，后续以 brief 为准；

• 中途因数据不足想改档 → 回头问用户，不许默默把某档删掉或并档。

• 我自己做（省 token，覆盖度中等，适合组合数 ≤3）

• 派 N 个并行（N 按下面的表给建议，速度快、每格款式更多）
• 你帮我判断（默认按表推荐）

先算组合数 = 维度A × 维度B（例：3 个价位 × 3 种鞋型 = 9），再按下表给建议：

还有一个更硬的判据——目标款数：用户要求「每张表 5-6 款」时，单线程基本做不到。9 张表 × 6 款 × 12 行 ≈ 650 个单元格，主 agent 写到第 5 张上下文就开始降级（表现：图片没抓、价格标"待核"、候选被偷偷砍掉）。这种情况下不是"要不要分片"，是必须分片——分片真正的价值在这里，不在"快"。

切分铁律：哪一维的候选「需要互相横向比较」，那一维就不能拆。

• 案例·秋冬鞋（3 价位 × 3 鞋型 = 9）：同价位内"买跑鞋还是板鞋"要横向比 → 价位是不可拆维，按价位切 3 片（每片负责该价位全部 3 种鞋型）。
• 案例·折叠雨伞（2 类型 × 3 价位 = 6）：手动 vs 自动结构不同、不需要互相比 → 类型是可拆维，按类型切 2 片（每片负责该类型全部价位）。
• 反例：秋冬鞋的 9 个格子各派 1 个 agent —— 每片只剩 3 款，探路成本重复 9 次，汇总时字段口径还容易漂。用户提出"每个组合派一个"时，直接把这条反例摆出来。

成本要说清：每个 sub-agent 要重复加载本 skill、重复踩取数坑，token 约 +50%~150%；换来的是每格款式数从 3 提到 6-8、待补项大幅减少、且不会因上下文超长而中途降级。把这句话在 Step 0 直接说给用户。

Step 1 锁定"用在哪"

先明确使用场景和预算（家庭人数/房间面积/使用频率/谁在用），再谈参数。没有场景的参数对比没有意义——同一款扫地机，养宠家庭和小户型关注点完全不同。

用户没说清时，用最可能的场景假设并标注，不要停下来反复追问。

Step 2 调研该品类的"大众关注点"（关键差异所在）

不同品类关注点差异极大，不要套用上一个品类的维度。用 WebSearch 调研，搜索词模板：

• <品类> 选购 关注点、<品类> 怎么选 避坑
• <品类> 消协 比较试验、<品类> 实测 横评
• <品类> 参数 智商税、<品类> 哪些参数重要

取信顺序：消协/质检机构实测 > 专业评测媒体 > 电商详情页宣传。

判据（把调研结果压成 5-8 个核心维度）：

1. 是否直接影响日常体验（洗净比、噪音、避障）→ 核心
2. 是否可验证（有检测值/实测数据）→ 核心；纯营销词（"全空间保鲜""AI 智洗"）→ 进阶或剔除
3. 是否存在"过了某阈值就边际递减"（如吸力 >15000Pa）→ 写进维度说明，避免用户为数字多付钱
4. 同价位段是否有决定性差异（双系统 vs 单系统防串味）→ 核心

已调研品类的关注点见 references/appliance-dimensions.md（冰箱/洗衣机/扫地机器人），可作为写法样例，也可直接复用其中维度。

Step 3 探路 + 预取素材（这一步决定后面每张表厚不厚）

分片之前必须先把"怎么取数"试通，否则每个 sub-agent 各踩一遍坑，成本翻倍。

• 短链解析：京东 3.cn → curl -s -o /dev/null -w "%{redirect_url}" 取 skuId；淘宝 e.tb.cn 需登录，抓不到就让用户给截图。
• 价格与图片接口常被挡（2026-10 实测：p.3.cn / item-soa.jd.com 返回 302 或连不通；search.jd.com curl 302）。有效降级路径见 references/footwear-dimensions.md §五：浏览器打开带 ev=exprice_X-Y 的价格筛选页 → 截图读「标题+标价+到手价」→ DOM 取 pid/imgUrl → 主图 img14.360buyimg.com/n1/<jfs> 直接 curl 下载。
• 探路产物写成一份 brief（取数路径 + 关键词清单 + 价格口径 + 已验证可用的 URL 模板），落 .ref/brief.md，后面每个 sub-agent 直接复用。

抓取顺序铁律：先抓用户主档（他最想买的那个价位），再抓左右的配角档。 限流、反爬、时间超时都是「后面的请求先死」，而主档数据最薄是用户唯一会立刻发现的缺陷。按价位从低到高顺着扫是本能，但等于把最贵的一档押在最后。

素材量下限（「表只有 3-4 款」的根因就在这里）：

• 每张子表的候选池 ≥ 目标款数 × 3。想要 5-6 款，入手就得先捞 15-20 个候选，再筛。
• 做不到的常见原因：用一个大关键词（如"加绒鞋 男"）搜完再按子类型拆——拆完每类只剩 3-4 款。正确做法是每个子类型单独搜一轮（"加绒跑鞋 男" / "加绒板鞋 男" / "低帮徒步鞋 男"各一页），或每片至少翻到第 2 页。
• 浏览器是独占资源：多个 sub-agent 共用一个 Chrome 会互相抢标签页。所以素材要么在分派前由主 agent 串行抓完（落 .ref/raw/），要么走 Step 4 的 C 串行模式。

Step 4 采集（三种执行方式，按 Step 0 定的方式走）

A 单线程（组合数 ≤3，或用户选"我自己做"）：主 agent 逐个组合采。

B 素材前置 + 并行（默认推荐，组合数 ≥4）：主 agent 按 Step 3 把每片素材抓齐 → 并行派 N 个 sub-agent，各片只做「从素材里筛款 + WebSearch 补参数 + 写 JSON」。

C 串行派遣（某片需交互式探索、看页面才知道下一步搜什么时用）：一个 sub-agent 收工再派下一个；它可自由开浏览器，不受预取素材限制。代价是速度不升、token 照涨，好处是每片上下文独立且能自由挖。

冲突边界要说准：只有浏览器导航/截图会冲突；WebSearch、读本地素材、curl 下载图片都不冲突。所以 B 天然安全，C 也不会打架。

分片模式下每个 sub-agent 拿到：
1. 自包含的 brief（用户画像 + 场景 + 该分片的范围 + .ref/brief.md 的取数路径 + .ref/raw/ 素材路径）；
2. 严格的输出约定：写 .ref/parts/<sheet名>.json，字段名与顺序固定，不许自己生成 xlsx（避免格式漂移）；
3. 数量要求：每张子表 目标 5-6 款，下限 4 款；候选不够就显式说明"该细分只有 N 款"，价格/参数拿不到标 "待核"/"待补"，不许臆造。
完整 prompt 模板与 JSON schema 见 references/subagent-brief.md。

两种模式共用的采集口径：

• 必查：核心参数、型号全称、实付价（到手价）、促销条件。
• 价格以用户截图或当前页面为准；活动价标注"会波动"；不要用"同类参考价"估。
• 注意标价陷阱：电商价格筛选按标价、不按到手价，标价通常高 30-50%，分档必须读到手价（详见鞋类 reference）。

Step 5 抓商品图

京东商品页（item.jd.com / cd.jd.com / wq.jd.com）全部 302 反爬，别反复重试；降级路径是从什么值得买移动版百科页抓 zdmimg 图片直链下载。若本地装有用户级技能 ecom-product-image，可优先走它的 playbook。

• 存 商品图片/，命名 款N_品牌型号_序号.jpg。
• 下载后必须 Read 看图验证确实是该型号，再嵌入。抓不到写"待补"，不拿近似款凑数。
• 批量核图用「联系表」而不是逐张 Read：图片多于 6 张时，先用 PIL 拼一张带 skuId 标注的网格图（6 列、每格 220px），Read 一次就能同时确认「是不是这个型号」「有没有贴错列」，比逐张打开省 80-90% 的看图开销。逐张 Read 只在联系表里某格看不清时才做。
• 无法目视验证时的降级校验（模型不支持读图 / 图片打不开）：电商详情页图常是"满版拼贴图"，嵌进表里用户看不清实物。用 PIL 做两项客观检测替掉肉眼：
  1. 按页面原始顺序取图（grep 后不要 sort -u，排序会打乱主图位置，主图通常在最前几张）；
  2. 白底检测：取四角+四边中点共 8 个采样点，全部 >232 视为白底；再算非白像素「主体占比」，0.08-0.75 为白底实物图，>0.9 基本是满版详情/拼贴图，弃用改标"待补"。
• 参考 scripts/pick_main_image.py（下载+校验一体：输入 URL 清单或本地目录，按序编号，输出每张图 PASS/REJECT/REVIEW 判定与 verdicts.json）。当前模型支持 Read 看图时，REVIEW 档再用目视确认是「白底商品图」还是「场景实拍图」，两者都可用，后者在报告里注明。

Step 6 生成与校验

分片模式下先合并校验再出表：逐份读 .ref/parts/*.json，检查①字段是否齐全、②价格口径是否统一（到手价 vs 标价混用是高频错）、③有没有编造的参数（拿不准的应写"待核"）、④每张子表款数是否达标。不达标的打回该片重做，不要自己顺手补——补出来的就是臆造。

python scripts/build_comparison.py spec.json

spec 见 references/spec_example.md。脚本自动完成三层配色、URL 超链接、图片行嵌图、冻结窗格、说明 sheet，CSV 落 .ref/。

必须跑一遍后处理（否则长文本会被行高截断、URL 断行、商品图偏小）：

python scripts/fix_layout.py "<out_dir>/<stem>.xlsx"

做四件事：正文行高按字数自适应、超链接显示文本缩成 host/path（target 不变仍可点）、商品图放大到 168px、说明页加宽换行避免打印断页。幂等，重复跑无害。

每份表都要带「参数小抄」sheet（spec 的 glossary 字段）：把表里出现的生僻参数逐条写成「参数 / 一句话解释 / 怎么判断（参考值·常见坑）」。常用词条见 references/parameter-glossary.md，按品类取用并补当季数据。

校验：图片是否落在对应列、链接是否可点、表头是否截断、评分列是否留空、参数小抄是否覆盖了表内所有生僻参数。
scripts/verify_xlsx.py 可程序化跑前四项，但视觉层（表头是否被行高截断、图片是否互相遮挡）程序查不出来，必须至少渲染一页看一眼。

数据源被封 / 某档拿不到货时的降级规则（2026-10-22 补，踩过）：

1. 单表「待核」上限 2 款，且必须在 price 里写明来源（「官方价·待核」/「媒体参考价·待核」），不许把参考价写成到手价；
2. 必须在 sheet 的 notes 顶部声明原因和缺口（哪几款没图、为什么、怎么自查），不许静默留白；
3. 某档实测款 < 4 款时，不许硬凑：要么明说「该档在售极少，只查到 N 款」，要么把档位改成市场真实存在的分段（如「¥300-400 预算档」而不是「到手 ¥300-400 档」），并在 notes 里讲清重新分档的理由；
4. 优先补齐主档：宁肯配角档只有 4 款，也要保证主档每款都有价有图；
5. 全部降级动作都要在收尾时回写 memory，下次同类调研先避坑。

Step 7 收尾

同步 使用说明.md 文件清单 + 追加 .workbuddy/memory/YYYY-MM-DD.md。分片模式再记一句：本次派了几个、按什么维度切、哪个片返工过——下次同类调研直接照抄切法。

三、三层维度（通用）

分类名不必逐字一致：脚本按关键词识别——含"溯源/参考"→绿；含"进阶/参数/加分"→灰；其余（基础体感/核心关注/核心体验）→黄。

四、写作口径（风格统一）

• 「结论 + 原因」：写"干得最快，疏水导汗结构"，不写"好/差"。
• 场景化：写清"什么条件下适合"，如"10℃ 通勤、出汗少""120㎡ 以内、无宠物"。
• 新手视角：核心层是主角；进阶层明确"了解即可"，不堆商家话术。
• 边际递减要点破：如"吸力超 15000Pa 提升不足 3%、功耗 +27%"，帮用户省钱。
• 同源产品要点破：两款几乎同配置时，写清差异只在版本/渠道/赠品。
• 不臆造：拿不到的参数写"未标注/待验证"。
• 参数必须带参照系：小白看不懂"洗净比 1.36""APF 5.0""dToF"这类值，写结论时要加括号释义与好坏区间，如"洗净比 1.08（国标一级 1.03，家用 1.1+ 即优秀）"；表内出现的每个生僻参数都要收进「参数小抄」。
• 只科普影响决策的参数：不要把每个数字都解释一遍，小抄控制在 8-15 条，优先选用户会犹豫、容易被营销放大的参数。

五、品类专项参考

• 服装（面料、凉感、吸汗、排汗、保暖、透气、场景）：见 references/clothing-sop.md，含分品类维度字典与写作口径。
• 家电（冰箱、洗衣机、扫地机器人、电热水壶）：见 references/appliance-dimensions.md。
• 日用百货（折叠雨伞，含保温杯/箱包/枕头骨架）：见 references/daily-goods-dimensions.md。
• 鞋类（跑鞋、板鞋、徒步鞋、工装靴；含「透气 vs 保暖」取舍、尺码口径、京东取价路径）：见 references/footwear-dimensions.md。
• 袜子（男袜/女袜/运动袜；含三条防臭路线、棉/氨纶/锦纶黄金配比、21 行维度、京东移动版取数与 full_page 截图路径）：见 references/socks-dimensions.md。
• 分片并行（组合数 ≥4 时用）：切法判断、两阶段流程、sub-agent prompt 模板与 JSON schema、合并校验清单，见 references/subagent-brief.md。

新品类第一次调研后，把该品类的关注点补进 references/，下次直接复用。

六、常见坑

• 套用其他品类的维度（用衣服的"凉感/透气"去套冰箱）。
• 把营销词当核心维度（"全空间保鲜""AI 智洗"），真正该比的是分区/循环/洗净比。
• 用"同类参考价"代替实价；活动价不标注。
• 京东 item.jd.com / cd.jd.com / wq.jd.com 全部 302，别反复重试。
• 图片没验证就嵌入，贴错型号。
• 填充 CSV 落进主目录。
• 只列参数不给结论：用户要的是"我该买哪个"，不是参数手册。
• 按「组合」切 sub-agent（9 个格子派 9 个）：每格只剩 3 款，探路成本重复 9 次。要按"不可拆的那一维"切成 3-4 片。
• 没探路就分派：sub-agent 各自踩一遍反爬坑；且多个 agent 共用一个浏览器会抢标签页，素材必须主 agent 先抓完。
• 让 sub-agent 自己出 xlsx：每片样式各写一套，合并必返工。只交 .ref/parts/*.json。
• 上下文吃紧就私自砍候选：删掉一半候选再表，用户看不出"少了什么"。正确做法是派片，或显式告诉用户"这档只查到 3 款"。
• 把京东搜索页当无限接口连翻：连续导航 6-8 次就 IP 级封禁（搜索/列表/详情全挂，换浏览器无效，恢复约 30 分钟）。搜索之间间隔 ≥60 秒，看到"访问频繁"立刻停手去做参数检索，别边等边试探。详见 references/footwear-dimensions.md §五。
• 按「价位」开等量标价窗：ev=exprice_X-Y 按标价筛，相邻窗口重合约 60%，4 个价位开 4 个窗纯属浪费配额。先用 2 个窗覆盖大头，再按缺口补第 3 个。
• 引用截图第 7-12 款却不补 DOM：一屏 12 款里只有可视区 6 款有 pid/主图，另一半没有 skuId 和图片，进表就是"待补"。正确解法是滚动再取一次 DOM（滚动不产生新请求，不吃限流配额），不是翻页也不是重搜。
• 把补图交给「等限流恢复再跑一次定时任务」：限流恢复后重搜同样的页，拿到的还是同样那 6 个 skuId——缺的是「首行之外没取 DOM」，不是「没重试」。先诊断缺的是数据还是取数动作。
• 一屏里 3 个 tab 并行 goto：并发请求比串行更容易触发风控，而且截图会串页。宁可串行 + sleep，别并行开页。