当AI实习生坚持认为一个「永远不会推进」的客服需求可以实现时，一场零成本的技术冒险就此展开。本文将揭秘如何利用腾讯云函数和RAG技术，在没有技术团队和服务器的情况下，打造出24小时在线的AI客服系统，并分享产品经理在与AI协作过程中那些令人意外的发现与成长。
我们公司的客服负责人有个需求：给小程序装一个能 7×24 小时值班的 AI 客服。
需求背景很简单：每天询问量不超过 100 条，但时间分布散，人工覆盖 24 小时至少需要 5 个客服轮班。客服部已经沉淀了一套非常成熟的问答 SOP，传统客服简单培训就能上手——理论上 AI 也可以。
但问题来了：我们公司的技术开发全部外包，内部不存代码资产，开发资源极其有限。这类需求的排期现实是 1-3 个月，而且大概率让位给更紧急的业务需求。
用产品经理的话说：这是一个「永远不会被推进的项目」。
本着「事事有回音」的原则，我没有直接拒绝，而是打开了和 AI 的对话框，开始做 research——本意是找到一堆无法落地的客观理由，给需求方一个有据可查的回复。
结果 Claude 告诉我：这是个可以实现的需求。
我内心 OS：这 AI 实习生怎么读不懂画外音呢？非要逼人进步。
既然 AI 坚持说能做，那就只能一步步往下走。
第一个决策：用什么来跑这个服务？
买云服务器？最便宜的也要 ¥40-100/月，而且要运维。对一个没有技术团队的产品经理来说，服务器崩了根本不知道怎么办。
AI 给出的方案是腾讯云函数（SCF）——用事件驱动的 Serverless 架构，只有真正收到消息时才运行代码，其余时间完全不计费。
对照我们的实际用量算一下：
结论：长期在免费额度内，月费约 ¥0（一次性SCF投入￥40+少量模型MAAS费用）。
整体架构链路如下：
用户发消息
→ 微信服务器（AES 加密 XML）
→ 腾讯云函数（FastAPI）
→ RAG 检索知识库 + AI 生成回复
→ 调用微信 API 发送回复
AI 模型选用 DeepSeek，API 按量付费，100 条消息的 token 成本基本可以忽略不计。整个系统没有服务器、没有数据库、没有运维——产品经理能看懂的架构。
这套系统真正有价值的地方，是 RAG（检索增强生成） 机制。
AI 的通病是「胡说」——当它不知道答案时，会用听起来合理的话糊弄过去。对客服场景来说，这是致命的。
解决方案是给 AI 一个知识库。用户发来消息时，系统先检索知识库里的标准问答，把匹配的内容塞进 AI 的提示词，AI 只需要用它自己的语言把这个答案输出给用户。
知识库的每条记录长这样：
{
“question”: “如何申请退款？”,
“answer”: “支持收到商品后 7 天无理由退款，请在「我的订单」中申请。”,
“keywords”: [“退款”, “退货”, “7天”, “无理由”],
“image_url”: “”
}
关键词命中 + 汉字重叠的双重评分机制，确保检索结果的相关性。
客服负责人只需要维护这份 JSON 文件，不需要懂代码。把原有的 SOP 整理进去，AI 就能按标准答案回复——可以正确调用客服负责人提供的回答模板，这也是客服负责人最终点头认可的核心原因。
项目最难熬的阶段，不是设计，而是部署。
选定云函数后，遇到了第一个硬核问题：云函数运行环境是 Python 3.10，我本机是 Python 3.12——中间有几个依赖包存在版本不兼容。更坑的是，压缩包的打包方式也有讲究，必须通过 Python 脚本压缩，否则会出现文件丢失。
这些问题我一开始完全不知道。
于是进入了「提交→失败→复制日志→给 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 可以全程接管，不再需要人类在浏览器和聊天框之间来回复制粘贴。
经过内部测试，这套系统目前的回答水平可以媲美初级客服，客服负责人认为已达到可用标准。
它能做到的事：
它做不到的事——也不需要做到：
这是这套系统的核心定位：AI 承担 24h 的首响层，复杂问题交还给人。不是要取代客服，而是把客服从「凌晨 3 点还要守着手机回”你们几点开门”」这件事里解放出来。
如果你是同样没有技术背景的产品经理，看完这篇文章想复刻这个项目，我只想说一件事：
用平常心去对待落地项目这个目标。
我们本来就在用 AI 不断拓宽自己的能力边界，对自己宽容些。落地项目时，你甚至可以用专业的语言告诉 AI 困难之处，质疑落地的可能性——如果这个问题真的可以解决，AI 会一步步指引你。如果不行，你也得到了一个有据可查的答案。
失败的项目，不过是浪费了一些 token，换来一些经验。
而那些创造的过程，等待 AI 回复时的学习和思考，才是我们在这个时代最宝贵的个人资产。
AI 时代，从信息时代开始就已经如此——工作产出不是严格和工作时长挂钩的。在工作中慢一点学，可能反而会更快地产出。
那个「读不懂画外音的 AI 实习生」教会我的，大概就是这件事。
本文由 @被抢了名字的Kimi 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自用户提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。