数据散在不同平台
淘宝、京东、小红书各有一套页面和入口，商品链接、规格、评论和笔记很难放到一起比较。
独立项目 / 电商内容运营
把一条商品链接，变成能核对的报告。
ReviewAgent 在本机运行，做电商口碑分析。粘贴商品链接后，它会解析商品对象，按品牌、型号和规格找同款，再把这些内容整理成一份能回查证据、也写明缺口的报告。
评论样本还没拿到时，报告只写到对象层，口碑分、风险、痛点和运营方案都留空，不用占位数字充数。
138项自动化测试通过
12个报告章节
2个同 SPU 候选
0条编造指标
01 / 问题
评论很多，
能用的结论很少。
做电商内容的人天天看评论，改标题、换卖点、补详情页。麻烦的是评论常常互相矛盾，要把它变成能回到原句、能说明样本范围的判断，并不容易。
真假混在一起
模板好评、刷单、反讽和真实抱怨，读起来可能差不多。只做情绪分类，容易把看起来正面的噪音算进结论。
结论回不到原句
报告里写“太油”“香味太重”，却找不到对应评论、平台和时间。这样的结论没法复核，也没法交给下一环执行。
“先确认对象，再谈口碑。”
这是产品的第一条规则，也是这一版只做到对象层的原因。
02 / 界面
一张工作台，
把对象、证据和缺口放在同一页。
下面四张图都来自本机运行的工作台。切换标签可以看对象匹配、诊断空态和证据区，点图能打开大图。
03 / 移动端
在手机上，也能读完一份报告。
工作台按 390px 宽度重排了对象卡、指标和候选表。窄屏下表格收成卡片，打印和导出换成另一套版式。
04 / 流程
解析、匹配、报告，
每一步都留下输入和输出。
分析没有藏在一个黑盒里。解析、匹配、报告各有自己的输入、输出和失败状态，前端只展示后端实际算出来的结果。
01resolve
解析对象
识别京东、天猫、淘宝和小红书的链接。京东公开商品页能取到标题、品牌、店铺、类目和同 SPU 规格；其他平台目前只确认链接，不猜标题。
- 页面内嵌 JSON 解析，不启动浏览器
- 失败时返回低置信度和补链接入口
- 纯商品名找不到可靠搜索源时，不硬编结果
02match
匹配同款
匹配时看品牌、型号、规格，也看标题关键词和类目。同一 SPU 的规格直接算同款；不同品牌的相近商品归为竞品，不混进主商品评分。
- 同款、近似款、竞品、待判断，共四级
- 每条候选带匹配分、依据和冲突项
- 价格、销量、评论数拿不到，就写缺失
03report
生成报告
报告按固定结构组织对象、候选、证据、缺口和下一步动作。没有评论样本时，只输出对象层报告，不生成口碑分、痛点或运营建议。
- 12 个章节，JSON 与 PDF 同源
- 每个指标都能找到来源；找不到就写 null
- 报告保存在本机 SQLite，刷新可恢复
输入商品链接 / 商品名
解析object_resolver
匹配same_product
报告report_builder
出口API · Web · PDF
05 / 工程
数据扎实了，
报告才站得住。
对象层没有调用大模型。解析、匹配和报告都能单独测试；前端用原生 HTML / CSS / JS，不引 CDN，离线也能打开。
object_resolver.py
链接识别、平台分发、京东 window._itemOnly 解析、失败状态与补链接入口
same_product.py
把品牌、型号和规格归一化，加权匹配；同 SPU 强制同款，竞品单独隔开
report_builder.py
按固定 schema 生成报告；空值不补数，证据、缺口和下一步动作来自同一份数据
http_api.py
FastAPI 路由、静态工作台托管、分析记录与 CSV / 证据导出
tests/
解析、匹配、报告、API、Web 静态检查；当前 138 项通过
06 / 边界
这一版做到哪儿，
就写到哪儿。
没做的部分如果藏起来，报告会显得完整，却更难核对。已经做到的和刻意没做的，下面分开写。
已经做到
- 京东公开商品页可解析标题、品牌、店铺、类目和同 SPU 规格
- 同款、近似款、竞品、待判断四级匹配，带理由和缺失字段
- 对象层报告覆盖对象档案、同款候选、平台覆盖、证据与下一步动作
- 本机保存、刷新恢复、CSV 导出、A4 打印 / PDF
- 桌面与 390px 移动端布局，138 项测试通过
刻意没做
- 不登录抓评论，也不绕京东评论接口的风控签名
- 淘宝、天猫、小红书只识别链接，不假装拿到商品标题
- 不从商品页猜价格、销量、评论数
- 没有评论样本时，不生成口碑分、痛点、增长机会和运营方案
- 跨平台自动找同款还没接，当前候选来自同一 SPU 和用户补充的链接
CASE STUDY / 2026