我来分享一个完整的营销 AI 项目。

这个营销 AI 项目的起点是什么呢？我们团队原来是做广告营销平台的，有一套基于用户、产品、标签库的多平台广告投放和多平台自动化客户营销系统。

这是我们团队原来提供的广告平台，营销平台的核心业务流程，你可以看看，理解项目背景。

图片

当时我们想，至少有两个产品方向可以借助微信 AI 这种模式。一个是企业营销知识服务，以企业自身的知识库为基础，营销平台或广告平台可以通过微信 AI 的形式高效地触达用户。另外一个方向是潜在客户的营销，基于平台现有客户库、潜在客户库，结合微信 AI 做老客户运营和新客户拓展。这个两个方向的核心，都是 AI+ 微信的结合。

传统营销的痛点

一、优化客户营销服务

传统服务难满足即时性与个性化需求，AI 通过智能聊天机器人突破局限：7×24 小时响应减少用户流失，结合用户数据生成专属消息（如优惠提醒、产品推荐），提升互动体验。

二、革新营销内容生产

传统内容生成耗力、周期长，生成式 AI 可基于品牌、人群与场景，快速生成广告文案、短视频脚本等素材，并优化内容细节，兼顾生产效率与质量。

三、升级数据分析与投放

传统数据分析低效、精准度低，AI 能快速处理海量数据，构建多维度用户画像，据此制定投放策略，实现广告与用户精准匹配，提升转化率与资源利用率。

微信 AI 的设计

显然，这些痛点不能一次解决。其实我们的整个项目经历了微信群 AI 开发，多模态 AI 开发，基于 Agent 的营销 AI 和营销 Agent 平台开发这 4 个阶段。具体过程会在接下来文章里展开介绍，这节课我们先从基础的 AI 结合微信交互开始。

先看看原有的广告营销系统的交互，我摘取了部分功能，比如营销文章生成，多平台广告，数据分析，邮件营销工具等等。

图片

我们想的是这些功能都可以在微信的聊天界面中完成，下面是基于微信的 AI 界面交互设计。用微信 AI 聊天的形式实现这些功能，本质上是通过大模型的上下文识别能力获得用户的输入，再调用后端能力实现具体功能。从设计角度看，前端微信结合 AI 的交互更加灵活高效，后端接入 AI 则增强了营销系统的内核能力，整体上可以提升人机交互效率和系统运行效率。

图片

到这一步，只能算有了一个设计蓝图。

微信 AI 的实现

在设计上，我们考虑了未来的营销 AI 能力，具体实现上则开发了基础的文本聊天功能。这个基础版本的微信 AI 文本聊天功能是怎么实现的呢？

架构选型

要实现微信 AI 聊天功能需要解决两个问题。首先需要一个支持 RPA 架构的微信机器人，实现微信消息的代理收发，以及一些微信界面的自动化操作。其次，AI 软件需要对接大模型，实现对用户聊天的代理。

比如上述交互中的 @AI广告 这个消息前缀，目的就是让 RPA 机器人在群聊中识别到用户想调用 AI 能力，从而路由到对应的 AI 广告机器人，让机器人处理、回复这条消息。

图片

我们选用了支持微信 RPA 的Python 库 WXAuto。这个 Python 库支持所有的微信代理操作，比如搜索群名搜索、读取群列表、读取群消息列表、模拟按键操作等。

假设我们要 hook 的微信群名称是 “AI 营销体验群”，那只要组合这些微信代理操作就可以实现 RPA 的代理逻辑。

至于实现最终 AI 聊天的大模型，我们选择的是 GPT 接口，经过一定的完善，搭建了一个 AI 微信机器人架构。具体实现思路，就是当程序接收到新的 @AI 广告的消息内容后，AI 广告机器人程序调用 GPT 的接口获得回复，最后调用 RPA 把内容回复到群里并 @用户。

图片

GPT 开发对接

OpenAI 的对接开发相对容易，具体对接的时候需要先安装相应的 Python 库，并且在环境变量中设置你的 OPENAI_API_KEY。参考下面的代码：

pip install openai requests
export OPENAI_API_KEY=your_openai_api_key

假设用户在群里 @AI广告 机器人的消息是“请你写一则广告，主题是推广一款新的 AI 软件”，那么微信机器人实际上只是代理用户的这条消息发送给 GPT，等待 GPT 回复消息，再将其转发到群里。

也就是说，这里的一次 GPT 操作就是一个标准的 GPT 大模型接口调用。

import os
import requests




