自行车店库存系统
一家自行车店其实是共用一间库房的三门生意：一间摆满高价整车的展厅、一整面装着成千上万种细小易耗零件的零件墙，还有一个悄悄从两边取货的维修部门。大多数现成的 POS 工具把这一切硬塞进一份扁平的商品清单，于是一台 5000 美元的电动自行车和一个五毛钱的气门嘴帽被同样地计数，到了夏天数字就全乱了。本文将带你走一遍一家车店真正需要的库存系统，以及如何把它作为一个运行中、托管的应用搭建在 ybuild 上、通过你自己的域名对外提供服务。
痛点
- 每一款车型都以尺码和颜色组成的矩阵形式出货，所以「库存有一台 Trek Marlin」这句话毫无意义。在你向顾客承诺之前，你需要知道它是一台哑光蓝的中码车，正躺在 R3 号货位上。
- 整车和电动车都带有车架序列号，但它们要么塞在鞋盒里，要么躺在一张表格里，于是只要有人拿着一个序列号和一段说辞走进店里，保修理赔和被盗找回就当场瓦解。
- 维修部门整天都在安装链条、线管和内胎，而这些零件几乎从来没有被扣减过，于是整个季节里货架上的数字都在悄无声息地偏离真实。
- 旺季波动剧烈，但如果没有按每个变体设定的补货点和真实的动销数据，季前进货就是一场猜谜，结果要么压着一堆卖不动的死库存，要么在四月份卖断了人人都要的那个尺码。
你能搭什么
一套两层结构的商品目录：车型（Trek Marlin 7，2026 款）是一个商品，而每一种尺码与颜色的组合都是它自己的变体，各自拥有独立的条码、成本、售价、数量和货位。整车和电动车还会成为带序列号的单件，每一副实体车架对应一行，于是库存永远不是一个含糊的车型级数字。从第一次构建起，它就在 ybuild 上以在线托管的方式运行。
一个接车与工单界面，技师针对一辆顾客的车开一张工单、添加工时行项、并领用零件。每添加一个零件，都会从销售区所出售的同一份库存里扣减，于是店后面的维修间和店前面的卖场终于共用同一份诚实的数字。
一个进货视图，浮现出每一个低于补货点的变体，按供应商分组、按动销排序，并附上所有顾客的特别订货。你从这里起草采购单，按这些采购单收货，库存就带着正确的成本和货位落位——全都在你那个在线运行的 ybuild 应用里完成。
数据模型
系统里的一天
- 早晨：来自经销商的一批货到店。你逐箱扫描，按那张未结的采购单收货，于是库存带着正确的成本和货位落到对应的变体上。
- 这批货里的每一台整车，都会被扫描车架序列号、录入为一件带序列号的单件并标记为 in_stock，把那副具体的实体车架和它的变体绑在一起。
- 一位到店顾客想要一台绿色的中码砾石公路车。你查一下变体矩阵，看到 R3 号货位上还有一台库存，便把它预留下来，免得别人抢在他前面把它卖掉。
- 结账时，这笔销售扣减那个变体、把这件带序列号的单件翻转为 sold、连同一个保修到期日一并绑定到顾客名下，并提示你去登记车架序列号以备日后被盗找回。
- 一位熟客把车留下来做保养。你针对他那件单件的序列号开一张工单、设定一个承诺取车日期，工单便进入维修队列。
- 技师添加了工时，外加一根新链条、两根线管和一条内胎。每个零件在被加进工单时就从库存里扣减，于是无论零件是从柜台卖出去还是在后面装上车，数字都保持真实。
- 一天结束时，补货仪表盘标出每一个低于补货点的变体、按供应商分组、并起草采购单，其中也包括那些正等着你店里没有存的尺码的顾客的特别订货行项。
- 你盘点一个货位，把实物点数与系统对账，任何差异都会记在那个变体名下，于是损耗变得可见，而不再是年终时的一个意外。
AI 容易出错的地方
- 把一款车型当成一个 SKU。车型不是库存，尺码与颜色的变体才是。如果表结构不把车型和变体拆开、不让每个变体各自携带自己的数量、成本、条码和货位，你就会超卖一个自己根本没有的尺码，整份库存也随之沦为虚构。
- 用同一种方式给带序列号的整车和散装零件建模。一副车架是一个独一无二的单件，拥有唯一的序列号和一条生命周期（收货到售出到保修）；而一箱内胎则是可互换的数量。若强行用一种模型套住两者，你要么得给内胎编造假序列号，要么会把一台 5000 美元电动车的序列号弄丢。你需要一个数量层和一个序列号层。
- 让维修工单绕开库存。技师装上的每一个零件都必须从卖场所出售的同一份库存里扣减，否则数字整个季节都在漂移。粗糙的做法只追踪工时，却忘了一张工单同样是一笔库存交易。
- 打断「序列号—顾客—保修」这条链。保修理赔和被盗找回都取决于车架序列号加购买日期加车主。如果序列号只是一条自由文本备注，而不是一条互相关联的记录，那么当一副被盗车架送上门时你答不出「这是不是我们店卖的车？」，两年后也没法处理一次保修。
- 把单件的状态混为一谈。已预留、已售出、送修保修中是三种不同的状态。把它们合并，一台实物已经不在的车会仍然显示为可售，或者一笔已预留的特别订货被卖给了一位到店顾客。要把单件状态显式地建模，并且绝不让库存变成负数。
- 那套两层目录：商品到变体（每个变体各自的数量、成本、条码、货位），再加上给整车用的带序列号单件。这是其余一切都挂靠其上的脊梁。
- 销售点扣减：扫描一个变体条码或一个车架序列号，把它卖出去，看着数量下降、单件翻转为已售、并关联到顾客身上。
- 那个补货视图：每一个低于补货点的变体，按供应商分组，随时可以转成一张采购单。
- 一套完整的会计总账。导出一份 CSV 给你的记账员或 QuickBooks，而不是在应用里重建一套总分类账。
- 一个面向顾客的线上店面以及网店同步。v1 阶段做的是店内卖场，不是全渠道；等数字变得可信之后，再把线上补上。
- 自动化的供应商目录和 EDI 数据接口。先从手工录入采购单和收货做起；等核心流程稳固之后，再接上电子经销商目录。
常见问题
一款车型有五个尺码、三种颜色，我该怎么处理？
把它建成一套两层目录。车型（Trek Marlin 7，2026 款）是一条商品记录，而每一种尺码与颜色的组合都是它自己的变体，各自拥有独立的条码、成本、售价、数量和货位。库存永远落在变体上、绝不落在车型上，所以「库存有三台」永远是指某个具体的尺码和颜色，你也就绝不会不小心卖掉一台自己其实没有的大码车。
我真的有必要追踪车架序列号吗？
对整车和电动车来说，有必要。车架序列号正是把某一件具体单车与它的买家、它的保修期以及任何被盗理赔绑在一起的东西。把这些车建成带序列号的单件，每一副实体车架对应一行、各带一个状态，而把内胎、线管和螺栓保留为单纯的数量。在销售当下把序列号登记到像 Bike Index 这样的公共登记平台上，万一日后被盗，也有助于把它找回来。
维修工单怎样才不会把我的库存数字搞乱？
让工单成为一笔库存交易。当技师往一张工单里加入一根链条或一条内胎时，那个零件就从卖场所出售的同一份库存里扣减。工时另行计费，但每一个离开货架的实物零件——无论是从柜台卖出，还是在后面装上车——都出自同一份数字。
如果顾客想要一件我店里没存的东西，它能处理这种特别订货吗？
能。一笔特别订货就是一条绑定到某位顾客的采购单行项。你向供应商订下那个具体的变体，货到时按采购单收货并被标记为已被预订、而非自由库存，于是在你的顾客来取货之前，它不会被卖给一位到店顾客。
这套系统对季前进货和季节性有什么帮助？
因为每个变体都带着一个补货点、系统也在追踪真实的动销，补货仪表盘会在临近春天时显示哪些货在动、哪些已经跌破阈值。你就从那个视图里向供应商下采购单。重点不是把进货决策自动化，而是把「货架 对 需求」的画面摆得一清二楚，让你在最忙的几个月到来之前不必再靠猜。
参考来源
- NBDA 2025 专业自行车零售渠道研究 — 美国自行车经销商协会（NBDA）的行业基准报告，基于 200 多家美国零售商编制，涵盖库存管理、维修运营和技术采用。
- Bike Index — 一个非营利的自行车登记平台，许多车店在销售当下用它登记车架序列号，从而支持被盗找回和保修查询。
- Bicycle Retailer and Industry News：零售现状（POS 调查） — 对车店老板的访谈，谈他们所使用的 POS 与库存系统，突出实时库存和单品动销报表是他们最为倚重的功能。
描述它，一次性上线到你自己的域名——托管、全栈、无需服务器。免费开始。