营智：面向电商运营的 AI Agent 工作台

项目类型：电商运营 AI Agent 工作台
核心能力：商品素材管理、AI 文案生成、RAG 知识检索、内容资产沉淀、会员计费、支付宝支付、秒杀活动、后台运营管理
技术栈：Vue 3 / Vite / TypeScript / Element Plus / FastAPI / SQLAlchemy / MySQL / Redis / MinIO / FAISS / BGE-M3 / DeepSeek / Docker Compose

1. 项目概览

“营智”是一个面向电商运营场景的 AI Agent 工作台。它不是一个单纯的“输入商品名，然后让大模型生成一段文案”的工具，而是围绕电商内容生产的完整业务链路构建：从商品素材沉淀，到 AI 生成，再到内容资产管理、会员权益、次数计费、支付转化、秒杀活动和后台运营看板，形成一套可运营、可追踪、可计费、可部署的 AI SaaS 化系统。

在这个项目中，商品不只是一个名称，而是包含品牌、卖点、适用人群、规格参数、价格、标签、图片、分类等结构化信息的“内容生成上下文”；文案也不只是一次性输出，而是会进入内容资产库，支持收藏、评分、备注、多版本修改和回滚；AI 生成也不是裸调模型，而是经过商品检索、历史文案参考、RAG 知识召回、Prompt 模板渲染、流式输出、内容审核和 trace 记录的完整 Agent 流程。

项目整体可以概括为一句话：

营智将大模型能力封装为面向电商运营的内容生产系统，把“生成一段文案”升级为“商品素材、AI Agent、内容资产、会员计费和运营管理”的完整闭环。

2. 项目背景：电商运营为什么需要 AI Agent

电商运营工作高度依赖内容生产。一个商品从上架到推广，往往需要多种不同类型的内容：

  • 商品标题与短卖点；
  • 小红书种草笔记；
  • 商品详情页文案；
  • 促销活动话术；
  • 测评对比内容；
  • 教程技巧类内容；
  • 私域朋友圈文案；
  • 短视频脚本和直播讲解词。

传统内容生产方式主要依赖运营人员人工撰写，存在几个明显问题：

  1. 效率低：每个商品都需要反复提炼卖点、修改语言风格、适配不同平台。
  2. 风格不统一：不同运营人员输出的内容调性差异较大，不利于品牌统一表达。
  3. 商品信息利用不足：大量商品参数、图片、标签和历史文案没有形成知识沉淀。
  4. 内容难以复用：生成过的好文案缺少统一资产管理，后续难以查找、评分、收藏或回滚。
  5. AI 调用不可控：直接调用大模型时，缺少模板、上下文、权限、额度、计费和审核机制。
  6. 商业化能力不足：如果要把 AI 生成功能做成产品，需要会员、次数包、支付订单、秒杀促销等配套能力。

营智的设计目标，就是把这些问题放到同一个产品体系内解决：

  • 用商品素材库沉淀 SKU 信息；
  • 用 RAG 和 Context Builder 给 AI 提供真实上下文；
  • 用 Prompt 模板和场景参数约束生成方向；
  • 用 SSE 流式输出提升交互体验；
  • 用内容资产库管理生成结果；
  • 用会员、次数包和支付系统承载商业化；
  • 用管理后台和 PromptOps 支撑持续运营。

3. 产品定位：从文案生成器到运营工作台

很多 AI 文案工具的核心链路是：用户输入需求，大模型返回结果。营智在这个基础上进一步扩展为“运营工作台”，其关键差异在于：

维度 普通 AI 文案生成器 营智
输入方式 用户手写一段需求 商品资料、场景、风格、模板、模型、自定义要求组合输入
上下文来源 主要依赖用户输入 商品结构化信息、历史优秀文案、RAG 知识片段
生成过程 一次性请求返回 Agent 节点编排 + SSE 流式输出 + 执行轨迹
结果管理 复制后自行保存 内容资产库统一管理，支持收藏、评分、备注、版本回滚
权限计费 通常较简单 会员等级、每日额度、次数包、模型倍率、模板倍率组合计费
商业闭环 多数不包含 会员订阅、次数套餐、充值、支付宝支付、秒杀活动
管理后台 弱或无 用户管理、PromptOps、模板管理、数据看板
部署形态 单服务或云端黑盒 Docker Compose 编排前端、后端、MySQL、Redis、MinIO

因此，营智更适合被理解为一个面向电商运营团队的 AI 内容中台：前台给运营人员提供生成、管理和支付能力，后台给管理员提供用户、模板、数据和策略管理能力，底层则通过 AI Agent、RAG、数据库、缓存和对象存储支撑业务运行。

4. 核心能力总览

营智的能力可以拆成八个核心模块：

模块 作用 关键能力
用户认证 识别用户身份和角色 登录、注册、JWT、刷新 token、退出登录、管理员权限
商品素材库 沉淀商品基础资料 商品 CRUD、分类筛选、标签、卖点、规格、图片上传
AI 生成工作台 面向运营人员的核心生产界面 商品选择、场景选择、风格配置、模板选择、模型选择、SSE 生成
RAG 与上下文构建 提升生成结果与商品的一致性 商品检索、历史文案检索、向量召回、Prompt 组装
内容资产管理 管理生成结果 收藏、评分、备注、版本列表、回滚、多轮修改
会员与次数计费 支撑商业化权限与额度 每日免费额度、次数包、模型倍率、模板倍率、管理员无限
支付与秒杀 完成交易闭环 支付宝沙箱、订单状态、权益开通、Redis Lua 秒杀
管理后台 支撑运营管理 用户管理、模板管理、PromptOps、数据看板、异常 trace

