博客监控器Skill：一条命令追踪博客与 RSS 更新，把内容巡检交给 AI
- 它就是一条命令：博客监控器Skill（英文名 blogwatcher）是一个 Go 编写的命令行工具，专注做一件事——追踪博客和 RSS/Atom feed 的更新。
- 安装极简：只需一条
go install命令即可完成安装，技能元数据中已声明依赖的可执行文件为blogwatcher。 - 命令体系清晰：
add、blogs、scan、articles、read、read-all、remove覆盖「加源—扫描—阅读—清理」完整闭环。 - 天生适合 AI 调用：作为 CLI 工具，它的输入输出都是文本，非常适合塞进 AI 助手的工作流里做自动巡检与摘要。
- 零账号、零订阅成本：本地命令行运行，不依赖网页端账号体系，数据留在自己的机器上。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 博客监控器Skill |
| 技能英文名 | blogwatcher |
| 技能ID | 13602 |
| 技能类型 | 命令行（CLI）技能 |
| 依赖可执行文件 | blogwatcher |
| 官方主页 | https://github.com/Hyaxia/blogwatcher |
它解决什么问题？
关注十几个技术博客、竞品官方博客、独立开发者站点的人，通常会陷入两种低效状态：要么每天手动挨个打开网页看有没有更新，要么把几十个站点塞进阅读器后，被未读数字淹没、逐渐放弃。博客监控器Skill 的思路是把「有没有更新」这件事变成一次命令调用的结果：scan 一跑，直接告诉你哪些源找到了新文章、新增了几篇。再配合 AI 助手，就能把「扫描—筛选—摘要」整条链路自动化。
一键安装的思路与步骤
这个技能的价值不只在工具本身，更在于它把安装方式写进了技能元数据（install 字段声明了 kind: go 与模块路径），所以「一键安装」的本质是：平台或 AI 助手可以直接读取元数据，替你执行安装命令，而不是让你去翻文档找安装方式。
具体操作分三步：
- 准备安装前提：机器上需要有 Go 环境（因为安装方式声明为 go 模块安装）。安装完成后，
blogwatcher需要位于系统 PATH 中——技能元数据里明确写了requires.bins: ["blogwatcher"]，也就是说技能运行时会去 PATH 里找这个可执行文件，找不到就无法调用。 - 执行安装命令：在终端运行官方给出的安装命令：
go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest这条命令会拉取github.com/Hyaxia/blogwatcher仓库中的cmd/blogwatcher并编译安装到 Go 的二进制目录（通常是$GOPATH/bin或$HOME/go/bin）。如果该目录不在 PATH 中，需要手动加入，否则技能仍会报「找不到命令」。 - 验证是否生效：先运行
blogwatcher --help，能正常打印帮助信息说明安装成功。再在 AI 技能平台中启用该技能，让它执行一次blogwatcher blogs，如果返回「跟踪的博客」列表（哪怕是空的），说明技能已能被正常调用。
提示：技能的安装入口、启用方式在不同平台上可能存在差异，具体以后续官方说明为准；本文只保证命令与依赖关系来自技能详情本身。
该技能的主要功能和特点
核心功能一览
- 添加监控源：
blogwatcher add "My Blog" https://example.com，用「名称 + URL」的方式把一个博客加入跟踪列表，名称是后续删除、识别时的标识。 - 查看跟踪列表：
blogwatcher blogs列出当前所有被跟踪的博客及其 URL，方便确认配置是否正确。 - 扫描更新：
blogwatcher scan是核心命令，会遍历所有源并输出每个源使用的抓取来源（如 RSS）、找到了多少条、其中多少条是新的，最后给出「找到 N 篇新文章总计」的汇总。 - 查看文章列表：
blogwatcher articles列出抓取到的文章，供后续阅读或标记。 - 标记已读：
blogwatcher read 1按序号标记单篇文章为已读；blogwatcher read-all一次性清空全部未读。 - 删除监控源：
blogwatcher remove "My Blog"移除不再关注的博客。 - 子命令自解释：任何命令都可以加
--help（如blogwatcher scan --help）来发现可用的标志和选项。
和普通工具比强在哪？
- 面向「变化」而不是「阅读」：通用阅读器强调的是阅读体验与信息流推荐，博客监控器Skill 强调的是「这一轮有没有新东西」，输出是结构化的扫描结果，天然适合被程序或 AI 消费。
- CLI 原生，可组合：输出为纯文本，可以被 AI 助手直接读取、判断、再加工成日报或摘要；也能被 shell 脚本、定时任务串联起来。
- 概念模型极简：只有「博客—文章—已读/未读」三个概念，没有分类、标签、推荐算法这些噪声，新用户几分钟就能理解全部命令。
- 无需账号体系：不涉及登录、订阅、同步，配置与状态都在本地。
如何使用该技能？
下面是一条从零到跑通的完整路径，命令均来自技能详情。
第 1 步：确认安装
运行 blogwatcher --help。能输出用法说明即代表可执行文件已就绪；如果提示 command not found，回到安装步骤检查 PATH。
第 2 步：添加第一个监控源
blogwatcher add "My Blog" https://example.com
这里第一个参数是自定义名称（删除时要用同一个名称），第二个参数是博客地址。建议名称起得可辨识，例如 "某团队技术博客"。
第 3 步：核对跟踪列表
blogwatcher blogs
输出形如：
跟踪的博客 (1):
xkcd
URL: https://xkcd.com
看到数量和 URL 都对，说明源已经登记成功。
第 4 步：执行扫描
blogwatcher scan
输出形如：
扫描 1 个博客...
xkcd
来源: RSS | 找到: 4 | 新: 4
找到 4 篇新文章总计！
解读方式：来源: RSS 表示该站点是通过 RSS 抓到的；找到 是本轮抓到的条目数；新 是此前没见过的条目数。第一次扫描通常全部为「新」，这是正常现象。
第 5 步：查看与处理文章
blogwatcher articles
拿到文章列表后，用 blogwatcher read 1 标记第 1 篇为已读，或用 blogwatcher read-all 一次性清空。下次 scan 时，已读文章不会再被计为「新」。
第 6 步：交给 AI 助手
在支持该技能的 AI 环境中，可以直接用自然语言下达指令，例如：「帮我扫描所有博客，把有新文章的源列出来，并按主题给我一份摘要」。AI 会调用 blogwatcher scan 与 blogwatcher articles，再基于输出做二次加工。这也是这个技能最省力的用法——把「巡检」变成一句话。
第 7 步：清理不再关注的源
blogwatcher remove "My Blog"
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 博客监控器Skill（blogwatcher） | 命令行博客/RSS 更新追踪工具 | 添加源、扫描更新、文章列表、标记已读、删除源 | 需 Go 环境，一条 go install 命令；使用只需记住 7 个左右子命令 |
开发者自建巡检、AI 助手自动化、脚本化定时任务 | 优势：极轻、纯文本输出、易被 AI 与脚本调用、无账号依赖；不足：无图形界面、无阅读排版，需要自己配定时任务 |
| 在线 RSS 阅读器（如 Feedly、Inoreader 类产品） | 面向大众的信息流阅读平台 | 订阅源、未读管理、分类标签、移动端同步、推荐 | 网页/App 注册即用，无需命令行 | 个人日常阅读、跨设备信息消费 | 优势：阅读体验好、多端同步、生态成熟；不足：依赖账号与网络服务，输出不是结构化文本，AI 集成需额外接口，付费档位以官方说明为准 |
| 终端 RSS 阅读器（如 newsboat 类工具） | 极客向终端阅读器 | 订阅、列表浏览、键盘交互阅读 | 需通过系统包管理器安装并手写配置文件 | 长时间待在终端的开发者 | 优势：终端内阅读体验完整；不足：配置成本较高，交互式而非「扫描输出」，不适合被程序批处理 |
| 网页变更监控服务（如 changedetection.io 类工具） | 页面级变更检测 | 针对任意网页抓取指定区域、比对差异、变更提醒 | 通常需自建服务或使用托管服务 | 无 RSS 的站点监控、价格页/公告页监控 | 优势：不依赖站点提供 feed；不足：部署与维护成本高，抓取规则需逐站配置，与「按篇管理文章」的模型不同 |
怎么选？ 如果你的目标是「每天用一条命令知道哪些博客更新了，并让 AI 帮我总结」，选博客监控器Skill；如果更看重阅读体验和多设备同步，选在线阅读器；如果要监控的是没有 RSS 的普通网页，页面变更监控类工具更合适。三者并不互斥，可以叠加使用。
该技能的典型应用场景与实际体验情况
场景一：开发者追踪技术博客与开源项目动态
角色：后端工程师。痛点：关注的十几个技术博客分散在不同域名，靠浏览器书签挨个点开，经常漏掉重要更新。使用方式：把所有源一次性 add 进去，每天早上跑一次 scan，有新文章再看 articles。实际体验：命令反馈非常直接，「找到 N | 新 M」一眼就能判断要不要继续看，比刷信息流省时间；注意点是站点必须提供 RSS/Atom 才行（扫描结果里会显示抓取来源），没有 feed 的站点加进去也扫不出内容。
场景二：内容运营与市场做竞品博客监控
角色：内容运营。痛点：需要定期汇报竞品最近发布了什么选题，人工整理耗时且容易漏。使用方式：把竞品官方博客全部加入跟踪列表，定期 scan 后把新文章交给 AI 生成选题对比摘要，read-all 收尾保持列表干净。实际体验：结构化输出让「整理」这一步几乎不用人工搬运，AI 拿到的是干净的文本列表；需要注意的是首次扫描会把历史文章全部算作「新」，建议先 read-all 一次建立基线。
场景三：AI 助手每日简报自动化
角色：效率工具用户。痛点：希望早上打开对话就有一份「今天关注领域发生了什么」。使用方式：在对话中直接说「扫描所有博客，有更新的话按主题给我三条要点」，AI 调用 scan 与 articles 后生成简报。实际体验：这是该技能最大的差异点——因为它是一个 CLI，输出即文本，AI 不需要处理网页解析和渲染；注意点是要确保技能已启用且 blogwatcher 在 PATH 中，否则 AI 调用会失败。
场景四：个人知识管理与学习跟踪
角色：学生 / 自学者。痛点：学习资源站点更新零散，想系统跟进但缺乏抓手。使用方式：把课程博客、专栏、个人博客加进列表，每周扫描一次，把新文章逐条标记已读形成学习记录。实际体验：上手成本极低，几乎不需要学习新概念；注意点是它只管「发现更新」，不负责保存正文，需要自己配合笔记工具。
该技能能为用户带来的价值
- 把「巡检」从分钟级压到秒级：过去打开 N 个站点需要 N 次点击与等待，现在一次
scan就能得到全量结果。源越多，节省越明显。 - 显著降低工具门槛：不需要搭建服务、不需要数据库、不需要账号，一条
go install加七个命令就是全部学习成本，非专业运维也能用起来。 - 让 AI 真正参与信息流：CLI 的文本输入输出天然适配 AI 助手，这是很多图形化阅读器难以做到的。用户得到的不是一个「更多信息」的工具，而是一个「更少操作」的流程。
- 可脚本化带来的长期价值：由于每个动作都是独立命令，可以组合成定时任务、巡检脚本、日报生成器，形成一套可复用的个人情报流水线。
- 数据自持：配置与已读状态留在本地，不依赖第三方服务是否持续运营，长期使用没有「平台迁移」的隐性成本。
常见问题 FAQ
Q1：这个技能怎么安装？需要什么前置条件？
A：需要机器上有 Go 环境，然后执行技能详情给出的安装命令 go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest。安装完成后确认 blogwatcher 可执行文件在系统 PATH 中（技能元数据要求 bins 中存在 blogwatcher），用 blogwatcher --help 验证。具体安装入口与平台启用方式以官方说明为准。
Q2：使用它需要付费吗？
A：该技能是一个开源命令行工具，主页为 GitHub 仓库 https://github.com/Hyaxia/blogwatcher，是否收费、是否有额外服务以后续官方说明为准。工具本身不依赖订阅账号，运行在本地。
Q3：它和 Feedly、Inoreader 这类阅读器有什么区别？
A：定位不同。阅读器面向「阅读」和「信息流消费」，强调多端同步与排版体验；博客监控器Skill 面向「变更检测」，输出的是结构化的扫描结果，更适合被脚本和 AI 助手消费。如果你只在意外观和移动端阅读，选阅读器；如果你想让 AI 帮你做巡检和摘要，选这个技能。
Q4：第一次扫描为什么所有文章都显示为「新」？
A：因为本地还没有已读基线，所有抓到的条目都是第一次见到。建议首次 scan 后执行一次 blogwatcher read-all，之后的扫描结果就只反映真正的增量更新。
Q5：添加了博客但扫描不到内容怎么办？
A：先确认该站点是否提供 RSS/Atom feed——技能说明中明确其用途是追踪博客和 RSS/Atom feed 更新，扫描结果里也会显示每条源的抓取来源。如果源本身没有 feed，需要换用页面变更监控类工具。此外可用 blogwatcher <command> --help 查看是否有相关选项，具体能力以官方说明为准。