DukaanAI：用开源AI把商品照片变成库存清单

对于街边杂货店和小型零售商来说，维护商品目录是一件重复且琐碎的事——名称、分类、描述、价格、库存数量，每一项都要手动录入。商品越多，这件事越让人头疼。一位开发者为此做了一个实验：如果店主只需上传一张商品照片，就能自动生成一条库存记录，会怎样？这个想法催生了 DukaanAI。

DukaanAI 做了什么

DukaanAI 是一个面向小零售商和本地店主的 AI 辅助库存工具。它的核心逻辑很直接：上传商品图片，AI 生成建议的商品名称、分类和描述，店主确认或修改后，补上实际售价和库存数量，保存入库。

当前 MVP 包含以下功能：

• 商品图片上传
• AI 生成商品名称、分类与描述
• 可编辑字段，供人工核验
• 手动录入售价与库存
• 库存搜索与删除
• CSV 目录导出

开发者强调，这个工具的目标不是替代店主的判断，而是在保留最终决策权的前提下，减少重复的数据录入工作。这个定位很关键——它决定了产品的形态是"辅助"而非"自动化"。

技术架构：本地优先的开源模型方案

DukaanAI 的技术栈选择体现了一个明确的取向：尽可能在本地完成 AI 推理。

前端使用 React 和 Vite 构建，后端采用 Node.js 与 Express，负责接收上传的图片。核心的 AI 能力来自本地运行的 Gemma 3 4B 模型，通过 Ollama 调用。模型分析图片后返回结构化 JSON，包含建议的商品信息。图片上传由 Multer 处理，库存数据初期存储在浏览器 localStorage 中，CSV 导出则用 JavaScript 实现。

完整技术栈：

• React + Vite（前端）
• Node.js + Express（后端）
• Gemma 3 4B via Ollama（AI 推理）
• Multer（图片上传）
• 浏览器 localStorage（库存存储）
• JavaScript（CSV 导出）

有意思的是，初始版本将库存存放在浏览器本地，这意味着它是一个 local-first 原型，而非云端多用户系统。这个选择降低了复杂度，也符合"先验证核心价值"的思路。

Gemma 3 4B 是 Google 于 2025 年发布的开源权重多模态模型家族中的一员，4B 指其参数量约为 40 亿。该系列模型支持文本与图像输入，能够直接对图片进行理解与描述，因此适合商品照片识别这类任务。相比动辄上百亿参数的大模型，4B 规模的模型对显存和算力要求较低，普通消费级显卡甚至部分高性能笔记本即可运行，这正是在本地部署的前提。

Ollama 是一个开源的本地大模型运行与托管工具，它把模型下载、量化、推理服务封装成简单的命令行与 HTTP 接口，开发者无需自行处理底层推理框架。DukaanAI 后端通过 Ollama 暴露的本地 API 调用 Gemma，模型响应返回结构化 JSON，从而把图像理解结果直接映射到商品名称、分类和描述字段。

localStorage 是浏览器提供的一种键值对本地存储机制，数据保存在用户设备上，不随请求发送到服务器，容量通常在 5MB 左右。对于 DukaanAI 这样的原型，把库存数据放在 localStorage 意味着无需搭建数据库、无需处理用户认证，刷新或重开浏览器后数据仍在，但换设备或换浏览器就无法访问。它是验证产品假设阶段成本最低的存储方案，一旦需要多设备同步或多人协作，就必须迁移到云端数据库。

为什么选择开源权重模型

开发者在文章中明确解释了选择 Gemma 这类开源权重模型的原因：对于面向小企业的产品，AI 推理的成本和控制权至关重要。

通过 Ollama 运行 Gemma，模型可以在兼容的硬件上本地运行。商品图片分析不需要发送到第三方托管的 AI API。这个方案还让开发者能够自由试验提示词、评估不同模型，并围绕具体用例构建工作流。

这种选择也有代价。本地推理要求店主拥有合适的硬件，推理速度可能慢于托管服务，而且模型生成的信息可能出错。正因如此，应用要求用户在保存前审核 AI 建议。这是对本地推理局限性的诚实回应，也是产品设计上的必要妥协。

开源权重模型（open-weight model） 指模型参数文件公开发布、可自由下载和本地部署的 AI 模型，与只能通过厂商 API 远程调用的闭源模型相对。开源权重不等于完全开源，训练数据和代码未必公开，但使用权和部署权通常较为宽松。对面向小商户的产品而言，开源权重的意义在于：推理成本由本地硬件承担而非按调用量计费，商品图片等经营数据无需离开店铺设备，开发者也能自行微调或更换模型而不被单一供应商锁定。

托管 AI API 指由第三方云服务商提供的模型推理接口，用户按调用次数或 token 数量付费。它的优势是无需本地硬件、响应快、模型能力通常更强，但代价是每张图片都要上传到外部服务器，产生持续费用并涉及数据隐私。对于每天可能要录入几十上百件商品的小店，按次计费会随规模线性增长，而本地推理的边际成本接近于零。这正是 DukaanAI 选择本地方案而非托管 API 的核心权衡。

从项目中获得的经验

开发者表示，构建 DukaanAI 的过程教会了他如何将用户界面、后端 API、图像处理流程和开源权重 AI 模型整合成一个实用应用。

更重要的是一个产品层面的教训：生成文本只是解决方案的一部分。应用必须契合店主已有的工作流程，并且产生足够准确、真正有用的结果。这个洞察指向了 AI 应用落地的核心难题——技术可行性不等于产品可用性。

商业潜力与下一步

DukaanAI 的初始目标用户是需要简单方式创建商品目录的独立杂货店和小型零售商。

开发者计划通过与本地店主测试来验证工具是否真正节省时间。具体做法包括：对比手动录入与 AI 辅助录入的效率，收集关于准确性的反馈，以及询问用户是否愿意为更完整的版本付费。可能的商业模式是月度订阅，但付费意愿需要在定价前得到验证。

未来的改进方向包括：云同步、店铺账户、条形码支持、低库存提醒，以及与现有收银系统的集成。

对 AI 工具落地小商户的启示

DukaanAI 的价值不仅在于它是一个可运行的原型，更在于它展示了一种务实的 AI 应用思路：

本地推理降低门槛。 对小商户而言，将每张商品图片发送到云端 API 意味着持续的成本和隐私顾虑。本地运行开源模型虽然牺牲了速度，但换来了成本可控和数据不出本地。

人机协作而非全自动。 让 AI 生成建议、让人来确认，这种模式承认了当前模型的不完美，同时保留了效率提升的空间。

先验证再扩张。 从 localStorage 存储到单机部署，这个 MVP 的每一步都在控制复杂度，把资源集中在验证核心假设上——照片能否有效转化为库存记录。

如果你经营小型零售生意，开发者的提问值得思考：从照片生成商品目录能否为你节省时间？在真正使用这类工具之前，你还需要什么？