开源天空相机：Claude Code 自动追流星，一晚捕获17颗

一位开发者打造了名为 openskycam 的开源天空相机系统，并让 Claude Code 接管了从检测到分类的完整流程。周六晚上，这套系统捕获了 17 颗流星，并在主人醒来前完成了整理。这背后的思路是：与其手动翻看数小时的夜间录像，不如让 AI 承担繁琐的筛选与模型迭代工作。

从手动标注到 AI 自主迭代

传统的流星检测流程相当低效：翻看整晚的视频、手动抽帧、打标签、重训模型，然后因为模型把每颗星星都标成飞行物而推倒重来。openskycam 的设计目标就是把这个循环交给 Claude。

系统会 7×24 小时录制 4K 天空影像，所有素材保存在本地磁盘。工作流负责抽帧、运行检测模型、将检测结果链接成轨迹以区分移动与静止目标，再把命中项分到流星、飞机、固定光源三个桶里。网站上的每一项功能同时也是 API 调用，加上内置的 MCP 服务器，Claude Code 可以直接驱动整个系统。

Claude Code 实际做了什么

据作者描述，Claude 的工作贯穿了整个夜间流程：

• 搭建了夜间工作流，每当新录像到达时自动运行；
• 审查每一帧检测结果，逐条接受或拒绝；
• 当模型持续把星星误判为飞行物时，它用作者已批准的检测结果构建数据集并重新训练模型。在从未训练过的夜晚数据上，星星误报率从约一半降到 7%，同时仍能捕获 90% 的流星；
• 每天早晨丢弃无效结果，只把有价值的流星推送到手机；阴天夜晚则安静地不发送任何消息。

这里的性能数据值得留意：误报率大幅下降的同时保持了高召回率，说明模型迭代没有以牺牲检测能力为代价。这是自动化闭环真正跑通的关键信号。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底推出的开放协议，用于让 AI 模型以标准化方式调用外部工具和数据源。可以把它理解成 AI 与软件系统之间的“USB 接口”：服务器端声明自己有哪些工具（tools）、资源和提示模板，客户端（如 Claude Code）便能自动发现并调用它们，无需为每个项目单独编写胶水代码。MCP 服务器本质上是一个遵循该协议的进程，通过 stdio 或 HTTP 与客户端通信。在 openskycam 中，作者把抽帧、检测、分类等能力封装为 MCP 工具，Claude 因此能“看见”系统有哪些操作可用，并按照服务器提供的 guides 和 skills 学习正确用法。这种设计把能力暴露与行为约束都放在服务器侧，是 AI 可靠驱动复杂管道的常见工程模式。

误报率与召回率 是评估检测系统的两个核心指标。误报率（false positive rate）指被错误标记为目标的样本比例，召回率（recall）指真实目标中被成功检出的比例。二者通常此消彼长：把判定阈值调严可以压低误报，但会漏掉真实流星；调松则相反。作者报告的“星星误报从约一半降到 7%，同时仍捕获 90% 的流星”，意味着模型在保持高召回的前提下大幅提升了精确度，说明重训带来的是真实的判别能力提升，而非简单收紧阈值。评估时使用“从未训练过的夜晚数据”也很关键——这属于样本外（out-of-sample）测试，能避免模型只是记住了训练集里的星星模式，是判断模型泛化能力的标准做法。

为什么 Claude Code 能可靠驱动它

让 AI 操作硬件与数据管道，最大的风险是不可控。这个项目的做法是把约束放在服务器端，而不是依赖提示词：

• MCP 服务器自带 guides 和 skills（build-a-workflow、find-detections、verify-changes），Claude 从服务器学习规则，而非从作者的口头指令中猜测；
• 护栏由服务器强制执行：任何密钥都不能创建新密钥，删除操作先显示预览并要求确认，编辑操作在遇到更新版本时会直接失败而非覆盖；
• 安装可无人值守运行，npm run setup -- --yes 从 .env 读取全部配置，缺少某项设置时会停下并指明缺失项；不过 Cloudflare 隧道、登录应用和 API 密钥仍需人工创建；
• 架构检查会在 Claude 把代码放到错误层级时让 make check 失败。

这套设计传递出一个明确观点：AI 自动化的可靠性来自系统边界，而不是模型自觉。

护栏（guardrails） 在 AI 自动化语境中，指独立于模型本身、由系统强制执行的安全约束。与提示词约束相比，护栏不依赖模型“听话”，而是从架构上让危险操作无法发生或必须经过确认。常见形式包括：权限分级（某些密钥或角色不能派生新密钥）、破坏性操作的两步确认（先预览再执行）、乐观并发控制（编辑时若数据已被更新则直接失败，而非静默覆盖），以及静态检查（如 make check 在代码放错层级时报错）。这种“纵深防御”思路源自传统安全工程：假定 AI 会犯错，把正确性保证下沉到服务器和构建流程中。对于无人值守运行的系统，护栏还承担了可审计性——每次拒绝和确认都留下明确边界，便于事后排查。

硬件与部署门槛

运行这套系统需要 RTSP 摄像头、树莓派、一台带大容量磁盘的机器（macOS 或 Linux，模型也可在该机器上运行，GPU 可选），以及一个带域名的 Cloudflare 账号。一条命令完成安装并引导配置，训练好的夜间模型已包含在仓库中。

涉及的仓库有两个：openskycam 负责相机、检测和 Claude 使用的工具，edmund-harness 则负责 iMessage 消息通道。

RTSP（Real Time Streaming Protocol） 是监控摄像头广泛支持的实时流传输协议，端口通常为 554。它只负责控制流会话（播放、暂停、参数协商），实际音视频数据多由 RTP 承载。之所以在天空相机项目中重要，是因为大多数网络摄像头都原生输出 RTSP 流，树莓派或主机可以直接拉流录制，无需依赖厂商云服务。这也意味着整套系统可以完全本地化运行，录像不出户。4K 分辨率下码率较高，对磁盘写入带宽和存储容量都有要求，因此作者强调需要一台带大容量磁盘的机器。若摄像头仅支持厂商私有协议，则通常需要先转封装为 RTSP 或使用其 SDK 接入。

产出与一点冷幽默

系统的每日视频从晚上 9:30 持续到次日下午 6 点：夜间每颗流星和飞机都附带 4K 相机的实际拍摄画面，白天每只被识别的鸟以粉点标记，每 10 次检测附一张真鸟特写。视频以整轮运行的单帧总览和若干图表收尾。

作者提到，某种版本的系统自 2024 年起就在观察他的天空，UFO 计数仍为零——流星很多，飞机更多，鸟类误判多到让他差点加入当地奥杜邦学会。这段自嘲背后是一个务实的结论：检测系统的价值不在于零误报，而在于误报可被批量清理、真实事件不被淹没。

如果你也在搭建类似的天文或自然观察自动化项目，这套「服务器端护栏 + 自训练闭环」的思路值得借鉴。