最新

在为客户构建智能体应用两年后，我 burnout 了。我成了唯一的故障点，没有任何备用方案。需求收集、提示工程、应用开发、沙盒测试，所有事情都由团队里最资深的开发者负责，而这个人总是我的化身。 根本原因不在于团队或客户，而在于我们设计智能体的方式：除非你采用一个众所周知的智能体框架，否则没有明确的边界。 我开始这个项目是因为，为开发者们绘制他们已经熟悉的清晰边界，我觉得是正确的做法。 为了进行“自举测试”，我定义了一个游戏开发专家，拥有一个简单的拓扑结构（计划 → 构建 → 验证 + 协调器），并在 5 个模型上运行了相同的任务。 以下是结果：<a href="https://github.com/perstack-ai/demo-catalog" rel="nofollow">https://github.com/perstack-ai/demo-catalog</a> 查询很简单：“创建一个类似《巫术》的地下城探险游戏...” 在评估中，我只关注了三件事：（1）专家是否遵守我的指示？（2）结果是否经过验证并且实际有效？（3）API 成本是否可承受？ 为什么是这三点？因为即使框架架构很稳固，也需要从指令遵循、最低质量保证和成本效益这几个方面来评估智能体。这是我从与客户合作中得到的经验。 我注意到： * 5 个模型中有 3 个遵循了完整的计划 → 构建 → 验证流程，并产生了经过验证的有效输出，无需特定于提供商的调整。拓扑结构定义一次，即可原样运行。 * Claude（4.6 Opus + 4.6 Sonnet）产生了最丰富的输出，并且完美地遵循了指令。它还实现了所有提供商中最高的缓存命中率（96%），但定价仍然使总成本达到了最接近竞争对手的 8 倍。 * Kimi K2.5 以 3.43 美元的价格产生了出色的输出，并且最忠实于委托任务。在这次测试中，它在指令遵循和质量方面都优于 GPT 和 Gemini。 * Gemini（3.1 Pro + 3.0 Flash）遵循了完整的流程并制作了一个经过验证的游戏。但它的输出比 GPT 的更糟糕，几乎无法玩。 * GPT（5.4 + 5-mini）是最快和最便宜的，但完全跳过了验证步骤。它调用了三次构建，而不是遵循流程。 * MiniMax M2.5 完全忽略了指令，制作了一个基于浏览器的 HTML 游戏。指令遵循是一个挑战，但最新版本 M2.7 最近宣布了改进，所以我很期待。 这只是演示目录中的一个任务。但每次运行的完整执行日志都在仓库中，因此您可以确切地看到每个模型做了什么，并自己重现它。

大家好，我们是Voltair（<a href="https://voltairlabs.com/">https://voltairlabs.com/</a>）的Hayden、Ronan、Avi和Warren。我们正在制造耐候型混合动力固定翼无人机，用于电力公司的巡检。<p>这里有一些视频：<a href="https://vimeo.com/1173862237/ac28095cc6?share=copy&amp;fl=sv&amp;fe=ci" rel="nofollow">https://vimeo.com/1173862237/ac28095cc6?share=copy&amp;fl=sv&amp;fe=...</a>，以及我们最新原型机的照片：<a href="https://imgur.com/a/bYHnqZ4" rel="nofollow">https://imgur.com/a/bYHnqZ4</a>。<p>美国有700万英里的输电线路（足够绕月球14圈）。超过50%的电力流经至少有30年历史的变压器，而这正是它们开始出现故障的节点。<p>电力公司尤其面临风险。导电体只是裸金属，上面承载着4,000-765,000伏的电压，放置在陶瓷绝缘体上，通常由木头支撑。这是一种经济高效且相对可靠的输电方式。但当木头开始腐烂，或者开口销脱落，导致带电导体掉落在有风的日子的枯树上时，就会引发毁灭性的野火，比如去年的洛杉矶帕利塞德斯大火。<p>大多数电力公司通过徒步巡逻来解决这个问题。线路工人带着剪贴板或iPad开车出去，用双筒望远镜查看清单，以目视确认一切正常。一个线路工人一天可以检查大约50-150个电杆，但一些最小的农村电力合作社（大约有20名员工）通常有大约50,000个配电杆。显然，这在数学上是行不通的。因此，一个电杆大约每10年检查一次（至少他们是这样告诉他们的保险理算员的）。<p>直升机也被使用，但起飞成本为25,000美元，更重要的是，每年都有线路工人在直升机坠毁中丧生。还要注意的是，卫星无法提供这些检查所需的毫米级精度。<p>无人机已经成为最佳解决方案。佐治亚电力公司在使用无人机后节省了60%的运营费用，而Xcel电力公司发现无人机比徒步巡逻发现了多60%的缺陷（因为无人机具有杆顶视角）。<p>问题#2：无人机受到需要不断充电和美国联邦航空管理局（FAA）超视距（BVLOS）法规的限制。因此，资金最充足的电力公司（例如，PG&amp;E，SCE）主要派出卡车里的飞行员来收集数据。<p>目前无人机领域的领导者——Skydio和DJI——已经构建了无人机入箱解决方案。这些充电站具有固有的并发限制（一次只能使用一架无人机），并且无法在大面积土地上轻松扩展。Skydio的收费是每个箱子250,000美元，并且往返距离约为15英里（假设性能理想）。它们价格昂贵且不灵活。<p>我们的第一个解决方案（以及它为什么不起作用）：我们进入YC时，希望制造能够从输电线路周围的磁场中感应充电的无人机。我们使用分体式电流互感器，用夹子将其缠绕在导线上，并收集电力。我们花了大约4个月的时间测试和开发这种硬件，并在现场成功地为几块电池充电。这是一个非常酷的概念验证。<p>但我们遇到了一个大问题。配电线路上的电流不足。这些是您家外的木杆，而不是您可能在乡村看到的高耸的钢制输电塔。一般来说，我们需要大约1兆瓦的电力——或者大约1000户家庭——通过线路才能为我们的无人机高效充电。

我小时候花了很多时间玩BBS上的门游戏——特别是《贸易战争》几乎吞噬了我大部分的夜晚。我一直想重现那种体验，终于实现了。 这是一个多人太空贸易游戏，以Telegram机器人形式运行。玩家在港口之间交易商品，升级飞船，组建公司，并争夺共享星系中的领土。回合每天刷新，所以一局游戏只需要几分钟的文本命令。 我选择Telegram是因为整个游戏只需要极少的带宽——你可以在飞机上的Wi-Fi、荒郊野外的断断续续的连接，或者任何可以发送短信的地方玩。无需安装应用程序，无需打开浏览器。 正在寻找玩家来压力测试经济系统并提供反馈。通过链接 <a href="https://t.me/spacetraderlobby" rel="nofollow">https://t.me/spacetraderlobby</a> 或 Telegram群组 @spacetraderlobby 加入。

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 的瓶颈在于：缺乏真正有效的微型模型。我们的目标是开源更多模型，以便完全在设备端运行可用于生产的语音助手和应用程序。欢迎您的反馈！