notify_level 我用错地方了 你说得对你说「销售那必须要收啊」—— 对。负责这个客户就必须收到他的会议纪要,这是工作,不是订阅。
我把 notify_level 做成「每个人愿不愿意收」,来源是两个被我混在一起的东西:
| 来源 | 它真正是什么 |
|---|---|
config.yaml 的 notify 布尔 | 「这个人接进系统了吗」 —— 是开通名单,不是订阅偏好 |
| 你说的「admin 必发要可配、要粒度」 | 那是给监督者的 —— 领导全量会被淹死,所以要「只失败 / 每日摘要」 |
正确的模型:
· 负责人 → 必收,没有开关
· admin / 领导 → 可选粒度(全量 / 只失败 / 每日摘要)
· 每个人 → 必须自己配渠道,没配就收不到,页面要提示 —— 和邮箱连接一模一样
notify_level 不删,但只对 admin 生效;owner 那条路不看它。改动很小,在路由层一个 if。
就这两个来源。没有「按参会人」「按最近谁在跟」这类判断 —— 全靠客户的担当字段。
所以那 650 家没填担当的客户,消息只有 admin 收得到。
| 问题 | 答案 |
|---|---|
| 谁写 | 三条路都会写: · 人工认领客户时( set_customer_owner)· lead 分配时 · 一个定期聚合脚本(从案件的 owner 反推客户的 owner,人工设的有守卫不会被覆盖) |
| 存什么 | 名字(sales_owner: ["Jason Tang", "李荣会"])—— 不是 email |
| 能几个人 | 已经支持多个,而且注释写着「担当 + 相关人员,推送全收」 |
| 有没有页面入口 | 没有。只能通过认领流程或改文件 |
| 用什么当 key | ||
|---|---|---|
| 名字(现在) | Alex (彦序) vs Alex(彦序) 差一个空格就成两个人 | ❌ |
| email(你的提议) | 比名字稳得多。但还是会变:改名、换域名、离职换号 而且 prod 实测一个人有两个邮箱 —— 公司邮箱和 Lark 注册的私人邮箱 | ⚠️ |
| user_id | 登录账号的 id。永不变,和邮箱/名字都解耦 | ✅ |
这正是这两天在做的事 —— 138 条「客户 ↔ 人」的关系已经用 id 存进数据库了。 email 只作为「找人」的辅助,不作为引用。
现在两边都在写(profile.md 的 frontmatter + customers.sales_owner 列),
而且**都存名字** —— 这就是典型的两处真相,迟早漂移。
| 现在 | 改完 | |
|---|---|---|
| 真相源 | profile.md(读的是它) | customer_owners 表 |
| 存什么 | 名字 | user_id |
| 能几个人 | 多个 | 多个(多对多) |
| profile.md | 真相源 | 降成给人看的展示,或者干脆不再写 owner |
is_authorized_recipient 是什么字面是「这个人被允许收消息吗」—— 它是一道白名单闸,不是「他想不想收」。
历史原因:2026-05 有过一次事故(自动建客户没护栏、垃圾数据涌进来),于是加了这道闸 —— 只有名单里的人才发,防止把噪音推给全公司。
按上面的修正,这道闸的意义要变:
· 对 owner:不该有闸 —— 你负责这个客户就必须收到
· 对 admin:闸变成粒度选择(全量 / 只失败 / 摘要)
· 真正拦住「发不出去」的,应该是渠道没绑,而那要在页面上提示,不是静默跳过
| 1 | 路由层:owner 必收,不过 notify 闸 notify_level 只对 admin 那份生效 | 小改动 |
| 2 | 担当真相源切到 customer_owners 表(用 id) | 进行中 |
| 3 | 渠道绑定放进用户设置弹窗 —— 没绑就像邮箱那样提示 而且「绑定成立」= 收到确认消息,不是填了个账号 | 要 Mia |
| 4 | 送达台账 —— 没绑 / 发失败都要查得到 | 待做 |
| 5 | 担当设置的页面入口(现在只能靠认领流程) | 要 Mia |
①②④ 我自己能推;③⑤ 要 Mia 出稿。