这些模块之间不是彼此孤立的。例如，用户在商品素材库维护商品信息后，这些信息会成为 AI 生成的上下文；生成后的内容会进入内容资产库；当免费额度不足时，会进入会员或次数包支付链路；管理员则可以在后台调整 Prompt 模板、查看数据指标并排查异常。

5. 用户使用流程

一个普通运营用户在营智中的典型使用路径如下：

  1. 用户注册或登录账号。
  2. 进入商品素材库，新增或维护商品信息，包括名称、品牌、卖点、规格参数、标签、价格、适用人群和商品图片。
  3. 进入 AI 文案生成工作台。
  4. 选择要生成文案的商品。
  5. 选择平台场景，例如小红书种草、商品详情页、教程技巧、测评对比或促销活动。
  6. 配置文案风格、字数、自定义要求、模板和模型。
  7. 系统先校验用户权限和剩余额度，再构建商品上下文。
  8. Agent 根据商品信息、历史文案和 RAG 召回内容进行流式生成。
  9. 前端实时展示生成片段、当前步骤和执行状态。
  10. 生成完成后，内容保存到资产库，用户可以收藏、评分、复制、备注或继续修改。
  11. 如果免费额度用尽，系统会按规则消耗次数包余额；如果余额不足，则引导用户购买会员或次数套餐。
  12. 用户可以通过支付页完成支付宝沙箱支付，支付成功后系统自动开通会员或增加次数。
  13. 管理员可以在后台管理用户、Prompt 模板、会员套餐、数据指标和异常 trace。

下面是用户流程的抽象图：

不足

足够

登录/注册

维护商品素材

进入 AI 生成工作台

选择商品/场景/风格/模板/模型

权限与额度校验

构建商品上下文

RAG 检索相关知识

Agent 流式生成内容

内容审核与保存

内容资产管理

收藏/评分/备注/版本回滚

额度是否足够

购买会员/次数包

支付宝支付

开通权益

6. 前端架构与页面模块

营智前端采用 Vue 3 + Vite + TypeScript 构建，配合 Element Plus 提供基础 UI 组件，Pinia 管理状态，vue-router 管理页面路由。视觉上，项目不是简单套用后台模板，而是使用深色科技风、玫红品牌色、玻璃拟态、Bento 卡片、WebGL 背景和交互动效，强化 AI 工作台的产品气质。

6.1 前端技术栈

技术 作用
Vue 3 前端视图框架
Vite 构建工具与开发服务
TypeScript 类型约束与工程可维护性
Pinia 登录态、会员状态、生成状态等全局状态管理
vue-router 页面路由与登录/管理员权限守卫
Element Plus 表单、弹窗、表格、按钮等基础组件
Three.js WebGL 背景与 3D 动效
SSE 工具 解析后端流式生成结果
Nginx 生产环境静态资源托管与反向代理

前端页面覆盖了产品官网式首页、登录注册、AI 生成工作台、商品素材库、内容资产库、会员中心、支付页、秒杀活动页、消费记录页和管理后台。

6.2 首页：产品官网式表达

营智首页不是传统后台系统的简单入口，而是更像一个面向用户展示产品价值的官网式页面。首页通过全屏分屏、动效背景、模块卡片和 CTA 引导用户理解产品能力。

首页主要表达五类信息：

  1. Hero 首屏：突出“AI 驱动电商内容生产”的核心卖点。
  2. 核心业务模块：商品素材库、AI 内容生成、内容资产管理、PromptOps、会员套餐。
  3. 产品优势：RAG 增强商品认知、内容合规、Agent 决策、PromptOps 可视化。
  4. 平台场景：覆盖小红书、商品详情页、促销活动、测评对比等运营场景。
  5. 行动引导：引导用户开始试用或进入工作台。

通过 WebGL 极光、丝绸质感背景、滚动动画和科技感卡片，首页在视觉上建立了“AI + 电商运营”的产品印象。

6.3 AI 文案生成工作台

AI 生成页是营智最核心的前端页面。它采用工作台式三栏布局：

  • 左侧：智能体配置区；
  • 中间：生成内容展示区；
  • 右侧：历史记录与智能分析区。

左侧配置区包含：

  • 商品选择；
  • 场景选择；
  • 文案风格；
  • 字数配置；
  • 自定义要求；
  • 模型选择；
  • 模板选择；
  • 预计消耗次数展示。

中间生成区包含：

  • SSE 流式内容展示；
  • 生成状态提示；
  • AI 执行步骤展示；
  • 复制、收藏、分享等操作；
  • 生成过程中的动态背景反馈。

右侧区域包含：

  • 历史生成记录；
  • 内容版本切换；
  • 删除或批量清理；
  • Agent trace 信息；
  • 情感指数、转化潜能等运营分析展示。

这使得生成页不只是一个文本框，而是围绕商品、场景、模板、模型、配额和历史资产组织起来的完整运营工作区。

6.4 商品素材库

商品素材库是 AI 生成的知识输入层。用户可以在这里维护商品资料，包括：

  • 商品名称；
  • 品牌；
  • 主图；
  • 核心卖点；
  • 规格参数；
  • 标签；
  • 一级/二级分类；
  • 价格；
  • 适用人群；
  • 详情描述；
  • 上架/下架状态。

