当前位置：首页 > news >正文

微信小程序被AI搅了，我靠这招稳住了

news 2026/8/7 3:58:23

我做小程序前端，三年。从0到1做过电商、社区、工具类，微信里那些坑——支付回调、审核被打回、request域名白名单、分包大小超限——我基本都踩过一遍。最忙那阵，一周能交两个小项目，私活单价八千到两万不等。

直到有个老客户甩给我一个链接，说：“我在网上找个AI工具，一百块，十分钟给我生成了个小程序，你看看能不能直接用。”我点开一看，页面、tabbar、几个基础页面，真像那么回事。他补一句：“你在这个基础上帮我改改就行吧？”改别人AI生成的代码。我那天晚上真没睡着——不是心疼那一单，是怕以后这种单子越来越多，我这三年的手艺不值钱了。

我一个做电商的朋友知道后笑我：“你怕啥，它生成的能过审吗？能接支付吗？”一句话点醒我。后来我认真看了那工具吐出来的代码，好家伙，布局在真机上错乱，老机型组件不兼容，它压根没考虑。客户以为“生成完就能用”，其实离上线还差我平时最烦的那堆适配活。

前阵子又有客户拿AI生成的页面来让我改，我没第一次那么慌了——改这摊活儿，本身也是钱。

客户要的从来不是“代码”，是“能跑通业务的页面”。AI能把骨架生成出来，但它不知道微信支付边界怎么处理，不知道审核为啥老卡“诱导分享”，不知道你这个社区产品的用户路径怎么设计才留得住人。这些，得懂小程序的人干。

一、我没去学怎么“用AI写小程序”，而是把AI接进我现有的小程序

想清楚上面那点，我干脆把AI当零件，塞进我已经在维护的小程序里。具体做了三件事，都是真实上过线的：

1. 智能客服接大模型。原来售后全靠人工回，重复问题占了一半。我在自己后端包了一层，小程序端用 wx.request 调我服务器，服务器再去调大模型对话接口，同时把订单号、物流状态这些真实数据喂进去。用户问“我快递到哪了”，它能结合真实物流回答。为了体验，我让后端走流式返回，前端用 typing 效果一段段吐字，看着跟真人聊差不多。但我写了硬规则：物流信息必须以接口返回为准，模型不许自己编；涉及退款金额，一律转人工。

客服和导购都得记上下文，我把会话存 Redis，按 openid 隔离，模型每轮带上历史，体验才连得上。不然用户问完“在哪发货”再问“那多久到”，它根本不知道你说的是哪单。

2. 商家传图自动出文案。后台让商家上传一张商品图，先走图像识别分出品类，再让大模型按我们定的模板写卖点和标题。上线后商家发品速度快了一截，但这不是全套托管——生成的东西得商家自己过一眼再发。

3. 用向量检索做导购问答。把商品库做成向量索引：标题、类目、卖点先切词、Embedding，存进向量库，用户自然语言问“两百以内送男生的生日礼物”，做 top-k 召回再让模型组织成话术。为了不乱推荐，我把用户 openid 绑上会话，记住他浏览过的商品，推荐更准一点。这块我不敢大改转化流程，先小流量灰度，效果一般，还在调。

技术上关键一点：小程序端永远不直接连模型，密钥放我后端，prompt 里的业务规则写死在服务端。我试过微信云开发，后来还是搬回自建 Node 服务，图的是对调用和花费看得更清。不然密钥一泄露，账单能吓死人。