这个项目在无锡惠山区阳山镇，客户是一家水蜜桃合作社带着自己的电商公司，三十七户桃农，二百二十亩地。App 是二零二五年三月上线的，会员直销、溯源查询、分销团购三块，桃园地块编码、分拣线电子秤读数、冷库温湿度记录仪的数据都往里灌，传感器是在无锡本地一家做工业物联网的厂子配的。我们是这套系统的APP开发公司，交付之后由同一个团队接着做运维。上线那年的采收季跌跌撞撞过去了，真正值得复盘的是第二年——一个采收季只有三十八天，我们和客户把发版节奏重新排了一遍。

淡季的八个月，二十七条工单里只有三条要动代码

桃子九月中旬就下市了，往后一直到次年五月，这套系统基本处在半睡状态。我们统计过那八个月的全部工单：二十七条。其中十九条属于使用问题，打印机连不上、新来的分拣员账号权限不对、导出的对账单在他们那台旧电脑上打开是乱码；五条是数据订正，多半是桃农把地块编码扫串了；真正需要改代码的只有三条，加起来不到六个人日。

合作社的理事长在三月找我们谈，话说得很直接：一个月四千八，八个月三万八千四，就换来三条改动，这钱花得冤。他的算法没错，按月均摊的运维合同在农产品项目上确实难看，这也是APP开发公司跟农业客户之间最容易扯皮的地方——系统的忙闲跟着果子走，不跟着日历走。但把月费砍到三千，采收季那三十八天就没人扛得住。谈判卡在这里两周，后来换了个思路：总额不动，把工时重新分配。

开摘前四十天，运维工时被重新分成三档

新的运维附件把一年切成三段。淡季，每月八个人时，做安全补丁、微信与应用市场的合规跟进、数据备份校验，用不完不累计；开摘前三十天进入备战档，每周十二个人时，这段时间集中做压测、把上一季攒下的需求做完并上线；采收季内改成值守，不再按工时算，约定十五分钟响应、两小时内闭环或给出绕行方案，我们这边排两个人轮值，其中一人手机必须二十四小时在线。采收季结束后另留四十个人时，专门用来做集中版本。全年总额还是五万七千六，分布完全变了。

备战档那三十天做的事很实在。压测按上一季峰值的三倍来，也就是每分钟一百八十单，跑出来两个瓶颈：溯源详情页每次都实时查冷库温湿度曲线，单次查询要六百多毫秒；优惠券核销接口没加幂等，并发下单时有重复核销的风险。这两处在开摘前十九天改完上线，是这一季唯一一次白天发版。做农产品项目的APP开发公司如果把压测排在开摘前一周，基本就是给自己挖坑，改出来的东西没有足够时间在真实流量前观察。

封版日定在开摘前三天

七月十二日开摘，七月九日封版。封版这个词在合同附件里有明确定义：代码仓库锁定，不接受任何功能提交；价格、库存、运费模板、首页文案、活动开关这些走后台配置的东西照常可改，改动不需要我们参与。这条界线划清楚很重要，去年就是因为没划，客户以为改个包邮门槛也得排队等发版，急得直接给我们负责人打电话。

热修窗口选在凌晨一点到四点，依据是上一季的时段数据：早上六点到八点是桃农扫码录采摘数据的高峰，晚上八点到十点是消费者下单高峰，这两段合起来占日单量的四成七；凌晨一点到四点的订单占比不到千分之六，就算出问题影响面也小。每次热修的规矩写得很细：只修单点缺陷，不带任何新功能，改动行数超过两百行就不许在窗口内做；发版前必须有回滚包，四点前没验证通过就直接回滚，不许拖到天亮。这几条是上一季试出来的，APP开发公司在采收季里最容易犯的错，是趁着热修顺手把攒着的小功能捎带上线。

采收季第六天插进来的排行榜，我们压到了九月

七月十八日，理事长在群里提需求：分销员实时排行榜，要能看到每个人当天卖了多少箱，说是好几个分销员在催。这种需求听上去不大，实际要扫订单表做实时聚合，我们在压测环境里试了一下，三千单量级时那条查询耗时八百多毫秒，正赶上晚高峰会把下单接口一起拖慢。

我们没接，但给了替代方案：把已有的对账导出任务改一下定时表达式和统计字段，每天早上七点跑一次昨日销量，自动生成表格发到分销群。零行业务代码，两个小时上线，用的是配置改动，不违反封版。理事长当时不太满意，觉得不是实时的。这个功能后来在九月四日的集中版本里正式做了出来，上线头三天分销员看得挺勤，第四天起打开率掉到百分之六，到十月基本没人点。回头看，采收季里最贵的东西不是人力，是稳定性，用它去换一个热度只有三天的功能不划算。

两个凌晨窗口实际动了什么

第一次在七月十五日，也就是开摘第三天。溯源页扫码之后首屏要三点二秒才出图，桃农在田头拿手机演示给收购商看，转圈转到尴尬。查下来是图片没走缓存策略，每次都回源拉原图，一张桃园实拍两兆多。凌晨一点二十开始改，转成 WebP 加缩略图，把当季常用的四十多张图预热到边缘节点，首屏降到零点九秒。第二天扫码完成率从百分之六十八回到百分之九十一。

第二次在七月三十一日。冷链那边的快递面单批量导入出了问题，一百五十七单的物流状态卡住不更新。原因是对方系统导出的表格是 GBK 编码，我们按 UTF-8 解析，单号串了位。凌晨那一小时里补了编码自动识别，又加了一道导入前预校验：先解析前一百行，把单号格式和重复项列出来给操作员确认，确认后才真正入库。这个补丁后来一直留着，第二年双十一的礼盒预售也在用。除这两次之外，整个采收季再没动过代码，第三次发版是九月四日的集中版本，把攒了一季的十四条需求一次做完。

三十八天结束后拉出来的几组数字

七月十二日到八月十八日，售出礼盒九千二百四十箱，客单价在一百六十八到二百六十八之间；溯源码被扫了五千六百多次，按箱算扫码率百分之六十一，比上一季高出二十三个点，多出来的部分主要来自那次图片提速；P0 故障零次，P1 两次，就是上面那两次热修；日均工单从上一季的十二条降到三点五条，客服从两个人减到一个人，另一个人调去做分销群运营。九月四日那个集中版本用了六个工作日，比上一季分五次零敲碎打省了差不多九个人日——同样的十四条需求，攒起来一次做，公共部分只改一遍。

写进今年续签合同的那句话

今年续签时，我们在运维附件里加了一张采收日历和一句话：自开摘前三日起至采收结束，非 P0 需求一律进入采收季后的集中版本，双方不再单独议价。这句话里有个细节是吃过亏才补上的——开摘日以合作社的书面通知为准，不写死日期。无锡的桃看天，遇上梅雨拖尾或者连续高温，开摘能提前或推后三到五天，去年合同里写死七月十五日，结果七月十一日就开摘了，封版日形同虚设。同行里做农产品项目的APP开发公司，运维合同十有八九还是按月均摊，附件里连一张采收日历都没有，这一张纸带来的差别比多派一个驻场工程师还大。