refactor(plan): 删掉"容量"这个数,批次人数改基数 + 落人走水位法
主管走查抓到死路:批次规模 = Σ(容量−在手) 时,**第二批必然是 0** —— 第一批把所有人填到水位,再算就是 Σ(20−20)。想连着圈两批人分,只能把容量 往上棚,而容量会被记住 → 下周的"习惯"是个虚高的数。 根子是一个数当了两个用:「这轮推多少」和「一个人最多压多少」。拆开后发现 上限那一半根本不需要 —— 负载不需要阈值,inHand 本身就是负载。 · 基数改为 **本批人数 N(首次 100)+ 时效(3 天)**,都沿用主管上一次的值; 容量、AGENT_CAPACITY_RANGE、capacityRange 全删。 · 落人第二趟由「轮转均分」改 **水位法**:每条都给当前在手最少的人。 均分是"每人加一样多",起点不齐终点还是不齐;水位法把差距抹平。 ·🔴 **专属那一趟也受目标水位约束**(=(团队在手+N)/在岗人数,由 N 推出,非新旋钮): 容量删掉后没东西约束专属了,实测 100 条里 76 条是同一人的专属,他吃到 76, 水位法只剩零头可铺。加约束后同一批变成每人 5~6 条。 超出份额的专属转 spread_overflow(关系还在,这轮没轮到),语义同原「专属已满转铺平」。 · 按客服精调 capacity → maxThisBatch(本批名额,0 = 这轮不给),不再是"上限"。 · 沿用同时认新键 batchSize 与老键 target —— 否则改版后所有人的沿用静默退回默认。 · 卡片「已满未分配」改「本批未分到(在手 N)」:没有上限了,写「已满(0)」自相矛盾。 本地实测:1,081 候选 → 本批 100 人铺给 17 位客服,分完后每人在手 5~6 条, 池子里还有 981 人排队(话术明说"随时可以再分一批")。986 tests green。 教条 T22 整节重写,把这条弯路记进去。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Showing
This diff is collapsed.
Click to expand it.
This diff is collapsed.
Click to expand it.
This diff is collapsed.
Click to expand it.
This diff is collapsed.
Click to expand it.
Please
register
or
sign in
to comment