企业官网建设流程全解析

做了大半年AI电商项目，踩了不少坑，也沉淀了一套可以复用的技术架构和实战方法论。这篇博文从零开始，把AI智能商城从需求拆解、架构设计、模型选型到落地部署的关键环节一次性说清楚。

先交代背景：这是一个真实落地的小型AI商城项目，核心目标不是“为了AI而AI”，而是解决电商场景里的三个实际问题——用户找商品太慢、客服响应不及时、商品内容生产效率低。整个项目从技术选型到上线用了大约三个月，中间经历了两轮架构调整。如果你正在考虑给自有商城加AI能力，或者想从0搭建一套大模型驱动的电商系统，这篇文章应该能帮你少走不少弯路。

整篇文章会围绕一条主线展开：为什么AI商城不能只靠“接个大模型聊天”来实现，而需要一套完整的工程化架构。我会重点讲清楚技术分层、核心组件选型、AI能力如何嵌入既有业务流程，以及哪些环节最容易翻车。内容偏实践，我会穿插大量真实配置参数和代码片段，保证你看完能直接抄作业。

1. 项目定位与整体设计思路

在动手写代码之前，我花了整整一周做需求梳理和方案选型。这个环节往往被技术团队忽略，但恰恰是整个项目成败的关键。AI商城不是简单地“加一个智能问答框”，它需要重新审视零售业务中每一个需要“思考”的环节，然后思考哪些可以用大模型增强，哪些适合用传统算法，哪些根本不需要AI介入。

1.1 我们到底要做什么样的“AI商城”

我最初拿到的需求文档只有一句话：做一个能自动回复、智能推荐商品的商城。这个描述太笼统，直接做很容易做成四不像。后来我把它拆解成四个可量化的业务场景，这也是AI商城最典型的四个切入点。

第一个场景是智能导购，用户在搜索框输入模糊意图（比如“适合送女朋友的生日礼物”），系统需要理解意图并给出个性化推荐，而不是只做关键词匹配。第二个场景是智能客服，用户咨询售前售后问题时，系统能基于商城知识库自动回复，人工只需要接管复杂投诉。第三个场景是内容生产，用大模型自动生成商品卖点文案、详情页图片和短视频脚本，把运营人员从繁重的内容生产中解放出来。第四个场景是数据分析，对用户评论做情感分析，对流失用户做行为预测。

这四个场景每一个都不难实现，但组合在一起就需要一个统一的技术底座。我见过不少团队分别买了四家AI厂商的方案，结果数据和架构完全割裂，用户体验和运维成本双双失控。所以项目启动的第一原则是：AI能力必须通过统一网关接入，所有场景共享一套基础设施。

1.2 技术路线选择：自建模型还是调用API

这是所有AI项目启动时都会遇到的灵魂拷问。我当时的判断标准很简单：看你的核心资产是什么。如果商城积累了大量私有数据（用户行为、商品知识、售后话术），那RAG检索增强是必须自建的，因为数据安全和企业知识沉淀不能依赖外部厂商。如果只是通用能力（通用问答、文案生成），直接调用大模型API性价比最高。

我最终选择了“混合路线”：自建向量数据库存储商品和企业知识，接入大模型API做内容生成和理解，同时用开源模型部署了一套内网可用的备用问答服务。这样既控制了成本，又保证了核心数据不离开自己的服务器。

具体到技术栈上，后端用了Spring Boot 3，AI集成层用的是Spring AI框架。这个选择主要是为了和现有Java技术栈融合，毕竟整个商城主干都是Java写的，引入Spring AI可以复用已有的Bean管理、配置中心和监控体系，不需要为AI单独维护一套基础设施。如果你团队是Python背景，LangChain或LlamaIndex更合适，技术选型必须和团队能力对齐，不能盲目追新。

1.3 梳理AI商城与传统商城的本质差异

想清楚一个关键问题：AI商城在本质上不是新事物，而是传统商城增加了三个新能力维度。第一个叫语义理解能力，传统商城只能做关键词索引，AI商城能理解“轻便又能装电脑的双肩包”这种复合意图。第二个叫生成能力，商品详情页、活动页可以千人千面地自动生成，而不是运营手工一张张做图。第三个叫推理能力，系统可以根据用户历史行为推断潜在需求，在用户开口之前就做出推荐。

