一名英国女孩通过全球首个基因疗法治愈耳聋

一名18个月大的英国女孩奥帕尔·桑迪成为全球首位接受突破性基因疗法试验的患者，其听力已基本恢复正常。

奥帕尔因OTOF基因缺陷导致的听觉神经病天生完全失聪。这种疾病会中断从内耳到大脑的神经信号传递。她在剑桥大学医院NHS基金会信托的阿登布鲁克医院接受了由生物技术公司Regeneron开发的“一次性”基因疗法。

该疗法通过手术将一份正常工作的OTOF基因注入内耳，以替代缺陷基因。奥帕尔于去年9月在右耳接受了治疗。术后四周，她的听力开始改善，能对响亮的拍手声转头。术后24周的测试显示，她甚至能听到耳语般微弱的声音，听力接近正常水平（约25-30分贝，正常听力为20分贝）。

首席研究员曼诺哈尔·班斯教授称结果“远超预期”，并认为这可能成为治愈此类耳聋的方法。该疗法是“一次性”治疗，有望让患者治疗后恢复正常生活。

目前，该临床试验（1/2期Chord试验）分为三部分进行：

1. 三名儿童（包括奥帕尔）先接受单耳低剂量治疗。
2. 另一组三名儿童将接受单耳高剂量治疗。
3. 若证明安全，更多儿童将同时接受双耳治疗。

试验计划从英国、西班牙和美国招募多达18名儿童，并进行五年随访。第二名儿童已在剑桥大学医院接受治疗并取得积极效果。

目前，听觉神经病的标准治疗是人工耳蜗。奥帕尔在接受基因治疗的同时，左耳也植入了人工耳蜗以确保及时获得听力。她是全球首位接受Regeneron疗法的患者，也是目前已知最年轻的接受者。

班斯教授认为，这项试验“标志着耳聋治疗的新时代”，并可能推动其他遗传性听力疾病的基因疗法发展。但他同时指出，该疗法目前尚未纳入英国国家医疗服务体系（NHS）的常规服务。

英国国家聋儿协会的政策顾问马丁·麦克莱恩对此研究表示欢迎，强调应从开始就为聋儿提供支持，并帮助家庭就医疗技术做出明智选择。

Steve Albini 生平概述

Steve Albini，独立摇滚界的标志性人物，作为制作人（他更倾向于“工程师”称呼）和表演者，于5月7日因心脏病去世，享年61岁。其所属录音室电气音频（Electrical Audio）的工作人员向Pitchfork证实了此消息。

职业生涯与影响

Albini是乐队Big Black和Shellac的核心成员，也是录音室领域的传奇人物。他录制了大量经典专辑，包括Nirvana的《In Utero》、Pixies的《Surfer Rosa》和PJ Harvey的《Rid of Me》等。他以其粗犷、充满现场能量的模拟录音风格而闻名，深刻影响了众多后辈摇滚、朋克及金属音乐人，如Mogwai、Sunn O)))等。他始终是音乐产业剥削行为的直言不讳的批评者。

早期经历与理念

Albini出生于加州帕萨迪纳，后随家人定居蒙大拿州。青少年时期接触Ramones乐队后，他投身于伊利诺伊州的芝加哥朋克场景。他强调自己是音乐社区的参与者而非掠夺者，并视其音乐生涯为文化记录的一部分，认为音乐应比创作者更长久。

工作原则

他坚守个人原则：

• 从不收取录音版税，即使参与录制了销量超1500万张的《In Utero》。
• 保持低廉的日费率。
• 在电气音频录音室，他要求艺术家在录音首日详细书面描述每首歌，以最大化利用付费的录音时间，避免误解。
• 录音时他有时会阅读或玩拼字游戏，以此保持注意力敏锐，避免过度干预。

争议与反思

其职业生涯早期因使用挑衅性乐队名称（如Rapeman）和言论而备受争议。尽管曾辩解其行为意图，但他后来多次公开道歉，承认自己早年基于特权和无知的立场是错误的，并表达了悔意。

个人生活与成就

• 作为Shellac乐队成员，乐队即将在下周发行十年来的首张专辑《To All Trains》。
• 他是一名出色的扑克玩家，曾在2018年和2022年两次赢得世界扑克系列赛（WSOP）金手链。

生命哲学

当被问及退休后如何看待其职业生涯时，他曾表示：“我不在乎别人怎么看……我正在做，而且明天还会继续做下去，这就是对我全部的意义。”

xkcd于4月发布了“Machine”，这是其第15次愚人节项目。项目灵感源自经典游戏“Incredible Machine”，希望让全球xkcd读者各自创作一个小机关，并拼接为巨型鲁布·戈德堡机械装置。本文主要记录项目三周开发过程及设计思路。

项目团队与职责：

• Randall、davean、作者负责美术、后台、前端。
• Ed White开发了审核界面。
• Alex Garcia实现了部分小组件及React物理集成。
• Kevin Cotrone开发元机器生成器，确定每块输入输出并搭建后台。
• Conor Stokes等负责物理引擎组件。
• Liran Nuna开发底部漂浮船只。
• Benjamin Staffin改进部署流程并参与审核。
• 多位成员参与审核与创意反馈。

设计初始： 团队早期通过脑暴确定核心玩法，即每人贡献小机制组成一张巨型“拼图”。参考以往互动漫画项目，发现玩家内容贡献如未配合足够约束和目标，易陷入混乱，难以激发创造力。因此本次更重视用户体验和机器设计的合理约束。

核心设计原则：

1. **优先玩家表达自由，不强求机械正确性。**选择更宽松机制，允许玩家构建高度不确定甚至“坏掉”的机关。为此引入主动审核，以过滤不符约束或者不适内容。
2. **设计硬性约束，鼓励兼容可替换的机关。**输入输出采用固定规则，提前生成整张机器地图（由Kevin实现），并逐步调整难度。玩家需保证自己机器输出与输入相匹配，防止积球或延迟。审核环节通过随机输入测试机器稳定性。
3. **机器30秒内须达到稳态。**设定球体30秒后自动消失，防止长时间积累导致物理引擎卡顿或机器出错，简化审核流程。每块审核时手动快照30秒后的状态，确保展示效果。

架构与实现细节：

