Codex 从 GitHub 找工具,并下载并验收 72 集视频

我先让 Codex 从 GitHub 找一个能下载 B 站视频的工具，要求它亲自测试，确认真实可用；随后把《小蝙蝠》幼儿英语视频交给它。这条视频有 72 个分 P。首集测通后，我又让它把整套下载下来。我给出目标、测试链接和操作授权，工具筛选、下载及验收都交给 Codex 执行。

这个任务有一个很具体的验收办法。最后应该出现 72 个能播放的文件，集数从 1 到 72，音轨和画面都在。只找到一个写着“支持 B 站”的仓库，还不能算完成。

先拿这条视频试工具

Codex 先查 GitHub 仓库、发布页和维护状态，还对照了仓库最近推送时间与发布包日期。搜索结果里有很多熟悉的名字。BBDown 的星标很多，仓库却在 2026 年 5 月归档了。它的旧安装包仍然能下载，项目作者已经说明后续不再维护。Codex 没有凭热度选它。

接下来，Codex 用我给的链接测试了几种工具。yt-dlp 的 2026 年 8 月发布版第一次请求就遇到 HTTP 412。调整请求头以后，它读出了这条视频有 72 个分 P，却没有拿到可下载的视频流。另一个近期发布的 BiliFlow 也在请求 B 站接口时收到 HTTP 412。

Codex 还用命令行访问了 B 站的公开视频信息接口，拿到了视频标题、分 P 数量和第一集的编号。这一步帮助它确认链接本身指向一个可识别的视频。报错仍在下载工具的解析过程里，具体原因没法只凭一个 412 状态码下定论。

这些报错说明，项目支持某个网站，与它能否下载眼前这条视频，需要分别验证。Codex 继续找工具，最后试了 Bilibili Downloader GUI 的 v1.62.0 发布版。

第一集下载成功以后，才开始批量处理

这次测试用的是 macOS 的 Apple Silicon 版本。Codex 从项目发布页取得安装包并启动程序。在继续操作这个新下载的程序前，我明确同意它使用该程序。首次启动时，程序先安装 FFmpeg，又在“正在获取用户信息”停了一会儿。进入搜索页后，Codex 把我提供的视频链接填进去。72 个分 P 都列出来了。

Codex 先只选第 1 集。界面显示任务完成，磁盘上也出现了 MP4 文件。它随后用 ffprobe 检查文件，读到了 852×480 的画面、HEVC 视频流和 AAC 音频流，时长约 2 分 10 秒。再用 FFmpeg 把整集从头解码到尾，进程正常退出，没有报错。界面的一行“完成”与磁盘上的实际内容，这时对上了。

这一集的画质是 480p，下载时没有登录 B 站账号。更高画质是否可用，这次没有验证。

我决定下载全集，Codex 接手队列

第一集确认可用后，我发出下载全部 72 集的指令。Codex 先把程序的输出目录改到交付文件夹。列表每页显示 10 集，它在第一页选择第 2 到第 10 集，避开已经下载过的第 1 集；后面逐页选择，到最后一页只选第 71 和第 72 集。

71 个新任务进入程序的下载队列。这个程序按顺序处理任务，提交完以后还要等文件陆续写入。Codex 继续查看目录，新下载的 MP4 从 10 个、23 个、31 个，一直增长到 71 个。加上先前测好的第 1 集，最后正好 72 个。等待过程花了十多分钟。

程序显示队列结束后，Codex 又逐个检查文件名里的集数。1 到 72 全部出现，没有缺集和重复。它用 ffprobe 确认每集都有视频流、音频流和时长，再让 FFmpeg 完整解码全部文件。72 次解码都通过了。这 72 集都是 852×480 的画面，文件合计约 540 MB，总时长约 177 分钟。最后，它按集数顺序把 72 个 MP4 装进一个 ZIP，并检查了压缩包的 CRC。

读者自己验证单个文件，可以使用下面两条命令。批量检查时，让脚本遍历目录里的所有 MP4 即可。

ffprobe -v error -show_entries format=duration:stream=codec_type -of json "第01集.mp4"ffmpeg -v error -xerror -i "第01集.mp4" -f null -

这次我做的事，是提出任务、给出具体视频链接，明确同意 Codex 继续操作新下载的程序，并在首集成功后决定下载全集。Codex 则负责搜索和实测工具。两次遇到 HTTP 412 后，它换了能操作的桌面程序，先测一集，再处理剩下的 71 集。任务结束时，它用文件数量、完整解码结果和 ZIP 校验结果交付。