企业官网建设流程全解析

简介：这是一套面向企业级社交客户关系管理与全渠道营销自动化的Odoo集成模块，适合ERP实施人员、Odoo开发者及数字化转型顾问使用。资源将微信服务号、微信小程序、企业微信、抖音号、抖音小程序、飞书H5、钉钉等主流社交渠道统一接入Odoo，并结合AI智能体实现客户数据分析、智能问答与自动化服务，可帮助企业跨平台管理客户互动并提高营销效率。压缩包共267个文件，整体约3.12MB，以Python业务模块、XML视图定义、JS前端交互、CSS样式及CSV权限数据为主，辅以少量Markdown说明、图片和HTML页面，代码结构清晰，便于二次开发与部署。已有50人学习浏览，适合需要快速搭建多平台社交集成能力、并用AI增强客户触达的Odoo使用者。通过该资源可获得完整模块源码、渠道对接配置、AI智能体融合示例及数据模型参考，有助于理解统一消息流与客户画像整合思路，为实际项目落地提供可直接借鉴的实现方案。

1. Odoo 社交集成模块：多渠道客户关系与 AI 智能体融合的落地解析

做 Odoo 二次开发这些年，我发现一个挺扎心的现实：很多企业不是没有客户，是客户散落在微信、抖音、飞书、钉钉这些渠道里，跟 Odoo 里的订单、商机数据完全是两个世界。销售在微信里聊完客户，回头还得手动去 Odoo 里补一条线索，漏跟、错跟是常态。这次拆的这个社交集成模块，解决的问题正好卡在这个点上——把微信服务号、小程序、企业微信、抖音号、抖音小程序、飞书、H5、钉钉全部接进 Odoo，再用 AI 智能体把消息自动归类、打标、生成回复建议甚至直接触发营销动作。它不是简单的消息转发工具，更像是在 Odoo 和社交平台之间铺了一条双向车道。适合谁用？手里有 Odoo 实施经验、客户又集中在微信生态里的乙方团队，或者规模不大但想把手动运营省掉的甲方。

2. 从接口配置到双向同步：模块的四层工作逻辑

2.1 渠道接入层：为什么不能只接一个微信

这个模块最大的设计特点，是把「渠道」做成了插件式结构。每个社交平台对应一个独立的连接器，比如wechat_connector、wecom_connector、douyin_connector、feishu_connector。每个连接器里面包含平台侧的凭证配置、API 调用封装和回调事件处理三件事。这种设计的好处是：你在 Odoo 后台安装一个新渠道，不需要动核心代码，只需要在ir_config_parameter里新增平台凭证，然后重启 worker。我拆解的时候重点看了它的消息统一模型——所有渠道的消息进来后，都会被转换成统一的social.message对象，字段包括渠道类型、外部用户 ID、消息体、附件、时间戳、方向（进/出）。这个统一模型是做后续 AI 打标和客户视图的基础。

以微信服务号接入为例，配置流程是这样的：

# 微信服务号配置示例，Odoo 后台 -> 设置 -> 社交集成 { 'app_id': 'wx1234567890abcdef', 'app_secret': 'your_secret_here', 'token': 'your_custom_token_for_signature', 'encoding_aes_key': 'your_aes_key_for_message_decrypt', 'callback_url': 'https://your-odoo-domain.com/social/wechat/callback', }

配置完成后，微信平台侧需要把服务器 URL 指向callback_url，并启用消息推送。这里有个关键点：微信服务号的消息回调要求 48 小时内回复，超过时限就不能再主动推送，只能等用户再次触发。很多项目上线后才意识到这个限制，导致自动回复功能在周末直接失效。我一般会在渠道配置里加一个值班规则——超过 48 小时的消息自动转给人工客服，并在 Odoo 里生成待处理工单。

2.2 数据同步层：客户身份打通是核心难点

