本文探讨了使用针对 COVID-19 优化的离散时间 **SEIRS**（易感者-潜伏者-感染者-康复者-易感者）模型进行的疾病建模。与基础 SIR 模型不同，SEIRS 模型考虑了病毒的潜伏期、再次感染的可能性以及免疫力的波动。
作者通过数学方法定义了暴露率 ($\beta$)、症状出现率 ($\sigma$)、康复率 ($\gamma$) 和免疫力丧失率 ($\xi$) 等变量。为了模拟现实世界的传播，作者使用矩阵来模拟个体之间的“社交亲密度”，并为接触更密切的人分配了更高的感染概率。
模拟结果显示，在一个没有社交距离限制的封闭人群中，病毒会迅速传播并导致大量死亡。然而，该模型也突显了干预措施的有效性：即使将社交接触减少四分之一，也能显著降低总死亡人数。作者得出结论：尽管这些模拟基于对人类行为的特定假设，但它们说明了社交距离在平抑疫情曲线及缓解病毒在社区内传播方面所发挥的关键作用。
每日HackerNews RSS
抱歉。
**claude-real-video** 是一款可以让大语言模型获取高质量、有意义的视频摘要的工具。与那些仅按固定间隔采样帧的标准方法不同——那种方法往往会漏掉快速剪辑或因重复的静态图像导致上下文溢出——该工具可以在本地对视频进行智能处理。 **主要功能包括：** * **场景感知提取：** 它能识别真实的场景切换，并使用密度下限来确保无论视频节奏如何，都能实现全面覆盖。 * **智能去重：** 它会移除近乎相同的帧，并避免重复发送模型已经看过的镜头（例如 A-B-A 剪辑），从而节省上下文空间。 * **音频集成：** 它可以通过 Whisper 生成转录文本或提取现有字幕，并能保存原始音轨供多模态模型使用。 * **隐私与高效：** 所有处理均在本地运行，无需上传至云端。 只需提供 URL 或本地文件，该工具就会输出一个包含关键帧、转录文本和清单的整洁文件夹。之后，您可以将这些文件放入 ChatGPT、Claude 或 Gemini 中，进行准确且高效的上下文分析。该工具需要 `ffmpeg` 支持，并可在 Windows、macOS 和 Linux 上运行。
**claude-real-video** 是一个 Python 工具，旨在优化大语言模型（LLM）处理视频的方式，以解决固定间隔帧采样效率低下的问题。该工具不再直接将原始视频发送给模型（这可能导致高昂的 Token 成本，或被标准 LLM 忽略），而是基于场景变化提取帧，并利用像素差算法剔除冗余镜头。它还集成了音频转录功能，从而生成一份可以轻松放入任何 LLM 对话中的综合“清单”。
在 Hacker News 的讨论中，用户称赞了该工具在显著节省 Token 的同时提升了模型理解能力。然而，该讨论帖也引发了以下争议：
* **模型选择：** 用户指出，在直接进行视频分析时，Gemini 通常在 Token 使用上更为高效。
* **技术手段：** 一些人认为基于帧的分析缺乏真正的运动理解，建议开发者应专注于描述视觉事件，而不是仅仅依赖图像序列。
* **命名：** 批评者建议修改项目名称，去掉其中的“Claude”，因为该工具与具体模型无关，本质上是一个预处理器。
* **实用性：** 一些用户担心，对于那些可以通过确定性计算机视觉轻松解决的任务，过度依赖 LLM 可能是不必要的。
这篇文章主张在构建高质量、安全关键型软件时，应采用一种严格的“短链（Short Leash）”方法来使用 AI 智能体。作者摒弃了目前流行的“氛围工程（vibe engineering）”趋势——即开发者将控制权下放给自主 AI 编排器——并指出这种“甩手掌柜”的做法必然会导致代码效率低下、漏洞百出且难以维护。
作者建议由专家开发者保持全程监督。其核心原则包括：
* **人在回路（Human-in-the-loop）：** 开发者必须主动分析 AI 提出的代码差异（diffs），拒绝未经授权的更改，并频繁介入以确保 AI 不偏离轨道。
* **细粒度提交（Granular Commits）：** 在每个子任务完成后进行提交以保护工作成果，从而防止 AI 导致的回归问题。
* **AI 辅助同行评审：** 将 AI 视为高级代码检查工具以捕获常见错误，而人类开发者仍需对架构完整性和逻辑负责。
* **强制审查：** 人类必须将自身经 AI 辅助编写的合并请求（pull requests）视为他人所写，并进行严格的逐行审查，以确保对代码库有完全的理解。
通过将 AI 视为增强工具而非人类专业知识的替代品，开发者可以在保持任务关键型系统所需代码质量的同时，获得更出色的成果。
关于“短链”（short leash）AI 编程方法的 Hacker News 讨论，凸显了开发者在与 Fable 等前沿 AI 模型协作方式上的两极分化。
“短链”方法指对 AI 输出进行严格的控制和审查，以确保代码质量。支持者认为，这对于维护代码完整性、防止模型“失控”以及确保开发者深入理解代码库至关重要。
然而，批评者认为这种方法是过时的微观管理。许多开发者推崇“YOLO”（自主）模式，即在隔离环境或容器中使用 AI，给予其更少的限制。他们认为现代模型有能力自行修复漏洞，而高强度的人工监督反而会阻碍生产力。
该讨论的主要观点包括：
* **“初级员工”之争：** 一些人认为 AI 相当于需要监督的初级到中级开发者；另一些人则认为它是具备高度能力的“资深工程师”，应当给予更多自主权。
* **安全与控制：** 业界共识是，在高风险领域（如银行、航空），仍需进行严格的人工核查。
* **“下一个标记”谬误：** 关于 AI 究竟仅仅是一个“标记预测器”，还是一个具备真正推理能力的工具，各方仍存在争议。
403 禁止访问
LMDB 是一个高性能、基于 B 树的事务型键值存储。它利用内存映射文件提供零拷贝数据访问，无需内部页面缓存，从而具备极高的内存效率。 其主要特性包括完全符合 ACID 标准，以及支持多版本并发控制架构，允许读写操作同时进行且互不阻塞。它采用写时复制策略，既防止了数据库损坏，也免除了崩溃后的恢复流程。与仅能追加的数据库不同，LMDB 会复用空闲页面，从而防止文件无限增长。 尽管 LMDB 功能强大，但需要谨慎管理。用户必须避免长事务导致数据库膨胀，并确保进程在持有活跃事务时不会异常中止。LMDB 具有线程感知能力，且支持跨进程并发访问，前提是开发者须遵循关于锁文件维护和线程局部事务的特定规则。值得注意的是，LMDB 不适用于远程文件系统。默认情况下，它提供只读内存映射以确保数据完整性，但也提供读写模式以获得更高性能，但这会带来应用程序级指针错误的风险。总之，LMDB 为嵌入式数据库需求提供了一种简单、可靠且无需维护的解决方案。
抱歉。
6月份的就业报告呈现了一幅具有误导性的美国劳动力市场图景。虽然失业率降至4.2%（为一年来的最低水平），但这种下降并非源于经济实力的增强，而是源于令人担忧的“大规模劳动力流失”。 劳动力参与率降至61.5%，创下2021年以来的最低水平，仅在一个月内就有72万人停止寻找工作。与以往通常归因于退休的趋势不同，最显著的下降发生在“黄金年龄”（25-54岁）的劳动者群体中，其参与率降至83.3%。此外，尽管机构调查显示就业人数有小幅增长，但实际就业人数却大幅下降。 经济学家担心，这些数据预示着劳动力市场正在收缩，许多失业者已放弃寻找工作。虽然一些专家认为数据可能存在波动，但这一趋势表明就业机会正日益减少，这使得人们对尽管失业率表面上很低、但实际上劳动力市场是否健康的状况产生了怀疑。
最近一份关于劳动力参与率降至50年来最低水平的报告，在Hacker News上引发了激烈的争论。用户们给出了相互矛盾的解读：一些人认为这些数据是人口老龄化和提前退休的副产品；而另一些人则认为这是一种“末日叙事”，并指出统计数据噪声过大，不足以说明存在系统性危机。
许多评论者对现代劳动力市场表达了深切的沮丧。他们指出，职场中的年龄歧视、大量AI生成的求职申请淹没了招聘系统，以及资深员工价值的贬低，都是现实问题。求职者们的共识是，传统的申请流程已经失效，迫使人们只能依赖小众的人际网络或“口口相传”来获得职位。
讨论还涉及了更广泛的经济议题，包括疫情期间财富转移的影响、住房成本的上升，以及年轻一代认为通往中产阶级稳定的道路已被摧毁的普遍感受。几位参与者分享了他们“退出”传统劳动力市场的故事——无论是搬到农村地区、选择自雇，还是干脆选择脱离——以此作为对一种他们认为“重资本、轻劳动”且无法为打工者提供保障的体制的某种反抗。
该项目旨在通过移植 Mesa 的 Lavapipe 软件驱动程序（运行于 CPU）为 NetBSD 带来 Vulkan 支持。该项目目前处于测试阶段，已成功在 NetBSD 10.1 (amd64) 上实现了 Lavapipe 驱动程序 (`libvulkan_lvp.so`) 的编译、链接和注册自动化。 主要成果包括： * **全面自动化：** 一套脚本允许用户将全新的最小化 NetBSD 安装环境转变为具备构建能力的开发环境。 * **可复现性：** 详尽的文档记录了包括依赖管理和构建配置在内的每一个步骤。 * **二进制分发：** 创建和获取预构建构件的框架已完成，旨在消除耗时数小时的手动构建过程。 虽然驱动程序已能正确向系统注册，但该项目目前侧重于构建栈而非运行时执行。未来的目标包括实现必要的 Vulkan 加载器 (`libvulkan.so.1`)，向上游提交小幅修复（如解决 GCC 格式说明符问题），并最终将工作集成到 `pkgsrc` 中。该项目为 NetBSD 加入其他主流操作系统以支持 Vulkan API 提供了一条透明且文档完备的路径。
Hacker News 上的一场讨论聚焦于用户“segaboy”的一个项目，旨在为 NetBSD 引入 Vulkan 支持。该项目目前专注于实现编译与链接，并使用了 Lavapipe 软件光栅化器，而非硬件加速的 GPU 渲染。
评论者们对该项目的范畴与实现方式展开了讨论。一些用户质疑软件渲染的实用性，而另一些人则指出 NetBSD 的 `pkgsrc` 仓库中已经存在现成的 Vulkan 组件——这一说法遭到了作者的反驳，理由是他个人在寻找可用软件包时遇到了困难。
技术讨论还涉及了 NetBSD 风格的工具链，特别是使用 `ftp` 工具来处理 HTTP/HTTPS 下载——这体现了该操作系统“扩展现有工具而非另起炉灶”的哲学。参与者指出，该项目似乎是一项非官方的早期探索，有人推测其文档可能使用了人工智能辅助编写。总体而言，社区对这一尝试现代化 NetBSD 图形栈的做法表示欢迎，但许多人同时也明确指出，实现真正的 GPU 加速 Vulkan 仍然是一个巨大的挑战。
作者认为，为了实现持久的工作流，开发者应摒弃外部工作流引擎，转而将工作流状态直接托管在应用程序的 Postgres 数据库中。 传统的分布式工作流往往难以应对部分故障，迫使开发者必须在应用层面构建复杂的机制来保障幂等性和原子性。通过将工作流元数据与应用数据存放在同一个数据库中，这些挑战可以通过原生的 ACID 事务来解决。 这种共存模式允许开发者将数据库更新与工作流检查点封装在同一个事务中。这提供了“恰好一次”（exactly-once）的执行语义，无需再进行繁琐的手动记录或幂等性检查。此外，它还简化了原子操作——例如在更新记录的同时触发下游任务——通过简单的数据库触发器取代了复杂的“事务性发件箱”（transactional outbox）模式。归根结底，通过将 Postgres 用作工作流引擎，开发者可以免去维护独立基础设施和对账任务的运营负担，从而构建出更可靠、更一致的分布式系统。
这次讨论的核心是**事务性发件箱模式（Transactional Outbox Pattern）**，这是一种在数据库和消息队列之间实现原子性的策略。
分布式系统中的核心挑战在于，无法同时对数据库和消息队列进行原子性更新。发件箱模式通过将数据库更新和“待发送消息”写入同一个本地数据库事务来解决此问题，从而确保只有在数据库更新成功时，消息才会被加入队列。
**辩论的重点总结如下：**
* **原子性与幂等性：** 该模式将原子性问题转化为了幂等性问题。由于处理过程为“至少一次投递”，消息消费者必须具备幂等性，以处理可能出现的重复事件。
* **中心化：** 批评者认为，使用数据库作为消息队列（即“分布式单体”）通过中心化数据源规避了真正的分布式系统复杂性。虽然这简化了数据一致性，但可能会导致性能瓶颈和紧耦合。
* **权衡：** 支持者将其视为一种务实的折中方案。它为关键状态变更提供了强一致性，同时将副作用分流至异步、可重试的后台进程中。归根结底，这往往是在架构纯粹性与实际运营可靠性之间做出选择。
### 问题总结：`AskUserQuestion` 工具出现意外超时 用户反馈在 Claude Code (v2.1.198) 版本中出现了一个回归问题：`AskUserQuestion` 工具在闲置 60 秒后会过早超时。 当工具触发此超时机制时，它会自动返回一条备选消息：“60秒内未收到回复……请使用您的最佳判断继续执行”，从而完全绕过了用户。用户指出这种行为并非预期，因为 `AskUserQuestion` 是一项关键的安全机制，旨在防止 AI 在未获得用户明确确认的情况下擅自操作。 **要点：** * **未经授权的行为：** 该工具默认切换为“自行判断”模式而非等待用户输入，规避了既定的安全协议。 * **非参数设置：** 用户确认此行为并非关联任何可配置的工具参数；这似乎是硬编码的内部超时限制或系统层面的变更。 * **版本回归：** 此功能在早期版本 (v2.1.196) 中工作正常。 * **文档缺失：** 官方更新日志中未提及此项变更，导致用户无法获知这一关键安全失效的原因。 用户要求进行修复，以恢复该工具在不自动继续的情况下等待用户输入的原始功能。
Hacker News 社区正在就“Claude Code”一项颇具争议的更新展开讨论：该更新为 `AskUserQuestion` 工具引入了默认 60 秒的超时限制。如果用户未在一分钟内回应，Agent 将自动跳过输入并继续执行。
支持者认为，这是智能体工作流发展的必然，能防止 Agent 在用户离开时空转，通过自主决策保持生产力。相反，批评者则认为这是一项“地雷”式功能，违反了“最小意外原则”。许多用户对该行为在默认开启且缺乏明确关闭说明感到沮丧，称其对于自动化编程助手而言是一种侵入性且具有风险的设计选择。
这场讨论突显了 AI 开发中更深层的矛盾：即如何平衡高度自主的“设置后无需关注”型 Agent 与人类监管之间的关系。尽管一些用户发现了非官方的变通方法（例如将环境变量设为极大值），但反对者的共识是，对核心功能进行如此重大的变更应采取默认关闭而非强制开启的方式。一名 Anthropic 开发者已承认了相关反馈，并确认计划通过补丁将该功能改为由用户选择开启。
本提案为 Java 虚拟机（JVM）引入了“严格初始化”（strictly-initialized）字段作为预览特性。与标准 JVM 字段不同（标准字段在未初始化时默认为 `null`、`0` 或 `false`），严格初始化字段必须在读取前被显式赋值。对于 `final` 字段，这确保了每次读取都能获得非默认的确定值。 **核心特性：** * **完整性：** 通过消除对默认值的可见性，防止程序因处理未初始化数据而产生错误（例如 `NullPointerException` 或不一致的 `final` 值）。 * **机制：** 编译器使用新的 `ACC_STRICT_INIT` 标志标记这些字段。JVM 在运行时强制执行静态字段的初始化规则，并利用增强的字节码校验确保实例字段在对象处于“早期（未初始化）”状态时即被设置。 * **性能：** JIT 编译器可将严格初始化的 `final` 字段视为“可信”，从而进行内存访问优化。 * **范围：** 这是一个 JVM 级别的模型，而非新的 Java 语言特性。其旨在支持未来如值类（Value Classes）和空限制字段（null-restricted fields）等语言增强，在不破坏现有代码兼容性的前提下，为开发者提供更强的完整性保障。
对不起。