尽管人工智能编码代理在跨平台原生代码生成方面取得了进展，但许多应用程序——即使是来自Anthropic的Claude等人工智能领导者的应用程序——仍然依赖Electron。Electron允许开发者使用Web技术（HTML、CSS、JavaScript）构建适用于多种操作系统的桌面应用程序，虽然这会带来便利，但会导致应用程序体积更大、速度更慢。 核心问题不在于*创建*代码，而在于完善和*维护*代码。编码代理擅长开发过程的最初90%，但在边缘情况、错误修复以及实际使用所需的持续支持方面却面临困难。为每个平台（Mac、Windows、Linux）开发原生应用程序会将支持负担和平台特定问题的可能性增加三倍，而Electron的共享代码库可以减轻这种风险。 虽然明确的规范和测试套件*可能*能够实现代理驱动的原生开发，但“最后一步”的复杂性和增加的维护成本目前超过了收益，使得Electron成为许多开发者的务实选择。
每日HackerNews RSS
无需处理Linux、虚拟机、编译器或Python即可编写应用程序。立即开始。 无需安装。直接在浏览器中编写应用程序。跳过所有设置步骤！ 无需编辑JSON。资源通过友好的用户界面管理。 云端。随时随地访问！这很好，不是吗？ 更多功能即将推出。这仅仅是个开始！未来还有更多。
一个新的平台 repebble.com 旨在复兴 Pebble 智能手表的开发。Hacker News 上的讨论强调了最初“CloudPebble”服务的吸引力，它因其简单性而受到赞扬——允许开发者轻松构建和部署应用程序，且设置最少。
用户对现代智能手表开发环境的复杂性表示沮丧，并指出构建系统和所需配置方面存在问题。Repebble 提供了一种潜在的解决方案，通过提供简化的体验，可能允许开发者从单个文件编写和运行代码。
然而，一些用户指出 repebble.com 需要帐户才能保存和发布，希望有一个“访客模式”以便快速测试。尽管如此，云选项之外还提供本地开发工具被视为一个积极因素。最终，repebble.com 正在引起人们的兴奋，因为它有望恢复 Pebble 应用程序开发的便利性。
## Beagle SCM：代码数据库 传统的SCM系统，如Git，虽然强大，但已经变得过于复杂，更像文件系统而非代码数据库。这种复杂性会降低开发速度，尤其是在AI辅助开发兴起的情况下。Beagle旨在通过充当数据库来解决这个问题，它存储抽象语法树（AST），而不仅仅是blob，从而实现代码的语义查询和操作。 Beagle将操作简化为四个核心命令——GET、POST、PUT和DELETE，模仿HTTP，并利用URI进行寻址。它引入了repos、branches（更接近Git仓库）、twigs（比branches更轻量，用于临时工作）和overlays（类似于Photoshop的图层，分离代码、提示和配置）的层次结构。 关键特性包括确定性的、非侵入式的CRDT合并，允许安全灵活的分支和代码混合。Beagle支持高级查询——搜索特定符号或AST子树——超越了简单的`grep`功能，这既对开发者有益，也对LLM有益。该系统优先采用结构化但更简单的方法来管理代码，这对于处理越来越多的AI生成代码至关重要。最终，Beagle旨在成为一个简单、可靠的工具，用于将代码作为超文本进行管理，其中IDE充当浏览器，而Beagle充当`curl`/`wget`的等效工具。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Beagle CRDT SCM 外部接口 (gist.github.com)
8 分，作者 gritzko 1 天前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
gritzko 17 小时前 [–]
https://replicated.wiki/blog/partII.html 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
启用 JavaScript 和 Cookie 以继续。
## 雏鸡中的“布巴-基基”效应：摘要
最近发表在Science.org上的一项研究表明，即使是没有任何先前经验的刚孵化雏鸡，也存在“布巴-基基”效应——声音与形状的直观联想。研究人员发现，雏鸡始终将“基基”的声音与尖锐的形状配对，而将“布巴”的声音与圆形的形状配对。
讨论的中心在于*为什么*会发生这种情况。理论范围从声音的物理特性（较高频率与更锋利的边缘相关）到威胁性声音/形状与安全之间的先天性、潜在的进化关联。一些人认为这是多感官处理的一个基本方面，连接了视觉和听觉信息。
这些发现令人着迷，因为它们将这种效应与复杂的语言起源分离开来，表明它具有更原始的认知基础。然而，对于复制性和潜在的实验者偏差，仍然存在怀疑。这项研究引发了关于这种效应在不同物种中的普遍性，以及它是否揭示了大脑处理和分类感官信息的更深层洞察力的争论。最终，它强调了看似“显而易见”的联系可能具有潜在的神经学根源。
## MeshTNC：面向消费级无线电的LoRa数据管道 - 摘要
MeshTNC是一种固件，旨在使现成的无线电，特别是MeshCore支持的无线电，能够进行LoRa数据传输和接收。它提供了一个串行命令行界面（CLI），用于控制无线电功能，例如传输原始十六进制数据、配置无线电参数（频率、带宽等）以及记录数据包。
主要功能包括：LoRa数据包和BLE嗅探，并将数据记录到串行端口；KISS-TNC模式，与现有的APRS软件（如Linux内核和流行的客户端）兼容；以及在MeshTNC设备之间建立基于AX.25的IP网络的能力。
安装涉及在Visual Studio Code中使用PlatformIO，通过meshcore flasher或开发者工具刷写固件，并通过串行端口连接（默认波特率115200）。CLI提供用于无线电控制、记录和在串行模式与KISS模式之间切换的命令。KISS模式允许MeshTNC充当传统的TNC，从而可以使用APRS工具。 详细文档和示例可在网上找到，包括设置基于LoRa的基本网络说明。
## 数据包无线电与LoRa：怀旧复兴？
一款名为MeshTNC的新工具，允许使用消费级LoRa无线电作为KISS TNC——本质上是无线电通信的调制解调器——引发了关于数据包无线电现状的讨论。尽管曾经很流行，尤其是在90年代用于数字通信和BBS类似的网络，但随着互联网和更快调制解调器速度的普及，这项爱好逐渐衰落。
用户们回忆起通过HF数据包无线电和卫星跳跃进行远距离通信，强调了在广泛互联网普及之前，这种免费、可访问的通信方式的吸引力。然而，9600波特速率和带宽拥塞等限制导致了它的衰落。
目前，APRS仍然活跃，但有些人觉得它缺乏满足感。像MeshTNC和KISSLoraTNC这样的新项目正在涌现，利用LoRa的长距离、低带宽能力。有些人甚至正在构建用户态AX.25协议栈，以将这些技术与现有基础设施连接起来，从而可能实现对家庭网络的远程访问。虽然VARA和弱信号模式正在获得关注，但数据包无线电的核心吸引力——一种社区驱动、可访问的通信方式——似乎正在经历复兴。
## SDLC 的衰落与 AI 原生开发的兴起 传统的软件开发生命周期 (SDLC) – 需求、设计、实现、测试、评审、部署、监控 – 并非仅仅加速，而是随着 AI 编码代理的出现而瓦解。AI 促成了一个紧密的 **意图、构建、观察和重复** 循环，取代了线性、阶段性的流程。 进入该领域的工程师通常甚至 *不了解* SDLC，因为他们直接借助 AI 辅助将想法转化为可用的代码，绕过了诸如 sprint 计划和详尽代码审查等传统流程。 SDLC 的每个阶段都正在被从根本上改变：需求变得迭代，设计通过 AI 建议 *发现*，实现自动化，测试与编码同步进行，代码审查在很大程度上已过时，部署是持续的。 在这个新范式中成功的关键不是流程，而是 **上下文**。向 AI 代理提供清晰、详细的上下文至关重要。虽然监控仍然至关重要，但它必须从以人为本的仪表盘发展为允许代理自我纠正的自动化反馈循环。 未来属于能够有效引导 AI 的“上下文工程师”，以及利用直接影响代理行为的可观察性技术的团队——而不是那些坚持过时工作流程的团队。
## EDuke32：终极《Duke Nukem 3D》体验
EDuke32是一个免费、开源且积极开发的《Duke Nukem 3D》经典第一人称射击游戏的源代码移植版本，使其能够在现代平台（如Windows、Linux和macOS）上运行，甚至超越这些平台！它由一个专注的社区创建，通过数千项改进，为玩家和模组制作者提供了比原版游戏更好的体验。
主要特性包括一个尖端的“Polymer”渲染器，提供动态光照、实时阴影和高级纹理支持，需要强大的显卡才能充分利用。EDuke32修复了原版游戏中存在的许多错误，确保在现代系统上的稳定性，并支持极高的分辨率。
除了《Duke Nukem 3D》之外，它还包含《Shadow Warrior》（VoidSW）的移植版本，并支持《NAM》等经典游戏。凭借扩展的脚本系统、全面的控制台和现代控制方式，EDuke32提供了显著增强且可定制的游戏体验，并在开发二十多年后持续发展。
## Duke Nukem 3D 与黑客新闻上的怀旧
最近黑客新闻上出现了一场关于 Duke Nukem 3D（EDuke32 开源移植版）的讨论，引发了一波怀旧回忆。用户分享了他们早期与这款游戏相关的经历——从十几岁时制作标志，到为盗版游戏而挣扎，以及编辑关卡的刺激。
这场对话突出了 Duke Nukem 3D 作为第一批大力鼓励模组的 FPS 游戏的影响，这归功于它的 Build 引擎。许多人 fondly 回忆了局域网派对、自定义地图以及标志性的武器，如冰冻射线和管状炸弹。
除了游戏本身，该帖子还涉及了围绕 Doom、Quake 和 Blood 等经典 FPS 游戏的持久社群，以及源代码移植和模组的持续开发。 还有关于人工智能为这些老游戏生成新内容的潜力，以及对现代射击游戏中经常缺失的触觉手感的共同欣赏的讨论。 几位用户推荐了 Duke3D 的“Alien Armageddon”模组和 Doom 的“Ashes 2063”模组。
作者强烈厌恶现代前端开发中的“魔法”——对复杂且常常不甚理解的技术的依赖，例如JavaScript库、框架（尤其是React），以及现在，AI生成的代码。这源于对控制权的渴望，以及对这些抽象化会降低开发者的能动性并造成长期维护噩梦的信念。 虽然承认像npm和大型语言模型这样的工具的实用价值，作者更喜欢在个人项目中坚持使用原始的HTML、CSS和JavaScript，优先考虑理解和持久性而非速度。他们承认这种立场在商业上不可行，甚至拒绝了需要使用React的客户工作。 核心论点是，虽然抽象化可以加速开发，但往往以牺牲理解为代价。代码库变得依赖于“咒语”——效果不明的函数，并在原始开发者的理解丧失时变得脆弱。对于长期项目，作者认为保持对代码的深刻理解至关重要，因此手工制作，即使速度较慢，也是更可取的方法。归根结底，这是一种对工艺而非便利的偏好。
## 黑客新闻讨论总结：“我不喜欢魔法”
一篇名为“我不喜欢魔法”的文章引发了黑客新闻的讨论，讨论的核心是软件开发中的抽象与对基础理解的渴望之间的 tension。原文作者表达了对 React 等复杂框架的不适，更倾向于使用 HTML、CSS 和 JavaScript 等“原始”技术。
许多评论者争论这种对抽象的反感是否合理。一些人同意，认为“魔法”（不透明的代码行为）会阻碍调试和长期维护。另一些人则认为所有软件都依赖于抽象层——甚至编译器和操作系统——并且专业化是必要的。 许多人指出框架对团队协作和生产力的好处。
一个关键的争论点是“魔法”的定义，一些人区分了有用的抽象和那些掩盖底层功能的抽象。AI 辅助编码的兴起也进入了讨论，一些人认为它可能会进一步降低对深入理解的需求。最终，这场讨论突出了软件开发中不同的理念，在控制和理解与实用主义和效率之间取得平衡。
zclaw：在ESP32上运行的，不到888KB的个人AI助手。
zclaw: personal AI assistant in under 888 KB, running on an ESP32
2 天前
## zclaw：适用于ESP32的微型AI助手
zclaw是一款轻量级AI个人助手，专为在ESP32板上运行而设计，固件尺寸非常小（<= 888KB）。它使用C语言编写，可以实现对计划任务、GPIO引脚和持久内存的自然语言控制。
用户可以创建自定义工具，并通过Telegram或托管Web中继与zclaw交互。它支持流行的LLM提供商，如Anthropic、OpenAI和OpenRouter，并在ESP32-C3、S3和C6板上进行了测试。
设置过程简化为一行启动脚本，然后进行烧录和凭证配置。提供了全面的文档和各种脚本，用于构建、烧录（包括安全选项）、测试和基准测试性能。zclaw非常适合寻求有趣且可黑客改造的AI驱动ESP32项目的爱好者和开发者。
## zclaw 与 OpenClaw 炒作：总结
一个名为 zclaw 的新项目允许在 ESP32 微控制器（小于 888KB）上运行个人 AI 助手。这在 Hacker News 上引发了讨论，主要围绕这些“爪子”的简单性——本质上是 LLM 发起 API 调用——以及一些技术专业人士缺乏基本的计算机科学理解。
许多评论员指出，核心概念并非新颖，是对现有“AI 代理”技术的重现。围绕使用 Mac Mini 作为主机产生的炒作受到了质疑，因为树莓派可以实现类似的结果。
讨论延伸到潜在的应用场景（智能电子宠物、自动化电子邮件/社交媒体管理）和本地模型的局限性。虽然赋予日常设备智能代理的想法很有趣，但人们对安全性和实用性提出了担忧。最终，这场对话凸显了对这些简单 AI 循环与更复杂、传统工程解决方案的价值的争论。 几位用户建议了其他的 ESP32 项目，例如桌面机器人或合成器。
Inputlag.science 是一个致力于理解和解决输入延迟——玩家操作与屏幕反应之间的延迟——的资源站点，尤其是在游戏系统中。 输入延迟曾经是一个小问题，但随着游戏技术的日益复杂，它变得越来越严重。
该网站解释说，延迟增加源于现代系统的复杂性以及开发者对导致延迟因素的认识不足。 它将“延迟链”分解为三个关键组成部分：控制器、游戏引擎和显示器。
Inputlag.science 旨在教育开发者和消费者，提供识别和减轻输入延迟的知识和测量技术，尤其侧重于控制器和游戏引擎方面。 最终目标是帮助将游戏体验的响应速度恢复到早期水平。
## 游戏输入延迟：摘要
一则Hacker News讨论集中在游戏输入延迟这一复杂问题上，详细介绍了如何测量和理解它。虽然延迟经常被归咎于显示器，但它实际上源于一个链条，包括控制器、游戏引擎和显示设备。
用户分享了测量延迟的方法，从昂贵的高速摄像机到令人惊讶的有效智能手机慢动作录制（120-240Hz），逐帧分析输入与屏幕反应之间的延迟。准确的测量需要重复测试以了解延迟的统计分布，而不仅仅是一个数字。
对话深入到技术细节，讨论了USB轮询率（现在1-8kHz与旧的PS/2速率）、窗口合成器的影响（尤其是在Linux上）以及Vulkan的演示API等技术的优势。流媒体/远程游戏也会增加显著的延迟。
一个关键的结论是，一致的延迟比可变的延迟更好，即使是小的延迟（10毫秒）也可能被注意到，特别是对于音乐家而言。讨论强调了理解整个系统的重要性，而不仅仅关注一个组件，并指出缺乏针对游戏玩家的全面研究和准确信息。