一、项目背景

这个项目的客户是一家省级农资流通企业，下面挂着一百七十多个县级经销商，再往下是三千多家乡镇零售店，主营化肥、农药、种子。农资这个行业有个绕不开的东西叫赊销：春耕时农户没钱，先把肥料化肥拉走，等秋收卖了粮再结账。这不是个别现象，客户的赊销占比常年在百分之五十五上下。

赊销靠什么维持？靠人情和熟人关系。零售店老板认识每个来赊账的农户，谁家几亩地、种什么、往年还款怎么样，全在他脑子里。这套系统在小范围内是有效的，但一旦规模上去就崩了。客户财务给我看过近三年的坏账数据，年均坏账率百分之三点二，绝对金额三千多万。更麻烦的是账龄，很多赊账挂了两三年，零售店老板还在说"再等等，明年一定还"。

农技服务是另一块。农资卖出去只是开始，怎么用、什么时候用、出了病虫害怎么办，农户都得问。以前靠业务员上门指导，一个业务员管三四十家零售店，根本跑不过来。指导内容也没沉淀，同一个稻瘟病的问题，今年跟这个农户讲一遍，明年跟那个农户再讲一遍。有经验的老业务员一退休，那些知识就跟着走了。

二、落地场景

我们用 XpShop 的 S2B2C 供应链平台搭主干，把品牌商、县级经销商、乡镇零售店三层组织串起来，AI 部分做了个农技知识库跑在集团私有化底座上。

客户授信分级替换了原来的人情判断。系统给每个下游客户算一个授信额度，输入包括历史采购额、历史还款记录、经营年限、门店规模、当地作物结构、抵押担保情况。额度不是一次定死的，每季度重算一次，还款好的自动上浮，出现逾期的立即冻结增量。

赊销额度与账期管控放在下单环节。零售店在系统里下单选赊销的时候，系统实时判断可用额度和当前逾期情况，超额或者有逾期就下不了单，只能改现款。这个卡点上线时阻力很大，后面细说。

农技知识库和到田服务工单是服务侧。农户或者零售店老板在小程序上描述问题，可以拍照上传，系统给出初步判断和处置建议。判断不了或者情况严重的，转成到田服务工单派给区域农技员，农技员到现场处理完回填结果，这个结果又回流到知识库。

回款预警是运营抓手。系统按账期算出每个客户的应收时间点，提前十五天、七天、三天推提醒，逾期后按天数分级升级，从提醒零售店老板到通知区域经理，再到进入催收流程。

三、关键技术挑战与解决思路

授信模型这块，我们最开始想做得挺"先进"，用机器学习跑一个评分卡。数据准备阶段就撞墙了。客户的历史数据里，还款记录是有的，但很多是事后补录的，日期不准；经营年限靠业务员填，填的时候随手写；作物结构这类信息压根没有。用这种数据训出来的模型，AUC 只有零点六二，比人工判断强不了多少。

后来改成规则打分加少量模型修正的混合方案。基础分由几条明确规则算出来，历史采购额、按期还款率、经营年限，这三项占七成权重，都是数据质量相对可靠的字段。模型只负责在基础分上做一个正负百分之十五以内的调整，输入是那些质量一般但有一定信号的特征。这样即使模型判断失误，兜底的规则分也不会让额度偏离太离谱。客户风控总监对这个方案的评价是"看得懂，敢用"。

赊销拦截上线时是最难的一段。第一周就有二十多个县级经销商打电话到总部投诉，说系统不让下单，耽误了春耕销售。有个经销商在电话里直接说，你们要是不放开，我这些客户全跑到别家去。当时压力确实大，客户内部也有声音说要不要先关掉。

我们和客户一起做了个折中。加了一个"例外审批"通道，超额订单可以提交申请，由区域经理和风控双签通过后放行，但每笔例外都会记录在案，并且计入该经销商的例外次数。例外次数多的经销商，下季度授信额度会被下调。这样既没有一刀切堵死业务，又给了约束。上线三个月后，例外申请从第一周的一百六十多笔降到每周十几笔，大部分经销商已经适应了在额度内运作。

农技内容结构化的挑战在于原始素材太散。客户手上有的是几百个 Word 文档、上千张病害照片、还有业务员群里的聊天记录。我们的处理是先定一套农技知识的结构模板，按作物、生育期、问题类型、症状描述、诊断依据、处置方案、用药建议、注意事项这些字段来组织，然后用大模型从原始素材里抽取填充，抽完由客户的农艺师审核。审核这一关不能省，农药用量这种东西错了是要出事的，我们把审核状态做成了强制字段，未审核的内容不进检索库。

弱网环境是农村场景绕不开的问题。农技员到田里，很多地方只有 2G 信号甚至没信号。小程序改成了离线优先的模式，工单信息提前下载到本地，现场填写和拍照都存在本地，有信号时自动同步。照片做了压缩和分片上传，单张压到两百 KB 以内。同步冲突的处理规则是以现场提交时间为准，服务端不覆盖。这块调了很久，最开始用的标准上传组件在弱网下失败率高达四成，换成分片加断点续传后降到百分之三点五。

