家庭物品管理系统：让家里的每件东西都能被快速记录、找到、维护和处理

1. 产品摘要

产品暂定名：家物管家。它可以先做成 iOS App，也可以做成响应式网站 / PWA。建议第一版优先 iOS App，因为家庭物品录入高度依赖手机拍照、扫码、离线使用、系统相册和推送提醒；同时保留 Web 管理端，用于批量编辑、导出和家庭成员协作。

2. 竞品参考

参考现有家庭库存与物品管理产品后，可以归纳出几类成熟能力：

参考来源包括 NAIC 官方家庭库存说明、Sortly 产品介绍、Itemtopia 官网功能说明，以及 2026 年家庭库存应用对比文章。本文只抽象产品模式，不复制任何竞品界面。

3. 问题与机会

用户真实痛点

• 东西太多，靠记忆找不到，尤其是柜子、抽屉、储物箱、床底、车库、仓库。
• 买过但忘了，重复购买，造成浪费。
• 票据、说明书、保修卡散落，维修时找不到。
• 搬家、断舍离、出租房、装修、保险理赔时，临时整理成本极高。
• 家人之间信息不透明，一个人知道东西在哪，其他人仍然找不到。

产品机会

大多数库存系统强调“完整记录”，但家庭场景更需要“低负担持续使用”。因此设计上应把完整性放在第二位，把快速记录、快速查找、位置表达和提醒放在第一位。

4. 产品定位

产品原则

• 先能找到，再追求完整。一件物品最低只需要名称、照片、位置即可入库。
• 位置比分类更重要。分类帮助浏览，位置解决“去哪拿”。
• 一箱多物是刚需。家里很多东西不是单件摆放，而是被放进盒子、袋子、柜格。
• 少打字。拍照识别、语音录入、扫码、模板和批量操作要优先。
• 可导出，不绑架。用户必须能随时导出 CSV / PDF / 图片包。

5. 用户与场景

6. 功能范围

MVP 必须有

• 物品快速添加：拍照、名称、数量、位置、分类。
• 位置体系：房屋、房间、柜子、抽屉、箱子、格子。
• 搜索与筛选：名称、分类、位置、标签、状态。
• 箱子 / 容器管理：一个容器可包含多个物品，可生成二维码。
• 照片、票据、保修日期、提醒。
• 家庭成员共享与只读 / 可编辑权限。
• CSV / PDF 导出，适合搬家和保险。

暂不做或后置

• 复杂采购审批、仓库调拨、企业级库存成本核算。
• 二手交易平台闭环。
• 完全自动识别全屋所有物品。AI 可以辅助，但不能作为第一版核心承诺。

7. 信息架构

8. 核心流程

快速录入单件物品

整理一个箱子

9. 功能详述

9.1 物品档案

字段分为基础字段和增强字段。基础字段包括名称、照片、位置、数量、分类、状态；增强字段包括品牌、型号、序列号、尺寸、颜色、价值、购买日期、购买渠道、票据、说明书、保修、备注。

9.2 位置地图

位置采用树状结构：家庭 / 房屋 → 房间 → 家具 → 层板 / 抽屉 / 箱子。位置页面要像“家里的地图”，而不是普通文件夹列表。每个位置显示物品数量、估值、最近更新和未整理数量。

9.3 容器与二维码

容器是特殊位置，可以被移动。比如“透明收纳箱 3 号”既可以在储物间，也可以搬到新家客厅。二维码链接到容器详情，支持离线缓存。

9.4 搜索

搜索必须容错，支持拼音、模糊匹配、同义词和照片识别结果。搜索结果优先显示“位置路径”和“最后确认时间”，因为用户搜索时最关心如何拿到。

9.5 票据与保修

用户可以拍摄发票、订单截图、保修卡。系统提取购买日期、价格、店铺和保修期限，并在到期前提醒。适合家电、数码、家具和贵重物品。

9.6 状态管理

建议内置状态：在用、闲置、借出、待维修、待出售、待捐赠、已丢弃。状态不是复杂流程，而是帮助用户减少东西。

9.7 家庭协作

家庭成员可以加入同一个家庭空间。权限分为管理员、可编辑成员、只读成员。每次移动或删除物品都记录操作人和时间，避免家庭协作时信息混乱。

10. AI 与自动化

AI 应作为降低录入成本的助手，而不是制造复杂感的卖点。

11. 数据模型

12. 爽感体验设计

这个产品要让用户觉得“终于有人替我把家里的混乱变简单了”。爽感不来自花哨动画，而来自少思考、少打字、少等待、少返工，以及每一步都能立刻解决生活问题。

