企业官网建设流程全解析

前阵子接了个项目，收了客户三万块，帮他做了一套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.7，top_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脚本采集店铺前一天的订单数、销售额、退款率和流量来源，汇总成一张表格，再通过企业微信机器人推送到客户的手机上。客户说他现在每天早上坐地铁时刷一眼就能知道店铺状态，再也不用打开电脑进后台了。

这里有个细节值得单独讲：多平台数据的时间口径不统一，淘宝用的是自然日，抖音用的是自然日但统计延迟不一样，拼多多某些指标是T+1更新的。如果直接拼在一起很容易出现对不上账的情况。我在汇总表里统一标注了每个数据源的时间口径，并在表格底部加了一行“数据更新截止时间”，避免客户拿不同口径的数据对比时一头雾水。就这个小小的标注，客户专门发消息说做得很专业。

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费用上限划给了客户承担，超出部分单独结算，避免了自己垫钱运行的风险。同时，所有抓取数据仅限内部使用，不公开传播，不给客户带来合规风险。这一点对做外包接活的人来说尤其重要，保护好自己才能长久做下去。