TalkLikeYou 启动后能听到声音、但数字人没有口型动作，通常不是单点故障，而是「音频链路通了、渲染链路没通」。权重没加载和渲染没启动都会表现为画面不动，但两者有区别：如果模型权重没读到，推理侧往往整体异常，音频也可能不正常或直接报错退出；只出声不张嘴，更常见的顺序是渲染子进程没被拉起、渲染调用没拿到推理结果、或者渲染输出帧没有落到输出目录。判断方向可以按「日志 → 进程 → 帧文件 → 拆分启动 → 代码打点」五步走，每一步只回答一个是非问题，不靠猜。

声音正常但口型不动，优先怀疑渲染进程未启动或渲染调用未拿到推理输出，而不是权重缺失；权重缺失通常连音频一起异常。可以按顺序验证：启动日志里的权重加载行、渲染子进程是否存在、输出目录帧文件是否随时间更新、音频与渲染能否各自单独启动、渲染函数前后日志是否成对出现。所有判断以实际日志字段、进程列表和文件时间戳为准，不同仓库参数名差异较大，需要结合环境确认。

在启动日志中搜索权重加载成功或失败的关键行

先把日志按启动顺序看一遍，重点找权重文件路径、加载状态、缺失的 key。不同项目的日志字段不一样，可以先粗搜再细看。命令骨架如下，把 app.log 换成实际日志文件，重定向输出或 nohup 写下的文件也算：

grep -iE 'load|loading' app.log
grep -iE 'weight|checkpoint|state_dict|ckpt' app.log
grep -iE 'missing|not found|no such file|unexpected key|size mismatch' app.log

判断方式：日志里出现权重文件路径，并且后面跟着成功加载类的提示，说明权重这一层大概率没问题；出现 missing key、文件不存在、size mismatch，就要先解决权重路径或版本对齐，再谈渲染。风险边界：有的实现把权重加载放在子模块里，日志会写到别的文件，只盯主日志容易误判，可以先确认日志配置的输出位置。

检查渲染模块是否作为独立进程启动

不少数字人项目把渲染放在独立进程或独立窗口里，主程序负责音频，渲染负责画面。主程序出声正常，只能说明音频侧在跑，不代表渲染侧也起来了。Linux 下可以用：

ps -ef | grep -iE 'talk|render|avatar|face|lip'
ps aux `--sort`=-%cpu | head -20

Windows 可以打开任务管理器看，也可以用命令行对照：

tasklist | findstr /i "render avatar python"

拿到进程列表后，回到启动脚本（如 start.sh、run.py、docker-compose.yml 里的 command）对照，脚本里写了但进程列表里没有的那条渲染启动命令，就是断点。适用场景是通过脚本一键启动的部署；如果是手动分步启动，需要按实际执行顺序核对。风险边界：部分框架把渲染做成线程而不是进程，进程列表里看不到属于正常，这种情况下改用下面第 5 节的代码打点确认。

确认输出窗口或视频文件是否生成帧

渲染进程存在，不等于它在干活。判断它有没有消费推理结果，看输出目录的帧文件或视频文件有没有持续更新。先看一次，隔几秒再看第二次，比较修改时间：

ls -lht output/ frames/ | head
watch -n 2 'ls -lt frames/ | head'
find output -type f -newermt '-2 minutes' | head

如果目录里没有新文件、时间戳停在启动那一刻，说明渲染没有往磁盘写结果；如果帧文件在增长但界面不显示，问题更可能在预览窗口或播放环节。适用场景是渲染模块会把帧落盘或推到指定目录；有的实现走共享内存或 socket 不落盘，这时 ls 看不出东西，需要找对应的调试开关。风险边界：用 watch 观察时注意别把磁盘写满，长时间跑建议先看日志再定点观察。

把音频输出和渲染输出拆开单独启动

把两条链路拆开，是区分「音频链路正常、渲染链路断开」最直接的办法。参数名每个仓库都不一样，下面只是骨架，实际以 `--help` 输出或配置文件字段为准：

# 只跑音频，不启动渲染
python app.py `--audio-only` `--no-render`

# 只跑渲染，喂一段已有音频或静音输入
python render.py `--input` sample.wav `--frames-dir` output/frames `--no-audio`

只跑音频时能听到声音，说明 TTS 或音频推理这段是通的；只跑渲染时能生成帧或弹出预览窗口，说明渲染模块本身能跑。两边单独都正常、合在一起只剩声音，问题就落在两者的衔接：传递的数据格式、时间戳对齐、队列或事件通知。配置型项目也可以找类似 enable_render、render.enabled 的开关做同样验证。风险边界：拆开启动时输入数据往往被简化，不能完全等价于联合运行，只能用来定位断点位置。

在代码中给渲染调用前后加日志打点

进程在、帧不更新、拆分也定位不到，就在渲染函数调用前后加日志，确认它有没有被调用、有没有正常返回。骨架如下，函数名和参数按实际代码替换：

import logging, time
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s")

logging.info("render call start, keys=%s", list(face_data.keys()))
t0 = time.time()
try:
    ret = render_frame(face_data, audio_chunk)
    logging.info("render call done, cost=%.3fs, status=%s", time.time() - t0, ret)
except Exception:
    logging.exception("render call failed")

看日志时重点看三件事：start 有没有打印（有没有进到渲染调用）、done 有没有配对出现（有没有卡住或抛异常）、cost 是否一直很小（可能在空转没拿到有效输入）。如果只有 start 没有 done，一般是渲染内部阻塞或在等输入；如果连 start 都没有，说明上游分支没走到渲染，需要回头查条件判断和配置开关。风险边界：加日志会改动源码，建议先在测试环境做，确认后删除或降到 debug 级别，避免长期刷日志。