企业官网建设流程全解析

1. 从需求到架构：先把系统拆明白再动手

1.1 “虚拟数字人直播”到底要做什么？——四个必须回答的问题

做过直播类项目的人都知道，所谓虚拟数字人直播并不是简单地在画面里放一个卡通角色，也不是单纯把摄像头画面丢给观众看。它本质上要解决四个问题：谁来“看”现场、谁来“想”内容、谁来“说”台词、谁来“演”形象。把这四个问题落到技术层面，就变成了摄像头采集、大模型推理、语音合成、形象驱动与画面渲染这样几个模块。

这个项目标题把技术栈定得很明确：Python作为主语言，Pygame负责画面渲染与动画驱动，OpenCV负责摄像头取流和图像处理，GPT负责内容生成。换句话说，这一套组合的目标是一个“能感知现场、能生成内容、能以虚拟形象出镜”的直播系统。适合谁来参考？有三类人最合适：一是对直播工具有兴趣、想自己做点不一样玩法的开发者；二是已经把Python基础学完、想找一个能串起OpenCV、GUI、API三块知识的综合项目练手的人；三是做虚拟主播、录课助手、企业宣传等方向，想快速搭一套原型验证可行性的产品人员。

既然是系列文章的第一篇，我不会一口气把语音克隆、口型同步、动作驱动全部塞给你。这一步先把系统的整体骨架立住：能用OpenCV把摄像头画面读进来，能用Pygame把渲染窗口跑起来，能通过GPT接口拿到文本回复，并且三者在一个程序里协同工作。这是整栋楼的地基，地基如果歪了，后面做表情迁移、声音克隆、弹幕互动都会跟着塌。

1.2 技术选型：为什么偏偏是Python+Pygame+OpenCV+GPT？

先说Python。这个选择几乎不需要辩论。直播类项目最怕的就是“边写边改”，Python的开发效率确实高，调试也直观，尤其面对摄像头、窗口渲染、HTTP请求这些不同领域的库时，Python的胶水特性让整合成本降到最低。而且OpenCV、Pygame、OpenAI这些库对Python的支持都是第一优先级的，生态系统成熟，遇到问题随便一搜就有答案，这一点对新手太重要了。

再说Pygame。有人会问，为什么不用Tkinter、PyQt或者干脆用Web前端做界面？我的理由很实在：Pygame的定位就是实时交互和帧渲染，它天然就是为游戏和动画场景准备的。直播画面的本质是持续刷新的帧序列，Pygame的显示循环、Surface贴图、精灵机制和事件系统，正好和这个需求严丝合缝。PyQt当然也能做视频显示，但它的优势在控件布局和管理界面，拿来逐帧画角色动画会别扭很多。后面如果你想做眨眼、张嘴、抬手这些虚拟形象动作，Pygame的精灵动画和逐帧绘制方案是现成的。

OpenCV在这里的角色容易被误解。很多人一听OpenCV就觉得它是用来做识别的，但在这个项目里，它最核心的任务是“取流”和“图像预处理”。摄像头采集、帧率控制、把BGR格式转成Pygame能用的RGB格式、把人像区域抠出来做背景替换，这些事OpenCV干得又快又稳。你甚至可以用它的级联分类器先做一个人脸位置检测，为后续把虚拟形象的头部绑定到真人脸部位置做铺垫，这在直播场景里很有用，可以让虚拟形象跟随你的头部运动。

GPT的作用就更清晰了。它负责“内容大脑”的部分，也就是根据直播的上下文、观众的提问、主播的设定，生成文本回复。这一层是整个系统里最灵活的部分——你今天可以接OpenAI的GPT接口，明天可以换成本地部署的模型，后天甚至可以换成你自建的小模型，只要输出文本，下层的语音合成和渲染模块完全不用改。这种插件式设计是我在动手之前就想清楚的，也给后续扩展留了极大的余地。

1.3 系列分步规划：第一篇做到什么程度才算合格

虚拟数字人直播这个题目太宽，如果一篇全写完，要么每部分都浅尝辄止，要么篇幅失控谁都看不完。我给自己定的系列节奏是四篇：第一篇做整体架构、环境搭建和基础主循环；第二篇做虚拟形象与Pygame渲染细节，包括动画帧管理和表情切换；第三篇做OpenCV的人脸追踪、背景替换和直播画面特效；第四篇做GPT对话流的完整接入和直播部署方案。