商品列表支持搜索、分类筛选、状态筛选、卡片/表格视图切换和分页。商品表单支持图片拖拽上传、预览和替换。上传后的图片通过后端进入 MinIO，再由前端通过统一代理路径访问。

这部分设计体现了一个重要思路：

AI 生成质量很大程度取决于上下文质量。商品素材库就是营智为大模型准备的结构化商品上下文。

6.5 内容资产管理

内容资产管理模块负责承接 AI 生成结果。用户可以对生成内容进行：

  • 查看详情；
  • 复制文案；
  • 收藏/取消收藏；
  • 评分；
  • 编辑备注；
  • 删除内容；
  • 查看版本列表；
  • 回滚到历史版本。

内容详情中不仅包含最终文案，还可以包含上下文快照、Agent trace、模型信息、token 使用情况和版本记录。这让内容不只是一次性输出，而是可以被复用、复盘和持续优化的运营资产。

6.6 会员、支付、秒杀与消费记录页面

营智前端还完整覆盖商业化流程：

  • 会员中心：展示当前会员、每日免费额度、修改次数、次数余额、会员套餐和次数包。
  • 支付页：根据订单号展示订单信息，创建支付宝支付链接，轮询订单状态并同步权益。
  • 秒杀页：展示秒杀活动、倒计时、库存进度、折扣信息和抢购按钮。
  • 消费记录页：按订单类型展示会员订阅、次数包、秒杀、充值等记录。

这些页面让系统从“AI 工具”进一步具备 SaaS 产品的商业化闭环。

6.7 管理后台与可视化

管理后台主要面向管理员，包含：

  • 用户管理：用户列表、角色筛选、状态筛选、启用/禁用用户；
  • Prompt 模板管理：新增、编辑、复制、停用模板；
  • Prompt AI 润色：对 System Prompt 做流式优化；
  • 数据看板：用户数、生成次数、今日生成、热门场景、Token 趋势、异常日志；
  • Trace 查看：帮助排查 Agent 执行异常。

这使管理员能够从运营视角维护 AI 策略，而不是每次都进入代码修改 Prompt。

6.8 视觉动效设计

营智前端使用多个动效组件营造 AI 科技感：

动效组件 使用场景 作用
PixelBlast 多个业务页面背景 像素噪声、点击涟漪，增强科技氛围
SilkBackground 首页分屏背景 WebGL 丝绸流动效果，提升产品质感
Ballpit3d AI 生成工作区 3D 小球物理动效，强化“AI 正在运转”的反馈
ElectricBorder 秒杀卡片 电光边框、倒计时和库存进度共同制造活动紧迫感

这些动效不是孤立装饰，而是围绕产品定位服务：让用户在使用时能感受到“AI 工作台”的实时性、科技感和专业感。

7. 后端架构设计

营智后端基于 FastAPI 构建，使用 SQLAlchemy 管理 MySQL 数据，Redis 负责缓存、配额和秒杀库存，MinIO 负责对象存储，FAISS 与 BGE-M3 负责向量检索，DeepSeek API 负责大模型生成。

7.1 系统总体架构

/api

/minio

用户浏览器

Vue 3 前端

Nginx

FastAPI 后端

MinIO 对象存储

MySQL 8

Redis 7

FAISS 向量索引

BGE-M3 Embedding

DeepSeek / Qwen LLM

支付宝沙箱

管理员

这套架构把系统拆成五类核心层次：

  1. 前端展示层：Vue 3 页面、工作台交互、SSE 流式展示；
  2. 网关代理层：Nginx 处理 SPA、API、SSE、MinIO 图片代理；
  3. 业务服务层：FastAPI 提供认证、商品、生成、支付、会员、秒杀等 API；
  4. 数据基础设施层：MySQL、Redis、MinIO、FAISS；
  5. AI 能力层：BGE-M3 embedding、DeepSeek/Qwen 大模型、Agent 编排。

7.2 API 模块划分

后端 API 按业务领域拆分，主要模块如下：

API 模块 职责
/api/auth 注册、登录、刷新 token、退出登录、短信登录
/api/products 商品 CRUD、上下架、商品资料管理
/api/templates Prompt 模板管理、模板 AI 润色
/api/agent AI 文案生成、多轮修改、Agent trace 查询
/api/contents 内容资产、版本、收藏、评分、备注、回滚
/api/admin 用户管理、数据看板、后台管理能力
/api/membership 会员套餐、当前会员、订阅与取消
/api/credit 次数套餐、余额、购买记录
/api/payment 支付创建、支付回调、查单同步、取消订单
/api/seckill 秒杀活动、抢购、库存查询、秒杀记录
/api/orders 用户订单列表和消费记录
/api/upload 商品图片上传

这种拆分方式让后端既能保持功能模块清晰，又能方便前端按业务页面调用。

7.3 数据模型设计

营智的业务数据主要围绕以下实体展开：

数据实体 作用
User 用户、角色、登录身份
Product 商品资料、卖点、图片、分类、价格
PromptTemplate 场景模板、风格、模板等级、Prompt 配置
ContentHistory 生成内容主记录、最终文案、上下文快照、trace
ContentVersion 内容版本记录，支持修改和回滚
TokenUsageLog 模型调用 token 日志，用于统计和看板
RagDocMapping FAISS 向量与原始商品知识片段映射
MembershipPlan 会员等级、每日额度、可用模型和模板等级
UserMembership 用户当前会员状态
CreditPackage 次数套餐定义
UserCredit 用户次数余额
Order 统一订单，支持会员、次数包、充值、秒杀
UserBalance 用户余额
RechargeRecord 充值记录
SeckillActivity 秒杀活动配置
SeckillRecord 用户秒杀参与记录

