竞见开发复盘：淘宝竞品报告从采集到继续追问

Wed, 26 Aug 2026 04:34:00 +0800

做淘宝竞品报告，资料本身并不难搜。麻烦的是把品牌、商品图、价格和来源一一对应：登录失效或遇到验证码时，任务要能停住；重新启动后，还得接着上一次的进度。报告做完后，我也希望后面的提问还能用到这次研究。

为此，我把竞见拆成两段：先完成一份有证据的报告，再把报告收进本地知识库，供后续检索和追问。

工作台界面使用脱敏演示数据；成果截图来自一次公开品牌研究示例，不含账号或客户信息。淘宝、模型和搜索服务需要在实际运行环境中连接。

先看最后生成的报告

任务完成后，用户可以下载一份能直接用 PowerPoint 打开的 PPTX。下面截取了同一份 31 页示例报告中的三个位置：开头交代研究对象和对标结论，中段保留商品样本与图片来源，后半段再把采集结果整理成包装观察和设计启发。

第 1～2 页：封面说明研究对象与采集范围，下一页先给出行业、竞争和品牌发展三个层面的对标结论。

第 5～6 页：罗技的电商视觉样本、原图入口、产品架构和价格层级。点击图片可查看大图。

第 18～19 页：雷柏的淘宝截图分析，以及达尔优的品牌概况。这里能看到包装视觉、货架观察和设计启发是怎样落进报告的。

这份报告还包括品牌概览、核心视觉、商品矩阵、跨品牌比较和来源索引。PPTX 用于汇报，HTML 用于浏览器预览，结构化 JSON 保存最终报告数据，供知识库同步和历史报告问答使用；任务恢复依赖单独的检查点文件。

一次调研会经过什么

一次调研从“研究简报”开始。用户可以填写调研主题、品类、目标市场、价格范围和重点关注，再选择快速、标准、深度或自定义样本规模。快速、标准和深度模式分别预设品牌数与每个品牌的商品数，手动调整后会转为自定义模式。

快速、标准和深度模式主要改变品牌数和商品样本量。

提交前，页面先检查内容分析服务、淘宝登录态和采集程序；请求到达后端后，再检查本地浏览器和登录资料。每次创建请求都有唯一标识，重复点击或网络重试会复用原任务。

提交后，系统大致按下面的顺序运行：

理解品类，整理研究边界和搜索关键词。
搜索并核验品牌，排除与目标品类无关的候选。
分品牌收集公开资料，整理定位、产品线、价格带和包装特点。
通过淘宝采集商品图、价格、规格和销量线索。
汇总跨品牌差异，形成市场判断和设计建议。
生成报告并检查内容、图片和版面。
交付一份 PPTX，同时保留 HTML 预览和结构化 JSON。

我把流程拆成这些步骤，是为了让每一步都能单独保存和检查。某个环节失败时，只重跑这一段，不必把前面的搜索和整理再做一遍。

淘宝采集：自动搜索，人工处理验证

公开网页用来了解品牌，商品图、价格和规格则尽量取自同一张真实商品卡。开启淘宝采集后，竞见会为报告中的每个商品位置创建采集任务。当前使用 ShadowBot 时，后台采集程序会控制一个已经登录的 Chrome，完成搜索、筛选和截图。

标题、价格、规格、销量线索、图片和商品链接会被记录在同一条证据里，避免从不同页面拼出一个并不存在的商品。已经采集成功的内容可以复用，只有失败或缺失的位置需要重新处理。

淘宝登录过期或出现验证码时，系统不会尝试绕过验证。任务会暂停，用户在远程浏览器画面中完成登录或验证；后台检测到淘宝会话恢复后，再从原来的阶段继续。

如果开启淘宝采集后仍找不到一张可用商品图，任务会直接失败，普通网络图片不会被拿来填空。

任务中断后，怎么接着跑

一次调研会连续调用搜索、模型、浏览器和渲染程序，不能依赖一条网页请求跑到底。竞见会把任务状态写进本地进度文件；刷新或关闭工作台页面不会丢掉任务记录，回来后仍能查看进度或继续处理。

