523 lines
22 KiB
Markdown
523 lines
22 KiB
Markdown
# 跨平台商品聚合与 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 输出卖点、好评点、差评点及跨平台分析报告。
|