归档先判载体再定厚度：视频帖与图文帖两条取料路，写薄写厚由文字量决定

观点：归档的第一道工序不是打标签，是先判载体——视频帖和图文帖的取料路径根本不是一条，混着处理必然有一半东西进不了库。

Florence 把 yzfly/douyin-mcp-server 二开成一个 Claude Code Skill（仓库 zzybrim/douyin-obsidian），用法是把仓库链接复制给 AI 助手让它自己装，之后在 obsidian claudian 里丢一条抖音链接就自动触发。链路的第一步是提取视频 ID 并判断帖子类型：视频帖走”无水印下载加语音转写”，图文帖走”正文提取加图片批量下载”。取到料之后才轮到提炼：AI 提炼核心观点、搭目录索引、打标签，落成带 frontmatter 的 Markdown 笔记，正文里有结构化摘要和全文转录，图片嵌在末尾。仓库 README 还补了一条简介里没讲明的机制——按内容文字总量自动生成轻量、标准、深度三档文档。也就是说，“怎么取”由载体定，“写多深”由原料信息量定，两道分档都不由人当下的心情定。要跑视频帖那一档还得自备条件：Python 3.8 及以上、FFmpeg、硅基流动 API Key。

洞察：分诊与分档是同一件事的两面——把主观判断前移成规则，产出质量才可复现。凡需要人临场决定”这条要不要细做”的归档管线，产量一上去质量必然抖动；把判断标准写进管线（载体分路、字数定档）之后，人才只需要验收，不需要每次重新决策。

启示：新建或改造任何入库工序，先回答两个问题再动代码——原料有几种载体，每种是否各有一条取料路；单条的信息量用什么指标分档。自己库里的对照尺子是”厚度是内容密度的如实反映”：我们靠人工判薄卡厚卡，它靠文字量自动分三档，同一条规律的两种实现。有没有换维度的可能：把分档指标从字数换成”能不能落成可照做的步骤序列”，分档就从篇幅问题变成用途问题，比按字数切更接近使用。

提醒：证据分层要看紧。视频本体零口播（时长 0 秒、无字幕无转写），全部工序描述出自作者自写的简介文案，无实测数据、无失败样本；「文件归位之后索引页自动更新、新条目顺延编号」这条在本仓 README 里查无——216 行正文一次”索引”都没出现，引用前回原视频。维护状态是硬伤：仓库 2026-08-06 建、最后 push 2026-08-22（到 2026-10-21 已 60 天未动）、star 74、fork 5、仓库根目录无 LICENSE 文件；上游 yzfly/douyin-mcp-server 已被原作者标记 archived（star 1279，最后 push 2026-07-02），把底座押在停止维护的仓库上，等于把抖音接口变动的修复责任外包给自己。整条链路对抖音登录、风控、转写错误率一字未提——恰恰是这类工具真正死掉的地方。真要引入，先按既有规矩过装前六类扫描，别被”复制链接让 AI 装”的顺滑骗过去。互动数据可作需求证据：收藏 2384 高于点赞 1758（比 1.36），本批最强的”先存后看”样本。

---

📺 Florence《抖音→Obsidian自动归档》，抖音，2026-08-10 · 原视频 · 仓库 zzybrim/douyin-obsidian · 上游 yzfly/douyin-mcp-server · 库内 2026-10-21-抖音→Obsidian自动归档 · 速览 速览/2026-10-21-抖音Obsidian自动归档skill · 作业卡 卡片/方法/10-21-归档先判载体再定厚度-RIA卡 · 碰撞 卡片/方法/10-12-收藏夹自动化入库流水线