这三个能力维度决定了我们在架构上必须引入大模型服务层、向量检索层和AI编排引擎。同时它们也决定了我们在产品层面要重新设计交互——不再是简单的搜索框+列表页，而是对话+推荐+内容动态生成的混合界面。

2. 技术架构核心拆解

架构设计第一阶段，我画了不下十版草图才定稿，最终落到五层结构。这个分层不一定适合所有团队，但它是我们实践下来最清晰、最容易扩展的形态。核心思想是：把AI能力当作独立服务层，与业务逻辑解耦，通过标准接口对外提供能力。

2.1 五层架构全景

第一层是接入层，包含Web商城、小程序、App多渠道入口，主要职责是统一会话管理和用户鉴权。这里要处理多端会话同步问题，用户在小程序里跟AI助手聊到一半，切到App还要能继续上下文。

第二层是业务服务层，包含订单、商品、库存、用户、营销等传统微服务模块。这一层完全沿用现有系统的能力，基本不需要改动。

第三层是AI服务层，是整个架构的核心增量。我们拆了五个子模块：语义理解服务（支持搜索意图识别和自然语言转SQL）、RAG检索服务（基于向量数据库做商品和企业知识召回）、内容生成服务（文案、图片、视频脚本）、推荐服务（双路召回+重排）、Agent编排服务（处理多轮对话和工具调用）。

第四层是数据层，包括MySQL主库存储业务数据、ES存储商品索引、Milvus向量数据库存储商品和企业知识的embedding向量、Redis缓存热数据。

第五层是基础设施层，包括模型网关、GPU推理节点、日志链路追踪和监控告警系统。

整个链路最关键的枢纽是模型网关。我之前吃过亏：最初直接让各业务模块各自调用大模型API，结果模型一换、接口一变，改代码改到怀疑人生。后来统一封装了一层网关，所有AI请求都走网关转发，业务侧只面对一个标准接口。网关负责的事情包括：模型路由（按业务场景分发到不同的模型）、API密钥管理、请求限流、token计费统计、上下文缓存、失败重试等。模型网关选型上，开源方案如LiteLLM、Kong配合自定义插件都可以，我们自己实现了一个轻量版，大约500行代码，核心就是配置模型映射表加路由策略。

2.2 向量数据库与知识库体系

RAG是整个AI商城最核心的工程。纯粹靠大模型自身知识回答商品问题，一定会出现幻觉——模型不认识你的商品，不知道你的促销政策，还会胡编优惠。解决这个问题的标准方案是RAG：先把商品资料、售后政策、物流说明、客服话术等切片转成向量存入向量库，用户提问时在向量库中检索最相关的片段，把检索结果拼进提示词让模型回答。

向量数据库我选了Milvus，主要原因是它支持混合检索（向量相似度+标量过滤），这是电商场景的刚需。比如用户问“帮我推荐红色、200元以下的连衣裙”，系统需要先在向量库检索语义相似的连衣裙，再用颜色和价格做标量过滤。纯向量检索做不了这种结构化约束，混合检索才能搞定。

Embedding模型选型也是关键，我用的是BGE-large-zh-v1.5，中文表现扎实，512维向量，专门针对中文语料优化过。向量维度是embedding模型定义的，改不了，但你可以调整切块大小。我们最终设置的参数是：商品描述和客服话术按照300字左右切块，块与块之间保留50字重叠，防止割裂语义连贯性。知识库不能一股脑塞进去，还要做清洗去重，不同来源的文本格式五花八门，清洗脚本前前后后写了三千行。

2.3 ArchiMate建模视角看架构关系

在架构评审时，为了让业务和技术团队有共同语言，我用ArchiMate画了架构建模图。这个方法很值得推广，它不画具体技术组件，而是把业务能力、应用服务、技术组件之间的关系表达清楚。

用ArchiMate表达物：业务层有导购服务、客服服务、内容运营、数据分析四个职能，对应到应用层是智能搜索服务、智能问答服务、AIGC内容服务、用户洞察服务，再向下对应到技术组件是模型网关、RAG引擎、Agent编排器、向量数据库等。