• **物理与渲染：**采用Rapier物理引擎（Rust+WASM），结合React的实现组件生命周期与物理对象绑定，便于开发和热更新。全部用DOM渲染，配合性能优化（比如视野范围内渲染、球体自定义渲染器等），最终可支撑上千球体表现。
• **机器“超现实”表现：**只模拟玩家视窗附近的机关，其他部分用对应稳态快照来展示。审核界面结合球体消失机制，确保每块展示不会积累过多误差。部分机器因随机输入而产生有趣联动效果，比如“Jamslunt Interfoggle”机制，展现意外的球体行为。
• **后台与审核：**后台用Haskell与Redis，API接口用OpenAPI同步类型。前端利用TanStack Query缓存和刷新机器数据。审核界面以定时器保证不急于通过设计；后期加入加速滑块，提升审核效率。队列排序偏向“有趣”设计，审核员可以挑选最具创意或最简约方案。

用户协作与创意： 本项目注重在高自由度与硬性约束之间平衡，通过精巧机制设计和主动审核保护玩家体验与终端效果。各块机关不可预知的联动产生了许多意外但有趣的机关行为，体现玩家集体创造的活力。

技术总结：

• 采用组件化架构、物理引擎与DOM优化实现高效渲染。
• 机器局部快照展示，简化全局模拟难题。
• 审核机制兼顾效率和效果，保障最终机器稳定与创意。

不足与展望： 设计中牺牲了部分玩家提交内容的展示比例，未来希望提供更多历史数据浏览。源代码已开放，欢迎有兴趣者尝试全局模拟等性能挑战。

“Machine”项目展示了协作式创意游戏的设计挑战和技术创新，经验可用于更大规模的互动创作项目。

这篇文章讲述了作者职业生涯中一次关键的经历，核心事件是他为了确保项目成功，向当时公司的CTO隐瞒了部分真相。

项目背景是CTO决定将一个关键项目外包给一家声称有成熟产品的科技服务公司。然而，该公司实际提供的只是需要大量定制化的半成品，结合了外包软件和定制软件的所有缺点。项目团队私下普遍认为这是一个糟糕的主意，但由于CTO频繁更换直属下属，无人敢提出异议。

项目集成阶段，技术问题彻底暴露：供应商产品将客户交易记录存储在一个巨大的JSON文档中，随着数据量增长性能急剧下降。当真实数据开始导入后，很快触碰到了当时所用MongoDB数据库的单文档16MB大小限制。

面对这个“阻碍性bug”，公司决定对客户隐瞒真相，并秘密启动一个内部项目来替换供应商的系统。作者当时作为“年轻热情的开发者”，被委派带领一个仅由3人组成的团队，在两个月内（包括节假日期间）重建整个核心系统。

关键时刻在于，当CTO宣布取消团队假期、要求继续“死亡行军”时，作者做出了决定。他让精疲力竭的团队成员休假一周，自己则每天向CTO汇报团队其实已经完成的工作进度，制造出团队仍在努力工作的假象。

休假归来的团队状态恢复，最终在一月份成功交付了新系统，并取得了良好的上线效果。作者将这次“说谎”视为职业生涯中最骄傲的时刻之一，因为它遵循了父亲的建议：“做好工作往往意味着在必要时，要绕过老板去完成该做的事。”

本文介绍了作者利用文本嵌入技术对Hacker News上约4000万条帖子和评论进行语义分析、可视化与探索的项目过程与成果。

核心目标：

• 实现基于语义的强大搜索（超越关键词匹配）。
• 基于兴趣进行个性化内容推荐。
• 分析社区内不同话题的情感倾向与流行度。

技术实现流程：

1. 数据获取：通过HN的公开API并行抓取所有项目（帖子和评论），使用Node.js的Worker Threads提高效率，并记录进度以支持断点续传。
2. 生成嵌入：
   • 初始尝试仅用帖子标题生成嵌入，但发现效果不佳（如Ask HN/Show HN聚类）。
   • 改进方案：对于链接帖，爬取链接网页正文；对于评论，拼接祖先评论以构建上下文。使用BGE-M3和jina-embeddings-v2模型生成高质量文本嵌入。
   • 为处理海量数据，使用RunPod的GPU集群和自定义的db-rpc、queued服务优化分布式推理的数据管道。
3. 降维与可视化：
   • 使用UMAP将高维嵌入降至2维，用于探索性可视化。
   • 将数据点划分为网格瓦片，按评分筛选代表性帖子。
4. 构建交互式地图：
   • 开发类似Google Maps的网页应用，支持缩放、平移和点击查看详情。
   • 使用Canvas渲染，并优化标签显示（基于评分和防碰撞）。
   • 通过高斯模糊+对数缩放生成“地形图”以显示内容密度分布，并用SVG路径实现清晰边界。
   • 手动标注“城市”（如Programming, Startups）作为导航地标。
   • 为降低延迟，在全球多个区域部署边缘服务器存储和分发地图数据。
5. 核心功能实现：
   • 语义搜索：基于余弦相似度计算查询与所有嵌入的距离，结合帖子评分和时间衰减进行排序，返回相关结果。
   • 虚拟子社区：根据用户输入的关键词或描述，自动筛选相似度高的帖子和评论集合。
   • 影响力分析：通过计算用户评论与特定话题的相似度总和，识别该话题下最活跃的用户。
6. 大规模分析：
   • 使用情感分类模型（如TweetEval）对3000万条评论进行情感分析，可追踪话题（如Rust）随时间的情感变化。
   • 利用GPU加速库（CuPy/cuDF）进行快速的数据分析查询。

关键洞察与优化：

• 余弦相似度比欧氏距离更适合文本嵌入，因为它能忽略文本长度差异，更关注语义方向。
• 在搜索和推荐中，社会证明（如帖子评分） 与语义相似度同样重要。
• 对于海量向量运算，后过滤（先计算相似度再筛选）通常比前过滤更高效。
• 使用GPU进行数据分析可大幅提升查询速度。

成果与开放资源：

• 项目演示网站上线，包含交互式地图、搜索、虚拟社区和数据分析工具。
• 所有代码（TypeScript/Rust/Python）和数据（嵌入、元数据、文本）均已开源，供社区进一步探索和创作。

作者希望通过开放这些工具和数据，鼓励社区进行更深入的分析、改进或开发新的应用。

Datatype99：纯 C99 的代数数据类型实现

简介

