信萃 InfoDigest：从 X 与 GitHub 萃取中文图文直达微信草稿箱的开源聚合器

信萃 InfoDigest

从 X（Twitter）与 GitHub 的海量信息中，萃取可信、易消化的中文图文，直达微信公众号草稿箱。

信萃，取"信息萃取"之意——"信"兼指信息、可信与微信，"萃"即萃取精华。它不是内容搬运管道，而是一条信息萃取管线：选料（多源抓取 + 两级过滤）→ 萃取（AI 改写增值，碎片化推文转译为完整易读的中文图文）→ 成稿（排版配图，生成微信草稿）。每篇成稿保留原帖来源与完整审计记录，萃取有据可查。

解决什么问题

信萃解决两层问题。

表层：手动运营一个技术类公众号，每天的事情高度重复。

1. 刷 X 和 GitHub Trending，找出值得写的内容
2. 判断内容质量，筛掉灌水和重复
3. 改写成中文公众号文风，排版、配图
4. 搬进公众号后台，做成草稿

这个过程每天耗费 1-2 小时，且大部分是机械劳动。

深层：好信息难以消化。 一条推文常常只是"预告片"——一句断言、一个链接、一张截图，原文可能是英文、充满术语、缺乏上下文。直接搬运读者看不懂，原文照翻读者没收获。信萃做的事是把"预告片"还原成"正片"：用 AI 把碎片化的信息转译为结构完整、中文读者可以直接消化的内容，而不是逐字翻译或缩写。

机器负责萃取，人来把关——机器产出草稿，人来决定发不发（只创建草稿，永不自动群发）。

工作流程

flowchart LR
    A["定时抓取<br/>X 推文 + GitHub Trending"] --> B["两级过滤<br/>互动量粗筛 + LLM 创新度评分"]
    B --> C["AI 改写<br/>三种生成模式"]
    C --> D["微信公众号草稿<br/>人工审核后发布"]
    C --> E["本地 Markdown 归档<br/>完整审计记录"]

Loading

三种生成模式

系统按内容来源自动选择处理路径，三条路互不干扰：

媒体处理有完整的降级策略：单张图片下载或上传失败只影响那张图（自动降级为纯文字），不会拖垮整篇文章；所有媒体操作留有审计记录，出问题可追溯。

核心特性

• 多源抓取，自带降级：X 内容支持本地 scraper / Apify / twscrape 多通道，一层失败自动切下一层，保证抓取可用性
• 省钱的内容过滤：先用互动量等廉价信号粗筛，再让 LLM 给创新度评分，避免对垃圾内容浪费 token
• 可插拔的 AI 萃取改写：支持 DeepSeek / GLM 等国产大模型（OpenAI 兼容协议），把碎片化推文转译为完整易读的中文图文；主模型失败自动切备用模型，可选多模型投票与 RAG 检索增强，均由配置开关控制
• 成本可见可控：token 用量与费用按月追踪，达到预算阈值自动暂停处理，月度账单一目了然
• 可观测：内置 Prometheus 指标端点与 Grafana 面板（队列积压、任务结果、JVM/容器资源），配套最小告警集，调度漏跑、队列积压、成本超支第一时间知道
• 可靠性优先：Redis 持久化任务队列，应用重启自动恢复断点；任何单篇内容失败不影响后续处理

技术栈

快速开始

# 本地启动（Redis Cluster 等前置配置见 LOCAL_STARTUP_GUIDE.md）
./mvnw spring-boot:run

# 全量回归测试
./mvnw clean test

需要配置：application.yml（主配置，参考 application.example.yml）、api-keys.yml（LLM / X / 微信凭据，不入库）。本地日志同时输出到控制台和 logs/ai-content-aggregator.log，按日期或 20 MB 滚动；生产覆盖配置为 application-prod.yml，自动化测试配置位于 src/test/resources/application.yml。

当前状态

MVP 已交付并在真实环境运行：内容抓取、过滤、改写、媒体嵌入、微信草稿创建全链可用。已知边界：微信 API 出口 IP 白名单未放行的部署环境无法创建草稿（本地 Markdown 归档不受影响）。

最后更新：2026-09-20