案例片段（已脱敏）：授信额度计算的规则部分配置。

yaml credit_score:  base_rules:    - {field: annual_purchase_amt, weight: 0.30, buckets: [[0,50w,40],[50w,200w,65],[200w,500w,85],[500w,+inf,95]]}    - {field: on_time_repay_rate, weight: 0.28, buckets: [[0,0.7,20],[0.7,0.9,60],[0.9,0.98,85],[0.98,1.0,100]]}    - {field: business_years,      weight: 0.12, buckets: [[0,2,40],[2,5,70],[5,10,88],[10,+inf,95]]}  model_adjust:    range: [-15, +15]    features: [作物结构稳定性, 区域灾害频次, 门店面积, 上游品牌集中度]  limit_formula: "min(score/100 * annual_purchase_amt * 0.45, cap_by_level)"  recalc_cycle: quarterly  freeze_on: {overdue_days: 30}

案例片段（已脱敏）：一次到田服务工单的完整流转记录。

ticket=FS-2026XXXX-0912  crop=水稻  stage=分蘖期 report: 店主上传3图，描述"叶片有梭形斑，边缘褐色" ai_pretriage: 稻瘟病(叶瘟) conf=0.87 | 胡麻叶斑病 conf=0.09 ai_advice: 建议三环唑或稻瘟灵，注明当地近30天降雨偏多需注意复发 dispatch: 农技员 A0271，距离 14.6km，接单耗时 22min onsite: 离线填报（现场无信号），2h17min后回城同步成功 confirm: 确诊叶瘟，实际用药与AI建议一致，追加田间排水建议 feedback_to_kb: 新增1条区域案例，标注"高湿田块复发风险"

四、效果数据

系统运行到现在十一个月，跨过了一个完整的春耕和秋收周期，数据相对可信。

逾期率从百分之十八点七降到百分之六点九。降幅最大的是三十天以内的短期逾期，说明提醒机制起了作用，很多逾期其实是忘了，不是还不起。

坏账率从百分之三点二降到百分之一点一。这个数字客户比较满意，按他们的销售规模算，一年少损失两千多万。

回款周期从平均一百三十八天缩短到九十四天。资金周转快了之后，客户跟上游厂家谈账期的底气也足了一些。

农技工单闭环率百分之九十一点三。这里的闭环指的是从提报到现场处理再到结果回填的完整流程走完。剩下的百分之八点七主要是农户自己解决了不需要上门，或者季节过了问题不存在了。

农技知识库现在有结构化条目四千二百多条，覆盖当地主要的十七种作物。AI 预诊断的准确率，按农技员现场确诊结果比对，一致率百分之八十二点四。这个数字不算特别高，但作为初筛给农技员做参考已经够用，客户的农艺师说最大价值是"把常见问题挡掉了，农技员能腾出时间处理疑难的"。

弱网同步成功率百分之九十六点五，剩下的失败基本是农技员当天完全没进过有信号的区域，第二天补同步。

文中数据均为项目复盘口径，已做脱敏。

五、可复用经验总结

风控类的功能，技术做出来只是三成，剩下七成是怎么让业务接受。我们在赊销拦截这件事上差点翻车，救回来靠的不是技术优化，是那个例外审批通道。留一个有代价的口子，比堵死更容易推行。这个思路后来我们在别的风控项目里也用上了。

数据质量决定模型上限，这话说了很多年，但真到项目里还是容易高估自己。授信模型那次，我们在数据准备上浪费了三周才承认此路不通。现在做类似的事情，我会先花两天做数据画像，看看关键字段的完整率和可信度，再决定模型的定位是主力还是辅助。

农业、医疗这类专业领域的知识库，专家审核环节不能省，也不能弱化。我们把审核做成硬门禁，未审核内容不进库，客户一开始嫌慢，后来发生过一次未审核内容被误放出来的事故，用药量写错了一位，还好农技员发现得早。从那之后客户自己坚持这个门禁比我们还严。

面向农村和田间的应用，网络条件要按最差情况设计，不是按平均情况。我们最初测试都在办公室和县城做，一切正常，到了田里才发现问题。后来项目组的人跟着农技员下过三次田，很多设计细节是在地头改出来的。这种事没有捷径，只能去现场。

分层组织的系统，权限和数据隔离要在最开始定清楚。品牌商能看到什么、县级经销商能看到什么、乡镇零售店能看到什么，这三层的边界我们中途调整过一次，代价是改了十几个接口。如果重来一次，我会在需求阶段就把三层的数据可见范围画成一张表钉死。

目前客户在推的下一步是把农技服务和商品推荐打通，农技员诊断出病害后直接关联可用药品和库存，这块涉及用药合规，还在跟当地农业主管部门确认口径。