当AI实习生坚持认为一个「永远不会推进」的客服需求可以实现时，一场零成本的技术冒险就此展开。本文将揭秘如何利用腾讯云函数和RAG技术，在没有技术团队和服务器的情况下，打造出24小时在线的AI客服系统，并分享产品经理在与AI协作过程中那些令人意外的发现与成长。

一、一个「永远不会推进」的需求

我们公司的客服负责人有个需求：给小程序装一个能 7×24 小时值班的 AI 客服。

需求背景很简单：每天询问量不超过 100 条，但时间分布散，人工覆盖 24 小时至少需要 5 个客服轮班。客服部已经沉淀了一套非常成熟的问答 SOP，传统客服简单培训就能上手——理论上 AI 也可以。

但问题来了：我们公司的技术开发全部外包，内部不存代码资产，开发资源极其有限。这类需求的排期现实是 1-3 个月，而且大概率让位给更紧急的业务需求。

用产品经理的话说：这是一个「永远不会被推进的项目」。

本着「事事有回音」的原则，我没有直接拒绝，而是打开了和 AI 的对话框，开始做 research——本意是找到一堆无法落地的客观理由，给需求方一个有据可查的回复。

结果 Claude 告诉我：这是个可以实现的需求。

我内心 OS：这 AI 实习生怎么读不懂画外音呢？非要逼人进步。

二、架构选型：怎么做到月费 ¥0

既然 AI 坚持说能做，那就只能一步步往下走。

第一个决策：用什么来跑这个服务？

买云服务器？最便宜的也要 ¥40-100/月，而且要运维。对一个没有技术团队的产品经理来说，服务器崩了根本不知道怎么办。

AI 给出的方案是腾讯云函数（SCF）——用事件驱动的 Serverless 架构，只有真正收到消息时才运行代码，其余时间完全不计费。

对照我们的实际用量算一下：

结论：长期在免费额度内，月费约 ¥0（一次性SCF投入￥40+少量模型MAAS费用）。

整体架构链路如下：

用户发消息

→ 微信服务器（AES 加密 XML）

→ 腾讯云函数（FastAPI）

→ RAG 检索知识库 + AI 生成回复

→ 调用微信 API 发送回复

AI 模型选用 DeepSeek，API 按量付费，100 条消息的 token 成本基本可以忽略不计。整个系统没有服务器、没有数据库、没有运维——产品经理能看懂的架构。

三、知识库：把客服 SOP 装进 AI 的脑子

这套系统真正有价值的地方，是 RAG（检索增强生成） 机制。

AI 的通病是「胡说」——当它不知道答案时，会用听起来合理的话糊弄过去。对客服场景来说，这是致命的。

解决方案是给 AI 一个知识库。用户发来消息时，系统先检索知识库里的标准问答，把匹配的内容塞进 AI 的提示词，AI 只需要用它自己的语言把这个答案输出给用户。

知识库的每条记录长这样：

{

“question”: “如何申请退款？”,

“answer”: “支持收到商品后 7 天无理由退款，请在「我的订单」中申请。”,

“keywords”: [“退款”, “退货”, “7天”, “无理由”],

“image_url”: “”

}

关键词命中 + 汉字重叠的双重评分机制，确保检索结果的相关性。

客服负责人只需要维护这份 JSON 文件，不需要懂代码。把原有的 SOP 整理进去，AI 就能按标准答案回复——可以正确调用客服负责人提供的回答模板，这也是客服负责人最终点头认可的核心原因。

四、最大的坑：人才是那个慢的

项目最难熬的阶段，不是设计，而是部署。

选定云函数后，遇到了第一个硬核问题：云函数运行环境是 Python 3.10，我本机是 Python 3.12——中间有几个依赖包存在版本不兼容。更坑的是，压缩包的打包方式也有讲究，必须通过 Python 脚本压缩，否则会出现文件丢失。

这些问题我一开始完全不知道。