这第一篇的合格标准有三个：第一，代码能在你的电脑上干净运行，不报错、不卡死，摄像头画面能出现在Pygame窗口里；第二，你理解为什么程序要这样拆，能说清楚每个模块的职责边界；第三，你手里有一个可扩展的代码骨架，后面每一篇的内容都是在这个骨架上长出来的，而不是推翻重来。如果这三个标准都达到了，这篇的内容你就完全吃透了。

2. 环境准备与工具链验证——先把地基打牢

2.1 Python版本和虚拟环境的选择（3.8 vs 3.10）

环境问题是我见过最多新手卡壳的地方，而且卡得很冤。先说结论：我推荐你用Python 3.10版本，64位版本。为什么不选3.8？因为新版OpenCV和某些依赖库在3.8上能装，但部分编译包已经开始用比较新的特性做优化，版本兼容性上越来越倾向3.10以上。为什么不直接上3.12？因为一些老版本的Pygame或OpenCV轮子可能还没有针对3.12的预编译包，装起来要多折腾很多。

虚拟环境一定要建。这不是什么洁癖，而是实际踩过坑之后怕了。Python项目最忌讳的就是全局环境里堆一堆包，今天为了项目A装了一个旧版本库，明天项目B需要新版本，一升级，项目A就废了。虚拟环境相当于给每个项目一个独立的工具箱，彼此不干扰。创建命令很简单，项目根目录下执行：

python -m venv venv

然后激活它。Windows下是venv\Scripts\activate，macOS和Linux下是source venv/bin/activate。激活之后命令行前面会出现一个(venv)前缀，这就说明你现在在独立的虚拟环境里了。之后所有安装包的操作都在这层“结界”中进行，干净又安全。

2.2 Pygame、OpenCV、OpenAI库安装这一步别踩坑

安装库的顺序有讲究，我建议按依赖深度从低到高装：先装Pygame，再装OpenCV，最后装OpenAI库。为什么这样排？因为Pygame最简单，几乎一次性成功，能给你建立信心；OpenCV涉及底层图像库和摄像头驱动，最容易出问题，建议单独装、单独验证；OpenAI是纯网络请求库，只要网络畅通基本没问题。

安装命令如下：

pip install pygame pip install opencv-python pip install openai

这里有一个重要的区分：opencv-python是社区维护的预编译包，里面包含了OpenCV库本体和Python绑定，日常开发用这个就够了。不要自己去编译OpenCV源码，除非你要改OpenCV内部实现或部署到特殊平台。现在网上还能看到很多让下载OpenCV 3.4.1 mingw64之类的老教程，那是早期Windows开发者被C++编译折腾怕了留下的历史产物，你用pip安装的方式会清爽得多。

装完之后用一段极简代码验证三个库是否都正常：

import pygame import cv2 print("Pygame version:", pygame.version.ver) print("OpenCV version:", cv2.__version__) import openai print("OpenAI library imported.")

PyGame如果在导入时报ModuleNotFoundError: No module named 'pygame'，基本就是没装进当前这个虚拟环境，检查一下终端前面有没有(venv)前缀。OpenCV报ModuleNotFoundError: No module named 'cv2'同理。要注意变量名不要起成cv2.py放在项目目录里，这个错误特别隐蔽，一旦你建了cv2.py这个文件，import的时候Python会优先找到你的文件而不是真正的库。

2.3 理清验证清单：摄像头有画面、窗口不卡、GPT接口通

环境装完之后不要立刻写大段的功能代码，先做一个“三连验证”，每项都通过再往下走。这个习惯能帮你把问题隔离在最小范围里，调试成本低很多。

第一项验证是摄像头。用OpenCV打开默认摄像头，把画面显示出来：

import cv2 cap = cv2.VideoCapture(0) if not cap.isOpened(): print("摄像头打开失败") else: ret, frame = cap.read() if ret: print("摄像头画面尺寸:", frame.shape) cv2.imshow("test", frame) cv2.waitKey(0) cap.release() cv2.destroyAllWindows()

如果你在笔记本上看到弹出一个窗口，里面是摄像头画面，说明视频采集链路通了。如果cap.isOpened()返回False，先排查是不是摄像头被其他软件占用了，比如Zoom、 Teams等，关掉它们再试。如果是台式机且没有摄像头，临时插一个USB摄像头也完全可以。