其中，content_history 与 content_version 让内容生成具备版本化能力；membership_plan 与 user_credit 让生成行为可以被计费；rag_doc_mapping 则负责把向量检索结果映射回具体业务片段。

8. AI Agent 生成链路

AI 生成是营智的核心能力。系统没有直接把用户输入转发给大模型，而是先进行权限校验、上下文构建、模板渲染，再通过 Agent 工作流生成内容，并将结果流式返回给前端。

8.1 生成请求入口

主要生成接口包括：

  • POST /api/agent/generate：生成新文案；
  • POST /api/agent/modify：基于已有内容进行多轮修改；
  • GET /api/agent/trace/{content_history_id}：查询 Agent 执行轨迹。

一次生成请求大致包含：

  • 商品 ID；
  • 生成场景；
  • 文案风格；
  • 字数要求；
  • 自定义要求；
  • 模板版本；
  • 模型选择；
  • 用户登录态。

后端收到请求后，会先识别用户身份，然后根据会员等级判断该用户是否有权限使用指定模型和模板等级，同时计算本次生成预计消耗的次数。

8.2 LangGraph 节点编排

后端 Agent 生成流程可以抽象为三个核心节点：

context_build → llm_generate → content_review
context_build：构建上下文

该阶段负责把商品信息、历史文案和 RAG 召回结果组织成一个统一上下文。上下文越准确，后续生成结果越贴近商品真实卖点。

llm_generate：调用大模型生成

该阶段根据场景和模板生成 Prompt，并调用 DeepSeek 或其他兼容模型进行流式生成。前端可以实时看到文案逐步输出，而不是等待完整响应结束。

content_review：内容审核与结果整理

该阶段用于对生成结果做基础审核和整理，例如识别敏感词、极限词或不适合营销使用的表达，并把最终内容保存到数据库。

8.3 SSE 流式返回

营智使用 SSE 实现流式输出。后端在生成过程中持续推送事件，前端实时解析并更新界面。

常见事件包括：

事件 说明
start 生成任务开始
step_done 某个 Agent 节点执行完成
chunk 大模型生成的文本片段
done 生成完成
error 生成失败或异常

这种方式相比普通 HTTP 一次性返回，有两个好处：

  1. 用户可以更快看到模型输出，降低等待焦虑；
  2. 系统可以展示每一步执行状态，让 AI 过程更透明。

8.4 生成链路时序图

MySQL DeepSeek LLM FAISS/RAG Context Builder 配额系统 FastAPI Agent API 前端工作台 MySQL DeepSeek LLM FAISS/RAG Context Builder 配额系统 FastAPI Agent API 前端工作台 POST /api/agent/generate 校验会员权限与可用额度 返回可用额度与消耗规则 构建商品/场景/模板上下文 检索相关商品知识片段 返回召回结果 返回完整 Prompt 上下文 发起流式生成请求 SSE chunk 文本片段 保存内容、版本、trace、token 日志 记录免费额度或扣减次数包 SSE done 生成完成

8.5 Agent Trace 与可解释性

营智在生成过程中记录 Agent 执行轨迹，包括：

  • 每个节点的执行状态；
  • 每个节点的耗时；
  • 上下文构建结果；
  • 模型调用情况；
  • 内容审核结果；
  • 错误信息。

这些 trace 信息可以在生成页和管理后台中查看，帮助用户理解“AI 为什么这样生成”，也方便管理员排查生成失败、模型异常或上下文缺失等问题。

9. RAG 与商品上下文构建

直接让大模型根据用户一句话生成电商文案，容易出现商品信息不准确、卖点不贴合、表达泛泛而谈等问题。营智通过 RAG 和 Context Builder 解决这个问题。

9.1 Context Builder：统一上下文入口

Context Builder 负责把多个信息源组合成生成上下文，主要包括：

  1. 商品结构化信息：名称、品牌、卖点、规格、标签、价格、适用人群等；
  2. 历史优质文案：按商品分类、场景和用户历史检索可参考内容；
  3. RAG 召回片段：从向量库中检索与当前商品和场景相关的知识片段；
  4. Prompt 模板：不同场景对应不同角色设定、输出格式和语言风格。

可以抽象为：

product_search + copywriting_search + rag_retrieve + prompt_template
= generation_context

9.2 商品资料向量化

商品新增或编辑后，系统可以把商品资料转化为文本片段，例如：

  • 商品名称与品牌；
  • 核心卖点；
  • 适用人群；
  • 详情描述；
  • 分类与标签。

然后使用 BGE-M3 生成向量，并写入 FAISS 索引。为了能从向量结果回到业务数据，系统还维护 rag_doc_mapping，记录向量 ID 与商品片段之间的关系。

9.3 BGE-M3 + FAISS 的作用

组件 作用
BGE-M3 将商品知识和查询文本转为向量
FAISS 存储和检索向量，返回相似片段
rag_doc_mapping 保存向量与原始商品片段之间的映射
Context Builder 把召回片段放入 Prompt 上下文

