从「开发环境能跑」到「生产环境稳跑」：一篇让你彻底搞懂RAG应用Docker容器化打包与分发的血泪避坑指南。本文将围绕RAG应用的生产环境部署痛点，从容器化必要性、Dockerfile编写、多阶段构建、服务编排、配置管理、镜像分发到生产监控七大维度，手把手教你把脆弱的本地Demo变成坚固的云原生应用。无论你是刚写完第一个RAG Demo的新人，还是正被环境依赖折磨到秃头的老兵，这篇避坑指南都能让你少走弯路，少熬大夜。

目录

1. 容器化必要性：为什么RAG应用离不开Docker？
2. Dockerfile编写：RAG镜像的"建筑设计图"
3. 多阶段构建与镜像瘦身：告别"镜像比模型还胖"
4. 服务编排：向量库与模型服务的"组队开黑"
5. 配置管理：别让敏感信息"裸奔"在镜像里
6. 镜像分发：从"手工搬运"到"一键秒发"
7. 生产监控：容器化不是终点，可观测性才是

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》174.[第18章 生产环境部署] Docker容器化：RAG应用的打包与分发。

开发一时爽，部署火葬场。 你是不是也有这种经历？本地Jupyter Notebook里跑得好好的RAG应用，一到服务器上就各种报错。Python版本不对、GLIBC太低、向量库编译失败、模型路径找不到……折腾到凌晨三点，你盯着终端满屏的红字，开始怀疑人生：是不是我代码有问题？不，问题大概率是——环境。你之前所有的精力都砸在Prompt工程和检索逻辑上，却忘了RAG应用要真正创造价值，必须稳稳地跑在生产环境里。而Docker，就是把这头RAG猛兽关进标准化集装箱的关键武器。今天咱们不聊虚的，就从实战角度，把这七个生死关一个一个趟过去。

---

1. 容器化必要性：为什么RAG应用离不开Docker？

点题

RAG应用从来都不是一个简单的Python脚本。它背后至少拖着三条尾巴：负责语义理解的Embedding模型、存储海量向量的向量数据库、以及生成最终回答的大语言模型。这三者加起来，意味着你的技术栈里既有PyTorch或TensorFlow这类对CUDA版本极其敏感的深度学习框架，也可能有Milvus、Qdrant、Chroma这类对系统库版本有要求的向量引擎。更别提还有FastAPI、LangChain、LlamaIndex等一系列中间件。这么复杂的依赖网络，放到不同的机器上，简直就是一场"环境灾难"的预埋。

痛点分析

很多新手在刚做完RAG Demo时，心里想的都是：“我本地pip install装好了，requirements.txt也导出了，直接扔到服务器上不就行了？” 太天真了。你本地是Python 3.11，服务器可能是3.8；你本地Macbook的M2芯片跑得好好的transformers库，到了Linux x86服务器上可能连装都装不上；你本机用Homebrew装了一堆底层库，服务器上连gcc的版本都对不上。

举个例子，你想用faiss-gpu做加速，本地conda一行命令搞定，到了生产环境，服务器CUDA版本是11.8，你开发机是12.1，结果torch和faiss的版本打架，一import就报错。再比如Chroma的某些版本依赖GLIBC 2.35，而你的生产服务器还是CentOS 7，GLIBC 2.17，启动直接报version GLIBC_2.25 not found。这时候你开始疯狂百度搜索，试各种源码编译，一天就这么过去了。

还有一种思维误区：觉得虚拟机（VM）可以解决一切。VM确实能隔离环境，但一个VM动辄几个G，启动要几分钟，你难道为了部署一个RAG服务去等虚拟机开机？而且VM的镜像更难迁移，更臃肿。

解决方案/正确做法

Docker的本质是什么？它是"环境+代码+依赖"的打包技术。你把RAG应用需要的一切——从操作系统基础库、Python运行时、apt安装的依赖，到pip装的包、甚至预下载的模型权重——全部打进一个镜像里。这个镜像就是一个只读的模板，无论你把它拿到测试机、生产机，还是你同桌的笔记本上，运行出来的环境都一模一样。