第二项验证是Pygame窗口能不能正常刷新。这个要写一个极简循环，让窗口里有一个填充色块，并持续刷新：

import pygame pygame.init() screen = pygame.display.set_mode((800, 600)) pygame.display.set_caption("PyGame Test") running = True clock = pygame.time.Clock() while running: for event in pygame.event.get(): if event.type == pygame.QUIT: running = False screen.fill((30, 30, 80)) pygame.draw.circle(screen, (255, 200, 0), (400, 300), 50) pygame.display.flip() clock.tick(60) pygame.quit()

运行之后应该看到一个深蓝色窗口，中间有一个黄色圆形，且不会有明显的闪烁和卡顿。如果窗口打开后立刻无响应，多半是事件循环没写好，或者你是在交互式环境里运行，主循环被阻塞了。这条先记着，后面会专门讲。

第三项验证是GPT接口。这里要准备一个可用的API Key，补丁代码里，用一个最简对话请求测通：

from openai import OpenAI client = OpenAI(api_key="你的API_KEY") resp = client.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": "请回复：你好"}], max_tokens=50 ) print(resp.choices[0].message.content)

能输出一段文本就算通了。如果报网络错误，先确认是你的本地网络是否能正常访问对应API服务。注意Key不要写死在正式代码里，这个我们放到项目环境变量那一节统一处理。

上面这“三连验证”通过之后，环境就算彻底稳了。整个过程我反复强调先验证再写功能，是为了避免后面出现一个“报了错但不知道是库的问题还是自己代码的问题”的尴尬局面。这个问题我在早期项目里被折磨太多次了，现在早就学会了：怀疑别人之前，先把自己的地基验明。

3. 项目骨架实现：先把主循环跑起来

3.1 目录结构和核心文件划分

环境稳了，现在开始搭建项目骨架。我非常不建议把所有的代码塞进一个main.py里，虽然那样能跑，但后面加功能时你会后悔。虚拟数字人直播系统的逻辑链路本来就长，如果不做模块划分，一个文件写到两千行之后，连你自己都找不到某个功能在哪。

我的目录划分是这样的：

virtual_stream/ ├── main.py # 主入口，负责拉起整个系统 ├── config.py # 所有配置项集中管理 ├── camera.py # OpenCV采集模块封装 ├── renderer.py # Pygame渲染模块封装 ├── gpt_brain.py # GPT对话模块封装 └── assets/ └── placeholder.png # 虚拟形象占位图

这个划分逻辑非常清晰：camera.py只管从摄像头拿画面，renderer.py只管把画面和虚拟形象画到窗口，gpt_brain.py只管生成回复文本，main.py负责把它们串起来。每个文件可以独立测试，也方便以后单独替换某个模块。config.py把所有变化的东西集中放一起，比如窗口尺寸、摄像头编号、API模型名称，换机器、换摄像头、换模型时就改这一个文件，不用满项目翻代码。

3.2 用Pygame搭建直播渲染主循环（含代码）

渲染主循环是整个项目的发动机，所有功能都是在这个循环里被反复调用的。我先写一个基础的渲染器模块，只做三件事：初始化窗口、刷新画面、响应退出事件。

import pygame class Renderer: def __init__(self, width=1024, height=768): pygame.init() self.width = width self.height = height self.screen = pygame.display.set_mode((width, height)) pygame.display.set_caption("Virtual Stream") self.clock = pygame.time.Clock() self.running = True self.background_color = (20, 20, 40) def handle_events(self): for event in pygame.event.get(): if event.type == pygame.QUIT: self.running = False elif event.type == pygame.KEYDOWN: if event.key == pygame.K_ESCAPE: self.running = False def draw_frame(self, surface): self.screen.fill(self.background_color) self.screen.blit(surface, (0, 0)) pygame.display.flip() self.clock.tick(60) def run(self, draw_callback): while self.running: self.handle_events() draw_callback(self.screen) pygame.display.flip() self.clock.tick(60) pygame.quit()

解释一下几个关键点。pygame.display.set_mode创建窗口，宽高用元组传入，1024x768是我们当前的默认画布大小。pygame.time.Clock是帧率控制器，tick(60)的意思是把循环尽量锁在60帧每秒，防止动画过快或CPU空转。事件循环里我额外加了Esc键退出，这个习惯很好，直播过程中如果需要快速停止程序，直接按Esc比去点窗口关闭按钮更快。

