[kanomahoro1224]

概要

• 将 download 收敛为唯一的 yt-dlp 下载后端，移除 Twitch TS 直连与后端选择逻辑
• download 默认下载最佳音频并提取 MP3，分片并发默认固定为 5
• 移除 --backend / --audio-only / --yt-format / Twitch 分片相关参数，新增 --yt-dlp-args 与裸 -- 透传 yt-dlp 原生参数
• yt-dlp 不进入 pyproject.toml / uv.lock 固定版本，按 ffmpeg 类似的外部工具处理：用户自行 pip install -U yt-dlp 保持最新版
• 同步 README / CLAUDE / 单元测试

背景

下游转字幕、翻译、总结流水线只依赖音频产物。使用 yt-dlp 作为唯一下载后端后，Twitch VOD、YouTube 和其他 yt-dlp 支持站点都走同一条路径，KITS 不再维护 Twitch TS 分片探测、合并与后端选择逻辑。

yt-dlp 需要跟随站点变化持续更新，因此不适合被项目 lock 文件固定版本；KITS 只调用 PATH 中的 yt-dlp 命令，并在缺失时提示用户安装/更新。

验证

• uv run ruff check .
• uv run pytest tests/test_downloader.py tests/test_cli.py
• uv run pytest
• uv run --no-project --with "pytest>=9.0.3" --with httpx --with pydantic --with tqdm python -m pytest -q -m "not requires_torch"

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[kanbereina]

1. 关于下载后端

yt-dlp 本身已经完整支持 Twitch VOD 下载，包括分片合并、格式选择等。既然本项目后续的转字幕、翻译、总结流水线只依赖音频产物，是否可以直接使用 yt-dlp 作为唯一的下载后端，移除原有的 Twitch 直连逻辑？

好处是：

• 不需要维护两套下载逻辑，减少测试和维护成本
• Twitch API 变化时，yt-dlp 社区响应更快，我们不需要跟着改
• 用户只需要一个 URL，不需要关心 --backend 选哪个

2. 关于CLI参数

既然本项目下游只依赖音频，可以简化 download 子命令的设计：

• 移除 --audio-only：默认就是下载音频，不需要用户指定
• 移除 --backend：统一使用 yt-dlp
• 移除 --yt-format：内部固定使用 yt-dlp 的最佳音频格式

另外想讨论一个方向：download 子命令是否可以直接接受 yt-dlp 的原生参数透传？

例如用户这样使用：

uv run kits download "https://youtu.be/xxx" -- -f bestaudio --extract-audio

或者直接：

uv run kits download --yt-dlp-args="-f bestaudio --extract-audio" "https://youtu.be/xxx"

这样本项目不需要维护任何下载相关的参数，完全由 yt-dlp 自己处理，用户也能使用 yt-dlp 的全部能力。

当然这样对用户的要求更高一些（需要了解 yt-dlp 语法），但好处是 CLI 非常薄，本项目只需要调用 yt-dlp 并拿到音频文件即可。

3. 关于依赖

建议将 yt-dlp 从 extra 提升为 core dependency，简化安装流程。

[kanomahoro1224]

1. 关于下载后端

yt-dlp 本身已经完整支持 Twitch VOD 下载，包括分片合并、格式选择等。既然本项目后续的转字幕、翻译、总结流水线只依赖音频产物，是否可以直接使用 yt-dlp 作为唯一的下载后端，移除原有的 Twitch 直连逻辑？

好处是：

• 不需要维护两套下载逻辑，减少测试和维护成本
• Twitch API 变化时，yt-dlp 社区响应更快，我们不需要跟着改
• 用户只需要一个 URL，不需要关心 --backend 选哪个

2. 关于CLI参数

既然本项目下游只依赖音频，可以简化 download 子命令的设计：

• 移除 --audio-only：默认就是下载音频，不需要用户指定
• 移除 --backend：统一使用 yt-dlp
• 移除 --yt-format：内部固定使用 yt-dlp 的最佳音频格式

另外想讨论一个方向：download 子命令是否可以直接接受 yt-dlp 的原生参数透传？

例如用户这样使用：

uv run kits download "https://youtu.be/xxx" -- -f bestaudio --extract-audio

或者直接：

uv run kits download --yt-dlp-args="-f bestaudio --extract-audio" "https://youtu.be/xxx"

这样本项目不需要维护任何下载相关的参数，完全由 yt-dlp 自己处理，用户也能使用 yt-dlp 的全部能力。

当然这样对用户的要求更高一些（需要了解 yt-dlp 语法），但好处是 CLI 非常薄，本项目只需要调用 yt-dlp 并拿到音频文件即可。

3. 关于依赖

建议将 yt-dlp 从 extra 提升为 core dependency，简化安装流程。

那么直接使用 yt-dlp 作为唯一的下载后端，关于CLI参数也可以这么改，不过对于yt-dlp还有一件事，目前yt-dlp需要一个相对来讲持续更新的版本，也就是说并不需要指定版本，保证最新版本即可

[kanbereina]

目前项目使用 uv sync 统一管理依赖，ffmpeg 是让用户自行安装的。yt-dlp 可以采用同样的方式，在文档中说明用户自行 pip install yt-dlp 即可。

另一种方案是作为可选依赖（extra）加入 pyproject.toml，不锁版本，用户通过 uv sync --extra yt-dlp 安装。

两种方式都能满足"不限制版本"的需求。

[kanomahoro1224]

目前项目使用 uv sync 统一管理依赖，ffmpeg 是让用户自行安装的。yt-dlp 可以采用同样的方式，在文档中说明用户自行 pip install yt-dlp 即可。

另一种方案是作为可选依赖（extra）加入 pyproject.toml，不锁版本，用户通过 uv sync --extra yt-dlp 安装。

两种方式都能满足"不限制版本"的需求。

那就在在文档中说明用户自行 pip install yt-dlp 安装最新yt-dlp即可