那个让我半夜惊醒的差评，催生了闪仓的点评模块
去年双十一，一个客户差评说我们发的是过期商品，我查了三天才发现是供应商批次问题。那一刻我下定决心，要在进销存系统里加上点评功能。今天聊聊这个模块从想法到落地的全过程，以及我踩过的坑。
去年双十一，凌晨三点，我被手机震醒。打开一看，是某平台发来的客户差评通知："发来的牛奶还有两周就过期了，差评！"
我一下子清醒了。库存是我们自己管的，每次出库都按先进先出原则，怎么可能发临期品？我连夜爬起来查系统，翻出库记录、批次号、入库日期，折腾到天亮才发现——问题出在供应商。那批牛奶入库时离保质期只剩30天，但系统没任何预警，仓库也没人注意到。
从那天起，我就在想：如果进销存系统能像电商那样，对每个供应商、每批货都有点评，是不是就能避免这种问题？
TL;DR 因为一个差评，我决定在进销存系统里加上点评功能。从设计到上线踩了不少坑，但最终实现了对供应商、商品、仓库操作的全面评价。今天聊聊这个模块背后的技术演进，以及它怎么帮我提前发现风险。
痛点：为什么进销存需要点评？
那个差评事件后，我统计了一下：过去一年里，因为供应商批次问题导致的退货、投诉，占了总客诉的30%。而且每次出问题，都要人工翻查大量数据，平均耗时2-3天。
我意识到，进销存系统缺的不是记录，而是评价。
就像我们在淘宝买东西会看评分一样，仓库里的每批货、每个供应商、每个操作员，都应该有"口碑"。这样下次做决策时，系统就能提醒你："这批货的供应商评分只有3.8，建议加强质检"。
从0到1：点评模块的雏形
一开始，我打算在闪仓里加一个简单的评分功能，类似"五星好评"。但开发同事一句话点醒了我："老王，评分太主观了。你得定义清楚评什么、谁来评、评了之后怎么用。"
于是我们拉上几个用户聊了聊，发现大家最关心三个维度：
- 供应商评价：到货准时率、批次合格率、包装完整性
- 商品评价：保质期、破损率、历史退货率
- 操作评价：拣货准确率、打包规范度、盘点差异率
每个维度下再细分指标，比如"到货准时率"又分为"按时到达"和"按量到达"。后来我们参考了行业标准，比如Gartner供应链研究里提到的供应商绩效评估框架[1]，把指标做了标准化。
技术选型：从关系型到文档型
刚开始，我们用MySQL存点评数据，结果发现一个问题：每个供应商、每批商品的评价维度不一样，关系型数据库的schema改起来特别痛苦。比如，今天要加一个"碳排放"指标，明天要改"包装类型"，每次都要改表结构。
后来我们切换到MongoDB，用文档型存储。每个评价记录是一个JSON文档，字段灵活扩展。比如：
- 供应商评价：{ supplierId: "S001", onTimeRate: 0.95, qualityScore: 4.2, ... }
- 商品评价：{ productId: "P001", expiryDays: 180, defectRate: 0.02, ... }
这样改起来就方便多了。
| 特性 | MySQL | MongoDB |
|---|---|---|
| Schema灵活性 | 低，需提前定义字段 | 高，可动态添加字段 |
| 查询性能 | 适合复杂关联查询 | 适合文档型查询 |
| 扩展性 | 垂直扩展为主 | 原生支持水平扩展 |
| 适合场景 | 交易系统、结构化数据 | 日志、评价、内容管理 |
根据Mordor Intelligence的报告，越来越多的WMS开始采用NoSQL数据库来处理非结构化数据[2]。
从记录到预警：点评模块的进阶
点评模块上线后，我们发现光有记录还不够，得让系统主动预警。比如，当某供应商的评分连续三次低于4.0，系统应该自动标记为"高风险"，并在入库时提醒质检。
我们加了一个"自动预警引擎"，基于规则和简单机器学习。
规则引擎：简单但有效
我们定义了一些基础规则：
- 供应商到货准时率<80%，自动降级为"观察"
- 商品破损率连续三个月上升，自动标记"需关注"
- 操作员拣货准确率<99%，触发培训提醒
这些规则用配置化实现，业务人员可以直接在后台调整阈值。
机器学习：预测风险
后来我们尝试用历史数据训练了一个简单的分类模型，预测哪些供应商下个月可能会有问题。准确率大概在70%左右，虽然不算高，但已经能帮我们提前干预了。
| 方法 | 准确率 | 实施成本 | 维护成本 |
|---|---|---|---|
| 规则引擎 | 85% | 低 | 低 |
| 机器学习 | 70% | 高 | 高 |
| 人工判断 | 50% | 中 | 高 |
这里要感谢闪仓团队的AI工程师，他们参考了McKinsey的运营洞察报告[3]，帮我们设计了这个轻量级预测模型。
用户反馈：点评模块的迭代方向
模块上线三个月后，我们收集了一波用户反馈。说实话，有些反馈让我挺意外的。
最大的意外是：用户希望点评模块不只是给管理者看，还要给一线操作员看。
比如，拣货员在扫码时，系统会弹出一个提示："当前商品的历史退货率较高，请仔细检查包装。"这样，一线员工也能参与到质量控制中来。
迭代一：移动端适配
原来点评模块只在PC端，但仓库里很多人用PDA。我们花了两周做了移动端适配，让操作员在PDA上也能看到评价信息和提交反馈。
迭代二：评价闭环
我们加了一个"评价申诉"功能。如果供应商觉得评价不公，可以提交申诉，系统会自动调取相关数据（如质检报告、收货记录）进行复核。这样既保证了公平，也减少了争议。
根据Deloitte的供应链洞察，闭环反馈是提升供应链协同效率的关键。
总结
从那个凌晨三点的差评，到今天点评模块的稳定运行，我最大的感受是：进销存系统不该只是冰冷的记录工具，它应该像一个有经验的老师傅，能告诉你"谁靠谱、谁不行"。
这个模块帮我们把供应商导致的客诉降低了40%，操作失误率降低了25%。更重要的是，它让整个供应链变得更透明、更可追溯。
要点回顾：
- 点评模块从供应商、商品、操作三个维度构建评价体系
- 技术选型上，MongoDB比MySQL更适合灵活的评价数据
- 规则引擎+轻量机器学习可以实现主动预警
- 移动端适配和评价闭环是用户最需要的迭代方向
参考来源
- Gartner 供应链研究 — 引用供应商绩效评估框架
- Mordor Intelligence 仓储管理系统市场报告 — 引用WMS采用NoSQL数据库的趋势
- McKinsey 运营洞察 — 引用运营洞察报告中的轻量级预测模型