def get_chatgpt_response(prompt: str) -> str:
    api_key = os.getenv('OPENAI_API_KEY')  # 从环境变量中获取 API 密钥
    url = 'https://api.openai.com/v1/completions'  # OpenAI API 的端点
    headers = {
        'Authorization': f'Bearer {api_key}',  # 设置授权头
        'Content-Type': 'application/json'  # 设置内容类型
    }
    data = {
        'model': 'text-davinci-003',  # 使用 text-davinci-003 模型
        'prompt': prompt,  # 提供给模型的提示
        'max_tokens': 1500,  # 设置生成的最大 tokens 数
        'temperature': 0.7,  # 控制输出的随机性
        'n': 1,  # 返回一个结果
        'stop': None  # 可以设置停止标志
    }
    response = requests.post(url, headers=headers, jsnotallow=data)  # 发送 POST 请求
    result = response.json()  # 获取 JSON 响应
    return result['choices'][0]['text'].strip()  # 提取并返回生成的文本




# 示例对话
prompt = """
请你写一则广告，主题是推广一款新的AI软件 
"""




# 调用函数
response = get_chatgpt_response(prompt)
print(response)  # 打印响应

GPT 接口调用的过程中有两个核心参数。一个是 model：text-davinci-003，它代表标准的 GPT3 大语言模型。另一个是 prompt，也就是本次大模型调用的提示词，在我们的场景里就是用户像机器人的提问 请你写一则广告，主题是推广一款新的AI软件。

这里注意，如果是单次操作这段代码并没有问题，但是要支持用户带历史消息的会话功能，则需要保存历史会话内容，并且每次的 prompt 提示词都要带上整个历史消息。

具体逻辑是每当用户给 @AI广告 机器人发送消息 message 时，都需要将这个消息增加到历史会话列表上，再对 GPT 发起请求，而从 GPT 得到的 response 也要立即加入历史会话列表。参考下面的示例：

... 
# 示例对话
conversation_history = """
User: 请你写一则广告，主题是推广一款新的AI软件
AI: 这是一款全新的AI操作软件
"""




#新增用户提问
add_user_message(message="注意软件的名字叫 智者AI")




conversation_history = """
User: 请你写一则广告，主题是推广一款新的AI软件
AI: 这是一款全新的AI操作软件
User: 注意软件的名字叫 智者AI
AI：
"""




# 调用函数
response = get_chatgpt_response(conversation_history)
print(response)  # 打印响应




#新增历史消息
add_response_to_history(response)

我们注意到代码中的 conversation_history 用 User 表示用户的消息，用 AI 表示 GPT 回复的消息。其实这个格式你可以自己定义，只要能表示出两个角色，GPT 就可以在它的引导下输出适合这个角色的消息。

真实的微信 AI 要实现一套用户消息存储系统，每次用户会话时只要重新组织这个 conversation_history 即可。参考下面一条新用户消息的流程示意图，会更好理解一些。

图片

难点与挑战

看起来似乎一切很顺利，不过，在微信 AI 项目里，更多的难点和挑战其实在 RPA 操作的部分，下面重点说几个核心的经验。

一、核心挑战：RPA 轮询效率瓶颈

RPA 基于界面操作模拟原理，为及时处理消息，需定时轮询群消息 —— 即便群内无新消息，仍需执行轮询动作。但随着群数量增加，这种模式的效率会显著下降，因此如何提升轮询效率、减少无效轮询次数，成为关键问题。若将 “挨个搜索群名称检查消息” 定义为基础的 V1 版本，后续针对消息轮询还迭代了两个优化版本。

二、V2 版本优化：利用消息列表特性减少操作

为降低不必要的群搜索与界面操作，V2 版本核心逻辑是借力微信消息列表的固有特点：当群内有新消息时，该群会自动置顶至消息列表顶部。基于此，RPA 无需遍历所有群，只需读取消息列表并从上到下检查，直至遇到无新消息的群即可停止，大幅减少了无效操作。

三、V3 版本优化：置顶目标群实现效率最大化

V3 版本在 V2 基础上进一步升级：先将所有 AI 相关的群设置为置顶状态。这样一来，RPA 仅需读取置顶区域内 “有新消息的 AI 群” 即可 —— 若轮询时段内无新消息，只需检查第一个置顶群便停止；若有新消息，也能精准读完所有有消息的置顶群后终止。该逻辑实现了轮询性能与效率的最大化，彻底规避了对无关联群的无效检查。

图片

下面是 V3 版本的消息轮询机制核心代码。

for who in new_list:
        if new_msg_stop >= 1: #msg_stop数越大 漏消息越少
            _debug("msg stop", flush=True)
            break
        #init
        if who not in _old_list.keys():
            init2(who)




        #开始
        wx_cli.ChatWith(who)




        ##尝试获取消息
        try:
            messages = wx_cli.GetAllMessage[-last_count:]
        except Exception as e:
            continue
        ...
        ##过滤消息
        messages = wxmsg.filter(messages,filter_users)
        md5 = wxmsg.md5(messages)
        if md5 == _old_list_md5[who]:
            _debug("no msg", flush=True)
            #确认没有消息
            new_msg_stop = new_msg_stop + 1
            continue
       ....

