1. 课程导入与追溯场景认知
食品批次追溯看板不是一个孤立的可视化页面，而是把“原料入库—生产投料—成品赋码—仓储出库—终端流向”这条链路中的批次信息，压缩成可查询、可下钻、可判断的界面。学习本课程，首先要建立三个认知：追溯为什么值得做、监管到底要求什么、看板在整个追溯体系中处于什么位置。只有把这三件事想清楚，后面的数据建模、接口对接和看板开发才不会变成“堆图表”。
一、食品批次追溯的业务价值
食品行业的质量问题有一个显著特点：同一条生产线、同一批原料，可能在短时间内产出大量成品并分散到多个区域。一旦某批原料被检出农残超标或微生物不合格，企业面临的核心问题不是“有没有问题”，而是“问题涉及哪些成品、已经流到哪里、需要召回多少”。批次追溯的价值就体现在把这个问题从“靠人回忆、翻纸质记录”变成“按批次号在系统中正向、反向各查一遍”。
具体来说，追溯能力带来四类直接价值。第一是召回精准度：能定位到具体批次和收货方，避免整品类下架造成的浪费。第二是响应速度：监管问询或客户投诉时，能在分钟级给出批次流向，而不是数天。第三是质量归因：通过批次关联，把成品异常回溯到原料供应商、生产班次、关键工序参数。第四是合规与品牌信任：完整的批次记录是应对飞行检查、客户审厂和平台抽检的基础材料。
需要强调的是，追溯的粒度由业务决定。以乳制品为例，原料奶按收奶罐次、成品按生产日期+班次+灌装线组批，是常见做法；而预包装调味品可能按“同一原料批次+同一生产日”组批。粒度太粗，召回范围过大；粒度太细，赋码和记录成本陡增。课程项目中我们采用一个可落地的示例设定：成品批次号 = 生产日期（8位）+ 产线代码（2位）+ 当日流水号（3位），例如 20240518A01037，原料批次则沿用供应商批号并建立关联表。
二、典型监管要求与追溯要素
国内食品追溯的监管要求分散在《食品安全法》、GB 14881（食品生产通用卫生规范）以及各类专项规定中，核心要求可以归纳为“记录真实、链条完整、保存期限达标、可快速提供”。对看板开发而言，更值得关注的是监管检查时实际会看哪些字段。通常包括：原料名称、供应商、原料批号、入库数量与日期；生产日期、班次、产线、投料批次与用量；成品批号、数量、检验结果；出库日期、经销商/收货方、数量。这些字段构成了追溯的“最小数据集”。
此外还有两条容易被忽视的要求。一是关联关系必须可验证：不能只记录“用了某原料”，还要能说明“哪一批成品用了多少该原料”，否则正向追溯会断链。二是记录保存期限：一般要求保质期满后保存6个月，没有明确保质期的保存2年以上。看板本身不存储全部原始记录，但必须能通过批次号跳转到对应的记录系统。
三、看板在追溯体系中的定位
很多初学者会把看板等同于追溯系统，这是定位偏差。完整的追溯体系通常分为四层：最底层是数据采集层（MES、WMS、ERP、赋码设备、检验系统），中间是批次关联与存储层（批次主数据、投料关系表、出入库流水），上层是追溯服务层（正向/反向查询接口、召回范围计算），最上层才是展示与决策层，也就是我们要做的看板。
看板的职责是“把已经算好的追溯结果以可读的方式呈现，并支持有限的交互下钻”，它不负责重新计算投料关系，也不应绕过服务层直接拼SQL查业务库。明确这一点，能避免开发中把大量业务逻辑塞进前端，导致口径不一致、性能不可控。下面的图示梳理了看板在追溯体系中的位置，以及它与其他系统的数据关系。
四、课程项目目标与交付物
本课程以一个虚构但贴近实际的场景贯穿：某中型食品加工企业生产调味酱与复合调味料，已有ERP和WMS，但批次信息分散，质量部接到客户投诉后需要人工翻台账。课程目标是开发一个可运行的批次追溯看板，支持输入成品批次号查看原料构成与检验结果，输入原料批次号查看受影响的成品与出库流向，并给出召回范围提示。
围绕这个目标，课程将逐步完成以下交付物，它们也是检验学习成果的依据：
- 追溯数据模型：批次主表、投料关系表、出入库流水表、检验记录表的结构设计与示例数据。
- 追溯查询接口：正向（原料→成品）与反向（成品→原料）两个查询的输入输出约定，含分页与异常返回。
- 看板页面：批次检索区、追溯链路视图、流向列表、召回范围提示区四个功能块。
- 验收用例：至少覆盖“正常批次双向追溯”“原料无关联成品”“成品无检验记录”三类场景。
为了让项目可控，示例数据规模设定为：原料批次约40条、成品批次约120条、投料关系约300条、出库记录约200条。这个规模足以体现查询与展示的真实问题，又不会让开发被数据量拖累。后续章节中出现的具体数值，除特别说明外均为教学示例或合理假设，不代表任何真实企业的实测数据。
本章的落点是一个判断：看板的价值不在于图表数量，而在于能否让使用者在最短时间内回答“这批货有没有问题、问题在哪、影响多大”。带着这个判断进入后续的数据建模与接口开发，才能保证每一行代码都服务于追溯本身。