Datatype99 是一个纯 C99 库，提供安全、直观的代数数据类型，支持穷尽模式匹配和编译时内省。无需外部工具，仅依赖一个头文件 datatype99.h 和其元编程依赖 Metalang99。

亮点

• 类型安全：在编译时捕获不正确类型变体、非穷尽模式匹配和无效字段访问。
• 可移植：只需标准 C99 编译器，无需标准库或特定平台功能。
• 可预测：形式化代码生成语义，保证数据布局一致。
• 可理解错误：对错误代码提供清晰错误消息。
• 实战测试：已在 OpenIPC 的实时流媒体软件中应用，包括 RTSP 实现和大量代码。

安装

库由 datatype99.h 和依赖 Metalang99 组成。安装方式：

• 添加 datatype99 和 metalang99/include 到包含目录。
• 设置编译器选项（如 GCC 的 -ftrack-macro-expansion=0 或 Clang 的 -fmacro-backtrace-limit=1）以避免宏展开错误。
• 推荐使用 CMake 的 FetchContent 进行集成。

用法

Datatype99 是标签联合的语法糖，提供更安全简洁的代码。

• 定义数据类型：使用 datatype 宏定义代数数据类型，如二叉树：

  datatype(
      BinaryTree,
      (Leaf, int),
      (Node, BinaryTree *, int, BinaryTree *)
  );
  

• 模式匹配：使用 match 和 of 进行穷尽模式匹配，绑定变量为指针类型，支持变异：

  int sum(const BinaryTree *tree) {
      match(*tree) {
          of(Leaf, x) return *x;
          of(Node, lhs, x, rhs) return sum(*lhs) + *x + sum(*rhs);
      }
      return -1; // 处理无效输入
  }
  

• 构造变体：生成内联静态值构造函数，如 Leaf(5) 和 Node(&leaf5, 123, &leaf7)。
• 其他模式：使用 otherwise 匹配默认情况，用 _ 忽略绑定。

语法和语义

• EBNF 语法：定义 datatype、record、match、of 等宏的语法。
• 宏版本：提供缩短和后缀版本（如 match 和 match99），通过定义 DATATYPE99_NO_ALIASES 避免名称冲突。
• 语义：
  • datatype 生成标签联合、结构体和值构造函数。
  • record 定义记录类型（结构体）。
  • match 扩展为 switch 语句，of 定义匹配分支。
  • 支持派生过程，允许生成接口实现等。
• 单元类型：UnitT99 表示单值类型。
• 派生辅助属性：通过宏传递参数给派生器。

杂项

• 版本控制宏与 Metalang99 类似。
• 提供 Metalang99 兼容宏版本用于元编程。
• 内置 dummy 派生器生成空内容。

指南

• 使用 Clang-Format 时，通过注释禁用格式化。
• 在数据类型定义后 #undef 派生辅助属性。
• 使用描述性名称提高代码可读性，如通过类型别名或独立结构体。

陷阱

• 避免在 of/ifLet 语句中使用顶级 break/continue；改用 goto 标签。
• 数组作为变体参数时需放入独立结构体。
• 绑定变量可变，注意 const 限定。

FAQ 摘要

• 为何用 C？：历史原因、稳定 ABI、现有代码库集成、平台兼容性。
• 如何工作？：基于 Metalang99 元编程，生成标签联合和模式匹配代码。
• C++ 支持：兼容 C++11 及以上。
• 编译时错误：库检测语法错误（如缺失逗号），非穷尽匹配等错误通过编译器警告报告。
• 测试编译器：支持 GCC、Clang、MSVC、TCC。

故障排除

• 警告 "control reaches end of non-void function" 时，确保 match 中处理所有变体或添加默认返回值。

项目概述

• 项目名称：grafychat
• 核心定位：一款全能型AI聊天客户端，提供非线性用户界面体验。
• 主要特点：
  • 画布扩展：用户可以在画布上自由扩展和组织想法。
  • 功能集成：平台集成了多种AI功能，旨在提供一体化的使用体验。

目标与愿景

• 该项目旨在优化与AI（如ChatGPT）的交互方式，通过创新的非线性界面，帮助用户更直观、更高效地管理和发散思维。

文章标题： 一致性大语言模型：将LLM转换为并行解码器以加速3.5倍推理

核心概述： 本文介绍了一种名为一致性大语言模型的新方法。该方法通过微调预训练的LLM，使其能够从传统的逐词顺序解码转变为高效的并行解码，从而显著降低推理延迟。实验表明，CLLMs能在不增加额外内存开销的情况下，实现2.4倍至3.4倍的生成速度提升。

背景与问题：

• 传统LLM采用自回归解码，逐个生成词元，导致生成长文本时延迟高。
• 雅可比解码是一种将顺序生成转化为并行求解非线性方程组的方法，理论上可并行预测多个词元。但在实践中，由于AR训练的LLM在前序词元出错时难以生成正确后续词元，雅可比解码的加速效果甚微（平均仅1.05倍）。
• 现有加速技术（如前瞻解码、投机解码）需要额外的模型组件或草稿模型，增加了推理时的内存开销。

CLLMs的核心方法：

1. 核心思想： 微调预训练LLM，使其能够将雅可比解码轨迹中任意随机状态直接映射到与AR解码结果相同的固定点。这模拟了人脑先形成完整句子再逐词表达的认知过程。
2. 训练数据： 为目标LLM收集雅可比轨迹。对于每个提示，通过雅可比解码生成一系列直至收敛的序列。
3. 训练目标： 联合优化两个损失函数：
   • 一致性损失：确保模型从轨迹上的任何中间状态都能直接输出最终的正确序列。分为全局一致性和局部一致性两种形式。
   • AR损失：基于目标LLM的原始生成结果计算，用于防止模型偏离原始能力，保持生成质量。

实验结果：

• 速度提升： 在多个任务（文本到SQL、代码补全、数学推理、开放域对话）上，CLLMs实现了2.4倍到3.4倍的推理加速。
• 性能对比： 其速度与或优于Medusa2和Eagle等快速推理技术，但无需在推理时引入额外的内存开销或架构修改。
• 效率机制： 训练后的CLLMs展现出**“快速前向”** （一次迭代中预测出多个连续正确词元）和**“固定token”** （即使前序词元错误，也能提前并正确地预测某些词元且后续保持不变）现象，这使其雅可比轨迹收敛速度比原始LLM快2倍。
• 训练成本： 微调成本较低，仅需使用预训练数据的一小部分（如0.01%至0.2%）来生成雅可比轨迹进行训练。
• 语言洞见： 模型通过训练掌握了搭配（如“动词+介词”、“动词+名词”等固定组合）等语言结构，从而能够同时预测多个词。