多渠道集成的难点不在消息收发，在身份识别。同一个客户，可能在微信里是一个 openid，在抖音里又是一个不同的标识，在企业微信里则是 userid。模块的处理方式是建立一张social.customer.mapping表，把这些外部标识映射到 Odoo 原生的res.partner记录上。如果匹配不到已有客户，就自动创建一条「待合并」状态的线索，不直接生成正式客户，避免垃圾数据污染客户主数据。

# 从 Odoo 中查找或创建客户 partner = env['res.partner'].search([ ('social_openids', 'ilike', external_user_id) ], limit=1) if not partner: partner = env['res.partner'].create({ 'name': msg.from_user_name, 'social_openids': external_user_id, 'is_social_customer': True, 'stage': 'lead', # 待确认阶段，不直接激活 })

这段代码逻辑不复杂，但有个值得注意的设计——is_social_customer和stage两个字段配合使用。社交渠道过来的客户，默认不进入 Odoo 的标准销售漏斗，而是先在一个独立的「社交客户池」里沉淀，等人工或 AI 确认有效后再转入正式商机。这么做的原因是：微信里经常有客户只是问一句价格，未必是真需求，直接进漏斗会把销售团队的数据搞乱。

2.3 AI 智能体层：消息分类与意图识别

模块里集成的 AI 智能体，核心不是一个写死的规则引擎，而是一个可以接任意大模型 API 的中间层。默认支持 OpenAI 格式的接口，也就是说你只要有任意一个兼容 OpenAI 协议的模型服务（国内有很多这种中间层服务），填上api_base和api_key就能用。AI 这块做了两件事：意图识别和内容生成。意图识别用来判断消息属于售前咨询、售后工单还是营销活动反馈，生成的内容可以是回复草稿、话术建议或者工单处理摘要。

# AI 意图识别与回复建议生成 def _analyze_inbound_message(self, message): system_prompt = """ 你是 Odoo 系统的客户服务助手。 根据以下客户消息，输出 JSON： {"intent": "sale/support/complaint/marketing", "suggestion": "回复草稿", "sentiment": "positive/neutral/negative"} """ resp = self._call_llm(system_prompt, message.body) return json.loads(resp) def _auto_reply(self, message, suggestion): if message.channel type in ['wechat', 'wecom']: # 微信类渠道允许自动回复，但限定模板消息 self._send_template_message(message.external_user_id, suggestion)

实际测试下来，模型对中文客户消息的意图判断准确率大概在 80% 上下，但这里有个坑——AI 生成的回复草稿有时候会用词过于「正式」，客户一眼就能看出是机器人。所以模块默认的策略是 AI 只生成草稿和标签，除非消息类型是标准的 FAQ（比如问营业时间、查物流单号），否则不直接自动发送。这个「先建议、后发送」的设计，对一线运营人员来说更靠谱。

2.4 营销自动化触发：把消息变成行动

当客户在任意渠道完成特定行为（提交表单、发送特定关键词、小程序下单），模块会触发营销自动化规则。规则在 Odoo 后台用图形化界面配置，底层是social.automation.rule模型，支持动作包括创建商机、发送优惠券、加入标签、推送企业微信通知等。这个设计把社交渠道和 Odoo 原生的 CRM、营销活动模块串了起来。

3. 把微信生态接进 Odoo：服务号、小程序、企业微信的分工与代码走读

3.1 微信服务号回调验签：每次集成的第一道坎

微信服务号的消息回调是所有微信生态集成的基石。服务号能拿到用户的 openid，能发模板消息，是消息触达最稳定的渠道，只是模板消息现在审核越来越严，很多行业模板不好申请。模块里回调验签的逻辑是标准的微信流程：把 token、timestamp、nonce 按字典序排列后做 SHA1 加密，与签名比对。

# 微信回调验签核心代码 def _verify_wechat_signature(self, token, timestamp, nonce, signature): import hashlib tmp_arr = [token, timestamp, nonce] tmp_arr.sort() tmp_str = ''.join(tmp_arr) calc_signature = hashlib.sha1(tmp_str.encode('utf-8')).hexdigest() return calc_signature == signature

