最新

Anthropic 重写了 Claude Code 的终端渲染器，发现问题不在于 React，而在于 Ink 的行级重写。我将他们的方法构建成了一个独立的库。 CellState 使用自定义的 React 协调器，直接渲染到单元格网格，并在单元格级别逐帧进行差异比较。由于它在内联模式下运行而不是在备用屏幕上运行，因此保留了原生终端行为（滚动、文本选择、Cmd+F）。 React 的协调器只处理发生变化的子树，而单元格差异比较只覆盖视口，而不是整个回溯。 在 250 条消息（33KB 内容）的情况下，单个单元格更新会向终端写入 34 字节，与内容大小无关。Ink 为同样的更改写入 41,955 字节。完整的渲染流程（协调、布局、栅格化、单元格差异比较）需要 2.54 毫秒，而 Ink 需要 36.93 毫秒。 基准测试和方法：https://github.com/nathan-cannon/tui-benchmarks https://github.com/nathan-cannon/cellstate

我厌倦了浏览采样库、购买插件，以及拼命想用Suno创作原创音乐和声音设计。 我开发了一款DAW（数字音频工作站），音乐制作人或内容创作者可以免费试用！你可以独立生成单独的音轨、单次采样和音效，也可以在工作室模式下进行。 你还可以即时分享和混音作品，这在现有的音频领域里是难以想象的。 如果你想和我一起开发这款产品，请给我发邮件：kindred@sonurastudio.com :)