结论： CLLMs是一种高效且内存友好的LLM推理加速方法。它通过一致性训练，将预训练的顺序解码器转换为并行解码器，在不牺牲生成质量的前提下，显著减少了推理延迟。

《追踪从亚马逊到你汉堡的非法巴西牛肉》摘要

调查背景与核心发现
巴西是全球最大牛肉出口国，养牛业是亚马逊森林砍伐的主要驱动力。记者马塞洛·戈梅斯及其团队通过调查揭示，全球最大肉类加工企业JBS的供应链与非法毁林及奴工问题存在关联，并将问题牛肉销往欧美超市及快餐店。

调查方法

1. 数据交叉验证：利用巴西2011年以来的透明度立法，收集环境、社会违规数据，结合卫星图像识别毁林农场，追踪从牧场到屠宰场、再到消费端的全流程。
2. 消费端追踪：派遣研究员赴欧美拍摄巴西牛肉包装标签，通过出口编号反向追溯至加工厂。
3. 多方协作：与工会、原住民社区合作获取实地信息，识别涉事牧场并规避暴力风险。

供应链漏洞与“牛肉洗白”

• 牛只在不同农场间多次转移，掩盖非法来源。企业仅记录直接供应商，前期环节难以监控。
• 家族成员通过土地交易、边界调整等手段将“脏牛”混入合法供应链。

影响与反应

• 欧洲零售商：Sainsbury's、家乐福、欧尚等六大零售商暂停采购JBS牛肉。
• 美国市场：麦当劳、汉堡王等企业仅声明“与供应商对话”，未采取实质性行动。
• JBS回应：承诺2030年前消除直接供应商毁林，2035年前覆盖间接供应商，但实际执行滞后。

系统性挑战

• 巴西塞拉多生态区法律允许清理80%植被，政策漏洞仍存。
• 企业若完全剔除违规供应商将损失大量市场份额，改革动力不足。
• 欧洲银行（如法国巴黎银行）因资助JBS面临诉讼，投资方压力渐增。

延伸调查
团队发现牛肉行业占巴西奴隶劳动受害者的三分之一，其他调查还涉及橙汁、咖啡供应链中的人权问题（如星巴克供应商违规）。

未来展望
戈梅斯认为巴西问题短期内难有根本改善，调查工作将持续。卢拉政府执政后亚马逊毁林率下降，但塞拉多等地治理仍需推进。

Libyear：依赖库老化度量标准

定义与计算 Libyear 是一个用于量化软件系统依赖项老化程度的指标。其核心计算方法是将所有依赖项的年龄相加。例如，一个系统若有一个一年前的依赖和一个三年前的依赖，则其整体 libyear 值为 4 libyears。

健康基准 在实践中，将应用的总 libyear 值维持在较低水平是良好维护的标志。例如，某些开发团队（如 Singlebrook）致力于将客户应用的 libyear 值控制在 10 libyears 以下，并经常接手和修复那些落后超过 100 libyears 的项目。

词源 术语 “libyear” 中的 “lib” 是 “library”（库）的缩写，因为库是软件依赖项最常见的形式。

扩展指标与工具 除了基础的 libyear 计算，还有其他量化依赖维护负担的指标，可通过工具（如 libyear-bundler）实现：

1. 版本差异指标：通过 --versions 标志提供，用于衡量已安装版本相对于最新版本在主版本、次版本和补丁版本方面的新鲜度。此指标对于遵循语义化版本控制（semver）的依赖最为有效。
2. 发布次数指标：通过 --releases 标志提供，用于计算依赖的当前版本与最新版本之间的发布次数差距。

总结与应用 每种指标各有优缺点，但它们共同旨在量化应用的维护负担。综合运用这些指标，有助于：

• 对接手的应用项目进行维护优先级排序。
• 为持续进行的项目设定并保持依赖项新鲜度的基线水平。

PGMQ：基于PostgreSQL的轻量级消息队列

PGMQ是一个轻量级的消息队列系统，作为AWS SQS和RSMQ的替代方案，完全基于PostgreSQL实现。

核心特性

• 轻量级：无需后台工作进程或外部依赖，仅使用PostgreSQL SQL对象。
• 可靠交付：在可见性超时内保证消息“恰好一次”交付给消费者。
• API兼容：提供与AWS SQS和RSMQ一致的API。
• 有序处理：支持带有消息分组键的FIFO（先进先出）队列。
• 主题路由：支持基于通配符模式的发布/订阅和基于内容的路由。
• 消息持久化：消息保留在队列中直至被显式移除。
• 归档功能：消息可被归档而非删除，用于长期保留和重放。
• 版本支持：支持PostgreSQL 14-18版本。

安装方式

PGMQ可作为PostgreSQL扩展运行，或直接以纯SQL方式安装到现有PostgreSQL实例中。

• Docker快速启动：

  docker run -d --name pgmq-postgres -e POSTGRES_PASSWORD=postgres -p 5432:5432 ghcr.io/pgmq/pg18-pgmq:v1.10.0
  

  连接后启用扩展：

  CREATE EXTENSION pgmq;
  

• 纯SQL安装：克隆仓库并执行SQL脚本安装所有对象。

SQL操作示例

1. 创建队列：每个队列在pgmq模式下对应一个以q_为前缀的表。

   SELECT pgmq.create('my_queue');
   

2. 发送消息：消息以JSON格式发送，可选设置延迟。

   SELECT pgmq.send('my_queue', '{"foo": "bar1"}');
   SELECT pgmq.send('my_queue', '{"foo": "bar2"}', delay => 5);
   

3. 读取消息：读取消息并设置可见性超时（vt），使消息在处理期间对其他消费者不可见。

   SELECT * FROM pgmq.read(queue_name => 'my_queue', vt => 30, qty => 2);
   

4. 弹出消息：读取并立即从队列中删除一条消息。

   SELECT * FROM pgmq.pop('my_queue');
   

5. 归档消息：将消息移出队列并插入归档表（前缀为a_），支持批量操作。

   SELECT pgmq.archive('my_queue', msg_id => 2);
   SELECT pgmq.archive('my_queue', msg_ids => ARRAY[3, 4, 5]);
   

