随缘惜情做阿里云代理商这几年，团队群聊经历过一段特别混乱的时期：客户消息、阿里云通知、工单提醒、续费预警全堆在飞书群里，谁有空谁接单，忙起来就漏消息，漏了又没法追责。后来我们在群里加了一个叫“小龙虾助手”的机器人，把阿里云侧的消息统一收进来，按关键词和优先级自动@负责人，再把任务同步到飞书多维表格，这才算把分工理顺。这篇文章就是一份完整的配置指南，从建飞书群机器人、申请阿里云 RAM 权限，到写转发脚本、接多维表格做任务池，全程按我们实际跑通的方式写，适合代理商团队、代运维伙伴以及所有想把飞书群变成“自动派单台”的朋友。
1. 先搞清楚：小龙虾助手到底是个什么东西
1.1 代理商每天都在哪些“信息孤岛”里切换
代理商团队和普通企业有个很大的区别：我们一边要盯阿里云控制台的各种状态，一边要处理客户在飞书群里的咨询，中间还夹着工单、备案进度、产品到期提醒，甚至还有客户私下发来的截图。这些信息分散在不同的系统里，天然形成了一座座“孤岛”。我见过太多团队的做法是：每隔一会儿刷新一次控制台，看到新工单就在群里吼一嗓子“有没有人接”，然后等着某个同事回复“我来”。消息少的时候没问题，一旦旺季或者客户集中续费，群里分分钟刷屏，重要消息被顶上去，等发现的时候可能已经超时了。
真正让我下定决心做小龙虾助手，是有一次客户半夜发来一条“服务器连不上了”的消息，群里的值班同事没看到，等到第二天早上客户已经在打投诉电话了。那次之后我意识到，光靠人眼盯群、靠自觉接单，在这个行业里迟早出事。我们需要一个能统一收消息、按规则分任务、并且把进度记录下来的“中间层”，而飞书群机器人 + 多维表格的组合正好能把这件事低成本地搭起来。
1.2 小龙虾助手的三层职责
小龙虾助手这个名字听着随意，其实它的定位很清晰，就是群里的“前台调度”。第一层职责是收消息，把阿里云消息中心、云监控告警、工单通知以及群内人工转发的客户问题，全部汇到一个入口。第二层职责是分任务，按我们提前配好的规则，比如消息里出现“续费”“故障”“备案”这类关键词，就自动@对应的负责人，同时在消息标题上标注优先级。第三层职责是盯闭环，任务不能光派出去就结束，还要同步到多维表格里，谁在处理、处理到哪一步、有没有超时，打开表格一目了然。
打个比方，如果你们团队是一个餐厅，那小龙虾助手就是前台迎宾加排号员：客人来了它先接待，判断这桌客人该找哪位服务员，然后通知服务员上桌，同时在后厨的排号单上记一笔。等客人走了，排号单上还能留下完整的服务记录。代理商团队本质上就是一个“云资源服务店”，客户的问题就是客人，小龙虾助手就是那个保证每个客人都有人接待、不会漏单的调度系统。
1.3 为什么选飞书 + 阿里云这套组合
市面上能用的群机器人不少，但我们最终选飞书，主要是看中三件事：群机器人配置简单，几分钟就能拉一个带签名校验的 Webhook 出来；多维表格对非技术同事极其友好，字段可以随便拖，状态一改就能看进度；开放 API 文档齐全，不管是收消息还是写记录，都有现成的接口可以调。对应到阿里云侧，消息中心、云监控、工单系统都提供了 API 或者回调能力，再加上我们本身就是代理商，天然需要把这些云上动态和团队协作绑在一起。
有人可能会问，直接用阿里云自带的“消息通知”功能，绑定手机号或者邮箱不就行了？说实话，那是给自己看的，不是给团队看的。个人通知只能保证“某个人知道”，没法保证“最合适的人去处理”，更没法在事后复盘。而把消息推进飞书群，再由助手分派，相当于把个人级通知升级成了团队级协作，这才是代理商真正需要的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 配置前的准备工作（账号权限与技术选型）
2.1 需要准备的三类凭证
在动手之前，先把账号和凭证理清楚，后面会省掉很多沟通成本。第一类是飞书侧的凭证：一个用于测试的飞书群（建议先用小群跑通流程再拉大群）、一个自定义机器人的 Webhook 地址，以及签名校验用的密钥。第二类是阿里云侧的凭证：强烈建议用 RAM 子账号的 AccessKey ID 和 AccessKey Secret，不要图省事直接用主账号密钥，权限范围也不好控制。第三类是部署环境：可以是团队内部一台常开的电脑、一台阿里云 ECS，也可以直接用函数计算，只要能定时或者常驻跑脚本就行。
这里有一个细节容易被忽略：飞书自定义机器人的 Webhook 在创建之后只显示一次完整地址，如果当时没复制好，后面只能删掉重新建一个。我们第一次踩过这个坑，后来把 Webhook 和签名密钥统一放在团队密码管理工具里，既方便分享，也避免随手发到群里造成泄露。
2.2 技术选型：三种运行方式怎么选
我把“跑小龙虾助手”的方式分成三种，团队可以根据自己的条件选：第一种是“本地定时任务”，在一台常开的电脑上写一个轮询脚本，用 cron 或者 Windows 计划任务每 30 秒到 1 分钟跑一次，优点是完全免费、改代码方便，缺点是电脑不能随便关机。第二种是“阿里云函数计算”，把脚本包成一个函数，定时触发器每隔一分钟调用一次，优点是稳定、不依赖本地设备、还有免费额度，缺点是需要稍微学一下函数计算的打包流程。第三种是“ECS 常驻服务”，适合团队本来就有服务器的情况，用 systemd 或 supervisor 托管脚本，运行最稳，但需要多花点时间维护。
如果你问我哪种最推荐，我会说：先在本机跑通逻辑，再迁到函数计算或者 ECS。本机调试时能看到完整的日志，出了问题也好排查；跑通了再往云上搬，逻辑不用大改，只是把运行环境换一下。我们当时就是在本机跑了两周，确认消息推送、去重、派单规则都稳定了，才迁到一台专门的轻量服务器上。
2.3 RAM 子账号和最小权限怎么配
阿里云 RAM 的配置其实不复杂，但很多人容易嫌麻烦跳过，直接用主账号 AccessKey。这里我多说一句：主账号密钥一旦泄露，基本等于把整个账号的管理权限交给别人，尤其代理商手里还托管着客户的资源，风险非常大，千万不要图省事。正确做法是在 RAM 控制台创建一个子账号，启用“编程访问”，然后只给必要的只读权限。如果主要用来读取消息中心公告和云监控告警，那授权“AliyunRMCReadOnlyAccess”和“AliyunCloudMonitorReadOnlyAccess”就够了；如果还要把工单信息和实例状态拉回来，再按需补充对应的只读策略。
权限配好之后，AccessKey 的保管也要讲究。不要硬编码在代码里，更不要提交到 Git 仓库。我们现在的做法是通过环境变量注入，部署到服务器时写在 systemd 配置里，或者放到专门的密钥管理服务中。同时建议定期轮换密钥，比如每 3 个月换一次，换完踢掉旧密钥，这样即使旧密钥意外泄露，影响范围也有限。
3. 核心链路解析：阿里云消息如何进入飞书群
3.1 阿里云侧的消息来源有哪些
很多人一上来就问“阿里云有没有现成的飞书机器人”，答案是有，但通常都是针对某个具体产品，比如云监控就能直接配飞书 Webhook。可是代理商需要的不是某个产品的通知，而是把所有动态汇聚到一起再统一分派，所以我们需要自己搭一条链路。链路的第一段，是搞清楚消息从哪来。
我把阿里云侧的消息来源分成三类。第一类是主动轮询，通过消息中心 OpenAPI 定时拉取未读消息，比如产品欠费、实例到期、备案进度、工单回复等；也可以拉取云监控的告警历史，看有没有新的报警事件。第二类是被动接收，在云监控或者运维事件平台里配置回调地址，让阿里云主动把事件 POST 到我们自己的服务，再由服务转发到飞书。第三类是人工转发，客户在群里发一句“我的服务器打不开了”，同事手动把消息转给小龙虾助手，助手提取关键词后登记成一条任务。前两类适合搞定系统通知，第三类适合搞定客户即时提问，缺一不可。
3.2 飞书机器人：自定义机器人和企业自建应用的区别
飞书群里加机器人有两种常见方式，一种是“自定义机器人”，一种是“企业自建应用”。自定义机器人的优势是快，在群设置里点几下就能拿到 Webhook，配合签名校验就能推消息，完全不用写 OAuth 逻辑，适合做“通知转发器”。企业自建应用则要麻烦一些，需要去开发者后台创建应用、配置权限、获取 app_id 和 app_secret，然后换取 tenant_access_token 才能调用 API，但它能做自定义机器人做不了的事，比如读取群里消息、操作多维表格、发送带交互按钮的卡片、获取成员 user_id 精准 @ 人。
给代理商的建议是：第一版先用自定义机器人把消息推送跑通，成本最低；等团队觉得“光通知不够，还得有人在卡片上点按钮认领任务”的时候，再升级成企业自建应用。我们就是先用了两个月自定义机器人，后来才补了自建应用来读写多维表格，两套并行。注意不要一开始就追求大而全，先把最核心的“消息进群 + 按关键词提醒”跑起来，团队有感知了，再谈升级。
3.3 分工规则的设计：关键词、优先级、@人
小龙虾助手真正值钱的地方，在于“分工规则”。规则不复杂，核心就是：消息进来之后，先做关键词匹配，匹配到哪个类别就@对应的人。比如我们团队分了四个角色：销售负责续费和新购咨询，技术负责故障排查和工单处理，备案专员负责备案相关，客服负责一般性客户问题。于是规则文件里就写成：出现“续费”“到期”“新购”就@销售；出现“故障”“打不开”“超时”“连接不上”就@技术；出现“备案”“ICP”就@备案专员；其他消息@客服。
除了关键词，优先级也很重要。我个人习惯用 P0、P1、P2 三级：P0 是故障类，需要立即响应；P1 是续费、备案等有明确时间节点的任务；P2 是一般咨询，当天处理即可。划分优先级之后，小龙虾助手可以在消息标题上直接加前缀，比如“【P0故障】客户反馈服务器无法访问”，群里一看到前缀就知道轻重缓急。更进一步，如果消息里带链接，就把链接拼在正文里，方便接手的人一键打开原始页面。
4. 手把手配置：从建机器人到任务闭环
4.1 步骤一：在飞书群里创建小龙虾助手
先说最简单的部分。打开飞书群，点击右上角的设置图标，进入“群机器人”，选择“添加机器人”，再选“自定义机器人”。机器人名称建议直接填“小龙虾助手”，头像可以换成一个显眼的虾子图标，这样群里辨识度高。创建成功后会得到一个 Webhook 地址，形如 https://open.feishu.cn/open-apis/bot/v2/hook/xxxxx，这个地址就是后续所有消息推送的入口。
接下来是安全设置，这一步千万别跳过。飞书提供了两种校验方式，我建议至少选“签名校验”。开启后页面会给你一个密钥，之后每次推消息，都要用当前时间戳和密钥生成一个签名，一起放进请求体里。这样做的好处是，即使 Webhook 地址泄露了，没有密钥的人也没法往群里发垃圾消息。创建完成之后，在测试群里先手动用 curl 推一条文本消息试试，比如：
bash复制curl -X POST -H "Content-Type: application/json" \
-d '{"msg_type":"text","content":{"text":"小龙虾助手已上线"}}' \
https://open.feishu.cn/open-apis/bot/v2/hook/你的webhook地址
如果只是简单测试，不加签名也能发出去，但正式使用一定要把签名逻辑加上，后面代码里我会给出完整实现。
4.2 步骤二：在阿里云创建 RAM 子账号
打开阿里云控制台，进入“RAM 访问控制”，在“用户”里创建一个子账号。创建时注意勾选“编程访问”，这样系统才会生成 AccessKey ID 和 AccessKey Secret。创建完成后，进入“权限管理”，给这个子账号添加只读策略。以我们团队的实践为例，核心权限就是两个：消息中心只读和云监控只读，对应策略名通常是 AliyunRMCReadOnlyAccess 和 AliyunCloudMonitorReadOnlyAccess。如果你的脚本还要拉取 ECS 实例列表或域名证书信息，再按需添加 AliyunECSReadOnlyAccess 和 AliyunDomainReadOnlyAccess。
权限配置上，我一直主张“宁可少给也不多给”。小龙虾助手只是个消息分发工具，它不应该有创建实例、修改安全组这类写权限。有一次我图省事直接给子账号绑了“AdministratorAccess”，结果脚本代码里一个循环写错了，差点批量释放了不带保护锁的实例。那次之后我把所有脚本账号的权限全部收敛成只读，才真正放心。子账号建好后，把 AccessKey 配置到环境变量里，比如在 Linux 上用 export ALIYUN_AK_ID=xxx，再到代码里用 os.getenv 读取。
4.3 步骤三：写一个消息转发脚本
我提供一个可以直接改的 Python 脚本框架，核心逻辑分成三块：生成飞书签名、拉取数据源、按规则转发。飞书签名部分我直接给出可运行代码，数据源部分因为大家的云产品组合不一样，我用一个函数占位，你按自己的产品 API 填入即可。
python复制import os
import time
import hmac
import hashlib
import base64
import requests
FEISHU_WEBHOOK = os.environ["FEISHU_WEBHOOK"]
FEISHU_SECRET = os.environ["FEISHU_SECRET"]
def gen_sign(secret: str, timestamp: int) -> str:
string_to_sign = f"{timestamp}\n{secret}"
hmac_code = hmac.new(
string_to_sign.encode("utf-8"),
digestmod=hashlib.sha256
).digest()
return base64.b64encode(hmac_code).decode("utf-8")
def send_feishu(content: str):
timestamp = int(time.time())
sign = gen_sign(FEISHU_SECRET, timestamp)
payload = {
"timestamp": timestamp,
"sign": sign,
"msg_type": "text",
"content": {"text": content}
}
resp = requests.post(FEISHU_WEBHOOK, json=payload, timeout=10)
print(resp.status_code, resp.json())
def fetch_new_messages():
# 在这里接入你的数据源：
# 1. 阿里云消息中心 OpenAPI
# 2. 云监控告警历史
# 3. 自建工单系统的数据库
# 返回格式：[{"id": "唯一ID", "title": "标题", "content": "正文", "source": "来源"}]
return []
def route_rule(content: str) -> str:
# 简单关键词匹配，实际可以换成规则表
rules = [
("续费", "@销售"),
("故障", "@技术"),
("备案", "@备案专员"),
]
for keyword, target in rules:
if keyword in content:
return target
return "@客服"
def main():
last_id_file = "last_msg_id.txt"
last_id = ""
if os.path.exists(last_id_file):
last_id = open(last_id_file).read().strip()
messages = fetch_new_messages()
for msg in messages:
if msg["id"] == last_id:
break
target = route_rule(msg["content"])
send_feishu(f"{target} 【{msg['source']}】{msg['title']}\n{msg['content']}")
last_id = msg["id"]
with open(last_id_file, "w") as f:
f.write(last_id)
if __name__ == "__main__":
main()
这个脚本里有几个值得展开的细节。首先是签名函数，飞书要求的签名算法是把时间戳 + 换行 + 密钥拼成字符串，然后用 HMAC-SHA256 做摘要，最后 Base64 编码，缺一不可。网上很多人抄错了拼接顺序，推消息时一直报签名错误，后来才发现是这里的问题。其次是去重机制，我用一个 last_msg_id.txt 文件记录上次处理的最新消息 ID，每次轮询只处理比它更新的消息。这样做可以有效避免重复推送，不然每跑一次脚本，群里就会多刷一遍历史消息。再就是规则函数，示例里用硬编码关键词，正式使用建议把规则抽到一个 JSON 或者 YAML 文件里，方便非技术同事自己改。
4.4 步骤四：用多维表格把任务“落账”
消息转发到群里只是第一步，真正让分工变得可管理，靠的是记账。我们把飞书多维表格当作小龙虾助手的“账本”，每一条新任务都在表里新增一行记录。轻量版的做法是人工登记：小龙虾助手在群里发消息后，值班同事手动把任务复制到表格里。听起来很原始，但很多小团队初期就是用这种方式跑起来的。完整版的做法是写代码调多维表格 API，脚本在推送飞书消息的同时，自动往表里插入一条记录，来源、标题、负责人、状态、链接全部填好。
多维表格的字段我建议这样设计：任务标题（文本）、来源（单选，可选阿里云/客户群/工单）、优先级（单选，P0/P1/P2）、负责人（人员）、状态（单选，待处理/处理中/已完成）、来源链接（超链接）、创建时间（日期）。状态字段是协作的关键，所有人打开表格就能看到哪些任务还没人动，哪些卡在某个环节，时间一长还能统计每个人的处理量。
这里分享一个经验：负责人在表格里用“人员”字段，而不要用普通文本。因为“人员”字段可以直接@飞书成员，成员会在飞书里收到通知，而且后续可以按成员筛选看每个人的任务列表。如果是纯文本，后期统计就会变成一场灾难。
4.5 步骤五：配置通知模板和派单规则
通知模板决定了群里消息长什么样，直接影响同事愿不愿意看。最开始我直接推纯文本，一大段话堆在一起，群里根本没人细看。后来改成标准模板，固定格式是：第一行优先级标签和任务类型，第二行标题，第三行来源和链接，末尾@负责人。通过实践，我发现带清晰层级的信息，被点开和处理的概率会高很多。
派单规则方面，我建议先在测试群里跑一周看看准确率。规则文件可以用简单的 JSON 维护：
json复制{
"rules": [
{"keyword": "续费", "target": "@销售", "priority": "P1"},
{"keyword": "故障", "target": "@技术", "priority": "P0"},
{"keyword": "备案", "target": "@备案专员", "priority": "P1"},
{"keyword": "发票", "target": "@财务", "priority": "P2"}
],
"default_target": "@客服",
"default_priority": "P2"
}
规则看起来简单，实际运行中最容易出问题的是关键词冲突。比如一条消息同时包含“故障”和“续费”，按我们现在的规则会先命中“续费”还是“故障”？这取决于遍历顺序。我的建议是优先级高的类别放前面，或者干脆给规则加上 priority 字段，匹配时选优先级最高的那条规则。另外，规则要定期复盘，每周翻一下多维表格里那些被“默认客服”接走但实际应该分给技术的任务，反推补充关键词，慢慢规则就会越来越准。
5. 常见问题与避坑实录
5.1 飞书机器人常见报错
飞书机器人在配置和使用中报错，大部分集中在三类问题。第一类是 Webhook 地址错误，常见原因是复制时只复制了一半，或者地址里混入了换行符。第二类是签名校验失败，飞书会返回类似“sign match fail”或者开放平台错误码，这时候优先检查时间戳是否用的是毫秒还是秒，以及签名拼接格式是否符合官方文档。第三类是频率限制，飞书自定义机器人对单个 Webhook 有并发和每分钟条数限制，如果脚本一次性推送大量消息，就会出现一部分成功一部分失败，表现就是群里消息断断续续。
这里特别提一下像 2700002 这类开放平台错误码。遇到这种号码，先别急着怀疑代码，去飞书开放平台查一下当前产品的错误码表，大多数情况指向的是机器人配置问题，比如机器人被移出群、应用未启用、或者权限范围不对。我们的排查套路是：先用飞书提供的“调试工具”直接调一次 API，把报错信息完整贴出来，再按错误码逐项对照，通常很快就能定位。切忌凭记忆猜错误码含义，飞书不同版本的文档对错误码的描述会有细微差别。
5.2 阿里云 API 调用失败
阿里云 OpenAPI 调用失败，最常见的是权限不足。报错信息通常是“Forbidden”或者“NoPermission”，这时候不要从头到尾翻代码，先去 RAM 控制台看子账号到底绑了什么策略。我见过一个团队，脚本逻辑写得很完整，结果 AccessKey 是主账号的，临时改成子账号后又忘了给权限，结果接口一个个报错，排查了半天。建议在脚本里加上启动自检，先调用一次只读接口，比如查询可用区列表，如果失败就直接打印 AccessKey 的权限范围，能省很多事。
另一个隐蔽的问题是数据源分页。消息中心或者监控历史的接口一般都分页返回，如果脚本只拉第一页，就会漏掉很多旧消息。有些接口还有时间窗口限制，一次只能查过去 24 小时的数据，如果脚本停机了一天再启动，中间的消息就会丢。我们现在的做法是每次轮询时记录上次成功处理的消息 ID，同时把时间范围放宽到最近 7 天，再程序里去重，这样即使脚本重启，也不会漏掉中间发生的通知。
5.3 多维表格和群消息的设计问题
多维表格接入之后，新的问题又来了：消息太多，表格里全是行，群里面全是推送，大家反而不知道从哪看起。我们当时踩过这个坑，上线第一周表格里堆了 300 多条未处理记录，群里的机器人消息刷屏到被好几个同事折叠。后来做了三件事才缓解：第一是给优先级加白名单，只有 P0 和 P1 级别的消息才推送到群里全员可见，P2 级别只在表格里登记；第二是每天定时生成一张“今日待办汇总”卡片，替代逐条推送，把零碎通知变成每日播报；第三是设置“已读即转”机制，任务被处理人点击完成后，机器人发一条简短确认，而不是再发一条完整消息。
这里也提醒一下，多维表格 API 本身也有调用频率和单表记录数限制，如果团队单日任务量特别大，建议分批写入，避免触发限流。另外，表格字段一旦上线，尽量不要随意改名，因为脚本里如果写死了字段名，改名后 API 写入就会失败。我们后来在脚本里把所有字段名都配置成常量，改字段时先改脚本再改表格，顺序不能反。
5.4 安全注意事项
安全这块怎么强调都不过分。Webhook 地址和签名密钥一旦泄露，陌生人就能往你们团队群里发钓鱼链接；RAM 子账号的 AccessKey 一旦泄露，别人就能读取你们阿里云账号下的消息和资源信息（取决于授权范围）。所以我有几条硬性要求：第一，AccessKey 绝不写入代码仓库，连私有仓库都不写，因为仓库历史里一旦出现就很难彻底清除。第二，飞书 Webhook 密钥和阿里云 AccessKey 分开保存，别放在同一个配置文件里，更不要放在同一个“常用密码”文档里。第三，每周检查一次 RAM 子账号的登录记录和 OpenAPI 调用记录，发现异常立刻禁用密钥。
还有一个小技巧：在脚本里加一个环境变量开关，比如 FEISHU_ENV=dev 时把消息推送到测试群，FEISHU_ENV=prod 时才推送到正式客户群。这样可以防止有人改配置时不小心把测试消息发到客户群里。我们之前发生过一次，测试消息“这是一条测试”发到了有客户在的大群，场面一度非常尴尬。
6. 进阶玩法：从消息通知到自动化协作
6.1 订单和续费提醒的自动化跟进
代理商最怕的不是没客户，而是客户产品到期了没人提醒，结果客户在别家续了费。小龙虾助手可以每天定时跑一遍：查询所有托管实例的到期时间，把未来 30 天内到期的实例整理成一张清单，推送到飞书群，并按客户维度@对应的销售。更进一步，脚本可以给清单里的每一条都附上阿里云控制台的具体续费链接，销售点进去就能操作，省去在后台翻找的时间。
这个功能在技术实现上并不难，核心是“定时任务 + 到期时间筛选”。我们在实践里遇到过两个小问题：一是部分产品实例有自动续费开关，不应该出现在提醒清单里，否则销售会重复跟进；二是时区问题，阿里云控制台显示的到期时间一般是北京时间，而脚本所在服务器可能默认 UTC，如果直接比较日期容易出现偏差。这两个坑踩过之后，我们在脚本里特意加了“自动续费状态”和“Asia/Shanghai 时区”两个处理逻辑。
6.2 云监控告警自动分派
如果你团队不仅做代理，还帮客户做代运维，那云监控告警的自动分派非常实用。常见的做法是用 Uptime Kuma 这类监控工具盯客户网站的存活状态，一旦发现 DOWN，就通过 Webhook 把消息推到飞书群。小龙虾助手收到告警后，根据消息里的 IP、域名、客户名，自动@对应的运维同事，并在多维表格里生成一条 P0 工单。告警恢复之后再推一条“UP”消息，任务状态自动更新为已完成。
这个流程最大的价值不是省去了人工转发，而是让每一次告警都有据可查。以前告警发生了就发生了，处理完也没人记录；现在每条告警都会落表，后续客户问“这个月到底中断了几次”“每次处理了多久”，我们直接拉表格就能给出答案，专业感一下子就不一样了。
6.3 值班表和 SLA 超时提醒
代理商团队经常要排值班，以前排班表放在文档里，没人提醒，轮到自己值班了也经常忘记。后来我们让小龙虾助手每天上午 9 点在群里发一条“今日值班播报”，内容包括当天值班人、当前待处理任务数、最久未处理任务时长。如果某条 P0 任务超过 15 分钟没人认领，机器人会自动在群里再@一次值班人，并把任务标记为“超时”。
SLA 超时提醒的实现，本质上是在多维表格里维护每个任务的创建时间和状态，定时脚本扫描所有“待处理”和“处理中”的记录，如果超过阈值就把该任务的相关信息推送回群里。这里需要特别注意：扫描间隔不要太频繁，否则每次都会把超时任务重复提醒一遍。我们的做法是在表格里增加一个“已提醒次数”字段，每次提醒后累加，只在第一次和第三次超时的时候推送，避免骚扰。
6.4 让小龙虾助手变成一个能回答问题的 AI 智能体
消息流转这件事跑顺之后，你会发现客户很多问题是重复的，比如“ECS 怎么登录”“续费有没有优惠”“备案需要什么材料”。这些问题完全可以交给 AI 智能体处理。现在飞书生态里已经可以很方便地把 Coze 机器人或者飞书智能伙伴接入群聊，把团队的知识库文档作为数据源，客户在群里提问，智能体自动从文档里找答案回答；遇到搞不定的问题，再转给人处理。
这个方向不一定适合所有代理商，但如果你团队已经积累了大量的 FAQ 文档和工单处理记录，完全可以尝试。它的价值在于把小龙虾助手从“消息中转站”升级成“自助服务台”，让销售和技术同事从重复性的回答中解放出来，把精力放在真正需要人判断的事情上。技术门槛不算高，核心是准备好高质量的知识库数据，机器人回答的质量基本取决于文档的覆盖度和写法。
6.5 其他可以继续扩展的方向
如果你想在“小龙虾助手”的基础上继续折腾，我建议考虑三个方向。一是做一个简单的网页管理后台，结合飞书网页应用免登，让同事用飞书扫一扫就能打开后台，查看所有任务状态，这个方向适合团队对分工跟踪有更高要求的情况。二是把客户发的截图、确认单等附件自动归档到阿里云 OSS，并在多维表格里留一个附件链接，方便后续追溯。三是把每日汇报模板完善起来，包括新增任务数、处理完成数、平均响应时长，每周五自动推给管理者，作为周会讨论的数据基础。
这些扩展方向并不需要一次全上。我现在比较认同的做法是：保持小龙虾助手的核心链路足够简单可靠，每新增一个功能之前先问一句“它能不能帮团队省下至少 30 分钟的人工操作”，能省就做，不能省就先搁置。工具是服务于协作的，别让工具本身变成新的负担。
说回团队协作这件事。我记得小龙虾助手刚上线那几天，群里特别热闹，每条消息都有人接，表里每条任务也有人认领，大家觉得新鲜。真正让我觉得这个配置没白做的，是两周之后的一个晚上，一条 P0 故障消息进来，技术同事在消息发出后不到一分钟就回复了“我来处理”，同时表格里多了一条“待处理”的记录。没有人大喊大叫，没有人转发群聊，整个流程安静又顺畅。这种“安静”就是分工到位最直接的证明。如果你也正为群消息混乱、分工靠喊而头疼，建议按这个指南先搭一个最小可用版本，跑一周看看，你会回来感谢那只小龙虾的。