验签通过后，如果配置了 EncodingAESKey，还需要对消息体做 AES 解密。这里我踩过一个坑：微信的解密要求 AES 采用 CBC 模式，密钥为 EncodingAESKey 加上等号做 Base64 解码，IV 是密钥的前 16 字节，网络字节序。网上很多博客写的 IV 取值是错的，导致解密出来是乱码。模块里的实现是对的，如果读者要自己写，建议直接复制libwechat的官方 Demo 代码再改。

3.2 微信小程序：手机号登录与订单数据回流

小程序的集成重点不在消息聊天，而在用户身份和订单数据。小程序端通过wx.login()获取 code，后端再用 code 换 openid 和 session_key。模块在这里做了一个很实用的功能：用户在小程序里授权手机号后，模块会自动把这个手机号与 Odoo 里的客户记录匹配，匹配成功后把小程序 openid 挂到客户档案上。这样客户在 H5、小程序、服务号三个入口进来，都能识别出是同一个老客户。

# 小程序手机号解密示例 def _decrypt_phone(self, session_key, encrypted_data, iv): from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes cipher = Cipher(algorithms.AES(session_key), modes.CBC(iv)) decryptor = cipher.decryptor() plain_text = decryptor.update(encrypted_data) + decryptor.finalize() data = json.loads(plain_text) return data['purePhoneNumber'] # 获取手机号

手机号解密需要先把 session_key 做 Base64 解码，iv 同样解码，再做 AES-128-CBC 解密。注意cryptography库在 Odoo 环境里需要额外安装，有些生产服务器不会装这个依赖，部署时会报ModuleNotFoundError。模块的requirements.txt里有列出，但实际执行pip install的时候经常会因为网络源问题装不上，建议优先用国内镜像源。

3.3 企业微信：员工与客户的绑定关系

企业微信和其他渠道最大的不同，是消息对象直接关联到具体员工。客户加了销售的企业微信，聊天的双方是「客户 ↔ 某个员工」。

### 3.4 抖音生态与飞书：被低估的营销渠道 抖音号和抖音小程序的集成，价值不在客服聊天，而在把抖音用户产生的兴趣行为回传到 Odoo，做更精准的营销推送。模块的做法是在抖音小程序里埋点，用户点击商品、观看视频、发起评论时，事件通过 API 回传到 Odoo，统一变成本地线索记录。 飞书和钉钉的定位是「内部协同渠道」，企业用它们做客户跟进的内部通知。比如客户在微信发了投诉，模块自动在飞书群里推一条消息，并带上客户历史订单和联系人信息，售后不用来回切换平台。这个设计我觉得很聪明——不是要把所有用户都拉到飞书，而是让内部团队在飞书看到外部客户的完整视图。 ## 4. 数据安全与权限边界：多渠道集成中的身份认证陷阱

4.1 多 Token 管理的混乱根源

社交集成模块涉及的 Token 种类非常多：微信的access_token、企业微信的access_token、飞书的tenant_access_token、钉钉的access_token，每种都有不同的有效期。微信的是 7200 秒，企业微信的是 7200 秒，飞书的tenant_access_token是 2 小时，钉钉的有效期也是 2 小时。模块在存储 Token 时采用了 Odoo 的ir.config_parameter，并加了每小时刷新一次的定时任务。

4.2 Odoo 提示无权限的排查思路

在实际使用中，用户最常遇到的错误是「提示无权限」。这个提示出现在 Odoo 后台访问社交渠道配置页面，或者员工尝试发送消息时。原因通常是字段级权限没有分配——模块安装后，会创建一组新的ir.model.access规则，但如果你是从旧版本升级过来的，规则可能没有覆盖新字段。排查方法是在开发者模式下查看model_metadata和ir_model_access，确认social.message模型对当前用户组开放了写权限。