具体怎么做？先别急着写Dockerfile，先在本地把你的RAG应用完整跑通，然后确定一个基准环境，比如Ubuntu 22.04 + Python 3.11。接下来，我们要做的就是把这个环境"冻结"进Docker镜像。一旦完成，你在生产服务器上只需要有Docker引擎，然后执行docker run就能拉起来，不需要在服务器上装任何Python环境，不需要配CUDA路径，更不需要折腾向量库编译。

这样做的好处是什么？一致性。开发环境、测试环境、生产环境，三码合一。可移植性。无论是阿里云、AWS，还是你们公司的私有服务器，镜像跑出来的结果完全一致。而且Docker的启动是秒级的，资源占用是MB级的，比VM轻量太多了。

小结

如果你还在用"上传代码+手动装依赖"的方式部署RAG应用，那本质上你还是在做"手工耿式部署"。容器化不是可选项，而是RAG应用从玩具走向工业级生产的门票。

---

2. Dockerfile编写：RAG镜像的"建筑设计图"

点题

Dockerfile是镜像的出生证明，也是你RAG应用的第一道门面。它看起来就是几行声明式的指令，但写得好不好，直接决定了你的构建速度、镜像体积和运行安全。很多新手觉得Dockerfile就是"把敲过的命令行抄进去"，结果写出来的镜像又胖又慢还一堆漏洞。

痛点分析

我见过太多让人血压飙升的Dockerfile了。典型的反面教材长这样：

FROM python:latest
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD python app.py

这短短几行，至少埋了五颗雷。

第一，用python:latest。latest标签就像盲盒，今天构建是3.11，明天基础镜像更新到3.12，你的依赖可能就炸了。而且python官方镜像的完整版自带了一堆你根本不需要的系统工具，体积巨大。

第二，COPY . /app。这一行堪称灾难。你有没有想过，你执行COPY .的时候，把本地的.git目录、__pycache__、虚拟环境venv、测试数据、甚至你藏在项目里的.env文件，全部塞进了镜像？镜像体积直接膨胀几百MB不说，敏感信息也泄露了。

第三，RUN pip install和COPY顺序反了。Docker构建是分层缓存机制，你前面几层是系统依赖，中间是Python包，最后才是业务代码。如果你先COPY .再pip install，那只要你的代码变了一行，缓存失效，Docker就会重新执行pip install，构建时间从几十秒变成十几分钟。

第四，用CMD python app.py而不是exec格式。这种shell格式会导致容器接收不到正确的SIGTERM信号，优雅停机失效。

第五，全程用root用户跑应用。一旦你的RAG应用有漏洞被攻破，攻击者在容器里就是root权限，风险极大。

解决方案/正确做法

一份合格的RAG应用Dockerfile，应该遵循分层、缓存、最小化和安全四个原则。来看看改造后的版本：

FROM python:3.11-slim

WORKDIR /app

# 先单独复制依赖文件，充分利用构建缓存
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 再复制业务代码
COPY src/ ./src/

# 非root用户运行
RUN useradd -m -u 1000 raguser && chown -R raguser:raguser /app
USER raguser

EXPOSE 8000

CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

改动点在哪里？首先，python:3.11-slim是精简版基础镜像，去掉了大量非必要工具，体积小、攻击面窄。其次，.dockerignore文件必须配好，把.git、__pycache__、*.md、tests/这些无关内容排除在构建上下文之外。第三，依赖文件和源码分开COPY，保证只有requirements.txt变化时才重装依赖，代码变更只需复制最后一层，构建飞快。第四，用USER raguser降权，就算被攻破，攻击者也只能在有限权限里折腾。第五，CMD用JSON数组格式，信号处理更标准。

小结

写Dockerfile不是写流水账，而是在设计一栋房子。分层清晰了，缓存才能命中；基础镜像选对了，安全风险才能降低。记住，好的RAG镜像，从第一行FROM就开始体现了你的水平。

