前两课，我们准备了AI协作工具和云资源，让AI通过MCP部署了一个展示网站。这一课，继续往前走：用OpenCart和MySQL，准备一家能浏览商品、选择尺码、提交测试订单的电商店。

案例是一家原创简约通勤女装店——DAYFORM｜日序。我们自己设计产品，顾客下单后，再确认尺码和交期，交给工厂生产。目标商品价位为十到三十美元，品牌、款式和政策先作为可修改的草案。

这次不急着把所有东西直接装到服务器。先创建AI项目，在本地把资料和商店准备好，预览、检查，再迁移上云。以后通过云端后台管理商品、支付、物流和订单。

用户打开的网页只是入口。商城背后还有负责处理操作的应用、负责保存信息的数据库，以及商品图片、支付和配送等环节。

Web服务器接收网页请求，PHP运行环境执行OpenCart程序，OpenCart负责商城业务，MySQL保存商品、客户、订单和部分配置。图片、主题、扩展等文件也需要单独保存，不能以为所有东西都在数据库里。

— 本地与云端Docker商城架构，原理示意

本课的具体示例使用Caddy作为Web服务器，PHP-FPM运行OpenCart，MySQL保存业务数据，三个服务分别运行在独立容器中。

云端还需要域名和HTTPS入口。反向代理接收用户访问，再交给商城应用；商城通过内部网络连接数据库。PayPal和物流平台则是外部服务，通过扩展或接口接入。

按单生产的业务链路也要分清：提交订单、付款确认、尺码与交期确认、工厂接单、生产、质检、发货，是不同的状态。网页提示下单成功，不代表已经收款，更不代表工厂已经开工。

用AI部署应用时，我喜欢使用Docker，因为各个服务之间的边界更清楚。

商城运行在应用容器里，MySQL运行在数据库容器里，反向代理负责访问入口。AI需要修改哪个服务、查看哪份日志、重启哪个容器，都更容易明确，也方便我们检查它的操作。

同时，本地和云端使用同版本镜像，有助于保持运行环境一致，便于迁移和重复部署。这样可以减少“本地能运行，搬上服务器却因为环境不同而报错”的问题。

本课所有自建服务都使用Docker Compose部署。Caddy、OpenCart及PHP-FPM、MySQL分别运行在三个容器中；本地由Caddy提供访问入口，云端再配置域名和HTTPS。第三课主线使用ECS上的MySQL容器，不额外购买云数据库。

Docker减少环境差异，但不会自动完成全部迁移。域名、密码、端口和路径需要按环境调整，数据库和商品图片需要持久化、备份及迁移。自建数据库的升级和恢复，也仍然由我们负责。

镜像与容器：镜像是包含应用及运行依赖的模板，容器是实际运行的服务。本课先认识商城应用和数据库两个容器。

Docker Compose：用一份配置文件描述多个服务，以及它们使用的镜像、网络、端口、挂载和启动依赖。

端口与内部网络：浏览器通过本机或服务器的入口访问商城，应用通过Compose服务名连接数据库。数据库不需要向整个公网开放。

数据卷：容器重建后，订单、商品图片和已有配置需要保留。停止服务不等于删除数据，更新镜像也不等于已经同步数据卷里的文件。

环境配置：本地和云端可以使用相同镜像，但访问域名、密码和端口等配置应分别准备。真实秘密不写进文章或代码仓库。

基本运维：会启动、停止、看状态和查日志，才能判断AI究竟改了哪个服务。下面这些命令在商城项目目录执行，服务名以实际Compose文件为准。

课程不要求你记住所有参数。先知道每条命令在做什么、结果该怎么看，也知道哪些操作会影响已经保存的数据。

网站基础设置：站名、logo、品牌介绍、币种、语言、经营信息和联系方式。后台语言与顾客看到的前台语言可以不同，需要分别核对。

隐私和政策：购买须知、制作周期、取消、退换、隐私说明与客服渠道。AI可以整理草案，但不能替你编造经营事实、面料检测、工厂产能或承诺的交期。

支付方式：安装什么扩展，绑定哪个收款商户，使用沙盒还是正式环境，付款与退款对应什么订单状态。安装成功、商户连接成功、付款测试通过，是三个不同结果。

本案例展示PayPal的商户连接入口。手动连接通常需要商户ID和对应的客户端ID、Secret；由账号持有人直接在后台填写。OpenCart扩展市场的API信息属于另一个账号体系，不是PayPal收款凭据。

产品上架：商品名、款号、分类、价格币种、颜色、尺码、图片、面料说明与库存策略。设计示意图要标明非实拍，尚未打样的尺寸和品质不作已验证承诺。

