intelligrow/cross-platform-products-ai-analyst
4
0
Fork 0
Code Issues Pull Requests Actions Packages Releases Wiki Activity
cross-platform-products-ai-.../docs/RequirementsDoc.md

22 KiB
Raw Blame History

跨平台商品聚合与 AI 分析需求文档

  • 文档状态：Draft
  • 版本：v0.4
  • 更新时间：2026-04-02
  • 参考文档：
    • docs/CrawlerFeasibility.md

1. 项目背景

品牌方或运营人员在分析某个商品时，通常需要分别打开多个电商平台，手动搜索同一商品，查看商品详情页、规格卖点、价格信息和评论区反馈，再自行做汇总与判断。该过程重复、耗时，且难以形成统一标准的数据与结论。

本项目目标是构建一个面向品牌方/运营人员的跨平台商品分析工具。用户输入商品名称后，系统自动在多个电商平台内搜索候选商品链接，由用户人工确认目标链接，再抓取商品信息和评论内容，并通过 AI 生成跨平台分析结果。

2. 产品目标

本项目 MVP 阶段的目标如下：

  1. 用户输入自然语言商品名称后，系统可分别在天猫、京东中搜索候选商品。
  2. 系统返回每个平台的多个最佳匹配结果，由用户人工确认目标商品链接。
  3. 支持同一平台确认多个商品链接，以适配同一商品在不同店铺、不同销售页中的情况。
  4. 在确认链接后，系统抓取商品页中的尽可能完整的信息，以及适量评论内容。
  5. 系统将不同平台的原始数据统一映射为标准化字段。
  6. 系统基于商品信息与评论内容，输出可供品牌方/运营使用的分析报告。

2.1 MVP 成功指标

以下指标用于判断 MVP 是否达到“可用可验证”状态，当前作为建议目标值：

  1. 搜索召回可用率：每个平台均能返回候选列表或明确返回“无结果”，不出现静默失败。
  2. 候选可确认率：在返回候选结果的平台中，用户能够确认至少一个有效商品链接。
  3. 报告完成率：存在至少一个已确认链接的任务，应能产出结构化报告；允许部分平台失败，但不应整体中断。
  4. 任务完成时长：在推荐配置下，80% 任务应在 15 分钟内完成从搜索到报告生成。
  5. 结论可回溯率：报告中的关键结论应尽量附带平台、商品链接、评论样本或抓取时间等证据指针。

2.2 基础验收标准

模块 验收标准
搜索召回 每个平台返回候选列表或明确返回“无结果”；候选项至少包含标题、价格、店铺、链接
人工确认 用户可对每个平台执行单选、多选、跳过；确认结果可回看
商品抓取 对所有确认链接抓取商品信息，并保留原始字段与标准化结果
评论抓取 按既定抽样规则抓取评论；每条评论保留来源信息和所属链接
标准化 输出统一结构，允许空值，但需保留未映射原始字段
AI 分析 报告至少包含卖点、好评点、差评点、跨平台差异，并附带来源摘要或证据指针
容错 单个平台失败不阻塞整体任务结束，最终结果中能看到失败原因
可追溯 报告中的关键结论可回溯到平台、商品链接、评论样本或抓取时间

3. 目标用户

主要目标用户：

  1. 品牌方运营
  2. 电商运营
  3. 商品研究、竞品分析相关岗位

非目标用户：

  1. 普通消费者导购场景
  2. 纯内容平台舆情分析用户

3.1 典型使用场景与报告关注点

  1. 品牌运营：重点关注卖点定位、平台差异、价格带与口碑风险。
  2. 商品运营：重点关注差评原因、SKU/履约问题、详情页与促销优化建议。
  3. 竞品研究：重点关注多店铺/多链接差异、评论结构与平台表现对比。

4. MVP 范围

4.1 输入方式

用户以自然语言输入商品名称或商品描述，系统基于该关键词在目标平台内执行搜索。

示例：

  1. iPhone 15 Pro
  2. 大疆 Pocket 3
  3. 某品牌蓝牙耳机

说明：

  1. MVP 不以用户提供单个平台商品链接作为主要输入方式。
  2. 输入的核心目的是触发各平台内部搜索，以便聚合同一商品在不同平台的结果。

4.2 覆盖平台

MVP 仅覆盖以下电商平台：

  1. 天猫
  2. 京东

暂不纳入：

  1. 淘宝，作为下一优先扩展平台
  2. 抖音电商，当前阶段延后实现
  3. 小红书、抖音内容、B 站、微博等内容平台
  4. 拼多多、Amazon 等其他电商平台