它最强的地方是把内部元素关系和依赖边界画清楚，比如“智能问答服务”依赖应用层接口、依赖技术层的RAG引擎，同时为业务层客服职能提供支撑。这个过程能提前发现职责边界问题——比如我发现“数据分析”这个业务职能没有对应的应用服务，才补上了用户洞察模块。ArchiMate不作为开发框架，只做架构设计沟通工具，Project Open或Archi都可以导出文档，团队评审足够用了。

3. 核心AI功能实现与模型部署

架构定完之后就是功能实现。这段是真正的硬核部分，我把四个核心场景逐个拆开，讲清楚每一步怎么落地以及背后的思考。

3.1 智能客服助手：从意图识别到RAG知识库

智能客服是AI商城的门面，用户感知最强的模块。我们接的渠道包括商城右下角悬浮窗、小程序客服入口和售前咨询页面。第一版只是简单调用大模型API问答，效果惨淡，模型经常一本正经地编造售后政策。后来改成了完整的RAG方案。

实现上，用户提问进入会话后，意图识别模块先判断问题类型：售前咨询、售后投诉、物流查询还是闲聊。售前和闲聊走知识库检索问答，售后投诉需要进入Agent人工接管流程。这个判断我们用了一个小型的文本分类模型，训练集是历史客服会话记录人工标注的5000条数据，准确率做到92%。为什么不用大模型做分类？因为成本高、延迟大，分类这种小任务用小模型就够了，大模型资源要留给更复杂的生成任务。

知识库问答部分，用户问题首先进入向量检索，取回top5相关片段。这里要解释一个关键参数：检索相关度阈值设为0.45，低于这个值默认知识库没有相关内容，这时候不会硬让模型回答，而是引导用户转人工，这是防止幻觉的关键兜底策略。检索结果拼装提示词时，我们用了三段式结构：系统设定角色+业务规则、知识库检索结果、用户原始问题。实践下来这个结构最稳定，模型回答准确率从第一版的67%提升到91%。

3.2 个性化推荐：不止是传统推荐算法

电商推荐算法传统套路是协同过滤+用户画像，但这类方法冷启动难，对新用户和长尾商品不友好。AI商城升级的方向是引入语义向量做双路召回。

具体实现是：一方面保留传统I2I（商品到商品）召回，基于用户近期浏览行为算出相似商品；另一方面新增语义向量召回，把用户实时搜索词和浏览记录转成embedding向量，在向量库检索语义相似的商品。两路召回结果合并去重后进入重排。

重排模型我们没有用复杂的Learning to Rank模型，而是用了一个大模型排序方案：把召回的商品候选信息拼成提示词，让大模型根据用户历史偏好输出排序结果，过滤掉不合适的商品后在页面展示。这个方案的好处是可以利用大模型对用户复杂意图的理解能力，不是冷冰冰的规则打分。

实测数据让我们都很惊喜：语义向量召回+大模型重排的方案相比纯协同过滤，商品点击率提升18%以上，转化率提升了近7个百分点。这里有一个关键经验，向量召回这一步必须做品牌、价格、类目的过滤，否则大模型会把同款不同色的商品一次性推给用户，用户会反感。我们后来在向量检索参数里加了标量过滤条件：限定上架3个月内、库存大于0、排除用户已购同类商品，过滤完之后再进重排。

3.3 多模态内容生成：文案图片一次搞定

内容生产是AI商城最直接降本增效的场景。我们跑了两个子应用：商品文案生成和商品场景图生成。

商品文案方面，运营只需要输入商品的基本参数（品牌、品类、材质、卖点），系统自动生成三个版本的详情文案：一个偏理性参数型，一个偏场景故事型，一个偏促销紧迫型。核心靠提示词工程，我用了一套动态模板，大概240行配置，不同类型商品自动加载不同模板。比如数码产品强调参数和性能，美妆强调肤质和成分，服饰强调版型和搭配。这个模块上线后，原先一个运营一天只能写10条商品文案，现在能过审的有50条。