大家好，HN！我们是 Aakash 和 Viswesh，正在构建 Canary (<a href="https:&#x2F;&#x2F;www.runcanary.ai">https:&#x2F;&#x2F;www.runcanary.ai</a>)。我们构建 AI 智能体，它们可以阅读你的代码库，弄清楚 pull request 到底改了什么，并为每个受影响的用户工作流程生成并执行测试。<p>Aakash 和我之前在 Windsurf、Cognition 和 Google 构建过 AI 编码工具。AI 工具让每个团队在发布方面都变得更快，但在合并之前，没有人测试真实的用户行为。PR 变得越来越大，代码审查仍然发生在文件差异中，而看起来干净的更改却导致生产环境中的结账、身份验证和计费出现问题。我们亲眼目睹了这一切。我们创建 Canary 就是为了弥补这一差距。它的工作原理如下：<p>Canary 首先连接到你的代码库，并了解你的应用程序是如何构建的：路由、控制器、验证逻辑。你推送一个 PR，Canary 读取差异，理解更改背后的意图，然后针对你的预览应用程序生成并运行测试，检查真实的用户端到端流程。它直接在 PR 上评论，提供测试结果和录像，显示更改了什么，并标记任何行为异常的地方。你还可以通过 PR 评论触发特定的用户工作流程测试。<p>除了 PR 测试之外，从 PR 生成的测试可以移动到回归测试套件中。你还可以通过简单地用通俗易懂的英语提示你想要测试的内容来创建测试。Canary 从你的代码库生成一个完整的测试套件，安排它，并持续运行它。我们的一位建筑技术客户有一个发票流程，应付金额与最初的提案总额相差约 1,600 美元。Canary 在发布前就发现了他们发票流程中的回归问题。<p>这并非单一的基础模型家族可以单独完成的事情。质量保证（QA）涵盖了多种模式，例如源代码、DOM/ARIA、设备模拟器、视觉验证、分析屏幕录像、网络/控制台日志、实时浏览器状态等，任何单一模型都无法专门处理。你还需要自定义浏览器集群、用户会话、临时环境、设备端农场和数据播种，才能可靠地运行测试。最重要的是，捕捉代码更改的二阶效应需要一个专门的工具，它会以多种可能的方式破坏应用程序，影响不同类型的用户，而正常的快乐路径测试流程无法做到这一点。<p>为了衡量我们专门构建的 QA 智能体的表现，我们发布了 QA-Bench v0，这是第一个用于代码验证的基准测试。给定一个真实的 PR，一个 AI 模型能否识别出每个受影响的用户工作流程并生成相关的测试？我们针对 Grafana、Mattermost、Cal.com 和 Apache Superset 上的 35 个真实 PR，在相关性、覆盖范围和一致性这三个维度上，测试了我们专门构建的 QA 智能体与 GPT 5.4、Claude Code (Opus 4.6) 和 Sonnet 4.6 的对比情况。覆盖范围是差距最大的地方。Canary 领先 GPT 5.4 11 分，领先 Claude Code 18 分，领先 Sonnet 4.6 26 分。要了解完整的测试方法和每个代码库的细分，请阅读我们的基准测试报告：<a href="https:&#x2F;&#x2F;www.runcanary.ai&#x2F;blog&#x2F;qa-bench-v0">https:&#x2F;&#x2F;www.runcanary.ai&#x2F;blog&#x2F;qa-bench-v0</a><p>你可以在这里查看产品演示：<a href="https:&#x2F;&#x2F;youtu.be&#x2F;NeD9g1do_BU" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;NeD9g1do_BU</a><p>我们非常欢迎任何从事代码验证或考虑如何以不同方式衡量这一指标的人提供反馈。

我一直在构建一个 GPT-2 的交互式 3D + 2D 可视化。它显示了从 GPT-2 Small (124M) 中提取的真实激活值和注意力分数，这些数据是在前向传播过程中获得的。目标是通过展示模型内部发生的事情，来帮助大家更容易地学习 LLM（大型语言模型）的工作原理。<p>3D 部分使用 Three.js 构建，2D 部分使用纯 HTML/CSS/JS 构建。<p>很想听听您的想法或反馈！

我经营一家建筑设计咨询公司。我厌倦了每月向 Wix 支付 40 美元，却只能得到一个无法回答简单服务问题的宣传册，而且我还要花几个小时处理相同的常见问题解答。<p>所以我把它全部砍掉，花了 4 个月时间构建了一个“对话机器人”：<a href="https://axoworks.com" rel="nofollow">https://axoworks.com</a><p>技术栈完全是拼凑起来的：Netlify 的 10 秒无服务器超时迫使我将代理分成三部分：大脑（边缘服务器）、双手（浏览器）和声音（边缘服务器）。我已经 30 年没有写过代码了。这算得上是前进 3 步，后退 2 步，很大程度上是 AI 引导的。<p>证明它有效的战斗：两周前，一位持证建筑师攻击了这个机器人，试图证明我的商业模式会损害这个行业。AI（DeepSeek-R3）完全驳斥了他的论点。过程非常辛辣，令人捧腹。<p>日志：<a href="https://logs.axoworks.com/chat-architect-vs-concierge-v147.html" rel="nofollow">https://logs.axoworks.com/chat-architect-vs-concierge-v147.h...</a><p>一些惨痛的教训：<p>* Web Speech API 运行良好，直到有人在没有切换语言模式的情况下说中文。然后它会强行吐出英语的语音乱码。这仍然是个难题。<p>* 责任是致命的。如果 AI 虚构了建筑规范条款？我们就完蛋了。保险公司不会碰我们。<p>* 我们发布审计日志以保持诚实，并确保系统保持稳固。<p>审计：<a href="https://logs.axoworks.com/audit-2026-02-19-v148.html" rel="nofollow">https://logs.axoworks.com/audit-2026-02-19-v148.html</a><p>最难的部分是正确把握意图：让一个 LLM 在与房主交流时无缝切换到温暖的负责人语气，而在被同行攻击时切换到防御性的斗牛犬模式。这花了 2.5 个月的调整时间。<p>我们通过一个“Eager RAG”技巧（预先获取猜测）来消耗大量 token，只是为了提高响应速度。我还删除了“必要的”持久数据库——只有不到 5% 的访问者会再次访问，所以何必呢？如果客户在查询过程中中断，他们的会话就会消失。没有服务器端队列。<p>重点：让我能够与经验丰富的专业人士网络合作，并精简冗余环节。<p>试试看，能否把它搞坏。我会在评论区等着。继续

Kitten TTS 是一系列开源的、小巧且富有表现力的文本转语音模型，专为设备端应用设计。（去年我们在这里有一个讨论：<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44807868">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44807868</a>。）今天，我们发布了三个新的模型，分别拥有 8000 万、4000 万和 1400 万个参数。 其中最大的模型质量最高。1400 万参数的模型在表现力方面达到了同等规模模型的最新 SOTA 水平，尽管其大小小于 25MB。这次发布是对之前版本的重大升级，并支持英语文本转语音应用，提供八种声音：四种男声和四种女声。大多数模型都量化为 int8 + fp16，并使用 ONNX 进行运行时处理。该模型设计用于在任何地方运行，例如树莓派、低端智能手机、可穿戴设备、浏览器等。无需 GPU！本次发布旨在弥合设备端和云端模型在 TTS 应用方面的差距。多语言模型即将发布。 设备端 AI 的瓶颈在于：缺乏真正有效的微型模型。我们的目标是开源更多模型，以便完全在设备端运行可用于生产的语音助手和应用程序。欢迎您的反馈！