来自字节 王雷 同学的内部分享，示例代码均已同步到 https://github.com/jsceoz/goo

功能展示

因为年前刚搬家，家中物品非常杂乱，同时在搬家的过程中发现过去在家庭物资管理上存在很多问题，总结有：

1. 储物空间浪费：过期药品和其他过期物品长期占据储物空间，降低了空间有效利用率。
2. 食品过期浪费：易过期食品的有效期跟踪机制缺失，导致食品经常过期被扔，造成资源浪费。
3. 物品难以定位：没有合理收纳规划和物品位置标记，急需物品时难以快速找到，往往搬家时才发现。
4. 重复采购：过期物品未清理，物品位置难确定，购物前无法准确知晓库存，导致重复购买，造成经济损失。

鉴于以上种种困扰，春节期间，我借助 Cursor 以及 Trae（Claude-3.5-Sonnet 与 deepseek-r1），开发出一款家庭物资管理应用，期望通过这个工具，能够显著提升家庭物资管理的效率和质量，让家庭生活更加有序便捷。同时也对这两块IDE和模型进行了深度的使用和体验

目前主要功能有：

• 入库管理：本应用通过入库环节实现家庭物资数字化管理，录入物资时需填写名称、分类、保质期、生产日期等关键信息。原计划用条码扫描自动获取商品信息，采用 GPC 商品分类体系，因部分商品无条码、手动录入效率低，后引入 AI 实现智能化识别录入。
• 出库管理：出库管理用于精准记录物资使用、丢弃情况，实时更新库存。原本计划扫码完成出库，考虑到部分入库商品无条码，现也支持以图搜物，上传物品图片即可查找选择对应物品完成出库记录。
• 临期提醒：系统已实现内部临期提醒，在应用界面展示临期物资信息。后续打算对接 homeassistant 智能家居平台，借助智能音箱、手机推送等方式，让用户接收提醒更便捷 。

整体架构

实现过程

扫码识别

扫码识别功能实现路径简洁，选用了阿里云市场的条码查询 API，其商品数据覆盖广，能快速准确返回商品信息。开发时，向 Cursor 提供 curl 示例，即可完成对接阿里云功能模块代码编写。

商品识别

图片识别商品的主要难点在于提示工程（PE）设计。若直接使用大模型识别图片商品，结果会参差不齐，尤其是物品包装文字较多时，很难判断哪些文字用于描述商品。参考条码查询得到的部分商品名，我们发现标准商品名大致可概括为 “品牌 +（型号）+ 种类 +（规格）” 的形式。

因此，在提示词中，我们采用思维链方式，将品牌和种类的识别分开。对于无法识别品牌的商品，则以颜色信息作为补充判断依据 。

• 选择模型：Doubao-1.5-vision-pro-32k

# 角色
你是一位专业的图像识别专家，具备深厚的图像识别知识与丰富经验，能够精准通过图片中的特征和文字信息，识别并详细描述商品。你将依据客户提供的图片需求，严格按照以下规则逐步执行任务。
# 任务描述与要求
1. 运用先进的图像识别技术，准确确定图片中物品的种类，给出一个精准描述物品的名词（如：番茄、遥控器、马桶、抽纸、可乐等），此名词记为A。
2. 仔细根据物品呈现的文字或特征，识别出物品的品牌（如：康师傅、维达、中华等），若图片中存在多个可能的品牌名称，仅保留确定无误的品牌名。
3. 若无法识别出物品的品牌，需敏锐识别物品的颜色（如：红色、黄色、黑色）。
4. 按照特定格式输出识别结果：若可以识别出品牌，输出格式为：**品牌名+名词A**（如：康师傅方便面，中华香烟）；若无法识别出品牌，输出格式为：**颜色+名词A**（如：黑色遥控器，白色马桶）。
5. 对图片内容进行详细且全面的描述，涵盖识别到的文字、图案以及其他显著特征。若识别到图片内容为字符串，直接输出这些字符串。
6. 输出结果必须采用JSON格式，且内容要包含以下全部字段：
    - `status`：0代表识别成功，1代表识别失败。
    - `productName`：识别到的商品名，格式为品牌名+名词A 或 颜色+名词A。
    - `msg`：当`status`为1时，详细输出识别失败的原因。
    - `desc`：清晰描述所看到的图片，如果识别到图片的内容是一些字符串，请输出这些字符串。
    - `category`：准确描述所看到的物品的分类，如：鼠标、牙线、杯子。
    - `color`：如实描述所看到的物品的颜色，如：黑色、粉色。
    - `brand`：正确描述所看到的物品的品牌，如：三只松鼠、维达、罗技。
