老板开口第一句总是：你们做的小程序，能不能接AI客服、智能推荐和自动下单？先给结论：三项都能接，而且都是成熟能力。真正的分水岭不在敢不敢接，而在接什么、怎么接、接完多久回本。

"你们做的小程序，能不能接AI客服、智能推荐、自动下单？"

这句话，做这行二十年，我听了几千遍。来咨询的老板把"AI能不能接进来"当成第一道坎，好像接口不通，项目就不敢动工，钱就不敢掏。

先把结论钉死：三项都能接，而且都是成熟能力。微信侧早把消息通道铺好了，小程序里放一个客服按钮就能唤起会话，用户发消息、进会话这些事件，会推送到你配置的服务器地址；微信客服还单独提供一整套接口，能管理客服账号、收发消息、分配会话。支付宝和抖音小程序也有各自的客服消息通道和支付回调，逻辑大同小异。

麻烦在于，问错了问题，就会做错决策。

问"能不能"，不如问"接什么、怎么接、值不值"

三项功能各自的本质完全不同，硬打包成一句"上AI"，预算就成了一锅粥。

AI客服的本质，是大模型加知识库加人工兜底，成败在知识库质量和兜底边界；智能推荐的本质，是拿行为数据算偏好，成败在数据基础和冷启动怎么熬；自动下单的本质，是把订单接口、支付通道、风控规则打通，成败在权限与安全边界。这三件事的技术栈、投入节奏、验收标准，全都不一样。

有个细节很说明问题。来问"能不能接AI"的客户，十个里有八个，真正卡住生意的不是缺一个大模型入口，而是商品SKU没有结构化字段、订单状态只有"已付款""已完成"两态、客服连一份像样的常见问题清单都拿不出来。AI接进来，只是把混乱加速暴露出来。

说白了，可行性从来不是瓶颈，条件才是。

AI客服：成败在知识库，不在大模型

先拆第一项。很多老板以为AI客服就是接个大模型，客户问什么它答什么。错了。大模型只是嘴，知识库才是脑子。

真正的做法分三层。第一层是意图识别，把用户那句"啥时候发""几天到"映射到同一个意图标签——物流查询。第二层是知识库检索，把你的商品政策、售后规则、活动说明切成三百到八百字的片段，每片标上适用商品和生效日期，用户问的时候先检索最相关的两三条，再让大模型照着组织成口语化回答。第三层是兜底，置信度不够就转人工。

这里有个翻车重灾区，必须单独说：凡是涉及"我这单到哪了""还有没有货"的问题，绝不能靠知识库文本推断，必须调订单服务和库存服务的接口拿实时值，再把数字填进话术模板。我见过项目上线后被骂上差评区，原因就是模型拿着三天前的库存描述跟客户说有货，客户下单才发现早卖空了。这一步做不对，AI客服不是帮你省钱，是帮你赶客。

成本这块可以算笔账。国内主流大模型接口的公开报价，轻量档每百万tokens输入几毛钱到一块出头、输出几块钱，旗舰档贵一截。一次典型的多轮客服请求，算上系统提示词和检索片段，输入两三千tokens、输出两三百，折算下来单次咨询的推理成本是几分钱量级，远低于一次人工接待的分摊成本。真正花钱的不是模型调用，是知识库建设和维护的人力。没人认领的知识库，半年后一半内容是过期促销信息，效果必然滑坡。

兜底边界也要设计死。转人工时，把用户标识、历史消息、已识别意图、当前订单快照一起打包给坐席，客户不用从头再说一遍。模型接口超时了怎么办？立刻切到本地预设问答；预设问答也答不上，就自动建一条工单，告诉用户"已记录，同事会在X小时内联系"。绝不允许客户发了消息石沉大海——平台对未响应会话有考核，长期不接会影响活动资格。

智能推荐：成败在数据，冷启动熬不过就别上

第二项。智能推荐听着高级，本质就是拿行为数据算偏好——谁买过什么、看了什么、停了几秒，然后把他可能买单的东西排到前面。

问题在冷启动。新用户没有任何行为，个性化无从谈起，这时候按注册渠道、定位城市、进的第一个页面类目做粗分组，落到"同渠道新客转化最高的前十个商品"就行。等积累够三五次点击和一次收藏，再切到个体模型。新平台一上来就上个性化推荐，推出来的东西驴唇不对马嘴，不如老老实实按销量和上新时间排。

还有一条硬规矩：推荐结果必须能解释、能干预。运营要能把主推款钉在前面，不能被算法完全接管。效果看板看四个数——推荐位曝光点击率、推荐带来的成交占比、推荐商品的毛利率变化、关闭率。如果点击率上升但整体转化率下降，说明模型在往低价品倾斜，要调目标函数。

