AI复利手记

WORKFLOW · 工作流

把重复劳动拆成 6 个可自动化的阶段

这不是教程,是一条真在跑的流水线。下面写它现在长什么样、每一步为什么这么拆,以及把它跑坏过几次的那些坑。

这条流水线 2026-09-16 才开始每天跑,还没满 30 天。所以下面写的是它每一步怎么搭起来的、坏过几次,而不是「最佳实践」。等它跑满两个月,这一页会重写一遍。

PRINCIPLES · 三条原则

先立标准,再看内容

01

只写跑了 30 天以上的

用过一次就夸的经验,对别人没有参考价值。所以这一页会随天数据实更新,资格不够的阶段先标出来。

02

说得出省下多少时间

拿不出前后对比的数字,说明只是「感觉快了」。这里能给的每个数字都来自真实运行记录,估的会写明是估的。

03

别人照做也能跑起来

不依赖内部系统、不依赖付费席位。信源全是公开的,取数方式也都在官方文档里写清楚了。

PIPELINE · 链路

整条链路长这样

  1. 01
    采集
    Collect

    21 个源 → RawItem

  2. 02
    归一化
    Normalize

    RawItem → NormalizedItem

  3. 03
    去重聚合
    Dedupe

    NormalizedItem → EventGroup

  4. 04
    排序
    Rank

    EventGroup → Top N

  5. 05
    翻译
    Translate

    英文条目 → 中文条目

  6. 06
    渲染
    Render

    EventGroup → 日报 md / html

21 个源全部跑在公开接口上,不依赖内部系统。 每一层的输入输出都固定,所以换掉任何一层都不会牵动其他层。

STAGES · 六个阶段

每个阶段到底在干什么

01

采集

21 个信源统一进采集层,按各源的实际形态分三类取法 —— RSS、官方 API、浏览器渲染。调度按源的更新频率走,不搞统一轮询。

  • RSS 源取 content:encoded 而不是 summary,否则正文是空的,后面没法溯源
  • 浏览器源先读实测档案再写选择器,不凭「看起来像 SPA」就上渲染
  • 文章型源必须进正文页取全文,停在列表页等于白抓
02

归一化

把每源各不相同的字段压成同一个 schema,同时抽取实体(模型名、机构名)—— 这是后面能跨源比较的唯一前提。

  • 事件发生时间和采集时间分成两个字段,混在一起会让新鲜度算错
  • 日期解析统一走一个入口,不直接调 fromisoformat —— 英文日期格式会静默失败
  • 入口就拦脏数据:CTA 按钮、榜单表头、占位链接都不许进
03

去重聚合

同一件事会被好几家同时报道,这一步把它们合成一条,并把「几个源在报」变成可展示的共振信号。

  • 跨日去重必须落盘,只在内存里做 set 的话,同一新闻会连进三天
  • 写入端和检查端用同一个身份键,两边各拼一个 key 就会静默失效
  • 聚合后还要过一道文本相似度守卫,否则会造出假共振(见下方第 2 个坑)
04

排序

源权威度、事件热度、新鲜度加权打分,再按当天的分数分布取相对阈值 —— 每天收录多少条由分布决定,不写死。

  • 时间参照全流程只取一次,锚定到当日 23:59:59,否则同一份数据两次跑出不同结果
  • 百分位是相对值,阈值会跟着分布动 —— 所以排序必须幂等,不然边界条目天天换
05

翻译

英文条目批量交给 LLM 翻成中文,标题和摘要分开处理,术语表固定下来避免同一个词两天两个译法。

  • 批量请求必须能降级到单条重试,一处坏 JSON 不能连坐整批
  • 要求模型直接返回 JSON 对象,并给足输出长度上限,防截断
  • 解析器要容忍尾随逗号与夹带的解释文字,模型不会永远听话
06

渲染

按版块和编号出当天的日报,原始抓取留档 —— 产物随时可以从原始数据重生成,改版式不用重跑采集。

  • 原始数据是资产、日报是产物,两者分开放,前者永远不覆盖
  • 同一天重跑必须产出逐字节相同的结果,否则改一个字都要重跑全流程
21
个信源
RSS / API / 浏览器三种取法
6
个阶段
从采集到出日报,逐层解耦
12
分钟跑完
全程无人工介入
12
天连续更新
累计 189 条进过日报

PITFALLS · 踩过的坑

这 3 个坑,花了我最多时间

01

拿「跑成功」当健康指标

管道跑通、没报错、也产出了日报,就以为做对了。但时效过滤没生效、重复没去、链接是错的 —— 这些问题全都不抛异常。

当时的证据

11 个浏览器源的日期是英文格式,时间解析一直静默失败,靠 except 兜底把它们全保留了。直到逐条审计才发现时效窗口对这些源从来就没生效过。

现在怎么防

报完成前拿真实产出核对每一项:条数、域名、日期窗口。日志里没有报错,只说明没崩,不说明做对了。

02

用「主实体 + 类型 + 日期」做聚合,会造出假共振

同一天里同一家公司的几条无关新闻被合成一条,还标上「多源共振」。更糟的是代表链接会被顶成不相干的那条。

当时的证据

2026-09-18 一次实测:一个 `openai|news|当日` 的 key 里同时装着「诉讼文件解封」「对谈播客」「提示注入笔记」三件事。当天标了 6 条共振,逐条查完只剩 2 条是真的。

现在怎么防

同一 key 还要过一道标题相似度守卫才允许合并;不像同一件事的条目派生独立 key。宁可少标共振,也不标假的。

03

一次坏 JSON,丢掉一整批

翻译阶段一次请求翻 8 条,用整体解析。模型返回的 JSON 只要坏一处,except 分支就把整批都算成失败。

当时的证据

2026-09-17 第一次全自动跑,GLM 返回的 JSON 在 1842 字符处坏了一个逗号。结果那一批 8 条全部留在英文,日报 16 条里一半是中英混排。

现在怎么防

批失败自动逐条重试,并要求模型直接返回 JSON 对象;解析器容忍尾随逗号。修完用同一批数据重放,8 条一次成功。