信息过载这件事搞技术的人感受最深。每天打开手机几十个公众号、十几个技术社区推荐算法再插一脚真正能进脑子、能指导决策的内容可能就三五条。做了两年多的 AI 资讯聚合平台我的核心体会是与其被别人的算法安排得明明白白不如自己动手把信息源掌握在手里。这篇文章完整记录了我从零搭建一个 AI 资讯聚合平台的全过程——从数据源接入、SimHash 去重到大模型摘要分类、搜索推荐、部署上线每个环节怎么选型、怎么实现、成本怎么控以及踩过的坑我都会摊开来讲。如果你正在做 AI Agent、AI 应用开发或者想给自己团队搭一套内部情报系统这篇内容应该能帮你省掉几个星期的试错时间。我不会只给结论会讲清楚每个选择背后的为什么。1. 为什么偏偏要自己搭现成方案与自建的取舍先聊点实在的。很多人第一反应是市面上海外的 Feedly、Inoreader国内的各种资讯 App 已经很成熟了为什么还要自己造轮子1.1 现成资讯产品的共性短板现成产品最大的问题不是功能不全而是三件事你控制不了数据源控制权、处理逻辑、以及隐私边界。算法黑箱是第一个坎。你订阅了 50 个源平台给你推什么实际是它的商业化排序决定的——带广告的、带外链的、平台想扶持的内容会天然靠前。我做技术调研的时候经常发现真正重要的论文和开源项目发布反而被大量营销稿淹没。第二个问题是延迟和覆盖度。垂直领域的优质信源比如 arXiv 的 AI 板块更新、GitHub Trending、特定团队的技术博客很多聚合产品要么接入不全要么抓取延迟高达数小时。对 AI 资讯来说延迟就是价值一个模型发布晚两个小时热点就已经过去了。第三个是隐私。做内部情报系统的时候团队关注的技术方向、竞品动态、内部标注这些数据放在第三方平台上始终有顾虑。基于这些原因自建的第一性目的是拿回控制权我自己决定抓什么、怎么排、给谁看。1.2 自建平台的真实收益与隐藏成本收益其实很清楚数据归你逻辑归你还能把大模型的摘要、分类能力做成自己的工作流。但自建并不适合所有人我建议你先冷静评估隐藏成本。采集层维护成本网站改版、接口限流、RSS 地址失效这些都是长期支出大模型 API 费用每篇文章都要过一遍摘要和分类token 消耗比想象中大服务器和运维成本数据库、定时任务、监控告警至少需要一台长期运行的云主机我的建议是如果只是个人看资讯先别急着做完整平台一个 Python 脚本加一个输出页面就够了。如果你有明确的场景——比如给团队做内部 AI 情报站、给垂直领域做内容监控、或者想做一个对外展示的独立站点那自建就是划算的。1.3 平台核心定位到底汇聚什么、给谁用动工之前必须先回答一个问题这个聚合平台的核心价值是什么我自己的定位是AI 领域从业者的每日信息入口。以此倒推信息源就该围绕 AI 大模型基础理论、工程实践、开源项目、产品发布这几个方向去选。不是什么都抓而是有明确边界。平台解决的核心痛点有三层一是把分散在几十个渠道的信息集中到一处二是用去重算法把重复内容过滤掉三是在尽量短的时间内让读者只花 3 分钟就能知道今天 AI 圈发生了什么、哪些值得细读。目标用户也很清晰算法工程师、AI 应用开发者、技术管理者。这个定位直接影响后面的所有决策——比如摘要要保留技术细节而不是泛泛而谈排序要强调时效性和信源权重UI 结构要能扫读。2. 整体架构设计从一个信息流到一个知识库定位确定之后架构设计就顺理成章了。我见过很多人一上来就写代码结果后面反复重构。建议你先在脑子里把一条数据从源头到页面的完整链路走通。2.1 一条数据从源头到页面的完整链路以我这套系统为例完整链路是这样的数据源RSS/API/网页 → 采集任务 → 原始库 → 清洗去重 → AI 处理队列 → 结构化标签库 → 检索/推荐引擎 → 前端页面 → 用户阅读行为回流每一步都有明确职责。采集层只负责把内容拿回来存到原始表不做任何加工AI 处理层负责摘要、分类、打分产出结构化的元信息服务层负责对外提供检索和排序接口展示层只关心怎么把信息密度做高。这个链路里最容易犯的错误是让采集层承担太多逻辑。比如有人直接在爬虫里调大模型做摘要一旦 API 超时整个采集任务就卡住了。我的做法是把各层彻底解耦采集只写库AI 处理通过队列异步消费两者互不阻塞。2.2 技术选型逻辑为什么是 Python FastAPI PostgreSQL技术栈没有绝对最优只有适不适合。我这套用的是 Python FastAPI PostgreSQLpgvector Redis Vue整体是典型的轻量级单体加异步任务模式。选 Python 的原因很直接采集和 AI 处理生态最成熟。feedparser 解析 RSS、BeautifulSoup 做网页解析、HuggingFace 生态做 embeddings、LangChain 和大模型 SDK 基本都是 Python 优先。FastAPI 则是当前异步 API 的首选性能足够文档自动生成配合 Pydantic 做数据校验很舒服。数据库选 PostgreSQL 加 pgvector 扩展是因为既要存结构化元数据又要存向量做语义检索。用一套库就省去了维护 ES 和关系库两套系统的成本。数据量在十万篇量级时pgvector 的 ANN 索引性能完全够用。Redis 用来做任务队列和缓存主要承接采集去重状态和前端热点榜单。如果你预算极其有限也可以把 pgvector 换成 SQLite 加一个 JSON 字段先跑起来但后续迭代会比较痛苦我还是建议一步到位。2.3 模块划分与数据模型设计核心表我设计得比较克制刚开始别搞太复杂。以下是最基本的三张表够用且容易理解sources数据源表id、名称、feed_url、网站类型、抓取频率、状态、最后抓取时间、ETagarticles文章表id、source_id、标题、链接、作者、正文快照、MD5 指纹、SimHash 值、发布时间、抓取时间、AI 摘要、质量评分、是否重复article_tags文章标签表id、article_id、tag_name、置信度这三张表已经能支撑核心流程。后续要加用户体系和阅读行为再扩展 users、read_history 表即可。我特别提醒一点给 articles 表的 url 加唯一索引这是防重复的第一道防线比程序里判断快得多。3. 采集层的三个核心环节抓取、去重、打标采集层是整个平台的地基。地基不稳上面的大模型再聪明也白搭。这一节我把抓取、去重、质量打标三个环节逐个拆开讲。3.1 数据源接入RSS、API 与定向抓取的取舍数据源接入有三种主流方式各有各的适用场景。RSS 是最省力的方式适合绝大多数博客和技术媒体。主流框架如 Hexo、WordPress、Medium 都原生支持 RSS稳定且友好。我这边大概六成内容来自 RSS用 feedparser 解析即可。需要注意的一点是很多源会给出全文有些只给摘要这会影响后续摘要生成的质量需要在接入时做标记。官方 API 适合有开放接口的平台比如 GitHub Trending API、Hacker News API、arXiv API。这类接口结构化程度高但会有速率限制必须做抓取间隔控制。Hacker News API 我实测可以请求得很频繁但 GitHub 的 API 有每小时 60 次的基础限流需要配合 ETag 和条件请求来省额度。定向抓取是兜底方案针对那些没有 RSS 也没有 API、但内容价值极高的站点。用 requests 加 BeautifulSoup 写解析逻辑即可。这里有个容易被忽略的点写爬虫前先用浏览器开发者工具看下页面是服务端渲染还是客户端渲染。如果是客户端渲染直接抓 HTML 只能拿到空壳得改用无头浏览器成本会明显上升。我的建议是能用 RSS 的绝不爬网页能用官方 API 的绝不自己解析 HTML。抓取方式的优先级直接决定长期维护成本。3.2 去重实战SimHash 怎么用、阈值怎么定资讯聚合最烦人的问题就是重复。同一个新闻十个公众号发十遍光靠 URL 和标题判重远远不够——很多网站转载时改个标题或者加一段导语标题就完全不一样了。我的方案是两套防线第一道是标题的归一化 MD5第二道是正文的 SimHash 相似度。SimHash 的核心思路是把一段文本压缩成一个 64 位的指纹然后通过比较汉明距离判断相似度。它的优势在于对文本的局部改动不敏感很适合识别“改标题、加导语”的转载文章。简单实现如下import jieba from simhash import Simhash def text_simhash(text: str) - int: # 先用 jieba 分词再把词序列交给 simhash 生成 64 位指纹 tokens jieba.lcut(text) return Simhash(tokens).value def hamming_distance(hash1: int, hash2: int) - int: x (hash1 ^ hash2) ((1 64) - 1) dist 0 while x: dist 1 x x - 1 return dist阈值怎么定我跑过一段时间的真实数据结论是汉明距离小于等于 3 基本可以判定为重复小于等于 5 大概率是高度相似。如果你的信息源转载关系复杂可以把小于等于 5 的结果先标记成“疑似重复”进入人工确认队列而不是直接删。这个经验值建议你也拿自己的数据跑一遍再定不同领域的文本长度和词汇分布差异很大。实际工程中别每次都全文比对那是 O(n²) 复杂度。正确做法是先按日期分桶只比当天的候选文章再结合标题归一化快速排除。这样量级就能从几万降到几百。3.3 质量评价为什么单纯靠时间排序是错的很多聚合平台默认按发布时间倒序排这是最大的认知误区。发布时间新不等于值得看。一个三流博客的长篇水文在发布时间上可能碾压当天的重磅论文反过来一篇深度分析可能发布三小时后才值得被置顶。我的做法是给每篇文章算一个质量分公式大致如下quality_score 信源权重 × 0.4 内容完整度 × 0.2 时效新鲜度 × 0.2 大模型价值判断 × 0.2信源权重靠历史经验累积被点击多、收藏多、被长文引用的源权重高。内容完整度看正文长度、图片数、是否有代码块等硬指标。时效新鲜度不是简单的“越新分越高”而是结合主题热度的衰减曲线。价值判断则交给大模型让它评估这篇文章对 AI 从业者的信息增益。这个打分方案一开始不需要做得太精细先跑起来拿到读者行为数据之后再迭代。打分逻辑的价值在于它让平台从“展示最新”进化为“展示最重要”这是聚合平台和普通新闻列表的核心区别。4. 让 AI 介入内容处理从摘要到分类的任务拆分这一节是平台的重头戏也是目前 AI 相关的热搜词里讨论最密集的部分——AI Agent、多 AI 协作、大模型应用全都在这里体现了。我的整体思路不是把所有事交给一个 Prompt 做完而是拆成多个专项任务让不同模型各司其职。4.1 多 AI 协作一个 Agent 编排器还是多个独立调用你在热词里看到的“AI Agent 搭建”、“多 AI 协作”在资讯聚合这个场景里非常落地。这里有两种路线一种是搭一个 Agent 编排器让 LLM 自主决定调哪些工具。好处是灵活但坏处是不可控和贵——如果让模型自由决定动作很容易出现重复调用、链式幻觉、token 翻倍的情况。对于资讯处理这种流程固定的场景我强烈不推荐纯自由编排。另一种是我最终采用的方案预定义流水线每个环节调用专用模型。分三个独立任务摘要生成任务用中等规模模型如 DeepSeek 或 GPT-4o-mini 级别一次调用产出结构化摘要分类和标签任务用小模型加 few-shot 示例做分类价值等级判断任务让模型输出高、中、低三档加理由三个任务可以并行调用互不依赖某一步失败只影响该步骤不会拖垮整条链路。这正是多 AI 协作的正确姿势不是所有模型塞进一个 Agent 里互相聊天而是各自做擅长的子任务用代码编排协作。4.2 摘要生成与 Token 成本控制怎么给大模型“减负”AI 生成摘要的效率和成本关键在于输入减负。很多人直接把整篇正文丢给大模型动辄五六千 token一篇的成本是别人的十倍。数据表明中文文本大约 1 个汉字对应 1 到 1.5 个 token。一篇 5000 字的行业文章正文就接近 7000 token。如果全部喂给模型即使产出只有 200 token输入成本也占了大头。我的策略是三层减负截断策略只取正文前 2000 字加上标题和关键段落因为新闻资讯的关键信息通常在前部结构化提取正文里已有的加粗句、小标题、列表优先保留这些往往是文章骨架输出约束用 JSON Schema 约束输出格式避免模型生成无关内容给一个我实际在用的 Prompt 模板你直接抄就能用你是一名 AI 行业资讯编辑。请对下面的文章做三件事 1. 用不超过 80 字概括核心信息保留时间、主体、关键数据 2. 提取 3 个主题标签必须是具体名词如“多模态模型”、“Agent 框架” 3. 判断这篇内容对 AI 从业者的价值等级高 / 中 / 低并给出一句话理由 只输出 JSON {summary: , tags: [], value_level: , reason: } 文章标题{title} 文章正文截断到 2000 字{content}成本细算一下假设一天处理 200 篇文章每篇输入约 2500 token、输出约 250 token调用一次的费用在主流中等模型上约 0.003 元到 0.01 元一天不到 2 元。一个月控制在 50 元左右。这个量级完全可接受。如果你的信息源暴增到每天上千篇再考虑用小模型先粗筛、大模型只处理高分文章的两级策略。4.3 自动分类与关键词抽取的 Prompt 设计分类标签的质量决定平台的信息架构。这里的难点不是让模型识别“这个文章讲什么”而是让模型输出符合你预定义体系的标签。否则今天输出“大模型”、明天输出“LLM”同一主题就分裂了。我的做法是在 Prompt 里给出一份固定标签体系列表让模型只能从中选取。体系大方向如下基础理论、模型发布、开源项目、工程实践、产品应用、商业动态、学术论文外加一个“其他”兜底。每个标签配两三个示例few-shot 能让准确率显著提升。同时要求模型输出置信度低于 0.6 的标签直接丢弃。这一步做完后续的个性化推荐和主题页聚合就有数据基础了。顺便说一句现在热词里提到的“AI 编程提示词”“AI 测试”在我这个项目里也在用——我自己会用大模型帮我写解析器单元测试、生成爬虫的边界用例尤其针对 RSS 字段缺失、编码异常这些情况。这属于用 AI 开发 AI 平台的典型实践极大的提升了迭代效率。5. 搜索与个性化推荐不止是展示列表做聚合平台只做一个按时间排序的列表是没有灵魂的。搜索和推荐才是把“信息流”升级为“知识库”的关键。这一节分享我的混合检索方案和冷启动经验。5.1 关键词检索与向量检索的混合排序用户搜“Agent 并发架构”如果只用数据库 LIKE 查询只能匹配到标题里同时含这几个词的文章语义相关的讨论就被漏掉了。我给平台加了混合检索BM25 关键词检索 pgvector 向量语义检索。BM25 由 PostgreSQL 内置的全文检索实现适合精确词匹配向量检索用 OpenAI 或 BGE 等 Embedding 模型把文章摘要转成向量适合语义匹配。两者结果用 RRFReciprocal Rank Fusion算法融合每个文档的融合得分 1 / (k 关键词排名) 1 / (k 向量排名)其中 k 一般取 60。这个方法的优点是无需调权重排名稳定工程实现简单。混合检索加上之后用户搜“大模型训练技巧”时不再只返回标题匹配的结果很多正文讨论了这个主题的文章也能被召回。向量维度和存储也不用担心文章量在十万级时 pgvector 完全可以顶住IVFFlat 索引建好后单次查询在几十毫秒级别。5.2 冷启动没有用户行为数据怎么做个性化个性化推荐的最大难题是冷启动——新平台没有用户点击、点赞数据协同过滤无从谈起。我的方案是两条腿走路。第一条是内容画像。基于标签体系给每篇文章打上多维标签再结合信源偏好、阅读时长预估构造一个“准个性化”排序。比如一个用户经常点开“Agent 框架”标签的文章系统就在他的信息流里提高该标签内容的权重。这不需要用户注册也能隐式完成。第二条是主题订阅。让用户主动选择关注的主题比如“AIGC 应用”“AI 编程工具”系统按主题聚合文章。这是最简单有效的个性化而且用户预期明确不会像算法推荐那样让人摸不着头脑。我实测下来主题订阅的满意度比纯算法个性化更高因为用户自己选的阈值最准确。5.3 聚合页的交互设计一屏信息密度的取舍聚合平台的 UI 设计和普通内容站很不一样核心目标只有一个一屏内让用户完成“扫读 跳转”动作。我的首页信息结构是这样的左侧是主题导航栏中间是文章列表右侧是热点关键词和今日必读。中间列表每项展示标题、来源站点、发布时间、AI 摘要前两行、标签不展示全文。设计原则是摘要只负责告诉用户“这篇文章值不值得点”而不是替代正文。这里有个技巧摘要生成的时候刻意让它保留信息缺口比如不给出最终结论引导用户点击原文。移动端适配是另一个重点。我统计过超过六成访问来自手机所以卡片宽度、字体大小、触摸目标都要单独调。PWA 方案值得考虑可以把平台加到手机桌面体验接近原生应用但开发成本很低。6. 部署上线与成本核算小流量也能稳定跑开发完成不代表结束把平台稳定跑起来并控制好成本才是长期主义。这一节给出一份可以直接照抄的部署清单和成本拆解。6.1 服务器配置与容器化部署清单一台 2 核 4G 的云主机足够支撑个人或小团队使用国内主流云厂商的新用户优惠机即可一年成本大概在几百元量级。如果你是技术负责人想把平台作为团队内部系统建议上 4 核 8G并开启定期快照备份。部署我用 Docker Compose 管理一套文件把数据库、后端、前端全部编排起来。核心配置文件大致如下version: 3.8 services: db: image: pgvector/pgvector:pg16 environment: POSTGRES_DB: agg POSTGRES_USER: agg POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U agg] interval: 10s api: build: ./backend environment: DATABASE_URL: postgresql://agg:${DB_PASSWORD}db/agg REDIS_URL: redis://redis:6379/0 depends_on: db: condition: service_healthy redis: condition: service_healthy ports: - 8000:8000 redis: image: redis:7-alpine web: build: ./frontend ports: - 80:80 depends_on: - api volumes: pgdata:部署顺序建议是先启动数据库和 Redis再启动后端最后启动前端。用 Docker Compose 的 healthcheck 机制可以避免后端在数据库就绪前连接失败。如果考虑 HTTPS用 Caddy 比 Nginx 更省心它会自动申请和续期证书配置只需要一行域名。6.2 定时任务的调度细节与失败重试采集是典型的定时任务。我用的是 Python 的 APScheduler部署在 API 服务内部独立运行三个调度器采集调度器每 30 分钟跑一轮拉取所有源的增量内容AI 处理调度器每 15 分钟检查一次待处理队列批量调用大模型清理调度器每天凌晨清理过期缓存、重建索引、发送日报摘要一个很容易踩的坑是采集任务重试机制。网络抖动、对方服务器 5xx、反爬限制都会导致抓取失败。我的策略是单次失败不重试而是把任务放回队列等下一轮调度统一处理连续失败超过 3 次的源自动标记为“异常状态”并通过邮件或飞书机器人告警。日志里记录失败原因和耗时方便排查。另外强调一点所有定时任务都要加锁避免多实例部署时重复调度。APScheduler 本身不支持分布式锁我用 Redis 的 SETNX 实现了一个简单锁实测够用。6.3 月度成本拆解与优化点按每天处理 200 篇文章、500 个独立访客的规模月度成本大致如下项目费用说明云主机约 60 元2核4G包年更便宜域名约 5 元备案域名或非备案域名均可大模型 API约 30 元日均 200 篇摘要分类用中等模型对象存储约 10 元用于存抓取快照和备份合计约 105 元不含人工成本如果想压缩开支最大的优化点是 API 费用。我后来加了一级缓存同一主题、同一来源的文章在 24 小时内不重复调用大模型直接用缓存结果。另一个优化是用便宜的小模型做粗筛分类只有价值等级达到“高”的文章才走完整摘要流程。这样 API 成本可以再降三分之一。7. 踩坑实录我实际遇到的问题与排查过程任何系统都是跑出来的不是设计出来的。这一节全是我真实的踩坑记录价值可能比前面所有内容都高。7.1 数据源结构的隐性变化与解析器脆弱性最烦人的坑是隐性结构变化。一个技术博客某天悄悄改了 HTML 结构class 名从article-content改成post-content我的解析器就静默失败一条新内容都抓不到但老的缓存还在页面看起来一切正常。等我发现的时候已经落后了整整三天。教训两条第一所有解析器必须有空结果告警连续两次抓取零新增就触发通知第二对每个数据源定期做健康检查不只是看 HTTP 状态码还要验证解析结果里是否包含预期字段。后来我给采集系统加了一个“内容结构签名”机制首次抓取时记录标题、正文、作者所在的 DOM 路径后续比对路径是否一致不一致就标记为“页面结构疑似变更”。7.2 大模型接口超时与并发限流的问题AI 处理刚开始上线时我天真地对每篇文章同步调用大模型接口结果高峰期直接把 API 限流打满一堆任务超时失败。这属于没有理解大模型 API 的并发配额模型——它不看你每秒请求多猛而是看你每分钟消耗的 token 总量。解决方案是引入令牌桶限流和批量模式。把待处理的文章按批次合并每批只发一个请求要求模型输出 JSON 数组同时用信号量控制并发数实测将并发压到 5单批 20 篇既不会触发限流整体吞吐反而更高。超时重试也很有讲究连接超时设 10 秒读超时设 60 秒失败任务最多重试 2 次超过就进死信队列人工处理。7.3 数据回填与去重策略导致的索引膨胀上线一个月后我发现 PostgreSQL 的 articles 表体积涨得很快查询也越来越慢。分析后发现两个原因一是抓取了大量正文快照一个 5000 字的正文能占几十 KB二是 SimHash 字段没建索引全表扫描做重复检测。优化方案正文快照单独存一张表articles 主表只保留前 500 字预览这样列表查询速度大幅提升SimHash 索引虽然有歧义性但配合日期分桶已经够用再给 fetched_at 建好普通索引。另外pgvector 的向量列单独放在附属表避免主表膨胀拖慢基础查询。7.4 AI 资讯聚合平台常见问题速查表现象可能原因解决方案某个源长时间无新内容网站改版或反爬拦截检查健康检查日志用浏览器模拟访问确认大模型摘要风格不稳定Prompt 约束不足增加输出格式约束加入两个正反例搜索结果重复率偏高去重只在入库时执行查询入口增加一次轻量 SimHash 过滤首页加载缓慢查询未走索引用 EXPLAIN 分析慢查询补建复合索引凌晨采集高峰期 CPU 飙高抓取任务全并发运行用协程信号量控制并发数限制在 10 以内顺便提一句现在 AI 编程工具的代码生成能力已经很强了我在开发这个平台时大量使用了 AI 辅助编程从解析器骨架到前端组件都让模型生成初版再人工修改。但有一点必须强调AI 生成的代码测试要自己补齐。尤其是爬虫解析和日期处理这些边界条件极多的地方不能依赖 AI 的乐观假设。这类代码我建议配好单元测试再上线上线前记得跑一遍回归。最后分享一点个人体会搭完这个平台后我最大的感受是真正值钱的不在页面有多好看而在于你积累了一份干净、结构化、不断沉淀的数据资产。这个数据资产可以直接用来做周报、做竞品分析、训练垂直模型甚至自动生成每日早报推送到群里。我个人后续打算做两件事一是加入多模态资讯把 AI 短剧、AI 图片生成等视频和图像内容也纳入聚合范围二是把平台沉淀的高质量历史文章做成团队内部的 RAG 知识库让团队成员可以直接用对话方式查询历史情报。这个方向如果你想深入了解可以从混合检索那节再读一遍那是整个系统的基石。