注意这里我刻意把“绘制内容”和“主循环”分开了，draw_callback是一个回调函数，由外部传入，渲染器只负责骨架，具体画面内容由main.py决定。这个设计能让渲染器足够通用，后面你换背景、加特效，都不需要改renderer.py本身。

3.3 OpenCV取流与帧处理（含代码）

摄像头模块的设计核心是“只管输出一帧画面”，至于画面怎么显示、怎么分析，是别人的事。我把整个采集和转换封装成一个类：

import cv2 import numpy as np class Camera: def __init__(self, camera_index=0, target_size=(1024, 768)): self.cap = cv2.VideoCapture(camera_index) if not self.cap.isOpened(): raise RuntimeError("无法打开摄像头，请检查设备号或驱动状态。") self.cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) self.cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) self.target_size = target_size def read_frame(self): ret, frame = self.cap.read() if not ret: return None frame = cv2.resize(frame, self.target_size) frame_rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) return frame_rgb def release(self): self.cap.release()

这里有一个很关键的转换：OpenCV默认读出来的图像是BGR三通道排列，而Pygame要显示时通常需要RGB排列。如果不做cv2.cvtColor这一步转换，你最后看到的画面里红色和蓝色会互换，人物的脸会变成诡异的青蓝色，这也是新手很常见的“翻车现场”之一。

还有一个细节：摄像头一般原始分辨率是640x480或者1280x720，而我们渲染窗口是1024x768，所以这里做个resize，保证视频帧和窗口画布尺寸一致。严格来说这种直接拉伸在宽高比例不一致时会导致人像变形，后面我会在第四篇里讲如何用“保持比例+黑边填充”的方式做完美适配，这一步先保证能跑通。

3.4 GPT接口模块设计（含占位实现）

GPT模块是整个架构里最独立的一环，它只做一件事：输入用户文本，输出模型回复。先实现一个带“占位策略”的版本，方便你还没有真正配好API Key时也能测试整个系统跑通。