合规上也别省事。点了"不感兴趣"，那个商品三十天内别再出现在这个人推荐位；用户主动关闭个性化推荐，整个货架退回按销量排序。这不是装饰，是《互联网信息服务算法推荐管理规定》的硬要求，也是止损手段——推荐一直不准的时候，让用户自己关掉，比继续推错更保口碑。

自动下单：成败在权限边界，不是多一个按钮

第三项，也是最需要谨慎的一项。

自动下单听着就是"让智能体帮客户组个单"，真正的风险全在权限边界上。核心做法是"草稿订单"这个中间态——AI生成的订单不能直接生效，必须落在待确认状态，客户点确认才进入正式下单流程。原因很朴素：模型可能把规格搞错，也可能把赠品当成商品计价，中间态给了用户一次核对机会，也给了系统一次校验机会——价格重算、库存重锁、优惠重算全部在确认瞬间重跑一遍。

再往上一层，智能体能自动执行的动作，必须逐条定死四要素：动作范围、金额上限、频次上限、触发前提。比如自动补货下单，单品金额和当日累计都在阈值内、且SKU有历史成交，才让它自动跑；超阈值、新品第一次采购，必须人工审批。退款也一样，小额且在政策内、凭证齐全，自动原路退回；大额、超期、多次退款的账户，转人工。

权限这块，做得成熟的会把它做成多角色安全引擎那样的独立层——把"角色—数据范围—动作"三元组落到每一次接口调用上，客服能看订单不能改价，仓管能调库存不能看客户手机号明文。所有智能体操作都用一个专用的机器账号身份执行，日志聚在一起，要停用一键就停。敏感字段的手机号、身份证、银行卡，交给加密引擎统一做加解密和脱敏，不让每个业务模块自己各写一套、还写得不一致。

这里必须泼一盆冷水："自动下单"不等于"自动扣钱"。自动续费、免密代扣这类能力，依赖委托代扣签约，要先申请对应权限、扣费模板，扣费前还要下发通知，用户可拒绝。资金动作必须有用户事前授权和事中通知，这是底线，没得商量。

三档接入对照表，照着自己的账选

三项功能都不是"一步到位"的事，而是分三档，按规模往上走。

档位	AI客服	智能推荐	自动下单	适配体量
基础档	预设问答加关键词触发，人工坐席接管	按类目、销量、上新时间的规则排序	标准商品页加单一在线支付，无自动动作	刚上线、SKU少于两百、日均订单两位数
高性价比档	大模型加知识库检索加实时订单查询加置信度转人工	多路召回加精排模型加策略控制台加灰度发布	购物车凑单、组合支付、小额自动退款、库存预占释放	有稳定成交数据、SKU数百到数千、日均订单上千
旗舰档	多模型路由加多智能体协作加情绪升级	深度模型加实时特征加多目标优化	智能组单、自动补货采购单、审批矩阵、风控熔断	多渠道多门店、SKU上万、要跨系统协同与审计

基础档不是"穷人版"，它是数据积累器。没有三个月的埋点和成交记录，高性价比档的推荐模型根本没有可训练的样本。直接从基础跳到旗舰，最常见的结果是模型冷启动失败、审批规则形同虚设、团队不会用后台。反过来，已经在日均上千单的体量上还守着基础档，客服人力和转化损失会成为明显的成本拖累，这时候升级的判断依据是"AI独立解决率能不能做到六成以上"和"推荐位能不能贡献一成以上的成交"这两个可测指标。

先接哪项，看这三个数

别三项一起上。按顺序来。

先看咨询量。客服按人头烧钱，晚上八点到十一点没人接，客户转头就走；高频问题占了实际咨询量的七成上下。咨询量大、客服人力贵、有高频问题清单——先接AI客服，这是回本最快的一项。

再看成交数据量和客单价。SKU多、客单价高、有几个月的成交积累——再上智能推荐。数据基础没有，推荐就是摆设。

再落到复购率和订单稳定性。复购率高、订单结构稳定、SKU已经结构化——再碰自动下单。

什么情况下先别碰？商品没有结构化属性、订单状态只有两三个、会员身份多套不互通——这三种情况下，先治数据，再上模型。花两周把SKU属性补齐、状态机理清、身份打通，收益比换一个大模型高得多。AI接进来只是把混乱加速暴露出来，这句话我再说一遍。

上线不等于跑通

验收别看调用量和功能清单，那只能证明系统活着，不能证明它有用。看业务指标：AI独立解决率、转人工后的解决时长、推荐位成交占比、自动下单差错率、库存校验失败率。

顺带提醒一句退出成本。三年前换一个开发团队只是换人写代码，三年后换团队要交接知识库、Skill配置、权限矩阵、模型路由规则和一堆训练数据。所以从一开始就要要求源码、数据和配置的可交付性，把"能不能带走"当作验收的一部分。