最新

Bambu制造出色的硬件，但您的数据存储在他们的云端，无法导出。当打印完成时，作业从任何有用的记录保存角度来看基本上就消失了。 BamBuddy通过在您自己的机器上运行并连接到打印机的本地MQTT接口来解决这个问题——它实时捕捉所有信息：缩略图、耗材使用、时间、切片设置。您将拥有一个完全可搜索的打印历史档案，完全属于您，能够离线工作，并且从不接触Bambu的服务器。 需要注意的是：他们的本地API没有文档，因此早期的很多工作都是对协议进行逆向工程。这项工作仍在进行中，因为固件更新偶尔会导致问题。 技术栈：TypeScript，自托管，约700颗星，小而活跃的贡献者社区。 GitHub: [https://github.com/maziggy/bambuddy](https://github.com/maziggy/bambuddy) 文档: [https://wiki.bambuddy.cool](https://wiki.bambuddy.cool)

在为客户构建自主应用程序的两年后，我感到精疲力竭。我成了唯一的失败点，没有备份。需求收集、提示工程、应用开发、沙盒测试，所有工作都通过团队中最资深的开发者进行，而这个人总是我。 根本原因并不在于团队或客户，而在于我们设计代理的方式：除非采用一个知名的代理框架，否则没有明确的边界。 我开始这个项目是因为绘制开发者已经熟悉的清晰边界感觉是正确的做法。 为了自我验证，我定义了一个具有简单拓扑结构的游戏开发专家（计划 → 构建 → 验证 + 协调员），并在5个模型上运行了相同的任务。 以下是结果： [https://github.com/perstack-ai/demo-catalog](https://github.com/perstack-ai/demo-catalog) 查询很简单：“创建一个类似于《魔法迷宫》的地下城爬行游戏……” 在评估时，我专注于三个方面。(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的Hayden、Ronan、Avi和Warren（<a href="https://voltairlabs.com">https://voltairlabs.com</a>）。我们正在开发用于电力设施检查的气候适应型混合固定翼无人机。 这里有一些视频资料：<a href="https://vimeo.com/1173862237/ac28095cc6?share=copy&fl=sv&fe=ci" rel="nofollow">https://vimeo.com/1173862237/ac28095cc6?share=copy&fl=sv&fe=...</a>，以及我们最新原型的照片：<a href="https://imgur.com/a/bYHnqZ4" rel="nofollow">https://imgur.com/a/bYHnqZ4</a>。 美国有700万英里电力线路（足够往返月球14次），这些线路正在老化。超过50%的电力通过至少已有30年历史的变压器，这大约是它们开始出现故障的时间。 电力线路导体仅仅是裸露的金属，承载着4,000到765,000伏特的电压，通常悬挂在陶瓷绝缘体上，支撑它们的通常是木材。这是一种成本效益高且相对可靠的电力传输方式。但是，当木材开始腐烂，或者插销掉落，带电导体在风大的日子里掉落到一棵枯树上时，就会引发像去年洛杉矶的帕利塞德火灾那样毁灭性的野火。 大多数电力公司通过步行巡检来解决这个问题。电工们开车带着夹板或iPad，使用望远镜通过检查清单来目视确认一切正常。一个电工每天可以检查大约50到150根电杆，但一些最小的农村电力合作社（大约20名员工）通常有大约50,000根配电杆。显然，这样的数学计算是行不通的。因此，某根电力杆的检查频率大约是每10年一次（至少这是他们告诉保险理赔员的）。 直升机也被用来进行检查，但起飞费用高达25,000美元，更重要的是，每年都有电工在直升机坠毁中丧生。此外，卫星无法提供这些检查所需的毫米级精度。 无人机已经成为最佳解决方案。乔治亚电力公司在转向使用无人机后节省了60%的运营费用，而Xcel电力发现无人机能够发现比步行巡检多60%的缺陷（因为无人机可以从电杆顶部进行观察）。 问题二：无人机受到需要不断充电和FAA超视距（BVLOS）法规的限制。作为回应，资金最充足的电力公司（例如PG&E、SCE）主要派出驾驶员在卡车中收集数据。 目前无人机领域的领导者——Skydio和DJI——已经构建了无人机箱解决方案。这些充电站存在固有的并发限制（一次只能充电一架无人机），并且在大面积土地上扩展困难。Skydio的收费是每个箱子25万美元，且在理想性能下的往返范围约为15英里。它们既昂贵又不灵活。 我们的第一个解决方案（以及为什么没有成功）：我们进入YC时想要构建能够从电力线路周围的磁场中感应充电的无人机。我们使用了一个分裂式电流变压器，将其夹在导体上并收集电力。我们花了大约4个月的时间测试和开发这个硬件，并成功在现场给一些电池充电。这是一个非常酷的概念验证。 但我们遇到了一个大问题。配电线路上的电流不足。这些是你家外面的木杆，而不是你在乡村可能看到的高大的钢铁输电塔。一般来说，我们需要大约1兆瓦的电力——或大约1000户家庭——通过线路流动，以便高效地为我们的无人机充电。

我在小时候花了很多时间在BBS门口游戏上，尤其是《贸易战争》占据了我大部分的晚上。我一直想重温那种体验，终于实现了。 这是一个作为Telegram机器人运行的多人太空贸易游戏。玩家在港口之间交易商品，升级船只，组建公司，并在共享的银河中争夺领土。游戏的回合每天刷新，因此每次游戏只需几分钟的文本指令。 我选择Telegram是因为整个游戏在极少的带宽下也能运行——你可以在飞机的WiFi上、在偏远地区的信号不稳定的地方，或者任何可以发送短信的地方进行游戏。无需安装应用程序，也无需打开浏览器。 现在寻找玩家来测试经济系统并提供反馈。请通过链接加入 <a href="https:&#x2F;&#x2F;t.me&#x2F;spacetraderlobby" rel="nofollow">https:&#x2F;&#x2F;t.me&#x2F;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制作原创音乐和声音设计。<p>于是我构建了一个供任何音乐制作人或内容创作者免费试用的数字音频工作站（DAW）！你可以生成独立的音轨、单声道音效和独立的音效，或者在工作室模式下使用。<p>你还可以即时分享和混音曲目，这在现有的音频领域中是非常痛苦的。<p>如果你想和我一起合作，请发邮件到kindred@sonurastudio.com :)

嗨，HN！我们是Aakash和Viswesh，我们正在构建Canary（<a href="https://www.runcanary.ai">https://www.runcanary.ai</a>）。我们开发的AI代理可以读取你的代码库，识别拉取请求（PR）实际更改了什么，并为每个受影响的用户工作流程生成并执行测试。 Aakash和我之前在Windsurf、Cognition和Google开发过AI编码工具。AI工具使每个团队在交付上变得更快，但在合并之前，没有人测试真实用户的行为。PR变得越来越大，审查仍然是在文件差异中进行的，而看似干净的更改在生产环境中却导致了结账、身份验证和计费等问题。我们亲眼目睹了这一切。我们创建Canary就是为了填补这个空白。以下是它的工作原理： Canary首先连接到你的代码库，并理解你的应用是如何构建的：路由、控制器、验证逻辑。你推送一个PR，Canary读取差异，理解更改背后的意图，然后生成并在你的预览应用上运行测试，检查真实用户的完整流程。它会直接在PR上发表评论，提供测试结果和录屏，展示更改内容，并标记任何不符合预期行为的部分。你还可以通过PR评论触发特定的用户工作流程测试。 除了PR测试外，从PR生成的测试可以移入回归测试套件。你也可以通过简单的英文提示创建测试。Canary会从你的代码库生成完整的测试套件，安排并持续运行它。我们的一个建筑科技客户在发票流程中发现应付金额与原始提案总额偏差了约1600美元。Canary在发布之前捕捉到了他们发票流程中的回归问题。 这并不是单一的基础模型能够独立完成的任务。质量保证（QA）涉及多个模态，如源代码、DOM/ARIA、设备模拟器、视觉验证、分析屏幕录制、网络/控制台日志、实时浏览器状态等，任何单一模型都难以专注于这些。你还需要定制的浏览器集群、用户会话、临时环境、设备农场和数据预置，以可靠地运行测试。此外，捕捉代码更改的二次效应需要一个专门的工具，以多种可能的方式破坏应用程序，而普通的顺利路径测试流程无法做到这一点。 为了衡量我们专门构建的QA代理的效果，我们发布了QA-Bench v0，这是第一个代码验证基准。给定一个真实的PR，AI模型能否识别每个受影响的用户工作流程并生成相关测试？我们将我们的专用QA代理与GPT 5.4、Claude Code（Opus 4.6）和Sonnet 4.6进行了测试，涵盖了Grafana、Mattermost、Cal.com和Apache Superset上的35个真实PR，从相关性、覆盖率和一致性三个维度进行评估。覆盖率是差距最大的地方。Canary在覆盖率上领先GPT 5.4 11分，领先Claude Code 18分，领先Sonnet 4.6 26分。有关完整的方法论和每个代码库的详细分析，请阅读我们的基准报告：<a href="https://www.runcanary.ai/blog/qa-bench-v0">https://www.runcanary.ai/blog/qa-bench-v0</a> 你可以在这里查看产品演示：<a href="https://youtu.be/NeD9g1do_BU" rel="nofollow">https://youtu.be/NeD9g1do_BU</a> 我们非常希望听到任何在代码验证方面工作或考虑如何以不同方式衡量此事的人的反馈。

我正在构建一个互动的3D + 2D可视化工具，用于展示GPT-2。它展示了在前向传播过程中从GPT-2 Small（124M）提取的真实激活值和注意力分数。这个工具的目标是通过展示模型内部的运作，帮助人们更容易理解大型语言模型（LLMs）的工作原理。 3D部分是使用Three.js构建的，而2D部分则是使用普通的HTML/CSS/JS制作的。 非常期待听到你的想法或反馈！

我经营一家建筑设计咨询公司。我厌倦了每月支付40美元给Wix，只为了一个无法回答简单服务问题的宣传册，同时还浪费了几个小时在同样的常见问题上。 于是我决定彻底放弃，花了4个月时间构建一个“对话者”： [https://axoworks.com](https://axoworks.com) 这个技术栈完全是临时拼凑的：Netlify的10秒无服务器超时迫使我将代理分成三个部分：大脑（边缘计算）、双手（浏览器）和声音（边缘计算）。我已经有30年没写代码了。这一过程就像是前进三步、后退两步，主要依靠人工智能的指导。 证明它有效的斗争：两周前，一位持证建筑师对我的机器人发起攻击，试图证明我的商业模式对这个行业有害。AI（DeepSeek-R3）完全驳倒了他的论点，过程非常幽默且尖锐。 日志： [https://logs.axoworks.com/chat-architect-vs-concierge-v147.html](https://logs.axoworks.com/chat-architect-vs-concierge-v147.html) 一些“战斗伤疤”： * 网络语音API工作得很好，直到有人在没有切换语言模式的情况下说中文。然后它会强行输出英语发音的胡言乱语，依然让人头疼。 * 责任是致命的。如果虚构了一条建筑规范条款？我们就完了。保险公司不会理会我们。 * 我们发布审计日志，以保持诚实并确保系统的安全性。 审计： [https://logs.axoworks.com/audit-2026-02-19-v148.html](https://logs.axoworks.com/audit-2026-02-19-v148.html) 最困难的部分是正确理解意图：让一个大型语言模型在与房主交流时无缝切换到温暖的校长语气，而在受到同行攻击时则变得像一只防御性的斗牛犬。这花了我2.5个月的调试时间。 我们通过一种“急切的RAG”黑客技术（预取猜测）快速消耗令牌，以提高响应速度。我还去掉了“必要的”持久数据库——不到5%的访客会再次访问，那何必呢？如果客户在查询过程中中途退出，他们的会话就会消失。没有服务器端的队列。 重点是：让我能够与一群经验丰富的专业人士合作，并精简流程。 试着去破坏它。我会在评论区等你。

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