SurplusLink AI：用开源大模型盘活烘焙尾货的B2B平台

在食品行业，每天都有大量包装烘焙产品因临近保质期而面临价值折损；话说回来，小型零售商却苦于找不到价格合适的批发货源。SurplusLink AI 试图用开源大模型和规则引擎搭建一座桥梁，把批发商的过剩库存变成零售商的采购机会。本文基于该项目在 Hacktoberfest 挑战中的提交内容，拆解其产品逻辑、技术架构与商业化设想。

从痛点出发：过剩库存与采购需求的错配

食品制造商、烘焙坊和批发商经常要面对一个现实问题：库存必须在失去商业价值前卖掉。而小型零售商虽然需要低价货源，却缺乏直接触达合适批发商的渠道。SurplusLink AI 的切入点正是这个供需匹配的空白。

该项目定位为面向巴基斯坦市场的 B2B 过剩包装烘焙品交易平台原型，初期品类限定为饼干、面包干、薄脆饼干和曲奇等密封包装商品。作者明确表示，真实部署还需要配套的产品验证、保质期管控和食品安全合规措施，这说明团队对业务边界有清醒认知。

核心工作流：AI 只做语言理解，规则负责商业决策

SurplusLink 最值得关注的设计是严格区分 AI 与业务逻辑的职责。批发商录入产品详情、数量、要价、位置和保质期信息；零售商则用自然语言描述需求，例如“我需要拉合尔地区 150 包饼干，预算 2 万卢比以内，剩余保质期至少 30 天”。

开源语言模型负责从这段非结构化文本中提取品类、数量、单位、预算上限、城市和最低剩余保质期等字段，提取结果先经 Pydantic 校验，缺失字段不做猜测，由用户复核确认后才保存。随后，后端用确定性的业务规则完成库存匹配——包括品类、单位、数量、城市、保质期和价格等维度。

这种分工的价值在于：AI 解决了买卖双方描述方式不一致的可用性问题，但定价、库存分配这类涉及资金的决策仍由可测试、可解释的规则引擎完成，避免了把关键判断交给黑箱模型。

Pydantic 是 Python 生态中广泛使用的数据验证库，其核心机制是开发者用类型注解定义数据模型的结构与约束，库在运行时自动校验传入数据是否满足这些约束，并在不满足时抛出清晰的错误信息。在 SurplusLink 的场景中，语言模型从零售商自然语言中提取的品类、数量、预算等字段本质上是不可信的原始输出，可能存在缺失、类型错误或超出合理范围的情况。借助 Pydantic 定义需求模型后，系统可以强制要求每个字段的类型与取值范围，把校验失败或不完整的提取结果拦截下来交还用户复核，而不是让脏数据流入后续匹配环节。这种“模型输出先过结构校验”的做法，是大模型应用工程化中控制输出可靠性的常见手段。

技术实现：以交易系统而非聊天机器人为中心

作者在架构上的关键选择是“把 SurplusLink 当作交易市场而非 AI 聊天应用来做”。后端数据模型覆盖组织、企业成员、过剩库存、买家需求、报价、成交、支付和交易事件，使用 PostgreSQL 管理关系，SQLAlchemy 与 Alembic 负责模型定义和版本化迁移。

库存一致性是交易系统的命门。项目定义了一条明确规则：可用数量 = 总数量 - 预留数量 - 已售数量，从而把已成交订单占用的库存与已提货库存区分开。报价被接受时，后端会校验库存可用性并以事务方式预留库存，防止同一批货被重复分配给多个买家——在可能同时吸引多位买家的市场中，这是必须解决的问题。

AI 推理层通过 GroqCloud 调用托管的开源 Llama 模型，免去了在开发机上下载模型权重的麻烦，同时将模型调用封装在提供方接口之后，便于后续替换其他兼容模型。匹配引擎支持双向发现：买家可以找货，卖家也可以找需求。