4.3 分析方式

MVP 仅支持一次性分析任务，不支持持续监控。

即：

  1. 用户发起一次商品分析任务
  2. 系统完成搜索、确认、抓取、分析、报告输出
  3. 不要求每日/每周自动更新

5. 核心用户流程

5.1 主流程

  1. 用户输入商品名称。
  2. 系统分别在天猫、京东中执行站内搜索。
  3. 系统返回每个平台的候选商品列表；若未找到，则明确提示该平台未搜到相关商品。
  4. 用户在每个平台中人工确认目标链接，允许单选、跳过或多选。
  5. 用户配置评论抓取数量上限 N（默认按单个已确认链接生效）。
  6. 系统在用户授权登录态下抓取已确认链接的商品信息与评论内容。
  7. 系统对原始数据进行清洗、标准化与聚合。
  8. 系统调用 AI 进行商品卖点、评论好评点、评论差评点等分析。
  9. 系统输出结构化分析报告。

5.2 人工确认规则

为解决“是否为同一商品”的相关度问题，MVP 不做完全自动判定，而是采用“系统召回 + 用户确认”的方式。

要求：

  1. 每个平台返回多个最佳匹配候选项。
  2. 用户可在同一平台确认多个候选链接。
  3. 若某平台未搜到合适结果，允许跳过该平台并继续分析其他平台。
  4. 若某平台存在多个被确认链接，系统需对每个链接独立抓取，并在最终报告中进行平台内聚合展示。

6. 功能需求

6.1 平台搜索与候选返回

系统需支持以下能力：

  1. 接收用户输入的商品关键词。
  2. 在天猫、京东中分别执行站内搜索。
  3. 返回每个平台的候选商品列表。
  4. 对未搜索到候选结果的平台返回明确提示。

候选商品最少应展示以下信息：

  1. 平台名称
  2. 商品标题
  3. 商品链接
  4. 商品价格
  5. 店铺名称
  6. 主图或缩略图（如可获取）
  7. 销量、热度、评分等辅助识别信息（如页面可见）

建议值：

  1. MVP 每个平台默认返回 Top 5 候选结果。
  2. 候选返回数量后续可配置。

6.2 商品链接确认

系统需支持以下交互：

  1. 用户可按平台查看候选商品。
  2. 用户可在单个平台中确认一个或多个链接。
  3. 用户可跳过某个平台。
  4. 用户确认完成后，系统仅对被确认的链接进入抓取阶段。

6.3 商品信息抓取

系统需尽可能完整抓取商品页原始信息，并保留原始数据。

优先抓取的信息包括：

  1. 商品标题
  2. 品牌
  3. 型号/系列
  4. 当前价格
  5. 促销信息
  6. 规格参数
  7. SKU/规格选项
  8. 商品主卖点描述
  9. 商品详情页文案
  10. 店铺名称
  11. 店铺类型
  12. 店铺评分或信誉信息（如可见）
  13. 商品评分（如可见）
  14. 评论总量（如可见）
  15. 销量/热度/成交人数（如可见）
  16. 商品链接
  17. 抓取时间
  18. 平台名称

说明：

  1. “尽量全抓”指尽可能保留页面可访问范围内的商品信息。
  2. 原始抓取字段允许平台间不一致。
  3. 后续统一分析时，需再映射为标准化字段。

6.4 评论抓取

评论抓取要求：

  1. 仅抓取适量评论，不要求全量抓取。
  2. 用户可配置评论抓取上限 N；MVP 默认将 N 定义为“单个已确认商品链接”的评论抽样上限。
  3. 若一个任务确认多个链接，则每个链接独立应用各自的 N，避免部分链接因共享额度而无样本。
  4. 系统应采用分层抽样，而非只抓取单一排序下的前几条评论。

分层抽样默认规则：

  1. 最新评论
  2. 最热评论
  3. 低分/差评评论
  4. 默认分配比例建议为 40% 最新 + 30% 最热 + 30% 低分/差评。
  5. 去重优先使用 review_id；若无 review_id，则使用标准化后的评论文本、评论时间、SKU 上下文和商品链接组合去重。
  6. 若平台不支持某一排序或筛选条件，则降级为平台实际可访问的近似排序，并在 sampling_bucket 中记录实际来源。
  7. 某抽样桶样本不足时，剩余额度回补到其他可访问抽样桶。

若平台能力受限，则应按平台实际可访问的评论排序或筛选条件执行。