这种设计让营智具备“商品知识增强生成”的能力。大模型生成文案时，不再只依赖模型内部知识，而是结合当前系统中的真实商品资料和运营历史。

9.4 RAG 的工程化考虑

BGE-M3 模型体积较大，CPU 推理成本也较高，因此项目在部署时需要考虑：

  • 模型目录挂载到宿主机，避免每次构建镜像重复下载；
  • FAISS 索引持久化，避免容器重建后丢失知识库；
  • 对空索引、模型未加载或 embedding 超时做保护；
  • 在 RAG 不可用时，核心文案生成链路仍可降级运行。

这体现了工程系统中很重要的一点：AI 能力需要增强主流程，但不能让主流程被单个模型或索引完全阻塞。

10. 内容资产与版本管理

电商文案通常不是一次生成就最终定稿。运营人员可能会要求“更口语化一点”“增加促销感”“更适合小红书”“缩短到 200 字以内”等修改。营智通过内容资产和版本管理支持这种迭代过程。

10.1 内容资产沉淀

每次生成完成后，系统会保存：

  • 最终文案；
  • 商品上下文快照；
  • 生成场景；
  • 使用模板；
  • 使用模型；
  • token 消耗；
  • Agent trace；
  • 创建时间；
  • 用户评分、收藏和备注。

这些数据让内容从“临时输出”变成可以被后续复用的资产。

10.2 多版本修改

当用户对已有内容发起修改时，系统不会简单覆盖原文，而是保存新的版本记录。这样可以支持：

  • 查看历史版本；
  • 比较修改前后的内容；
  • 回滚到某个版本；
  • 追踪每次修改的意图；
  • 统计修改次数并用于计费。

10.3 运营价值

内容资产管理的价值不只是“保存文案”，更重要的是形成运营经验沉淀：

  • 高评分内容可以作为后续参考；
  • 收藏内容可以进入精选素材；
  • 备注可以记录投放效果或运营判断；
  • 历史文案可以被检索并参与新的上下文构建。

这让营智从生成工具升级为内容生产和复盘平台。

11. 会员权益与次数计费

营智的计费体系不是简单地“调用一次扣一次”，而是将会员权益、每日免费额度、次数套餐、模型等级和模板等级组合在一起。

11.1 会员权益

系统中可以配置不同会员等级，例如免费版、专业版和旗舰版。不同等级可以拥有不同权益：

  • 每日免费生成次数；
  • 免费修改次数；
  • 可使用的模型；
  • 可使用的模板等级；
  • 更高的生成额度或更多高级功能。

其中，每日免费额度来自会员方案配置，而不是写死在用户表中。这种设计更灵活，后续可以通过后台或数据库调整不同会员套餐的权益。

11.2 扣费顺序

一次生成请求通常按以下顺序扣减：

管理员无限额度 → 会员每日免费额度 → 次数套餐余额

也就是说：

  1. 如果是管理员账号，生成和修改不扣额度，方便内部测试和运营管理。
  2. 如果是普通用户，先消耗会员每日免费额度。
  3. 如果当日免费额度已用完，再扣除次数套餐余额。
  4. 如果次数余额也不足，则提示用户购买会员或次数包。

11.3 模型与模板等级倍率

系统还可以根据模型和模板等级设置不同倍率。例如：

  • 普通模型消耗较低；
  • 高级模型消耗较高；
  • 普通模板消耗较低；
  • 精选模板或独家模板消耗较高。

抽象公式可以表示为：

本次消耗次数 = 基础消耗 × 模型倍率 × 模板倍率

这使营智能够支持更细粒度的商业策略：普通用户可以使用基础能力，高级会员可以使用更强模型、更高质量模板和更多每日额度。

12. 支付订单与支付宝沙箱

营智已经具备相对完整的交易闭环。系统中的订单类型包括：

订单类型 说明
membership 会员订阅订单
credit_package 次数套餐购买订单
recharge 余额充值订单
seckill 秒杀活动订单

12.1 支付流程

一次典型支付流程如下：

  1. 用户选择会员套餐、次数包或秒杀活动。
  2. 后端创建订单，状态为待支付。
  3. 前端进入支付页，展示订单号、商品名称和金额。
  4. 用户点击支付，系统创建支付宝沙箱支付链接。
  5. 用户完成支付后，支付宝向后端发起异步通知。
  6. 后端验签、校验金额、校验订单状态。
  7. 订单状态更新为已支付。
  8. 后端根据订单类型开通权益：会员、次数包、余额或秒杀权益。
  9. 前端轮询或主动同步订单状态，支付成功后刷新用户权益。

12.2 幂等与可靠性

支付系统必须处理重复通知、网络延迟、用户关闭页面、同步跳转失败等情况。因此后端需要做：

  • 支付宝回调验签；
  • 订单号校验；
  • 金额校验；
  • 交易状态校验；
  • 已支付订单幂等处理；
  • 主动查单同步；
  • 支付成功后权益开通；
  • 支付失败、取消、过期等状态处理。

这类设计保证即使用户没有成功跳回前端页面，只要支付宝异步通知正常到达，系统仍然能正确更新订单状态并开通权益。

13. Redis 秒杀系统设计

秒杀活动是营智商业化能力中的一个亮点。秒杀场景的核心问题是：高并发下不能超卖，不能重复购买，还要处理用户抢到后不支付导致库存占用的问题。

13.1 秒杀流程

