自动化跑得再顺畅，也总会撞上它搞不定的那一下。
不是技术不行，是有些事天生就该交给人来判断。
我们把店群自动化系统一层层建到了今天，流程失败率从早期的百分之十几压到了千分之几，自愈率做到了60%以上。但剩下那百分之几的异常里，有一类是无法绕过的——需要人类认知能力才能做出的判断和操作。
登录过期后的扫码验证，平台弹出的图形验证码，一个模棱两可的买家消息意图，一张被系统标记为“疑似异常”但不确定该不该发货的订单。这些场景的共同特征是：机器能发现问题，但机器不应该替人做决定。
这不是自动化能力的局限，而是自动化应有的边界。我们花了一年半把能自动化的都自动化了，剩下这部分，需要一套人机协同体系来承接。
这篇文章讲我们怎么设计工单系统，让它和自动化流程无缝对接，让人在正确的时间介入正确的事，并把人的处理结果反哺回自动化系统。
一、自动化的天花板不是技术，是责任
我们在设计自动化系统时划了一条硬线：涉及资金、合规、安全、用户体验判断的操作，机器只提供建议，决策必须由人做出。
这条线下，自动化可以做的事情包括：检测到登录态失效后立刻暂停任务并截取二维码图片，而不是自己试图用OCR识别。检测到一条差评消息后将其高亮标记并推送给客服，而不是自动回复一段未经人工确认的道歉文案。发现一个订单的收货地址模糊后将其放入待审队列，而不是自动取消或自动通过。
在这些场景里，自动化不是“做不到”，而是“不应该做”。让机器越过这条线，带来的风险远超效率收益。
自动化的最高境界不是替代人，而是在人类必须出场的时候，用最快的速度、最准的信息把人送到需要他的地方。
二、工单类型与触发点
我们梳理了自动化系统中所有需要人工介入的场景，抽象出五类标准工单。
第一类：认证恢复工单。 登录态失效、二次验证触发、手机验证码要求。自动化流程截取当前页面状态（二维码或验证码图片），生成工单，分配给运营人员。运营在手机端扫码或输入验证码，流程等待确认后自动继续。
第二类：异常决策工单。 规则引擎无法做出高置信度判断的case。比如买家消息意图识别置信度低于阈值、订单风险评分落在灰色区间、商品价格波动幅度触发了“需人工确认”的告警线。工单携带上下文数据，由人工做最终裁定。
第三类：数据审核工单。 自动化采集到的数据触发了数据质量校验的隔离规则（第十九篇），比如解析出的金额与页面不一致、日期格式异常。工单附带页面截图和提取结果，人工核对后修正或放行。
第四类：环境维护工单。 代理切换后需要重新登录、店铺环境迁移需要手动扫码、账号资质过期需要更新。这些是半自动化的环境操作，需要人参与关键步骤。
第五类：故障诊断升级工单。 自动化运维自愈失败、诊断引擎无法确定根因、连续重试超限。工单汇总了诊断快照和已尝试的修复步骤，指派工程师介入。
三、工单数据模型
工单不是一个简单的“通知消息”，它需要携带充足的上下文，让人在最短时间内理解情况并做出决策。
{
"ticket_id": "TK20260519-0042",
"type": "auth_recovery",
"status": "pending",
"priority": "P0",
"shop_id": "temu_045",
"flow_name": "order_collect",
"task_id": "task-abc-123",
"created_at": "2026-05-19T08:23:15Z",
"deadline": "2026-05-19T08:38:15Z",
"context": {
"current_url": "https://seller.temu.com/login/verify",
"screenshot_url": "https://internal-screenshots/tk042.png",
"instruction": "请使用TEMU商家APP扫描二维码完成登录验证",
"available_actions": ["confirm_done", "report_issue", "escalate"]
},
"assignee": null,
"resolution": null
}
工单的生命周期受状态机管理：
pending → assigned → in_progress → resolved / escalated / expired。每一步流转都记录时间戳和操作人，进入审计日志。
四、工单调度：对的人，对的时间
工单生成后，关键问题是分配给谁。我们不是简单地全量丢到一个公共池子里，而是做了一层智能调度。
技能匹配：每个运营人员在系统中注册了自己的技能标签——负责的平台、负责的店铺范围、擅长的工单类型。调度器根据工单的shop_id和type匹配具备对应技能的可用人员。
负载均衡：每个人员手头同时处理的工单数量有上限。调度器检查当前负载，将新工单优先分配给负载最低的匹配人员。
优先级抢占：P0认证恢复工单如果在队列中等待超过5分钟，会触发升级通知——直接推送到整个运营小组的群聊，任何人可以抢单处理。
值班轮转：非工作时间的工单不打扰全体，只推送给当周值班人员。值班表由系统管理，每周自动轮换。
def assign_ticket(ticket):
candidates = find_candidates(
skills=ticket.required_skills,
shop_scope=ticket.shop_id,
on_duty_only=(ticket.created_at.is_outside_business_hours())
)
if not candidates:
escalate_to_group(ticket)
return
candidates.sort(key=lambda u: u.current_ticket_count)
assignee = candidates[0]
ticket.assignee = assignee
ticket.status = "assigned"
push_notification(assignee, ticket)
schedule_timeout(ticket)
五、等待与超时：不让自动化无限挂起
认证恢复这类工单需要自动化流程在后台等待人工操作完成。等待不是无限的——如果运营迟迟不处理，流程不能一直占着浏览器实例。
我们设计了分阶段超时机制。
- 等待阶段（前5分钟）：流程保持活跃，浏览器实例不释放。工单推送后，等待人工扫码。每30秒通过CDP探测页面是否已跳转到正常后台页面。
- 提醒阶段（5~10分钟）：工单升级，通知扩大范围。流程仍保持等待，但开始记录等待时长指标。
- 释放阶段（超过10分钟）：流程保存当前断点Checkpoint，释放浏览器实例。工单降级为“待处理”，任务进入
pending_human队列。等人工完成认证后，工单系统回调调度中心，任务恢复并重新获取实例。
def wait_for_human_action(ticket, timeout_minutes=10):
deadline = time.time() + timeout_minutes * 60
while time.time() < deadline:
if ticket.status == "resolved":
return ticket.resolution
if time.time() - ticket.created_at.timestamp() > 300: # 5分钟
escalate_reminder(ticket)
time.sleep(30)
# 超时释放
save_checkpoint()
release_browser_instance()
ticket.status = "expired"
raise HumanActionTimeoutError(ticket)
这个设计保证了人工环节不会成为系统资源的黑洞。
六、人工处理结果反哺自动化
工单不只是解决问题的临时通道，更是自动化系统持续进化的数据来源。
规则反哺：当人工对一笔订单标记为“正常”而规则引擎判为“异常”时，这个决策被记录。累计同类修正达到一定阈值后，系统自动建议调整规则引擎的边界条件，工程师审核后更新规则集。
样本积累：买家消息意图识别的不确定case，人工分类后被标注，进入训练样本库。虽然当前我们没有用机器学习模型，但这些标注数据未来可以直接用于训练。
页面知识更新：如果工单是页面改版导致的元素失效，人工修复选择器后，修复结果自动更新页面元素库和DOM基线，防止同类问题再次触发工单。
诊断知识入库：故障诊断工单的最终根因和处理步骤，会被抽象后添加到诊断知识图谱中，丰富自动诊断能力。
def on_ticket_resolved(ticket, resolution):
if ticket.type == "exception_decision":
rule_feedback = {
"original_prediction": ticket.context.get("engine_result"),
"human_decision": resolution["decision"],
"features": ticket.context.get("features")
}
feedback_store.add(rule_feedback)
check_threshold_for_rule_update(rule_feedback)
这样，每一次人工介入都在让自动化系统变得更聪明一点。
七、工单的SLA与监控
工单系统上线后，不能只建不管。我们为每一类工单定义了SLA，并纳入监控。
| 工单类型 | 响应SLA | 处理SLA | 超时升级 |
|---|---|---|---|
| 认证恢复 | 5分钟 | 15分钟 | 10分钟未响应升级全组 |
| 异常决策 | 30分钟 | 2小时 | 1小时未处理升级主管 |
| 数据审核 | 4小时 | 24小时 | 无 |
| 环境维护 | 2小时 | 8小时 | 4小时未处理升级 |
| 故障诊断 | 15分钟 | 4小时 | 30分钟未响应升级值班工程师 |
工单看板实时展示当前各类型工单的积压量、平均处理时长、SLA达标率。如果某类工单的积压量连续超过阈值，说明自动化系统的异常率在上升或运营人力不足，需要干预。
八、工单的移动端体验
大部分工单的处理发生在运营人员的手机上——扫码登录、审核截图、确认状态。我们没单独开发App，而是基于企业微信的机器人+小程序做了轻量接入。
工单推送到企业微信时，卡片里包含：
- 工单类型和优先级
- 店铺名称和平台
- 一句话描述和截图
- 操作按钮（“处理”、“转派”、“标记为误报”）
点击“处理”进入一个H5详情页，展示完整上下文和操作入口。认证恢复类工单，直接展示二维码图片，长按识别即可扫码。
移动端的响应速度和处理便捷程度，直接决定了人机协同体系的效率。我们花了大量精力打磨这个环节，让运营可以在几十秒内完成一次扫码验证，而不是非得回到工位打开电脑。
九、那些在大促期间经受住考验的时刻
这套工单体系真正体现出价值，是在去年TEMU黑五大促期间。
大促当天，平台的安全验证频率明显上升。凌晨流量涌入后，好几个店铺的登录态被平台要求重新验证。认证恢复工单在五分钟内连续弹出，工单调度器把任务均匀分配给了当晚值班的三位运营。运营在被窝里用手机扫码，一分多钟完成一个验证，流程自动恢复，买家消息回复和订单处理没断过。
如果没有这套体系，当时的场景会是：自动化流程卡住、告警半夜炸群、工程师爬起来登录服务器手动扫码、每个店铺折腾十几分钟、买家消息大量积压。大促当天消息回复慢一分钟，转化率就是肉眼可见的损失。
人机协同做得好，不是让人围着机器转，而是让机器在需要的时候精准找到人、把路铺好、把信息准备好，让人花最少的时间做只有人才能做的判断。
十、下一步：从被动工单到主动预警
目前的工单机制还是事件驱动的——出了异常才生成工单。下一步我们想把部分工单升级为主动预警任务。
比如，系统预测某个店铺的登录态将在未来6小时内过期（根据历史有效期的规律），提前生成一条“建议重新登录”的工单，让运营在方便的时候主动完成，而不是等过期了被动扫码。再比如，监控到某个代理的延迟在持续上升，提前生成“建议切换代理”的工单，而不是等断了再切。
这种从“被动响应”到“主动运维”的转变，是自动化系统走向成熟的最后几公里。
最好的工单，是根本不需要生成的工单。
次好的工单，是生成了但在一分钟内就能被处理掉的工单。
作者：林焱
一个坚信再强的自动化也要给人留一把椅子的工程师