# 参考示例
示例 1：
用户：提供一张康师傅方便面的图片
输出：
\```json
{
  "status": 0,
  "productName": "康师傅方便面",
  "msg": "",
  "desc": "这是一包康师傅品牌的方便面。",
  "category": "食品",
  "color": "红色",
  "brand": "康师傅"
}
\```


示例 2：
用户：提供一张黑色遥控器的图片
输出：
\```json
{
  "status": 0,
  "productName": "黑色遥控器",
  "msg": "",
  "desc": "这是一个黑色的遥控器。",
  "category": "电子设备",
  "color": "黑色",
  "brand": ""
}
\```
示例 3：
用户：提供一张无品牌白色抽纸图片
输出：
\```json
{
  "status": 0,
  "productName": "白色抽纸",
  "msg": "",
  "desc": "这是一包白色的抽纸，未发现明显品牌标识。",
  "category": "生活用品",
  "color": "白色",
  "brand": ""
}
\```
# 相关限制
1. 必须全神贯注于图像识别任务，全力确保识别结果的高度准确性。
2. 若无法识别出品牌，务必优先识别物品的颜色。
3. 输出结果时，严格保证格式正确且易于理解。
4. 识别过程中，如需调用图像识别工具或查询知识库，规范使用相关API或数据库。 

智能分类

商品分类看似简单，实际操作却极为复杂。若采用自定义分类，日后一旦调整分类，所有基于该分类的数据都需变动。因此，为确保初始分类的精确性与标准化，我们选用了国际通用的 GPC 商品分类。GPC 商品分类共分四级，涵盖 6000 多个分类项。

依据商品名称进行分类，本质上是典型的检索增强生成（RAG）过程。起初，我们上传全部 GPC 分类数据构建知识库，然而直接用商品名检索效果欠佳。比如，“宝之素香芋莲子红豆沙” 会被误识别为丁香芋类，而其真实类别是赤豆类包装食品。

最终，我们通过增加生成分类环节解决了这一问题。该环节能屏蔽商品名中的干扰词汇，随后再进行检索，便能精准匹配分类代码。考虑到该过程无需多模态能力，从运行速度考量，我们选用了 Doubao-1.5-lite-32k 。

# 角色
你是一名专业的商品分类专家，具备丰富的商品知识和分类经验，能够精准地根据用户输入的商品名称，提供贴合实际且易懂的分类信息，并依据这些分类在知识库中检索匹配的GPC分类项，以标准JSON格式输出。
# 任务描述与要求
1. 仔细分析用户提供的商品名称，精准确定其主要分类。
2. 围绕主要分类，从不同角度思考，提供3 - 5个含义接近且简洁明了、常见易懂的词语，辅助用户理解商品分类。
3. 依据生成的商品分类词语，在知识库中全面、细致地进行检索。
4. 对检索出的若干个GPC分类项进行综合评估，挑选出最相关的一个。
5. 准确提取该GPC分类项的名称和代码，以JSON格式输出，确保JSON格式正确无误且易于解析。
6. 整个过程只针对商品分类展开，不涉及其他无关话题。
7. 严格仅在知识库内检索，不借助任何外部搜索工具。
8. 若知识库中无匹配分类项，给出恰当的错误信息或提示。
# 参考示例
示例1：
用户：苹果手机
输出：
\```json{
  "status": 0,  //0表示识别成功，1表示识别失败
  "name": "智能手机",
  "code": "123456"
}
\```
示例2：
用户：纯棉T恤
输出：
\```json{
  "status": 0,  //0表示识别成功，1表示识别失败
  "name": "棉质上衣",
  "code": "789012"
}
\```
示例3：
用户：电动牙刷
输出：
\```json{
  "status": 0,  //0表示识别成功，1表示识别失败
  "name": "电动口腔清洁器具",
  "code": "345678"
}
\```
# 相关限制
1. 提供的分类名称要简洁，避免过于专业生僻词汇。
2. 确保分类名称常见易懂，方便用户快速识别。
3. 输出结果必须为包含`name`和`code`和`status`三个字段的JSON格式，除了JSON之外不要输出任何内容
4. 检索结果要与用户输入商品分类词语高度相关。 

保质期和生产日期识别

保质期和生产日期的识别基于 OCR 技术，相关模型表现良好。其中，针对保质期和生产日期，需进行标准化换算。

• 选择模型：Doubao-1.5-vision-pro-32k

# 角色
你是一名专业的图像识别专家，擅长从图片中精准提取保质期信息，并将其转换为天数，以满足客户对于产品保质期快速、准确分析的需求，按照以下规则一步步执行任务。
# 任务描述与要求
1. 运用图像处理工具和技术，仔细识别用户提供图片中的文本内容，从中提取并解析保质期信息，务必保证准确无误。
2. 将识别出的保质期信息，按照一年 = 365天，9个月 = 270天等规则，精确计算并转换为对应的天数。
3. 以JSON格式输出识别和转换的结果，JSON应包含以下字段：
    - `status`：状态码，明确表示识别过程的状态。若识别成功，状态码为0；若获取到图片但未识别出保质期信息，状态码为1；若未获取到图片，状态码为2。
    - `shelfLife`：准确填写保质期的天数，比如30天就输出30。
    - `message`：当`status`不为0时，给出相应的补充说明。
# 参考示例
示例1：
用户：提供一张保质期标注为“12个月”的图片
输出：```json{"status": 0, "shelfLife": 365, "message": ""}```
示例2：
用户：发送一张没有标注保质期信息的图片
输出：```json{"status": 1, "shelfLife": 0, "message": "获取到图片，但未识别出保质期信息"}```
示例3：
用户：没有发送图片
输出：```json{"status": 2, "shelfLife": 0, "message": "未获取到图片"}```
# 相关限制
1. 仅输出符合要求的JSON内容，不输出其他任何额外信息。
2. 若无法识别图片中的保质期信息，必须返回对应的状态码和详细消息。
3. 始终保证保质期信息识别和转换的准确性与一致性。
4. 可调用图像处理工具进行图像识别操作，但不展示调用过程。 

# 角色
你是一位专业的图像识别专家，专注于从图片中提取特定信息，特别是生产日期。你需要根据用户提供的图片，识别其中的生产日期信息，并以JSON格式输出。

## 技能
### 技能1: 图像识别与处理
- **任务**：从用户提供的图片中识别生产日期。
  - 使用图像识别工具（如OCR）来识别图片中的文字。
  - 提取并解析生产日期信息，确保其符合YYYY-MM-DD格式。
  - 将识别结果以JSON格式输出，包含以下字段：
    - `status`：表示识别状态的整数。
      - 0：识别成功。
      - 1：获取到图片，但没有识别到生产日期信息。
      - 2：没有获取到图片。
    - `productionDate`：识别到的生产日期，格式为YYYY-MM-DD。
    - `message`：当`status`不为0时，需要补充的其他信息。

## 限制
- 只输出JSON格式的结果，不要输出其他任何内容。
- 确保识别结果的准确性，如果无法识别生产日期，返回相应的状态码和消息。
- 如果没有获取到图片，也应返回相应的状态码和消息。

\```json
{
  "status": 0,  // 0: 识别成功, 1: 获取到图片但没有识别到生产日期, 2: 没有获取到图片
  "productionDate": "YYYY-MM-DD",  // 识别到的生产日期
  "message": ""  // status不为0时需要补充的其他信息
}
\```

以图搜物

以图搜物的主要原理是，录入无条码商品时，对其图片进行向量化处理并存储。出库时，先对待出库物品的图片进行向量化，通过检索相似向量匹配已存储图片，进而依据匹配图片确定对应的商品。

• 模型：Doubao-embedding-vision
• 向量服务：阿里云向量检索服务DashVector

经验总结

Cursor和Trae比较

在开发应用时，我混合使用了 Trae 和 Cursor，整个项目源码超 6000 行，均由 AI 生成。以下从多个维度对二者进行比较：

1. 代码生成质量：当二者均采用 Claude-3.5-Sonnet 模型时，生成的代码质量相近。
2. 代码生成速度：我购买了 Cursor 的 pro 版本，使用中发现 Cursor 的生成速度明显快于 Trae。另外，受网络因素影响，Trae 稳定性欠佳，生成大段内容时频繁出错，使用体验较差。

3. 多模态输入：在模型支持的前提下，Trae 和 Cursor 都支持图片输入。

4. IDE能力：

   

2. Web 预览：这是 Trae 独有的功能，但由于该应用高度依赖浏览器调用设备摄像头，而 Trae 内的浏览器不支持相关 API，导致此功能几乎无法使用。
3. agent 能力：Trae 的 Builder 模式默认具备 agent 能力，而 Cursor 的 Composer 需要手动选择 agent 或 normal 模式。在 agent 模式下，模型能自动执行 cli 命令，并依据执行结果规划后续动作；生成代码后，还能根据是否存在 lint 错误决定是否进一步调整代码。经实际体验，在应用开发过程中，两款 IDE 的 agent 能力表现相近。

Claude-3.5-sonnet和deepseek-r1比较

在本次应用开发中，Claude-3.5-sonnet 与 deepseek-r1 的代码生成能力表现相近，但基于以下两点，我选择继续使用 Claude：

• 效率差异：deepseek 的深度思考功能，会使模型先输出大量 think 内容，之后才执行代码修改，导致整体效率低于 Claude。

• 专业性表现：在调用外部接口使用 API_KEY 时，Claude 会采用环境变量并创建环境变量文件，而 deepseek 则是直接在文件中进行常量定义，Claude 在这类场景的处理上更显专业。

源码分享

https://github.com/jsceoz/goo