营智秒杀流程可以概括为：

  1. 后端启动时将秒杀活动库存预热到 Redis。
  2. 用户发起抢购请求。
  3. 后端检查活动状态和时间窗口。
  4. Redis Lua 脚本原子执行库存判断、扣减和用户记录。
  5. 扣减成功后创建预订单。
  6. 用户进入支付页支付秒杀订单。
  7. 支付成功后开通对应权益。
  8. 如果订单超时未支付，后台任务回滚库存。

13.2 Redis Lua 原子操作

秒杀扣库存不能简单拆成“查询库存 → 判断库存 → 扣减库存”三个独立操作，否则高并发下容易出现超卖。营智使用 Redis Lua 脚本将这些动作合并成原子操作：

  • 判断用户是否已购买；
  • 判断库存是否大于 0；
  • 扣减库存；
  • 记录用户已参与。

这保证了同一时刻只有一个脚本在 Redis 内部执行，不会出现多个请求同时读到相同库存并重复扣减的问题。

13.3 超时订单回滚

用户抢到秒杀资格后，不一定会立即支付。如果一直占用库存，会影响其他用户。因此系统通过后台任务定期扫描超时订单：

  • 如果订单在指定时间内未支付；
  • 将订单标记为过期；
  • 回滚 Redis 库存；
  • 清理或修正用户秒杀记录。

这让秒杀流程更接近真实业务场景，而不是简单的库存扣减演示。

14. 管理后台与 PromptOps

营智的管理后台不仅是普通 CRUD 后台，还承担 PromptOps 和运营监控职责。

14.1 用户管理

管理员可以查看用户列表，并根据用户名、昵称、角色、状态进行筛选。对于异常用户，管理员可以执行启用或禁用操作。后台也可以展示用户今日额度使用情况和会员状态，方便运营人员理解用户消耗情况。

14.2 Prompt 模板管理

Prompt 模板管理是营智的关键能力之一。管理员可以配置：

  • 模板名称；
  • 场景标识；
  • 模板等级；
  • 支持的文案风格；
  • System Prompt；
  • 输入表单定义；
  • 输出规则；
  • Temperature；
  • 适用模型。

这种设计把 Prompt 从代码中抽离出来，让运营或管理员可以在后台调整生成策略，而不需要每次修改后端代码。

14.3 Prompt AI 润色

后台还支持对 System Prompt 进行 AI 润色。管理员可以选择优化方向，例如：

  • 内容风格；
  • 语气；
  • 结构；
  • 角色感；
  • 输出规范。

润色过程同样可以通过 SSE 流式返回，并校验变量占位符是否保留，避免模板变量被误删。

14.4 数据看板

数据看板可以展示：

  • 总用户数；
  • 累计生成次数；
  • 今日生成次数；
  • 热门场景分布；
  • Token 消耗趋势；
  • 本月 Token 总消耗；
  • 最近 Agent 异常日志。

这些指标可以帮助团队了解系统使用情况、热门生成场景和模型成本变化。

15. Docker Compose 部署架构

营智支持通过 Docker Compose 一键编排核心服务。整体包含五个主要容器：

容器 职责 说明
MySQL 8 结构化数据存储 用户、商品、订单、内容、会员、秒杀等表
Redis 7 缓存与高并发辅助 每日额度、token 黑名单、秒杀库存、订单辅助状态
MinIO 对象存储 商品图片、上传资源等
Backend 后端业务服务 FastAPI、AI Agent、RAG、支付、秒杀、管理 API
Frontend 前端与反向代理 Vue 静态资源、Nginx、API/SSE/MinIO 代理

15.1 后端容器

后端镜像基于 Python 3.11 slim 构建，安装 FastAPI、SQLAlchemy、Redis、MinIO、FAISS、Embedding 和大模型调用相关依赖。

启动时后端会执行一些初始化动作：

  • 加载配置；
  • 连接数据库；
  • 自动创建 ORM 表结构；
  • 初始化 MinIO bucket；
  • 预热秒杀库存；
  • 启动订单超时回滚任务；
  • 提供健康检查接口。

BGE-M3 模型目录建议通过宿主机挂载到容器中，避免镜像过大，也避免每次重建容器都重新下载模型。

15.2 前端容器与 Nginx

前端采用多阶段构建：

  1. Node 阶段安装依赖并执行构建；
  2. Nginx 阶段托管构建后的静态资源。

Nginx 在系统中承担多个职责：

  • 支持 Vue SPA 路由；
  • 将 /api/ 代理到后端；
  • 为 SSE 生成接口关闭代理缓冲；
  • 将 /minio/ 代理到 MinIO；
  • 支持图片上传大小限制。

SSE 相关接口需要特别注意关闭缓冲，否则浏览器可能无法实时看到模型输出，而是等后端完整生成后才一次性显示。

16. 环境配置说明

下面是脱敏后的环境配置说明。真实部署时应根据服务器、域名、数据库和密钥进行配置，严禁将真实密码、API Key、私钥提交到仓库或公开博客。

16.1 项目目录

本地开发目录示例：

D:\JDFS\项目管理\阶段二项目\test1

服务器部署目录示例：

/opt/yingzhi

代码托管可使用 Gitee 或其他 Git 平台，主分支可统一为 master 或团队约定分支。

16.2 后端环境

后端核心技术：

  • FastAPI；
  • SQLAlchemy；
  • MySQL 8；
  • Redis 7；
  • MinIO；
  • FAISS；
  • BGE-M3；
  • DeepSeek API；
  • 支付宝沙箱；
  • Docker。

