HustleRadar：用SerpApi+Gemma 2验证转售利润

一个标价 ₹22,000、现价 ₹15,000 的商品页面，看起来像"立省 ₹7,000"。但对转售者来说，这个数字几乎毫无意义——参考价可能是为促销虚增的，别的店可能卖得更便宜，平台抽佣、运费、优惠券会吃掉利润，甚至最便宜的那条搜索结果根本不是同一款产品。

HustleRadar 就是为这个问题写的：一个开源的市场证据与套利决策工具，把"这个折扣是真的吗、我买下来还能赚多少"变成一条可审查的工作流。据开发者 DeepSaha 在 Dev.to 的发布文章，它同时接入了 SerpApi 的实时零售数据与 Google Gemma 2 的语言解释能力，并把两者严格分层——模型只负责解释，不负责发明数字。

产品定位：不是购物聊天机器人

HustleRadar 刻意把能力边界写得很窄。它输入四项信息：产品名称或链接、实际支付价、可选的参考价、以及服务端证据模式（live 实时调查流程，或明确标注的 demo 固定数据）。然后按固定顺序跑完整个决策闭环：

1. 从购物结果、指定零售商和带日期的上下文中收集证据
2. 归一化产品身份，排除配件、翻新和错误型号
3. 计算市场图景：最低观测价、中位数、来源覆盖率、扣费后的转售毛利
4. 展示证据——零售商名称、链接、价格、时间戳、覆盖度警告
5. 调用 Gemma 2 把结构化事实翻译成一段可操作的说明
6. 模型不可用时退回到确定性的证据解释

它的核心承诺只有一句：不要因为商品页写着"折扣"就下单，要看到市场、扣费后的退出价格和推荐背后的证据之后再决定。 目标用户是自掏腰包买高单价库存的人——电子产品倒卖者、零售套利新手、自由职业工作室、摄影师、剪辑师和小电商运营者。

决策逻辑：算术在先，语言在后

这是 HustleRadar 最重要的设计选择，也是它区别于普通 AI 导购的地方。

确定性计算先行

转售毛利在 TypeScript 里算完，之后才轮到 Gemma。当前版本把平台费建模为 8%，并用百分比毛利和绝对净利润两个维度给机会分级：

const grossMargin = resaleMedianPrice - buyPrice;
const marginPercent = Math.round((grossMargin / buyPrice) * 100);
const platformFeeEst = Math.round(resaleMedianPrice * 0.08);
const netProfit = grossMargin - platformFeeEst;

if (grossMargin > 0 && netProfit > 0) {
  opportunityScore =
    marginPercent >= 20 && netProfit >= 2000 ? "HIGH" :
    marginPercent >= 10 || netProfit >= 800 ? "MODERATE" : "LOW";
} else {
  opportunityScore = "UNPROFITABLE";
}

简化后的公式是：预估净利润 = 预期转售价 × (1 − 平台费率) − 采购价。运费、优惠券和银行折扣放在场景计算器里单独建模，而不是被塞进一个乐观的百分比。

平台费模型是转售利润计算中最容易被低估或简化的部分。不同电商平台的佣金结构通常由类目佣金、支付网关费、履约费和推广费叠加而成，实际扣点往往在 10%–20% 之间，而二手交易平台的费率逻辑又完全不同。HustleRadar 当前把平台费统一建模为 8%，这是一个便于原型验证的简化假设，但它的影响是系统性的：费率每偏低 5 个百分点，净利润就会被系统性高估，机会分级也可能从 LOW 被误判为 MODERATE。因此，在把这个工具用于真实采购决策之前，用户应当先用自己的实际费率替换这个常量，并对高单价商品额外考虑退货损耗、库存周转时间和资金占用成本。

Gemma 只拿到事实，不拿到空白画布

发给 Gemma 的 prompt 里已经包含归一化产品名、判定结论、置信度、申报价格、市场中位数、最低可比报价和算好的套利结果。模型被要求只回答两个问题：这个宣称的折扣是真的还是虚增的？扣掉平台费后还有没有可行的转售空间？prompt 里明确写着"禁止幻觉出价格或零售商"。

