企业官网建设流程全解析

开年的时候帮客户搭过一套AI数字人直播系统，从源码拉取到最终跑通直播间，前后折腾了小半个月。当时踩了不少坑，也积累了一些部署上的实战经验。今天就把这套系统的源码部署完整流程拆开来讲，从环境准备、服务配置、数字人驱动接入到推流上线，每一步都给出可落地的方案和参数，希望对准备自建数字人直播系统的朋友有帮助。

先说清楚这个项目到底在做什么。AI数字人直播系统，本质上是用虚拟形象替代真人出镜，通过语音合成和口型驱动技术让虚拟主播在直播间讲解商品、回答用户问题，实现7x24小时不间断直播。市面上有很多SaaS产品提供这类服务，但源码自部署的价值在于：没有按分钟计费的抽成、可以深度定制形象和话术、数据掌握在自己手里。适合有一定技术基础、想要搭建直播矩阵的团队，或者说想往这个方向转型的开发者。

1. 项目整体设计与技术架构

1.1 核心需求解析

把标题拆开看，这个项目其实包含了三条技术线。第一是AI能力线，涉及数字人形象的生成和驱动、语音合成、对话应答；第二是直播工程线，涉及音视频流的采集、编码、推流；第三是业务管理线，涉及直播间的创建、排班、商品话术配置、数据统计。三条线缺一不可，最终串成一个完整的直播闭环。

很多人以为数字人直播就是把一段录好的视频循环播放，那是视频轮播，不是数字人直播。真正的系统级数字人直播，需要做到以下几点：

• 形象可控：可以换服装、换背景、切换机位角度，而不是固定一段视频
• 语音实时合成：根据商品文案实时生成语音，支持不同音色、语速、语调
• 口型精准同步：音频播放的同时，数字人的嘴型要和语音内容对齐
• 互动响应：用户评论触发关键词，系统自动生成应答内容并驱动数字人回复
• 直播流稳定输出：长时间运行不掉线、不卡顿，音视频同步

从部署视角来看，系统的核心难点在于把AI推理、媒体处理和业务服务三者串起来，每一层的资源消耗方式和故障表现都不一样，排查问题时往往需要分层去定位。

1.2 系统模块与技术选型

我部署的这套系统，整体分为六个核心组件，每个组件承担独立职责，通过HTTP接口、WebSocket或消息队列进行数据交互：

选型时有一个原则，AI推理类组件和高并发媒体组件尽量分开部署，不要把模型推理和直播流转发放在同一台机器上。我遇到过有人在单机上同时跑数字人推理和Nginx推流，结果直播一开播，CPU直接打满，推理延迟从几百毫秒飙到几秒，数字人直接卡成PPT。

1.3 为什么选择源码自部署

不少朋友问，直接买SaaS服务不香吗？我算过一笔账。市面上的数字人直播服务，一般按直播时长收费，多在每小时几毛到几块钱不等，看起来不贵，但如果你有10个账号同时直播，每天播20小时，一个月的费用就很可观了。而且SaaS方案的数字人是通用的，想用特定形象、特定声音，往往要加钱定制，后期想修改某个功能，还得看平台是否支持自定义。

源码部署的意义在于，一次投入，长期复用。服务器是自己的，模型是自己的，数据也是自己的。系统运行稳定后，增加一个直播间的边际成本极低，这正好匹配直播矩阵的打法。

2. 部署前的环境准备与资源评估

2.1 服务器配置选型

部署这套系统，我首先想强调一个经验：不要拿最低配机器试生产环境，否则你的时间会消耗在排查资源瓶颈上，而不是业务本身。

这里给出两套配置建议：

操作系统的选择上，我建议直接用Ubuntu 20.04或22.04 LTS，原因是部署文档和社区方案大多以 Ubuntu/Debian 为基准，遇到问题搜方案容易搜到。CentOS现在已经停止维护，新系统就别碰了。

GPU服务器采购上，个人开发阶段其实可以先用云GPU按需租用，比如某些云厂商的T4、A10实例，先把整个流程跑通，确认业务模型稳定后再考虑包月或物理机托管。这样前期的试错成本会低不少。

2.2 基础环境安装

