这是为周末挑战：激情版提交的参赛作品
我构建了什么
我在哈科特港。本届世界杯期间，开球时间通常在凌晨1点、2点，有时甚至更晚——晚到赛程表上标注为某一天的比赛，在我所在的地方实际上已经是第二天了。我就这样观看了阿根廷在四分之一决赛中以3比1击败瑞士的比赛：官方赛程显示为7月11日的赛事，但在哈科特港，开球时已是7月12日。我在凌晨4点左右入睡，几小时后便起床工作。
这是我密切关注以来，首届在北美举办的世界杯，而从哈科特港的角度来看，时区换算令人头疼。
在此次挑战启动的四天前，我发布了workers-monitor——一个用于监控其他工作器是否出现异常的云flare工作器。它由每小时触发的定时任务驱动，从云flare的图形查询分析应用程序接口获取集群指标。一个确定性的阈值门控机制决定是否存在真正的问题。只有当门控被触发时，它才会调用克劳德·哈iku模型来区分信号与噪声。只有当哈iku确认存在问题时，它才会发送电报警报。在一个平静的小时内，不会产生任何对安思ropic公司的应用程序接口调用。
github.com/dannwaneri/workers-monitor
当此次挑战的主题发布时——构建一个受激情启发的项目——我没有寻求新的模式。我选择了刚刚验证过的那个模式，并思考还有什么值得这种克制。答案是睡眠。
夜守者由此诞生：结构相同，但领域不同。一个门控机制判断是否发生了决定性事件；一个大语言模型判断该事件是否值得让人醒来。电报则负责传递通过这两层筛选的信息。
其核心要点在于大语言模型的调用，而它的任务并非描述事件。模板可以将结构化数据转换为句子。它所做的是判断事件是否仍然重要——在一场4比0的比赛中的第4个进球，与第90分钟的扳平进球，虽然技术上都是“进球”事件，但前者不值得打断睡眠，后者却值得。我手机上的每个通知应用都能告诉我比分，但没有一个会问我是否应该在意。
演示
四分之一决赛于7月11日结束。半决赛将于7月14日开始——即此次挑战截止日期的后一天。在构建过程中，没有正在进行的实时比赛可供夜守者监控。
因此，本演示重放了阿根廷3比1瑞士比赛的真实事件流，并通过实际部署的流水线进行处理——相同的门控机制，相同的电报推送——而非捕捉正在进行的实时比赛。共触发了九次真实警报，比分通过代码确定性计算，而非交由模型复述，因此精确追踪了真实比赛进程：1比0、1比1、2比1、3比1。其中四个事件被评定为高重要性（第10分钟的首开纪录进球、第67分钟的扳平进球、第72分钟的红牌、加时赛第112分钟的反超进球），五个为低重要性（四张常规黄牌以及第120+1分钟的锁定胜局进球）。我宁愿向你展示真实的细分情况，也不愿将其简化为更整洁的形式。
[观看警报触发过程](https://i.imgur.com/EJfqdxC.mp4
代码
github.com/dannwaneri/nightwatch——一个新的代码仓库，首次提交于7月12日，处于此次挑战的时间窗口内。
我是如何构建它的
它从美国娱乐与体育节目电视网未公开的公共记分板端点获取数据——site.api.espn.com/apis/site/v2/sports/soccer/fifa.world/scoreboard。无需密钥，无需注册。这是非官方的，可能会在不通知的情况下发生变化；我构建的解析器会在发生这种情况时针对每个事件安全失败，而不是导致整个轮询崩溃。
门控机制本身：一个进球或卡牌必须在两个c
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
