企业微信智能运营怎么做

可行范围由「错了谁兜」决定

判断一个运营动作能不能交给模型，先问三个问题：结果谁看得到、错了多久能发现、发现了能不能撤回。这几个问题站内讲自动运营那篇用来判断「要不要交给规则」，换成模型之后判据不变、结论只会更保守：三个答案把所有运营动作切成三档，而模型能力在这条线上几乎不起作用 —— 再强的模型也有非零错误率，不可撤动作的错误成本不会随着准确率提升而线性下降，从 95% 提到 98% 并不能把「发错了要赔钱」变成「发错了没关系」。

• 内部只读：值班摘要、异常巡检、待办生成、会话质检抽样。错了最多浪费一次人工确认。
• 外部可撤：一条能再补一句解释的回复、一次能改的群公告、一个能撤的标签。错了要道歉但不出事。
• 外部不可撤：客户分配、退款与承诺、发给一批人的批量内容、涉及金额与时限的答复。错了要赔。

三档对应三种交付形态：第一档直接做完，第二档做初稿等人按发送，第三档只排序只提示、决定权不交出去。绝大多数「智能运营做不下去」的项目，问题都不在模型，而是把第三档的动作按第一档的形态交付了 —— 上线一周出一次事故，第二周开关就被关掉，然后整个项目背上「AI 不靠谱」的结论。

先上巡检和摘要，不是先上回复

团队上智能运营，第一个想做的几乎都是自动回复。这是收益最不确定、争议最大、也最容易被叫停的入口。真正该先上的是对内那一档，具体说是三件事：值班摘要、异常发现、待办生成。它们有个共同点 —— 现在由人做，做得慢且不稳定，而且做错了下一个环节立刻会发现。

值班摘要：把一段时间内多个账号、多个群的会话压成一份可读的交接文档，接班的人五分钟看完就知道昨天发生了什么、哪几件事悬着。这活人工要做半小时，还高度依赖写的人当天的状态；模型做得比人稳定，格式统一，漏了什么下一班一看就知道。唯一的硬要求是每条摘要都要能点回原文，不能核对的摘要用久了会被当成事实引用，那就成了新的风险源。

异常发现：从会话流里找出「客户问了三次没得到答复」「同一个问题当天出现十次」「这个群突然安静了两天」。前两个规则能覆盖，第三个和「客户语气开始不耐烦」这类只能靠模型读语义。这一档的原料就是消息与事件流本身，用 wecomapi 的事件回调把会话与群变更接进来落到自己的库里，模型只在离线链路上读，全程不参与任何对外动作，风险敞口是零。

待办生成：把会话里出现的承诺抽成待办挂到人身上 —— 客户说「那你明天发我报价」，坐席回「好的」，这就是一条明天到期的待办。承诺兑现率是私域里最便宜的提升点，而它完全不碰外发。这三件事跑两周，团队会建立起「模型的输出是要被人看的」这个习惯，后面推草稿队列会顺很多。

中间那档：草稿队列，不是自动发

对外可撤的动作，正确形态是草稿队列：模型生成，人在一个集中的界面里扫一眼，采纳、改一下再发、或者直接丢弃。这个设计经常被嫌「不够智能」，但它是目前唯一能同时拿到效率和可控性的形态，而且它给出的数据比任何离线评测都真实。

草稿队列和站内讲自动运营那篇里的人工辅助走的是同一条路，区别在于这里的内容是模型写的：人要做的不是从几条备选里挑一条，而是逐条比对它有没有说错。所以界面的优化目标是「减少要读的字」—— 把草稿依据的客户事实并排放在旁边，让人一眼判断得出有没有说错，比省掉一次点击有用得多。点击当然也别浪费：默认聚焦第一条、单键采纳、单键跳过、改完自动记录差异、键盘能走完全程。这部分的工作量通常比接模型大，也是最值得投人的地方。

唯一有意义的指标是采纳率和改动率，而且要一起看。采纳率低说明生成不可用，方向错了；采纳率高但改动率也高，说明模型抓对了方向没抓对细节 —— 这两种问题的解法完全不同，前者要换提示或换输入，后者往往只是缺了几条业务事实。只报一个采纳率的看板，看不出该改哪。