环境准备阶段，我建议把所有依赖直接用Docker搞定，不要在自己机器上装一堆原生环境，否则升级系统时容易把环境搞挂。分享一下我的基础环境安装顺序。

先安装Docker和Compose插件：

# 安装Docker curl -fsSL https://get.docker.com | bash # 设置普通用户使用Docker sudo usermod -aG docker $USER newgrp docker # 安装Compose插件 sudo apt-get update sudo apt-get install docker-compose-plugin # 验证 docker --version docker compose version

然后是MySQL和Redis，生产环境我用的是Docker Compose管理：

version: "3.8" services: mysql: image: mysql:8.0 container_name: live-mysql restart: always environment: MYSQL_ROOT_PASSWORD: live@2024 MYSQL_DATABASE: ai_live command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --max_connections=1000 volumes: - ./data/mysql:/var/lib/mysql ports: - "3306:3306" redis: image: redis:7.0 container_name: live-redis restart: always command: redis-server --appendonly yes --maxmemory 1gb --maxmemory-policy allkeys-lru volumes: - ./data/redis:/data ports: - "6379:6379"

MySQL的字符集一定用utf8mb4，中文场景下涉及到表情和特殊字符，如果你用老版本utf8，直播间评论里带着emoji时数据库会直接报错。这个坑我在推行SQL初始化脚本阶段就踩过，初始化时必须把字符集指定清楚，不然后面改起来非常痛苦。

2.3 域名与基础网络配置

如果要在公网直播，建议准备一个域名并完成ICP备案，用于管理后台的HTTPS访问。推流走RTMP协议一般不需要备案，但管理后台如果绑定域名，国内服务器不备案的话，HTTP请求会被拦截。

反向代理我用Nginx，核心配置要点如下：

