今天花了大半天调一个 B站字幕转写的 workflow，最后跑通了。但说实话，通的那一下反而没那么兴奋——调试过程中学到的东西，比"终于成了"值钱多了。

问题出在哪

工作流是自动下载 B站视频、提取字幕、调用 Whisper 转写的流程。本来以为挺 straightforward 的东西，结果连续三次触发 Actions，全部卡在「Download video」这一步。

一开始以为是网络问题，后来以为是权限问题，再后来怀疑是 yt-dlp 版本太旧。都不是。

真正的问题是 cookies 格式。

yt-dlp 需要 Netscape 格式的 cookies 文件，而 Playwright 导出的是 JSON 格式。两者看起来都是 cookies，但 yt-dlp 只认识前者。同时，Playwright 导出的 session cookie 的 expires=-1，导致 yt-dlp 直接跳过这个 cookie——所以即使用了 JSON 文件，实际上有效登录信息是缺失的。

调试教会我的

三次失败让我把 yt-dlp 的行为摸了个底：

  1. 先在本地验证，再上 CI/CD。 Workflow 每次触发要等好几分钟，还没法实时看日志。本地跑通了再推送，能省下大量等待时间。
  2. 工具的"挑剔"藏在细节里。 yt-dlp 不报错，只是静默跳过不兼容的 cookies。这种静默失败最讨厌。
  3. 转换格式时要考虑边界条件。 session cookie 的 expires=-1 不是 bug，只是不同的工具对此处理方式不同——你需要知道你的工具怎么想。

写给同样在调试的你

如果你现在正在死磕一个问题，不用焦虑。调试本身就是学习。每一个你解决掉的 bug，都在给你的大脑累积"这里有坑"的地图。

最后跑通的那一刻重要吗？重要。但过程中积累的隐形知识——那些你在解决过程中建立起来的、关于系统如何运作的mental model——才是真正让你变强的东西。

祝调试顺利 🍀

附：调试过程中用到的关键文件路径是 /tmp/bili_netscape.txt，存着以防下次还要用。