自建AI资讯聚合平台：从RSS到智能摘要的完整实践

最近这一年我明显感觉AI相关的信息爆炸到了失控的程度。各种大模型发版、Agent框架更新、论文解读、工具推荐……每天打开X、公众号、TechCrunch光是把标题扫一遍就得花一两个小时更别说还得判断哪些值得细看。于是就有了自己动手搭一个AI资讯聚合平台的想法。这个平台不是简单地把RSS列表换成网页它要做的是一件更有价值的事自动抓取几十个信源用大模型做摘要和分类最后把真正值得读的内容呈现在一个简洁界面里。如果你也在做AI产品、搞技术研究或者只是每天被信息流淹没的普通爱好者这篇文章应该能给你一条清晰的路。1. 项目画像为什么非要自己搭一个AI资讯聚合平台1.1 核心需求不是爬虫而是“AI加工的信息管道”很多人一听“AI资讯聚合平台”第一反应就是写个爬虫抓新闻。但真正用起来你会发现抓取只占20%的工作量。难点在怎么把抓来的几百条噪音变成几十条值得读的内容。我的核心需求是这样的从几十个信息源自动抓取文章抽取干净正文用大模型生成摘要和标签按主题分类去重最后有一个能快速浏览和搜索的网页界面。说白了这就是一条信息管道上游接各种RSS和API中段做正文清洗和去重再交给AI做加工下游展示给用户。跟自来水厂处理水一个逻辑从源头引水、沉淀、过滤、消毒最后打开水龙头就是能直接喝的水。没有AI加工时RSS阅读器充其量只是一根“直通水管”水是浑的喝之前还得自己分辨。这个定位直接影响后续技术选型。如果你只需要“订阅一百个源然后按时间刷”那Feedly完全够用。但如果你要的是“只看和AI Agent相关的文章并且每篇配一个200字摘要和三个标签”那就必须把AI加工环节设计进去。而一旦AI进入管道数据源格式、文本清洗质量、调用成本、返回结构都得重新考虑。明确这个定位后我列了一个最低可用功能清单多源采集、干净正文抽取、AI摘要、自动标签、按标签筛选、关键词搜索、定时增量抓取。什么用户注册、点赞评论、推荐算法第一版全都不做。先跑通一条管道再谈锦上添花。1.2 适用场景与目标用户个人读报室还是团队情报站我搭这个平台的原始动机是个人使用每天早上一杯咖啡的时间用十五分钟扫完前一天全球AI领域值得看的20条内容。但做到一半我意识到这个框架稍微改改也能给团队用。比如给前端组配一个“前端资讯看板”给市场组配一个“竞品动态监控”只要调数据源和Prompt就能切换主题。目标用户定位清楚了技术复杂度就会收敛。如果只是我自己看架构上完全可以用SQLite Flask 单机cron不用上PostgreSQL和Kubernetes。如果是三五个人的小团队共享那需要加一个最简单的用户认证和只读分享链接解决“让同事也能打开”的问题。如果要做成开放的公共平台还得考虑恶意爬虫、内容版权、数据清洗复杂度直接翻倍。建议先把“个人使用”或“小团队共享”作为基准。不要一开始就想着做“AI资讯界的今日头条”那会陷入内容审核和商业模式的无底洞。我后来的做法是核心平台只服务自己和两三个信任的朋友每月把热门摘要生成一份邮件简报发给团队这样既不需要用户系统也能把情报价值传递出去。如果你也打算自建先回答三个问题给谁用用什么语言每天希望花多少时间维护这三个答案决定你是用纯Python脚本还是上完整Web应用。就我实测个人场景下一个脚本加一个网页已经能覆盖90%需求。1.3 跟现成工具比自己搭的优势到底在哪市面上不是没有AI读新闻工具Feedly都推出AI摘要功能了一些创业公司也在做“AI新闻聚合”。但具体用过你会发现大多是黑盒你不知道它为什么推荐这条、为什么不推荐那条数据源列表固定不可改摘要风格也不能调。对我这种把AI工程当乐趣的人来说最受不了的就是不可定制。自己搭的最大优势是完全可控。数据源我可以自己增删比如订阅arXiv的cs.AI分类、Hacker News的AI标签、几个核心公众号的镜像RSS、GitHub Trending里的机器学习项目想加就加。摘要Prompt我可以写成“用三句话讲清楚文章提出什么问题、用什么方法、结论是什么”而不是通用的“一句话概括”。分类也不是固定几个频道可以按需要动态生成。下表是我在做选型时整理的对比横向维度是内容采集、AI加工、数据所有权、定制程度和学习价值维度Feedly / Inoreader商业AI新闻App自己搭多源RSS订阅支持但源数量有限基本不支持自定义完全自定义AI摘要部分付费功能有但黑盒可自定义Prompt数据所有权不归你不归你全在本地数据库分类与标签手动标签为主固定频道动态生成标签技术学习无无全链路练手当然自己搭也有代价。最大的代价是维护成本RSS源会失效网页结构会改版AI接口会变更程序会出bug。但对我个人来说这些代价本身就是收获——每一次排查问题都在加深对爬虫、NLP和Web开发的理解。如果你希望得到一个开箱即用、零维护的工具那现成产品确实更省心。2. 技术选型与架构设计五个模块搭起整个平台2.1 数据源接入RSS优先、API为辅、爬虫兜底第一个模块是数据接入。我一开始以为要写一堆爬虫后来发现大部分目标站点都提供了RSS或Atom订阅。RSS是标准XML格式结构固定用feedparser十几行代码就能解析而且网站只要不改XML结构我这边就不用动。这比解析HTML稳定太多。数据源接入的优先级我定为RSS/Atom 官方API 网页爬虫。RSS典型代表Hacker News的RSS、arXiv的rss、各类博客的feed。API典型代表GitHub Trending没有官方RSS但有第三方API接口Hacker News的Algolia API可以按关键词搜最新文章。网页爬虫放在最后只针对那些确实没有feed、又实在想看的站比如某些资讯站只提供“最新”页面。这个顺序背后的逻辑是稳定性和维护成本。RSS和API的格式由站点自己维护我的解析逻辑几乎是静态的网页爬虫则要面对HTML结构调整、反爬验证、动态加载等问题每一样都能消耗大量时间。实测下来我80%的内容来自RSS和API爬虫只贡献几个特定源。实现时还得分清两种模式拉取和推送。RSS、API都是拉取定时去取新内容Webhook之类的是推送但个人平台基本用不到。拉取频率要克制我默认设置为每30分钟到1小时轮询一次重要源可提高到15分钟但别超过一分钟一次否则很容易触发站点限流。2.2 正文抽取与清洗Trafilatura和readability怎么选拿到RSS后我通常只能得到摘要和链接。想要高质量AI摘要就必须拿到文章正文所以正文抽取是第二关键模块。这个模块我推荐直接用现成库别自己写HTML解析规则。试过自己用BeautifulSoup去抠特定网站的正文一旦网站改版就是一场灾难。我首选Trafilatura这是一个学术界常用的正文抽取工具基于文本密度和结构特征做抽取能较好地识别正文内容并自动去掉导航、评论、分享按钮等噪音。它提供Python库可以将网页转为Markdown或纯文本还能抽取标题、日期、作者。实测对技术博客、开源文档、新闻站的效果都很好。readability-lxml是另一个选择它的思路是模拟“读者模式”使用DOM结构分数来寻找主内容。优势是轻量缺点是容易把相关文章列表当正文。我的方案是以Trafilatura为主一旦它返回的文本长度过短再降级用readability-lxml尝试一次。如果两个都失败就放弃正文只用RSS摘要入库。清洗环节容易被忽略。HTML里的特殊实体、控制字符、评论区的“楼中楼”、页脚的版权声明都会混进抽取结果。Trafilatura已经处理了一部分但还要自己做几件事把连续空行压缩为单个换行、去除明显的垃圾关键词行、将全角标点归一中便于后续AI处理。清洗质量直接决定后续摘要的准确度这一步值得花时间写规则。2.3 AI加工流水线摘要、标签、分类、去重一次搞定这是整个平台的心脏。我在设计时引入了“多AI协作”的思路把加工拆成摘要Agent、标签Agent、分类Agent、去重Agent四个角色。第一版其实没必要真的起四个进程而是用一个LLM API调用通过Prompt“扮演”四个角色让它在一次请求里返回结构化JSON效率和效果都不错。以一个3000字的技术文章为例我发给大模型的输入包括标题和正文Prompt要求输出三部分一是200字以内的摘要必须包含问题、方法、结论二是3到6个中英文标签三是判断文章主题类别可选类别包括“大模型”、“Agent”、“开发工具”、“学术论文”、“行业动态”、“AI绘画”等。并要求所有标签和类别严格按照JSON格式返回。这个设计的好处是一次往返就能拿到全部加工结果成本低且稳定。坏处是如果某个环节出错比如标签生成得特别差会连带其他结果一起不可用。所以我在代码里做了字段级容错能解析出哪个字段就用哪个字段实在解析失败就把整条文章标记为“待处理”下次定时任务再重试一次。去重放在AI加工之后反而更准。因为LLM可以理解“这篇文章虽然标题不同但本质是同一个模型的重复报道”。我用标题和正文各算一个SimHash再存到数据库里做比对同时让LLM也在JSON里返回一个“related_flag”字段专门标注是否与近期文章主题重复。两条路结合重复内容基本能被拦住。2.4 存储与检索SQLite起步向量检索跟上存储这层不用过度设计。我第一版用的SQLite一张表存文章一张表存数据源一张表存标签关系。SQLite的好处是零配置文件、单文件备份、在个人量级几千条到几万条文章下性能完全够用。等哪天文章到了几十万条再迁PostgreSQL也不晚。正文和摘要字段建议用TEXT类型另外一定要给URL建唯一索引这是天然去重键。抓取时先查URL是否已存在存在就跳过这样定时任务不会重复入库。再建一个published_at字段按时间排序后续首页展示都指望它。搜索方面SQLite自带FTS5全文搜索虽然不支持中文分词但可以通过把标签、摘要、标题拼在一起做全文索引来缓解。实际体验是全文检索能解决“我记得看过一篇讲prompt engineering的文章但忘了标题里有没有prompt”这类问题。向量检索我放在了第二阶段用Embedding模型把摘要向量化然后存到sqlite-vec里按照cosine距离做语义相似推荐。建议所有内容源抓取时都存一个raw_hash字段正文的SHA256用于精确去重。配合SimHash做近似去重数据质量会显著提升。备份也很简单定时用sqlite3 .backup命令复制一份数据库文件到另一个磁盘就算完成。2.5 前端展示最小可用界面和交互逻辑我不打算做成花哨的SPA前端第一版直接用Flask Jinja2服务端渲染样式用Tailwind CDN。页面就三个首页文章列表、文章详情页、按标签筛选页。首页每张卡片显示标题、来源、摘要、标签、发布时间点击卡片进入详情详情页展示AI生成的摘要和全文链接。这个选择主要是为了降低复杂度。服务端渲染不需要构建Node环境不需要API联调一个Python进程就能跑完整个应用。如果以后要做复杂交互比如拖动排序、实时推荐、无限滚动再引入前端框架也不迟。但第一版的核心目的是“能看、能筛、能搜”Jinja2足够。交互上我加了两个很实用的小功能“只看推荐标签”和“标记已读”。只看推荐标签通过URL参数实现比如 /?tagAgent已读功能在本地Cookie里存文章ID列表已读文章卡片降透明度。这种小功能上手成本低却能大幅提升日常使用体验。总之前端不是重点能把后端价值呈现出来就算成功。3. 实操过程从零开始搭建并跑通全流程3.1 环境准备Python虚拟环境和依赖清单我使用的环境是Python 3.11Ubuntu 22.04服务器内存1GB。先创建虚拟环境避免污染系统Pythonpython3 -m venv .venv source .venv/bin/activate然后写好requirements.txt一次性安装依赖。我的依赖清单如下feedparser requests trafilatura readability-lxml beautifulsoup4 lxml openai flask jinja2 apscheduler为什么不选Scrapy因为这个小项目只有二三十个数据源不需要分布式爬虫和中间件体系。Requests加循环完全够用代码反而更简单。Trafilatura内部依赖了lxml所以也要装。openai库负责调用大模型接口如果你用本地Ollama则不需要这个包换成requests调用本地HTTP接口即可。依赖装完后我先建了一个名为aggregator的项目目录下面分四个子模块collector负责抓取RSS和网页extractor负责正文抽取processor负责调用AI加工web负责Flask展示。这种目录划分虽然简单但能保证后续加功能时不混乱。3.2 采集器用feedparser和requests实现多源抓取采集器最核心的代码不长核心逻辑是遍历RSS源解析条目提取链接、标题、发布时间再交给下一层。我用一个list保存所有feed URL循环处理import feedparser import requests from time import sleep FEED_URLS [ https://hnrss.org/newest?qAI, https://arxiv.org/rss/cs.AI, https://www.jiqizhixin.com/rss, https://github.com/trending/ml?sinceweekly, ] def fetch_feed(feed_url): headers {User-Agent: Mozilla/5.0 (AI Aggregator/1.0)} resp requests.get(feed_url, headersheaders, timeout10) resp.raise_for_status() return feedparser.parse(resp.content) for url in FEED_URLS: try: feed fetch_feed(url) for entry in feed.entries: item { link: entry.link, title: entry.get(title, ), summary: entry.get(summary, ), published_at: entry.get(published_parsed), source_url: url, } save_to_pending_queue(item) except Exception as e: log_error(f{url} failed: {e}) sleep(2)这里的关键点是设置User-Agent和超时。很多站点对非浏览器Request会直接拒绝一个标准UA能解决大部分403问题。超时设为10秒防止某个慢服务把整个循环拖死。每次请求结束后sleep 2秒是保护源站的礼貌行为也能减少被限流概率。抓到的item先进入pending_queue下一步正文抽取消费。如果某个entry没有paywall或全文RSS自带的summary也可以作为降级内容。后来的经验是保存原始发布时间比保存抓取时间更重要因为RSS里可能有延迟发布的旧文章用published_at去重更合理。3.3 正文抽取Trafilatura参数调优与兜底逻辑正文抽取函数我封装成extract_main_text(article_url)核心逻辑是先用Trafilatura失败后用readability再不行就返回RSS摘要import trafilatura from readability import Document import requests def extract_main_text(url): headers {User-Agent: Mozilla/5.0} try: downloaded trafilatura.fetch_url(url, headersheaders) if downloaded: text trafilatura.extract( downloaded, output_formatmarkdown, include_commentsFalse, include_tablesTrue, favor_precisionTrue, ) if text and len(text) 200: return text html requests.get(url, headersheaders, timeout10).text doc Document(html) main_content doc.summary() text trafilatura.extract(main_content, output_formatmarkdown) if text and len(text) 200: return text except Exception as e: log_error(fextract failed {url}: {e}) return Nonefavor_precisionTrue告诉Trafilatura更看重精准度宁可少提取也不要夹带大量噪音。include_commentsFalse关闭评论区内容。include_tablesTrue保留表格技术文章里的对比表和信息表有时候比正文还重要。这里有个容易踩的坑有些网站返回的内容是JavaScript动态渲染的Trafilatura拿到的是空HTML骨架。这种页面靠requests解决不了我试过用Playwright无头浏览器去渲染但资源开销和编程复杂度都太高。最终我的原则是优先寻找这个站点的RSS源找不到就降低该站优先级不为一个源投入过多精力。3.4 AI摘要与分类Prompt设计、JSON输出、成本估算AI加工我用的是OpenAI的gpt-4o-mini模型性价比很高。对于普通技术文章调用一次摘要分类成本大约在0.002美元左右。如果每天新增500篇一天也就1美元完全在可接受范围。下面是核心Prompt设计from openai import OpenAI client OpenAI(api_keyYOUR_API_KEY) SYSTEM_PROMPT 你是一名资深AI技术编辑。请阅读下面的文章标题和正文完成任务 1. 用中文写一段200字以内的摘要包含文章解决的问题、核心方法和主要结论。 2. 给出3到6个标签中英文皆可。 3. 判断文章的主题类别从以下选一个大模型、AI Agent、开发工具、学术论文、行业动态、AI绘画、AI编程、其他。 4. 如果该文章与过去三天内的常见话题高度重复将duplicate设为true否则为false。 只返回JSON格式如下 {summary: ..., tags: [...], category: ..., duplicate: false} def process_with_llm(title, content): resp client.chat.completions.create( modelgpt-4o-mini, temperature0.2, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f标题{title}\n正文{content[:4000]}} ], ) return json.loads(resp.choices[0].message.content)注意我在正文中只截取前4000字符。原因是大部分文章的关键信息在前半部分而且可以控制Token成本。response_format设为json_object可以强制返回JSON省去字符串解析的麻烦。temperature设为0.2让输出更稳定不会每次生成不同标签。如果你不想调用云API想完全本地跑可以用Ollama加载Qwen2.5 7B。本地模型的优势是免费和隐私但速度慢摘要质量也略逊一筹。我在备用服务器上跑过一个版本对一个800字的文章约需3到5秒对个人非实时需求也能接受。选云API还是本地模型核心看预算和数据隐私要求。3.5 Web展示Flask服务端渲染和筛选功能Flask端的路由非常简单我维护了两个核心页面。首页从数据库读取最近两天、非duplicate的文章每篇显示标题、来源、摘要和标签。详情页展示完整摘要并附原文链接和标签链接。用Jinja2模板渲染Markdown需要加一个markdown过滤器import markdown from flask import Flask, render_template, request import sqlite3 app Flask(__name__) def query_articles(tagNone, limit50): conn sqlite3.connect(aggregator.db) conn.row_factory sqlite3.Row sql SELECT * FROM articles WHERE duplicate0 params [] if tag: sql AND tags LIKE ? params.append(f%{tag}%) sql ORDER BY published_at DESC LIMIT ? params.append(limit) rows conn.execute(sql, params).fetchall() conn.close() return rows app.route(/) def index(): tag request.args.get(tag) articles query_articles(tagtag) return render_template(index.html, articlesarticles, current_tagtag) app.route(/article/int:article_id) def detail(article_id): conn sqlite3.connect(aggregator.db) conn.row_factory sqlite3.Row row conn.execute(SELECT * FROM articles WHERE id?, (article_id,)).fetchone() conn.close() if row: row dict(row) row[content_html] markdown.markdown(row[content]) return render_template(detail.html, articlerow)这里用LIKE模糊查询标签是一个取巧办法标签是逗号分隔的字符串匹配简单但不精确。等文章量多了建议拆成article_tags关联表再用JOIN查询。首页模板里我加了“只看已经AI摘要过的”开关这样还没被LLM处理的新文章不会混在阅读列表里体验更好。如果你没有服务器本地跑这套Flask应用用flask --app app run --host0.0.0.0 --port8000就起来了。npm装Vue这套完全没必要。3.6 定时更新APScheduler和增量抓取为了保持平台“活”着必须有定时任务。我用APScheduler在进程内启动一个后台调度器每30分钟扫描一次所有数据源。启动时放在Web应用的同一条数据管道里避免另外一个cron进程重复执行。from apscheduler.schedulers.background import BackgroundScheduler scheduler BackgroundScheduler() scheduler.add_job(run_pipeline, interval, minutes30, coalesceTrue, max_instances1) scheduler.start()coalesceTrue的意思是如果上次任务还没跑完新任务不会排队挤着执行max_instances1保证同一时刻只有一个采集任务在跑。这两个参数很重要避免定时任务重叠导致数据库出现重复数据或者请求风暴。增量抓取的本质是数据库天然的去重。我插入文章前先查一下URL是否已存在存在就跳过。即使RSS返回了历史内容存储层也会拦截。对于已存在的文章我还更新一下“最近看见时间”方便以后统计哪个源活跃度高、哪个源在长期重复内容。4. 常见问题与排查技巧实录4.1 采集频率过高导致IP被封怎么缓解我在第一次上线时把所有源都设成了5分钟抓一次结果不到半天就被几个技术网站返回403。随后我把默认抓取间隔调到了30分钟并对每个源配置了独立的最小间隔值。心法就一条尊重源站像人一样读网页而不是像机器一样轰炸。具体措施包括Requests会话里带上常见浏览器的Accept-Language头每次请求之间sleep随机1到3秒遇到429响应时先停止该源的抓取等待至少10分钟再重试重试次数限制在3次以内超过就标记为“源暂不可用”等下次周期再试。这些措施看起来微不足道却能有效降低被封概率。如果已经被封最常见的是持续403。我的排查步骤是先看返回的请求头是否包含完整UA再查源网站是否有robots.txt限制最后检查自己的抓取频率。不要急着改IP去绕过限制那既不稳定也不合规正确的做法是降低抓取频率并等待封禁自动解除。尊重robots.txt不只是礼貌问题也是降低平台风险的关键。4.2 正文抽取为空、乱码、抓到广告的解决方法正文抽取为空通常有三个原因。第一是页面需要JavaScript渲染Trafilatura拿不到内容第二是网站使用了反爬验证码第三是RSS里的链接本身就不是文章页而是列表页。我的排查策略是先手动打开浏览器访问该URL确认页面内容正常再在代码里打印response的源码长度判断到底有没有拿到完整HTML。乱码问题多半是编码识别出错。不要相信某些网站报的charset正确的处理是用requests的resp.apparent_encoding识别实际编码再交给Trafilatura。如果正文里混入了大量广告和推荐文章常见原因是Trafilatura用了favor_recallTrue模式更全但噪音多解决办法是改回favor_precisionTrue。我还遇到过Trafilatura把文章的下一篇推荐列表当成正文的情况原因是页面结构里推荐内容的文本密度太高。解决方法是手动给Trafilatura传入一些排除CSS类名例如exclude_commentsTrue并在清洗阶段过滤掉“相关阅读”、“推荐阅读”、“最新文章”这些固定词。这种问题没有一劳永逸的方案只能持续积累规则。4.3 AI接口超时和成本失控如何控制AI接口超时很容易遇到尤其当摘要任务排队变多时。我在调用OpenAI时设置了timeout30并在外层用tenacity库做重试最多两次。如果两次都超时就把这条文章标记为“AI处理失败”丢回队列底部等下次任务再试。这样不会因为一次网络抖动丢掉内容。成本控制是我的重点。我设了一个每日预算计数器每次调用前检查累计Token消耗是否超过阈值。如果接近阈值后续文章就只打标签不写摘要或者完全跳过。此外我对文章先做一次关键词价值过滤比如包含“release notes”“开源”“论文”的才调用AI纯软件发布简报这类低信息量内容直接走规则标签不浪费Token。还有一个很有效的省钱技巧缓存。如果标题和正文的哈希值在库里已经存在就直接复用上次的摘要结果不再调用模型。对多个RSS源报道同一篇论文、同一个发布会的情况这个缓存机制能省下至少20%的API费用。如果你用本地模型成本问题会简单很多但时间成本要心里有数。4.4 重复内容、水帖和低质文章怎么过滤重复内容不只是完全一样的转载还有改标题、改几个段落的伪原创。我采用两层过滤第一层存正文SHA256完全一样直接丢弃第二层用SimHash计算正文指纹汉明距离小于阈值的视为近似重复保留发布时间最早的那篇。这条规则对“某模型发布后十几个号同时发体验”的场景非常有效。水帖的典型特征是标题夸张、正文信息密度低、结论空泛。这类文章人工一眼就能看出但规则不好定义。我的做法是让AI在返回JSON时增加一个字段quality_score从0到10给文章打分。低于5分的文章自动降低展示权重。实测下来LLM给出的分数和我的主观判断一致性超过八成但依然不能完全替代人工判断。设置一个“垃圾词黑名单”也很有效。比如“震惊”“必看”“千万不要错过”“重磅”“白嫖”这些词出现在标题中直接降权或拦截。虽然会误伤个别正常文章但对“宁缺毋滥”的资讯聚合场景来说误伤是完全可以接受的。4.5 关键词搜索和语义推荐怎么实现关键词搜索我第一版用SQLite FTS5。建一张虚拟表索引标题、摘要、标签字段然后用MATCH语法查询。虽然FTS5对中文不友好但标签字段是中英混合实际搜索体验尚可。代码示例CREATE VIRTUAL TABLE articles_fts USING fts5(title, summary, tags); SELECT a.* FROM articles_fts f JOIN articles a ON a.id f.rowid WHERE articles_fts MATCH ? ORDER BY a.published_at DESC;语义推荐是第二阶段的功能。我给每篇文章的摘要生成一个Embedding向量存到一个单独的表里然后对当前文章向量做余弦相似度搜索取Top10作为“相关阅读”。向量库初期可以直接用numpy计算几千条文章性能毫无压力。等到过万条再引入sqlite-vec或者干脆外部向量库。个人使用场景这个级别已经足够。搜索和推荐的关键是“索引先行”。我建议在文章入库那一刻就同时生成摘要向量和全文索引条目不要等搜索时才临时算。这样首页加载和搜索响应都能保持在毫秒级。每次AI摘要更新后记得同步更新对应向量否则搜出来的可能是旧理解。5. 维护这套系统最值得注意的三件事跑了大半年踩过的坑不少但最值得提醒后来人的只有三件事。第一数据源质量决定平台天花板。我最初加了六十多个源每天抓回来五百篇里面一半是SEO垃圾AI摘要做得再好也救不回来。后来删到二十个精挑细选的源信息密度反而大幅提升。不要沉迷于“源数量多”而是要关注“好内容占比”。第二Prompt要持续迭代别指望一次写对。我最初的摘要Prompt是“给这篇文章写个摘要”生成结果简直像复读机。后来改成带角色、带输出格式、带类别的结构化Prompt质量才稳定下来。每隔一两周我会翻一翻最近生成的摘要把明显不好的样本收集起来反向调整Prompt。这个小循环是平台质量的关键。第三不是所有文章都值得AI加工。现在很多内容本质上就是官方公告的复读和拼贴让大模型为它们写摘要纯属浪费钱和时间。我现在在调用AI之前先做规则层过滤标题含特定关键词、正文过长或过短、来源权重低都先跳过。只有通过基础门槛的内容才进入AI加工队列这既省成本又提升结果纯度。这套系统现在还在我服务器上每天默默跑着每天早上七点推送前一天的20条AI精选摘要给我。我最有价值的感受不是“省了刷手机时间”而是把一个模糊想法拆成了采集、清洗、加工、存储、展示五个清晰模块每个模块都能用最朴素的工具解决。下一步我准备把每天生成的摘要再喂给一个Agent让它自动抓出趋势曲线做成周报。这个方向应该能让我这个信息管道更自动真正做到从聚合到洞察。