一份采购询价发出去，几十家供应商，迟迟没人回。什么时候该催、该催谁？这件事过去全靠运营同事的手感。我们想把它变成系统每天算出的一份名单。
这件小事教了我两课：怎么用数据定阈值，以及怎么把人的经验写成系统不能越过的规则。
第一课：阈值不是拍的
「久没回」到底是多久？我们把历史上每一次「询价发出 → 供应商第一次真实回信」的时间差量了一遍（自动回复不算回）。分布非常陡：会回的人，两小时内基本已经回了；过了一天，几乎不会再有人回。
数据印证了业务同事的直觉，也给了一个可以写进代码的数字：近期交付的单等满两小时进名单，远期单等满一天。为什么近期单只等两小时？因为多等一小时只多等到很少一点回复，而对一天后就要交付的订单，早一小时是实打实的机会。
第二课：不催谁
比「催谁」更重要的是「不催谁」。催回用的是我们在供应商那里的信誉，催错了比不催更贵。业务同事有四条不成文的规矩，我们把它们写成了硬规则：
- 这一单已经拿到足够多的报价，不催。 催回的目的是拿到报价，不是收齐回执。
- 交付日期已过，不催。 再催只显得我们没看订单时间线。
- 已经等了超过一天，不催。 数据说这时候催也不会有回音，只剩打扰。
- 同一轮询价只催一次。 催过没反应就停手。
还有一条容易被忽略的：按订单判断，不按供应商判断。 一次询价常常群发几十家，最后只有几家会回。如果按「谁没回就催谁」，一次就要给几十家同时发第二封信——而历史数据显示，群发对象里的大多数从来不回，催他们改变不了结果。所以判断单位是「这一单缺不缺报价」：缺，才进名单；不缺，剩下没回的就让它去。这一条规则挡掉了绝大多数不必要的催促。
系统的边界
系统只算名单，不发信，也不写业务系统。催信仍由人发。这不是技术做不到，而是刻意的：催回消耗的是人际信誉，这种资源的支出应该由人来签字。
为什么值得写
这是一个非常小的功能。但它的做法可以复用到几乎所有「把运营判断交给 AI」的场景里：
- 先量历史数据，让阈值有出处；
- 把业务同事的经验写成不可越过的硬规则，而不是让模型「综合判断」；
- 把判断单位选对（是订单，不是供应商）；
- 把消耗信誉的动作留给人。
智能体减负，人拍板。把重复劳动一段一段交出去，但每一段都知道边界在哪。