先看一个每周都在上演的场景。活动复盘会上，运营和增长吵了半小时：一份数据说这次触达渗透率 12%，另一份说只有 4%。差别不在效果，而在「这批人是谁」——一份按「注册满 90 天」圈人，另一份按「近 30 天有下单」圈人。两组人数量差了三倍，分母都不一样，效果自然对不上。
用户分群和人群画像这件事，看着像数据活儿，难点其实在「把话说清楚」：一群人凭什么被归到一起、这个归法谁认、分完之后对谁做什么。而中间恰好有大量可规则化的重复劳动：标签口径登记、名单去重、条件校验、口径变更比对。这些正是能交给 Agent 的部分。
先说清这篇的位置。站内相邻的几篇都不在这个角度上：用 AI Agent 做渠道归因分析 管的是结果已经产生之后「功劳算谁的」；用 AI Agent 做销售漏斗健康检查 管的是线索在哪个环节卡住、跟进节奏对不对；OpenClaw 做客户回访与满意度调研 管的是名单已经到手里之后怎么触达、怎么回收；用 AI Agent 做销售线索整理 管的是单条线索怎么从表单和邮件变成跟进清单。这一篇管的是更前面的一段——把一堆人按可复述的规则分成若干组，每组有名字、有口径、有明确用途。
一、先把三件事分清：画像、分群、触达
很多「用户运营项目」做不下去，是因为一开始就把三件事混成了一件：
- 画像解决的是「这个人身上有哪些可用事实」。它是描述问题。
- 分群解决的是「按什么规则把一批人划到同一组」。它是划分问题。
- 触达解决的是「对这一组人做什么、什么时候做、做完怎么算」。它是动作问题。
混在一起的典型症状是：改一个标签口径，三份名单全变，没人说得清哪一版才是这次活动真正用的。所以第一刀要先切开：标签是原料，分群是配方，触达是成品。
二、标签从哪来：三类标签与口径
标签不要一上来就堆数量，先按来源分成三类，每类只回答一个问题：
- 事实标签：客观发生过的，比如注册渠道、首单时间、是否开过发票。这类最难吵，因为是事实。
- 统计标签：在一段时间内数出来的，比如近 30 天下单次数、客单价分档、最近一次登录距今天数。这类最容易出分歧，因为口径可改。
- 推断标签：模型算出来的，比如流失倾向、品类兴趣偏好。这类只能用于辅助，不能用于硬规则。
每个标签必须写清六项，缺一项就先别上线：名称与别名（含历史叫法，不然老报表对不上）、业务定义（不许写「大概是活跃用户」）、计算口径（分子分母与去重方式）、时间窗口（自然日还是滚动 30 天）、过滤条件（排不排内部测试账号）、责任人。这跟 用 AI Agent 做数据仓库分层与自助取数 里的指标字典是同一套逻辑——口径写不出来，说明这件事还没想清楚。
三、分群规则怎么写才可维护
分群规则最常见的死法，是写得只有当初那个人看得懂。四条底线：
- 规则要可复述：能对着一张 A4 讲清楚，讲到同事能照着圈出同一批人。
- 条件是「且」还是「或」要显式写：别让「近 30 天有下单 且 客单价高于 200」被误读成「或」。
- 每个分群给稳定 ID 与版本：改动留痕，不覆盖旧版本，否则历史活动没法复盘。
- 分群数量要克制：一屏能看完的 5～7 个够了，超过这个数就没人真的按组区别对待；同时留一个「其他」兜底组，避免有人落不进任何组。
四、Agent 能做与不能做
这块边界必须写在最前面，不然 Agent 会越界去做它不该做的判断。
- 能做：按已有口径生成名单 SQL 或筛选条件、跨来源做去重、校验规则有没有互相矛盾（比如同时要求「已下单」和「从未下单」）、监控口径变更影响哪些历史分群。这和 用 AI Agent 做埋点方案设计与校验 的思路一致——Agent 管一致性与完整性。
- 不能做：不定义新口径（口径是业务决策，不是模型推断）、不替人拍板「这批人算不算目标客群」、不直接连生产库自由写查询。
五、触达名单的三条硬规则
名单是从分群到动作的最后一跳，也是最容易出事的地方。三条规则设成硬性的：
- 去重：同一个人只能进一个名单，跨名单冲突按优先级裁决，别让用户一天收到三条互斥的推送。
- 排除：退订、投诉、内部测试账号在生成名单时自动剔除，不靠执行的人记得。
- 冻结：名单定稿后打一份快照，之后标签再变也不影响已发出的名单。不然「当时到底发了谁」永远说不清。
六、效果回流：分群不是一次性动作
分群做完就散，是最常见的浪费。每个分群上线时就要配一个成功指标，并明确它怎么算、看多久。指标口径和护栏怎么定，可以参照 AI Agent 改了之后怎么知道真的变好了 里的 A/B 思路——没有对照的分群，效果只是感觉。同时上游的数据质量要有人管，空值、重复、旧数据先进门就拦，这部分交给 OpenClaw 数据质量门禁 那套规则来处理。如果发现某个分群连续两轮效果都低于基准，就该评估是不是要拆组或退役，而不是年年照发。
七、落地四步
- 先收标签：把散在各部门的标签集中登记，补全六项口径，砍掉没人用得上的。
- 再定分群：按业务动作反推需要哪几组人，而不是从数据里能分出几组就建几组。
- 然后接名单：把去重、排除、冻结三件事做成流程里的固定步骤。
- 最后做回流：每组配指标与观察周期，两轮不达标就评估退役。
八、五个坑
- 口径只活在口头：会上说清楚了，没人写下来，下周换个人又吵一遍。
- 标签越多越好：建了几百个标签，常用的不到二十个，剩下的只会让人选错。
- 分群一次定死：业务已经变了，分群还是半年前那套，效果自然一年不如一年。
- 名单不去重：同一个用户被三组人同时触达，体验直接变差，投诉也来了。
- 只看发送量不看回流：发出去多少条是过程指标，真正该看的是每组人有没有被改变。
九、适合谁
这套做法适合已有一定用户量、开始按人群做差异化运营的团队：电商、SaaS、内容平台、企业服务都可以用。如果量还很小、每次活动就那么几十个人，靠人记着就行，不必上系统。判断标准很简单——当你开始为「这批人到底是谁」开第二个会，就说明该把口径写下来了。