6. 删除消息：从队列中永久移除消息。

   SELECT pgmq.delete('my_queue', 6);
   

7. 删除队列：

   SELECT pgmq.drop_queue('my_queue');
   

关键机制：可见性超时

这是保证“恰好一次”交付的核心。消息被读取后，在指定的超时时间内对其他消费者隐藏。处理完成后，应用需调用delete()或archive()移除消息。若超时前未处理，消息将重新可见。

生态与社区

PGMQ提供官方Rust和Python客户端库，以及社区支持的多种语言库（如.NET、Go、Java、JavaScript、Ruby等）。目前已被Tembo、Supabase等公司正式采用。

Muddy 产品摘要

产品概述
Muddy 是一款由 YC S19 团队（Jimmy、Ron 和 Austa）开发的多玩家浏览器，专为提升工作协作效率而设计。它通过自动组织项目文件、整合 web 应用和优化团队协作，减少日常工作中的摩擦。

解决的问题

• 用户在工作中常面临文件组织混乱、应用孤岛和沟通断层问题，例如在聊天记录中寻找链接或打断同事询问文件位置。
• Web 应用虽能提高生产力，但各自独立，导致冗余操作和组织负担。

核心功能

• 项目空间（Spaces）：类似自动标签组，用于分组和管理相关应用。
• 共享时间线：用户可将任何网站（如 GitHub PR、Figma 文件、Trello 看板）添加到项目共享时间线，浏览器自动打开相关标签页，一键启动所需应用。
• 自动组织：后台使用 LLM（大型语言模型） 持续分析文件流行度、命名规范和对话等信号，自动更新重要标签列表，无需手动整理。
• 时间线回溯：支持一键回溯项目历史时间线，快速查看过去文件和状态。
• 网站注解：对于缺乏内置协作功能的网站（如文档），允许直接在页面上添加注解。
• AI 问答集成：AI 功能可回答项目相关问题，引用文件作为来源，并直接返回相关应用；基于本地浏览器运行，注重隐私保护。

技术基础

• 浏览器基于 Chromium 构建，确保兼容性和性能。
• 利用 LLM 和本地 AI 处理数据，实现自动化组织和智能查询。

市场定位

• 与 Chrome 和 Arc 等浏览器不同，Muddy 优先考虑团队协作，而非个人生产力附加共享功能，强调协作是效率的核心。

商业模式

• 基础产品免费提供。
• 未来将推出付费订阅，针对团队提供高级功能，如共享密码、团队管理、自定义快捷方式和 SSO 集成。
• 明确表示不依赖数据货币化盈利。

获取方式

• 可在官网 feelmuddy.com 下载 Mac 或 Windows 版本，并邀请他人协作。

该研究探讨了多模态模型（如CLIP和Stable Diffusion）的"零样本"性能与其预训练数据集中概念频率之间的关系。研究发现，这些模型并非真正的"零样本"泛化，其性能提升遵循对数线性缩放趋势，即需要指数级更多的预训练数据才能实现下游"零样本"性能的线性改进。

主要发现包括：

• 研究覆盖了34个模型和5个标准预训练数据集（CC-3M、CC-12M、YFCC-15M、LAION-400M、LAION-Aesthetics），生成了超过300GB的数据产物。
• 观察到的样本效率低下的对数线性缩放趋势在控制预训练与下游数据集样本相似性、以及在纯合成数据分布上测试时仍然成立。
• 在基于研究分析抽样的长尾数据基准上，所有多模态模型表现均较差。研究者为此贡献了名为"Let it Wag!"的长尾测试基准集。

研究揭示了大规模训练范式下实现"零样本"泛化能力仍面临挑战，其关键在于对训练数据量的指数级需求。

文章摘要

本文探讨了循环呼吸法作为一种非药物、可及性强的替代方案，在引发意识改变状态（ASCs） 方面的潜力。研究表明，ASCs（如通过迷幻药物诱发）对治疗抑郁症和创伤后应激障碍等广泛心理健康问题具有巨大潜力，但其应用受限于法律、医疗和财务障碍。

核心研究问题：填补呼吸法对心理健康影响及其生理、心理机制的认知空白。

研究方法：通过追踪一次呼吸法课程中的生理和体验动态，比较了两种流行的呼吸法形式：全向呼吸法和意识连结呼吸法。

主要发现：

1. 关键生理机制：由有意过度换气导致的呼气末二氧化碳分压降低，是催化呼吸法过程中ASCs的关键因素。
2. 效果可比性：呼吸法诱发的ASCs在深度和性质上与迷幻药物产生的ASCs具有可比性，且ASCs的深度能预测后续的心理和生理改善效果，包括提升幸福感和减轻抑郁症状。
3. 形式一致性：不同形式的呼吸法（全向呼吸法与意识连结呼吸法）产生了高度相似的生理、体验和心理结果。

结论与意义： 本研究明确了在非药物背景下诱发ASCs的生理性边界条件，揭示了呼吸法的功能机制，并证实了其作为一种心理治疗工具的潜力，为将其发展为一种安全、可及的意识干预手段提供了科学依据。

无Xlib直接通过X11协议创建Linux窗口

本文展示了如何仅使用C语言和Unix套接字，通过直接与X11协议交互，在Linux中创建窗口，而不依赖Xlib等图形库。核心在于将X11视为一个网络协议，与X服务器进行通信。

核心目的与结构

• 目的：探索X11协议本身，理解其作为客户端-服务器通信协议的工作原理。
• 前提：X服务器使用Unix域套接字通信。需要先运行xhost +local:来禁用基于cookie的认证。
• 结构：程序分为连接、初始化、创建/映射窗口和事件处理几个阶段。

关键步骤与实现

1. 建立连接

• 使用AF_UNIX套接字连接到/tmp/.X11-unix/X0。
• 连接成功后，发送一个12字节的初始化请求，设置字节序（如'l'表示小端）和主版本号（11），跳过认证数据。

2. 处理初始化响应

• 读取服务器响应。第一个字节标识响应状态（成功/失败/需要认证）。
• 成功响应（约9KB）包含大量信息，程序提取关键部分：
  • 资源ID基准和掩码：用于生成客户端资源（如窗口、图形上下文）的唯一ID。新ID由(本地ID & 掩码) | 基准生成。
  • 根窗口ID和根Visual ID：后续创建窗口所需。