12.1 让第一次使用就顺

• 本地先用：允许用户不注册先记录 20 件物品，等用户感到有价值后再引导创建账号和云同步。
• 三种起步方式：整理一个箱子、整理一个抽屉、记录贵重物品。不要让用户面对一个空系统自己规划。
• 样例家庭空间：默认给出客厅、卧室、厨房、卫生间、储物间、阳台等常见位置，用户只需要删改。
• 不用先建分类：分类由系统建议，用户可以以后再整理；第一天只要把东西拍进去。

12.2 六个关键爽点

12.3 把录入从“填表”改成“连续动作”

12.4 高频场景要做到像快捷指令

• “这个东西在哪？”首页搜索、Siri / Spotlight、桌面小组件都能查，结果直接给位置，不先给列表。
• “我刚把它挪走了。”物品卡片长按选择“移动到”，最近位置排在最前。
• “借给别人了。”选择联系人和归还日期，自动生成提醒。
• “这个快过期了吗？”食品、药品、耗材支持保质期提醒，列表按紧急程度排序。
• “我要搬家了。”切换搬家模式后，每个箱子有编号、目标房间、箱内清单和是否已到达。

12.5 家庭协作要低摩擦

家庭成员不一定愿意维护系统，所以协作设计要允许轻参与。比如家人只需要扫码查看箱子、用语音问“备用钥匙在哪”、或把新拍的照片发进家庭空间，由主要维护者稍后归档。

13. 多物品识别技术方案

中国大陆版本建议以百度智能云为主链路，不自研模型。方案不是依赖单一“大模型猜答案”，而是组合 图像多主体检测、通用物体识别、OCR、千帆多模态理解、业务规则层，让识别结果既有框选能力，也有中文家庭物品语义。

13.1 推荐能力组合

供应商能力参考：百度智能云图像识别、百度 OCR、百度千帆多模态。正式开发前需要根据开通区域、计费、QPS、图片大小限制做一次真实接口联调。

13.2 端到端识别链路

13.3 后端接口设计

建议后端只暴露一个聚合接口，前端不直接调用百度 API，方便后续切换供应商、做缓存和风控。

POST /api/recognition/multi-item-photo

Request:
{
  "image_url": "https://example.bcebos.com/photo.jpg",
  "location_hint": "书房 / 右侧抽屉",
  "mode": "drawer",
  "user_hint": "这是我刚整理的抽屉"
}

Response:
{
  "job_id": "rec_20260519_001",
  "image_width": 3024,
  "image_height": 4032,
  "items": [
    {
      "temp_id": "item_1",
      "bbox": { "left": 320, "top": 460, "width": 520, "height": 380 },
      "name": "7号电池",
      "category": "家用耗材",
      "brand": "南孚",
      "quantity": 4,
      "confidence": 0.86,
      "evidence": ["multi_object_detect", "ocr", "qianfan_vl"],
      "ocr_text": "南孚 AAA",
      "needs_confirmation": true
    }
  ]
}

13.4 千帆多模态提示词

千帆这一步要做“结构化判断”，不要让模型自由发挥。提示词要明确分类范围、输出格式和不确定时的保守策略。

你是家庭物品管理系统的识别助手。
请根据图片、物体框位置、OCR文字、用户所在位置，识别每个候选物品。

要求：
1. 只输出 JSON。
2. name 使用中国家庭用户容易理解的名称。
3. category 从以下分类中选择：数码配件、厨房用品、清洁用品、药品保健、工具五金、衣物鞋包、食品饮料、文件证件、玩具文具、家居家电、其他。
4. 如果不确定，name 使用更保守的名称，不要编造品牌。
5. 如果 OCR 和视觉冲突，优先相信 OCR 中明确出现的品牌、型号、品名。
6. confidence 使用 0 到 1。
7. 每个物品都必须返回 needs_confirmation=true。

13.5 置信度与前端策略

13.6 第一版优先识别类目

第一版不要追求识别所有东西，应优先打磨 OCR 价值高、家庭高频、用户愿意记录的品类。

13.7 兜底与学习机制

• 手动画框：识别不到时，用户可以框出物品并让 AI 起名。
• 快速改名：点击候选名称即可修改，修改后的名称进入个人词库。
• 同类合并：多个电池、数据线、药盒可合并成“电池 x4”。
• 低置信度过滤：框太多时，只默认选择可信结果，避免打扰用户。
• 家庭词库：用户确认过的常用叫法优先使用，例如“苹果数据线”“备用钥匙包”。

