做可交互的视听生成，卡点往往不在交互层，而在“一次完整生成”本身没跑通。EchoWM 这类项目要先确认三件事：权重能被加载、一个示例输入能被读进去、输出能落到磁盘并能被播放器或解码工具打开。这三件事成立之前接交互控制，只会把问题从模型层扩散到接口层，后面的延迟、同步、状态管理都无从谈起。最小闭环的合理边界是：一份能跑通的入口脚本加配置、一份能加载的权重、一个最小示例输入，加上一次不带任何交互的前向生成。
EchoWM 的交互控制建议后置。先跑通一次最小生成，固定输入、参数与输出路径，确认输出文件可打开、日志能说清用了哪些设置；再只改一类输入重跑一次，确认输出确实随输入变化。这一步不通，接交互只会把排查面放大。判断交互放在哪一层时，先看延迟预算，再看模型是否支持增量或分块输入，最后才看交互是否只是对已有输出做变换。能放在后处理侧的，通常不必动模型。
确认最小运行需要哪些文件：代码、配置、权重、示例输入
这一节的目的是把“能跑起来”的必需项和可选项分开。EchoWM 仓库的实际目录结构以你本地克隆下来的版本为准，下面按作用分类，文件名只作示例，缺失时的报错表现需要在你的环境里实际确认。
- 入口脚本（常见命名如 inference.py、demo.py、generate.py）：负责加载权重、读输入、调用模型、写输出。缺失或路径不对时，命令直接报“no such file”，或脚本 import 之后找不到可调用的入口函数。
- 配置文件（如 config.yaml、configs/ 下的若干 .json）：指定设备、精度、采样率、时长、步数、输出目录。缺失时常见表现是 KeyError、文件不存在，或者脚本悄悄用了默认值，导致输出和你预期不一致——这类最容易被误判成“模型有问题”。
- 模型权重（如 .pt、.ckpt、.safetensors，可能还带 tokenizer、vocoder 等配套文件）：缺失时报 FileNotFoundError；权重与代码版本不匹配时报 state_dict 键名不匹配；能加载但输出是噪声或静音，通常是权重与配置里的模型规模对不上。
- 示例输入（examples/ 下的一段参考音频、一段文本、一张图或一小段视频）：脚本要求 `--audio`、`--prompt` 之类的参数却没给，会报参数解析错误；给了不存在的路径则报 IO 错误。
- 依赖清单（requirements.txt、environment.yaml）：缺失或版本不合，典型表现是 ImportError、torch 与 torchaudio 版本冲突、CUDA 与驱动不匹配。
可选项包括评测脚本、可视化脚本、Web UI、缓存的预处理结果、预热权重。这些先不装，等最小生成跑通再说。判断某一项是必需还是可选，最简单的办法是看报错：去掉它之后报错指向缺失，就是必需；只是少了某个功能，就是可选。
跑一次不带交互的生成并保存输出与日志
目标不是生成得好看，而是拿到一条后续可以逐项对照的基准输出。下面是一个通用骨架，参数名和选项请以仓库 README 或 `--help` 的实际输出为准，不要照抄。
cd <echo-wm-repo> python -m venv .venv && source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install -r requirements.txt python inference.py \ `--config` configs/base.yaml \ `--checkpoint` weights/echo-wm.ckpt \ `--input` examples/sample.* \ `--output` outputs/run_001/out.* \ `--seed` 1234 \ 2>&1 | tee logs/run_001.log输出统一放到 outputs/run_001/，日志统一放到 logs/，两次运行不要互相覆盖。需要留存的日志片段至少包括这几类：脚本启动时打印的设备与精度、权重加载完成的那一行（含路径）、输入被解析后的形状或时长与采样率、模型执行的总耗时、以及最终写盘的输出路径。这几行是后面判断“输出变了是因为输入变了还是因为别的”的唯一依据。
跑完后先做文件级确认：输出文件存在且大小不为 0，能被 ffprobe、播放器或对应的解码库打开，时长或帧数与配置里写的接近。如果这一步就失败，先不要往下走，问题还在生成链路本身。
改一个输入变量再跑一次，确认输出随之变化
这一步验证的是输入与输出之间的因果关系是否成立。原则是只改一类输入，其他全部保持不变，包括随机种子。按仓库支持的范围选一个最容易观察的变量，优先级建议是：时长或帧数 > 文本内容 > 参考音频。
# 只把时长从基准值改掉，其余参数与 run_001 完全一致 python inference.py \ `--config` configs/base.yaml \ `--checkpoint` weights/echo-wm.ckpt \ `--input` examples/sample.* \ `--duration` 4 \ `--output` outputs/run_002/out.* \ `--seed` 1234 \ 2>&1 | tee logs/run_002.log两次输出的对比观察点，按可核验程度排序：一是日志里输入被解析后的值有没有变；二是输出文件的时长、帧数或尺寸有没有跟着变；三是文件大小和首尾片段的内容差异；四是波形图或频谱图这类可视对比。只看“听起来不一样”不足以归因。
- 输入参数变了、输出时长没变：大概率是参数没被读到，或配置文件的优先级覆盖了命令行参数，需要检查加载顺序。
- 两次输出都有变化，但变化方向杂乱：先把 seed 固定住再看，随机采样会掩盖输入带来的差异。
- 两次输出完全一致：输入根本没进模型，重点查输入路径解析和缓存逻辑。
如果随机种子在仓库里无法固定，那么这一步的结论只能写成“输出确实随输入变化”，不能写成“变化幅度是多少”。
再决定交互控制放在哪一层：输入侧、参数侧还是后处理侧
最小生成稳定之后，再考虑交互挂在哪一层。三种放法各有适用条件，过早压在没稳定的生成链路上，会让排查成本成倍增加。
输入侧：交互产生的内容本身就是模型输入，比如用户改文本提示、换参考音频、按片段送入新的音频块。判断条件是模型支持分块或流式输入，且改动能直接反映到输出。验证方式是改一次输入跑一次，记录从输入变化到输出可用的那段时间；这个时间超出交互预期时，输入侧就不合适。
参数侧：交互改的是采样步数、时长、引导强度、温度这类参数。判断条件是这些参数能被命令行或接口覆盖，并且调整时不需要重新加载权重。验证方式是把权重加载一次，连续改参数跑多次，观察日志里权重是否只加载了一次；如果某个参数一改就触发重载或重建状态，它就不适合做高频交互。
后处理侧：先生成一段较长的基准输出，交互只做裁剪、拼接、变速、淡入淡出、混音这类变换。判断条件是交互对内容的影响可以近似成对已有输出的变换。验证方式是用同一份生成结果做不同后处理，确认全程不需要再跑模型。代价是内容层面无法响应，交互感偏弱，但对延迟最友好。
选择顺序建议是：先看延迟预算，再看模型是否支持增量输入，最后看交互是否只影响呈现。能放在后处理侧就先放后处理侧，等生成链路的耗时和稳定性都清楚了，再把一部分交互上移到参数侧或输入侧。