---

3. 多阶段构建与镜像瘦身：告别"镜像比模型还胖"

点题

RAG应用特别容易长出"肥胖镜像"。因为你可能需要编译一些向量检索库（比如faiss、hnswlib），或者安装一些需要C扩展的Python包。这些操作在编译时需要gcc、build-essential甚至g++，但运行时就完全不需要了。如果你把这些编译工具全留在镜像里，就像搬家时把装修队的电钻和梯子全塞进衣柜——占地方且危险。

痛点分析

新手最容易犯的错，就是单阶段构建一条龙。比如你要装psycopg2-binary或faiss-cpu，有些环境需要现编，你就在Dockerfile里写：

RUN apt-get update && apt-get install -y gcc g++ build-essential
RUN pip install faiss-cpu chroma-hnswlib

装是装上了，但gcc和build-essential这些包加起来可能占了五六百MB。更坑的是，apt的缓存文件也没清，/var/lib/apt/lists/里还躺着一堆索引。最后你一看，镜像2.5GB，推送到私有仓库要半个钟头，服务器拉取又要半个钟头，启动还慢。

还有一个误区：觉得"镜像大点无所谓，现在硬盘便宜"。错。在云环境里，镜像体积直接影响CI/CD流水线的构建和推送时间，影响节点扩容时的拉取速度，甚至影响你的容器启动耗时。在大规模部署时，镜像每大100MB，成本和时间都是线性增长的。

解决方案/正确做法

多阶段构建（Multi-stage Build）就是来解决这个问题的。它的核心思想是：让编译的归编译，让运行的归运行，中间只传递必要的产物。

来看一个针对RAG应用的多阶段构建示例：

# 阶段一：编译与构建
FROM python:3.11-slim as builder

WORKDIR /build
RUN apt-get update && apt-get install -y gcc g++ && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --user --no-cache-dir -r requirements.txt

# 阶段二：运行环境
FROM python:3.11-slim

WORKDIR /app

# 从builder阶段复制已安装的Python包
COPY --from=builder /root/.local /root/.local

# 只复制源码
COPY src/ ./src/

ENV PATH=/root/.local/bin:$PATH \
    PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

EXPOSE 8000
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0"]

看到了吗？第一阶段装了gcc，编译安装完依赖后，第二阶段是一个干净的slim镜像，只把第一阶段pip install的成果（在/root/.local里）复制过来。最终的镜像里没有gcc，没有build-essential，甚至连apt缓存都被第一阶段清理了。

另外，还有两个瘦身小技巧。一是使用python:3.11-alpine，但它对某些Python科学计算库的兼容性不太好，RAG应用建议还是用slim。二是在pip install时加--no-cache-dir，避免pip把下载的wheel包留在本地缓存。

小结

单阶段构建是新手村的做法，多阶段构建才是生产级的标配。记住一句话：编译工具不是 runtime 的朋友，打完仗就该让它们退场。瘦下来的镜像，跑起来才更快、更省、更安全。

---

4. 服务编排：向量库与模型服务的"组队开黑"

点题

RAG应用从来不是单打独斗。你的FastAPI服务只是门面，背后还得站着向量数据库（比如Milvus、Qdrant、Chroma），可能还得站着Embedding推理服务和大模型推理服务。这意味着一次完整的RAG请求，可能要跨越三个甚至四个进程。如果你只容器化了自己的API服务，让其他组件裸奔在宿主机上，那等于组了个五人队，四个人在泉水挂机——根本不算容器化。

痛点分析

很多新手在Docker化的第一步，只把app.py塞进了容器，然后发现向量库连不上了。为什么呢？因为在容器里，localhost或127.0.0.1指的不是宿主机，而是容器自己。你代码里写死了chroma_host="localhost"，milvus_host="127.0.0.1"，容器一启动，它就在自己肚子里找服务，当然找不到。

还有些同学，知道要用容器，就开始手动执行一堆docker run：