Alembic 是 SQLAlchemy 官方配套的数据库迁移工具，用于把数据模型的每一次结构变更（如新增表、修改字段、添加索引）记录为可版本化、可回放的迁移脚本。对于交易类系统而言，数据库结构会随业务演进不断调整，若靠手工改库，开发、测试与生产环境极易出现结构不一致，进而引发难以排查的故障。Alembic 通过维护一条迁移版本链，使团队能够按顺序升级或回滚数据库结构，并让代码仓库中的模型定义与线上库结构保持同步。SurplusLink 将其与 SQLAlchemy 模型定义配合使用，意味着订单、库存、报价等核心表的结构演进被纳入工程化管理，这对一个需要长期维护真实交易数据的平台来说是必要的基础设施。

“以事务方式预留库存”中的事务，指数据库事务（transaction）：一组操作要么全部成功提交，要么全部失败回滚，不会出现中间状态。在库存预留场景中，系统需要在确认报价被接受的同时，原子地增加该批库存的预留数量并写入订单记录；如果两个买家几乎同时接受同一批货的报价，缺少事务保护就可能导致超卖或重复分配。借助数据库事务与行级锁，后到的请求会看到已被占用的预留量，从而在校验阶段被拒绝。这一机制与“可用数量 = 总数量 - 预留数量 - 已售数量”的规则相配合，构成交易系统防止库存不一致的核心防线，也是区别于普通聊天应用的关键工程要求。

商业模式：交易抽佣而非订阅

SurplusLink 设想以交易费而非月费创收：买家服务费 2%，卖家佣金 2%。以 150 包饼干、单价 120 卢比的批发交易为例，交易小计 18000 卢比，买卖双方各付 360 卢比费用，买家实付 18360 卢比，卖家实收 17640 卢比，平台毛收入 720 卢比。

作者特别声明这只是说明性商业场景，并非真实收入，原型也不处理真实资金交易。这种克制的表述值得肯定，但它同时暴露了一个待验证的问题：2% 的双边费率在低单价、低毛利的尾货生意中是否具备足够吸引力，仍需真实市场检验。

交易抽佣（take rate）是双边市场平台常见的变现方式，平台按成交金额的一定比例向买方、卖方或双方收取费用，其收入随交易规模增长而自然放大，无需依赖用户数直接付费。相比订阅制，抽佣模式在冷启动阶段对商家更友好——没有成交就不产生费用，降低了小零售商尝试的门槛。但其可行性高度依赖两个条件：一是平台确实促成了原本无法达成的交易，二是抽佣比例相对于单笔交易的毛利足够低，不至于侵蚀买卖双方从尾货低价中获得的收益。在低单价、低毛利的过剩食品生意中，2% 的双边费率是否可持续，取决于平台带来的匹配效率提升能否覆盖这笔成本，这也是该模式最需要在真实市场中验证的假设。

开源权重模型带来的灵活性与边界

该项目选择开源权重模型的理由很务实：对小团队而言，价值不在于训练更大的模型，而在于把现有模型用在具体问题上，并用可靠的软件工程兜住输出。托管推理降低了基础设施门槛，模型集成可被隔离替换，业务逻辑保持可控。

作者也坦率指出了边界：使用开源权重模型并不自动意味着应用是私密、离线或零成本的，托管推理仍有提供方成本和数据处理方面的考量，接入真实商家前需要评估。未来可针对本地批发库存描述（包括乌尔都语-英语混用术语和商品缩写）对模型进行评估或微调。

开发过程中，作者使用 OpenAI Codex 辅助实现 FastAPI 端点、数据库模型、Alembic 迁移、AI 推理集成和前端对接，但先自行定义市场架构、业务工作流和技术需求，再让 AI 实现和细化组件，从而把精力集中在后端架构、库存管理和交易处理的理解上。

编辑观点

SurplusLink AI 的启发不在于“用 AI 做了个市场”，而在于它对 AI 边界的处理方式：让模型处理模糊的自然语言，让规则处理明确的商业逻辑。对于想用大模型改造传统行业流程的开发者，这个原型提供了一个可复用的思路——先想清楚哪些决策可以交给模型，哪些必须留给可审计的代码。项目目前仍处于原型阶段，食品安全合规、双边冷启动和费率可行性都是它从黑客松走向真实生意必须跨过的门槛。