系统会在几个关键位置存档，例如品类理解完成、品牌核验完成、单个品牌研究完成和淘宝采集完成。恢复时先确认存档属于同一份请求：匹配就跳过已经完成的部分，存档损坏或不匹配则从安全位置重新执行。

界面会把运行、等待人工操作、中断、取消和失败分开显示。看到这些状态时，我能判断任务卡在哪一步、还能不能继续，以及下一步需要程序还是人来处理。

我主要用运行中心确认任务卡在哪一步，以及模型、浏览器和采集程序是否就绪。

重新派发淘宝采集前，系统会先等上一轮采集释放任务锁，再使用新的采集编号。这样上一轮迟到的结果不会写进当前报告。

报告怎么生成，又怎么过质检

研究结果最终会整理成同一份结构化数据。系统先用它生成分页 HTML，再按固定的幻灯片尺寸逐页渲染成 PPTX。这样网页预览和演示稿来自同一套排版，不容易出现“网页是一版，PPT 又是另一版”的问题。

每个任务只输出一份正式 PPTX，同时保留同内容的 HTML 预览和内部使用的 report-data.json；当前不生成 PDF。PPT 中的来源链接可以点击，但每页主体是一张整页渲染图，不能像普通文本框那样逐段编辑。我优先保证了版式稳定和便于分发，代价是后期修改不够灵活。

交付前最多检查、修复三轮：

内容检查：品牌数量、字段和来源是否齐全，文案有没有重复或跑错品类。
图片检查：文件能否打开，是否混入二维码、登录页、重复图或无关图片。
版面检查：逐页查找越界、重叠和商品卡溢出。

如果问题能定位到某一张商品图，系统只补采这一格，再重新渲染。三轮之后仍有影响交付的问题，任务就以失败结束，界面不会把半成品显示为“已完成”。

做到这里，一次调研已经可以交付。接下来解决的是另一件事：这份报告以后怎么继续用。

已完成的报告，怎么变成知识库

完成的报告不会立刻出现在知识库里。打开知识页时，系统会同步新报告，把调研概况、品牌、商品、市场判断和设计建议拆成较小的知识块。提问时只取相关内容，不必把整份报告都塞给模型。

一条品牌知识块的可读版

下面节选自一份实际生成的卫龙报告。数据库里的 content 是连续文本；为便于阅读，我补了换行并删掉部分较长字段，所以这里不是逐字转储。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


section:
 品牌 · 卫龙

content（节选）:
 品牌：卫龙
 品类：辣条；小面筋；
 大面筋；大刀辣条
 定位：以香辣配置、面筋口感
 和便携零食为核心的
 主流辣条品牌
 用户：偏好香辣、筋道口感
 及怀旧零食的消费者
 主色：红；金
 产品架构：小面筋系列；
 大面筋系列；
 大刀辣条系列；
 香辣味产品
 包装策略：稳定品牌区与背书……
 角色或插画资产……
 系列色和型号色……
 货架观察：大小面筋名称清楚；
 香辣味型号突出；
 覆盖单袋与多袋组合
 设计洞察：突出面筋和辣味；
 放大系列名称；
 建立规格层级
 机会：强化规格分层与型号识别
 价格带：低位 ¥3.5；
 中位 ¥4.1；
 高位 ¥12.09

metadata:
 {"brand": "卫龙",
 "kind": "brand"}

我给每个知识块保留三类信息：section 用于显示章节名，content 参与检索，metadata 记录品牌和资料类型。空字段直接略过；品牌、商品、洞察和建议分别建块。品牌块还会保留来源列表中第一条格式正确的网址，方便之后回到原页面核对。

回答旁边保留报告入口和原始来源，方便继续核对。

提问时，系统怎样找到证据

这里说的 RAG，就是先从报告找证据，再让模型回答。一次提问会经过下面几步：

