## 动态视频速度调整 Chrome 扩展 - 摘要 这个 Chrome 扩展程序智能地调整视频播放速度，以规范语速，从而在不牺牲理解的情况下加快内容消费速度。它通过使用 Web Audio API 分析页面上最大的视频元素的音频轨道来实现。 该扩展程序的核心在于其音节速率检测算法。在隔离关键元音频率（300-3000Hz）后，它分析能量包络调制——特别是过零率——来估计说话者说话的速度。 以前使用峰值计数和 AudioWorklets 的迭代由于语音特征和浏览器安全策略而面临限制。 检测到的速率随后用于计算目标播放速度，旨在达到每秒 9 个音节的稳定速率（用户可调整）。 速度变化被平滑处理，以避免突兀的过渡。 用户界面提供对目标速率、最小/最大速度的控制，并显示实时数据，例如当前速度、估计的音节速率和能量水平。 局限性包括与 DRM 保护的内容不兼容以及音乐或多个说话者可能出现不准确的情况。 未来的改进可能包括语音活动检测和针对每个说话者的自适应调整。
每日HackerNews RSS
## Chrome 扩展程序根据语音调整视频速度
一个 Chrome 扩展程序旨在自动调整视频播放速度，以匹配说话者的语速。该扩展程序在 Hacker News 上分享，基于 GitHub，它会根据检测到的语速动态改变速度，可能提高对语速快的人的理解力。
讨论迅速转向了 Chrome 扩展程序的安全问题，用户担心恶意接管。一些评论者建议直接下载扩展程序的源代码并“加载未打包”以绕过自动更新并保持控制。
诸如 Firefox 的“Video Speed Controller”和“Sponsorblock”扩展程序（用于跳过片头/广告）等替代方案也被提及。一些用户报告说该扩展程序性能不稳定，而另一些用户则强调需要更好地支持口音或与播客应用程序集成。一个关键的收获是人们希望拥有个性化播放速度的工具，有些人更喜欢以 2 倍甚至 3 倍的正常速度收听。
## gstack：软件开发新时代
Y Combinator 首席执行官 Garry Tan 正在展示由人工智能（特别是 Claude Code）的进步所带来的软件开发领域的根本性转变。他个人每天编写 10,000-20,000 行可用代码——过去需要一个大型团队才能完成的壮举。
这得益于 **gstack**，一个他构建并现在分享的开源“软件工厂”。gstack 利用 Claude Code 模拟一个由 13 名专家组成的团队——CEO、工程经理、设计师、QA 等——可以通过简单的斜杠命令访问。这些代理处理从产品规划和设计审核到代码生成、测试和部署的各个方面。
gstack 不仅仅是一个副驾驶；它会主动重新构建问题、识别错误并自动化关键任务。它的设计旨在大幅提高单个开发者的生产力，并已获得许可性的 MIT 许可证。Tan 鼓励开发者 fork、改进和采用 gstack，他相信掌握这些新的 AI 驱动工具的人将获得显著优势。他正在积极开发 gstack，并邀请社区加入他的旅程。
[https://github.com/garrytan/gstack](https://github.com/garrytan/gstack)
## 嘉里·谭的“Claude 代码设置”引发担忧与争论
嘉里·谭（Y Combinator 首席执行官）最近在 GitHub 上展示了他的人工智能辅助编码设置，引发了 Hacker News 上激烈的讨论，并引发了对潜在倦怠和心理健康的担忧。许多评论员指出，谭报告的工作习惯——吹嘘 60 天内编写了 60 万行代码且睡眠极少——与躁狂症或精神病症的症状相似。一些人分享了朋友在寻求治疗前表现出类似行为的经历。
除了健康问题外，该项目还因其依赖代码行数 (LOC) 作为生产力指标而受到批评，被认为是一种有缺陷且容易夸大的衡量标准。怀疑论者质疑生成的代码的实际价值，指出缺乏可证明的已发布产品。
虽然有些人觉得该设置的某些方面很有趣，但许多人认为它过于复杂、自我宣传，最终毫无用处。有人建议 Every 团队的方法和 Simon Willison 的工作作为更实用的 AI 辅助工程资源。这场讨论凸显了人们对人工智能生产力工具炒作日益增长的不安，以及对更现实和可持续方法的呼吁。
这篇散文讲述了一个家庭通过对黑巧克力的共同喜爱建立的持久联系，尤其源于父亲一丝不苟且珍视的仪式。作者从1960年代开始，描述了每年与父亲一起去当地巧克力店的经历，以及父亲享用几块，每块恰好有两颗杏仁的习惯，这创造了一种令人安心的规律。尽管作者最初并不喜欢黑巧克力的苦味，但她还是参与其中，希望能与她常常严肃的父亲更亲近，并见证他每咬一口都变得柔和和满足。 多年来，巧克力的来源发生了变化，但仪式却始终如一，成为团结的象征，也是与父亲联系的一种方式，即使在她母亲去世后和她自己生活发生变化之后。这个传统延续到了她的孩子们身上，孩子们非常喜欢“爷爷的巧克力”。现在，作者继续传承这一遗产，随时准备着黑巧克力，这是一种甜蜜而苦涩的提醒，提醒着一种超越世代并继续将她的家庭联系在一起的爱。
一篇《基督教科学箴报》关于家庭巧克力制作仪式的文章在Hacker News上引发了争论，一些用户怀疑该文章是由人工智能生成的。最初的评论者指出了一些写作风格元素——重复的句子结构（“这从来不仅仅是关于……”）和破折号的使用——可能是“人工智能标记”。
其他人则为这篇文章辩护，指出《箴报》长期以来的良好声誉，以及这篇文章与其典型的“家庭论坛”风格相似。一项详细的分析将文章中破折号的使用频率与作者（南希·英特拉托）90年代的早期作品进行了比较，发现显著增加。
最终的普遍理论是，英特拉托的草稿可能被生成式人工智能扩展了，将人类经验与人工智能辅助相结合。这场讨论凸显了人们对人工智能在内容创作中作用日益增长的关注，以及难以明确识别人工智能撰写的文本的困难。
非怠工作室
Unsloth Studio
9 天前
## Unsloth Studio：本地AI模型训练与推理 Unsloth Studio (Beta) 是一款新的、开源的、无需代码的网页界面，旨在简化本地AI模型的使用。它允许用户在Mac、Windows和Linux上运行、训练和导出开源模型——即使对于基本的聊天推理，也不需要强大的GPU。 主要功能包括：训练速度提升2倍，VRAM使用量减少70%，支持500多种模型（文本、视觉、音频、嵌入），以及轻松微调Qwen3.5等LLM。用户可以通过PDF、CSV和JSON上传数据，使用“数据配方”创建自定义数据集。实时观测工具跟踪训练进度，模型可以导出为与llama.cpp和Ollama等流行平台兼容的格式。 Unsloth优先考虑隐私，提供完全离线操作和安全认证。目前仍处于Beta阶段，未来的更新将支持Apple MLX、AMD、Intel，并改进多GPU功能。提供Google Colab笔记本，方便快速探索。
## Unsloth Studio 总结
Unsloth Studio (unsloth.ai) 是一款新兴工具，因其简化了AI模型微调过程而备受关注，尤其适合那些运行自己AI引擎的用户。它采用Apache许可证，对受专有许可证（如LM Studio）限制的用户具有吸引力。
开发者强调专注于提供有用的开源工具，虽然提供大量免费内容，但他们通过企业客户获取收入——声称是第四大独立LLM分发商，与财富500强公司和主要实验室合作。
讨论主要集中在安装问题（推荐使用`uv`和`pipx`等工具以避免系统范围内的冲突）以及预训练支持和Runpod/HF Jobs集成等功能请求。团队正在积极响应反馈，承诺改进安装和UI功能，包括AMD ROCm支持。虽然GUI对爱好者来说很有吸引力，但Unsloth也被大型组织用于微调和推理。
## Rust 与高阶类型：深入探讨 本文探讨了 Rust 缺乏对高阶类型（HKT）的直接支持——泛型可以接受其他泛型作为参数——以及围绕此限制的解决方法和未来方向。虽然 Rust 本身不允许 `struct Foo<T>(T<i32>)`，但作者深入研究了底层的类型系统概念来理解原因。 核心解释阐明了类型是“函数”，接受其他类型并返回新类型（如 `Vec` 这样的类型构造器）。Rust 区分值（如 `true`）、类型（如 `i32`）和类型构造器（如 `Vec`）。缺乏 HKT 意味着 Rust 无法直接将类型构造器作为泛型参数传递。 泛型关联类型（GAT）提供了一个部分解决方案，允许 trait 定义关联类型，这些类型*可以*被参数化。然而，这是一种解决方法，而不是真正的 HKT 实现。文章随后深入研究了证明类型属性的数学基础，涉及归纳法，以及关键的 *余归纳法*。 余归纳法允许无限的证明树，这对于处理递归类型至关重要，其中 trait 的实现依赖于自身。这一点很重要，因为下一代 Rust trait 求解器旨在支持余归纳 trait。然而，当前的实现仍然存在错误，正如一个由看似简单的示例触发的编译器 ICE（内部编译器错误）所示。尽管存在这些挑战，但持续的工作表明，未来 Rust 的类型系统可以更优雅地处理复杂的泛型场景。
一个Hacker News的讨论围绕着Rust中高级类型操作的挑战。g0xA52A2A发布了一篇帖子，详细描述了通过模拟高阶类型（HKTs）来“折磨”Rust编译器（Rustc），这是一个强大但复杂的功能。
评论显示开发者正在尝试类似的技术——映射、过滤和归约类型——并且即使在强大的硬件（如M2 Pro）上，也由于大量的编译时求值和特征解析而达到性能极限。一位用户分享了一个复杂的结构体定义，使用了泛型常量表达式，这超出了编译器的承受能力。
对话还涉及RFC8366，一份技术文档，其复杂的术语引人发笑，以及普遍承认需要深厚的数学和编程知识才能完全理解这些概念。 许多评论者戏谑地承认自己被这个话题“nerdsniped”（被吸引）。
## Get-Shit-Done (GSD)：一款强大的AI驱动开发系统
GSD是一个轻量级系统，旨在利用Claude Code、OpenCode、Gemini、Codex、Copilot和Antigravity等AI模型增强代码生成，解决“上下文衰退”问题——即随着AI上下文窗口的填充，质量下降的问题。GSD由一位对过于复杂的规范驱动开发工具感到沮丧的独立开发者构建，优先考虑简单性和有效性。
它通过自动化上下文工程、提示格式化和代理编排来实现，允许用户简单地*描述*他们想要构建的内容。GSD然后提取需求、研究解决方案、创建路线图，并以可管理的方式执行任务，并进行原子提交——同时保持干净的git历史记录。
主要功能包括自动化规划、研究和验证，以及定制选项和快速临时任务。GSD受到亚马逊和谷歌等大型公司工程师的信赖，专注于在不增加传统企业工作流程开销的情况下，提供一致的高质量结果。安装简单，使用`npx get-shit-done-cc@latest`即可，并支持全局或本地项目设置。
## 完成任务 (GSD) - 摘要
这次Hacker News讨论围绕**GSD**展开，这是一个用于AI辅助软件开发系统，侧重于元提示、上下文工程和规范驱动开发（可在GitHub上找到）。用户分享了不同的体验，突出了它的潜力与缺点。
许多人发现GSD与直接使用Claude Code或Superpowers等工具相比，**消耗大量token**且**速度慢**。一些人欣赏它详细的规划和对整个项目考虑的关注，尤其是在大型任务中，而另一些人则认为繁琐的规划阶段效率低下。
一个关键的争论点在于这些“代理式工作流”与直接编码的价值。一些人认为它们增加了不必要的复杂性，而另一些人则认为它们对于管理复杂项目和构建持久上下文很有价值。人们对AI可能生成包含安全漏洞或逻辑错误的代码表示担忧，尤其是在缺乏足够的人工监督的情况下。
**Superpowers、OpenSpec和PAUL**等替代方案经常被提及，用户们寻求自动化与控制之间的平衡。最终，讨论强调了AI辅助开发不断发展的本质，以及找到适合个人偏好和项目需求的流程的必要性。
Meta公司资深研究员马特·莫蒂尔表示，该公司对TikTok的竞争产品Instagram Reels在2020年推出时缺乏足够的保障措施。与BBC分享的内部研究显示，Reels上的评论中，欺凌、骚扰、仇恨言论以及暴力或煽动性内容比Instagram其他地方更为普遍。
本田突然大幅缩减了其电动汽车（EV）的雄心，停止开发如讴歌RDX和本田0系列等新电动车型，并停止生产通用汽车制造的Prologue。本田将此决定归因于美国关税和中国竞争，但普遍认为这源于缺乏可行的长期电动汽车战略。 此举有使本田在两个关键的汽车转型中落后的风险：电动驱动系统和软件定义汽车。与一些竞争对手不同，本田仅仅将电动汽车视为内燃机的替代品，未能抓住机会从根本上重新思考车辆设计以提高效率和降低成本。 此外，放弃电动汽车开发会阻碍本田在先进软件、空中更新和数据驱动改进等关键领域的进展——这些功能越来越受到消费者的期望。这给本田带来了身份危机，本田传统上以发动机质量和驾驶者为中心的设计而闻名，但随着汽车行业向可靠性、可负担性和自动驾驶转变——本田已经在这些领域难以竞争，尤其是在中国市场。
## 本田缩减电动汽车计划
本田正在大幅削减其电动汽车（EV）的雄心，停止开发三款计划中的车型。这一决定源于市场现实的变化，包括CAFE标准的弱化，而这些标准最初推动了对合规车辆的需求，例如改标的通用Prologue。
讨论强调了对日益依赖软件的车辆的实用性和安全性问题的担忧，一些人认为应该回归更简单、可靠的“家电式”汽车。另一些人则指出中国电动汽车制造商（如比亚迪）的 dominance，它们正在快速创新并提供经济实惠的选择。
虽然一些人认为电动汽车转型因基础设施和成本问题而停滞，但另一些人则认为电动汽车正在获得 traction——全球范围内，现在有20%的新车销售是电动汽车。一个关键点是本田在传统发动机技术，特别是摩托车方面的优势，以及一种等待电动汽车技术成熟后再全面投入的策略。关于电动汽车供应链的可持续性以及对稀土材料的依赖，也存在争论。
## CPython JIT进展：提前一年达到目标
CPython JIT项目在性能提升方面取得了显著进展，在macOS AArch64上提前一年，在x86_64 Linux上提前数月达到了最初的目标。3.15 alpha版本的JIT在macOS AArch64上比标准解释器快11-12%，在x86_64 Linux上快5-6%——性能范围从20%减速到超过100%加速，具体取决于工作负载。
这一成功是在最初的JIT几乎没有改进，Faster CPython团队面临资金削减之后实现的。 这一转机归功于运气、一支敬业的团队（Savannah Ostrowski、Mark Shannon、Diego Russo、Brandt Bucher等）以及战略性地转向社区管理。
关键改进包括新的基于跟踪的前端（“双分派”）和引用计数消除，这两者都得益于将复杂任务分解为可管理的小贡献，从而吸引了11名贡献者组成的不断壮大的团队。Savannah Ostrowski领导的每日性能报告可靠的基础设施也至关重要。该项目强调与PyPy等其他项目的合作和学习，强调社区和共享知识在推动JIT开发方面的重要性。未来的工作将集中在3.15/3.16版本中的自由线程支持。
## Python 3.15 JIT 进展与讨论
Python 社区正在热议 CPython 的即时编译 (JIT) 编译器取得的进展，旨在显著提升性能。 在资金受挫（微软裁员）后，开发已重回正轨，部分由 ARM 提供支持。 目前的方法利用“双分派”机制，最大限度地减少解释器尺寸的增加。
讨论的重点是为什么 Python 在 JIT 实现方面落后于其他语言（Ruby、PHP、JavaScript）。 关键挑战包括复杂的 C API、向后兼容性问题以及 GIL（全局解释器锁）。 一些人认为，Python 专注于库支持（NumPy、PyTorch）降低了对核心语言优化的需求。
人们对诸如 `__del__` 和引用计数系统等特性对优化产生的影响表示担忧。 关于 Python 是否应该优先考虑向后兼容性，还是拥抱更激进、可能破坏兼容性的变化，存在争论。 基准测试显示出令人鼓舞的收益，尤其是在 Windows 上，但硬件和操作系统之间的差异使分析复杂化。
对话还涉及替代 Python 实现（如 PyPy）的作用，以及 AI 辅助代码移植到更快的语言（如 Rust）的可能性。
花了我30年才解决这个问题——绿幕问题[视频]
It Took Me 30 Years to Solve This VFX Problem – Green Screen Problem [video]
9 天前
关于按住版权联系我们创作者广告开发者条款隐私政策和安全性YouTube的工作原理测试新功能© 2026 Google LLC
## CorridorKey：解决长期存在的VFX问题
一项名为“CorridorKey”的新技术，有望大幅简化和改进视觉特效中的绿幕抠像。传统上，获得干净的色度键效果需要耗费大量时间，并且需要熟练的艺术家手动修复缺陷。CorridorKey利用人工智能，特别是经过合成数据训练的神经网络，自动从绿幕素材中创建高质量的Alpha通道（透明蒙版）。
这项关键创新在于绕过了对诸如迪士尼钠蒸汽工艺（难以复制）等专业设备的依赖，而是利用人工智能来*学习*完美的抠像。创造者强调，AI代理协助生成了训练数据，提高了效率。
虽然它并非完美解决方案——目前无法处理玻璃等造成的扭曲——但它显著减少了后期制作时间和成本，有可能以更少的专业知识实现更高质量的VFX。该工具提供了一个GUI界面，但目前仅限于Python，并且需要至少8GB的显存。该项目解决了存在数十年的问题，为专业人士和爱好者提供了一种更易于访问的解决方案。