很多人做 AI 资讯整理时，第一反应是“多接几个 RSS，再加一个摘要接口”。真正运行一段时间后，难点通常不在摘要，而在于如何把不同来源的内容稳定地采集、过滤、去重，并且让数据库能够承受后续查询和扩展。
本文把一个 AI 资讯聚合平台拆成四层：采集、筛选、去重和存储。示例采用 Python、兼容 OpenAI API 的模型服务、PostgreSQL 与 pgvector，适合个人开发者或小团队先做一个可运行的版本，再逐步增加数据源和调度能力。
先确定最小可用链路
一个可用的资讯聚合器，不必一开始就覆盖所有平台。建议先完成下面这条链路：
- 从 RSS/Atom 或一个稳定的 API 获取文章元数据和正文。
- 用规则做第一轮过滤，例如发布时间、语言、来源和关键词。
- 用模型判断主题相关性，生成标题、摘要、标签和重要性分数。
- 用指纹和向量分别处理“几乎相同的转载”和“不同措辞的同一事件”。
- 把原文、处理结果、来源和向量写入 PostgreSQL。
- 通过一次性命令和定时任务分别支持调试运行与长期运行。
这样拆分的好处是每一层都能单独替换。后续增加 YouTube 字幕、社区讨论或 GitHub 项目时，只需要新增采集器，不必重写数据库和摘要流程。
数据源：按内容形态分别处理
RSS/Atom 适合博客和媒体，是最容易维护的入口。讨论型来源需要额外保存互动数据和评论上下文，否则模型只能看到标题，难以判断一条帖子是否值得保留。视频来源则需要先获得字幕或转写文本，再进入过滤和摘要环节。
采集器不要把“抓到”直接等同于“入库”。建议先保存来源 URL、抓取时间、发布时间、作者、原始标题和正文哈希；抓取失败、正文为空或超过保留期限的内容，都应在进入模型之前被拦截。
对于讨论内容，互动门槛可以作为排序信号，但不宜作为唯一淘汰条件。刚发布的内容可能还没有足够的点赞和评论，因此更稳妥的做法是把低互动内容放入延迟复查队列，而不是永久删除。
过滤与摘要：让模型处理判断，不处理脏数据
模型调用前先做便宜的规则过滤，可以减少无效请求。模型输出也应使用结构化格式，至少包含：是否与 AI 相关、摘要、标签、重要性分数和需要人工复核的原因。
不同内容类型要使用不同的摘要口径：新闻摘要要区分已确认事实和影响判断；开源项目要说明解决的问题、依赖和部署门槛；讨论帖要保留主要观点分歧，而不是把评论简单压成一句结论。
不要把模型返回的自然语言直接写入下游业务字段。建议先校验 JSON schema、长度、枚举值和必填项；校验失败时重试或转人工。模型只是处理链路中的一个组件，不能替代数据质量检查。
去重：先便宜后精确
去重最好分两级。
第一级是文本指纹。对标题和正文做规范化后生成 SimHash 或其他指纹，能够快速拦截镜像、转载和重复抓取。它适合判断“文本是否高度相似”，但不能可靠判断两篇不同媒体对同一事件的改写。
第二级是语义去重。将标题、摘要或正文的关键段落转换为 embedding，保存到 PostgreSQL 的 pgvector 列中，再用余弦距离或内积查询近邻。Supabase 的官方文档将 pgvector 用于存储 embedding 和向量相似度检索，并支持在数据库中创建向量索引。使用 Supabase 时，需要在数据库扩展中启用 vector，而不是把它当成一个独立的外部数据库。
相似度阈值不应直接照搬别人的配置。不同 embedding 模型、文本长度和数据源都会改变分布。上线前应抽取一批“同一事件/不同事件”的样本，统计相似度，再选择阈值；同时保留人工复核入口，避免把重要的独立报道误合并。
数据库设计：把原文、结果和检索字段分开
最小表结构可以包括：
sources：来源名称、类型、地址、启用状态和抓取配置。articles：原始 URL、标题、正文、发布时间、抓取时间和内容哈希。article_summaries：摘要、标签、相关性判断、重要性分数和模型版本。article_embeddings：向量、embedding 模型和生成时间。crawl_runs：每轮任务的开始时间、结束时间、错误数和处理数。
把模型版本和提示词版本一起记录下来很重要。否则，当摘要质量变化时，很难判断是模型升级、提示词修改，还是数据源本身发生了变化。
如果使用 Supabase，除了启用 pgvector，还要注意数据库权限。Supabase 文档将 RLS（行级安全策略）作为客户端直连数据库时的重要安全机制；生产环境不应把高权限连接串放在前端，也不应把包含密钥的环境变量提交到仓库。向量查询同样要配合业务字段过滤，不能只依赖相似度排序。
部署与调度：先验证一轮，再长期运行
配置项建议全部放在环境变量或配置文件中，包括模型接口地址、密钥、数据库连接串、并发数、单轮最大文章数和保留天数。密钥只放在服务端，日志中也不要打印完整连接串或 API key。
第一次部署时，先只配置少量稳定来源，执行一次性任务，检查每篇内容最终被哪一步处理：规则过滤、模型判定、文本去重、语义去重，还是成功入库。确认数据质量后，再切换到定时模式。
调度器至少要具备三项能力：任务超时、失败重试和幂等。相同 URL 或内容哈希重复出现时，不应重复消耗模型额度；单个来源失败时，也不应阻塞其他来源。对于外部接口，还要设置并发上限和退避策略。
一套更稳妥的落地顺序
可以按下面的顺序迭代：
- 只接 RSS，完成抓取、规范化和数据库入库。
- 加入规则过滤与结构化摘要，并保留原文方便复核。
- 增加文本指纹去重，确认幂等和重试逻辑。
- 启用 pgvector，建立语义去重的评测样本。
- 再接入视频、社区和 GitHub 等需要专门采集器的来源。
- 最后增加管理界面、告警、权限和数据清理策略。
这类项目的核心不是“接入多少个源”，而是能否让每条数据都可追踪、可解释、可重跑。先用 PostgreSQL 和 pgvector 建立一条简单、透明的处理链路，再根据真实数据量决定是否拆出队列、独立向量服务或更复杂的检索系统，通常比一开始堆叠组件更容易维护。