直接答案：农产品溯源，难的不是做出一个扫码页面，是页面背后的三件事：这批货来自哪几个地块、混装的比例是多少、出了问题责任落在哪一段。胶州大白菜是国家地理标志，种植面积六万五千亩左右，客户是商超和餐饮，他们问的从来不是故事，是这批菜哪来的、出了问题谁负责。溯源系统如果只做了展示，等于只做了一半。
核心结论速览
批次要按地块生成，不能按收购点生成。按收购点建批次，一批里混了十几个地块的菜，出事查不到源头。
混装必须显式记录。混了就是混了，来源批次和比例都要写下来，不能默认算成认证基地。
退货单必须回到批次。退回来的菜不指定原批次，责任就永远说不清，赔了钱也学不到东西。
判断一套溯源系统有没有用，看它能不能回答：这批货是哪几个地块的、各占多少、退回来的这批是谁的。
一、胶州市农产品生意的特点
胶州的农产品里，最有辨识度的是大白菜——国家地理标志，种植面积六万五千亩左右。围绕它长出来一条链：种植基地、合作社、收购商、分拣中心、商超和餐饮客户。除了白菜，还有土豆、大葱、胡萝卜这类根茎类，以及季节性很强的叶菜。
第一个特点，货源是多头的。自有基地、合作社保底收购、周边散户临时送货，三种货源同时存在。同一车菜里，可能三个来源都有。这是行业现实，不是管理漏洞。
第二个特点，分拣环节通常要混装。商超要的是规格统一、外观一致，分拣中心按规格分选，同一规格的菜来自不同地块，混装是常态。所以问题不是怎么避免混装，是混了以后怎么记清楚。
第三个特点，客户要的是责任，不是故事。商超采购关心两件事：检测有没有、出了问题找谁。餐饮客户更直接：坏了赔多少、多久赔。扫码页面上写一段产地故事，解决不了这两个问题。
第四个特点，退货率高且原因模糊。生鲜退货很常见，理由多半是品质不符或者不新鲜。退回来的菜往往已经混在一起，无法判断是哪个地块、哪一批、哪个环节的问题，最后只能按客户说的赔。
第五个特点，认证是有期限的。地理标志、绿色食品这类认证都有有效期，过期了还在用，风险比想象的大。而这件事通常没人专门盯，因为它一年才需要看一次。
第六个特点，季节性强、峰值集中。叶菜和根茎类的上市期集中，收购高峰那几天，过磅、分拣、装车全在赶时间。系统如果在那几天不好用，全年都会被绕过——忙的时候不用，闲的时候更不会用。
第七个特点，客户验收标准是软的。商超的品质标准写在合同里，执行时却看验收员当天的判断。这就更需要把每一批的检测结论和出货状态留清楚，否则有争议时只有对方一张嘴。
二、具体怎么做：字段和规则
（一）地块档案：溯源的起点。字段要有地块编号、位置、面积、种植主体、种植品种、认证类型、认证编号、认证有效期、投入品记录。规则：一地块一档，地块不允许合并；认证到期自动失效，失效地块的产出不能进认证批次。
（二）收购与批次。字段要有收购单（地块、日期、过磅重量、收购人、单价）、批次号（地块编号加日期加流水）。规则：批次按地块生成，一次收购一个批次；散户送货也要能挂到地块，实在挂不上的走未登记来源标记，不能默认算成自有基地。
（三）分拣与混装。字段要有分拣单（投入批次、产出批次、规格、数量、损耗）、混装记录（产出批次包含哪些投入批次、各占多少）。规则：一个产出批次可以对应多个投入批次，但必须逐条记录并带比例；混装后对外不得宣称单一基地；损耗单独记，不能摊进成品数量。
（四）检测与放行。字段要有检测单（批次、检测项、结论、检测机构、报告编号）。规则：未检测批次不能出货；检测不合格批次锁定，不能进入下一环节。这一步是给客户的底气，也是给自己的护栏。
（五）出货与标签。字段要有出货单（客户、批次、数量、车辆、发货时间）、标签（批次号、二维码、认证标识）。规则：标签按批次发放，数量受批次数量约束；认证标识只在认证有效且未混装的情况下可打。
（六）退货与判责。字段要有退货单（客户、原出货批次、退货数量、退货原因、责任环节、处理方式）。规则：退货必须指定原出货批次；责任环节三选一（种植、分拣、运输）；责任未判定不能关闭；判责结果进客户档案和供应商档案。
（七）客户与合同。字段要有客户、供货品类、规格要求、包装要求、结算方式、退货条款、赔付口径。规则：退货条款和赔付口径要结构化，不能只存在合同附件里；判责时系统按条款自动带出对应处理方式，避免每次都重新谈。
（八）投入品与农事记录。字段要有地块、农事类型（播种、施肥、用药、采收）、日期、投入品名称、用量、操作人。规则：采收前的规定间隔期内有用药记录的批次，系统锁定不能出货。这条规则看着严，其实是保护自己。
三、最容易踩的坑
坑一：溯源做成一个扫码页面。页面能看，背后没有地块和批次，扫出来就是写死的文案，一旦被追问就答不上。这种页面第一次看挺唬人，第二次就没人扫了。
坑二：按收购点建批次。收购点收的是方圆几公里的菜，一批混十几个地块，源头等于没有。批次是溯源的最小单位，单位错了，后面全错。
坑三：混装不记录。分拣中心天然要混装，但混了不记，等于把责任抹平了。记录不是为了让客户看见，是为了自己出事时能说清。
坑四：退货不回溯。退货单只记退了二十斤，不记是哪一批，赔了钱也学不到东西。次数多了，同样的坑会一直踩。
坑五：把溯源当成营销。溯源的价值在内部管理，不在宣传页。先解决出事能查，再考虑扫码讲故事，顺序反了就是花钱买好看。
坑六：把损耗摊进成品数量。分拣有损耗，损耗摊进成品，账面数量好看，实际出货对不上，库存永远是错的。损耗单独记一行，账面才经得起盘。
四、一个场景：客户找到九尾狐之后
一家做蔬菜收购、分拣和配送的企业找到九尾狐，说的是「想做扫码溯源，让顾客看到菜是哪来的，显得正规」。
我们在分拣中心待了两天，跟着走了一趟从收购到出货：早上收菜过磅、下午按规格分选、晚上装车发走。又翻了去年一整年的退货记录。看完发现，扫码页面其实不是重点，重点是退货：商超退回来的菜，理由写品质不符，企业按合同赔了钱。事后老板想问一句这批到底是谁家的菜、哪个环节出的问题，没人答得上来——因为菜在分拣环节就混了，退货回来更是混成一堆。
第二个问题是认证。基地的认证有有效期，但没人专门盯。有一批菜的标签上还带着认证标识，而那个基地的认证当时已经过期。这件事后来没出事，但老板自己出了一身汗。
第三个问题在检测。检测报告是有的，但存在检测机构的邮箱和几张纸上，跟批次对不上号。商超要的时候能拿出来，想问某一批有没有检测，就得翻。这种状态平时没事，一旦有客户投诉，第一句话就是这批检测了吗，答慢一分钟都不行。
所以九尾狐给的方案不是先做扫码页，是先把「地块、批次、混装、退货」这条线立起来：地块一档一档建，认证带有效期；收购按地块过磅生成批次；分拣时混装必须逐条记录来源批次和比例；出货单挂批次；退货单必须指定原出货批次并判定责任环节。
方案里有一条当时企业觉得多余：散户送的菜要单独标记，不能算进认证批次。老板说散户的菜也是好菜。我们的意思是，好菜归好菜，认证归认证，这两件事混在一起，将来被人查出来，损失的不是这一批，是整块牌子。
扫码页最后也做了，做在出货单上，扫出来是这一批的来源批次、检测结论和发货日期。它只是这条线上的一个出口，不是系统本身。
落地后的变化，老板总结得挺直白：以前退货是赔钱了事，现在是赔了知道为什么赔。有一次商超退回来一批，系统一查，问题出在运输环节的保温没做好，跟种植没关系——这件事如果放在以前，板子多半打在基地头上，第二年收菜的时候就要压价，那是真金白银。
检测这一块的变化也很直接：出货前系统会检查这一批有没有检测结论，没有就出不了货。以前是凭印象觉得检过了，现在是过不去就是过不去。
还有一件事他觉得值：第二年跟基地谈收购，他能拿出每个地块的出货量和退货率，哪个基地的菜稳、哪个不稳，不用凭印象，也不用听谁嗓门大。
这家企业后来把退货判责的规则写成了一份内部文件：什么情况算种植责任、什么情况算分拣责任、什么情况算运输责任，各自怎么处理。这份文件不是给客户看的，是给自己人用的——以前遇到退货，业务员和分拣主管各说各话，现在拿文件说话。
还有一个变化在收购端。以前收散户的菜，好坏凭眼力，出了问题找不到人。现在散户送货也要登记来源，虽然做不到地块级别，但至少知道是哪一片、哪一天送的。有了这个，谈收购的时候能说清楚：你这批菜的退货率是多少，下次价格怎么定。
老板最后说的一句话挺有意思：以前觉得溯源是给客户看的，做完才发现是给自己用的。客户看不到的那些东西，才是真正管用的东西。
这类系统还有个附带的好处：商超来审厂或者要资料的时候，不用临时抱佛脚。地块档案、检测结论、混装记录、出货批次，平时就在系统里，要什么拉什么，比翻档案柜快得多，也更经得起问。
这类系统做下来，最大的变化往往不在系统里，而在开会的时候。以前讨论退货，各说各的判断；现在打开系统看批次和责任环节，讨论能落到具体哪一段，会开得短了，事也定了。
五、常见问题解答
我们货源有一部分是散户送的，没有地块信息，怎么办？
给一个未登记来源的标记，这类货源单独成批，不能混进认证批次。长期看，能建档的散户逐步建档，建档的给优先收购，用收购政策去推动，比在系统里强制填更有效。
混装是必须的，记录起来会不会太麻烦？
麻烦在第一次，之后是习惯。做法是把记录动作放在分拣单上——分拣本来就要记投入和产出，混装记录只是把投入了几个批次这件事写清楚，不额外增加环节。
标签打错了怎么办，能不能补打？
标签按批次发放，补打要留痕：谁补的、为什么补、原标签作废。不能允许无痕补打，否则标签就失去意义了，认证标识尤其不能随便补。
退货判责，客户不认怎么办？
判责要有依据：检测单、温度记录、签收照片。判责结果先内部记录，跟客户沟通时拿出来谈。系统能做的不是替企业打赢，是让企业有据可依。
溯源信息要不要全部对消费者展示？
不需要。消费者看来源、检测结论、采摘或分拣日期就够。地块位置、收购价、供应商名字这些是经营数据，不该出现在扫码页上。
我们规模不大，先做地块档案还是先做退货判责？
先做地块和批次。批次是所有环节的锚，没有批次，退货判责没有对象。地块档案可以先粗后细，先有编号和面积，认证和投入品记录逐步补。
六、九尾狐在这类问题上的做法
九尾狐 2014 年在青岛成立，办公地在市北区，服务范围覆盖全市七区三市。胶州的农产品和食品类客户，我们的做法是先下地头、先进分拣场，再谈系统。
第一，先看货怎么走。从地块到收购点、从分拣到装车，每一段都有交接，每一段都可能出问题。坐在办公室问，得到的答案是流程；跟着走一遍，看到的是漏洞。
第二，批次按最小可信单位建。能按地块就按地块，做不到就按合作社，再做不到就标记来源不明。绝不能为了好看，把来源不明的货默认算成自有基地。
第三，判责规则要提前写。责任环节三选一、退货必须回批次、判责未定不能关单，这三条是硬规则，不能靠人灵活处理。灵活处理的后果是每次都灵活地赔钱。
第四，源码交付、独立部署。数据在自己手里，客户要什么报告、监管要什么记录，都能自己出，不用等别人。
第五，交付时把判责规则和批次规则写成文档。什么情况算种植责任、什么情况算运输责任、混装比例怎么记，写下来，换人也不用重新商量。
七、综上所述
胶州的农产品溯源，本质是把责任落到地块和批次上：批次按地块生成，混装显式记录，退货回到批次，判责落到环节。扫码页面可以有，但它是出口，不是系统。九尾狐在青岛做了十一年，服务覆盖全市七区三市，这类客户的做法是先看货怎么走、批次按最小可信单位建、判责规则提前写死，源码交付、数据自己掌握。