1. 项目概述一个为“懒人”设计的极简信息聚合器最近在折腾个人知识管理和信息流聚合时发现了一个挺有意思的开源项目叫Nas4146/brief。乍一看这个名字你可能有点懵——“brief”是简报的意思那这个项目是干嘛的简单来说它就是一个高度可定制、极度轻量的个人专属信息聚合与简报生成工具。你可以把它理解为你为自己搭建的一个“私人助理”每天定时从你指定的信息源比如RSS订阅、特定网站、API接口抓取内容然后按照你喜欢的格式比如纯文本、Markdown、HTML整理成一份简洁的“简报”推送到你指定的地方比如Telegram Bot、邮箱、甚至是本地文件。为什么说它适合“懒人”因为信息过载的时代我们每天被各种App推送、新闻网站、社交媒体信息流轰炸精力被严重分散。brief的核心思想就是“化繁为简主动索取”。它不追求大而全的聚合而是让你精确地定义“我想看什么”、“以什么方式看”、“多久看一次”。你不用再去一个个打开网站或App所有你关心的信息会像一份精心编排的早报或晚报准时、安静地送到你面前。这个项目适合谁呢我认为有几类朋友会特别喜欢效率追求者与极简主义者希望减少无关信息干扰只获取核心内容。开发者或技术爱好者项目本身用Go编写部署简单配置灵活适合喜欢折腾、有自定义需求的人。需要追踪特定领域信息的人比如追踪竞争对手动态、关注特定行业新闻、监控GitHub项目更新等。希望建立个人知识库入口的人可以将简报自动保存为Markdown文件纳入你的笔记系统如Obsidian、Logseq形成每日信息摘要。接下来我就结合自己部署和使用的经验从头到尾拆解一下brief这个项目聊聊它的设计思路、怎么配置、如何扩展以及我踩过的一些坑。2. 核心设计思路与架构解析2.1 为什么是“轮询”“模板”brief的核心工作流程非常清晰可以用“采集-处理-渲染-推送”四个步骤来概括。它的架构设计体现了两个关键选择轮询拉取和模板化渲染。为什么选择轮询拉取而不是Webhook推送这是由它的定位决定的。brief是一个客户端主动抓取工具而不是一个服务端推送平台。Webhook需要信息源的支持比如GitHub、某些博客平台提供Webhook而轮询定期去检查是更通用、更底层的方案。它不依赖任何第三方服务的特殊接口只要你能通过HTTP访问到目标内容哪怕是简单的网页brief就有办法把它抓取下来。这极大地扩展了其信息源的范围。当然轮询的缺点是有延迟且对目标服务器有一定访问压力。因此brief允许你为每个信息源配置独立的抓取间隔interval对于更新不频繁的源如个人博客可以设置较长的间隔如12小时而对于新闻类源可以设置较短间隔如30分钟。模板化渲染是灵活性的关键。brief不假设你需要的输出格式。你可能想要一份纯文本简报发到Telegram一份带链接的HTML发到邮箱同时再生成一份Markdown存档。通过Go标准库中的text/template包brief实现了强大的模板功能。你可以在配置文件中为不同的“推送器”定义不同的模板。模板里可以访问到抓取到的所有数据如文章标题、链接、摘要、发布时间等然后按照你的想法编排它们。这意味着简报的最终样式完全由你掌控从简单的列表到复杂的带分类的日报都可以实现。2.2 项目结构一览虽然项目本身代码不算庞大但结构清晰便于理解和二次开发。主要目录和文件作用如下config/存放配置相关的代码核心是解析YAML配置文件。fetcher/抓取器模块。这里是项目的核心之一定义了如何从不同来源获取数据。目前内置了常见的抓取器如rss用于RSS/Atom源、http用于普通网页配合选择器提取内容。parser/解析器模块。抓取到的原始数据如XML、HTML需要被解析成结构化的信息标题、链接等。这里定义了不同抓取器对应的解析逻辑。render/渲染器模块。负责将结构化的数据按照配置的模板渲染成最终的文本输出。这是模板引擎发挥作用的地方。sender/发送器/推送器模块。决定将渲染好的简报发送到哪里。内置了file保存到本地文件、telegram通过Bot发送、stdout打印到控制台等。task/任务调度模块。负责管理各个信息源的抓取任务按照配置的间隔定时执行。main.go程序入口负责初始化配置、启动调度器。config.example.yaml最最重要的配置文件示例你的所有自定义行为都通过它来定义。这种模块化设计的好处是扩展性极强。如果你想增加一个新的信息源比如从某个特定API获取数据你基本上只需要在fetcher/目录下新增一个抓取器并在parser/下配套一个解析器即可。推送渠道的扩展也同样方便。3. 从零开始部署与基础配置实战理论说得再多不如动手跑起来。我们假设你有一台Linux服务器或本地开发环境从零开始部署和配置brief。3.1 环境准备与项目获取首先确保你的机器上安装了Go语言环境1.16版本。brief是Go项目我们可以直接通过go install来安装这是最推荐的方式因为它会自动处理依赖并编译出二进制文件。# 安装最新版本的 brief go install github.com/Nas4146/brieflatest安装完成后二进制文件brief会出现在你的$GOPATH/bin目录下通常是~/go/bin/。确保这个目录在你的系统PATH环境变量中。注意如果你遇到网络问题无法从GitHub拉取可以考虑先git clone项目到本地然后在项目根目录执行go build -o brief .进行手动编译生成的可执行文件在当前目录。另一种更“运维”的方式是使用Docker项目提供了Dockerfile。你可以自己构建镜像也可以使用我构建好的假设为my-brief:latest。用Docker部署的优势是环境隔离特别适合在服务器上长期运行。# 克隆代码 git clone https://github.com/Nas4146/brief.git cd brief # 构建Docker镜像 docker build -t my-brief . # 运行容器将本地配置文件目录挂载进去 docker run -d --name brief-service -v /path/to/your/config:/app/config my-brief3.2 核心配置文件深度解读配置文件是brief的灵魂它是一个YAML文件。我们以config.example.yaml为基础创建一个自己的config.yaml。下面我拆解每一个核心配置块。全局配置 (config)config: data_file: ./data/data.db # 用于存储抓取历史实现去重避免每次推送重复内容 log_level: info # 日志级别debug, info, warn, error timezone: Asia/Shanghai # 设置时区影响日志和模板中的时间显示data_file非常重要。brief通过一个SQLite数据库记录已经抓取并推送过的条目ID或链接。下次抓取时会自动过滤掉已推送的确保简报内容不重复。请确保运行brief的用户对该文件所在目录有读写权限。抓取源定义 (sources)这是配置的重头戏每个源代表一个你想追踪的信息渠道。sources: - name: cnbeta # 源名称自定义用于日志标识 type: rss # 抓取器类型这里是RSS url: https://www.cnbeta.com/backend.php # RSS源地址 interval: 30m # 抓取间隔30分钟。支持单位s(秒), m(分), h(时) parser: # 解析器配置用于从原始数据中提取字段 type: rss filters: # 过滤器可选用于进一步筛选内容 - rule: title contains 苹果 # 例如只保留标题包含“苹果”的文章 action: keeptype: rss这是最常用的类型适用于绝大多数博客、新闻网站的RSS/Atom订阅源。interval根据信息源的更新频率合理设置。技术博客可能一天一更设为24h快讯类新闻可以设为15m。太频繁可能对对方服务器不友好。filters这是一个强大功能。你可以基于标题(title)、描述(description)等字段进行过滤。action可以是keep保留匹配的或drop丢弃匹配的。比如你可以用drop过滤掉所有标题含“广告”的文章。对于没有RSS的网站怎么办这时就需要用到http抓取器和goquery解析器。这需要一些前端知识了解HTML结构。sources: - name: 某无RSS技术论坛 type: http url: https://example.com/latest-posts interval: 2h parser: type: goquery item_selector: .post-list article # CSS选择器选中文章列表中的每一项 fields: # 定义从每个item中提取哪些字段 title: selector: h2 a attr: text # 获取标签内的文本 link: selector: h2 a attr: href # 获取href属性 description: selector: .excerpt attr: textitem_selector是关键它必须能精确选中列表页中每一个内容项的HTML元素。fields定义了如何从每个“项”中提取数据。你需要用浏览器的开发者工具F12查看网页结构找到合适的CSS选择器。这是一个需要耐心调试的过程。推送渠道配置 (senders)定义简报生成后发到哪里。可以配置多个发送器。senders: - name: daily_digest # 发送器名称自定义 type: telegram # 类型telegram bot template: {{.SourceName}} 更新啦\n{{range .Items}}• a href\{{.Link}}\{{.Title}}/a\n{{end}} # 模板 schedule: 0 9,18 * * * # 发送计划Cron表达式。此处代表每天上午9点和下午6点发送 sources: [cnbeta, 某无RSS技术论坛] # 指定哪些源的内容汇总到这份简报里 telegram: bot_token: YOUR_BOT_TOKEN # 从 BotFather 申请 chat_id: YOUR_CHAT_ID # 可以是个人ID、群组ID或频道IDtemplateTelegram支持HTML格式所以我们可以用a标签做链接。{{.SourceName}}和{{range .Items}}是模板语法分别代表源名称和循环遍历所有文章项。schedule这是核心调度逻辑。brief并不是每次抓取后就立刻推送而是根据这里配置的Cron表达式来定时触发推送。它会收集自上次推送以来所有配置的源抓取到的新内容然后一次性渲染并推送。这实现了“聚合”和“定时”两个关键特性。除了telegram常用的还有type: file保存到本地。配置path指定文件路径适合用来做归档或给其他程序如静态站点生成器消费。type: stdout打印到控制台主要用于调试。type: email通过SMTP发送邮件需要配置SMTP服务器信息。3.3 首次运行与调试配置文件写好后建议先以调试模式运行检查配置是否正确抓取是否成功。# 在前台运行并指定配置文件路径 brief -c /path/to/your/config.yaml # 或者如果配置文件就在当前目录且名为config.yaml可以直接 brief观察日志输出。如果看到类似Fetched X new items from source [cnbeta]的日志说明抓取成功。如果看到错误通常是以下几种网络错误检查URL是否能正常访问。解析错误对于goquery解析器很可能是CSS选择器写错了无法匹配到元素。日志会打印抓取到的HTML片段帮助你调试。配置格式错误检查YAML缩进和冒号后面是否有空格。实操心得建议初期为每个源单独配置一个type: stdout的发送器并设置较短的抓取间隔如interval: 2m这样能快速在终端看到抓取到的原始数据结构和内容方便调试解析器配置。确认无误后再加入到正式的定时推送发送器中。4. 高级玩法与自定义扩展基础功能用顺手后就可以开始折腾一些高级功能了这也是brief乐趣所在。4.1 编写自定义模板打造个性化简报模板是决定简报最终样式的核心。brief使用Go的标准模板语法功能强大。假设我们想要一份更丰富的Markdown格式日报包含日期、分类统计和摘要。senders: - name: markdown_daily type: file template: | # {{.Date | date 2006-01-02}} 信息简报 共收录 {{len .Items}} 条更新。 {{$sources : group .Items SourceName}} {{range $sourceName, $items : $sources}} ## {{$sourceName}} {{range $items}} - **[{{.Title}}]({{.Link}})** {{truncate .Description 100}}... []({{.Link}}) {{end}} {{end}} *简报由 Brief 生成* path: /path/to/digest/{{.Date | date \2006-01-02\}}.md schedule: 0 20 * * * # 每天晚上8点生成{{.Date | date 2006-01-02}}.Date是推送触发的时间date是模板函数将其格式化为指定日期。注意Go的日期格式化模板是固定的2006-01-02 15:04:05这是一个易错点。{{$sources : group .Items SourceName}}使用内置的group函数将条目按源名称分组。这样简报就能按来源分类呈现更清晰。{{truncate .Description 100}}使用truncate函数将描述截断为100个字符防止摘要过长。path中也可以使用模板变量这样就能每天生成一个以日期命名的文件例如2023-10-27.md。4.2 实现内容过滤与去重策略除了基础的filters我们还可以利用brief的存储机制实现更智能的去重。基于内容的去重有时同一个新闻会被多个源抓取链接不同但内容相似。简单的链接去重不够。我们可以在parser中尝试提取更稳定的“唯一标识”比如文章的发布时间加标题的哈希值作为id字段。但brief默认使用链接(link)去重。更复杂的去重可能需要修改源码或编写自定义的processor如果项目支持的话目前版本主要靠filter。关键词黑名单/白名单filters的rule支持简单的表达式如contains包含、matches正则匹配。我们可以建立一个“黑名单”过滤器组放在最前面丢弃所有广告、软文或不想看的话题。filters: - rule: title matches (?i)促销|广告|赞助 # (?i)表示不区分大小写 action: drop - rule: description contains 免责声明 action: drop4.3 扩展抓取源应对反爬与动态页面对于简单的动态页面数据通过JavaScript加载http抓取器直接获取到的HTML可能不包含内容。这时有几种思路寻找隐藏的API用浏览器开发者工具的“网络”(Network)选项卡查看页面加载时发出的XHR或Fetch请求很可能找到返回JSON数据的API接口。然后可以尝试配置type: http但parser可能需要换成json类型如果brief支持的话或者需要自定义解析器。使用无头浏览器对于严重依赖JS渲染的页面如某些现代前端框架构建的网站brief内置的抓取器无能为力。一个可行的方案是自己写一个简单的服务使用Puppeteer(Node.js) 或Playwright、Selenium等无头浏览器工具来渲染页面并提取数据然后暴露一个简单的HTTP API。接着让brief的http抓取器去调用你这个API。这相当于为brief增加了一个“无头浏览器”适配层。利用第三方服务有些在线服务提供将网页转为RSS的功能如RSSHub、Kill the Newsletter!可以先将目标网页通过这类服务转为RSS再让brief去订阅这个RSS。注意事项在配置抓取间隔时务必遵守目标网站的robots.txt协议不要设置过短的间隔如几秒一次这会被视为恶意爬虫可能导致你的IP被封锁。对于个人使用将间隔设置在15分钟到几小时之间通常是安全和礼貌的。5. 运维、监控与问题排查将brief作为长期运行的服务需要考虑其稳定性和可观测性。5.1 以服务形式运行在Linux服务器上推荐使用systemd来管理brief服务实现开机自启、自动重启、日志集中管理。创建服务文件/etc/systemd/system/brief.service[Unit] DescriptionBrief - Personal Information Aggregator Afternetwork.target [Service] Typesimple Useryour_username WorkingDirectory/path/to/brief/workdir ExecStart/path/to/brief/binary -c /path/to/config.yaml Restarton-failure RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable brief.service sudo systemctl start brief.service # 查看状态和日志 sudo systemctl status brief.service sudo journalctl -u brief.service -f5.2 常见问题与排查技巧即使配置正确在长期运行中也可能遇到问题。下面是一个常见问题速查表问题现象可能原因排查步骤与解决方案抓取失败日志显示网络超时或连接拒绝1. 目标网站不可用或屏蔽了你的IP。2. 服务器网络问题。3. 配置的URL错误。1. 用curl或浏览器手动访问配置的URL确认可访问。2. 检查服务器网络连接。3. 对于偶尔的超时可以适当增加http抓取器配置中的超时时间如果支持。抓取成功但解析出的条目为空或字段不对1. 网页结构发生变化CSS选择器失效。2. RSS源格式不标准。1. 使用stdout发送器输出抓取到的原始HTML/XML用工具分析结构更新parser中的选择器。2. 对于RSS尝试用在线RSS验证器检查源是否有效。定时推送没有发生1. Cron表达式配置错误。2. 系统时区与配置时区不一致。3. 在计划时间点所有源都没有抓到新内容。1. 使用在线Cron表达式验证工具检查。2. 确认服务器系统时区和config.yaml中timezone配置一致。3. 检查日志看计划时间点前后相关源是否有抓取动作。这是正常现象说明没有新内容。数据库文件权限错误运行brief的用户没有data.db文件所在目录的读写权限。检查data.db文件的权限和所属用户组确保运行brief的用户有权读写。或者将data_file配置到一个有权限的路径。Telegram Bot 发送失败1.bot_token或chat_id错误。2. Bot 被用户屏蔽或未加入频道。3. 网络问题无法访问Telegram API。1. 用curl测试Bot Token是否正确curl https://api.telegram.org/botYOUR_TOKEN/getMe。2. 确保Bot已发送/start消息给用户或已作为管理员加入频道。3. 检查服务器网络是否能连通api.telegram.org。一个关键的调试技巧充分利用log_level: debug。在调试模式下brief会打印出非常详细的日志包括HTTP请求和响应的头部、抓取到的原始数据等。这能帮助你精准定位是网络问题、解析问题还是模板渲染问题。生产环境中建议改回info以减少日志量。5.3 性能与资源考量brief本身非常轻量占用资源极少。主要考量点在于抓取频率源越多、抓取间隔越短对目标服务器的请求压力越大也可能消耗更多本地带宽和CPU用于解析。请合理设置间隔做个有礼貌的爬虫。数据存储data.db文件会随着时间增长但速度很慢因为只存储条目ID/链接等元数据。定期清理并非必需但可以偶尔用sqlite3工具连接上去执行VACUUM;命令来优化数据库文件空间。内存占用长期运行内存占用稳定几乎可以忽略不计。6. 我的使用场景与心得在我自己的使用中我把brief用在了几个地方技术资讯聚合订阅了Hacker News的RSS、几个喜欢的独立技术博客、以及GitHub上关注项目的Release动态。每天下午6点Telegram Bot会给我推送一份摘要让我快速了解今天技术圈发生了什么有感兴趣的点再深入阅读。竞争情报监控配置了几个行业竞争对手的官网新闻中心用goquery抓取。每天上午9点生成一份Markdown简报自动保存到我的Obsidian笔记库的特定文件夹形成长期追踪记录。个人博客归档我订阅了自己的博客RSS。brief每次抓取到新文章后会将其标题和链接追加到一个本地Markdown文件中。这相当于一个自动生成的、按时间倒序的博客文章索引页我把它用在了我的静态网站侧边栏上。踩过最大的坑CSS选择器的脆弱性。我曾经用goquery抓取一个资讯网站运行得很好。但两个月后突然抓不到数据了。查日志发现解析条目为空。原来是网站前端改版整个HTML结构变了。解决方案是对于重要的、非RSS的信息源最好在配置里加上注释写明你当时使用的CSS选择器路径并且定期比如每月检查一下简报是否正常。或者如果可能尽量优先选择提供RSS/Atom订阅的源它们的结构更稳定。关于模板一开始总想做一个排版精美的简报后来发现对于每日快速浏览的场景信息密度和可读性比花哨的排版更重要。我现在用的Telegram模板就是最简单的“• 标题 (来源)”列表点击标题直接跳转。效率最高。最后brief的魅力在于它的“简单”和“可控”。它没有复杂的界面所有逻辑都通过一个配置文件呈现。这要求使用者有一定的动手能力和耐心去调试。但一旦配置完成它就像一个默默工作的数字园丁每天准时为你采摘好你关心的信息果实。这种将信息获取主动权夺回自己手中的感觉非常好。如果你也受困于信息碎片化不妨花点时间用brief为自己打造一个清爽的信息入口。
从RSS聚合到信息流定制：用Brief打造个人专属信息简报系统
发布时间：2026/5/16 18:09:45
1. 项目概述一个为“懒人”设计的极简信息聚合器最近在折腾个人知识管理和信息流聚合时发现了一个挺有意思的开源项目叫Nas4146/brief。乍一看这个名字你可能有点懵——“brief”是简报的意思那这个项目是干嘛的简单来说它就是一个高度可定制、极度轻量的个人专属信息聚合与简报生成工具。你可以把它理解为你为自己搭建的一个“私人助理”每天定时从你指定的信息源比如RSS订阅、特定网站、API接口抓取内容然后按照你喜欢的格式比如纯文本、Markdown、HTML整理成一份简洁的“简报”推送到你指定的地方比如Telegram Bot、邮箱、甚至是本地文件。为什么说它适合“懒人”因为信息过载的时代我们每天被各种App推送、新闻网站、社交媒体信息流轰炸精力被严重分散。brief的核心思想就是“化繁为简主动索取”。它不追求大而全的聚合而是让你精确地定义“我想看什么”、“以什么方式看”、“多久看一次”。你不用再去一个个打开网站或App所有你关心的信息会像一份精心编排的早报或晚报准时、安静地送到你面前。这个项目适合谁呢我认为有几类朋友会特别喜欢效率追求者与极简主义者希望减少无关信息干扰只获取核心内容。开发者或技术爱好者项目本身用Go编写部署简单配置灵活适合喜欢折腾、有自定义需求的人。需要追踪特定领域信息的人比如追踪竞争对手动态、关注特定行业新闻、监控GitHub项目更新等。希望建立个人知识库入口的人可以将简报自动保存为Markdown文件纳入你的笔记系统如Obsidian、Logseq形成每日信息摘要。接下来我就结合自己部署和使用的经验从头到尾拆解一下brief这个项目聊聊它的设计思路、怎么配置、如何扩展以及我踩过的一些坑。2. 核心设计思路与架构解析2.1 为什么是“轮询”“模板”brief的核心工作流程非常清晰可以用“采集-处理-渲染-推送”四个步骤来概括。它的架构设计体现了两个关键选择轮询拉取和模板化渲染。为什么选择轮询拉取而不是Webhook推送这是由它的定位决定的。brief是一个客户端主动抓取工具而不是一个服务端推送平台。Webhook需要信息源的支持比如GitHub、某些博客平台提供Webhook而轮询定期去检查是更通用、更底层的方案。它不依赖任何第三方服务的特殊接口只要你能通过HTTP访问到目标内容哪怕是简单的网页brief就有办法把它抓取下来。这极大地扩展了其信息源的范围。当然轮询的缺点是有延迟且对目标服务器有一定访问压力。因此brief允许你为每个信息源配置独立的抓取间隔interval对于更新不频繁的源如个人博客可以设置较长的间隔如12小时而对于新闻类源可以设置较短间隔如30分钟。模板化渲染是灵活性的关键。brief不假设你需要的输出格式。你可能想要一份纯文本简报发到Telegram一份带链接的HTML发到邮箱同时再生成一份Markdown存档。通过Go标准库中的text/template包brief实现了强大的模板功能。你可以在配置文件中为不同的“推送器”定义不同的模板。模板里可以访问到抓取到的所有数据如文章标题、链接、摘要、发布时间等然后按照你的想法编排它们。这意味着简报的最终样式完全由你掌控从简单的列表到复杂的带分类的日报都可以实现。2.2 项目结构一览虽然项目本身代码不算庞大但结构清晰便于理解和二次开发。主要目录和文件作用如下config/存放配置相关的代码核心是解析YAML配置文件。fetcher/抓取器模块。这里是项目的核心之一定义了如何从不同来源获取数据。目前内置了常见的抓取器如rss用于RSS/Atom源、http用于普通网页配合选择器提取内容。parser/解析器模块。抓取到的原始数据如XML、HTML需要被解析成结构化的信息标题、链接等。这里定义了不同抓取器对应的解析逻辑。render/渲染器模块。负责将结构化的数据按照配置的模板渲染成最终的文本输出。这是模板引擎发挥作用的地方。sender/发送器/推送器模块。决定将渲染好的简报发送到哪里。内置了file保存到本地文件、telegram通过Bot发送、stdout打印到控制台等。task/任务调度模块。负责管理各个信息源的抓取任务按照配置的间隔定时执行。main.go程序入口负责初始化配置、启动调度器。config.example.yaml最最重要的配置文件示例你的所有自定义行为都通过它来定义。这种模块化设计的好处是扩展性极强。如果你想增加一个新的信息源比如从某个特定API获取数据你基本上只需要在fetcher/目录下新增一个抓取器并在parser/下配套一个解析器即可。推送渠道的扩展也同样方便。3. 从零开始部署与基础配置实战理论说得再多不如动手跑起来。我们假设你有一台Linux服务器或本地开发环境从零开始部署和配置brief。3.1 环境准备与项目获取首先确保你的机器上安装了Go语言环境1.16版本。brief是Go项目我们可以直接通过go install来安装这是最推荐的方式因为它会自动处理依赖并编译出二进制文件。# 安装最新版本的 brief go install github.com/Nas4146/brieflatest安装完成后二进制文件brief会出现在你的$GOPATH/bin目录下通常是~/go/bin/。确保这个目录在你的系统PATH环境变量中。注意如果你遇到网络问题无法从GitHub拉取可以考虑先git clone项目到本地然后在项目根目录执行go build -o brief .进行手动编译生成的可执行文件在当前目录。另一种更“运维”的方式是使用Docker项目提供了Dockerfile。你可以自己构建镜像也可以使用我构建好的假设为my-brief:latest。用Docker部署的优势是环境隔离特别适合在服务器上长期运行。# 克隆代码 git clone https://github.com/Nas4146/brief.git cd brief # 构建Docker镜像 docker build -t my-brief . # 运行容器将本地配置文件目录挂载进去 docker run -d --name brief-service -v /path/to/your/config:/app/config my-brief3.2 核心配置文件深度解读配置文件是brief的灵魂它是一个YAML文件。我们以config.example.yaml为基础创建一个自己的config.yaml。下面我拆解每一个核心配置块。全局配置 (config)config: data_file: ./data/data.db # 用于存储抓取历史实现去重避免每次推送重复内容 log_level: info # 日志级别debug, info, warn, error timezone: Asia/Shanghai # 设置时区影响日志和模板中的时间显示data_file非常重要。brief通过一个SQLite数据库记录已经抓取并推送过的条目ID或链接。下次抓取时会自动过滤掉已推送的确保简报内容不重复。请确保运行brief的用户对该文件所在目录有读写权限。抓取源定义 (sources)这是配置的重头戏每个源代表一个你想追踪的信息渠道。sources: - name: cnbeta # 源名称自定义用于日志标识 type: rss # 抓取器类型这里是RSS url: https://www.cnbeta.com/backend.php # RSS源地址 interval: 30m # 抓取间隔30分钟。支持单位s(秒), m(分), h(时) parser: # 解析器配置用于从原始数据中提取字段 type: rss filters: # 过滤器可选用于进一步筛选内容 - rule: title contains 苹果 # 例如只保留标题包含“苹果”的文章 action: keeptype: rss这是最常用的类型适用于绝大多数博客、新闻网站的RSS/Atom订阅源。interval根据信息源的更新频率合理设置。技术博客可能一天一更设为24h快讯类新闻可以设为15m。太频繁可能对对方服务器不友好。filters这是一个强大功能。你可以基于标题(title)、描述(description)等字段进行过滤。action可以是keep保留匹配的或drop丢弃匹配的。比如你可以用drop过滤掉所有标题含“广告”的文章。对于没有RSS的网站怎么办这时就需要用到http抓取器和goquery解析器。这需要一些前端知识了解HTML结构。sources: - name: 某无RSS技术论坛 type: http url: https://example.com/latest-posts interval: 2h parser: type: goquery item_selector: .post-list article # CSS选择器选中文章列表中的每一项 fields: # 定义从每个item中提取哪些字段 title: selector: h2 a attr: text # 获取标签内的文本 link: selector: h2 a attr: href # 获取href属性 description: selector: .excerpt attr: textitem_selector是关键它必须能精确选中列表页中每一个内容项的HTML元素。fields定义了如何从每个“项”中提取数据。你需要用浏览器的开发者工具F12查看网页结构找到合适的CSS选择器。这是一个需要耐心调试的过程。推送渠道配置 (senders)定义简报生成后发到哪里。可以配置多个发送器。senders: - name: daily_digest # 发送器名称自定义 type: telegram # 类型telegram bot template: {{.SourceName}} 更新啦\n{{range .Items}}• a href\{{.Link}}\{{.Title}}/a\n{{end}} # 模板 schedule: 0 9,18 * * * # 发送计划Cron表达式。此处代表每天上午9点和下午6点发送 sources: [cnbeta, 某无RSS技术论坛] # 指定哪些源的内容汇总到这份简报里 telegram: bot_token: YOUR_BOT_TOKEN # 从 BotFather 申请 chat_id: YOUR_CHAT_ID # 可以是个人ID、群组ID或频道IDtemplateTelegram支持HTML格式所以我们可以用a标签做链接。{{.SourceName}}和{{range .Items}}是模板语法分别代表源名称和循环遍历所有文章项。schedule这是核心调度逻辑。brief并不是每次抓取后就立刻推送而是根据这里配置的Cron表达式来定时触发推送。它会收集自上次推送以来所有配置的源抓取到的新内容然后一次性渲染并推送。这实现了“聚合”和“定时”两个关键特性。除了telegram常用的还有type: file保存到本地。配置path指定文件路径适合用来做归档或给其他程序如静态站点生成器消费。type: stdout打印到控制台主要用于调试。type: email通过SMTP发送邮件需要配置SMTP服务器信息。3.3 首次运行与调试配置文件写好后建议先以调试模式运行检查配置是否正确抓取是否成功。# 在前台运行并指定配置文件路径 brief -c /path/to/your/config.yaml # 或者如果配置文件就在当前目录且名为config.yaml可以直接 brief观察日志输出。如果看到类似Fetched X new items from source [cnbeta]的日志说明抓取成功。如果看到错误通常是以下几种网络错误检查URL是否能正常访问。解析错误对于goquery解析器很可能是CSS选择器写错了无法匹配到元素。日志会打印抓取到的HTML片段帮助你调试。配置格式错误检查YAML缩进和冒号后面是否有空格。实操心得建议初期为每个源单独配置一个type: stdout的发送器并设置较短的抓取间隔如interval: 2m这样能快速在终端看到抓取到的原始数据结构和内容方便调试解析器配置。确认无误后再加入到正式的定时推送发送器中。4. 高级玩法与自定义扩展基础功能用顺手后就可以开始折腾一些高级功能了这也是brief乐趣所在。4.1 编写自定义模板打造个性化简报模板是决定简报最终样式的核心。brief使用Go的标准模板语法功能强大。假设我们想要一份更丰富的Markdown格式日报包含日期、分类统计和摘要。senders: - name: markdown_daily type: file template: | # {{.Date | date 2006-01-02}} 信息简报 共收录 {{len .Items}} 条更新。 {{$sources : group .Items SourceName}} {{range $sourceName, $items : $sources}} ## {{$sourceName}} {{range $items}} - **[{{.Title}}]({{.Link}})** {{truncate .Description 100}}... []({{.Link}}) {{end}} {{end}} *简报由 Brief 生成* path: /path/to/digest/{{.Date | date \2006-01-02\}}.md schedule: 0 20 * * * # 每天晚上8点生成{{.Date | date 2006-01-02}}.Date是推送触发的时间date是模板函数将其格式化为指定日期。注意Go的日期格式化模板是固定的2006-01-02 15:04:05这是一个易错点。{{$sources : group .Items SourceName}}使用内置的group函数将条目按源名称分组。这样简报就能按来源分类呈现更清晰。{{truncate .Description 100}}使用truncate函数将描述截断为100个字符防止摘要过长。path中也可以使用模板变量这样就能每天生成一个以日期命名的文件例如2023-10-27.md。4.2 实现内容过滤与去重策略除了基础的filters我们还可以利用brief的存储机制实现更智能的去重。基于内容的去重有时同一个新闻会被多个源抓取链接不同但内容相似。简单的链接去重不够。我们可以在parser中尝试提取更稳定的“唯一标识”比如文章的发布时间加标题的哈希值作为id字段。但brief默认使用链接(link)去重。更复杂的去重可能需要修改源码或编写自定义的processor如果项目支持的话目前版本主要靠filter。关键词黑名单/白名单filters的rule支持简单的表达式如contains包含、matches正则匹配。我们可以建立一个“黑名单”过滤器组放在最前面丢弃所有广告、软文或不想看的话题。filters: - rule: title matches (?i)促销|广告|赞助 # (?i)表示不区分大小写 action: drop - rule: description contains 免责声明 action: drop4.3 扩展抓取源应对反爬与动态页面对于简单的动态页面数据通过JavaScript加载http抓取器直接获取到的HTML可能不包含内容。这时有几种思路寻找隐藏的API用浏览器开发者工具的“网络”(Network)选项卡查看页面加载时发出的XHR或Fetch请求很可能找到返回JSON数据的API接口。然后可以尝试配置type: http但parser可能需要换成json类型如果brief支持的话或者需要自定义解析器。使用无头浏览器对于严重依赖JS渲染的页面如某些现代前端框架构建的网站brief内置的抓取器无能为力。一个可行的方案是自己写一个简单的服务使用Puppeteer(Node.js) 或Playwright、Selenium等无头浏览器工具来渲染页面并提取数据然后暴露一个简单的HTTP API。接着让brief的http抓取器去调用你这个API。这相当于为brief增加了一个“无头浏览器”适配层。利用第三方服务有些在线服务提供将网页转为RSS的功能如RSSHub、Kill the Newsletter!可以先将目标网页通过这类服务转为RSS再让brief去订阅这个RSS。注意事项在配置抓取间隔时务必遵守目标网站的robots.txt协议不要设置过短的间隔如几秒一次这会被视为恶意爬虫可能导致你的IP被封锁。对于个人使用将间隔设置在15分钟到几小时之间通常是安全和礼貌的。5. 运维、监控与问题排查将brief作为长期运行的服务需要考虑其稳定性和可观测性。5.1 以服务形式运行在Linux服务器上推荐使用systemd来管理brief服务实现开机自启、自动重启、日志集中管理。创建服务文件/etc/systemd/system/brief.service[Unit] DescriptionBrief - Personal Information Aggregator Afternetwork.target [Service] Typesimple Useryour_username WorkingDirectory/path/to/brief/workdir ExecStart/path/to/brief/binary -c /path/to/config.yaml Restarton-failure RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable brief.service sudo systemctl start brief.service # 查看状态和日志 sudo systemctl status brief.service sudo journalctl -u brief.service -f5.2 常见问题与排查技巧即使配置正确在长期运行中也可能遇到问题。下面是一个常见问题速查表问题现象可能原因排查步骤与解决方案抓取失败日志显示网络超时或连接拒绝1. 目标网站不可用或屏蔽了你的IP。2. 服务器网络问题。3. 配置的URL错误。1. 用curl或浏览器手动访问配置的URL确认可访问。2. 检查服务器网络连接。3. 对于偶尔的超时可以适当增加http抓取器配置中的超时时间如果支持。抓取成功但解析出的条目为空或字段不对1. 网页结构发生变化CSS选择器失效。2. RSS源格式不标准。1. 使用stdout发送器输出抓取到的原始HTML/XML用工具分析结构更新parser中的选择器。2. 对于RSS尝试用在线RSS验证器检查源是否有效。定时推送没有发生1. Cron表达式配置错误。2. 系统时区与配置时区不一致。3. 在计划时间点所有源都没有抓到新内容。1. 使用在线Cron表达式验证工具检查。2. 确认服务器系统时区和config.yaml中timezone配置一致。3. 检查日志看计划时间点前后相关源是否有抓取动作。这是正常现象说明没有新内容。数据库文件权限错误运行brief的用户没有data.db文件所在目录的读写权限。检查data.db文件的权限和所属用户组确保运行brief的用户有权读写。或者将data_file配置到一个有权限的路径。Telegram Bot 发送失败1.bot_token或chat_id错误。2. Bot 被用户屏蔽或未加入频道。3. 网络问题无法访问Telegram API。1. 用curl测试Bot Token是否正确curl https://api.telegram.org/botYOUR_TOKEN/getMe。2. 确保Bot已发送/start消息给用户或已作为管理员加入频道。3. 检查服务器网络是否能连通api.telegram.org。一个关键的调试技巧充分利用log_level: debug。在调试模式下brief会打印出非常详细的日志包括HTTP请求和响应的头部、抓取到的原始数据等。这能帮助你精准定位是网络问题、解析问题还是模板渲染问题。生产环境中建议改回info以减少日志量。5.3 性能与资源考量brief本身非常轻量占用资源极少。主要考量点在于抓取频率源越多、抓取间隔越短对目标服务器的请求压力越大也可能消耗更多本地带宽和CPU用于解析。请合理设置间隔做个有礼貌的爬虫。数据存储data.db文件会随着时间增长但速度很慢因为只存储条目ID/链接等元数据。定期清理并非必需但可以偶尔用sqlite3工具连接上去执行VACUUM;命令来优化数据库文件空间。内存占用长期运行内存占用稳定几乎可以忽略不计。6. 我的使用场景与心得在我自己的使用中我把brief用在了几个地方技术资讯聚合订阅了Hacker News的RSS、几个喜欢的独立技术博客、以及GitHub上关注项目的Release动态。每天下午6点Telegram Bot会给我推送一份摘要让我快速了解今天技术圈发生了什么有感兴趣的点再深入阅读。竞争情报监控配置了几个行业竞争对手的官网新闻中心用goquery抓取。每天上午9点生成一份Markdown简报自动保存到我的Obsidian笔记库的特定文件夹形成长期追踪记录。个人博客归档我订阅了自己的博客RSS。brief每次抓取到新文章后会将其标题和链接追加到一个本地Markdown文件中。这相当于一个自动生成的、按时间倒序的博客文章索引页我把它用在了我的静态网站侧边栏上。踩过最大的坑CSS选择器的脆弱性。我曾经用goquery抓取一个资讯网站运行得很好。但两个月后突然抓不到数据了。查日志发现解析条目为空。原来是网站前端改版整个HTML结构变了。解决方案是对于重要的、非RSS的信息源最好在配置里加上注释写明你当时使用的CSS选择器路径并且定期比如每月检查一下简报是否正常。或者如果可能尽量优先选择提供RSS/Atom订阅的源它们的结构更稳定。关于模板一开始总想做一个排版精美的简报后来发现对于每日快速浏览的场景信息密度和可读性比花哨的排版更重要。我现在用的Telegram模板就是最简单的“• 标题 (来源)”列表点击标题直接跳转。效率最高。最后brief的魅力在于它的“简单”和“可控”。它没有复杂的界面所有逻辑都通过一个配置文件呈现。这要求使用者有一定的动手能力和耐心去调试。但一旦配置完成它就像一个默默工作的数字园丁每天准时为你采摘好你关心的信息果实。这种将信息获取主动权夺回自己手中的感觉非常好。如果你也受困于信息碎片化不妨花点时间用brief为自己打造一个清爽的信息入口。