物流方式：配送地区、运费规则、承运商、运输时间与退货地址。按单生产还要把制作时间和运输时间分开说明，测试运费不能当成真实跨境报价。

先把这些内容整理成检查表。哪些已经确定，哪些只是AI草案，哪些还在等工厂或店主确认，都写清楚。

给商店建立独立项目目录，把品牌、商品、图片、配置模板、Docker文件和验收记录放在一起。优先复用已确认内容，不让AI每次从头生成、覆盖人工修改。

可以把下面这张任务卡交给AI：

真实密码、商户Secret和客户资料放在受保护配置中，不放到公开资料里。AI能生成品牌和文案，不代表名称已经注册、图片已经实拍或商品已经具备销售条件。

启动本地商城，进入后台，按清单完成网站基础信息、商品和配送。支付扩展先检查来源与版本，再安装；真实账户授权和必要确认由商户完成。

直播使用课前准备的案例，现场完整演示一款商品的修改和一条配送规则，不把全部品牌设计、图片生成和软件下载塞进一小时。

如果首页是另外制作的展示页面，而商品来自OpenCart数据库，修改价格时两处都要检查。只改首页的一行文字，不等于后台商品已经更新。

— 日序女装店本机预览，商品图为设计示意

依次打开首页、商品详情、购物车、结算和后台订单，再查看窄屏显示。核对名称、图片、价格、币种、尺码、运费，以及提示文案是否一致。

结算如果提示没有支付或配送方式，先查对应设置和适用条件，不要立刻重建整家商店。提交成功后，进入后台查找同一订单，核对商品、数量、尺码和合计。

然后停止并恢复应用，再检查商品与订单是否保留。数据卷和数据库正常持久化，才不至于重建容器就丢掉业务数据。

AI每轮按“读取现状、说明修改、执行操作、检查结果、记录变更”推进。你检查的是服务状态、日志和前后台结果，而不是一句“已经完成”。

云端继续使用Docker Compose。迁移前先读取服务器和已有网站情况，确定独立站点、容器项目名、端口和访问入口，保留第二课网站。

要搬过去的不只是网页，还包括锁定版本的应用、主题、扩展和语言包，商品图片与上传文件，数据库业务数据，以及目标环境配置。

先备份和导出数据库，再传递项目与资料；云端启动MySQL容器，导入业务数据，恢复应用文件和图片，调整OpenCart的站点地址、路径与数据库连接。不要直接复制正在运行的MySQL数据目录，也不要重新初始化已有商城。

镜像中的文件和已挂载的数据卷也要分清。后台安装过的插件、语言包和上传图片，可能保存在持久化目录中；单纯更新镜像，不代表这些内容已经迁移。

目标环境恢复后，再提交一笔云端测试订单，在云端后台核对，并检查重启后的数据。成功有记录，失败有回滚，才是这次迁移的完整结果。

商品、价格、配送、联系方式和订单，通过云端后台维护。代码、主题和插件升级，先在本地或测试环境验证，再发布。

云端开始产生订单后，不能再把旧的本地数据库整体覆盖上去。网站的程序可以更新，顾客的业务数据需要被保留。

真实支付还需要在目标环境核验商户、正式凭据和通知流程。本机地址不能证明支付平台的服务器通知已经送达；本课模拟订单成功，也不等于真实扣款、退款和工厂派单已经完成。

前十分钟展示成果和电商架构；接着十分钟讲Docker及服务边界；再用十分钟梳理网站、政策、支付、商品和物流配置。

第三十到四十五分钟，用AI完成本地修改、预览与模拟下单；第四十五到五十六分钟，按课前验证路线演示迁移和云端验收；最后四分钟说明备份、持续管理、作业并答疑。

Docker环境、镜像下载、软件包、商品素材，以及云服务器、域名和HTTPS准备放在课前。直播日期另行通知，云端迁移必须完整预演后再跟练。

课后至少准备三款测试商品，设置一条配送规则，提交并核对模拟订单。能指出每个容器的职责、入口、日志与数据保存位置；有已授权云资源的学员，再完成迁移并保存实际验证记录。

截至二〇二六年十月二十八日，案例已在本机验证OpenCart、PHP和MySQL容器运行、模拟下单、后台查单及重启数据保留。商品图仍是设计示意，PayPal尚未绑定商户；完整云端迁移和正式收款尚未验证。

接下来，我们会为这家店加入AI商品顾问和有资料依据的客服。先把商品、订单和服务边界看清楚，再让AI逐步参与更多业务。

OpenCart本次使用的发行版本

Docker Compose官方说明

Docker数据卷说明

PayPal的OpenCart接入指南