butubb
2112c1a870
移植自 mac-agent-os 的 mediacrawler_adapter：不起子进程、不开页面，用浏览器里那份
登录态直接调抖音 Web 接口。产物键名照抄 store/douyin，所以 ingest 那条链路一个字不用改。
**目前能用的（真环境实测，非推断）**：
profile/other : 200, 7075 字节 —— 博主主页指标（粉丝/获赞/作品数/昵称）
aweme/detail : 200, 45425 字节 —— 单条作品详情（含点赞/评论/收藏/分享）
**目前不能用的：作品列表 `aweme/post`。** 两个互相独立的原因：
1. 这个接口被抖音单独升级成了真校验：不带 x-tt-argus 回 403「Uifid Not Found」，
带上 dummy 值回 200 + **空 body**。也就是说「头在不在」骗得过，「真校验」过不了。
同一套头打 profile/other 和 aweme/detail 都是通的 —— 抖音是挑着接口加保护的，
挑中的恰好是「批量拉作品列表」这个最敏感的动作。
2. 改走页面截获也不行：CDP 浏览器打开博主主页会落到「验证码中间页」（当天大量探测的
代价，过几小时要重测）。
所以现在的边界是：**已知作品的指标刷新能做，自动发现新作品做不了**。
**排查中控住变量后得到的两条事实**（都写进注释了）：
· `Accept` / `Accept-Language` / `Referer` 才是主页接口能返回真数据的原因 —— 只有
UA+client hints+Cookie 时是 200 但仅 121 字节的空壳，补上这三个头变 7074 字节。
（我先前猜的 sec-ch-ua 不是关键。）
· 因此 UA 与 client hints 必须**成套地取自同一个浏览器**，所以 BrowserIdentity 一次
从 CDP 取齐 cookie + UA + hints，而不是各自写死。
「200 + 空 body 必须当场报错」也是刻意写死的：放过去它会在下游变成「这个博主没作品」，
把一次失败伪装成一条正常结果 —— 爬虫那条路正是这么栽的，还被翻译成「账号被封」。
测试 +11：cookie 解析、请求头成套性（含 uifid 缺失/回退）、产物键名与 store 对齐、
以及 _get 的三条失败路径（空 body / 403 带网关原话 / 正常返回）。
4.1 KiB
4.1 KiB
name: collect_to_inbox version: 1.0.0 status: legacy description: [降级] 扫描旧目录的文件转入 00_inbox/。注：v2.0 设计（以 01_submissions/ 为主入口）尚未实现。当前实际代码扫描的是 50_resources/、20_methods/、01_daily/、40_references/ 等旧目录。 triggers:
- 归集
- 归集收件箱
- 收集到收件箱
- 汇聚收件箱
- collect inbox
Collect to Inbox —— 提交箱 → 收件箱
概述
将 01_submissions/（提交箱）中的采集内容转入 00_inbox/（待提纯收件箱）。
这是 收件箱提纯的前置步骤，v2.0 以 01_submissions/ 为主入口。
设计背景（v2.0）
根据 内容收集全链路规范 v2.0：
所有机器统一流程
↓
收集内容 → 01_submissions/（提交箱）
↓
collect_to_inbox（归集）
↓
00_inbox/（待提纯）
↓
inbox_refine（提纯）→ 分类入库
扫描目录配置（按优先级）
| 优先级 | 源目录 | 说明 | 提取策略 |
|---|---|---|---|
| 1 | 01_submissions/ |
v2.0 主入口，所有新建采集内容 | 读取 frontmatter 直接转存，无需重新提取 |
| 2 | 50_resources/ |
旧版兼容，历史遗留内容 | 提取核心摘要 |
| 3 | 20_methods/ |
旧版兼容 | 提取方法名 + 步骤 |
| 4 | 40_references/ |
旧版兼容 | 提取标题 + 核心观点 |
| 5 | 01_daily/闪念笔记/ |
旧版兼容 | 提取要点 + 标签 |
执行步骤（v2.0）
1. 扫描 01_submissions/ 下所有 status:submitted 的 .md 文件
↓
2. 读取 frontmatter：
├── collect_type + collect_subtype 决定提取策略
├── purpose 判断知识类/素材类
└── 素材类 → 跳过（已直存 materials/）
↓
3. 检查 00_inbox/ 中是否已有同名条目（按 title 去重）
↓
4. 无重复 → 复制到 00_inbox/{filename}，追加字段：
├── staged_date: 归集日期
└── status: inbox
↓
5. 更新源文件 status → staged
↓
6. 输出统计报告
兼容旧目录
保留对 50_resources/、20_methods/ 等旧目录的扫描能力，
但优先级低于 01_submissions/。旧目录内容同等转入 00_inbox/。
执行步骤
- 扫描上述所有源目录，查找
.md文件 - 对每个文件：
a. 读取 Frontmatter 提取元数据（title, date, tags, source 等）
b. 读取正文，根据提取策略生成摘要
c. 检查
00_inbox/中是否已有同名文件（去重） d. 如无重复，生成标准化 MD 文件写入00_inbox/e. 在原文件 Frontmatter 中标记collected: true和collected_date - 输出统计报告（扫描数、提取数、跳过数、重复数）
提取后生成的 MD 格式
---
title: {原标题}
source_dir: {原目录相对路径}
source_file: {原文件名}
date: {原始日期}
collected_date: {收集日期}
tags: {原始标签}
nature: {推断的属性：concept/method/fact/reference/resource/opinion}
domain: {推断的领域}
status: inbox
---
# {原标题}
> 来源：{原目录路径}
{提取的主要内容摘要}
去重规则
- 同名文件跳过（
00_inbox/中已存在同文件名） - 同标题文件跳过（Frontmatter title 匹配）
- 已标记
collected: true的源文件跳过
前置依赖
| 依赖 | 说明 |
|---|---|
| Python 3 | 运行脚本 |
| 03_knowledge/ 目录 | 知识库根目录 |
自动化
- 每日凌晨 2:30 自动执行（WorkBuddy automation）
- 在
inbox_refine（3:00）之前运行，确保收件箱有内容可提纯 - 也可手动触发：说"归集"或"收集到收件箱"
与其他技能的关系
收集技能 → 各分类目录（视频笔记/阅读笔记/灵感素材/...）
↓
collect_to_inbox（每日 2:30）
↓
00_inbox/（收件箱，标准化 MD）
↓
inbox_refine（每日 3:00）
↓
按属性+领域分类归档 → 最终目录 + 更新首页