脱敏 .env 示例：

APP_NAME=yingzhi-backend
APP_ENV=production
APP_DEBUG=false
SECRET_KEY=<your-jwt-secret>

FRONTEND_PUBLIC_URL=https://<your-domain>
API_PUBLIC_URL=https://<your-domain>

MYSQL_HOST=mysql
MYSQL_PORT=3306
MYSQL_USER=<your-db-user>
MYSQL_PASSWORD=<your-db-password>
MYSQL_DATABASE=yingzhi

REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=<your-redis-password>
REDIS_DB=0

MINIO_ENDPOINT=minio:9000
MINIO_PUBLIC_BASE_URL=https://<your-domain>/minio
MINIO_ACCESS_KEY=<your-minio-access-key>
MINIO_SECRET_KEY=<your-minio-secret-key>
MINIO_BUCKET=products
MINIO_SECURE=false

DEEPSEEK_API_KEY=<your-deepseek-api-key>
DEEPSEEK_BASE_URL=https://api.deepseek.com
DEEPSEEK_MODEL=deepseek-chat

EMBEDDING_MODEL=bge-m3
EMBEDDING_MODEL_PATH=/app/model/bge-m3
FAISS_INDEX_PATH=/app/storage/faiss/product.index

ALIPAY_APP_ID=<your-alipay-app-id>
ALIPAY_PRIVATE_KEY=<your-alipay-private-key>
ALIPAY_PUBLIC_KEY=<your-alipay-public-key>
ALIPAY_RETURN_URL=https://<your-domain>/api/payment/return
ALIPAY_NOTIFY_URL=https://<your-domain>/api/payment/notify

16.3 前端环境

前端核心技术：

  • Vue 3；
  • Vite；
  • TypeScript；
  • Element Plus；
  • Pinia；
  • vue-router；
  • Three.js；
  • Nginx。

生产环境中前端通常不写死后端地址，而是通过 Nginx 把 /api 代理到后端服务。这样前端请求可以保持同源，减少跨域和部署复杂度。

16.4 常用部署命令

部署时可在服务器项目目录中执行：

git pull
docker compose up -d --build

只重建前端：

docker compose up -d --build frontend

只重启后端：

docker compose restart backend

查看后端日志：

docker logs yingzhi-backend --tail 50
docker logs -f yingzhi-backend

16.5 模型与向量索引

BGE-M3 模型和 FAISS 索引建议以运行时目录方式挂载：

runtime/model/bge-m3
runtime/storage/faiss/product.index

这样做有三个好处：

  1. 避免模型进入镜像导致构建过慢、镜像过大；
  2. 容器重建后模型仍然保留；
  3. FAISS 索引可以持久化，避免商品知识库丢失。

16.6 MinIO 图片访问

商品图片上传到 MinIO 后，前端通过统一代理路径访问，例如：

https://<your-domain>/minio/products/<file-name>

这种方式避免浏览器直接访问内部 MinIO 容器地址，也方便后续接入 HTTPS、鉴权或 CDN。

17. 安全与敏感信息脱敏

由于营智涉及数据库、Redis、MinIO、大模型 API、支付宝支付和服务器部署，安全配置非常重要。

17.1 不应公开的信息

以下内容不应写入公开文档、博客或代码仓库：

  • 数据库真实密码；
  • Redis 密码；
  • MinIO access key 和 secret key；
  • DeepSeek API Key；
  • JWT Secret；
  • 支付宝私钥和完整公钥；
  • 服务器 SSH 凭据；
  • Gitee 或其他 Git 平台 token；
  • 管理员账号密码；
  • 测试账号密码组合；
  • 可直接访问真实后台的地址加凭据组合。

17.2 脱敏写法

信息类型 博客或文档中推荐写法
公网地址 https://<your-domain> 或 http://<server-ip>
数据库密码 <your-db-password>
Redis 密码 <your-redis-password>
MinIO 密钥 <your-minio-access-key> / <your-minio-secret-key>
DeepSeek Key <your-deepseek-api-key>
支付宝私钥 <your-alipay-private-key>
JWT Secret <your-jwt-secret>
管理员账号 只说明存在管理员角色，不公开密码

17.3 生产安全建议

  • 生产环境强制修改所有默认密码；
  • API Key 和私钥通过 .env 或密钥管理服务注入；
  • .env 不提交到 Git；
  • MySQL、Redis、MinIO 管理端口不要直接暴露公网；
  • 公网服务建议绑定域名并启用 HTTPS；
  • 支付宝回调必须验签；
  • 管理后台必须做角色权限校验；
  • 日志中避免输出完整 token、密码和私钥。

18. 测试、排查与上线检查

上线前需要从功能、数据、部署和安全四个角度检查。

18.1 功能检查清单

  • 用户可以注册和登录；
  • 登录态刷新正常；
  • 普通用户无法进入管理后台；
  • 商品可以新增、编辑、删除、上下架；
  • 商品图片可以上传并在前端正常显示；
  • AI 生成接口可以流式返回内容；
  • 生成结果可以保存到内容资产；
  • 内容可以收藏、评分、备注；
  • 多轮修改可以生成新版本；
  • 版本回滚正常；
  • 会员状态和每日额度显示正确；
  • 次数包余额扣减正确；
  • 支付订单创建正常；
  • 支付成功后权益能开通；
  • 秒杀库存扣减、防重复购买和超时回滚正常；
  • 管理后台数据看板能正常加载。

