前阵子接了个项目收了客户三万块帮他做了一套AI电商自动化系统。从需求沟通到上线交付前后折腾了将近一个月。这活儿的核心不是“接个大模型API”这么简单真正麻烦的是把AI嵌进客户现有的电商运营流程里让它每天老实干活不出幺蛾子。这篇复盘我就按照从谈需求到落地交付的顺序写把方案选型、模块拆解、成本控制、踩坑实录全捋一遍给准备接同类项目或打算在自己店铺里上AI自动化的朋友一个参考。1. 项目背景与需求拆解1.1 客户到底想要什么客户是个做了三年的淘宝店主手里有几十个SKU主要靠自然流量和老客复购活着。他提的需求是“想用AI把日常运营自动化”但这句话非常含糊等于什么都没说。我做过的外包项目多了最怕的就是这种“你自己看着办”的需求因为最后验收的时候他觉得你没做到位你觉得他当初没说清楚扯皮扯到心累。所以第一次见面我专门花了一个下午拿着他的后台数据一笔一笔问。最终把“AI电商自动化”拆成了四个实际场景客服咨询接待、商品文案生成、竞品数据监控、日常报表汇总。这四个场景是他每天真实在做、且重复度极高的事情每一样都在消耗人工。定完这四个方向客户自己都松了口气说原来脑子里那团乱麻被撸顺了。这里插个谈项目的心得收三万听起来不少但如果你把需求谈模糊了后面返工的成本可能是三万都挡不住的。我给自己定了个习惯凡是自动化类项目第一步只问“你现在每天打开后台都要干哪几件事”用清单的方式逼迫客户把问题具象化。需求一旦变成一行行清单方案才能落地。1.2 三万块钱的边界是怎么划定的三万块的报价在我心里对应的不是“无限功能”而是“边界清晰的一期工程”。一开始客户问我能不能把“所有运营工作都AI化”我直接说不行至少三万块不行。AI自动化的成本大头在开发和联调不在功能数量上盲目铺大饼只会把交付周期拖垮。这期项目我圈定的边界是客服自动回复覆盖售前常见问题、商品文案批量生成模板化内容、竞品价格与评价抓取形成日报、销售与流量数据每日汇总推送。所有涉及账号操作、资金流转、复杂售后纠纷处理的部分一概不做因为风险太高出了事我兜不住客户也兜不住。边界谈清楚之后合同里每条功能都写成了可验收的条目后面对账就没有含糊空间。2. 技术方案选型与架构设计2.1 大模型选API调用还是本地部署方案阶段最大的分歧点是大模型用云厂商API还是做本地部署。客户听人说“本地部署安全、省钱”倾向于拉一台GPU服务器搞本地模型。我给他算了一笔账本地跑一个能用的7B模型单卡3090或4090起步一台机器一两万算上电力、维护、模型调优的时间成本早就超过API调用了。更重要的是本地小模型的电商文案生成效果跟商用大模型旗舰款差距明显写出来的东西带着一股机器味客户自己都摇头。所以最终选型是混合方案客服对话和文案生成调用云端大模型API用通义千问的qwen-plus和DeepSeek-V3双路切换作为冗余兼顾效果和稳定性数据抓取和后台操作类环节用Python脚本加Playwright处理不走模型减少不必要的token开销。至于本地部署等项目量级大到每天百万级token了再考虑现在这个阶段属于纯属给自己添堵。参数选择上我目前用得比较顺手的是温度设0.7top_p设0.85电商文案场景这两个值出来的文本既有一定多样性又不至于跑飞。客服场景温度降到0.3让回复更稳定少点“创作欲”。2.2 自动化整体架构怎么搭这套系统的结构不复杂大致是一条单向流水线触发源定时器、平台消息回调、人工指令进到任务队列队列分发到对应的处理模块模块去调大模型或直接执行脚本结果写回数据库或通过钉钉/微信机器人推送。核心是一个用FastAPI写的调度服务挂了一堆任务类型。电商场景里最麻烦的是接口对接。淘宝/天猫的开放平台接口申请有门槛客户没有自研团队拿不到太多高级权限所以抓数据我直接走了爬虫路线用Playwright控制浏览器登录后台解析接口返回的JSON。整套架构跑下来最大的感悟就是别迷信“全AI化”该用脚本的地方用脚本AI只负责“生成内容”和“做决策”执行的事交给确定性代码。2.3 为什么选了Agent框架而不是硬编码工作流开发过程中我面临一个选择每个任务写独立的if-else逻辑还是用一个带简单记忆和工具调用能力的Agent框架。最终我选择了一个自研的轻量Agent方案给大模型配备工具调用能力让它根据用户意图自己决定调用哪个工具。举个例子客户问“昨天哪个链接流量跌了”传统硬编码工作流你就得提前写死很多分支但用Agent框架模型自己理解意图然后去调一个“查询商品流量”的函数再从返回结果里组织回答。这个弹性和后续扩展性都更好。但Agent框架也有坑就是模型偶尔会“自作聪明”调用错误参数所以我在工具调用层加了参数白名单校验不在列表里的参数一律拦截。3. 核心模块拆解与实操细节3.1 智能客服不是简单接个API就完事客服模块是我花时间最多的部分也是客户感知最强的一部分。原以为把大模型API接上、系统自动回复就完事了实际做下来发现根本不是那么回事。最大的问题是大模型不懂客户的商品库你问它“这件衣服适合多少斤穿”它真敢给你瞎编。所以必须给模型做RAG把客户店铺的商品资料、尺码表、售后政策全部向量化存起来回答问题时先检索相关资料再让模型基于资料回答。具体实现上我把商品信息切成小段文本用Embedding模型转成向量存进轻量向量库。收到客户问题时先在商品知识库里做相似度检索取Top 5内容拼进Prompt再让大模型归纳回答。这么做之后胡编乱造的概率大幅下降而且有一个附加好处商品的促销话术可以随手补进知识库客服回复时顺带就能带出活动信息。客服模块还要处理一个容易被忽略的问题聊天内容里的错别字和口语化表达。比如“包邮吗亲”“几天能到”。单纯把原始文本丢给大模型容易出现理解偏差。我在前面加了一层输入清洗函数统一把“亲”“呢”“哦”之类的语气词去掉再把“几天能到”这类口语映射成标准问句“发货时效”模型理解准确度马上就上去了。3.2 竞品数据监控Playwright抓页面加降噪解析竞品监控模块是我最开始想得太简单的地方。客户要看竞品的价格变动和新上架商品我就想每天定时抓一遍竞品链接的页面提取价格和标题。结果发现真实世界比想象中脏得多电商页面有反爬验证、有动态加载、有各种无效字符和广告推荐位干扰。最终方案是用Playwright的无头浏览器模式运行时模拟真实用户操作。启动浏览器访问竞品链接等待核心接口响应返回JSON直接从JSON里解析关键字段。这么做比解析DOM稳定得多因为接口返回的JSON结构很少变动而页面结构三天两头就改版。数据清洗环节我写了几条简单规则剔除促销横幅位置的干扰文案合并只改动大小写或空格的重复标题价格字段保留最近72小时的完整记录用于画趋势线。这里提醒一句抓竞品页面属于灰色地带别做太狠抓取频率控制在每小时一次以内别给人家服务器造成压力也别把抓来的数据用于商业发布。给客户交付时我明确写了数据仅内部参考不得转售。3.3 商品文案生成模板化Prompt加批量优化商品文案是客户最先看到效果的功能也是让我最有成就感的一块。我写了一套支持批量生成的文案工作流从客户Excel表格里读取商品名称、核心卖点、材质、适用人群每行商品组装一个Prompt调用大模型生成标题、五点描述、详情页段落和社交媒体口播稿。Prompt模板我在项目里反复调了七八版最终固定的结构是四段式角色设定、商品信息、风格要求、输出格式。比如角色设定是“资深电商运营擅长把产品参数转化为用户可感知的卖点”风格要求是“口语化、突出使用场景、避免机械罗列参数”输出格式是“标题一行、五点描述用短句、详情页段落按3段输出”。这套模板化方案最大的好处是客户自己也能维护新商品上架时把参数填进Excel跑一遍脚本几分钟就能出来所有渠道需要的文案版本。批量生成有个常见坑几十条商品同时调用API容易出现部分返回内容残缺或者格式错乱的情况。我在生成脚本里加了校验函数输出后检查是否包含指定的关键卖点词以及字数是否在合理区间不合格的自动重试一次。这套机制的失败率从第一版的10%左右降到了2%以下。3.4 数据报表汇总定时任务加推送闭环数据报表模块是唯一一个客户每天都会打开看的功能。我写了一个每日凌晨的定时任务跑Python脚本采集店铺前一天的订单数、销售额、退款率和流量来源汇总成一张表格再通过企业微信机器人推送到客户的手机上。客户说他现在每天早上坐地铁时刷一眼就能知道店铺状态再也不用打开电脑进后台了。这里有个细节值得单独讲多平台数据的时间口径不统一淘宝用的是自然日抖音用的是自然日但统计延迟不一样拼多多某些指标是T1更新的。如果直接拼在一起很容易出现对不上账的情况。我在汇总表里统一标注了每个数据源的时间口径并在表格底部加了一行“数据更新截止时间”避免客户拿不同口径的数据对比时一头雾水。就这个小小的标注客户专门发消息说做得很专业。4. Token消耗控制与成本优化4.1 成本先算明白再动手做AI项目最怕的就是“功能上线了才发现API账单爆炸”。我接这个项目的时候客户给的预算是包含一部分运行费用的但没说清楚上限。我开工前先拿客户的历史数据估了个量级每天客服对话大约150轮、文案生成大约20条、其他杂项不超过50次调用加起来每天大约消耗35万到50万token。按当时通义千问qwen-plus的价格算一个月撑死在1500到2500元之间。这个量级对三万的项目来说是健康的我才敢放心用高配模型。如果估算出来成本超过项目款的30%我一般会劝客户做减法比如降低文案生成频率或者客服场景换更便宜的小模型。做项目的人心里得有本账功能做得再炫客户以后养不起也是失败的交付。4.2 上下文瘦身与缓存复用在客服场景里多轮对话随着时间的推移会把上下文越滚越长每轮对话都在重复发送前面的历史记录成本直线上升。我处理的办法是滑动窗口只保留最近六轮对话作为上下文更早的历史记录做摘要后存进内存变量摘要本身不超过二百字。这个策略让客服模块的长对话成本降低了大概一半而且没有明显感觉到回答质量的下降。文案生成模块我做了Prompt缓存。二十条商品文案的Prompt头部是非常相似的只有商品参数和卖点部分不同。我在代码里把固定部分缓存成模板每次请求只替换动态参数虽然响应速度提升不明显但整体token量确实少了一些。另外我把温度参数适当调低之后生成结果的稳定性提高了重试次数变少等于间接省了钱。4.3 备用API双路切换电商行业有个真实存在的痛点大模型API偶尔会抽风要么响应超时要么返回明显错误。如果客服系统挂了客户是直接损失询单的这就不能接受。所以我做了双路切换主API用通义千问备用API用DeepSeek日常请求都走主路一旦出现连续三次超时或返回500错误代码自动切到备用API等主路恢复之后自动回切。切换逻辑本身不复杂核心是要加一个健康状态计数器记录连续失败次数。在项目里这个双路机制在第二周就真实触发过一次客户完全没有感知到那个瞬间我觉得这套系统才真正算是“能扛事的东西”。5. 实战踩坑与问题排查记录5.1 大模型幻觉怎么压住客服模块第一个星期就出现了一次严重的幻觉事故。客户问某款连衣裙“是不是纯棉的”商品资料里写的是“棉麻混纺”模型却回复“是的100%纯棉”。幸亏客户自己多看了一眼否则就是一次售后纠纷。这件事给我提了个醒RAG不是接上就万事大吉必须加约束规则。我后来在Prompt里加了一条硬性指令“回答商品参数时必须严格基于给定资料若资料中不存在该信息必须明确回复‘资料未提及建议咨询人工客服’禁止推测。”同时在后端代码里加了一层关键词校验凡是回复里出现“纯棉”“真丝”“头层牛皮”这类高风险材质词自动与商品知识库比对不一致就转人工客服处理。这条组合策略上了之后幻觉类投诉归零算是彻底解决了这类问题。5.2 接口限流和并发排队开发测试时没感觉正式上线第一天就被教育了。客户店铺上午十点迎来咨询高峰几十条消息同时涌进系统我原本以为FastAPI天然支持并发没做特别处理结果直接把API的每分钟调用限额打爆了后面的一堆请求全部报错。排查后发现大模型API是按每分钟请求数和每分钟token数双层限流的咨询高峰期随便一下就超了。我的解决方式是在自己这侧加了一个令牌桶限流器设置每分钟最多调度12次模型调用超出部分先放在内存队列里排队。另外把六秒之内到达的相似问题做了合并缓存同一个商品尺码的问题一分钟内重复问十遍就只调一次模型其余直接复用第一次的回答。上线后观察了两周排队的部分最多等待几秒钟就能处理客户完全没感受到延迟。5.3 定时任务丢跑问题数据报表模块上线第一天晚上就没跑出来。我查日志发现是Python的定时任务挂在了一个长期运行的进程里半夜触发了内存里的一个隐藏异常进程崩了任务自然就没跑。这事让我重新评估了部署方案最后改成了系统级定时器直接调用Python脚本脚本每次独立运行跑完就退出互不干扰。改完以后我又加了一道保险每天推送完成之后系统向我的测试群发一条成功通知如果早上八点没收到通知就说明任务失败了会自动触发告警。运维这件事说白了就是用笨办法防止静默失败。5.4 预期管理是隐形工作量技术问题都好解决最难的是客户的预期管理。客户一开始以为上了AI系统就能“躺着赚钱”我跟他对齐的目标是“帮你把重复工作省下来让你有时间去做真正需要人判断的事情”。光这个认知对齐就花了大概两天的沟通时间。我在交付文档里特地写了个“系统不能做什么”的章节把不支持的场景一一列全。比如不能处理复杂售后纠纷、不能自动改价、不能应对平台规则突变。这样做的目的是让客户对系统边界有合理预期后续真遇到这类问题不会怪到系统头上反而会把它当成正常业务的一部分去处理。6. 交付验收与后续维护经验6.1 验收标准按场景来定交付验收阶段我准备了三个维度的标准功能正确性、稳定性、成本可控性。功能正确性看每个模块是否能完成预设任务稳定性看连续一周的运行数据成本可控性看日均token消耗是否在预算内。这三个维度都要有数据支撑我用后台埋点记录了每次请求的响应时间、token消耗、成功失败状态验收时直接导出一周的统计报表给客户看。客户看到报表里写着“客服模块日处理消息约两百条日均token消耗约十二万一天花费大约三十元”的时候他的表情从怀疑变成了踏实。说到底商业客户要的不是炫技是清清楚楚的投入产出比。6.2 维护期内的两次真实告警交付后的维护期内我经历过两次告警。一次是竞品监控模块的页面改版导致抓取失败Playwright选择器匹配不上了我连夜更新了选择器规则才恢复。另一次是企业微信机器人因为主动消息频率限制被平台暂时封禁我紧急加了消息发送间隔并申请了应用白名单之后就没再出过问题。这两次告警让我总结出了一个经验任何依赖第三方平台的功能都要在代码里预留手动开关。页面改版、平台封禁这类事情早晚会发生有了开关你可以先一键暂停模块再慢慢修不会影响整条自动化链路。6.3 项目做完之后的几点个人体会这个项目做下来我最大的体会是AI自动化的价值不在于“看起来聪明”而在于“稳定地干活”。大模型本身再多才多艺落到具体的电商场景里还是要靠工程化的流程管理、异常兜底和成本控制来支撑。花里胡哨的Agent框架和所谓的通用人工智能都不如一条老老实实跑数据的流水线实在。另外接这类项目一定要在合同里写清楚数据使用边界和模型API费用承担方式。我这次把API费用上限划给了客户承担超出部分单独结算避免了自己垫钱运行的风险。同时所有抓取数据仅限内部使用不公开传播不给客户带来合规风险。这一点对做外包接活的人来说尤其重要保护好自己才能长久做下去。