三个学生用Django+MongoDB解决农产品滞销

「有人手里有资源，有人急需这些资源，但他们就是碰不到一起。」这是农业和畜牧业里反复出现的困境。三个学生没等别人来解决，直接动手搭了个平台。

谁在用这个系统

AgriExchange的设计很直接：两种角色，两种需求。

农民需要饲料、工具或原材料。供应商手里压着库存卖不出去。现有的平台要么太分散，要么根本不是为直接交易设计的。

所以团队做了角色隔离：

农民端：浏览和申请资源。

供应商端：发布和管理可售资源。

没有多余的功能堆叠，每个人只看到与自己相关的界面。

这种设计选择背后有个判断：农业用户的时间成本很高，学习曲线必须压到最低。

技术选型：为什么选MongoDB

技术负责人Chada Sirichandana在架构上做了务实选择。Django处理业务逻辑和路由，MongoDB存数据。

文档模型的优势在于灵活。农业资源的属性差异很大——饲料有保质期和营养成分，工具有规格和使用年限，原材料有产地和批次。关系型数据库需要预先定义严格的表结构，而MongoDB的文档可以随资源类型变化。

代码里能看到最直接的配置：

MONGO_URI = os.getenv('MONGO_URI', 'mongodb://localhost:27017/')

MONGO_DB = os.getenv('MONGO_DB', 'agriexchange')

环境变量管理，本地开发直连，部署时切到生产集群。没有过度设计。

核心功能拆解

平台做了三件事：资源市场、评分历史、数据看板。

资源市场解决匹配问题。供应商发布库存，农民按需求筛选，系统不做强制撮合，只提供信息层。

评分和历史解决信任问题。农业交易的复购率很高，一次失信会迅速在本地网络扩散。线上评分把这套机制显性化。

数据看板解决决策问题。供应商能看到什么资源流动快，农民能看到什么渠道更可靠。

路由设计暴露了产品的完整逻辑：

/resources 处理资源的增删改查

/transactions 管理交易流程

/match 做资源匹配

/stats 输出统计

/ratings 沉淀信用数据

每个端点对应一个明确的用户动作，没有为了"完整"而硬塞的功能。

前端的选择与妥协

团队没有追求前后端分离的时髦架构。前端用静态文件服务器直接跑，开发时切到5500端口，后端Django开在8000端口。

cd frontend

python -m http.server 5500

这种方案在生产环境需要替换，但原型阶段足够用。资源有限时，先让流程跑起来比架构完美更重要。

几个比预期复杂的点没展开细说，但留下了痕迹。农业用户的设备环境差异很大，从老旧安卓到功能机都有，前端兼容性是隐性成本。

这件事为什么值得关注

AgriExchange的典型性在于：它不是一个技术驱动的项目，而是问题驱动的。

团队先确认了农业资源错配的真实存在，再选择足够用的技术栈，而不是反过来拿着Django和MongoDB找场景。这种顺序在学生项目中并不常见。

更关键的是角色设计的克制。很多平台想通吃供需两端，结果界面臃肿、定位模糊。AgriExchange把农民和供应商彻底分开，牺牲了"一站式"的叙事，换来了更低的认知负担。

如果你也在看垂直领域的资源匹配问题，这个项目的取舍逻辑可以直接复用：先切分用户角色，再压缩每个角色的决策路径，最后用最小可用的技术栈验证假设。

农业数字化喊了很多年，真正落地的往往是这种轻量、具体、不试图解决所有问题的工具。