评论至少应保留以下信息：

  1. 评论内容
  2. 评论时间
  3. 评分或情感倾向标识（如可见）
  4. 点赞数/互动数（如可见）
  5. 规格/SKU 信息（如可见）
  6. 评论来源链接或来源页面标识
  7. 抓取平台
  8. 对应商品链接

边界说明：

  1. 不保证抓取评论总量覆盖平台全量评论。
  2. “适量抓取”由用户通过 N 决定，且 N 的默认生效口径为单链接。
  3. 系统目标是为分析提供足够样本，而不是穷尽式抓取。

6.5 数据清洗与标准化

系统需将各平台原始抓取数据转换为统一结构，以支撑跨平台汇总与比较。

标准化目标包括：

  1. 将不同平台的商品信息映射为统一字段。
  2. 将不同平台的评论信息映射为统一字段。
  3. 保留无法映射的原始字段，供后续扩展或回查。
  4. 当平台字段缺失时，允许标准化字段为空。

统一后的商品标准字段建议包含：

字段 说明
platform 平台名称
source_url 商品链接
product_title 商品标题
brand 品牌
model 型号/系列
price 当前价格
promotion 促销信息
specifications 主要规格参数
sku_options SKU/规格选项
selling_points 提取后的核心卖点
shop_name 店铺名称
shop_type 店铺类型
product_rating 商品评分
review_count 评论总量
sales_volume 销量/热度
crawl_time 抓取时间

统一后的评论标准字段建议包含：

字段 说明
platform 平台名称
source_url 商品链接
review_id 评论标识，若可获取
review_time 评论时间
review_text 评论文本
review_rating 评论评分，若可获取
interaction_count 点赞/互动量
sku_context 评论对应规格
sampling_bucket 抽样来源，如最新/最热/差评
crawl_time 抓取时间

字段类型与归一规则要求：

字段 类型/单位 归一规则
source_url string 对 URL 做标准化，移除无关追踪参数，作为链接级去重主键之一
price number，人民币元 统一转换为人民币元并保留两位小数；原始展示文本保留在原始字段中
sales_volume / review_count / interaction_count integer 将“1.2万”“3k+”等展示格式转换为整数；无法解析时填 null
product_rating / review_rating number，5 分制 如平台采用百分制、星级或其他刻度，需映射到 0-5 分制，并保留原始刻度
review_time / crawl_time datetime 统一输出 ISO 8601 格式，时区按 Asia/Shanghai 解释；原始时间文本需保留
specifications / sku_options object 或 array 优先结构化；无法可靠拆解时保留原文并标记未结构化
空值字段 null 缺失、不可见、不可解析均使用 null，不得以 0 或空字符串代替

6.6 AI 分析

MVP 阶段 AI 分析重点如下：

  1. 基于商品信息提炼主要卖点。
  2. 基于评论提炼用户好评点。
  3. 基于评论提炼用户差评点。
  4. 对多平台结果进行横向对比。

AI 输出应尽量做到：

  1. 结论清晰
  2. 可用于运营决策
  3. 尽量附带来源依据

AI 输出必须遵循统一结构：

  1. 每个平台至少输出：核心卖点、主要好评点、主要差评点、样本量说明。
  2. 跨平台部分至少输出：共同卖点、差异点、潜在风险、运营建议。
  3. 每条关键结论应附带来源摘要，至少关联到平台、商品链接、评论样本或商品字段。
  4. 当证据不足或样本不足时，必须显式标注“样本不足”或“不形成明确结论”。
  5. AI 不得补造未抓取到的商品参数、评论观点或平台差异。

6.7 报告输出

最终分析报告建议至少包含以下模块：

  1. 商品基础信息汇总
  2. 各平台商品卖点提炼
  3. 评论正负面分析
  4. 跨平台差异对比
  5. 代表性评论证据
  6. 运营建议或优化建议

说明：

  1. “代表性评论证据”是重要能力，但不是首要完成优先级。
  2. 即便前端暂不完整展示证据，底层也应尽量保留评论来源与商品链接，便于后续回溯。

报告补充要求：

  1. 报告需标注各平台确认链接数、评论样本量与抓取时间。
  2. 若存在部分失败，需单独列出失败平台、失败环节与其对结论范围的影响。

6.8 多链接聚合逻辑