图片生成要走更谨慎的路线。一开始我想直接调用开源文生图模型，生成商品图，效果翻车了——商品logo被改、瓶身标签文字乱码、细节崩坏比较严重。后来换成成熟商业接口生成背景场景图，商品本体直接切割商品原图做合成，这样可以保证主体一致性。这个是最稳的方案排序：先用大模型生成背景风格图，再通过图像合成将商品原图贴合上去，最终再人工抽检5%的图片。这里给一个参数参考：背景生成时采样步数设为30，CFG引导系数设为7.5，这两个值在商品场景图生成中效果最稳。步数太少画质粗糙，太多细节过度锐利，7.5是在真实感和创意度之间的平衡点。

3.4 AI Agent工作流：售后处理的自主决策

这个模块用了AI Agent的概念。我认为它在电商领域最落地的是自助式服务闭环：当客服收到用户投诉，Agent自动判断问题类型，检索订单信息，判断是否符合退换货政策，符合则自动生成工单并通知仓库，不符合则转人工。

整个流程我用了一个状态机加Agent编排：第一步意图识别判定投诉类型，第二步RAG检索售后政策，第三步调用订单系统接口查询订单状态，第四步根据政策+订单数据做决策，第五步执行动作（生成退款单、填物流单或转人工）。

部署层面，模型推理用了两套方案兼顾速度和成本：在线实时场景（客服问答、搜索）部署了量化版的Qwen-14B，INT8量化后显存占用约16G，单卡A10即可支撑，首token延迟控制在800毫秒内。离线批量场景（商品文案、图片生成、数据分析）直接用API调用，吞吐优先。需要说明的是，质量和成本之间必须做明确取舍，不是所有场景都值得上大模型，小模型能解决的就不要引入大模型。

4. 工程化实战与落地经验

功能模块能跑了只是起点，距离生产可用还差一条鸿沟——工程化。这段分享我们在编码、测试、部署和迭代过程中总结的实操经验。很多是新项目才看得见的坑，建议收藏。

4.1 Spring AI集成：代码层面的轻量接入

我们Java后端集成使用了Spring AI，它最大的价值是提供了统一的ChatClient和EmbeddingClient接口。接入模型时不需要在业务代码里写特定厂商的SDK，换模型只改配置不动代码。

一个典型的调用示例：

