-
feat(引导): 「最忙的那位」补上「另有 N 位也超时效」;修一处注释与 SQL 打架 · f8fd1ee5
**① 只报最忙一位,分不出两种相反的局面**(产品定): · 只有他一个人超 → 该给他少分点 / 改派几个 · 全队都超 → 该减少这批 / 延长时效 同一句话、相反的处置 —— 而本节点唯一的选项是「整批时效改成 N 天」, 碰上第一种局面它本身就是错的(为一个人的负载去延长整批时效)。 ⇒ why 里补「另有 N 位也超过 X 天;每位分完之后要打几天,确认单上逐位都写着」。
⚠ ️ 只加一个数 + 一句引路,⛔ 不在引导里铺开每个人:确认单每行已经有「约 N 天」, 分布本来就在眼皮底下(引导节点的职责是点出要他定的事,不是展示数据)。⚠ ️ 只有一个人超时那半句**不出现** ——⛔ 不制造无谓噪音。📌 加在**工具产出的数据**里(`daily_overload` 的 why),⛔ 没动提示词 —— 模型从返回值里直接读,不需要被提醒(工具返回值 > 提示词)。 **② 团队面板那段注释与 SQL 打架**:注释把「超期」和「在手」并列写成"与窗口无关", 而 SQL 里是 `assignment_expires_at >= since` —— **SQL 是对的**: 一年前过期的单报上来对主管没意义,他此刻能处置的只有近期这批。 ⇒ 改注释、⛔ 别照注释去掉 SQL 的窗口,并把理由写在旁边。 新增 2 条测试(多人超时 → 报数并引到确认单;只有一人超 → 那半句不出现),1298 全绿。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| asr-sensevoice | Loading commit data... | |
| pac-docs | Loading commit data... | |
| pac-service | Loading commit data... | |
| pac-web | Loading commit data... |