1）立项原因：精密测量设备（CNC 机床测头、对刀仪、激光干涉仪）维修是典型的高专业度、低频次 B2B 业务。客户习惯直接在微信里问：这个测头撞了还能不能修、有没有配件、修好要多久、我的单子到哪一步了。原来全部依靠人工客服，工程师在车间或出差时无法及时回复，夜间与周末的咨询大量流失；客户描述又很口语（“测头不亮灯”“测出来偏了 2 丝”），必须先追问品牌、型号、数控系统才能判断，沟通成本高。
2）行业场景：客户主要是汽车零部件、3C、模具与通用机械加工厂的设备主管和维修班组，咨询高峰集中在撞机、换线、精度异常之后。业务链路是“咨询→寄修→检测→报价→维修→标定→回寄”，每一步客户都会来问进度；其中电池、测针、密封圈、标定等重复性问题占比很高，人工回复既慢又难统一口径。
3）结论：需要一个 7×24 在线、懂雷尼绍/马波斯/波龙三大品牌产品线，能把一段口语化对话直接变成工单与客户档案，并且严守“不报价、不承诺工期、不做品牌优劣对比”边界的 AI 客服。
1）微信公众号接入：完成服务号服务器配置与 Token 签名校验，处理文本、图片、语音、关注/菜单事件等多类消息，5 秒内被动回复，长任务异步推送。
2）多轮 AI 对话：接入大模型并配套分层系统提示词（角色、能力边界、报修引导、技术口径、禁用词），支持上下文连续对话与超长会话压缩；菜单提供“在线报修 / 查进度 / 手机号绑定”三个入口。
3）RAG 知识库：把官方手册、技术文章、维修案例切片入库（约 9.9 万条），按语义检索 Top-3 注入上下文，并做乱码与低质片段过滤，让回答有据可依。
4）工单自动化：AI 输出结构化标记，后端解析后写入工单表、生成 RP 工单号并回执；客户发送手机号或工单号即可查进度，无需登录、无需下载 App。
5）客户智能档案：7 张表（客户/画像/设备/商机/附件/跟进/报价），AI 在对话中自动建档、补充画像、登记设备与商机，形成从咨询到成交的销售管道。
6）多模态：客户拍测头铭牌或故障照片，系统下载图片→视觉模型识别→转成文字喂给对话，并归档留痕；语音消息直接用微信识别结果参与对话。
7）运营与风控：客服消息/订阅消息推送、管理员通知、手机号自动绑定（只填空值不覆盖历史）、滥用与敏感内容拦截、全链路日志留痕与定时健康巡检。
我独立负责需求梳理、系统架构、后端开发、提示词工程与上线运维，全流程一人完成。
技术栈：Python / Flask + Gunicorn、MySQL、ChromaDB 向量库、Nginx（HTTPS 反代）、Docker、Linux、微信公众号 API、大模型 API。
架构：微信服务器 → Nginx（443/TLS）→ Docker 容器内 Flask → 大模型 API / 向量库 / MySQL → 微信客服消息接口回推；管理端与客服共用一套工单库。
难点与解法：
① 微信 5 秒被动回复窗口：图片识别、知识检索、长回答改为后台线程异步处理，先回占位语再推送结果，避免超时重试导致同一条消息被重复处理。
② 大模型参数幻觉：以向量库检索结果作为事实来源，系统提示词划定边界（不报价、不做品牌优劣对比、不确定就说不确定），关键业务动作由结构化标记驱动，不让模型直接写库。
③ 对话转业务数据：标记解析 + 幂等查重 + 只在字段为空时写入，客户换号不冲掉历史记录；数据库异常绝不阻断消息回复。
④ 稳定性与运维：从微信云托管迁移到独立云服务器，容器化 + 自动重启 + 4 小时健康巡检 + 监控告警，密钥用环境变量与容器内文件双通道兜底，服务连续运行数月无中断。
亮点：客户零学习成本——不加好友、不下载 App、不注册账号，在公众号里说人话就能完成咨询、报修、查进度。
评论