@RestController @RequestMapping("/ai") public class ChatController { private final ChatClient chatClient; private final VectorStore vectorStore; public ChatController(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient = builder.build(); this.vectorStore = vectorStore; } @PostMapping("/ask") public String ask(@RequestBody QuestionRequest req) { // 1. 根据用户问题在向量库检索知识 List<Document> docs = vectorStore.similaritySearch( SearchRequest.query(req.getQuestion()).withTopK(5) ); // 2. 将知识拼入提示词 String context = docs.stream().map(Document::getText) .collect(Collectors.joining("\n")); String prompt = """ 你是商城的智能客服，只能基于以下知识回答用户问题。 如果知识中没有答案，请明确告知用户转人工处理。 知识：%s 用户问题：%s """.formatted(context, req.getQuestion()); // 3. 调用大模型生成回答 return chatClient.call(prompt); } }

这段代码基本覆盖了RAG问答的完整链路。实际生产中还需要处理流式输出（SSE推给前端）、会话记忆、超时熔断。流式这块很影响用户体验，用chatClient.stream()方法就能实现类似打字机的效果，首字返回快很多。生产环境建议开启超时控制，单次调用超过15秒就熔断降级，避免某个模型节点故障拖垮整个服务。

4.2 提示词工程的三层模板体系

提示词决定了AI输出的质量上限。我们实践中沉淀了一套三层模板体系，推广到全公司项目都适用。

第一层是系统基座，定义AI的角色、任务边界、禁忌事项。比如“你是商城的智能客服，你不是万能的，不确定时必须说不知道”。第二层是业务规则层，根据不同场景注入不同的规则，比如售后场景必须遵循“先安抚情绪再处理问题”的流程，推荐场景必须遵守“预算约束优先”原则。第三层是动态数据层，包括知识库检索结果、实时订单数据、用户历史上下文等运行时信息。

这套分层的好处是改动成本低：业务规则变了只改第二层，知识库更新只动第三层，基座人设原则上不放。全部提示词存到配置中心管理，修改后无需重新发布服务，这一点在业务频繁调整时帮了大忙。

4.3 性能优化：从缓存到流式输出

性能是AI商城上线后最先遭遇的挑战。最初接口响应时长中位数在4.5秒，用户流失严重。我们分三步优化：第一步加Redis缓存，对高频问题（如“发货时间”“退换货政策”）设置短TTL缓存，命中率能达到35%左右，整体响应时间降到3秒内。第二步是流式输出改造，响应速度感知上有质的提升，虽然生成总时长差不多，但用户1秒内就能看到内容开始滚动，实际转化效果好了很多。第三步是并发优化，把AI请求从同步线程池挪到异步事件循环，并且对模型API配置了连接池复用机制。

GPU资源不足的时候可以用 vLLM 部署开源模型，支持高并发推理，吞吐量大约是原生推理框架的3-5倍。当时一个小型GPU节点就能扛住我们并发峰值。

4.4 模型评测与灰度发布

AI功能不能像传统功能那样只验证逻辑，模型输出是概率性的，所以要建立独立的评测体系。我们维护了一个200条测试集的标准评测集，涵盖售前、售后、推荐、拒答（不应该回答的场景）四类。每次换模型、改提示词，先自动跑一遍评测集，人工复核打分，平均分达到90%以上才能进入灰度。

灰度发布策略也很重要，我们会在正式环境切5%流量用新模型，对比旧模型的点击率、满意度、转人工率，跑一周看数据再全量切。换模型不是小事，我曾经直接把一个“聪明”的新模型全量上线，结果它太“聪明”了经常帮用户计算优惠组合，导致客服系统瘫痪，那次的教训印象非常深刻。

5. 常见问题与排查技巧实录

这部分是我最想写的。AI项目很多问题在教科书上查不到，只能一个个踩过来。我把高频问题整理成速查表，再分享三个典型的翻车现场。

5.1 典型问题速查表

5.2 三个典型的“翻车”现场

第一个：智能推荐上线第二天，有用户投诉“我看了婴儿车，你们连续三个页面推荐奶粉，我还没孩子呢”。排查发现是语义召回时embedding相似度把“婴儿车”和“奶粉”归为一类，但没有考虑用户行为的时间衰减。修复方案是在召回阶段加入时间权重，最近两周浏览的商品权重提高，历史浏览权重降低，之后这种问题就没再出现过。

第二个：客服知识库更新后，AI回答错误了。原因是运营更新售后政策后，知识库重建任务失败，向量库里还是旧版本的内容。排查了很久才定位到问题。从那以后我们设计了知识库版本管理，每次更细记录版本号和发布时间，后台一键比对线上实际向量内容和源文档。

第三个：全量上线新模型后整体转化率反而出现了下滑。原因是新模型生成文案“太有创意”，严重偏离品牌调性，用户反馈反而信任度下降。后来新模型灰度前必须加入文案风格评分，和基准模型对比跑A/B测试，确认点击和转化不降级才能上线。

5.3 关于成本、性能与数据合规的三条提醒

成本控制是AI项目无法回避的话题。大模型的调用成本主要由上下文长度、输入输出token数决定。我们在提示词里严格控制上下文长度，知识库切片最多带5段且每段不超过300字，一个请求的输入token控制在2500左右。这样大概测算一下，每次客服问答成本不到一分钱人民币，完全在可接受的范围。另外，所有对话请求在网关层做了敏感信息脱敏，用户手机号、地址在进模型之前都会被替换成占位符，防止隐私数据外泄。这个合规要求不能心存侥幸，等出了事再补就晚了。

关于私有化部署模型，我的建议是100%在线业务流量都走API也行，但高频重复的请求一定要有一层私有化小模型兜底，否则每个月光token费用就能侵蚀掉毛利。我们后来把“商品参数问答”这个小业务迁移到私有化部署的量化模型上，成本直接降低了80%。

写在最后

我自己的感受是：AI商城项目最大的挑战不在模型选型或某个AI算法精度，而在于如何让AI能力像微服务一样可靠地融入业务链路。最后再分享一个实用小技巧：给每个AI功能都加上兜底方案，不管是大模型超时、幻觉、还是向量库检索不到数据，都要有一条不用AI也能完成的备用路径，这样整个系统在机器故障时仍然能撑着。如果你也在搭AI商城，祝你的第一版架构就能避开我踩过的这些坑。