docker run -d --name milvus milvusdb/milvus:latest
docker run -d --name ollama ollama/ollama
docker run -d -p 8000:8000 --link milvus --link ollama my-rag-app

先不说--link这个参数已经被官方标记为遗留功能，这种手动管理的方式在需要重启、扩缩容、查看日志时简直是噩梦。你根本记不住哪个容器对应哪个端口，哪个先启动，哪个后启动。

解决方案/正确做法

对于这种多服务协作的场景，docker-compose.yml才是正确的打开方式。它让你用一份声明式的YAML文件，定义整个RAG技术栈的拓扑关系。

来看一个精简但完整的示例：

services:
  rag-api:
    build: .
    ports:
      - "8000:8000"
    environment:
      - MILVUS_HOST=milvus
      - OLLAMA_HOST=http://ollama:11434
      - EMBEDDING_MODEL_PATH=/models/bge-large
    depends_on:
      - milvus
      - ollama
    volumes:
      - ./models:/models:ro

  milvus:
    image: milvusdb/milvus:v2.3.3
    ports:
      - "19530:19530"
    volumes:
      - milvus_data:/var/lib/milvus

  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama_models:/root/.ollama

volumes:
  milvus_data:
  ollama_models:

关键点在哪里？第一，服务发现。在Compose网络里，milvus和ollama这两个服务名就是DNS主机名。你的代码里直接用os.getenv("MILVUS_HOST", "milvus")，容器内部就能自动解析到对应IP，根本不需要写死localhost。第二，depends_on保证了启动顺序，虽然它只保证容器启动，不保证服务就绪，但至少不会乱序。第三，volumes把模型文件和向量数据持久化到宿主机，容器删了数据还在。第四，一键管理。docker compose up -d拉起全家桶，docker compose logs -f rag-api看日志，docker compose down全停掉，丝般顺滑。

小结

RAG应用是微服务集合，不是单体孤岛。如果你还在手动docker run去拼服务，那就像用算盘做云计算。Compose才是RAG开发环境的瑞士军刀，Production环境的上一步台阶。

---

5. 配置管理：别让敏感信息"裸奔"在镜像里

点题

十二要素应用（Twelve-Factor App）的第一条原则就是：代码库与配置严格分离。对RAG应用来说，OpenAI API Key、向量数据库密码、模型服务端点、日志级别，这些都属于配置，不属于代码。但如果你把它们写进了Dockerfile，或者 worse，写进了代码里，那就等于把家钥匙贴在了大门上。

痛点分析

我见过最离谱的操作，是在Dockerfile里这样写：

FROM python:3.11-slim
ENV OPENAI_API_KEY="sk-1234567890abcdef"
ENV MILVUS_PASSWORD="admin123"
COPY . .
CMD ["python", "app.py"]

看起来很方便，对吧？构建完镜像，跑到哪都有配置。但这里有两个致命问题。

第一，Docker镜像的每一层都是可审查的。别人拿到你的镜像，执行docker history <image>，你Dockerfile里写的每一个ENV值都会明文显示出来。如果你的镜像被推到了公开仓库，或者哪怕私有仓库被同事拉下来看一眼，密钥就泄露了。你的OpenAI账号可能下一秒就被盗刷。

第二，镜像和配置强耦合。你测试环境用一个Key，生产环境用另一个Key；A客户用GPT-4，B客户用国产大模型。如果配置在镜像里，每换一个环境就要重新build一次镜像，这完全违背了Docker"一次构建，到处运行"的设计理念。

还有些同学把配置放在代码里的config.py，虽然没放在Dockerfile，但COPY . .的时候一样打进去了，问题没解决。

解决方案/正确做法

正确的姿势是：镜像是通用的，配置是动态的，在运行时注入。

最基础的做法是用docker run的-e参数：

docker run -d \
  -e OPENAI_API_KEY="$OPENAI_API_KEY" \
  -e MILVUS_HOST="milvus.prod.internal" \
  -p 8000:8000 \
  my-rag-app