18.2 部署检查清单

  • docker compose ps 中五个核心容器均为运行状态；
  • 后端健康检查接口正常；
  • 前端首页可访问；
  • Nginx /api 代理正常；
  • SSE 接口没有被代理缓冲阻塞；
  • MinIO bucket 已创建；
  • 图片代理路径可访问；
  • MySQL 初始化表结构完整；
  • Redis 连接正常；
  • BGE-M3 模型目录存在；
  • FAISS 索引目录可写；
  • 支付宝回调地址与公网地址一致。

18.3 常见问题排查

问题 可能原因 排查方向
前端无法请求后端 Nginx 代理或后端容器异常 查看 frontend/backend 日志，检查 /api 代理
SSE 不流式输出 Nginx 缓冲未关闭 检查生成接口的 proxy buffering 配置
图片上传后打不开 MinIO 公网地址或代理路径错误 检查 MINIO_PUBLIC_BASE_URL 和 /minio 代理
生成速度慢 模型响应慢或 RAG embedding 慢 查看 Agent trace、模型日志和超时配置
支付成功但权益未开通 回调未到达或订单类型处理异常 查看支付日志、订单状态、权益服务
秒杀库存异常 Redis 库存未预热或超时回滚异常 查看 Redis key、秒杀记录和后台任务日志
管理后台无数据 初始化数据缺失或权限不足 检查数据库、管理员角色和 API 响应

19. 项目亮点总结

营智的项目亮点可以概括为以下几个方面：

19.1 从 AI 调用到 Agent 工作流

营智不是简单调用一次大模型，而是将生成过程拆成上下文构建、模型生成、内容审核等节点，并通过 SSE 和 trace 暴露执行过程。这样既提升用户体验，也增强了可观测性。

19.2 从商品素材到 RAG 增强生成

商品素材库不是孤立模块，而是整个 AI 生成链路的知识输入。商品资料经过结构化整理和向量化后，可以在生成时被召回，从而提升文案与商品真实卖点的一致性。

19.3 从生成结果到内容资产

生成后的文案会进入内容资产库，支持收藏、评分、备注、多版本和回滚。这让系统具备内容沉淀能力，而不是一次性工具。

19.4 从免费额度到商业化闭环

会员、次数包、模型倍率、模板倍率、支付宝支付、秒杀活动共同构成商业化基础。系统可以支持免费试用、会员订阅、高级模板收费、限时促销等运营玩法。

19.5 从前端体验到后台运营

前端通过三栏工作台、流式生成、WebGL 动效和可视化看板提升使用体验；后台通过用户管理、PromptOps 和数据看板提升运营管理能力。

19.6 从本地开发到 Docker 部署

项目使用 Docker Compose 编排 MySQL、Redis、MinIO、后端和前端，配合 Nginx、模型挂载、FAISS 持久化和初始化脚本，使系统具备较完整的部署闭环。

20. 后续优化方向

营智已经具备完整的 AI 内容生产和商业化基础，后续还可以继续从以下方向演进。

20.1 AI 生成质量优化

  • 引入更细粒度的 Prompt 评估体系；
  • 根据用户评分反向优化模板；
  • 增加 A/B 测试能力；
  • 支持多模型对比生成；
  • 对不同平台输出结构进行更严格约束。

20.2 RAG 能力增强

  • 增加商品知识自动分块策略；
  • 对召回结果做重排序；
  • 将高评分历史文案纳入优先召回；
  • 支持按店铺、品牌、行业维度构建知识库；
  • 增加向量索引重建和监控工具。

20.3 内容运营闭环增强

  • 增加内容标签体系；
  • 记录内容投放效果；
  • 根据转化效果推荐模板；
  • 支持团队协作、审批和发布流程；
  • 接入小红书、抖音、淘宝等平台发布接口。

20.4 商业化能力增强

  • 增加优惠券、兑换码和企业套餐；
  • 支持更多支付方式；
  • 支持发票与企业账单；
  • 增加订单退款和售后流程；
  • 对秒杀活动增加限购策略和风控规则。

20.5 工程与运维增强

  • 引入数据库迁移工具管理 schema；
  • 增加 Prometheus/Grafana 监控；
  • 增加结构化日志与链路追踪；
  • 增加 CI/CD 自动部署；
  • 将敏感配置接入密钥管理服务；
  • 为 AI 生成链路增加更完整的自动化测试。
# python # typescript # vue.js
Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

Python 开发者进阶指南，这套大模型课值不值得深钻

本文深度解析 Python 开发者进阶大模型架构的实战路径。课程涵盖 LangGraph 智能体编排、MCP 协议标准互联，以及 Qwen3 与 DeepSeek 模型的微调私有化部署。通过多模态融合与 RAG 架构演进，助力开发者从脚本编写者蜕变为具备企业级落地能力的大模型应用专家。

avatar MCP技术社区
cover

【无标题】

avatar MCP技术社区

Kiro 配置 Git MCP Server 通用教程

Git MCP Server 配置指南 本教程介绍如何为Kiro配置Git MCP Server，实现在对话中直接执行Git操作的功能。 核心内容： 安装：使用uv工具安装mcp-server-git 配置：在.kiro/settings/mcp.json中添加git server配置 使用：支持12种Git操作工具，包括查看状态、提交历史、分支对比等 关键配置项： 必须指定仓库绝对路径 可设置自

avatar MCP技术社区