同步并切块。 报告内容或向量配置变化时，系统会重建这份报告的索引；没有变化就继续复用。报告被删除后，相应索引也会清理。外部向量服务若在同步时失败，旧索引保持不动。
查找候选证据。 每个知识块同时进入关键词索引和相似度向量。以“卫龙包装怎么区分系列”为例，关键词检索会直接命中“卫龙、包装、系列”；外部语义向量还能找出措辞不同但意思接近的内容，本地向量则更偏向文字特征。外部向量服务临时故障，或查询向量的格式与现有索引不兼容时，系统就只做关键词检索。
合并和再次排序。 系统先合并两路结果。还可以让模型再排一次顺序，但这个选项默认关闭；即使精排失败，也会沿用原来的混合检索结果。
组装回答上下文。 排在前面的知识块会标为 [S1]、[S2]，再和会话上下文、本次问题一起交给回答模型。没有找到报告证据时，系统直接说明证据不足，不只凭聊天记忆作答。
核对引用。 流式文字会先显示，回答结束后服务端再检查每个 [S#] 是否来自本次候选列表。引用不存在的编号会让这次回答失败。这个检查只能阻止伪造来源编号，不能自动证明每句话都正确；提问者仍可从来源面板打开报告和原始链接。

像“现在一共有多少份报告”这样的全库问题会直接查询数据库。普通检索只返回最相关的几块内容，不能用来统计报告总数。

长对话怎样保留早期约束

只带最近几轮，早期约束容易丢；带上全部历史，提示词又会迅速变长。我最后把上下文分成四层：

滚动摘要：把较早讨论里的目标、约束、决定和未解决问题压成一份长期笔记。
相关旧对话：按词面重合和本地特征向量，找回最多两组与当前问题相关的历史问答。
衔接对话：保留尚未进入摘要的最近内容，避免两次摘要更新之间出现空档。
最近对话：直接带上最近四组完成问答，尽量保留原话。

原始聊天记录不会因为生成摘要而被删除。摘要单独保存，并记录“已经整理到哪一条消息”，避免较旧的摘要覆盖较新的记忆。摘要失败或超时时，系统仍会用已有上下文回答当前问题。

我只把会话记忆当作沟通线索：它告诉模型前面讨论到了哪里，却不能充当报告来源。摘要里即使出现了某个结论，本轮没有找到报告证据，系统也不会把它当成事实。

这里有个会直接影响提问方式的限制：历史内容只参与回答，不会自动补全本次搜索词。因此用户问“那它的包装呢？”时，如果“它”指的是上一轮的品牌，检索阶段仍可能不知道具体指谁。更稳妥的问法还是把品牌名写出来。

生成摘要会多调用一次模型，最慢可能让回答多等约 15 秒；被整理的旧聊天还会发送给模型供应商。现在系统只检查摘要是否为空、是否过长，不会核对其中的事实。我因此只把它当作上下文提示，不当作来源。

实现上怎么分工

技术	在项目里解决什么问题
React + TypeScript	管理工作台各页面的状态和流式回答。
FastAPI + asyncio	运行长任务、模型调用、报告接口和人工验证。
Playwright + Chrome	操作淘宝页面、提供人工验证画面，并把 HTML 渲染成幻灯片。
JSON + SQLite	JSON 保存单机任务进度，SQLite 保存知识索引和会话。
HTML + PPTX	让网页预览和正式演示稿共用一套视觉来源。

任务状态需要频繁落盘，出错时也要方便人工查看，所以我选择 JSON；知识块和会话需要检索、关联和删除，放在 SQLite 更合适。

目前的使用边界

目前竞见按本地工作站设计，适合个人或小团队使用。多租户和分布式队列都还没做。淘宝采集依赖 Windows 可交互桌面、Chrome、有效登录态和人工验证，网页结构或平台风控变化仍会影响成功率。

长对话召回目前会在单个会话内逐条扫描。会话积累得很长后，这部分还需要专门的检索索引。

我现有的自动化测试覆盖了任务恢复、文件结构、提示词分层、摘要失败降级和页面布局。真实模型、真实搜索、真实淘宝账号和最终报告仍需要人工跑一遍小任务验收。

做完这版以后，我关注的重点已经变成任务中断后能不能接着跑、图片和价格是否来自同一件商品、结论能不能回到出处。后面继续加功能，也会先守住这些基础。

SQLite on 404_@林达