用AI构建外卖分析工具的经验与反思

最新推荐文章于 2026-01-07 10:31:23 发布

原创最新推荐文章于 2026-01-07 10:31:23 发布 · 615 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #javascript #开发语言 #AI #Chrome扩展 #LLM #程序那些事

我的外卖数据分析工具构建之旅

每隔几个月，我的妻子都会问我同样的问题：我们点外卖是不是太频繁了？大多数时候，我只是耸耸肩。

某平台让翻阅历史订单并重新订购变得很容易，但很难回答以下问题：

一段时间内的总支出是多少？
我的饮食习惯是怎样的？饮食均衡吗？
我最常点的是什么？

这一次，既然手头有AI，我没有猜测，而是决定构建一些东西。

动手构建

我编写了一个Chrome扩展程序，从某外卖平台的订单页面抓取我的食品订单，并使用AI生成“健康洞察”。这让我对AI的使用（而非营养事实）有了非常有价值的见解。

让Copilot搭建项目脚手架

我登录了我的代码托管平台账户，在创建新仓库时，我给出了如下提示：
“一个Chrome扩展程序，可以从某外卖平台和另一个外卖平台抓取订单历史记录，提取订单数据（餐厅、商品、费用），并提供关于支出、饮食习惯、健康评分和最爱菜品的实时分析。”

这个提示对我想要扩展程序做什么并不十分清晰。然而，在几分钟内，我就得到了：

一个抽象的BaseProvider和两个实现，分别针对两个外卖平台。
用于存储和分析的独立工具函数。

Copilot在项目引导方面确实表现出色，它生成了清晰的抽象结构，并编写了与实际代码匹配的良好文档。我基本上已经获得了一个可工作的原型，至少我当时是这么认为的。

修复Bug

当我使用Chrome的“加载已解压的扩展程序”选项加载我的扩展代码，并打开外卖平台的订单页面时，第一个真正的故障出现了。

Copilot生成的DOM选择器实际上并不存在。

// Copilot生成的内容（幻觉）
const orders = document.querySelectorAll('[data-anchor-id="OrderHistoryItem"]');

这个属性看起来合理，但并不真实。当我在订单页面上打开Chrome开发者工具并手动检查DOM时，我发现实际的选择器应该是：

// 外卖平台实际使用的选择器
const orders = document.querySelectorAll('[data-anchor-id="OrderHistoryOrderItem"]');

这就是大语言模型最擅长的事情：它们会产生幻觉，猜测一些看起来正确的东西。代码编译了，没有出现明显的失败。不过问题不大，我只是更希望代码中能有一个TODO注释之类的东西，让我自己来更新这些选择器。

旁注：我知道这种方法在设计上就很脆弱。对于屏幕抓取，总是存在目标网站更改其HTML结构从而导致这些选择器失效的风险。真正的解决方案应该是一个官方的订单导出API，但也许出于合理的原因，它并不存在。

接下来，最有指导意义的失败来自分析层。该扩展程序使用一个加权公式计算健康评分：

健康评分 = (菜系多样性 * 0.4) + (订单频率得分 * 0.3) + (平均订单价值得分 * 0.3)

起初这看起来很合理。但后来我用这个例子做了一个简单的计算：

价值5美元的快餐汉堡，每周订购5次；健康评分：75
价值20美元的沙拉，每周订购2次；健康评分：45

这个公式奖励了廉价的频率，而不是营养质量。这毫无道理。Copilot只是给了分析层一种虚假的智能感。

尝试大语言模型

为了改进分析，我增加了基于大语言模型的洞察。因为这是一个Chrome扩展程序，我使用了 @xenova/transformers 库，它似乎已成为JavaScript中进行本地推理的事实标准。Chrome开发者平台并不偏好远程代码执行和加载大型模型，所以这个方法效果很好。我选择了 Xenova/flan-t5-base 模型，并使用了以下提示词：

你是一位营养和健康专家，正在分析某人的外卖模式。
外卖习惯：
- 频率：每周X单
- 菜系多样性：Y种不同类型的菜系（首选：Z）
- 平均支出：每次订单A美元

根据这些模式，找出2-3个具体的健康问题。请考虑以下因素：
- 外出就餐与在家做饭的频率
- 营养平衡与多样性
- 餐厅食品可能导致的钠、卡路里或不健康脂肪过量
- 预算对健康选择的影响
- 菜系类型及其典型的营养构成

将你的问题以编号列表的形式列出。

而我得到的“AI摘要”是：

摘要：您有什么正面评价要添加吗？每周点单2.9次，涉及9种菜系，平均每单30.71美元。
⚠️ 问题：非为您准备的食物是一个主要问题。

文本生成模型在做它本意要做的事情：从文本生成看似合理的文本。它不是在推理营养问题，而是在预测词元。没有产生真正的洞察。

考虑到我已经有了调用本地Transformers模型的所有代码，我想为什么不试试调用某机构的某个模型呢？我选择某机构是因为它的一些模型允许免费使用且有不错的速率限制。旧版的某个模型可能拥有最宽松的速率限制，所以我选择了它。代码改动很小：

向 v1beta/models/gemini-pro:generateContent 发送POST请求。
添加一个设置页面来添加某机构的API密钥，这样密钥就不会被硬编码。
基于本地存储中是否存在某机构的API密钥来做决策逻辑。

这是我最终得到的设置页面外观：

（此处应有一个设置页面的描述或截图占位符，但原文未提供具体图片）

相同的提示词，不同的模型。某机构的洞察有价值得多：

（此处应有一个洞察结果的描述或截图占位符，但原文未提供具体内容）

经过4个小时的“氛围编码”后，我发现自己在过去6个月里在某外卖平台上花费了1800美元。这个数字无需解释！

下次我会采取不同的做法？

如果要重来一次，我首先要做的是优化提示词，使其更具描述性。仅仅一两句话的提示词无法完成任务。我会用类似这样的提示词：

你是一家顶级科技公司的高级软件工程师。你的工作是构建一个可工作的Chrome扩展程序，功能如下：
- 抓取某外卖平台的订单页面，获取订单和商家列表并存储。
- 使扩展程序具有可扩展性，以便将来能适配其他外卖服务提供商。
- 添加一个设置页面，用户可以在其中添加他们的某机构API密钥。
- 如果存在API密钥，则使用某机构的模型来生成有价值的洞察；否则使用本地模型。

注意：
- 你不应猜测任何东西。如果你不确定代码的任何方面，请添加TODO让我稍后修复。
- 使用最符合营养分析需求的模型。AI洞察应言之有理。

注意：一个更好的初始提示词对Copilot搭建脚手架会有所帮助，但它无法解决试图使用能力较弱的本地模型进行推理任务的根本问题。此外，可能先开发一个没有AI摘要的版本，再逐步演化为使用大语言模型，会更有价值。