在代码里，统一用os.environ.get("OPENAI_API_KEY")读取。如果本地开发，可以用python-dotenv加载.env文件，但.env文件一定要加入.gitignore和.dockerignore，绝不能进镜像。

在docker-compose环境下，更优雅的做法是用.env文件配合Compose自动加载：

services:
  rag-api:
    image: my-rag-app:latest
    env_file:
      - .env.production

或者，在更正式的K8s环境里，使用Secret和ConfigMap来挂载配置和敏感信息。Docker本身也支持Docker Secrets（在Swarm模式下），不过Compose开发环境用环境变量已经足够。

还有一个细节：Dockerfile里可以用ARG来接收构建参数，比如版本号，但绝对不要用ARG或ENV来存放密码、Key这类敏感信息。构建参数的残留同样可能在镜像历史中暴露。

小结

镜像应该像纯净的水晶球，透明且通用，里面不藏任何秘密。配置是衣服，运行时根据不同的场合给它穿上。记住：凡是不应该出现在Git仓库里的东西，更不应该出现在Docker镜像里。

---

6. 镜像分发：从"手工搬运"到"一键秒发"

点题

镜像构建出来了，怎么送到生产服务器上去？如果你还在用docker save打成tar包，然后用scp传到服务器，再docker load，那你的部署流程还停留在石器时代。现代RAG应用的迭代速度极快，Prompt改了要发版，模型权重更新了要发版，检索逻辑优化了也要发版。没有高效的分发机制，你的创新速度会被部署流程活活拖死。

痛点分析

手工分发的问题罄竹难书。首先是版本混乱。因为你懒得打标签，所有镜像都叫my-rag-app:latest。测试环境正在验证一个版本，你顺手又给latest覆盖了一层，结果测试环境莫名其妙拉到了新代码，测试员一脸懵逼。生产环境也是latest，但你根本不知道这个latest对应的是Git仓库的哪一次提交，出了问题无法回滚。

其次是效率低下。一个RAG镜像动辄七八百MB甚至上GB，用scp传一次十分钟，传着传着连接断了，心态也崩了。团队里多几个人同时部署，带宽占满，大家排队等。

最后是安全隐患。tar包到处传，谁手里有备份都不清楚，泄露了也查不到责任人。

解决方案/正确做法

你需要一个私有镜像仓库（Registry），这是镜像分发的"中央火车站"。轻量级的可以直接用Docker官方提供的registry:2镜像自己搭，企业级推荐Harbor，它自带权限管理、漏洞扫描、复制策略，非常适合RAG应用这种对安全性有一定要求的场景。

有了Registry，你的镜像命名应该遵循语义化版本规范：

docker build -t my-registry.internal/rag-api:v1.2.3 .
docker push my-registry.internal/rag-api:v1.2.3

生产环境部署时，不再scp，而是直接：

docker pull my-registry.internal/rag-api:v1.2.3
docker run -d my-registry.internal/rag-api:v1.2.3

更进一步，把构建和推送流程写进CI/CD流水线。以GitLab CI为例：

stages:
  - build
  - push

build_image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

每次你push代码到主分支，CI就自动构建镜像，并以Git提交哈希作为tag推送到仓库。生产环境要发版时，只需要更新compose文件里的镜像tag，执行docker compose pull && docker compose up -d即可。回滚也简单，把tag改回上一个版本号，重新up一次，秒级完成。

对于国内用户，如果拉取基础镜像慢，可以配置Registry的镜像缓存（Mirror），或者在CI里使用阿里云的ACR、腾讯云的TCR等托管服务，内网传输速度极快。

小结

没有版本管理的镜像分发，就是一场游击战。搭建私有Registry，配合语义化Tag和CI/CD自动化，才能让你的RAG应用从"月更"变成"日更"，甚至"随时更"。

---

7. 生产监控：容器化不是终点，可观测性才是

点题

很多新手以为，容器化就是把应用塞进Docker，然后docker run -d扔在后台，万事大吉。但生产环境是真正的战场。你的RAG应用可能因为一次超长的上下文检索导致内存爆涨，可能因为模型加载失败进入假死状态，也可能因为磁盘IO过高被宿主机Kill。如果看不到、感知不到，那你就是一个"盲人骑手"。