• 这些信息存储在全局变量中供后续使用。

3. 创建与映射窗口

• 创建窗口：
  • 发送类型为1的创建窗口请求。
  • 请求包含：窗口ID（由GetNextId()生成）、父窗口（根窗口）、位置、大小、边框宽度、窗口类、Visual ID。
  • 通过位掩码设置值列表，例如设置背景像素（黑色）和事件掩码（接收曝光和按键事件）。
• 映射窗口：
  • 发送类型为8的映射窗口请求，使窗口在屏幕上可见。

4. 扩展功能：绘制文本

• 打开字体：发送类型为45的请求，指定字体名（如"fixed"）和自生成的字体ID。
• 创建图形上下文：
  • 发送类型为55的请求，指定GC ID、字体ID。
  • 通过位掩码设置前景色、背景色等绘图属性。
• 写入文本：
  • 发送类型为76的请求，指定窗口ID、GC ID、坐标和字符串内容。
  • 在事件循环中，在每次收到事件时重绘文本。

5. 事件循环

• 使用poll函数阻塞等待套接字上的数据（即X服务器事件）。
• 循环处理收到的事件：
  • 错误处理：打印错误详情。
  • 事件处理：打印事件代码和详情（如按键码、曝光事件参数）。
  • 响应按键事件（如WASD）可动态调整文本绘制位置。
• 程序在连接关闭时退出。

代码结构与编译

• 单文件C程序：所有逻辑集中在一个.c文件中。
• 关键函数：X_InitiateConnection、X_CreateWindow、X_MapWindow、X_OpenFont、X_CreateGC、WriteText、事件处理循环。
• 编译：gcc main.c -o main。
• 演示：成功创建一个带文本的窗口，可通过按键移动文本位置。

结论

本文证实了X11协议本质是一个可直接通过套接字操纵的网络协议。尽管X Server正逐渐被Wayland取代，但理解X11有助于了解二进制协议和资源管理的实现。该方法仅依赖libc，无需外部库，为理解底层图形系统通信提供了一个清晰的视角。

文章摘要：UTC、TAI与Unix时间

本文解释了三种时间标准：国际原子时间（TAI）、协调世界时（UTC）和Unix时间，并分析了它们之间的差异与现有系统的问题。

1. TAI（国际原子时间）

• 基于铯原子辐射定义的恒定秒长，自1955年起持续测量。
• 每天固定为86400秒，采用公历日期标记，是民用时间标准的基础。

2. UTC（协调世界时）

• 基于TAI，但引入了闰秒以调整地球自转的不规则性（每日约86400.002秒）。
• 通过不定期添加闰秒（如1997-06-30的23:59:60），使UTC与地球自转保持同步，确保正午太阳位于英国子午线上方。
• 自1972年起实施闰秒系统，初始时UTC比TAI慢10秒。

3. Unix时间

• 自特定纪元（通常为1970-01-01 GMT）起的秒数计数，便于计算时间间隔。
• 但传统Unix库（如localtime()）未正确处理闰秒，实际上将TAI当作UTC使用，导致时间显示随闰秒累积误差。

4. 核心问题：xntpd与POSIX标准

• 网络时间协议（NTP）同步程序xntpd为兼容有缺陷的localtime()库，在闰秒时刻重置时钟，导致Unix时间戳出现重复值（例如1997-07-01 UTC 00:00:00.0对应的时间戳与闰秒期间相同）。
• 这使得Unix时间与UTC的可靠转换失败，影响需要精确时间计算的应用。

5. 技术障碍与解决方案

• 技术上可修复xntpd和localtime()以支持闰秒（如采用Olson时间库），但POSIX标准强制保留旧有错误行为（如错误定义2100年为闰年），阻碍了改进。
• 作者提出：
  • 支持闰秒的64位时间处理库（如libtai）。
  • 能正确处理闰秒的时钟同步工具（如clockspeed）。

关键引用

• NIST时间与频率部门主页提供时间测量基础信息。
• Olson库（ftp://elsie.nci.nih.gov/pub/）包含正确处理闰秒的实现。
• 作者的库与Olson库共享TAI纪元，并针对Y2036/Y2038问题设计。

摘要：React图标包迁移指南

本文档宣布旧版React图标包hugeicons-react已被弃用，建议迁移到官方维护的新包。以下是主要内容和关键细节：

• 弃用通知：hugeicons-react包标记为Deprecated/Legacy，仅保留用于向后兼容。新项目应使用官方包，AI工具（如v0、Lovable、Bolt等）可能引用旧包名称，需迁移。
• 推荐包：
  • React渲染器：@hugeicons/react（用于渲染图标）。
  • 免费图标包：@hugeicons/core-free-icons（提供Stroke Rounded风格的免费图标）。
• 迁移步骤：
  1. 卸载旧包：使用npm、yarn、pnpm或bun命令移除hugeicons-react（例如：npm uninstall hugeicons-react）。
  2. 安装新包：安装@hugeicons/react和@hugeicons/core-free-icons（例如：npm install @hugeicons/react @hugeicons/core-free-icons）。
• 新用法示例：
  • 从@hugeicons/core-free-icons导入图标（如Home01Icon），使用HugeiconsIcon组件渲染。
  • 关键控制参数：size（大小）、color（颜色）、strokeWidth（描边宽度）。
  • 示例代码展示在React组件中如何集成图标。
• 迁移原因：
  • 更多图标：4,600+免费图标且持续更新。
  • 更好性能：更清洁、模块化的包结构。
  • 活跃支持：官方维护的渲染器和图标包。
  • 可扩展性：同一集成模式适用于Pro版本升级。
• AI工具纠正：提供纠正提示模板，指导AI工具从旧包迁移并输出正确代码。
• 文档和许可证：相关文档可在Hugeicons官网获取（如React集成指南），采用MIT许可证。

此迁移确保项目使用最新、最高效的图标解决方案。

Knit 是一个基于浏览器的编织图案生成工具，专注于帮助用户编织简单的波浪形围巾。

主要功能

