Compare
自动化资讯获取与内容分发流水线：从夜间抓取到播客/多端发布
2026-01-29 14:37 · Zon · Issue → AI → Report
面向 Obsidian + 公众号草稿的可迭代实现方案（含 ck/成本监控）
夜间抓取AI资讯→摘要→播客→多端草稿分发
TL;DR
- 本文将“ck”理解为每次 LLM/TTS 调用的 token/费用消耗（若你指 Cookie/凭证等其它含义见 Options）。
- 推荐把现有“随手语音/转发收集→自动整理→公众号草稿”扩展为三层：收集箱(Inbox)→加工层(Curation)→分发层(Channels)，夜间 3–4 点批处理，早上 10 点给你可阅读/可收听的精选。
- 最小可行版本(MVP)先用 RSSHub/FreshRSS 把知乎/微博热搜等变成统一 RSS，再用 n8n 或 Python 定时抓取、去重、摘要，输出到 Obsidian（或你现在的中转库）并生成公众号草稿。
- “ck/成本”优先在你的流水线里做本地账本：记录每次模型返回的 usage、按价格表计算；只有在供应商不提供 API 时才考虑 Playwright 抓取后台（有风控与合规风险）。
Key Insights
- 你已解决“移动场景快速记录+自动落库”，下一步关键不是“更多信息”，而是“相关性与新颖度”排序：让你 10:00 只看 20 条最值得的。
- 数据源策略：能用官方 API 用 API（YouTube Data API、GitHub API）；能用 RSS 用 RSS；对 X/Twitter、部分内容平台优先用“榜单/二次聚合”替代直接抓取，减少封号与不稳定性。
- 产出要面向多渠道复用：同一条内容对象输出 3 种渲染器（阅读版 Markdown、公众号稿、小红书短文/要点），而不是每次重写。
- 播客自动化的门槛不在 TTS，而在“脚本结构+音频托管+分发协议”：先做私有 RSS 播客 feed，你随时可在路上点开听；是否上传到小宇宙再单独评估。
Playbook
- 统一数据模型与存储：定义 Item{url,title,source,published_at,raw,score,tags,summary,script,audio_url,cost}；把“随手语音/转发”也当作一种 source，语音可用 Whisper/faster-whisper 转文字后入库；原始数据与加工结果分层存放（raw/curated/output）+ SQLite 索引，并与 Obsidian Vault 同步。
- 夜间抓取层：RSSHub 路由覆盖知乎/微博等；YouTube 用 Channel RSS 或 Data API 拉取（补齐时长/播放量）；GitHub 用 Search API（stars、created、pushed、topics）+ 可选 trending 抓取；用 cron/systemd timer 或 n8n 定时 03:30 跑完。
- 加工层（决定“值不值得看”）：URL 规范化+simhash/minhash 去重；关键词规则+embedding（sentence-transformers）打标签；按“相关性×热度×新颖度×时效”打分并只保留 Top N；用 LLM 生成 5 句摘要、3 个行动点、1 句为何重要，并输出每日 Digest.md。
- 分发与播放：复用你已有“公众号草稿”链路（优先走微信公众号草稿箱接口）；播客稿用 Piper/edge-tts/Coqui 生成音频，ffmpeg 合成片头片尾与响度归一；上传到 S3/Cloudflare R2 并生成 RSS feed；通过 Telegram/企业微信/邮件推送“今日音频链接”。
Diagrams
Options
- 方案 A（最快落地）：n8n 负责定时、抓取、调用 LLM、写入 Obsidian/公众号草稿；Python 只做少量去重与模板渲染，适合你已通部分渠道的现状。
- 方案 B（可控可扩展）：全 Python（requests+feedparser+GitHub/YouTube SDK）+ Prefect/Airflow 编排；摘要、打分、TTS、RSS 生成都可测试与版本化，也更容易切换到本地 LLM/TTS 降成本与提隐私。
- “ck”另一种常见含义是 Cookie/CK（登录凭证，用于抓取/发布）；若你指的是这个，则需要引入密钥管理（1Password/Bitwarden/Vault）、定期轮换、以及尽量改用官方 API 来减少对 Cookie 依赖。
- 分发策略分级：1) 自动生成 Obsidian Digest + 公众号草稿（默认） 2) 生成私有 RSS 播客供你收听 3) 半自动一键多平台发布（你确认后触发） 4) 全自动跨平台发布（最高风险，不建议起步就做）。
Expert Views
- 开源数据工程师（paraphrase）：先把抓取做成幂等与可回放（保存 raw），否则一旦源站变动就无法重建；把“抓取/清洗/摘要/分发”拆成独立任务，用队列或至少用文件夹状态机避免重复跑。
- 内容运营/产品经理（paraphrase）：强烈建议保留“人审阀门”，默认只自动进草稿箱；先定义栏目模板（今日 3 大主题、每主题 3 条要点、1 个观点冲突），否则自动生成会越来越像“信息噪声”。
- 数据隐私/合规从业者（paraphrase）：尽量避免存储平台 Cookie/密码；使用官方 OAuth/API key 并做最小权限；自动登录+发布在很多平台会触发风控，且可能违反条款，需要你自己评估并准备“随时停机”的开关。
- 语音/音频工程师（paraphrase）：音质提升优先级：稿子结构（分段、停顿、标题读法）> 音色；先用稳定可控的 TTS（可离线）和响度标准化，保证车内/耳机都清晰，再追求“像真人”。
Evidence & Confidence
- “RSSHub + RSS 阅读器/聚合器能统一多来源订阅”——置信度 high；理由：成熟开源生态与大量实践，但具体路由是否可用需你本地跑通（无法在线核验你要的每个源）。
- “YouTube Data API、GitHub REST API 可用于获取视频/仓库元数据与搜索”——置信度 high；理由：有官方文档与稳定接口。
- “X/Twitter 直接 API 获取热点与完整数据可能受限/需付费/政策常变”——置信度 medium；理由：历史上频繁调整，且当前细则无法在线核验，需要以 X 官方开发者文档与账号实际权限为准。
- “小宇宙/小红书是否支持开放发布 API 或 RSS 导入”——置信度 low；理由：公开权限与政策不明，无法在线核验；大概率需要人工或浏览器自动化（风险高）。
Next Steps
- 先补齐 5 个需求参数：ck 的定义、每日产出时长/条数、必选信息源清单、是否必须自动上传小宇宙、运行环境（本地/NAS/VPS）与可用密钥。
- 用 48 小时做 MVP：RSSHub+FreshRSS 拉流 → nightly 摘要与 TopN 打分 → 生成 Obsidian 日报（含“待深读链接”）+ 公众号草稿；同时把每次 LLM 调用 usage 写入 SQLite。
- 跑一周做评估：统计“你最终点开的链接占比/漏掉的热点/重复率/单日成本 ck”，据此调权重与黑白名单；再接入 GitHub rising 与 YouTube。
- 第二周再上播客：先生成私有 RSS feed（你用任意播客 App 听），确认脚本/音质/节奏后，再决定是否做平台上传与多端发布按钮。
Details (Optional)
Details
TL;DR
- 本文将“ck”理解为每次 LLM/TTS 调用的 token/费用消耗（若你指 Cookie/凭证等其它含义见 Options）。
- 推荐把现有“随手语音/转发收集→自动整理→公众号草稿”扩展为三层：收集箱(Inbox)→加工层(Curation)→分发层(Channels)，夜间 3–4 点批处理，早上 10 点给你可阅读/可收听的精选。
- 最小可行版本(MVP)先用 RSSHub/FreshRSS 把知乎/微博热搜等变成统一 RSS，再用 n8n 或 Python 定时抓取、去重、摘要，输出到 Obsidian（或你现在的中转库）并生成公众号草稿。
- “ck/成本”优先在你的流水线里做本地账本：记录每次模型返回的 usage、按价格表计算；只有在供应商不提供 API 时才考虑 Playwright 抓取后台（有风控与合规风险）。
Key Insights
- 你已解决“移动场景快速记录+自动落库”，下一步关键不是“更多信息”，而是“相关性与新颖度”排序：让你 10:00 只看 20 条最值得的。
- 数据源策略：能用官方 API 用 API（YouTube Data API、GitHub API）；能用 RSS 用 RSS；对 X/Twitter、部分内容平台优先用“榜单/二次聚合”替代直接抓取，减少封号与不稳定性。
- 产出要面向多渠道复用：同一条内容对象输出 3 种渲染器（阅读版 Markdown、公众号稿、小红书短文/要点），而不是每次重写。
- 播客自动化的门槛不在 TTS，而在“脚本结构+音频托管+分发协议”：先做私有 RSS 播客 feed，你随时可在路上点开听；是否上传到小宇宙再单独评估。
Playbook
- 统一数据模型与存储：定义 Item{url,title,source,published_at,raw,score,tags,summary,script,audio_url,cost}；把“随手语音/转发”也当作一种 source，语音可用 Whisper/faster-whisper 转文字后入库；原始数据与加工结果分层存放（raw/curated/output）+ SQLite 索引，并与 Obsidian Vault 同步。
- 夜间抓取层：RSSHub 路由覆盖知乎/微博等；YouTube 用 Channel RSS 或 Data API 拉取（补齐时长/播放量）；GitHub 用 Search API（stars、created、pushed、topics）+ 可选 trending 抓取；用 cron/systemd timer 或 n8n 定时 03:30 跑完。
- 加工层（决定“值不值得看”）：URL 规范化+simhash/minhash 去重；关键词规则+embedding（sentence-transformers）打标签；按“相关性×热度×新颖度×时效”打分并只保留 Top N；用 LLM 生成 5 句摘要、3 个行动点、1 句为何重要，并输出每日 Digest.md。
- 分发与播放：复用你已有“公众号草稿”链路（优先走微信公众号草稿箱接口）；播客稿用 Piper/edge-tts/Coqui 生成音频，ffmpeg 合成片头片尾与响度归一；上传到 S3/Cloudflare R2 并生成 RSS feed；通过 Telegram/企业微信/邮件推送“今日音频链接”。
Expert Views
- 开源数据工程师（paraphrase）：先把抓取做成幂等与可回放（保存 raw），否则一旦源站变动就无法重建；把“抓取/清洗/摘要/分发”拆成独立任务，用队列或至少用文件夹状态机避免重复跑。
- 内容运营/产品经理（paraphrase）：强烈建议保留“人审阀门”，默认只自动进草稿箱；先定义栏目模板（今日 3 大主题、每主题 3 条要点、1 个观点冲突），否则自动生成会越来越像“信息噪声”。
- 数据隐私/合规从业者（paraphrase）：尽量避免存储平台 Cookie/密码；使用官方 OAuth/API key 并做最小权限；自动登录+发布在很多平台会触发风控，且可能违反条款，需要你自己评估并准备“随时停机”的开关。
- 语音/音频工程师（paraphrase）：音质提升优先级：稿子结构（分段、停顿、标题读法）> 音色；先用稳定可控的 TTS（可离线）和响度标准化，保证车内/耳机都清晰，再追求“像真人”。
Options
- 方案 A（最快落地）：n8n 负责定时、抓取、调用 LLM、写入 Obsidian/公众号草稿；Python 只做少量去重与模板渲染，适合你已通部分渠道的现状。
- 方案 B（可控可扩展）：全 Python（requests+feedparser+GitHub/YouTube SDK）+ Prefect/Airflow 编排；摘要、打分、TTS、RSS 生成都可测试与版本化，也更容易切换到本地 LLM/TTS 降成本与提隐私。
- “ck”另一种常见含义是 Cookie/CK（登录凭证，用于抓取/发布）；若你指的是这个，则需要引入密钥管理（1Password/Bitwarden/Vault）、定期轮换、以及尽量改用官方 API 来减少对 Cookie 依赖。
- 分发策略分级：1) 自动生成 Obsidian Digest + 公众号草稿（默认） 2) 生成私有 RSS 播客供你收听 3) 半自动一键多平台发布（你确认后触发） 4) 全自动跨平台发布（最高风险，不建议起步就做）。
Evidence & Confidence
- “RSSHub + RSS 阅读器/聚合器能统一多来源订阅”——置信度 high；理由：成熟开源生态与大量实践，但具体路由是否可用需你本地跑通（无法在线核验你要的每个源）。
- “YouTube Data API、GitHub REST API 可用于获取视频/仓库元数据与搜索”——置信度 high；理由：有官方文档与稳定接口。
- “X/Twitter 直接 API 获取热点与完整数据可能受限/需付费/政策常变”——置信度 medium；理由：历史上频繁调整，且当前细则无法在线核验，需要以 X 官方开发者文档与账号实际权限为准。
- “小宇宙/小红书是否支持开放发布 API 或 RSS 导入”——置信度 low；理由：公开权限与政策不明，无法在线核验；大概率需要人工或浏览器自动化（风险高）。
Next Steps
- 先补齐 5 个需求参数：ck 的定义、每日产出时长/条数、必选信息源清单、是否必须自动上传小宇宙、运行环境（本地/NAS/VPS）与可用密钥。
- 用 48 小时做 MVP：RSSHub+FreshRSS 拉流 → nightly 摘要与 TopN 打分 → 生成 Obsidian 日报（含“待深读链接”）+ 公众号草稿；同时把每次 LLM 调用 usage 写入 SQLite。
- 跑一周做评估：统计“你最终点开的链接占比/漏掉的热点/重复率/单日成本 ck”，据此调权重与黑白名单；再接入 GitHub rising 与 YouTube。
- 第二周再上播客：先生成私有 RSS feed（你用任意播客 App 听），确认脚本/音质/节奏后，再决定是否做平台上传与多端发布按钮。
Sources
- RSSHub: https://github.com/DIYgod/RSSHub FreshRSS: https://github.com/FreshRSS/FreshRSS Huginn: https://github.com/huginn/huginn
- n8n（工作流编排）: https://github.com/n8n-io/n8n https://docs.n8n.io/ Prefect（可选）: https://github.com/PrefectHQ/prefect tiktoken（token 计数）: https://github.com/openai/tiktoken
- YouTube Data API: https://developers.google.com/youtube/v3 GitHub REST API: https://docs.github.com/en/rest 微信公众号平台文档: https://developers.weixin.qq.com/doc/offiaccount/
- Playwright（自动化/兜底抓取）: https://playwright.dev/ Piper TTS: https://github.com/rhasspy/piper edge-tts: https://github.com/rany2/edge-tts faster-whisper: https://github.com/SYSTRAN/faster-whisper ffmpeg: https://ffmpeg.org/ （小宇宙/小红书发布接口：无法在线核验）
Sources
- RSSHub: https://github.com/DIYgod/RSSHub FreshRSS: https://github.com/FreshRSS/FreshRSS Huginn: https://github.com/huginn/huginn
- n8n（工作流编排）: https://github.com/n8n-io/n8n https://docs.n8n.io/ Prefect（可选）: https://github.com/PrefectHQ/prefect tiktoken（token 计数）: https://github.com/openai/tiktoken
- YouTube Data API: https://developers.google.com/youtube/v3 GitHub REST API: https://docs.github.com/en/rest 微信公众号平台文档: https://developers.weixin.qq.com/doc/offiaccount/
- Playwright（自动化/兜底抓取）: https://playwright.dev/ Piper TTS: https://github.com/rhasspy/piper edge-tts: https://github.com/rany2/edge-tts faster-whisper: https://github.com/SYSTRAN/faster-whisper ffmpeg: https://ffmpeg.org/ （小宇宙/小红书发布接口：无法在线核验）
Closing Summary
- 结论：夜间抓取AI资讯→摘要→播客→多端草稿分发
- 下一步：先以 RSSHub+定时任务产出 Obsidian 日报与公众号草稿的 MVP。
One next action
先以 RSSHub+定时任务产出 Obsidian 日报与公众号草稿的 MVP。
把收集自动化，把判断留给你，把分发做成按钮。
— 工作流设计原则