13.8 识别速度与渐进式体验方案

多物品视觉识别的体验瓶颈通常不是服务器性能，而是视觉大模型接口本身的响应时间。第一版不应让用户盯着加载状态干等完整结果，而应采用“先反馈、再补全、可中断”的渐进式识别体验。

当前线上过渡方案保留：以“看图识万物”做具体命名，多主体检测和 OCR 只做辅助，并给辅助接口设置短超时。长期目标是切换到更稳定、更快的千帆视觉大模型或其他可控视觉模型，同时支持流式 / 渐进式返回。

13.9 条形码识别与商品数据库方案

有包装条形码的商品，应优先使用扫码识别，而不是让视觉模型猜。条形码能直接对应 GTIN / EAN / UPC 商品编码，适合食品饮料、日用品、药品、清洁用品、个护产品、书籍、耗材等品类。它的优势是名称、品牌、规格、厂家、图片和参考价更清晰，用户确认成本更低。

13.9.1 产品策略

13.9.2 技术链路

13.9.3 推荐返回模型

GET /api/barcode/lookup?code=6901234567890

Response:
{
  "code": "6901234567890",
  "name": "某品牌洗手液 500ml",
  "brand": "某品牌",
  "category": "清洁用品",
  "spec": "500ml",
  "manufacturer": "某某日化有限公司",
  "image_url": "https://...",
  "reference_price": 19.9,
  "source": "barcode_provider_a",
  "confidence": 0.96,
  "cache_hit": true,
  "needs_confirmation": true
}

13.9.4 供应商选择

13.9.5 与多物品视觉识别的关系

13.10 POC 验证计划

14. 交互设计

首页布局

• 顶部固定搜索框：输入任何东西都先搜索。
• 主操作按钮：添加物品、扫一扫、添加箱子。
• 今日提醒：保修到期、食物过期、借出未还。
• 常用位置：最近查看的房间、柜子、箱子。

物品详情页

首屏必须看到照片、名称、位置路径、数量、状态和关键操作。票据、保修、历史记录等放在下方标签页，避免首屏过载。

空状态设计

新用户不应该看到空表格。首次进入应提供三个入口：从一个房间开始、从一个箱子开始、先记录贵重物品。这样更符合家庭整理的真实起点。

整理模式

整理模式是让产品变爽的关键入口。用户选择一个位置后进入连续拍照和快速确认界面，底部只保留拍照、确认、换位置、结束四个动作。结束后展示整理成果、待补全信息和可一键设置的提醒。

15. iOS / 网站形态

推荐路线：先做 iOS App + 简单 Web 管理页。若预算有限，先做 PWA 验证核心流程，再把拍照扫码体验迁移到原生 iOS。

16. 隐私与安全

• 默认私有，不做公开分享。
• 本地加密缓存，云端附件加密存储。
• 支持 Face ID / Touch ID 解锁。
• 家庭邀请需要明确确认，可随时移除成员。
• 导出文件带敏感信息提醒，例如贵重物品、住址、序列号。
• 支持完整数据导出和账号注销。

17. MVP 规划

第一阶段：4-6 周

• 账号与家庭空间。
• 位置树、物品增删改查、照片上传。
• 搜索、分类、标签。
• 容器和二维码。
• CSV 导出。

第二阶段：6-10 周

• 票据 OCR、保修提醒。
• 家庭成员协作。
• PDF 保险清单。
• 离线缓存和同步冲突处理。

第三阶段：10-16 周

• 百度智能云多物品识别与自然语言录入。
• 断舍离建议。
• 搬家模式。
• Web 批量管理和二维码打印。

18. 指标与验收

19. 风险与取舍

• 录入负担过高：用最小字段、连续拍照、AI 建议和批量操作降低门槛。
• 用户坚持不下来：用房间 / 箱子任务化引导，而不是要求一次性录完整个家。
• AI 识别不准：所有 AI 结果都作为建议，用户确认后才入库。
• 供应商依赖：识别服务通过后端聚合接口封装，避免前端绑定单一 API，后续可替换或增加其他国内供应商。
• 隐私顾虑：提供本地优先、加密、导出、删除账号等明确能力。
• 功能膨胀：第一版不做企业库存，不做复杂财务，不做二手交易闭环。

20. 路线图

最终愿景

用户不需要记住每件东西在哪里，只需要相信系统能告诉他。这个产品的成功不是让用户录入最多数据，而是让用户在“找不到东西、要维修、要搬家、要理赔、要清理”这些关键时刻真正省时间。