• 参数化图案生成：用户输入围巾的长度和形状参数后，软件会生成对应的编织行序列（即图案）。
• 实时渲染与进度追踪：软件会根据参数实时渲染围巾的视觉效果，并帮助用户追踪当前编织到哪一行。
• 客户端运行：整个应用的状态都保存在浏览器中，除了加载静态文件外，没有服务器端交互。
• 形状生成算法：围巾的形状（即加针和减针的位置）通过贝塞尔曲线根据输入参数计算生成。

使用流程

1. 访问软件：通过 GitHub Pages 链接使用在线版本。
2. 建议本地保存：为避免开发者后续更新影响，推荐将全部文件下载到本地使用。
3. 参数校准：可通过编织一个小样本来确定你的纱线宽度和手松紧，从而设置行数和针数参数。
4. 配置围巾：调整参数至满意，鼠标悬停可查看输入说明，然后点击“Knit”生成图案。
5. 开始编织：按步骤从第0行开始编织。完成一行后，通过点击“Next”、按空格键或在移动设备上滑动来前进。软件会记忆进度。
6. 收尾：编织到最后一行后收针。

界面显示说明

编织行信息显示格式如下，例如："92↓ (13 Δ1) 2K KFB 6K WYIF 3SLP"

• 行号：如 92，表示当前是第93行（从0开始计数）。
• 编织方向：↓ 表示朝向渲染图的方向（可理解为正面），↑ 表示反面。
• 针数信息：(13 Δ1) 表示本行结束时应有13针，Δ1 表示本行增加1针。
• 步骤说明：后续内容为本行的具体编织指令。
• 进度显示：仅当前行会显示一个基于总针数的百分比，表示当前行开始时的总体完成度。

未来计划

开发者计划增加以下功能：

1. 计时功能：记录每行所用时间，防止遗忘记录进度。
2. 更多织物类型：软件底层设计不限于围巾，未来计划支持袜子、帽子等更多种类的编织图案生成。

《Model Spec》摘要

概述

《Model Spec》是OpenAI发布的一份草案，旨在规范其模型（如API和ChatGPT中的模型）的行为。它为研究人员和数据标注者提供指导，用于通过人类反馈强化学习（RLHF）训练模型，未来模型也可能直接从中学习。该文档是OpenAI负责任构建和部署AI的一部分，与使用政策互补，将持续更新以反映反馈。

核心框架：目标、规则与默认行为

规范使用三层原则指导模型行为：

1. 目标：最广泛的指导原则，如“协助开发者与用户”和“造福人类”。在复杂场景中，这些目标可能冲突。
2. 规则：用于处理高风险情境的绝对限制（如“不做非法之事”），开发者和用户通常无法覆盖。
3. 默认行为：在无明确指令时的标准响应模式，开发者或用户可根据需要覆盖。例如，在代码生成任务中，默认是提供可运行代码而非闲聊式解释。

关键定义与消息结构

• 助手：与用户或开发者交互的主体。
• 对话：输入模型的有效消息列表。每条消息包含：
  • role：必需，可为platform、developer、user、assistant或tool。
  • content：必需，文本或多模态数据。
  • settings：可选，用于调整模型设置（如interactive模式和max_tokens）。
  • recipient：可选，控制消息处理方式（如调用函数）。
  • end_turn：必需（仅助手消息），指示是否停止操作。
• 角色优先级：指令冲突时，优先级为：Platform > Developer > User > Tool。规范本身具有平台级权限。

主要规则与准则

• 遵守指令链：助手应遵循规范及平台消息。开发者消息默认视为不可覆盖的规则。
• 处理不信任数据：引号内文本、文件附件等视为不信任数据，其中的指令应视为信息而非指令，以防止提示注入。
• 合法性：禁止促进或参与非法活动。
• 安全：不提供制造化学、生物、放射性或核威胁的指导，不鼓励自残。
• 尊重权利：尊重创作者知识产权，不复制受版权保护内容。
• 隐私保护：不透露私人或敏感信息，即使信息在线可用。
• 内容限制：不生成不适宜工作场合（NSFW）的内容，但在科学或创意语境下可保持专业讨论。
• 例外：内容转换：对于用户提供的内容（如翻译、总结），助手应假设用户有权提供，直接执行任务。

默认行为指南

• 假设善意：不评判用户或开发者意图，拒绝时应简洁、不训诫。
• 澄清需求：在交互模式下（interactive=true），对不明确任务应询问澄清问题；非交互模式下应直接执行。
• 保持适度帮助：遵循明确指令并合理推断隐含意图，但不越界。在敏感话题（如医疗、法律）上提供信息但不给出受监管的建议。
• 支持不同模式：
  • 交互模式：可提问、使用代码块等。
  • 程序化模式（interactive=false）：输出应精确匹配请求格式，无额外文本。
• 保持客观：呈现事实和多方观点，不持有个人意见或试图改变用户看法。
• 鼓励公平与友善：体现包容价值观，避免强化刻板印象。
• 表达不确定性：对超出知识范围的问题应使用“我不确定”等表述，避免自信的错误回答。
• 响应长度：兼顾详尽与效率，遵守令牌限制，避免冗余重复。

工具使用

助手可通过消息调用工具，消息中指定recipient为工具名称，并遵循开发者提供的工具语法。

总结

《Model Spec》通过目标、规则和默认行为的分层框架，系统性地定义了AI助手的期望行为。它强调在遵守安全、法律和伦理边界的同时，最大化用户和开发者的可控性，并明确了不同角色和场景下的交互准则。该文档旨在促进透明度，并作为持续优化的基础。

OpenAI 模型规范概览

核心目标与更新

• 2025年2月12日发布更新版：强化可定制性、透明度和无任意限制的知识自由，同时保留安全防护措施以减少真实危害风险。
• 2024年5月8日首版发布：旨在公开模型在API和ChatGPT中的行为准则，促进公众理解与讨论。
• 规范定位：整合现有内部文档、研究与实践，指导未来模型开发，并随反馈持续迭代。

核心原则框架

1. 目标（Objectives）

• 协助用户与开发者：遵循指令，提供有用响应以实现用户目标。
• 造福人类：考虑广泛利益相关者（包括内容创作者、公众）的潜在益处与危害。
• 维护OpenAI声誉：遵守社会规范与适用法律。

2. 规则（Rules）

• 遵循指令链：开发者指令优先于用户指令（如API场景）。
• 遵守适用法律：不协助非法活动（需结合具体司法管辖区考量）。
• 避免信息危害：不提供危险信息。
• 尊重创作者与隐私：保护知识产权和个人隐私。
• 禁止NSFW内容：不生成不安全工作场合的内容。