# 查看 Odoo 中模型权限的常用命令 python odoo-bin shell -d your_db env.ref('base.group_user').write({'model_access': [ (6, 0, [ env.ref('social.model_social_message').id, ]) ]})

注意：model_access这种写法的意思是替换整个权限列表，如果你用(1, id, {...})做增量修改，权限组的定义会写得很乱。我一般会直接把新模型加到底层base.group_user里，确保所有内部员工至少能读。运营人员需要发送消息的，再单独加social.group_message_sender。

4.3 企业微信与微信的 Token 刷新频率差异

企业微信的access_token有效期是 7200 秒，但频繁刷新会被微信侧限流。实际上企业微信的 Token 刷新接口对调用频率有限制，我见过有项目因为定时任务设成每分钟刷新一次，直接被腾旭云封了 IP 一段时间。模块默认是 7000 秒刷新一次，留出 200 秒的缓冲，这个数值不建议再调小。

4.4 数据库安全与微信数据解密

微信数据库解密是个敏感话题，但模块里涉及的 `session_key` 和 `EncodingAESKey` 的保管其实更值得注意。不要让 Odoo 的执行用户对配置文件有写权限，密钥放在 `odoo.conf` 里比放在数据库里更安全一点。数据库如果被拖库，`ir.config_parameter` 里的微信密钥是明文的，等于把微信消息的加密能力直接送给了攻击者。我建议在 Odoo 层做一个字段加密扩展，或者至少把敏感参数单独存放在环境变量中，不落到数据库表里。

4.5 微信小程序登录获取手机号的兼容性

微信小程序获取手机号这个能力，现在的规则是必须用户在页面主动点击授权按钮，且一个手机号在同一个小程序里一年只能被获取 10 次。这个限制看似不痛不痒，但对重运营的场景影响很大——如果你的小程序的登录环节会频繁调起手机号授权，很容易把额度用完。模块里在这个接口下面加了缓存机制：已经授权过的用户，手机号在 Odoo 客户档案里存在时，直接读档案不重复调微信接口。

5. 避坑指南：社交集成最常见的五个翻车现场

这条是我最想写的一章，因为拆解模块的过程中，我把自己过去踩过的坑都翻了出来。

第一，小程序抓包时看不到登录请求。很多搞小程序集成的工程师会想通过抓包看小程序的 API 调用，结果发现抓不到。原因不是抓包工具不行，而是小程序默认开启了域名合法性校验，只有配置在「小程序后台 → 开发设置 → 服务器域名」里的域名才会建立实质性的网络连接。解决办法是在小程序开发者工具里勾选「不校验合法域名」，但在正式环境中，必须把 Odoo 的域名配置进去，否则手机端小程序根本请求不到你的服务器。

第二，微信回调推送一直报 URL 超时。这个问题的本质是 Odoo 的gevent模式与长任务冲突。微信推送回调是同步请求，如果 Odoo 处理回调的代码里调用了耗时的同步方法（比如 AI 回复生成），请求处理时间超过 5 秒，微信侧就会判定失败并重试。重试几次后微信会直接把回调地址的推送能力关掉。解决方法是回调接口只做入队操作，把实际的消息解析丢到 Odoo 的queue_job后台任务里异步执行。

python # 回调接口只入队，不处理 @http.route('/social/wechat/callback', type='json', auth='public', methods=['POST', 'GET']) def wechat_callback(self, **kwargs): if self._verify_wechat_signature(kwargs.get('signature'), ...): env['queue.job'].enqueue( 'social.service_wechat._process_inbound_message', message_payload=request.jsonrequest ) return 'success' return 'invalid signature'

第三，H5 页面在微信里打开时识别不了二维码。这个听起来很玄学，其实是 UA 的问题。微信内置浏览器的 UA 里有MicroMessenger字样，你可以据此判断当前环境。但如果你在服务端做了 UA 改写或者反向代理去掉了这部分信息，JS 调用的wx.config就会失败，导致扫码、分享这类能力不可用。排查方法是先输出window.navigator.userAgent，确认 MicroMessenger 存在，再检查 Odoo 网关层有没有把这个请求头字段过滤掉。