这种分工的意义在于：一段漂亮的 Gemma 输出不是证据。HustleRadar 的置信度和警告基于来源覆盖和匹配结果，模型无法靠更有说服力的措辞把弱证据升级成强推荐。设置 ENABLE_LLM=false 即可完全绕过模型，系统会用同一份结构化证据生成确定性解释。

证据收集完全独立于结论

后端用 Promise.all 并发跑三条 SerpApi 路径：google_shopping 拿结构化报价、零售商限定搜索（as_sitesearch）补直营店覆盖、带 tbs: "qdr:y" 的上下文搜索抓近期价格提及。每条路径都保留自己的状态——success、empty 或 error。一次 HTTP 200 但响应体里含 SerpApi 错误的请求，不会被当成"成功但为空"的市场扫描。

SerpApi 是一个把搜索引擎结果页转化为结构化 JSON 的第三方 API，它本身不提供价格数据库，而是代理 Google Shopping、Google 网页搜索等结果。这意味着 HustleRadar 拿到的“市场证据”本质上是搜索结果的快照，具有三个固有特征：其一，覆盖度取决于关键词和搜索路径设计，未出现在结果中的零售商并不代表不存在；其二，结果带有时间戳，价格可能在数小时内失效；其三，tbs: "qdr:y" 这类时间过滤参数只约束搜索结果的新鲜度，不保证其中提及的价格仍然有效。理解这三点，才能正确解读报告中的来源覆盖率警告——它衡量的是证据的广度，而不是市场的真实分布。

工程上真正花时间的，是让失败路径诚实

作者在原文里坦承了两个关键 bug，这比展示 happy path 更有价值。

Bug 1：供应商故障悄悄看起来像成功扫描

早期实现会在实时供应商失败时回退到 demo 数据，界面看起来很完整，但"live"这个词的含义被彻底摧毁了——转售者会以为报告来自当前市场证据。修复方式是把模式写进证据契约：实时请求保持实时、供应商错误保持错误、demo 数据只在显式请求 mode: "demo" 时加载、部分失败不会被缓存成健康报告、界面可以显示 insufficient_data 而不是编造信心。

Bug 2：最便宜的报价不总是对的产品

搜索引擎会把保护壳、替换零件、上一代型号和翻新机混进结果里。没有身份校验的价格聚合，本质上是在奖励错误的那条 listing。校验层现在会在价格进入中位数计算之前检查型号身份、成色、配件关键词、变体属性和币种。如果还剩下多个配置，HustleRadar 会停下来让用户自己选，而不是把它们混成一个假中位数。

作者举的例子很具体：查询 "MacBook M5" 时，一台 13 英寸或低存储配置的更便宜机器，如果被允许进入 15 英寸高存储版本的对比，会凭空造出一个看起来极好的利润率。

产品身份归一化（product identity normalization）是价格聚合类系统的核心难点。同一个商品在搜索引擎中可能以不同标题、变体属性和商家自定义命名出现，而配件（如保护壳、电源适配器）、翻新机、上一代型号和不同存储配置又共享大量关键词。常见的处理手段包括：提取型号与容量等结构化属性做精确匹配、用否定关键词过滤配件词、按成色标记区分全新与翻新、以及校验币种和地区。当匹配结果仍存在多个配置时，系统面临一个权衡——强行合并会制造虚假中位数，直接丢弃则会损失覆盖度。HustleRadar 选择让用户手动确认，这是把不确定性交还给决策者的保守做法。

前端体验：流式进度而非假转圈

搜索比本地计算慢得多，所以 API 用 NDJSON 逐行推送进度事件，前端增量读取响应体，能显示购物、零售商、上下文和分析各阶段的实际状态。这不是一个装饰性的计时器——它让用户看见报告正在被拼装，而不是在等一个不透明的"AI 答案"。浏览器断开连接时，AbortController 会中止供应商请求。