server { listen 443 ssl http2; server_name admin.example.com; ssl_certificate /etc/nginx/ssl/admin.pem; ssl_certificate_key /etc/nginx/ssl/admin.key; # 管理后台前端 location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 后端API location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # WebSocket信令服务 location /ws/ { proxy_pass http://127.0.0.1:8082/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; } }

WebSocket的代理配置特别容易漏，Connection: upgrade一定要写进去，否则数字人直播间的弹幕互动功能会一直连不上。初次测试时我花了半天排查这个，最后发现就是Nginx配置里少了这两行。

3. 核心服务源码部署与配置

3.1 源码获取与目录结构

拿到源码之后，先不要急着启动，花半小时把目录结构过一遍，弄清楚每个模块的用途。这里的建议是：先理清依赖关系再启动，否则启动时缺一个依赖就会卡住。

一套标准的数字人直播系统源码，通常包含以下目录：

ai-live-system/ ├── admin-web/ # 管理后台前端 ├── server-api/ # 核心后端服务 ├── ai-engine/ # AI推理引擎 ├── media-server/ # 媒体处理与推流服务 ├── data/ │ ├── sql/ # 数据库初始化脚本 │ └── model/ # 数字人模型文件 ├── nginx/ # 反向代理配置 └── docker-compose.yml # 基础设施编排

我需要特别提醒一个点，AI推理引擎的模型文件不要放在Git仓库里直接拉取。数字人模型通常有几个GB大小，Git管理会产生很多无用历史记录，导致克隆很慢。源码仓库里一般只保留模型下载脚本，部署时单独执行脚本把模型文件拉下来。

3.2 数据库初始化

数据库初始化是整个部署过程中最容易出问题的环节。常见的报错是SQL脚本执行一半中断，或者字符集不匹配。

我的建议是手工逐步执行SQL，而不是一把梭把所有脚本管道执行。先在MySQL中创建数据库，再按依赖顺序导入结构脚本和初始数据：

# 进入MySQL容器 docker exec -it live-mysql mysql -uroot -p # 创建数据库 CREATE DATABASE IF NOT EXISTS ai_live DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 退出后在宿主机导入SQL docker exec -i live-mysql mysql -uroot -p ai_live < ./data/sql/01_init.sql docker exec -i live-mysql mysql -uroot -p ai_live < ./data/sql/02_trigger.sql docker exec -i live-mysql mysql -uroot -p ai_live < ./data/sql/03_menu.sql

这里有个很重要的细节：导入SQL前，一定要检查脚本文件本身的字符集。用file命令就能看：

file -i 01_init.sql # 输出应为 charset=utf-8，如果提示 us-ascii 一般问题不大 # 如果提示 iso-8859-1，说明文件编码不对，需要用iconv转码

3.3 后端服务配置

后端配置文件一般在server-api/src/main/resources/application.yml，核心需要关注以下几项：

spring: datasource: url: jdbc:mysql://localhost:3306/ai_live?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: live@2024 redis: host: localhost port: 6379 password: database: 0 timeout: 5000ms # 自定义业务配置 live: # 推流地址 rtmp-addr: rtmp://127.0.0.1:1935/live # 数字人服务地址 ai-engine-url: http://127.0.0.1:9000 # 语音合成类型：aliyun/edge/vits tts-type: edge # 直播状态回调地址 callback-url: http://admin.example.com/api/live/callback

serverTimezone=Asia/Shanghai这个参数也很关键。如果没设置，Java服务连接MySQL时可能出现时区报错。另外MySQL连接串里的useSSL=false要保留，本地部署直接用SSL证书会拖慢建立连接的速度。

3.4 前端管理台编译部署

前端模块如果是Vue项目，编译前先安装依赖：

cd admin-web npm install --registry=https://registry.npmmirror.com

如果npm安装超时或失败，大概率是网络问题。考虑到部署在国内服务器，建议直接用镜像源。编译生产包：

npm run build

编译产物在dist/目录下，把它复制到Nginx的web目录就行：

sudo cp -r dist/* /var/www/admin/ sudo systemctl reload nginx

前端编译时多留个心眼，如果node版本太新或太旧，编译可能报错。我建议Node.js使用16.x LTS版本，v18以上在某些旧前端项目里会报OpenSSL错误。遇到这类报错时，最简单的处理是换Node版本，而不是改代码。比如报error:0308010C:digital envelope routines::unsupported，就是Node版本太高导致，切到Node 16就好。

3.5 服务启动顺序与验证

整体服务的启动顺序很重要，按依赖关系排列：

1. 基础设施：MySQL、Redis
2. 反向代理：Nginx
3. 数字人驱动引擎：AI推理服务
4. 核心后端：server-api
5. 前端静态资源：admin-web
6. 推流服务：media-server

启动后端时，建议用nohup或systemd托管，并设置日志输出，方便排查问题：

cd server-api nohup java -jar live-server.jar --spring.profiles.active=prod > ../logs/server-api.log 2>&1 &

启动后验证是否正常：

# 查看启动日志 tail -f ../logs/server-api.log # 访问健康检查接口 curl http://127.0.0.1:8081/api/health

正常会返回{"status":"UP"}，如果一直不健康，优先检查数据库连接和Redis连接配置。大多数后端启动失败，都是因为这两个依赖服务没通。

4. 数字人驱动模块部署

4.1 形象与音色的准备

数字人驱动模块是整个系统里最核心、也最容易让人一头雾水的地方。这套系统支持的2D数字人方案我实测最靠谱，先用真人口播视频训练一个形象模型，再通过音频驱动生成说话视频。训练素材建议采集1到3小时的竖屏口播视频，分辨率至少1080x1920，画面干净、背景单一、光线均匀，这样训练出来的形象质量最有保障。

音色方面，常用的做法有两种。一是用云厂商的语音合成，音色多、稳定性高、接口简单，按量付费，成本可控；二是本地训练VITS模型，把特定主播的声音克隆下来，完全离线运行。就我的测试体验，本地VITS在拟真度上偶尔会出现发音咬字不清的问题，需要专门调参数，如果你对声音还原度要求极高，建议优先考虑云厂商方案。

4.2 语音合成服务接入

我测试过Edge-TTS、Azure TTS、阿里云TTS和VITS几种方案，从部署成本和效果权衡来看，小规模测试阶段先用Edge-TTS就能满足需求，免费且声音自然度还不错。

Edge-TTS的接入很简单，Python环境里一行命令就能完成：

pip install edge-tts # 测试 edge-tts --voice zh-CN-XiaoxiaoNeural --text "欢迎来到我的直播间，今天给大家带来一款超值好物" --write-media test.mp3

如果是生产环境，我建议把TTS服务封装成一个独立接口，统一提供给数字人驱动引擎调用。简单的Flask封装示例：

from flask import Flask, request, jsonify import edge_tts import asyncio import uuid app = Flask(__name__) VOICE_MAP = { "xiaoxiao": "zh-CN-XiaoxiaoNeural", "yunxi": "zh-CN-YunxiNeural", "yunjian": "zh-CN-YunjianNeural" } async def generate_audio(text, voice, output_path): tts = edge_tts.Communicate(text, voice) await tts.save(output_path) @app.post("/tts") def tts(): data = request.json text = data.get("text", "") voice_name = VOICE_MAP.get(data.get("voice", "xiaoxiao")) if not text: return jsonify({"error": "text is required"}), 400 file_id = str(uuid.uuid4()) output_path = f"/data/audio/{file_id}.mp3" asyncio.run(generate_audio(text, voice_name, output_path)) return jsonify({"url": f"/audio/{file_id}.mp3"}) if __name__ == "__main__": app.run(host="0.0.0.0", port=9001)

这里需要注意，Edge-TTS接口是微软的公开服务，可以用来做二次开发测试，但如果做商用直播，你需要评估服务条款和稳定性。我实际部署时，生产环境就是切换到了阿里云TTS，因为它的接口稳定性和并发能力更好，而且支持长文本分句合成，不会出现读一大段文案突然断掉的情况。

4.3 口型驱动与视频生成

数字人口型驱动这块，我用到的是基于wav2lip的优化方案。核心流程是：输入音频 + 静态形象图，推理生成口型同步的视频。

推荐的开源方案是SadTalker和wav2lip。前者生成效果更自然，包含头部动作、眼睛眨眼细节，但推理速度慢；后者推理速度快，适合长视频生成。我实际部署中做了个折中：静态口播场景用wav2lip，需要带动作和神态的精品视频用SadTalker。

驱动服务的调用接口可以封装成REST API，让调度的直播任务去调用：

from fastapi import FastAPI, UploadFile, File, Form import requests import uuid app = FastAPI() @app.post("/generate") async def generate_video( audio: UploadFile = File(...), image: UploadFile = File(...), ): task_id = str(uuid.uuid4()) # 调用底层的wav2lip或SadTalker推理 result_path = await run_inference(audio.file, image.file, task_id) return {"task_id": task_id, "video_url": f"/result/{task_id}.mp4"}

这里给个性能参考，我用的GPU是RTX 3060 12G显存，每秒推理约2到4帧。一段60秒的数字人口播视频，需要花3到5分钟生成。所以生产环境一定要做视频缓存，不要每次开播都现生成，否则GPU任务排队要压死人。

4.4 GPU显存与并发策略

数字人驱动服务长时间运行后，GPU显存可能会缓慢增长，最终触发OOM。我加的监控指标是nvidia-smi的显存占用和推理服务的平均耗时。

# 定时监控GPU状态 watch -n 1 nvidia-smi

如果发现显存持续升高，及时排查是不是推理框架的内存泄漏。有些版本的Python脚本，每次推理都会保留中间tensor，需要显式调用torch.cuda.empty_cache()。另外一个经验是，对GPU推理服务设置并发数上限，建议并发数不超过2，否则显存不够用时推理任务会排队等待，直播延迟会严重飙升。

5. 直播推流与平台对接

5.1 直播推流的原理与流程

直播的核心是把数字人视频流推到直播平台。通用流程是：数字人视频通过本地推流器或FFmpeg编码后，通过RTMP协议发送到直播平台提供的推流地址。

RTMP推流地址一般长这样：

rtmp://live.example.com/live/stream_key

其中stream_key是平台分配的推流密钥，相当于直播间的身份凭证。如果推流地址或密钥不对，会提示连接失败。需要强调的是，直播平台的推流地址和拉流地址是不同的，平台间的密钥有效期也有差异，有的平台密钥24小时刷新一次，有的长期有效，对接时要看平台文档确认。

5.2 FFmpeg推流实操

生产环境我用的推流方案是FFmpeg，因为它资源占用低、稳定、可脚本化。假设数字人驱动引擎已经生成了一段mp4视频流，使用FFmpeg循环推流：

ffmpeg -re -stream_loop -1 -i digital_human.mp4 \ -c:v libx264 -preset veryfast -b:v 2500k -maxrate 2500k -bufsize 5000k \ -c:a aac -b:a 128k -ar 44100 \ -f flv "rtmp://live.example.com/live/stream_key"

参数说明：

• -re：以原始帧率读取文件，防止推流速度过快
• -stream_loop -1：无限循环播放视频
• -preset veryfast：编码速度优先，减少CPU占用
• -b:v 2500k：视频比特率，清晰度和带宽的平衡点
• -c:a aac -b:a 128k：音频编码和比特率
• -f flv：RTMP协议使用FLV封装格式

码率选择上，1080p直播建议控制在2500到4000kbps之间。如果服务器上行带宽只有50M，多路直播时一定要计算带宽总和，避免总码率超出了服务器带宽上限，所有直播间一起卡。

5.3 直播平台对接的细节

直播平台对接这块，不同平台差异很大。以抖音和视频号为例，都需要先在自己的创作服务平台创建直播间，拿到推流地址和串流密钥。过程中最容易踩的坑是：

• 平台要求推流分辨率、帧率必须满足条件，否则开播状态异常
• 音视频编码格式要符合平台规范，H.264+AAC是通用选项
• 推流过程中不能断流，断流超过一定时长直播会自动关闭
• 直播间的评论互动数据，需要通过平台开放平台的WebSocket或HTTP接口拉取

我之前在对接某平台时，连续推流失败，排查了半天，最后发现是推流地址里多了一个空格字符。这种细节问题最容易浪费排查时间，建议推流地址先用echo命令验证，不要直接复制粘贴到代码里。

平台互动这块，弹幕关键词自动回复需要额外开发，核心逻辑是用WebSocket接收用户评论，做关键词匹配或调用大模型生成回复文案，然后把回复文案传给TTS合成语音，再推送给数字人驱动引擎做口型生成。这个链路中，延迟是最明显的体验指标，整个链路最好能控制在3秒以内，否则用户看到回复太慢，体验会很差。

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

6.1 服务启动失败类问题

后端服务启动失败，是部署阶段最常遇到的问题。我按出现频率列一下，可以直接对照排查：

排查服务启动问题时，我强烈建议先看日志再动手改配置，不要凭感觉乱调。有一次负责部署的同学觉得是内存不足，一上来就把JVM参数调大了，结果还是启动失败，最后看日志才发现是MySQL连接串里密码带了特殊字符，被yaml解析成别的含义了。

6.2 直播画面卡顿与延迟问题

直播画面卡顿，通常有三种原因：编码性能不足、网络带宽不够、CDN链路问题。

编码性能不足的排查方式是看推流服务器的CPU占用，如果CPU接近100%，需要降低分辨率或降低编码preset。我测试过，用ultrafast预设对CPU的占用非常低，但画面颗粒感比较明显，适合低配置机器临时顶一下。

网络带宽问题的排查方式是看推流端的实际上行速率，用iftop查看：

iftop -i eth0 -n -P

如果实际上行速率已经打到带宽上限，那就不是推流软件的问题，是带宽不够了，需要升级带宽或者降低码率。还有一种情况是服务器是共享带宽型，晚高峰会出现带宽争抢，直播延迟和卡顿会变得明显。

画面延迟问题，RTMP推流本身就是秒级延迟，传统RTMP端到端延迟在3到5秒，如果还要叠加CDN分发，延迟会更高。如果对延迟要求高，可以考虑使用低延迟方案如WebRTC或超低延迟直播，但部署复杂度会相应提升。

6.3 数字人口型不同步问题

数字人口型不同步，是这套系统里最让人头疼的问题之一。原因有几种：

音频与视频生产割裂

当TTS服务生成音频后，口型驱动服务以音频为输入，但音频播放的时间基准和视频生成的时间基准没有对齐，就会出现音画不同步。解决办法是在生成视频前，先提取音频的时间戳，根据音频时间轴驱动口型模型。

播放缓存机制不一致

浏览器或播放器的音视频缓冲策略不同，也可能导致已经同步的音视频在播放端不同步。通常的解决办法是让播放器启用音视频时钟同步，以音频时钟为主时钟。

长视频的累积偏差

生成超过3分钟的视频时，每次推理产生的微小误差会累积，导致越往后口型和音频偏差越大。解决方案是分段生成：每60秒一个片段，最后用FFmpeg拼合。

ffmpeg -f concat -safe 0 -i file_list.txt -c copy merged.mp4

我在实际操作中采取的策略是：生成视频后用FFmpeg自带的音视频同步检测工具验证：

ffmpeg -i output.mp4 -af "astats=metadata=1" -f null -

结合人工抽查，基本能保证上线直播的状态下口型误差在可接受范围内。

6.4 长时间运行稳定性的保持

数字人直播系统是7x24小时运行的，稳定性问题一定会暴露。

我遇到的一个典型问题是，直播跑了三四个小时后，数字人的动画开始变得不自然，有时嘴型对不上，经常卡顿。排查后发现是推理服务的显存占用持续增长，最终导致GPU提前释放显存，推理速度变慢。

解决方案是写一个定时监控脚本，如果显存占用超过限制，自动重启推理服务：

#!/bin/bash # 每10分钟检查一次显存占用 while true; do memory=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits) echo "$(date): GPU memory = ${memory}MB" if [ "$memory" -gt 7000 ]; then echo "$(date): GPU memory too high, restarting AI engine..." docker restart ai-engine sleep 60 fi sleep 600 done

另外，日志轮转也值得重视。系统运行一段时间后，日志文件会越来越大，最后占满磁盘导致服务写不了日志直接退出。生产环境建议配置logrotate：

/etc/logrotate.d/ai-live /data/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }

6.5 平台风控问题思考

关于直播平台的风控策略，这里我不展开说细节，但需要给一个明确的提醒：任何数字人直播系统在正式上线前，一定要仔细阅读目标直播平台的规则与规范。不同平台对非真人直播的审核策略不一样，有的平台允许AI数字人直播但必须标注，有的平台会严格限制。

合规运营的建议是：

• 优先选择对数字人直播明确友好的平台
• 在直播间文案中声明虚拟形象播报，避免误导消费者
• 直播内容严格遵守广告法和平台内容规范，不要夸大宣传
• 关注平台发布的AI生成内容治理规则，及时调整

合规问题不是技术能解决的，需要业务层面提前规划。

7. 部署成本与控制方案

部署这套系统，成本需要提前预估。按推荐配置算一笔账：

如果业务量还没跑起来，前期可以先不买GPU服务器，直接用CPU云服务器加TTS云服务测试业务流程。数字人视频预生成后循环播放，甚至可以不用GPU，推流编码由CPU完成，这样前期的成本可以压到几百块一个月。跑通了、确定有收益再升级GPU推理环境，是比较稳的路径。

8. 经验总结与下一步优化方向

这套系统部署跑通之后，后续的优化空间其实很大。我个人实操中体会最深的是，整个项目的复杂度不在单一技术点上，而是在于把AI能力、音视频工程和业务逻辑串起来的过程中，每个环节都可能出现预期之外的问题。

如果让我给准备做这件事的朋友一个建议：第一轮部署不要追求大而全，先把最小闭环跑通，也就是“1个数字人形象 + 1段固定文案 + FFmpeg推流 + 平台开播”，确认直播间能正常出画面、有声音、不卡顿，之后再逐步接入TTS实时合成、弹幕互动、多直播间并发。小步快跑，每一步验证完再做下一步，比一次搞全再大规模排障要高效得多。

关于数字人形象和话术的打磨，我再分享一个经验。同样的技术框架下，直播间的数据差异很大，核心在于人设和话术是否贴合受众。数字人的形象服装、背景色调、语速节奏，包括直播间讲解的起承转合，都要针对目标群体去设计。我之前做过一个对比测试，同一套技术，一套通用话术和一套量身定制话术，观众停留时长差了接近一倍。技术是地基，内容和运营才是上层建筑。

现在这个项目，我后续的方向是在互动能力上做深，让数字人不仅能回答固定关键词，还能结合大模型能力理解用户评论的完整语义，针对复杂问题生成更自然的回复。同时把多平台分发和直播间数据分析做起来，让运维同学在一个后台就能管理所有数字人直播间。这块能力对做直播矩阵的团队来说，价值会非常明显。