import os from openai import OpenAI class GPTBrain: def __init__(self, api_key=None, model="gpt-3.5-turbo", system_prompt=""): self.client = OpenAI( api_key=api_key or os.environ.get("OPENAI_API_KEY") ) self.model = model self.system_prompt = system_prompt or "你是一名直播主播，请用生动口语化的方式回答观众的问题。" def ask(self, user_input): if not self.client.api_key or self.client.api_key == "YOUR_API_KEY": return "[占位回复] 当前未配置有效的API Key，这只是一条模拟直播文案。" try: resp = self.client.chat.completions.create( model=self.model, messages=[ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": user_input}, ], max_tokens=200, temperature=0.9, ) return resp.choices[0].message.content.strip() except Exception as e: return f"[错误] GPT调用失败: {e}"

我要特别解释一下为什么不直接把这个模块写在main.py里。因为直播系统里“生成回复”和“展示回复”是可以完全解耦的——观众提问进来之后，先触发GPT生成，生成过程中画面完全不用卡住等待，等结果回来了再决定怎么播报。把这一层独立出来，后续你就能非常自然地实现异步化改造。

另外一个很实用的设计是system_prompt参数。同一个GPT模型配合不同的人设提示词，就能生成截然不同的直播风格：学霸博主、搞笑主播、情感电台、产品讲解员，只要改一行配置就行。这个参数在系列第四篇会重点展开，现在先留着接口。

4. 核心细节：图像融合、坐标对齐与模式切换

4.1 Pygame和OpenCV坐标系差异及转换

如果只是分别测通摄像头和窗口，那还不算真正做项目。真正让新手闻风丧胆的是把两个系统的画面合在一起时出现的坐标系错乱。先说清楚两者的差异：OpenCV的图像坐标系原点在左上角，x轴向右，y轴向下，图像的每个像素就是坐标系里的一个点；Pygame的窗口坐标系同样原点在左上角，x轴向右，y轴向下，两者的基本方向其实一致，容易出问题的是尺寸和通道顺序。

还有一个隐藏的坑：OpenCV的VideoCapture.read()返回的图像是numpy.ndarray类型，而Pygame的Surface是它自己的数据类型。你不能直接把numpy数组传进blit，必须先把数组转成Pygame Surface。转换方式很固定：

import pygame import numpy as np # frame_rgb 是形状为 (height, width, 3) 的 uint8 numpy 数组 surface = pygame.surfarray.make_surface(frame_rgb)

但这里有个坑中坑：pygame.surfarray.make_surface默认把数组的维度解释为(width, height, channel)，也就是说它会认为你的数组第一维是宽度、第二维是高度。而我们前面拿到的frame_rgb.shape是(height, width, 3)，维度顺序正好相反。所以直接传进去，出来的画面会有问题。正确做法是先转成(width, height, 3)，也就是做一次轴交换：

frame_surface = pygame.surfarray.make_surface(np.transpose(frame_rgb, (1, 0, 2)))

这一行代码我当年第一次写的时候完全没有意识到，结果画面显示出来是旋转加镜像的，找了很久bug。希望你现在看到这里，能直接绕过这个坑。

4.2 如何在渲染窗口叠加摄像头画面和虚拟形象

我们的渲染逻辑实际上是“分层画布”思路：最底层画摄像头画面，中间层画虚拟形象，最上层画直播UI元素，比如字幕、点赞动画、时间戳等。Pygame里每一层就是一张Surface，通过blit方法把它们按顺序贴到主窗口上。

我这里用一个简化的示例展示三层叠加效果：

import pygame from camera import Camera from renderer import Renderer import numpy as np def draw_scene(screen): # 1. 背景层：深色底 screen.fill((10, 10, 30)) # 2. 摄像头画面层 frame = cam.read_frame() if frame is not None: frame_surface = pygame.surfarray.make_surface(np.transpose(frame, (1, 0, 2))) # 放在窗口右下角，避开虚拟形象的占用区域 screen.blit(frame_surface, (screen.get_width() - frame.shape[1], 0)) # 3. 虚拟形象层（先用占位块） pygame.draw.rect(screen, (100, 200, 255), (400, 300, 220, 220), border_radius=20) renderer = Renderer(1024, 768) cam = Camera(0, target_size=(320, 240)) renderer.run(draw_scene)

这个示例里虚拟形象用一个蓝色圆角矩形代替，实际项目中这里应该是一张带透明通道的角色立绘，甚至是一组动态播放的动画帧。摄像头画面暂时缩小后放在窗口右上角，这是为了调试方便——你可以看着自己的真实动作，确认程序状态正常。

在实际开发中，你通常会希望以摄像头画面为全屏背景，然后把虚拟形象叠加在画面中央，比如覆盖在你的真人脸部上方。这时需要动态计算虚拟形象的绘制位置，而人脸位置的获取就要用到OpenCV的人脸检测能力，这个留给系列第三篇详细展开。但目前你要理解的是：不管你之后用多花哨的效果，底层都是“多个Surface按顺序blit”这一个原理，没有任何魔法。

4.3 接入GPT后的异步非阻塞设计要点

当你把GPT接进主循环后，最直接会遇到的问题是卡顿。因为GPTBrain.ask()是一个同步阻塞操作，一个网络请求可能需要一到三秒才能返回，如果这一步直接写在主循环里，整个直播画面会在这几秒内凝固，观众体验就是“主播卡住了”。这在直播领域是不能接受的。

解决思路是异步化。把GPT调用放到单独的线程或者异步任务里，主循环只负责检查“结果有没有回来”，没回来就继续播画面，回来了就拿结果做显示。用Python的threading实现非常简单，不需要引入重框架。我在gpt_brain.py里可以这样设计一个异步接口：

import threading class GPTBrain: def ask_async(self, user_input, callback): def worker(): result = self.ask(user_input) callback(result) t = threading.Thread(target=worker) t.daemon = True t.start()

这样主循环完全不会被阻塞。调用方在需要时触发ask_async，后台线程去等网络响应，渲染线程继续刷画面，等到回调函数被执行时，再把回复结果更新到画面上。这是直播项目里非常基础但极其重要的一个设计模式，你哪怕现在不写代码，也一定要把这个思路刻在脑子里：凡是耗时操作，都不要占住渲染主线程。

5. 实战中一定会遇到的问题与排查速查表

5.1 环境类问题速查（常见错误表）

我在写这类项目时，几乎每次都能遇到新手栽在同一个地方。我整理了一个速查表，你可以直接收藏起来，遇到问题先来这里对号入座。

这里特别要提一下“环境串了”这回事。很多人明明装好了OpenCV，换一个项目再import就报错，大多数人是因为新项目没有新建虚拟环境，而是直接用了之前的全局环境，但全局环境里恰好没有cv2。养成每项目一环境的好习惯，能消灭大量这种低级但极其消耗耐心的报错。

5.2 摄像头和窗口卡顿的排查顺序

画面卡顿这个问题很玄学，同样是“卡”，原因可能五花八门。我建议按这个顺序排查，能快速定位问题。

第一步查帧率限制。检查你的clock.tick()参数，如果设得太高比如120，而摄像头只有30帧的能力，循环就会空转等待，浪费CPU但画面其实没有更流畅。一般直播渲染场景锁30帧就可以了，人的肉眼看起来完全连续，CPU占用率还降一大截。

第二步查图像尺寸。摄像头原始分辨率如果太高，比如1920x1080，每次resize加cvtColor都要消耗不少CPU资源，尤其是老旧电脑上会更明显。调试期间建议先把采集尺寸降到640x480，渲染窗口降到800x600，等所有功能调通了再往回升分辨率。

第三步查主循环里是否有同步阻塞操作。GPT调用、文件读取、大计算量的图像处理，只要有一个阻塞点卡住主循环，画面就会掉帧甚至卡死。这个问题的王道解法就是我前面说的异步化，先把阻塞操作挪到后台线程里去。

第四步查是否有内存堆积。OpenCV读帧后如果处理速度跟不上，生成的numpy数组会堆积在内存里，越跑越慢直到卡死。确保一帧处理完后及时释放引用，Python虽然会帮忙回收，但大批量临时数组分配时，垃圾回收压力也确实会影响性能。

5.3 GPT接入时的性能与成本控制建议

把GPT接进直播系统，除了技术问题，还有性能和成本的问题值得提前提醒。第一个建议是控制请求频率，不要把每一帧都触发一次GPT调用。合理的做法是设置一个“人机交互触发”机制：有观众提问、有弹幕命中关键词、或者主播按了某个快捷键时才发起请求，平时根本不需要调用。你可以简单维护一个时间戳，距离上次请求至少间隔10秒才允许新的请求，这既是成本控制，也是直播内容质量的保障。

第二个建议是不要滥用max_tokens。直播场景里的回复需要短、口语化、有信息密度，把max_tokens设成300到500就够了。设得过大，不仅计费增加，生成时长也变长，观众等得久体验反而下降。你甚至可以要求系统提示词里写明“字数控制在50字以内”，从源头上约束回复长度。

第三个建议是做好错误降级。网络抖动、接口限流、鉴权过期，这些问题在直播中一定会遇到。代码里必须有兜底逻辑：比如返回一条预设文案或者直接使用上一条回复，不能让画面变成白屏或者直接崩溃。直播没有重来的机会，稳定性永远大于功能丰富度。

6. 从骨架到“活人”：后面的路要怎么接

这套基础骨架跑通之后，你手里就有了一个真正“活”的系统雏形：摄像头在采画面，窗口在持续渲染，GPT在等待被调用。接下来每一个方向的深化都基于这套骨架进行。

我个人在实际开发中的经验是，这个阶段最值得先做的不是更炫酷的动画，而是把GPT的“直播人格”立起来。你可以用系统提示词把虚拟主播的人设写得很具体，包括说话的语速偏好、常用口头禅、知识范围、互动风格等。测试时在终端输入问题，让生成的文案直接显示在Pygame窗口下方作为字幕，这个效果已经很有直播味道了。

后面第二篇我会去处理虚拟形象的动画渲染，把占位矩形替换成真正的角色立绘和动作帧。现在你可以提前准备一张带透明通道的PNG图片，尺寸大概512x512，作为虚拟形象的第一版素材。如果你手头没有美术资源，可以去一些免费素材站找带有透明背景的二次元立绘或者吉祥物形象，先用着，后面技术成熟了再换更精细的版本。

如果你在这个阶段遇到某个具体问题卡了很久，也别灰心。这类跨领域整合项目的特点就是知识面要求宽，但每一项单独拆开都不算太深。你只要把环境、主循环、模块边界这三件事彻底弄懂，后面的路就会越走越顺。接下来我们进入第二篇，正式开始让虚拟形象动起来。