整套技术栈包括 React 18 + TypeScript + Vite + Tailwind 前端、Node/Express API、SerpApi 搜索接地、确定性的 INR 解析与产品护栏、Gemma 2（经由 Ollama 或可配置的开放模型端点），以及 Render Blueprint 部署。前端通过 Render 的 service reference 拿到 API 地址，SERPAPI_KEY 和 GEMMA_API_KEY 都是 sync: false，凭据不进入仓库。

开放权重模型改变了什么

原文专门讨论了开放模型对这个产品的实际影响，答案不是"模型免费"这么简单。

本地隐私。 转售者的关注清单会暴露他们在找什么产品、什么细分市场。通过 Ollama 可以把结构化报告发给本地 Gemma，语言生成这一步不必离开笔记本电脑。实时市场搜索在启用时仍是外部依赖，但推理环节可以留在本地。

边际成本。 目标用户不是有 AI 预算的企业，而是下班后查几个商品的个人。本地跑 gemma2:9b 没有按 token 计费——这不代表整个技术栈免费（SerpApi、托管和平台费仍然存在），但少了一项经常性支出，让小规模实验变得可行。

模型可替换。 应用自己拥有 prompt 契约和证据 schema，可以在本地 Ollama、配置的开放模型端点或确定性解释路径之间切换，而不用改报告界面。

边界可审查。 关键链路 search → normalize → calculate → explain 的前三步都在仓库里可见、可测，开放模型只接收受约束的输入且可以关闭。对这个产品来说，这比声称"某个 prompt 能让模型不犯错"是更实质的 AI 安全。

开放权重模型（open-weight model）指模型参数可公开下载、可在本地或自有基础设施上运行的模型，Gemma 2 即属于此类，与只能通过 API 调用的闭源模型形成对比。二者的关键差异不在能力上限，而在部署边界：开放权重模型允许把推理环节留在本地，从而避免把查询内容和结构化报告发送给第三方；同时它按硬件成本而非 token 计费，边际成本接近于零，适合低频、小规模的个人使用场景。但其代价是用户需要自行承担模型下载、硬件资源和版本维护，且本地小参数模型在复杂推理上的表现通常弱于云端大模型——这正是 HustleRadar 把模型限制在“解释已有事实”这一窄任务上的原因。

诚实性验证：24 个离线测试

仓库包含 24 个通过的离线测试，覆盖查询清洗与 INR 价格解析、配件/翻新/错误型号拒绝、demo 模式与缓存分离、实时供应商失败的诚实处理、NDJSON 流式进度与结果、Gemma 禁用时的确定性解释，以及模糊短链接的拒绝。

值得肯定的是，作者明确说明了测试证明什么、不证明什么：SerpApi 调用被 mock 或禁用，Gemma 在离线服务端测试里也是关闭的，所以测试验证的是适配器契约、校验规则、回退行为和流式协议，而不是外部配额或远程模型端点。/api/health 端点被定位为部署与配置检查，而非"此刻实时调用成功"的证明。

原文还列了一组产品明确不承诺的东西：不保证转售者能按中位数卖出、不保证扫描后零售商仍有库存、不把展示 MRP 当成历史真实价格、不把供应商故障悄悄转成 demo 结果、不声称开放权重 AI 消除了所有成本。

这类工具的机会与局限

HustleRadar 找到的切口是真实的：零售套利和二手转售的决策质量，长期依赖个人经验和 Excel 手算，而大模型恰好擅长把多源事实组织成一段人话。把算术和语言分离、把证据和结论分离、把 live 和 demo 分离，这三条边界对任何想把 LLM 嵌入金钱决策的产品都有参考价值。

局限也很清楚。8% 的平台费是一个固定假设，不同市场、不同品类的费率差异很大；零售商白名单和 INR 解析让当前版本高度绑定印度市场；24 个离线测试无法证明实时数据管道的稳定性，作者本人也在文末邀请用户反馈"当前版本最先搞错的是哪个费率、市场或产品变体"。原文没有虚构付费客户或用户证言，这一点保持了克制。

如果一个工具能持续帮人避开一次糟糕的库存采购，它就有付费价值。HustleRadar 目前更像一个结构扎实的开源原型，而不是一个已验证的商业产品——但它对"AI 应该在哪里停手"的回答，比很多同类项目更清楚。