抖音归档转写

要解决什么问题

如果你需要把某位抖音创作者的公开可采集作品长期留在本地，而不只是零散保存几个链接，常见痛点是：视频列表容易变、下载中断后难以续传、以及「有文件但没文字」导致后续检索和笔记几乎不可用。这个技能把目标收敛成一条可验证的流水线：每个作品对应一个 .mp4 和一个同名的 .md 转写文件，并且可以用清单对照检查是否真的做完。

技能如何工作

执行前会先检查当前项目里是否已有 douyin_downloader.py 等现成脚本，优先复用而不是另起炉灶。典型流程如下：

1. 用具备浏览器/网络能力的流程解析你提供的抖音分享链接，先拉取创作者视频列表，并保存为 douyin_manifest.json 之类的清单。
2. 按创作者或任务分目录存放，例如 downloads/douyin_*，避免不同创作者的结果混在一起。
3. 逐条下载视频为 .mp4，并在同目录写入同 basename 的 Markdown；文件中需包含元数据、原始文案，以及 ## Transcript 段落的实际转写正文（仅写失败说明不算完成）。
4. 断点续跑：已完整的 .mp4 可复用；.md 只有在已含非失败转写时才跳过。
5. 结束后对照 manifest 做审计：manifest_items、.mp4 数量、带编号的 .md 数量应一致，且每条 .md 在 ## Transcript 之后有真实文本。

转写侧优先 faster-whisper；需用 ffmpeg 抽音频。大陆访问 Hugging Face 不稳定时可设 HF_ENDPOINT=https://hf-mirror.com；未确认 CUDA 可用时，更稳妥的是 --transcribe-device cpu --compute-type int8，以减少类似缺少 cublas64_12.dll 的环境问题。

适用边界与注意点

仅用于你拥有、已获授权，或平台规则允许保存的内容；不要用于无权限批量抓取。解析链接、下载视频、拉取 ASR 模型前通常需要网络权限升级。首次全量归档若风险较高，可先对少量样本做 dry run；默认 base 模型适合稳定首跑，更高质量需接受更长耗时。若 OCR 或人工校对仍必要，应在报告中如实说明质量 caveat。