前言
律所的案源争夺战，很大程度上在第一条微信消息里就已分出胜负。潜在委托人深夜发来"我能起诉吗"，若次日才有律师回复，客户早已联系其他律所。调研数据显示，法律咨询行业的微信首次响应时间超过 30 分钟，转化率下降超过 60%。微信自动接待与案源管理体系，正是为填补这一"响应真空"而生。本文从技术架构出发，手把手拆解律所如何基于 个人微信 API 搭建 7×24 小时自动接待机器人，并将接待数据实时写入案源 CRM，实现从询问到建档的全链路自动化。
一、律所微信接待的核心痛点拆解
传统律所的微信客服依赖真人律师或助理轮班值守，带来三个结构性问题。
问题一：响应时差造成案源流失。 个人咨询类案件（离婚、劳动纠纷、交通事故）高度冲动，委托人通常同时联系 3-5 家律所，先回复、先建立信任的那家拿单概率最高。凌晨、节假日等无人值守时段尤为明显。
问题二：信息收集标准化程度低。 不同助理问的问题不一样，有人忘记问案发时间，有人忘记确认对方当事人信息，导致律师接手时需要重新了解情况，体验差、效率低。
问题三：案源数据沉睡在聊天记录里。 微信聊天记录本质上是非结构化数据，无法直接导入 CRM，人工整理耗时且遗漏率高，案源分析更无从谈起。
要同时解决这三个问题，需要一个能稳定对接个人微信、支持消息监听+自动回复+结构化信息提取的技术底座。WechatApi 基于 iPad 协议实现了这一能力，提供完整的 HTTP API，律所技术团队（哪怕只有一名外包开发）即可快速接入。
二、技术架构：iPad 协议 + 业务逻辑层 + CRM 写入
整套方案的架构分为三层：
┌──────────────────────────────────────┐
│ 微信客户端（用户侧） │
└──────────────────┬───────────────────┘
│ 微信消息
┌──────────────────▼───────────────────┐
│ WechatApi 接入层（iPad 协议网关） │
│ 消息监听 Webhook / 长轮询接口 │
└──────────────────┬───────────────────┘
│ 结构化消息事件
┌──────────────────▼───────────────────┐
│ 律所业务逻辑服务（自研/外包） │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ NLP意图 │ │ 问卷流程状态机 │ │
│ │ 分类引擎 │ │（案件类型→问题序）│ │
│ └──────────┘ └──────────────────┘ │
└──────────────────┬───────────────────┘
│ 结构化案源数据
┌──────────────────▼───────────────────┐
│ 律所 CRM / 案件管理系统（写入层） │
│ MySQL / 飞书多维表格 / 自研系统 │
└──────────────────────────────────────┘核心思路：WechatApi 的 微信 iPad 协议 把微信消息从私有协议转化为标准 HTTP 事件推送，业务层只需处理 JSON，完全不需要关心微信底层通信细节。
三、接入流程：从注册到收到第一条消息事件
3.1 设备注册与登录
在 WechatApi 控制台 创建设备，获取 appId（设备标识）和 VideosApi-token（请求鉴权 Header）。
bash# 登录律所专用微信号（示例：扫码登录接口调用方式）
curl -X POST https://api.wechatapi.net/v1/device/login \
-H "VideosApi-token: YOUR_TOKEN_HERE" \
-H "Content-Type: application/json" \
-d '{
"appId": "YOUR_APP_ID",
"loginType": "qrcode"
}'
返回体示例：
json{
"ret": 200,
"msg": "获取二维码成功",
"data": {
"qrcodeUrl": "https://cdn.wechatapi.net/qr/xxxxxxxx.png",
"expireSeconds": 120
}
}
扫码成功后，该微信号即进入在线状态，后续所有收到的消息会通过 Webhook 实时推送到你配置的业务服务器地址。
3.2 配置消息 Webhook
在控制台填写你的业务服务器回调地址，WechatApi 会将每条消息以 POST 请求的形式推送过来，消息体结构示例如下：
json{
"ret": 200,
"msg": "message_event",
"data": {
"appId": "YOUR_APP_ID",
"fromUser": "wxid_abc123456789",
"toUser": "wxid_lawfirm001",
"msgType": 1,
"content": "我老公出轨了，我想离婚，能帮我吗？",
"msgId": "9876543210987654321",
"timestamp": 1718236800
}
}
msgType: 1 表示文本消息，律所最核心的接待场景都在此类型。图片（3）、语音（34）、名片（43）等类型也支持解析，用于接收委托人发来的证据材料。
四、问卷流程设计：用"状态机"标准化信息收集
律所接待的核心不是聊天，而是有序收集案件关键信息。建议按案件类型设计独立问卷流程，用状态机管理每个用户的当前问卷进度。
4.1 案件类型识别
用户第一条消息通常包含案件性质的关键词，可用简单关键词匹配或调用大模型 API 完成分类。以下是常见律所业务的分类映射表：
| 案件类型 | 触发关键词示例 | 问卷流程 ID |
|---|---|---|
| 离婚纠纷 | 离婚、出轨、婚姻、分居、财产分割 | flow_divorce |
| 劳动纠纷 | 辞退、裁员、拖欠工资、劳动合同 | flow_labor |
| 交通事故 | 车祸、撞车、赔偿、交通事故 | flow_traffic |
| 债务纠纷 | 借钱不还、欠款、债务、借贷 | flow_debt |
| 房产纠纷 | 房屋、买卖合同、中介、烂尾楼 | flow_property |
| 刑事辩护 | 被抓、拘留、逮捕、刑事、辩护 | flow_criminal |
| 其他/未识别 | — | flow_general |
4.2 离婚纠纷问卷示例（flow_divorce）
pythonDIVORCE_FLOW = [
{
"step": 1,
"field": "marriage_years",
"question": "您好，我是律所智能助手。请问您结婚多少年了？"
},
{
"step": 2,
"field": "has_children",
"question": "请问婚内是否有孩子？孩子目前几岁？"
},
{
"step": 3,
"field": "property_status",
"question": "婚内是否有共同房产或其他大额资产？"
},
{
"step": 4,
"field": "divorce_reason",
"question": "能简单说说离婚的主要原因吗？（如出轨、家暴、感情破裂等）"
},
{
"step": 5,
"field": "contact_phone",
"question": "感谢您的信息。请留下您的联系电话，律师将在工作时间内与您详细沟通。"
}
]
状态机逻辑：每收到用户消息，查询 Redis/数据库中该用户的当前 step，将用户回答存入该 step 对应字段，然后发送下一个 step 的 question，直至问卷完成。
4.3 自动回复接口调用
pythonimport requests
def send_reply(app_id: str, token: str, to_user: str, content: str):
"""向指定微信用户发送文本消息"""
url = "https://api.wechatapi.net/v1/message/sendText"
headers = {
"VideosApi-token": token,
"Content-Type": "application/json"
}
payload = {
"appId": app_id,
"toUser": to_user,
"content": content
}
resp = requests.post(url, headers=headers, json=payload, timeout=10)
result = resp.json()
if result.get("ret") == 200:
print(f"消息发送成功：{to_user}")
else:
print(f"发送失败：{result.get('msg')}")
return result
五、案源数据结构化与 CRM 写入
问卷完成后，系统拥有了一个结构化的案源对象，可直接写入 CRM。以飞书多维表格为例（也可写 MySQL 或律所自研系统）：
pythondef build_case_record(session: dict) -> dict:
"""将问卷会话组装成案源记录"""
return {
"wxid": session["from_user"],
"case_type": session["flow_id"],
"case_summary": session.get("divorce_reason") or session.get("incident_desc", ""),
"contact_phone": session.get("contact_phone", "待补充"),
"create_time": session["start_timestamp"],
"source_channel": "微信自动接待",
"assign_lawyer": "", # 待分配
"status": "待跟进",
"raw_chat": session.get("chat_log", [])
}
def push_to_crm(record: dict):
"""写入 CRM 系统（此处示意飞书多维表格接口）"""
crm_url = "https://your-crm-endpoint/api/cases"
headers = {"Authorization": "Bearer YOUR_CRM_TOKEN"}
resp = requests.post(crm_url, headers=headers, json=record)
return resp.json()
案源记录落库后，律师助理打开 CRM 看到的是已分类整理的线索，而非杂乱的聊天记录，跟进效率大幅提升。
六、进阶功能：群接待、名片自动归档与超时提醒
6.1 律所咨询群自动管理
部分律所建有"法律咨询群"，用于批量触达潜在客户。WechatApi 同样支持群消息监听与回复，借助 微信群管理机器人 能力，可实现：
- @机器人触发私聊问卷：用户在群内 @律所助手，机器人自动发起私聊开启问卷流程，避免在群内泄露当事人隐私；
- 定时群发法律科普内容：每天/每周定时向群内推送与案件类型匹配的法律知识，维持群活跃度的同时塑造专业形象；
- 关键词自动回复：群内出现"收费"、"怎么起诉"等高意向词时，立即弹出律所介绍卡片并 @发言者引导私聊。
6.2 名片与联系方式自动归档
委托人有时会主动发来名片或直接报手机号，可在消息处理层增加正则提取逻辑：
pythonimport re
def extract_phone(content: str) -> str:
"""从消息文本中提取手机号"""
pattern = r"1[3-9]\d{9}"
match = re.search(pattern, content)
return match.group() if match else ""
提取到的号码直接更新至案源记录的 contact_phone 字段，无需人工干预。
6.3 超时未回复提醒机制
用户在问卷进行到一半时中途消失是常见场景（被打断、犹豫中）。建议设置定时任务，对超过 2 小时未回复的进行中问卷触发一条跟进消息：
"您好，刚才您的问题还没填完，律师正在待命，有任何疑问欢迎继续提问～"
这一功能通过 WechatApi 的定时发送接口配合业务层的定时任务（Celery / Cron）即可实现，技术门槛极低但转化拉升明显。
七、合规性与风险控制要点
律所使用微信自动化工具，需特别关注以下合规事项：
1. 禁止在自动回复中提供具体法律意见。 机器人只做信息收集和引导，所有实质性法律建议必须由持牌律师在跟进阶段给出，避免构成"无证执业"风险。
2. 用户知情同意。 建议在问卷第一步明确告知"您正在与智能助手对话，信息将转交律师处理"，符合个人信息保护法要求。
3. 数据存储安全。 案源信息属于高度敏感个人数据，CRM 需加密存储，传输使用 HTTPS，访问需权限控制，留存时间不超过必要期限。
4. 微信号健康维护。 基于 微信 iPad 协议 的接入方案稳定性好，但仍建议避免短时间内大量加人、群发行为，保持自然的账号使用节奏，降低账号风控概率。
WechatApi 在接口设计上已内置频率限制与异常检测提示，开发者可参考 开发文档 中的风控建议章节进行配置。
小结
律所微信自动接待与案源管理的核心价值在于：用技术手段填补"人不在线"的时间空档，用标准化问卷替代随机性沟通，用结构化数据驱动案源运营。整套方案的技术实现并不复杂，关键是选对底层 API 工具。
WechatApi 基于 iPad 协议的稳定接入能力、完整的 微信二次开发 接口体系，以及详尽的文档支持，使其成为律所信息化改造中微信接待环节的首选方案。从中小律所的单微信号接待机器人，到大所的多号+群管理+CRM 全链路集成，WechatApi 均能灵活覆盖。如需试用或接入，访问 WechatApi 官网 或直接登录 控制台 创建设备开始体验。