当同一平台确认多个链接时，系统需支持以下逻辑：

  1. 每个被确认链接均独立抓取、标准化并保留链接级结果。
  2. 平台级结果需先在同平台内完成评论去重与字段汇总，再输出平台层摘要。
  3. 跨平台比较时，仅使用平台层摘要进入横向比较，避免同平台多链接被重复放大权重。
  4. 商品链接去重以标准化后的 source_url 为准，仅清理重复确认的同一页面；不同店铺或不同销售页链接不自动合并为同一商品。
  5. 评论去重优先使用 review_id；缺失时按标准化评论文本、评论时间、SKU 上下文和标准化链接组合去重。

7. 登录态与平台访问要求

考虑到电商平台通常需要登录，且存在验证码、风控等问题，MVP 采用“用户自有账号授权登录”的模式。

7.1 平台接入模型

  1. MVP 不采用“纯浏览器默认主路径”，而采用“服务端策略路由 + 会话驱动请求回放优先 + 受控浏览器旁路恢复”的平台接入模型。
  2. 当前阶段不把任何官方开放平台当作直接数据源承诺；工程路线以平台真实页面请求链路为准。
  3. 每个平台必须按 search/detail/reviews/login 四项能力分别定义默认路径、降级路径、阻塞信号和恢复动作，不能只写成“该平台可抓取”。
  4. 当前阶段的主采集路径明确为“服务端 HTTP 请求回放 + Hydration 解析”；受控浏览器只用于登录、验证码、模板刷新、风控恢复和接口发现。
  5. 每个平台使用独立会话容器，避免 Cookie/Session 串用。
  6. 用户需在系统提供的受控会话中手动完成登录、验证码或人工确认；系统仅在授权会话范围内执行搜索和抓取。
  7. MVP 默认不直接读取用户其他浏览器中的账号密码或任意 Cookie 文件；如后续支持导入登录态，必须经过单独授权并提供清理能力。
  8. 若关键动态参数无法在授权会话内通过平台页面现有上下文刷新，应直接判定为 Blocked，不把逆向私有算法作为交付前提。

7.2 当前阶段平台可行性结论

基于 docs/CrawlerFeasibility.md 的 2026-04-02 调研结果，当前阶段的暂定结论如下：

平台 当前阶段定位 暂定 search_requirement 工程默认路径 当前结论
天猫 当前 MVP 平台 recommended L0 Request Replay + L1 Hydration 搜索与评论都更适合按淘宝/天猫同构请求实现，浏览器只保留给登录和模板刷新
京东 当前 MVP 平台 required L0 Request Replay + 搜索前预检查 详情接口层可见，但搜索和详情都受会话与风控约束，必须先完成稳定的会话中心
淘宝 下一优先平台 recommended 复用天猫 mtop/h5api 适配栈 后续新增淘宝具备明显适配复用价值，但不进入当前 MVP 排期
抖音电商 当前延后 required 暂不进入当前实现 当前阶段不排期、不验收，待网页链路和成本重新验证后再评估

补充约束：

  1. 当前阶段只承诺天猫和京东的完整实现。
  2. 非浏览器主路径应尽量对齐平台真实请求形态，但不把伪造设备、逆向私有签名或绕过风控作为交付前提。
  3. 天猫与京东应先跑出可复用请求模板和稳定的 Blocked 恢复策略，再进入大规模功能开发。

7.3 账号安全与合规

  1. 系统不得采集或保存用户账号密码。
  2. 若需要复用登录态，仅允许在当前工作区的服务端会话中心加密保存 Cookie/Session，不下发明文，不跨工作区共享。
  3. 会话默认最长保留最后使用后 24 小时；用户主动退出、平台判定失效或手动清理后应立即删除对应会话。
  4. 系统异常退出后，下次启动需检测并清理过期、损坏或不可用的会话快照。
  5. 产品需向用户明确提示：仅在其授权账号、合法访问范围和平台规则允许范围内使用。

7.4 失败回退策略

  1. 支持识别登录失效、跳转登录页、验证码、风控拦截等状态。
  2. 当出现无法自动继续的情况时，系统需暂停当前平台任务并明确提示人工处理。
  3. 搜索、抓取阶段的会话失效应支持在用户恢复登录后继续执行，避免整任务重头开始。
  4. 若平台访问策略变化导致抓取失败，系统需记录失败节点、失败原因和是否可重试。

边界说明：

  1. 本项目不承诺无条件绕过所有平台风控。
  2. 本项目的目标是在授权登录态下尽可能稳定地完成搜索、抓取和分析。
  3. 若平台访问策略变化导致抓取失败，系统需可定位原因并向用户提示。

8. 非功能需求

8.1 可追溯性

系统输出的分析结果应尽量可回溯到原始来源，包括：

  1. 商品链接
  2. 平台名称
  3. 评论文本或评论来源
  4. 抓取时间