于是进入了「提交→失败→复制日志→给 AI 分析→修改→再提交」的死循环，前后重复了十几次，才最终找到根本原因并成功部署。

事后我复盘，这个过程里有一个让我难受的发现：

人才是那个拖慢进度的因素。

原因有两个：

1. 我对项目依赖、环境架构的知识储备不足，无法在部署失败时第一时间定位问题，只能靠反复试错积累认知。
2. 人类的「复制粘贴速度」远远慢于 AI 的 token 阅读速度。如果 AI 能自己提交部署、查看日志、修改代码，这个问题可能几分钟就解决了。

后来我真的解决了这个问题——用腾讯云 CloudBase Framework CLI，让 AI 直接在终端里完成部署、查看日志，把人从「传话筒」的角色里彻底解放出来。

整个流程变成了：AI 写代码 → AI 执行 cloudbase framework deploy → AI 读日志报错 → AI 自己修复 → 再次部署。人只需要在旁边看着，偶尔拍板。

事后算了一下：如果当初项目启动时就搭好这套 CLI 脚手架，整个项目的工时大概还能再节约 30%。那十几次手动提交的来回，本质上都是在替 AI 做它完全可以自己做的事。

想把这套一键部署给协作者试用？只需三步完成子账号授权：

第 1 步：在腾讯云 CAM 控制台创建子账号

进入 访问管理 CAM → 用户 → 新建用户 → 自定义创建 → 勾选「可编程访问」，创建完成后下载 SecretId / SecretKey（只显示一次）。

第 2 步：给子账号授予 CloudBase 权限

在子账号权限页搜索并勾选：

QcloudTCBFullAccess（云开发 CloudBase 完整权限）

只想部署不想给过多权限的话，可以只授 QcloudSCFFullAccess（云函数权限），够用。

第 3 步：子账号用密钥登录 CLI 并部署

# 安装 CLI（一次性）

npm install -g @cloudbase/cli

# 用子账号密钥登录

cloudbase login –secretId YOUR_SECRET_ID –secretKey YOUR_SECRET_KEY

# 进入项目目录，一键部署

cloudbase framework deploy

部署完成后，日志、函数状态都可以在终端直接查看——AI 可以全程接管，不再需要人类在浏览器和聊天框之间来回复制粘贴。

五、落地效果：媲美初级客服，24h 不间断

经过内部测试，这套系统目前的回答水平可以媲美初级客服，客服负责人认为已达到可用标准。

它能做到的事：

• 常见问题的标准答案，按知识库模板精准回复
• 多轮对话记忆（保留最近 5 轮上下文）
• 「正在输入」状态提示，用户体验接近人工
• 24 小时不间断，不需要排班

它做不到的事——也不需要做到：

• 处理复杂的投诉、纠纷、异常订单
• 这些场景直接触发「转人工」关键词，切换到真实客服

这是这套系统的核心定位：AI 承担 24h 的首响层，复杂问题交还给人。不是要取代客服，而是把客服从「凌晨 3 点还要守着手机回”你们几点开门”」这件事里解放出来。

六、给同行的一句真心话

如果你是同样没有技术背景的产品经理，看完这篇文章想复刻这个项目，我只想说一件事：

用平常心去对待落地项目这个目标。

我们本来就在用 AI 不断拓宽自己的能力边界，对自己宽容些。落地项目时，你甚至可以用专业的语言告诉 AI 困难之处，质疑落地的可能性——如果这个问题真的可以解决，AI 会一步步指引你。如果不行，你也得到了一个有据可查的答案。

失败的项目，不过是浪费了一些 token，换来一些经验。

而那些创造的过程，等待 AI 回复时的学习和思考，才是我们在这个时代最宝贵的个人资产。

AI 时代，从信息时代开始就已经如此——工作产出不是严格和工作时长挂钩的。在工作中慢一点学，可能反而会更快地产出。

那个「读不懂画外音的 AI 实习生」教会我的，大概就是这件事。