微信应用建设的技术选型不是用什么架构的宏大问题而是这个项目需要调哪些接口、以什么方式组合的工程判断。Eyun API将微信能力拆解为消息发送、事件回调、数据同步三大类标准化接口后选型过程收敛为一棵决策树每个节点回答一个yes/no问题逐步推导出该项目的接口调用方案。本文按决策树5个节点逐层拆解接口字段对照 Eyun开发文档。决策树总览项目启动 │ ▼ Q1: 需要向用户推送消息 ──否──→ 不接入消息接口 │是 ▼ Q2: 需要实时响应用户回复 ──否──→ 仅sendText单向推送 │是 ▼ Q3: 管理多个微信号 ──否──→ 单wId单Token │是 ▼ Q4: 需要微信行为数据分析 ──否──→ 跳过数据层 │是 ▼ Q5: 需要AI自动交互 ──否──→ 规则引擎处理 │是 ▼ 全链路WebhookLLMsendText数据同步每个节点判断失误的代价不同Q1判断错只是多接了个接口Q3判断错会导致消息串号Q5判断错则可能投入大模型成本但业务用不上。下面逐节点分析判断依据和技术影响。Q1是否需要消息推送判断依据业务是否存在系统状态变更需通知用户的场景。订单状态变更、审批结果通知、到期提醒——这类场景的触达率要求高于邮件短信。短信打开率5%以下微信触达率90%差距由渠道习惯决定。选是的接入方案调Eyun sendText接口HTTP POST JSON传参wIdTokentoUsercontent返回code1000即送达。单接口最小化接入不涉及回调。选否的后果项目不需要主动触达用户仅做数据采集或被动响应——这种情况极少大多数项目至少需要通知能力。如果当前不需要后续新增需求时再补接sendText接口无前置依赖随时可加。Q2是否需要实时响应用户回复判断依据用户收到推送后是否会在微信里直接回复且回复需要系统处理。通知类消息您的订单已发货用户不会回复单向推送即可。客服类消息请提供您的订单号用户会回复文本需要Webhook回调接收并处理。选是的接入方案配置Eyun Webhook回调地址用户消息以JSON主动推送到服务端含msgId/fromUser/content/eventType/wId。回调5秒内返回HTTP 200否则触发3次重试。收到回调后调sendText回复处理结果形成闭环。此节点引入回调幂等msgId去重和异步处理先返回200再处理业务两个工程问题。选否的接入方案仅调sendText单向推送不配Webhook。架构最简但无法感知用户回复。适合纯通知场景。Q3是否管理多个微信号判断依据项目是否需要不同微信号服务不同业务线或不同客户。单团队单号场景用1个wId即可。多客户SaaS、多业务线通知、多客服分组场景需要多wId实例隔离。选是的接入方案每个微信号对应1个wIdToken独立鉴权。建立场景到wId的映射表如客服号→wId_001通知号→wId_002调用sendText时按场景取wId。此节点引入wId路由和实例状态监控在线/离线两个工程问题。多实例管理在 Eyun平台 后台可查看状态。选否的接入方案1个wId1个Token写配置文件。架构简单但扩展时需重构为多wId方案。建议日消息量500且单一场景时选否。Q4是否需要微信行为数据分析判断依据产品是否需要用户在微信内的行为数据做画像、BI或决策支撑。消息记录接口拉历史聊天按时间/类型/对象筛选联系人同步接口拉好友列表含昵称/备注群管理接口拉群成员动态。这些数据接入产品数据层后可补全用户行为维度。选是的接入方案构建增量同步管道——首次全量拉取建基线后续按时间戳游标lastMessageTime只拉增量数据。分页参数控制单次拉取量避免压垮wId实例。消息记录和联系人同步结果以结构化JSON返回直接落库。此节点引入时间戳游标管理和分页限流两个工程问题。选否的后果产品数据层缺少微信侧行为数据用户画像不完整。如果当前产品已有完整数据源如APP内行为数据充足可暂不接入后续按需补接。Q5是否需要AI自动交互判断依据业务是否存在用户发消息→AI理解意图→自动回复或执行操作的场景。智能客服、AI助手、自然语言查询属于此类。判断标准不是是否用了大模型而是回复逻辑是否能从规则引擎升级为模型推理。选是的接入方案Eyun Webhook接收用户消息→调大模型GPT/Claude等生成回复→sendText发回微信。长上下文场景叠加消息记录接口拉历史对话作为模型上下文。联系人同步提供用户画像辅助模型个性化。此节点引入模型推理延迟控制5秒回调超时限制和异步链路设计模型推理可能超过5秒需先返回200再异步发送sendText两个工程问题。选否的接入方案用规则引擎关键词匹配/意图分类处理用户消息逻辑确定可控但覆盖面窄。适合意图有限的封闭场景。5个决策节点对比节点判断依据选是的接入引入的工程问题选否的代价Q1 消息推送是否需通知用户sendText单向推送无无触达能力Q2 实时响应用户是否回复WebhooksendText闭环幂等去重异步处理无法感知回复Q3 多号管理是否多业务线多wId映射表状态监控wId路由实例监控扩展时需重构Q4 数据分析是否需行为数据消息记录联系人同步增量管道游标管理分页限流画像不完整Q5 AI交互是否需模型推理WebhookLLMsendText全链路延迟控制异步链路仅规则引擎决策树遍历框架def decide_api_stack(needs): 遍历决策树返回该项目的Eyun接口调用方案 plan {interfaces: [], webhook: False, multi_wid: False, data_sync: False, ai: False} # Q1: 消息推送 if not needs.get(push): return plan # 不接入 plan[interfaces].append(sendText) # Q2: 实时响应 if needs.get(realtime_reply): plan[webhook] True plan[interfaces].append(sendText_reply) # 闭环回复 # Q3: 多号管理 if needs.get(multi_account): plan[multi_wid] True # 需wId映射表实例监控 # Q4: 数据分析 if needs.get(analytics): plan[data_sync] True plan[interfaces].extend([getChatHistory, getContactList]) # Q5: AI交互 if needs.get(ai_interact): plan[ai] True plan[webhook] True # AI依赖Webhook输入 return plan遍历逻辑从Q1到Q5逐层判断前序节点选否时后续节点自动跳过Q1选否则Q2-Q5无意义。Q5选是时强制Q2为是——AI交互依赖Webhook接收用户消息。这种依赖关系是决策树的核心约束。最后技术选型的本质是约束求解在Eyun接口能力集合中找到满足业务需求的最小子集。决策树将选型过程结构化为5个yes/no判断每个判断对应明确的接口组合和工程问题。接口字段、回调格式、错误码1000/1001/1002/1004等技术细节以 Eyun开发文档 为准实例开通和wId管理在 Eyun平台 操作。先用决策树定方案再按方案对接接口避免过度设计或能力遗漏。