挑战 2，消息可靠性问题

一、核心诉求：消息系统的可靠性与完整性

对消息系统而言，可靠性是核心 —— 本质是确保消息收发的完整性，既要避免漏读消息，也要防止重复发送。在微信 AI 项目中，RPA 通过读取群消息列表实现消息获取，但过程中面临一个关键障碍：微信消息列表不提供消息 ID 与单条消息时间戳，这使得精准识别并提取最新消息变得极具挑战。

二、痛点与折中方案：利用时间戳消息简化处理

若直接存储并比对整个消息列表，会对计算资源与数据存储产生过高要求。为此，我们采用了折中方案：观察到微信消息列表中，某一时段内的消息会附带一条 “总时间戳消息”，以此为关键节点，仅存储该时间戳之后新增的消息，并通过逐个比对的方式，精准筛选出最新消息，既降低了资源消耗，又保障了消息的可靠性。

三、结合 V3 轮询：保障程序重启后的消息完整

该方案进一步与 V3 版本的群轮询机制结合：当程序重启后，无需遍历所有群，仅需关注有新消息的群。一旦某群出现新消息，立即将此刻的消息列表作为 “初始版本” 存储，后续基于该版本与时间戳消息进行比对更新，从流程上确保了消息不会漏读或重复处理，彻底闭环消息可靠性问题。（可参考示意图辅助理解这一流程）

图片

下面是用于消息排重的核心代码逻辑。

##过滤消息
messages = wxmsg.filter(messages,filter_users)
md5 = wxmsg.md5(messages)
if md5 == _old_list_md5[who]:
    _debug("no msg", flush=True)
    continue




##有新消息
new_messages = wxmsg.find_new(_his_list[who], messages)
_debug(new_messages, flush=True)




if False == new_messages:
    _debug("no new msg", flush=True)
    continue


#更新历史消息
_user_list = wxmsg.find_user(new_messages, _user_list, who)
_old_list[who] = messages
_old_list_count[who] = len(_old_list[who])
md5 = wxmsg.md5(_old_list[who])
_debug(md5, flush=True)
_old_list_md5[who] = md5

挑战 3，微信 RPA 稳定性问题

基于 RPA 的微信操作需要定期登录，这对运营来说是一定的挑战。我们的微信 AI 一直是企业内部试用和测试，所以问题不大。如果正式对外，应该用微信官方推荐的企业微信的接口。

自有模型训练

一、新挑战：消息量暴增与成本压力

在前述三大挑战（轮询效率、消息可靠性）解决后，微信 AI 项目迎来新问题：产品推出后消息量迅速暴增，若持续使用 GPT 付费版本大模型，成本会大幅攀升。基于成本控制考量，我们决定放弃 GPT 付费模型，转而搭建私有大模型，最终选定开源的 ChatGLM-6B 模型作为基础版本。

二、模型效果争议：参数量差距与场景适配

不少人会质疑：ChatGLM-6B 参数量仅 60 亿，远低于 GPT-3 的 1750 亿，效果能否达标？答案需结合项目的营销场景来看：普通营销内容场景对输出内容的复杂度、深度无过高要求，更侧重响应速度与内容适配性。因此，小参数量模型在匹配场景需求的前提下，效果并不逊色于大参数量模型，完全能满足营销类客户问答、互动的基础需求。

三、商用优化：从微调至知识库融合的工程实践

为让 ChatGLM-6B 达到商用标准，我们开展了多阶段优化：初期，利用现有产品库信息对模型进行微调，使其初步具备产品相关的问答能力；后期，将完整的产品知识库数据接入大模型，让模型在与用户的实时会话中动态学习知识库内容，进一步提升回答的准确性与针对性。最终，基于该模型搭建的 “AI 营销客户问答互动自动化系统”，完全满足了项目的商用需求。

这是一个典型的在大模型会话中嵌入知识库的方法。很多企业知识库场景下，模型微调训练的效果往往不如在会话中嵌入知识库的方案。

小结

我希望你能记住两点。一是对大模型能力的评估和掌握方面。从起初的 GPT 接口调用到后来的自有大模型训练和使用，至少在目前营销场景下，自研的小模型也有出色的表现，你在选择模型的时候，也需要根据具体场景来考虑。

回应用户的使用需求，在 RPA 基础上做了很多优化工作，包括轮询效率的提升、消息稳定性的改进等。这是这个案例里的技术价值，为后续开发继续使用微信 AI 交互提供了基础。

图片

文章来自：51CTO