1. 项目概述一个能“消化”信息的智能RSS阅读器如果你和我一样每天被海量的信息流淹没订阅了几十个RSS源但根本没时间一篇篇点开细读最后收藏夹里堆满了“稍后阅读”却再也没打开过的文章那么这个项目可能就是你的解药。FeedMe一个我最近深度使用并部署的智能RSS聚合器它解决的核心痛点非常直接用AI帮你“消化”信息把冗长的文章变成可快速浏览的摘要。这不是一个需要你注册账号、下载App的臃肿服务。它的本质是一个静态网站你可以零成本部署在GitHub Pages上或者用Docker跑在自己的服务器里。所有的数据——你订阅的RSS源、AI生成的摘要——都完全由你掌控。技术栈选用了当下前端开发里相当务实和现代的组合TypeScript保证代码质量React构建用户界面Tailwind CSS快速搞定样式再配上shadcn/ui这套高质量的组件库以及Vite带来的极速开发体验。整个项目的设计哲学就是“轻量、智能、为你定制”我实际用下来它确实做到了。2. 核心设计思路静态生成与AI处理的巧妙结合2.1 为何选择“静态网站定时更新”的架构很多RSS阅读器是动态的每次打开页面都去实时抓取源站内容。FeedMe走了另一条路预生成静态内容。这背后有几个非常实际的考量。首先性能与成本。静态文件可以被全球的CDN高效缓存用户打开页面的速度极快体验接近本地应用。对于个人使用或小团队来说部署在GitHub Pages、Vercel或阿里云ESA Pages这类服务上几乎是零成本的。如果每次访问都动态抓取和请求AI接口不仅速度慢API调用成本也会急剧上升。其次稳定性与可控性。RSS源站可能不稳定AI服务也可能偶尔抽风。通过GitHub Actions或Cron任务在后台定时执行抓取和摘要生成即使某次任务失败用户端看到的仍然是上一次成功生成的内容服务不会完全中断。你可以从容地查看日志、排查问题而不会让用户面对一个白屏或错误页面。最后隐私与所有权。你的订阅列表rss-config.js和生成后的摘要数据JSON文件都存放在你自己的仓库或服务器上。没有中间服务器存储你的阅读习惯数据主权清晰明了。2.2 AI摘要生成从“阅读”到“理解”的关键一跃RSS阅读器的核心价值是信息聚合但FeedMe通过引入大语言模型LLM将价值提升到了信息提纯。它不是在简单展示标题和简介而是试图让AI理解文章内容并提炼出核心要点。这个过程在scripts/update-feeds.js中完成。脚本会遍历你配置的所有RSS源抓取最新的条目。对于每一篇文章它会提取出标题、链接、发布时间和完整的正文内容这里通常需要借助rss-parser等库的能力来获取全文或摘要。然后构造一个特定的提示词Prompt将文章内容发送给你配置的LLM API例如硅基流动、OpenAI、DeepSeek等兼容OpenAI格式的接口。注意AI摘要的质量和成本很大程度上取决于你的Prompt设计和选择的模型。项目默认的Prompt是一个很好的起点它要求模型以简洁的列表形式总结要点。但你可以根据需求调整比如要求用中文总结、突出技术细节、或者评估文章的可信度等。模型方面轻量级的如Qwen2.5-7B效果和速度平衡的如GLM-4-9B都是不错的选择。你需要在自己的.env文件中配置LLM_API_KEY、LLM_API_BASE和LLM_NAME。生成的摘要会和文章元数据一起保存为public/data/目录下的JSON文件。前端应用在加载时直接读取这些静态的JSON文件来渲染页面。这种将计算密集型任务AI处理后置到构建阶段的思路是保证前端体验流畅的关键。3. 从零开始本地开发与环境配置详解3.1 项目初始化与依赖安装拿到一个开源项目第一步永远是把它拉到本地看看能不能跑起来。FeedMe的开发者体验做得不错跟着README操作基本不会踩坑。# 克隆项目到本地 git clone https://github.com/Seanium/feedme.git cd feedme # 使用 pnpm 安装依赖项目推荐速度更快磁盘空间更省 pnpm install如果还没安装pnpm可以用npm i -g pnpm快速安装。这里有个小细节项目锁定了包版本通过pnpm-lock.yaml这能确保所有开发者环境一致避免“在我机器上是好的”这种问题。安装过程如果遇到网络问题可以尝试配置国内镜像源。3.2 核心环境变量配置详解安装完依赖接下来就是配置项目的“大脑”——AI摘要服务。这需要通过环境变量来完成。# 复制环境变量示例文件 cp .env.example .env现在打开新生成的.env文件你会看到三个关键的配置项LLM_API_KEY你的_API_密钥 LLM_API_BASELLM服务的API基础URL LLM_NAME使用的模型名称LLM_API_KEY这是访问AI服务的通行证。你需要去对应的AI服务平台注册账号并获取。例如如果你使用硅基流动SiliconFlow可以在其控制台创建API Key。LLM_API_BASE这是API的端点地址。对于OpenAI格式兼容的接口通常是https://api.siliconflow.cn/v1或https://api.openai.com/v1。务必确认地址末尾的/v1是否正确很多请求失败都是因为地址不对。LLM_NAME指定你要使用的具体模型。例如THUDM/GLM-4-9B-0414、Qwen/Qwen2.5-7B-Instruct或gpt-3.5-turbo。模型名称必须与API提供商支持的列表完全一致。实操心得在本地开发阶段我强烈建议先使用一个免费的或低成本的测试用API Key。因为update-feeds脚本会对你配置的所有RSS源的最新文章逐一请求摘要如果订阅源较多一次可能消耗不少token。先用少量源测试确保整个流程跑通再增加源和调整更新频率。3.3 首次数据抓取与摘要生成配置好环境变量后就可以尝试让FeedMe“动起来”抓取文章并生成摘要了。# 执行数据更新脚本 pnpm update-feeds这个命令会执行scripts/update-feeds.js。你会看到终端开始输出日志连接RSS源、抓取条目、调用AI API、保存数据。如果一切顺利完成后会在public/data/目录下生成以时间戳命名的JSON文件如feeds-20240515.json里面包含了所有文章及其AI摘要。可能遇到的问题与排查网络超时某些RSS源服务器可能在海外或者响应慢。脚本中可以考虑为rss-parser或fetch增加超时设置并做好错误处理避免一个源失败导致整个任务中断。AI API调用失败检查.env文件配置是否正确检查API Key是否有余额或调用权限查看AI服务商的控制台确认请求是否被正常接收并返回了错误信息如429表示频率限制401表示密钥错误。文章内容抓取不全rss-parser默认可能只拿到摘要。有时需要启用customFields或寻找全文RSS地址。对于不支持全文输出的源摘要生成效果会大打折扣。3.4 启动本地开发服务器数据生成后就可以启动前端应用查看效果了。pnpm devVite会快速启动一个开发服务器通常在http://localhost:3000。打开浏览器你应该能看到一个简洁现代的界面左侧是分类或源列表右侧是文章列表点击文章可以展开阅读AI生成的摘要。在开发模式下前端会监听文件变化热更新速度很快。你可以尝试修改src/目录下的React组件实时看到UI变化。但是请注意修改RSS配置src/config/rss-config.js或更新摘要数据后需要重新运行pnpm update-feeds才能在前端看到最新内容因为前端读取的是静态JSON文件。4. 核心功能配置与深度定制4.1 打造你的专属信息源RSS配置解析项目的核心配置文件是src/config/rss-config.js。它决定了你关注哪些信息源。// rss-config.js 结构示例 const rssConfig { maxItemsPerFeed: 20, // 每个源最多保留多少篇文章 feeds: [ { name: 科技爱好者周刊, url: https://example.com/feed.xml, category: 科技, }, { name: 某技术博客, url: https://blog.example.com/rss, category: 编程, }, // ... 更多订阅源 ], };maxItemsPerFeed这是一个重要的清理机制。为了避免数据文件无限膨胀每次更新时每个RSS源只保留最新的N条。建议设置为20-50既能保持内容新鲜度又不会给AI处理和前端加载带来太大压力。feeds数组每个对象代表一个订阅源。name是显示在前端的名称url是RSS或Atom源的地址category用于分类筛选你可以自定义任何分类如“新闻”、“设计”、“个人”。如何寻找高质量的RSS源很多博客和新闻网站会在首页的head部分通过link relalternate typeapplication/rssxml href...标签声明RSS地址。对于不支持原生RSS的网站如一些社交媒体、公众号可以使用第三方服务如RSSHub来生成RSS源。注意使用第三方中转服务时需考虑其稳定性和隐私政策。一些传统的RSS阅读器如Feedly、Inoreader也提供了导出OPML文件的功能你可以从中提取出源的URL。4.2 调整AI的“思考”方式Prompt定制AI摘要的质量除了模型本身Prompt提示词的设计至关重要。默认的Prompt在scripts/update-feeds.js里它指示模型用列表形式总结要点。如果你想让摘要更符合你的需求可以修改这个Prompt。例如要求中文输出在Prompt开头明确写上“请用中文回答”。改变摘要风格“请用一段话总结文章的核心论点和技术细节。”增加特定指令“如果文章是教程请列出关键步骤如果是观点文请总结正反方论据。”控制长度“总结内容请控制在100字以内。”修改Prompt后记得重新运行pnpm update-feeds来重新生成摘要。这是一个需要不断调试和优化的过程不同的信息源类型新闻、技术教程、长文分析可能需要不同的Prompt策略。4.3 前端界面个性化调整FeedMe的UI基于shadcn/ui和Tailwind CSS定制起来非常灵活。主题颜色Tailwind的配色方案可以在tailwind.config.js中修改。shadcn/ui的组件样式则通过修改src/lib/utils.ts中的cn函数或直接覆盖组件CSS变量来调整。布局与组件主要的页面布局在src/app/page.tsx和src/components/下的各个组件中。你可以调整文章列表的展示方式如卡片式、列表式、侧边栏的宽度、字体大小等。添加新功能比如你可以增加一个“标记为已读”的功能将已读文章的ID存储在浏览器的localStorage中并在UI上做视觉区分。或者增加一个“收藏”功能将喜欢的文章摘要另存为一个列表。由于项目是React TypeScript对于有一定前端经验的开发者来说进行这类功能增删和界面调整是比较直观的。5. 生产环境部署方案全解析本地玩转之后下一步就是把它部署到一个公开可访问的地方随时随地阅读。FeedMe提供了多种部署方式适应不同场景。5.1 零成本首选GitHub Pages自动化部署这是最推荐个人用户使用的方式完全免费且利用GitHub Actions实现了全自动化。部署步骤精讲Fork项目点击GitHub仓库右上角的“Fork”按钮将项目复制到你自己的账号下。这样你才能拥有仓库的设置权限。配置密钥Secrets这是最关键的一步。进入你Fork后的仓库点击Settings-Secrets and variables-Actions。点击New repository secret。Name输入LLM_API_KEYValue粘贴你的AI API密钥。同样地创建LLM_API_BASE和LLM_NAME这两个Secret。重要提示Secrets中的值在页面上会显示为星号且一旦创建无法再次查看明文。请务必妥善保管原始密钥。这些Secrets会在GitHub Actions的工作流运行时作为安全的环境变量注入。启用GitHub Pages在仓库Settings-Pages。Source选择GitHub Actions。这意味着部署将由我们定义的工作流.github/workflows/update-deploy.yml来驱动。手动触发首次构建可选但建议进入Actions标签页找到 “更新数据并部署” 工作流。点击Run workflow选择main分支然后运行。这将触发一次完整的数据抓取、摘要生成和静态网站构建并自动部署到GitHub Pages。工作流原理剖析打开.github/workflows/update-deploy.yml文件你可以看到这个自动化流程触发器schedule每3小时一次、push代码推送时、workflow_dispatch手动触发。执行环境在一个Ubuntu虚拟机中配置好Node.js环境。核心步骤Checkout拉取你的代码。Setup pnpm安装pnpm。Install deps安装项目依赖。Update feeds这是核心。运行pnpm update-feeds此时脚本会读取你在Secrets中配置的LLM_API_KEY等环境变量调用AI服务生成摘要。Build运行pnpm build使用Vite将React应用打包成静态文件位于dist目录。Deploy使用peaceiris/actions-gh-pages这个Action将dist目录的内容推送到仓库的gh-pages分支。GitHub Pages服务会自动从这个分支提供网站服务。部署成功后你的个人FeedMe站点地址通常是https://[你的GitHub用户名].github.io/[仓库名]/。你可以在仓库的Settings-Pages里看到确切的URL。5.2 灵活高效的云端部署Vercel / 阿里云 ESA Pages如果你觉得GitHub Pages的自动化流程稍显复杂或者希望获得更快的全球访问速度、更简单的自定义域名绑定体验那么Vercel或阿里云ESA Pages是绝佳选择。FeedMe项目已经为此做好了准备。核心原理GitHub Actions在构建完成后不仅部署到GitHub Pages还会将构建产物dist目录推送到一个名为deploy的分支。Vercel或ESA Pages只需要监控这个deploy分支一旦有更新就自动拉取并发布。以Vercel为例的部署流程访问 Vercel 并登录支持GitHub账号。点击 “Add New…” - “Project”导入你Fork的FeedMe仓库。在配置页面关键一步是修改“Production Branch”从默认的main改为deploy。环境变量配置在Vercel项目的Settings-Environment Variables中同样添加LLM_API_KEY、LLM_API_BASE、LLM_NAME这三个变量。点击 “Deploy”。首次部署可能会失败因为deploy分支可能还不存在。回到你的GitHub仓库手动触发一次GitHub Actions工作流参考5.1节第4步。工作流成功运行后会自动创建并更新deploy分支。Vercel检测到deploy分支的更新会自动重新部署网站就上线了。阿里云ESA Pages的流程与此类似在控制台创建Pages应用关联GitHub仓库并设置生产分支为deploy即可。其优势在于依托阿里云的全球加速网络国内访问速度可能更理想。注意事项使用这种方式AI摘要的生成仍然依赖于GitHub Actions的定时任务。Vercel/ESA Pages只负责托管前端静态文件。如果你关闭了GitHub Actions或者Fork的仓库被删除内容将停止更新。你需要确保GitHub仓库中的Actions权限和Secrets配置正确且持续运行。5.3 完全私有化掌控Docker本地/服务器部署对于需要在内网部署、或希望完全脱离GitHub生态的用户Docker部署方案提供了最大的控制权。部署流程与深度配置准备环境确保你的服务器或本地机器已安装Docker和Docker Compose。克隆与配置git clone https://github.com/Seanium/feedme.git cd feedme cp .env.example .env # 编辑 .env 文件填入你的AI API配置一键启动docker-compose up --build -d这个命令会执行docker-compose.yml文件构建一个包含Node.js环境的Docker镜像。将当前目录挂载到容器的/app目录。启动时执行start.sh脚本安装依赖、首次更新数据、构建应用、并用一个HTTP服务器如serve在3000端口启动服务。-d参数让容器在后台运行。访问应用打开浏览器访问http://你的服务器IP:3000。自动化更新的奥秘 Docker方案的精髓在于容器内的Cron任务。查看src/config/crontab-docker文件0 */3 * * * cd /app /usr/local/bin/pnpm update-feeds /var/log/cron.log 21 /usr/local/bin/pnpm build /var/log/cron.log 21这行Cron表达式表示“每3小时执行一次”。执行的内容是进入应用目录运行更新摘要命令然后重新构建应用。由于构建产物目录dist是通过卷volume挂载的新的静态文件会直接覆盖旧的。前端HTTP服务器如serve会自动服务最新的文件。如何修改更新频率直接编辑src/config/crontab-docker文件修改Cron表达式即可。例如0 */6 * * *每6小时在每小时的0分。0 2 * * *每天凌晨2点。*/30 * * * *每30分钟测试时可用生产环境请谨慎避免高频调用AI API。修改后需要重建Docker容器以使更改生效docker-compose down docker-compose up --build -d6. 常见问题排查与优化实践在实际部署和使用FeedMe的过程中你可能会遇到一些问题。下面是我遇到的一些典型情况及其解决方法。6.1 AI摘要生成失败或内容不佳问题表现pnpm update-feeds运行时报错或生成的摘要为空、乱码、质量低下。排查步骤检查环境变量确认.env文件或GitHub Secrets中的LLM_API_BASE和LLM_NAME完全正确包括大小写和特殊字符。最好去API提供商的文档页面核对模型名称。检查API密钥与余额登录AI服务商控制台确认API Key有效且未过期账户有足够的余额或免费额度。查看详细日志在scripts/update-feeds.js中可以增加更详细的错误日志输出比如打印出每个RSS源抓取后的原始内容、发送给AI的Prompt内容、以及AI返回的原始响应。这有助于判断问题是出在数据抓取还是AI处理环节。调整Prompt如果摘要质量差尝试优化Prompt。让指令更清晰例如指定输出语言、格式、长度。对于技术文章可以要求“总结核心代码片段和实现原理”对于新闻可以要求“提取时间、地点、人物、事件关键要素”。尝试不同模型不同的模型擅长不同的任务。可以换一个模型比如从较小的7B模型换到更大的70B模型或在同一系列内切换测试效果。注意更大的模型通常响应更慢、费用更高。处理超长文本有些文章非常长可能超过模型的上下文窗口限制。需要在代码中对文章内容进行截断或分段处理。可以在update-feeds.js中在构造Prompt前检查文章内容的长度如果超过某个阈值如8000字符则进行智能截断例如取前N个字符或尝试提取主要段落。6.2 GitHub Actions工作流运行失败问题表现GitHub Actions的“更新数据并部署”工作流显示红色失败状态。排查步骤查看具体错误日志点击失败的工作流运行查看详细的步骤日志。错误通常会在Update feeds或Build步骤中暴露出来。常见错误Error: Missing required secret: LLM_API_KEY说明Secrets没有正确设置。请严格按照步骤在仓库的Settings - Secrets and variables - Actions中添加注意名称必须完全一致。Process completed with exit code 1通常是pnpm update-feeds脚本执行出错。可能是网络问题导致某个RSS源抓取超时或者AI API调用失败。查看该步骤的日志输出定位具体错误信息。部署失败检查Deploy步骤的日志可能是部署令牌GH_TOKEN由GitHub自动提供权限不足或者gh-pages分支存在冲突。手动调试尝试在本地环境中使用相同的环境变量值运行pnpm update-feeds看是否能成功。这能帮助排除是代码问题还是GitHub Actions环境问题。调整更新频率如果是因为频繁调用AI API导致额度超限或触发频率限制可以修改.github/workflows/update-deploy.yml中的schedule将cron: 0 */3 * * *每3小时改为cron: 0 12 * * *每天中午12点等更低频率。6.3 网站内容不更新问题表现部署成功后网站可以访问但文章内容一直是旧的没有看到新抓取的文章。排查步骤检查自动化任务是否运行GitHub Pages部署去仓库的Actions标签页查看最近的工作流运行记录和时间确认定时任务是否被触发并成功完成。Docker部署进入容器查看Cron日志docker exec -it [容器名或ID] cat /var/log/cron.log。或者直接进入容器手动执行一次更新命令看是否报错。检查数据文件查看public/data/目录下对于GitHub Pages需要查看gh-pages或deploy分支里的对应文件最新的JSON文件确认其生成时间是否最新文件里是否包含了你期望的新文章。检查RSS源确认你配置的RSS源地址是有效的并且该源最近有更新。可以用浏览器直接打开RSS的URL看看最新的文章条目是什么。前端缓存问题浏览器可能会缓存旧的JSON数据文件。可以尝试强制刷新CtrlF5或者检查前端代码中是否对数据请求设置了不合理的缓存策略。6.4 性能与成本优化建议控制数据量合理设置maxItemsPerFeed如20。不要盲目追求保留大量历史文章这会让数据文件变大前端加载变慢AI处理成本也增高。选择性使用AI摘要不是所有文章都需要AI摘要。可以在rss-config.js中为每个源增加一个enableAISummary: true/false的配置项。对于更新极快、标题即内容的新闻源如快讯可以关闭AI摘要只显示标题和链接。使用更经济的模型对于摘要生成这种任务不一定需要最顶尖的模型。像Qwen2.5-7B、GLM-4-9B这类中等规模的模型在效果和成本上往往有更好的平衡。多测试几个模型找到性价比最高的那个。合并摘要请求高级如果订阅源很多可以考虑将多篇文章的内容合并成一个稍长的文本一次性发送给AI请求它为每篇文章生成一个要点摘要。这能减少API调用次数按Token计费的服务可能不适用。但这需要更复杂的Prompt设计和结果解析逻辑。经过一段时间的深度使用FeedMe已经成了我每日信息筛查的固定入口。它的价值不在于替代深度阅读而在于高效过滤。每天早上花十分钟浏览一遍AI提炼的要点就能对关注领域的最新动态有个大致把握再决定哪几篇值得点开原文细读。这种“AI预处理人工决策”的模式极大地提升了信息消费的效率。如果你也苦于信息过载不妨亲手部署一个根据自己的阅读习惯精细调教它很可能成为你数字生活里一个得力的助手。 基于AI的智能RSS阅读器：静态生成与自动化部署实践
1. 项目概述一个能“消化”信息的智能RSS阅读器如果你和我一样每天被海量的信息流淹没订阅了几十个RSS源但根本没时间一篇篇点开细读最后收藏夹里堆满了“稍后阅读”却再也没打开过的文章那么这个项目可能就是你的解药。FeedMe一个我最近深度使用并部署的智能RSS聚合器它解决的核心痛点非常直接用AI帮你“消化”信息把冗长的文章变成可快速浏览的摘要。这不是一个需要你注册账号、下载App的臃肿服务。它的本质是一个静态网站你可以零成本部署在GitHub Pages上或者用Docker跑在自己的服务器里。所有的数据——你订阅的RSS源、AI生成的摘要——都完全由你掌控。技术栈选用了当下前端开发里相当务实和现代的组合TypeScript保证代码质量React构建用户界面Tailwind CSS快速搞定样式再配上shadcn/ui这套高质量的组件库以及Vite带来的极速开发体验。整个项目的设计哲学就是“轻量、智能、为你定制”我实际用下来它确实做到了。2. 核心设计思路静态生成与AI处理的巧妙结合2.1 为何选择“静态网站定时更新”的架构很多RSS阅读器是动态的每次打开页面都去实时抓取源站内容。FeedMe走了另一条路预生成静态内容。这背后有几个非常实际的考量。首先性能与成本。静态文件可以被全球的CDN高效缓存用户打开页面的速度极快体验接近本地应用。对于个人使用或小团队来说部署在GitHub Pages、Vercel或阿里云ESA Pages这类服务上几乎是零成本的。如果每次访问都动态抓取和请求AI接口不仅速度慢API调用成本也会急剧上升。其次稳定性与可控性。RSS源站可能不稳定AI服务也可能偶尔抽风。通过GitHub Actions或Cron任务在后台定时执行抓取和摘要生成即使某次任务失败用户端看到的仍然是上一次成功生成的内容服务不会完全中断。你可以从容地查看日志、排查问题而不会让用户面对一个白屏或错误页面。最后隐私与所有权。你的订阅列表rss-config.js和生成后的摘要数据JSON文件都存放在你自己的仓库或服务器上。没有中间服务器存储你的阅读习惯数据主权清晰明了。2.2 AI摘要生成从“阅读”到“理解”的关键一跃RSS阅读器的核心价值是信息聚合但FeedMe通过引入大语言模型LLM将价值提升到了信息提纯。它不是在简单展示标题和简介而是试图让AI理解文章内容并提炼出核心要点。这个过程在scripts/update-feeds.js中完成。脚本会遍历你配置的所有RSS源抓取最新的条目。对于每一篇文章它会提取出标题、链接、发布时间和完整的正文内容这里通常需要借助rss-parser等库的能力来获取全文或摘要。然后构造一个特定的提示词Prompt将文章内容发送给你配置的LLM API例如硅基流动、OpenAI、DeepSeek等兼容OpenAI格式的接口。注意AI摘要的质量和成本很大程度上取决于你的Prompt设计和选择的模型。项目默认的Prompt是一个很好的起点它要求模型以简洁的列表形式总结要点。但你可以根据需求调整比如要求用中文总结、突出技术细节、或者评估文章的可信度等。模型方面轻量级的如Qwen2.5-7B效果和速度平衡的如GLM-4-9B都是不错的选择。你需要在自己的.env文件中配置LLM_API_KEY、LLM_API_BASE和LLM_NAME。生成的摘要会和文章元数据一起保存为public/data/目录下的JSON文件。前端应用在加载时直接读取这些静态的JSON文件来渲染页面。这种将计算密集型任务AI处理后置到构建阶段的思路是保证前端体验流畅的关键。3. 从零开始本地开发与环境配置详解3.1 项目初始化与依赖安装拿到一个开源项目第一步永远是把它拉到本地看看能不能跑起来。FeedMe的开发者体验做得不错跟着README操作基本不会踩坑。# 克隆项目到本地 git clone https://github.com/Seanium/feedme.git cd feedme # 使用 pnpm 安装依赖项目推荐速度更快磁盘空间更省 pnpm install如果还没安装pnpm可以用npm i -g pnpm快速安装。这里有个小细节项目锁定了包版本通过pnpm-lock.yaml这能确保所有开发者环境一致避免“在我机器上是好的”这种问题。安装过程如果遇到网络问题可以尝试配置国内镜像源。3.2 核心环境变量配置详解安装完依赖接下来就是配置项目的“大脑”——AI摘要服务。这需要通过环境变量来完成。# 复制环境变量示例文件 cp .env.example .env现在打开新生成的.env文件你会看到三个关键的配置项LLM_API_KEY你的_API_密钥 LLM_API_BASELLM服务的API基础URL LLM_NAME使用的模型名称LLM_API_KEY这是访问AI服务的通行证。你需要去对应的AI服务平台注册账号并获取。例如如果你使用硅基流动SiliconFlow可以在其控制台创建API Key。LLM_API_BASE这是API的端点地址。对于OpenAI格式兼容的接口通常是https://api.siliconflow.cn/v1或https://api.openai.com/v1。务必确认地址末尾的/v1是否正确很多请求失败都是因为地址不对。LLM_NAME指定你要使用的具体模型。例如THUDM/GLM-4-9B-0414、Qwen/Qwen2.5-7B-Instruct或gpt-3.5-turbo。模型名称必须与API提供商支持的列表完全一致。实操心得在本地开发阶段我强烈建议先使用一个免费的或低成本的测试用API Key。因为update-feeds脚本会对你配置的所有RSS源的最新文章逐一请求摘要如果订阅源较多一次可能消耗不少token。先用少量源测试确保整个流程跑通再增加源和调整更新频率。3.3 首次数据抓取与摘要生成配置好环境变量后就可以尝试让FeedMe“动起来”抓取文章并生成摘要了。# 执行数据更新脚本 pnpm update-feeds这个命令会执行scripts/update-feeds.js。你会看到终端开始输出日志连接RSS源、抓取条目、调用AI API、保存数据。如果一切顺利完成后会在public/data/目录下生成以时间戳命名的JSON文件如feeds-20240515.json里面包含了所有文章及其AI摘要。可能遇到的问题与排查网络超时某些RSS源服务器可能在海外或者响应慢。脚本中可以考虑为rss-parser或fetch增加超时设置并做好错误处理避免一个源失败导致整个任务中断。AI API调用失败检查.env文件配置是否正确检查API Key是否有余额或调用权限查看AI服务商的控制台确认请求是否被正常接收并返回了错误信息如429表示频率限制401表示密钥错误。文章内容抓取不全rss-parser默认可能只拿到摘要。有时需要启用customFields或寻找全文RSS地址。对于不支持全文输出的源摘要生成效果会大打折扣。3.4 启动本地开发服务器数据生成后就可以启动前端应用查看效果了。pnpm devVite会快速启动一个开发服务器通常在http://localhost:3000。打开浏览器你应该能看到一个简洁现代的界面左侧是分类或源列表右侧是文章列表点击文章可以展开阅读AI生成的摘要。在开发模式下前端会监听文件变化热更新速度很快。你可以尝试修改src/目录下的React组件实时看到UI变化。但是请注意修改RSS配置src/config/rss-config.js或更新摘要数据后需要重新运行pnpm update-feeds才能在前端看到最新内容因为前端读取的是静态JSON文件。4. 核心功能配置与深度定制4.1 打造你的专属信息源RSS配置解析项目的核心配置文件是src/config/rss-config.js。它决定了你关注哪些信息源。// rss-config.js 结构示例 const rssConfig { maxItemsPerFeed: 20, // 每个源最多保留多少篇文章 feeds: [ { name: 科技爱好者周刊, url: https://example.com/feed.xml, category: 科技, }, { name: 某技术博客, url: https://blog.example.com/rss, category: 编程, }, // ... 更多订阅源 ], };maxItemsPerFeed这是一个重要的清理机制。为了避免数据文件无限膨胀每次更新时每个RSS源只保留最新的N条。建议设置为20-50既能保持内容新鲜度又不会给AI处理和前端加载带来太大压力。feeds数组每个对象代表一个订阅源。name是显示在前端的名称url是RSS或Atom源的地址category用于分类筛选你可以自定义任何分类如“新闻”、“设计”、“个人”。如何寻找高质量的RSS源很多博客和新闻网站会在首页的head部分通过link relalternate typeapplication/rssxml href...标签声明RSS地址。对于不支持原生RSS的网站如一些社交媒体、公众号可以使用第三方服务如RSSHub来生成RSS源。注意使用第三方中转服务时需考虑其稳定性和隐私政策。一些传统的RSS阅读器如Feedly、Inoreader也提供了导出OPML文件的功能你可以从中提取出源的URL。4.2 调整AI的“思考”方式Prompt定制AI摘要的质量除了模型本身Prompt提示词的设计至关重要。默认的Prompt在scripts/update-feeds.js里它指示模型用列表形式总结要点。如果你想让摘要更符合你的需求可以修改这个Prompt。例如要求中文输出在Prompt开头明确写上“请用中文回答”。改变摘要风格“请用一段话总结文章的核心论点和技术细节。”增加特定指令“如果文章是教程请列出关键步骤如果是观点文请总结正反方论据。”控制长度“总结内容请控制在100字以内。”修改Prompt后记得重新运行pnpm update-feeds来重新生成摘要。这是一个需要不断调试和优化的过程不同的信息源类型新闻、技术教程、长文分析可能需要不同的Prompt策略。4.3 前端界面个性化调整FeedMe的UI基于shadcn/ui和Tailwind CSS定制起来非常灵活。主题颜色Tailwind的配色方案可以在tailwind.config.js中修改。shadcn/ui的组件样式则通过修改src/lib/utils.ts中的cn函数或直接覆盖组件CSS变量来调整。布局与组件主要的页面布局在src/app/page.tsx和src/components/下的各个组件中。你可以调整文章列表的展示方式如卡片式、列表式、侧边栏的宽度、字体大小等。添加新功能比如你可以增加一个“标记为已读”的功能将已读文章的ID存储在浏览器的localStorage中并在UI上做视觉区分。或者增加一个“收藏”功能将喜欢的文章摘要另存为一个列表。由于项目是React TypeScript对于有一定前端经验的开发者来说进行这类功能增删和界面调整是比较直观的。5. 生产环境部署方案全解析本地玩转之后下一步就是把它部署到一个公开可访问的地方随时随地阅读。FeedMe提供了多种部署方式适应不同场景。5.1 零成本首选GitHub Pages自动化部署这是最推荐个人用户使用的方式完全免费且利用GitHub Actions实现了全自动化。部署步骤精讲Fork项目点击GitHub仓库右上角的“Fork”按钮将项目复制到你自己的账号下。这样你才能拥有仓库的设置权限。配置密钥Secrets这是最关键的一步。进入你Fork后的仓库点击Settings-Secrets and variables-Actions。点击New repository secret。Name输入LLM_API_KEYValue粘贴你的AI API密钥。同样地创建LLM_API_BASE和LLM_NAME这两个Secret。重要提示Secrets中的值在页面上会显示为星号且一旦创建无法再次查看明文。请务必妥善保管原始密钥。这些Secrets会在GitHub Actions的工作流运行时作为安全的环境变量注入。启用GitHub Pages在仓库Settings-Pages。Source选择GitHub Actions。这意味着部署将由我们定义的工作流.github/workflows/update-deploy.yml来驱动。手动触发首次构建可选但建议进入Actions标签页找到 “更新数据并部署” 工作流。点击Run workflow选择main分支然后运行。这将触发一次完整的数据抓取、摘要生成和静态网站构建并自动部署到GitHub Pages。工作流原理剖析打开.github/workflows/update-deploy.yml文件你可以看到这个自动化流程触发器schedule每3小时一次、push代码推送时、workflow_dispatch手动触发。执行环境在一个Ubuntu虚拟机中配置好Node.js环境。核心步骤Checkout拉取你的代码。Setup pnpm安装pnpm。Install deps安装项目依赖。Update feeds这是核心。运行pnpm update-feeds此时脚本会读取你在Secrets中配置的LLM_API_KEY等环境变量调用AI服务生成摘要。Build运行pnpm build使用Vite将React应用打包成静态文件位于dist目录。Deploy使用peaceiris/actions-gh-pages这个Action将dist目录的内容推送到仓库的gh-pages分支。GitHub Pages服务会自动从这个分支提供网站服务。部署成功后你的个人FeedMe站点地址通常是https://[你的GitHub用户名].github.io/[仓库名]/。你可以在仓库的Settings-Pages里看到确切的URL。5.2 灵活高效的云端部署Vercel / 阿里云 ESA Pages如果你觉得GitHub Pages的自动化流程稍显复杂或者希望获得更快的全球访问速度、更简单的自定义域名绑定体验那么Vercel或阿里云ESA Pages是绝佳选择。FeedMe项目已经为此做好了准备。核心原理GitHub Actions在构建完成后不仅部署到GitHub Pages还会将构建产物dist目录推送到一个名为deploy的分支。Vercel或ESA Pages只需要监控这个deploy分支一旦有更新就自动拉取并发布。以Vercel为例的部署流程访问 Vercel 并登录支持GitHub账号。点击 “Add New…” - “Project”导入你Fork的FeedMe仓库。在配置页面关键一步是修改“Production Branch”从默认的main改为deploy。环境变量配置在Vercel项目的Settings-Environment Variables中同样添加LLM_API_KEY、LLM_API_BASE、LLM_NAME这三个变量。点击 “Deploy”。首次部署可能会失败因为deploy分支可能还不存在。回到你的GitHub仓库手动触发一次GitHub Actions工作流参考5.1节第4步。工作流成功运行后会自动创建并更新deploy分支。Vercel检测到deploy分支的更新会自动重新部署网站就上线了。阿里云ESA Pages的流程与此类似在控制台创建Pages应用关联GitHub仓库并设置生产分支为deploy即可。其优势在于依托阿里云的全球加速网络国内访问速度可能更理想。注意事项使用这种方式AI摘要的生成仍然依赖于GitHub Actions的定时任务。Vercel/ESA Pages只负责托管前端静态文件。如果你关闭了GitHub Actions或者Fork的仓库被删除内容将停止更新。你需要确保GitHub仓库中的Actions权限和Secrets配置正确且持续运行。5.3 完全私有化掌控Docker本地/服务器部署对于需要在内网部署、或希望完全脱离GitHub生态的用户Docker部署方案提供了最大的控制权。部署流程与深度配置准备环境确保你的服务器或本地机器已安装Docker和Docker Compose。克隆与配置git clone https://github.com/Seanium/feedme.git cd feedme cp .env.example .env # 编辑 .env 文件填入你的AI API配置一键启动docker-compose up --build -d这个命令会执行docker-compose.yml文件构建一个包含Node.js环境的Docker镜像。将当前目录挂载到容器的/app目录。启动时执行start.sh脚本安装依赖、首次更新数据、构建应用、并用一个HTTP服务器如serve在3000端口启动服务。-d参数让容器在后台运行。访问应用打开浏览器访问http://你的服务器IP:3000。自动化更新的奥秘 Docker方案的精髓在于容器内的Cron任务。查看src/config/crontab-docker文件0 */3 * * * cd /app /usr/local/bin/pnpm update-feeds /var/log/cron.log 21 /usr/local/bin/pnpm build /var/log/cron.log 21这行Cron表达式表示“每3小时执行一次”。执行的内容是进入应用目录运行更新摘要命令然后重新构建应用。由于构建产物目录dist是通过卷volume挂载的新的静态文件会直接覆盖旧的。前端HTTP服务器如serve会自动服务最新的文件。如何修改更新频率直接编辑src/config/crontab-docker文件修改Cron表达式即可。例如0 */6 * * *每6小时在每小时的0分。0 2 * * *每天凌晨2点。*/30 * * * *每30分钟测试时可用生产环境请谨慎避免高频调用AI API。修改后需要重建Docker容器以使更改生效docker-compose down docker-compose up --build -d6. 常见问题排查与优化实践在实际部署和使用FeedMe的过程中你可能会遇到一些问题。下面是我遇到的一些典型情况及其解决方法。6.1 AI摘要生成失败或内容不佳问题表现pnpm update-feeds运行时报错或生成的摘要为空、乱码、质量低下。排查步骤检查环境变量确认.env文件或GitHub Secrets中的LLM_API_BASE和LLM_NAME完全正确包括大小写和特殊字符。最好去API提供商的文档页面核对模型名称。检查API密钥与余额登录AI服务商控制台确认API Key有效且未过期账户有足够的余额或免费额度。查看详细日志在scripts/update-feeds.js中可以增加更详细的错误日志输出比如打印出每个RSS源抓取后的原始内容、发送给AI的Prompt内容、以及AI返回的原始响应。这有助于判断问题是出在数据抓取还是AI处理环节。调整Prompt如果摘要质量差尝试优化Prompt。让指令更清晰例如指定输出语言、格式、长度。对于技术文章可以要求“总结核心代码片段和实现原理”对于新闻可以要求“提取时间、地点、人物、事件关键要素”。尝试不同模型不同的模型擅长不同的任务。可以换一个模型比如从较小的7B模型换到更大的70B模型或在同一系列内切换测试效果。注意更大的模型通常响应更慢、费用更高。处理超长文本有些文章非常长可能超过模型的上下文窗口限制。需要在代码中对文章内容进行截断或分段处理。可以在update-feeds.js中在构造Prompt前检查文章内容的长度如果超过某个阈值如8000字符则进行智能截断例如取前N个字符或尝试提取主要段落。6.2 GitHub Actions工作流运行失败问题表现GitHub Actions的“更新数据并部署”工作流显示红色失败状态。排查步骤查看具体错误日志点击失败的工作流运行查看详细的步骤日志。错误通常会在Update feeds或Build步骤中暴露出来。常见错误Error: Missing required secret: LLM_API_KEY说明Secrets没有正确设置。请严格按照步骤在仓库的Settings - Secrets and variables - Actions中添加注意名称必须完全一致。Process completed with exit code 1通常是pnpm update-feeds脚本执行出错。可能是网络问题导致某个RSS源抓取超时或者AI API调用失败。查看该步骤的日志输出定位具体错误信息。部署失败检查Deploy步骤的日志可能是部署令牌GH_TOKEN由GitHub自动提供权限不足或者gh-pages分支存在冲突。手动调试尝试在本地环境中使用相同的环境变量值运行pnpm update-feeds看是否能成功。这能帮助排除是代码问题还是GitHub Actions环境问题。调整更新频率如果是因为频繁调用AI API导致额度超限或触发频率限制可以修改.github/workflows/update-deploy.yml中的schedule将cron: 0 */3 * * *每3小时改为cron: 0 12 * * *每天中午12点等更低频率。6.3 网站内容不更新问题表现部署成功后网站可以访问但文章内容一直是旧的没有看到新抓取的文章。排查步骤检查自动化任务是否运行GitHub Pages部署去仓库的Actions标签页查看最近的工作流运行记录和时间确认定时任务是否被触发并成功完成。Docker部署进入容器查看Cron日志docker exec -it [容器名或ID] cat /var/log/cron.log。或者直接进入容器手动执行一次更新命令看是否报错。检查数据文件查看public/data/目录下对于GitHub Pages需要查看gh-pages或deploy分支里的对应文件最新的JSON文件确认其生成时间是否最新文件里是否包含了你期望的新文章。检查RSS源确认你配置的RSS源地址是有效的并且该源最近有更新。可以用浏览器直接打开RSS的URL看看最新的文章条目是什么。前端缓存问题浏览器可能会缓存旧的JSON数据文件。可以尝试强制刷新CtrlF5或者检查前端代码中是否对数据请求设置了不合理的缓存策略。6.4 性能与成本优化建议控制数据量合理设置maxItemsPerFeed如20。不要盲目追求保留大量历史文章这会让数据文件变大前端加载变慢AI处理成本也增高。选择性使用AI摘要不是所有文章都需要AI摘要。可以在rss-config.js中为每个源增加一个enableAISummary: true/false的配置项。对于更新极快、标题即内容的新闻源如快讯可以关闭AI摘要只显示标题和链接。使用更经济的模型对于摘要生成这种任务不一定需要最顶尖的模型。像Qwen2.5-7B、GLM-4-9B这类中等规模的模型在效果和成本上往往有更好的平衡。多测试几个模型找到性价比最高的那个。合并摘要请求高级如果订阅源很多可以考虑将多篇文章的内容合并成一个稍长的文本一次性发送给AI请求它为每篇文章生成一个要点摘要。这能减少API调用次数按Token计费的服务可能不适用。但这需要更复杂的Prompt设计和结果解析逻辑。经过一段时间的深度使用FeedMe已经成了我每日信息筛查的固定入口。它的价值不在于替代深度阅读而在于高效过滤。每天早上花十分钟浏览一遍AI提炼的要点就能对关注领域的最新动态有个大致把握再决定哪几篇值得点开原文细读。这种“AI预处理人工决策”的模式极大地提升了信息消费的效率。如果你也苦于信息过载不妨亲手部署一个根据自己的阅读习惯精细调教它很可能成为你数字生活里一个得力的助手。