痛点分析

最常见的坑是资源不设限。Docker容器默认可以使用宿主机的全部资源。你的RAG应用在处理一个超长文档时，Embedding模型需要大量内存，突然就把宿主机的16G内存吃满了。Linux的OOM Killer一看情况不对，直接把你的容器杀掉。你早上起来发现服务挂了，日志里只有一行Killed，一脸懵逼。

第二个坑是日志管理。有些同学让应用把日志写到容器里的/app/logs/app.log，结果容器一重启，日志全没。或者日志文件无限增长，把宿主机的磁盘撑爆。还有些同学发现docker logs看不到东西，因为在应用里配置了FileHandler，标准输出（stdout）是空的。

第三个坑是缺少健康检查。容器状态是Up，但里面的FastAPI服务已经因为向量库连接断开而卡死了。负载均衡器还源源不断地把请求发过来，用户看到的全是超时。

解决方案/正确做法

第一，给容器戴上"紧箍咒"——资源限制。

docker run -d \
  --memory="2g" \
  --memory-swap="2g" \
  --cpus="1.5" \
  my-rag-app

这表示你的RAG容器最多只能用2GB内存和1.5个CPU核心。即便发生内存泄漏，也不会拖垮整台服务器。在docker-compose里也可以写：

services:
  rag-api:
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 2G
        reservations:
          memory: 512M

第二，在Dockerfile里加入健康检查（HEALTHCHECK）。

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD curl -f http://localhost:8000/health || exit 1

你的RAG应用需要暴露一个简单的/health端点，检查一下向量库连接和模型加载状态是否正常。如果连续三次检查失败，Docker会将容器标记为unhealthy，配合--restart=unless-stopped或编排工具可以实现自动重启或流量摘除。

第三，日志必须输出到标准输出和标准错误。不要用文件日志Handler，而是让Python的日志直接走stdout：

import logging
import sys

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    handlers=[logging.StreamHandler(sys.stdout)]
)

这样docker logs -f <container>就能实时看到日志。在生产规模较大时，可以用Fluentd、Promtail或Filebeat把容器日志统一收集到ELK或Loki里，方便检索和告警。

第四，监控指标。对于RAG应用，除了常规的CPU、内存监控，还要关注检索延迟（retrieval latency）、生成延迟（generation latency）、向量库连接池状态等。可以在应用内暴露一个/metrics端点，用Prometheus来抓取。

小结

会写Dockerfile是入门，会设置资源限制是进阶，能构建完整的可观测性体系才是生产级高手。容器化只是让应用跑起来，监控和日志才能让它一直稳着跑。

---

写在最后

读到这儿，你应该发现了，Docker容器化对RAG应用来说，绝不只是"写一个Dockerfile"那么简单。它是一套从构建、编排、配置、分发到运维的完整工程化思维。很多新手卡在部署这一关，不是因为技术多难，而是没有体系化地看待这个问题——环境依赖要靠容器解决，服务协作要靠编排解决，配置安全要靠运行时注入解决，持续交付要靠Registry和CI/CD解决，稳定运行要靠监控和资源限制解决。这七个要点环环相扣，缺一不可。

咱们搞技术的，最怕的不是写不出代码，而是代码跑不起来、跑不稳、跑不久。你花三个月调出了一个召回率90%的RAG检索策略，结果因为镜像没做好，生产环境一天崩三次，那这三个月的价值就大打折扣了。所以，请务必重视部署这件事，它是你技术实力的最后一道护城河，也是你职业生涯里最具性价比的投资之一。

编程之路不易，但每一步成长都算数。能把RAG应用稳稳当当地塞进容器、分发到生产、监控到细枝末节，这种能力会让你在团队里闪闪发光。保持好奇，保持动手，保持对工程化细节的敬畏，你不仅能成为代码写得快的人，更能成为系统跑得稳的人。加油，咱们下篇见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》