企业官网建设流程全解析

上个月我们产品经理拉我开会，开门见山："我们这个软件，怎么接入微信？" 我没急着答，先反问他三个问题：你的用户在微信里待多久？你希望微信做入口还是做出口？你愿不愿意为生态化重做架构？问完我心里有数了。给他列了五种接入方案，让他按产品阶段挑。今天把这五种整理出来，给同样卡在这儿的同行参考。

想弄清每种方案具体调哪些接口，建议先打开 Eyun开发文档 对着看，下面我只讲思路和取舍。

方案一：通知型接入

定位：最轻量，软件只往微信发，不收。

典型场景：服务器告警、订单状态变更、审批提醒。软件里发生事，推一条到用户微信，用户看完就好，不用回。

Eyun API 能力：核心就一个 sendText，传 wId、toId、content。不配 Webhook 也行，单向推送够了。

接入复杂度：低，半天就能跑通。

适用产品：内部系统、运维工具、SaaS 后台。

坑：通知太频繁，用户嫌烦，得做好频率控制。

方案二：指令型接入

定位：微信当入口，用户发消息触发软件操作。

典型场景：用户在微信发"查订单 10086"，软件收到后查库返回结果。微信变成一个命令行。

Eyun API 能力：Webhook 收消息 + sendText 回结果，一收一发闭环。wId 实例配 Token 鉴权，回调走 JSON。

接入复杂度：中，要解析消息、路由指令、组装回复。

适用产品：客服系统、查询类工具、轻量自动化产品。

坑：自然语言解析不稳定，建议先用固定指令格式，别一上来就 NLP。

方案三：伴随型接入

定位：微信做日常伴随触达，不是事件驱动，是节奏驱动。

典型场景：每天早上给用户发行业早报，朋友圈定时发内容，群里定时互动。软件变成"在微信里陪用户的伙伴"。

Eyun API 能力：朋友圈接口 + 群消息接口 + 定时任务调 sendText。组合起来覆盖一天的触达节奏。

接入复杂度：中高，要排内容日历，还要管账号状态。

适用产品：媒体号、社群运营工具、内容型 SaaS。

坑：伴随型最容易被当成骚扰，内容质量要扛得住，否则掉粉掉得快。

方案四：数据型接入

定位：不主动发，把微信里的行为数据回流到软件。

典型场景：客户在微信聊了什么、加了谁、退了哪个群，全部回流到 CRM，软件据此打标签、做画像。

Eyun API 能力：消息记录接口 + 联系人同步接口，Webhook 把实时消息推回来，定时拉联系人增量。

接入复杂度：高，要建数据管道、做去重、存档。

适用产品：CRM、SCRM、客户洞察类产品。

坑：回流数据要做脱敏和合规，别什么都存，触线的事别干。

方案五：全能型接入

定位：以上四种组合，软件长在微信生态里。

典型场景：通知型 + 指令型 + 伴随型 + 数据型全上，软件既是出口又是入口，既实时又伴随，还沉淀数据。一家做社群电商的客户就这么接，整个产品形态都长在微信上。

Eyun API 能力：Eyun 全套 API 支撑——sendText、群管理、朋友圈、联系人、消息记录、Webhook 回调，按需取用，wId 多实例分配给不同业务模块。

接入复杂度：高，要分模块、分实例、分层鉴权。

适用产品：重度依赖微信生态的产品，比如社群电商、私域运营平台。

坑：摊子铺太大，监控和告警一定要跟上，否则一处坏全线崩。

五种方案对比

附：5种方案的统一接入框架

给产品经理看的时候，我直接画了这么个策略模式的架子，五种方案各自实现，主流程统一：

from abc import ABC, abstractmethod class WeChatAccessStrategy(ABC): """接入策略抽象，5种方案各自实现""" @abstractmethod def execute(self, eyun_client, context): pass class NotifyStrategy(WeChatAccessStrategy): """通知型：软件 → 微信""" def execute(self, eyun_client, context): eyun_client.send_text(context["inst"], context["user"], context["message"]) class CommandStrategy(WeChatAccessStrategy): """指令型：微信 ↔ 软件""" def execute(self, eyun_client, context): cmd = self._parse(context["incoming"]) result = self._dispatch(cmd) eyun_client.send_text(context["inst"], context["user"], result) class CompanionStrategy(WeChatAccessStrategy): """伴随型：定时节奏触达""" def execute(self, eyun_client, context): for slot in context["schedule"]: eyun_client.send_moment(context["inst"], slot["content"]) class DataStrategy(WeChatAccessStrategy): """数据型：微信行为回流""" def execute(self, eyun_client, context): eyun_client.sync_contacts(context["inst"]) eyun_client.fetch_messages(context["inst"], context["since"]) class FullStackStrategy(WeChatAccessStrategy): """全能型：组合调度""" def __init__(self): self.parts = [NotifyStrategy(), CommandStrategy(), CompanionStrategy(), DataStrategy()] def execute(self, eyun_client, context): for p in self.parts: p.execute(eyun_client, context) class WeChatAccessRouter: """统一入口，按场景路由到对应策略""" def __init__(self): self._strategies = { "notify": NotifyStrategy(), "command": CommandStrategy(), "companion": CompanionStrategy(), "data": DataStrategy(), "full": FullStackStrategy(), } def handle(self, scene, eyun_client, context): self._strategies[scene].execute(eyun_client, context)

这个框架的好处是，产品经理选哪个方案，就是换一个 scene 参数，主流程不动。后面从通知型升级到全能型，也不用推倒重来。我对 Eyun平台 的接口用得熟，所以策略里调的方法都对应得上。

写在最后

那次会议结束后，产品经理挑了指令型先跑，验证用户习惯后准备往伴随型升。这个决策顺序我挺认同——先轻后重，先单向后双向。接入微信这件事，最难的不是技术，是搞清楚自己的产品到底要在微信里扮演什么角色。把这五种方案摆开，对照自己的用户和场景选一个，远比上来就堆功能靠谱。Eyun 的接口和 Eyun开发文档 我翻了大半年，RESTful + JSON 这套用着顺手，wId 实例化和 Token 鉴权也契合多产品线场景。如果你正发愁产品怎么接微信，不妨照这五种方案先做个选型表。