8.2 容错性

系统应允许部分平台失败或无结果，不应因单个平台异常导致整个任务失败。

例如：

  1. 某平台未搜到候选商品
  2. 某平台登录态失效
  3. 某平台评论抓取失败

上述情况不应阻断其他平台的分析结果生成。

8.3 可配置性

以下参数建议支持配置：

  1. 每个平台候选返回数量
  2. 评论抓取上限 N 及其作用域
  3. 评论抽样策略
  4. AI 分析模板或提示词版本

8.4 任务反馈与状态机

由于搜索、抓取、分析过程可能耗时较长，系统应具备任务进度反馈和可重试状态流转能力。

推荐状态至少包括：

  1. 待开始
  2. 搜索中
  3. 等待人工确认
  4. 抓取中
  5. 等待人工处理登录/验证码
  6. 分析中
  7. 已完成
  8. 部分失败
  9. 已失败
  10. 已取消

状态流转要求：

  1. 搜索中、抓取中、分析中支持有限次自动重试。
  2. 登录失效、验证码或风控拦截时，进入“等待人工处理登录/验证码”状态。
  3. 单个平台失败时，其他平台应继续执行，最终可进入“部分失败”。
  4. 最终结果需展示各平台状态、失败节点、失败原因和重试结果。

8.5 性能与成本边界

  1. MVP 推荐配置为：3 个平台、每个平台最多 2 个确认链接、单链接评论上限 N <= 100。
  2. 在上述推荐配置下，80% 任务目标在 15 分钟内完成。
  3. MVP 默认单用户同时仅运行 1 个抓取任务，避免登录态与抓取资源冲突。
  4. AI 分析应优先消费标准化摘要和抽样评论，不直接发送全量原始页面内容，以控制成本和上下文长度。

8.6 数据留存与导出

  1. 原始抓取数据默认保留 7 天，用于回溯、排错和证据复核。
  2. 标准化数据与分析报告默认保留 30 天，后续可按部署形态调整。
  3. 用户应可手动导出分析报告与标准化数据；MVP 至少支持 Markdown 和 JSON 导出。
  4. 用户删除任务后，应同步清理与该任务相关的原始数据、标准化数据和报告缓存；登录会话按第 7 章单独管理。

9. 明确的非目标

MVP 阶段不包含以下能力：

  1. 不做持续监控或定时更新
  2. 不做面向消费者的导购推荐
  3. 不做内容平台、社区平台、短视频平台的舆情聚合
  4. 不保证评论全量抓取
  5. 不在没有人工确认的前提下自动判定同款商品
  6. 不承诺完全自动化绕过验证码、风控和登录限制

10. MVP 优先级建议

10.1 P0

  1. 商品名称输入
  2. 天猫、京东站内搜索
  3. 候选商品返回
  4. 人工确认商品链接
  5. 商品信息抓取
  6. 评论分层抽样抓取
  7. 数据标准化
  8. AI 输出卖点、好评点、差评点、跨平台对比
  9. 生成基础分析报告

10.2 P1

  1. 更丰富的证据展示
  2. 更细的运营建议
  3. 更完善的字段提取与结构化
  4. 更强的失败恢复与任务编排
  5. 更丰富的平台扩展能力

11. 当前建议值与待定项

以下内容当前可作为建议值进入设计与实现阶段，后续可调整：

  1. 每个平台默认返回 Top 5 候选商品。
  2. 评论抓取上限 N 默认按单个已确认链接生效，建议默认值先从 100 开始验证。
  3. 评论抓取采用分层抽样，默认比例为 40% 最新 + 30% 最热 + 30% 差评。
  4. 同平台多个确认链接在平台层汇总时仅做评论去重，不自动合并为单一商品。
  5. 评分统一映射到 5 分制，销量/评论数统一转为整数，时间统一为 Asia/Shanghai 时区下的 ISO 8601。
  6. 登录态仅允许在服务端会话中心加密保存，默认最长保留最后使用后 24 小时。
  7. 报告输出优先满足“结构化分析报告 + 证据回溯”能力。
  8. 最终呈现载体可后续再定为页面、Markdown、导出文件或其他形式。

12. 一句话定义

这是一个面向品牌方/运营人员的跨平台商品分析工具：用户输入商品名称，系统在天猫、京东中搜索候选商品，由用户人工确认一个或多个商品链接后，抓取商品信息与适量评论，统一标准化并用 AI 输出卖点、好评点、差评点及跨平台分析报告。