第四，企业微信里发的图片消息在 Odoo 后台显示不出来。这是素材上传接口的 domain 没对齐造成的。企业微信的图片素材上传后会返回一个media_id，但你下载这个素材必须用另一个接口，而且media_id的有效期只有三天。模块在处理图片消息时，如果后台任务延迟超过三天才去下载，素材早就失效了。解决方法是收到图片消息的瞬间立即把media_id下载为本地附件，存到 Odoo 的ir.attachment里，这之后就跟企业微信没有关系了。注意这个设计是我后来补上的，原版模块没有做主动下载。

第五，AI 智能体生成的回复建议出现「幻觉」，给客户报了根本不存在的价格。这是大模型自身的已知问题，模块的缓解方案是在 Prompt 里强行注入 Odoo 当前商品的价格列表，并要求模型只能引用这个列表里的数据。但即便如此，模型偶尔还是会编造折扣信息。我的建议是：所有涉及金额的自动回复必须经过人工确认才能发送，二次确认的交互直接做成 Odoo 里的待办审批流。

6. 消息到行动的最后一公里：用 AI 自动生成客户画像标签

聊一个进阶用法，也算是这个模块我觉得最有价值的地方：把消息记录变成客户画像标签，用行为数据反向驱动营销活动。

模块接入 AI 智能体后，不只是做回复建议，它会分析一个客户在多个渠道的历史消息，提取出关键词标签，比如「关注价格」「疑似竞品对比」「决策周期长」。这些标签可以通过一个定时任务，自动写入res.partner的x_social_tags字段。你可以用这些标签做客户分群，给不同分群的人推不同的营销内容，而不需要手动打标。

python # 定时任务：聚合客户标签 def _cron_aggregate_customer_tags(self): customers = self.env['res.partner'].search([ ('is_social_customer', '=', True) ]) for partner in customers: messages = self.env['social.message'].search([ ('partner_id', '=', partner.id), ('direction', '=', 'inbound') ], order='create_date desc', limit=50) content = '\n'.join([m.body for m in messages]) tags = self._extract_tags_with_llm(content) partner.x_social_tags = ','.join(tags)

这个_extract_tags_with_llm的 Prompt 设计有一个小技巧：不要直接问「这个客户有什么特征」，而是要模型「以客户运营专家的视角，给出 3-5 个影响成交的关键标签」。把角色前置后，输出的内容更具体，不会出现「客户很重要」「需要跟进」这种废话。调试 Prompt 时，我会同时让模型输出置信度分数，低于 0.6 的标签直接丢弃。

标签积累到一定程度，就能做营销自动化了。模块里有现成的规则模板：给打上「竞品对比」标签的客户群发一条带有优惠券的模板消息，触发条件是标签新增后的 24 小时以内。这里要注意模板消息的合规性，微信对营销类消息的发送频率和内容审核很严格，违规会导致模板消息功能被禁。

还有一个可以自己动手加的功能：把客户在不同渠道的行为拼成一条完整 Timeline。因为所有渠道的消息都落在同一张social.message表里，你可以写一个简单的视图，按客户分组显示时间线，这样人工客服在 Odoo 里点开一个客户，就能看到他在微信问过价格、在小程序下过单、在抖音评论过新品——不用再切五个后台去翻记录。

模块整体跑下来，我能明显感受到设计者对微信生态的理解，比如对 48 小时回复窗口的处理、对消息幂等性的考虑、对素材时效性的敏感，这些都是书本上看不到的实战经验。如果你的 Odoo 项目正卡在客户数据分散、多平台运营低效这个瓶颈上，这份资源值得顺着 2.1 到 4.5 的配置顺序完整过一遍代码。

本文还有配套的精品资源，点击获取