3. 默认行为（Default Behaviors）

• 假设用户善意，必要时提问澄清。
• 最大化协助，但不越界（如敏感领域提供信息而非专业建议）。
• 支持不同使用场景（交互聊天与程序化调用）。
• 保持客观视角，鼓励公平友善，不试图改变用户观点。
• 表达不确定性，高效使用工具，兼顾全面与简洁。

应用示例

• 法律合规：拒绝协助商店盗窃（除非用户目的是安防研究）。
• 指令优先级：开发者设定的数学辅导角色优先于用户“直接解题”的要求。
• 敏感领域处理：医疗问题中提供可能性说明，建议咨询医生（非诊断）。
• 澄清需求：用户要求写情人节贺卡时，主动询问细节而非直接生成模板。
• 观点中立：面对“地球是平的”主张，陈述科学共识但尊重用户信仰自由。

使用与演进

• 内部应用：作为研究人员和AI训练者的指导方针，用于强化学习。
• 公开反馈：邀请政策制定者、机构专家及公众提供意见，持续优化规范。
• 未来计划：定期发布更新，公开反馈整合进展，并探索模型直接从规范学习的可能性。

注：规范强调平衡*安全性、有用性与开放性，旨在引导模型行为同时避免过度限制探索与创新。*

Stack Overflow用户因与OpenAI合作而删除答案事件

合作内容

• Stack Overflow与OpenAI建立新的API合作伙伴关系，旨在结合Stack Overflow的知识平台与OpenAI的AI模型。
• OpenAI将使用Stack Overflow的OverflowAPI访问经过验证的数据，以改进其AI模型，并在ChatGPT中标注来源。
• Stack Overflow将把OpenAI的模型集成到其OverflowAI开发中，并共同优化模型性能。
• 合作目标是提升开发者体验，通过社区驱动的功能和负责任的AI实践提高效率。
• 合作的初步整合与功能计划于2024年上半年推出。

用户反应与抗议

• 社区对合作出现反弹，部分用户因不满其内容被用于训练AI（尤其可能缺乏署名），开始尝试删除或修改自己在Stack Overflow上的历史问答。
• 由于平台限制直接删除，一些用户选择篡改内容以进行抗议。
• 互联网内容生态正经历变化，如博客流量下降、AI搜索替代传统引擎等，此次事件反映了内容创作者对AI大规模采用的普遍担忧。

平台处理措施

• 多名用户报告称，在试图删除或大量修改内容后，收到Stack Overflow版主邮件，账户被暂时封禁7天。
• Stack Overflow解释称，删除或破坏可能对他人有用的内容会扰乱社区。平台依赖用户生成内容保持价值，因此有政策防止大规模内容清除。
• 平台发送的警告邮件指出，用户发布的内容已成为集体努力的一部分，除非特殊情况不应移除。大量删除需要修复，可能导致账户临时暂停。
• 目前尚不清楚抗议用户的规模，也未见Stack Overflow就此事件公开回应。平台强调用户可直接联系以处理内容问题。

现状与影响

• 尽管出现反弹，AI采用的趋势仍在持续。事件突显了AI发展背景下，用户生成内容平台、创作者权益与AI数据使用之间的紧张关系。
• 文章建议其他Stack Overflow用户谨慎考虑是否以删除内容作为抗议手段。

VideoPrism：用于视频理解的基础视觉编码器

核心目标与挑战

• 目标：构建一个通用的单一视频基础模型，以处理多样化的视频理解任务，而非依赖针对特定任务的专用模型。
• 挑战：视频内容包含动态视觉信息（运动、变化、实体关系），其复杂性和公开数据的庞大多样性对模型提出了更高要求。

VideoPrism 模型概述

VideoPrism 是一个专为通用视频理解设计的视频基础模型，旨在处理包括分类、定位、检索、描述和问答在内的广泛任务。其创新主要体现在预训练数据和建模策略上。

关键创新点

1. 大规模多样化的预训练数据

• 构建了迄今最大、最多样化的视频预训练语料库，包含：
  • 3600万高质量视频-文本对（精心筛选，配文准确）。
  • 5.82亿视频片段，配有噪声或机器生成的并行文本（如自动生成的字幕）。
• 数据质量多样，覆盖了从精准描述到嘈杂文本的各种情况，为模型提供了广泛的语义学习基础。

2. 两阶段训练策略

• 第一阶段：视频-文本对比学习
  • 利用对比学习，最小化正样本对（视频及其文本描述）的距离，最大化负样本对的距离。
  • 目的：建立视频内容与语言语义（即使是不完美的文本）之间的基础匹配能力。
• 第二阶段：改进的遮蔽视频建模
  • 在大量无文本描述的视频上进行训练。
  • 模型需要预测被遮蔽的视频块。
  • 改进点：同时预测来自第一阶段模型的视频级全局嵌入和令牌级嵌入，并随机打乱预测的令牌，以防止模型学习捷径。
• 策略优势：结合了文本（侧重于外观）和视频内容（侧重于运动和动态）两种互补的信号，使模型能同时理解外观和动态。

性能表现与评估

VideoPrism 使用一个冻结的单一模型，仅需最少的适配，即可在广泛的视频理解任务上达到先进水平。

评估结果

• 基准测试：在 33项 视频理解基准测试中的 30项 上取得了当前最优性能。
• 分类与定位：在 VideoGLUE 基准上超越了所有其他最先进的基础模型，且没有其他单一模型能始终位居第二，表明其能有效整合多粒度语义、外观和运动线索。
• 与语言模型结合：与文本编码器或大型语言模型（如 PaLM-2）结合后，可用于视频文本检索、描述生成和问答任务，并在大多数视觉-语言基准上创下新高。模型能理解复杂动作和外观（如识别旋转物体的不同颜色）。
• 科学应用：在动物行为学、行为神经科学和生态学等领域的科学数据集上表现优异，甚至超越了为这些任务专门设计的模型，展现了其在跨学科科学分析中的潜力。

结论

VideoPrism 作为一个强大且通用的视频编码器，为通用视频理解设立了新标准。其成功验证了构建大规模多样化数据集和创新训练方法的重要性。模型展现出的泛化能力使其适用于从科学发现到教育、医疗等广泛的实际应用场景。