凌晨11点，你推送了那行"应该是最后一次"的提交。GitHub Actions开始运行。红色叉号。

你点进工作流日志。4000行输出。真正的错误藏在npm安装提示、弃用警告，以及那个莫名其妙重试两次的任务之间。20分钟后你找到了：一个缺失的环境变量。或者一个 flaky test。或者某个特定任务里的Node版本不匹配。

打开网易新闻 查看精彩图片

这个循环太熟悉了。FailBrief的诞生，就是因为有人厌倦了这种循环。

这是一款GitHub App，专门监控Actions工作流。当构建失败时，它会做一件人类有无限耐心才会做的事：读完日志，找出问题，用 plain English 写一条评论——直接出现在你的PR页面。

评论里包含错误类型、严重程度、具体出错的代码行，以及建议修复方案。它出现在你本来就要看的地方。

最初以为这只是个"读日志、解释日志"的单功能工具。但团队想要更多。

Flaky test 检测。你知道那种测试：本地通过，CI失败，重试又通过，周二又失败。FailBrief追踪多次运行的通过/失败模式，标记统计上不可靠的测试，给出 flaky 分数和可能原因（时序、异步、共享状态等）。大多数CI工具完全忽略 flaky 测试。它们不应该。

一个仪表盘，追踪每个仓库的健康分数、失败趋势、MTTR（平均修复时间）、最常见的错误类别。用来回答那个"我们的CI到底怎么样"的问题——这个问题原本出奇地难回答。

Slack和Discord通知。有些团队希望失败被主动推送，而不仅仅是评论。

仓库健康评分。一个数字告诉你：这个仓库的CI是状态良好，还是在默默着火。

目标用户很明确：个人开发者，或2-50人的中小团队，使用GitHub Actions。开源维护者尤其如此——盯着贡献者的失败CI运行，反复解释同样的五种错误，是一种已知的痛苦形式。

500人的工程组织，有专门的平台团队和自定义日志解析器？你们大概有自己的方案。

FailBrief不是什么：它不是完全替代人工调试的工具，不能修复所有CI问题，也不是企业级可观测性平台。但它是一双可靠的第二双眼睛，永远不会累，永远不会在凌晨11点翻4000行日志。

安装很简单：GitHub App，选择仓库，完成。没有配置文件，没有工作流改动，没有YAML要编辑。免费版每月25次分析，跨无限仓库，足够大多数小项目验证是否有用。

目前有早鸟码（EARLYBIRDCODE），前100名用户可免费使用3个月Pro计划：500次分析、高级AI、Slack/Discord集成。地址是failbrief.com。

如果试了发现它漏掉了明显的东西，告诉开发者。比起默默卸载，他们更愿意听到"你们的AI对Rust构建错误很蠢"。评论、提issue，都可以。