// 示意逻辑：发送走 wecomapi 的 /message/sendText，字段与端点以线上文档为准
// 这里只表达状态顺序：生成 → 抢占 → 校验 → 发送 → 归档
async function onAdopt(draftId, operatorId) {
  const d = await drafts.claim(draftId, operatorId);   // 抢占，避免两个人同时处理
  if (d.state !== "pending") return;                   // 已被别人处理过
  if (Date.now() - d.createdAt > DRAFT_TTL) {          // 过期草稿不许发
    return drafts.close(draftId, { state: "expired" });
  }
  await send({ guid: d.accountGuid, toId: d.toId, content: d.finalText });
  await drafts.close(draftId, {
    state: "sent",
    edited: d.finalText !== d.draftText,               // 改动率的原始数据在这里
  });
}

过期时间这条不要省。运营场景里时效性极强，二十分钟前该发的那句话，现在发出去可能比不发更糟 —— 客户已经自己解决了，或者已经在群里抱怨过一轮了。草稿默认带 TTL，过期自动作废并计入一个单独的指标：作废率高说明值班人手不够，或者队列推送的节奏不对，这是排班问题不是模型问题。

不可撤那档：只排序，不决定

客户分配、退款审批、承诺时限、批量外发 —— 这些动作模型能参与的只有排序和提示。给坐席一个按紧急度排好的待办队列可以，替他把客户分给谁不行；把可能相关的三条历史工单推到侧边栏可以，替他决定这单退不退不行。

区别不在技术难度，在追责链条。分配错了要能说清依据是哪条规则、规则是谁定的、什么时候改的；模型给不出这个链条，事后复盘会变成「模型当时是这么算的」，这是任何一个运营负责人都不能接受的答案。技术上你甚至可以让模型解释它的理由，但那段解释是生成出来的，不是决策依据，拿去和业务方对账会更糟。

有一种折中值得推荐：模型出建议、规则出依据、人一键确认。建议排在最前面，旁边写清楚命中了哪条规则、参考了哪几个字段，确认动作留给人。效率能拿到七八成，责任链一点没断。真正做过的团队会发现，人在这个界面上点确认的速度，比自己从头查一遍快一个数量级 —— 收益主要来自信息聚合，而不是来自替人做决定。

真正的工程量在上下文供给

智能运营做不好，八成不是模型不行，是喂进去的东西不对。运营场景要的上下文和客服场景很不一样：客服要的是眼前这一通对话，运营要的是这个客户过去三个月的轨迹、他所在的几个群现在什么状态、销售手上还有哪些没做完的待办。这些东西散在不同系统里，口径还经常对不上。

• 时效对齐：模型看到的数据有多旧要明确写出来。用一份延迟半小时的活跃标签去判断「现在该不该联系」，结论会系统性地偏，而且偏得很隐蔽。
• 权限对齐：模型能读到的范围不能超过使唤它的那个人能看到的范围，否则一份跨部门摘要就是一次数据泄露，而且没人会立刻发现。
• 口径对齐：同一个「活跃客户」在报表里和在模型提示里必须是同一个定义，否则运营会同时收到两个互相矛盾的建议，然后两个都不信。

落地上省事的做法是先把消息、群变更与客户变更收敛成一条流：用 wecomapi 的统一事件订阅把这几类事件一次接齐，落到自己这边再做归并与口径统一，比让每次模型调用现去三四个系统里拉数据可靠得多，也快得多。中间这层归并是自己的资产 —— 换模型、换场景它都不用动。

还有一件小事影响很大：给模型的每一份上下文都带上数据截止时间，并在界面上显示出来。人看到「基于 14:30 之前的数据」，会自己判断要不要再刷一次；看不到这行字，就会默认它是实时的，然后在一次重要沟通里用了两小时前的库存数。

落地顺序与三个止损信号

1. 1对内摘要与巡检跑两周，先把数据管道和「模型输出被人看」的习惯建立起来。
2. 2挑一个高频、低风险、话术相对固定的场景上草稿队列，只上一个，把交互打磨到一屏十条。
3. 3采纳率稳定在一个团队能接受的水平之上，再横向扩场景；扩的时候先复用同一套队列界面。
4. 4不可撤那一档最后碰，而且只做建议加一键确认，不要在这一档上追求全自动。

三个止损信号：草稿采纳率连续走低；人开始绕过队列直接手工做；摘要发出去没人点开。任何一个出现，先停下来查上下文供给和交互路径，不要第一反应换模型 —— 这类问题里能靠换模型解决的比例，远低于「查出来喂进去的数据是三天前的」。