最新

我构建了 k-synth，作为一个实验，看看极简主义的、受 K 语言启发的数组语言是否能比传统代码更快、更直观地绘制波形。我创建了一个基于网络的工具包，您可以在浏览器中直接尝试语法，而无需接触编译器： 在线工具包：<a href="https:&#x2F;&#x2F;octetta.github.io&#x2F;k-synth&#x2F;" rel="nofollow">https:&#x2F;&#x2F;octetta.github.io&#x2F;k-synth&#x2F;</a> 如果您访问该页面，这里有一个快速获得音频结果的步骤： - 点击“patches”并选择 dm-bell.ks。 - 点击“run”——笔记本区域将更新。点击波形以听到结果。 - 点击波形下方的“->0”按钮，将其复制到顶部的槽位 0（槽位也是可点击的）。 - 在输入区域点击“pads”以显示一个演奏网格。 - 点击“melodic”以在网格上以不同的间隔播放槽位 0 的样本。 “奇怪”的技术栈： - 语言：一种简化的、右结合的数组语言（例如，s 代表正弦，p 代表 pi）。 - Web 工具包：使用 WASM 和 Web Audio 构建，用于实时编码样本。 - AI 结对编程：我使用 AI 代理来引导解析器和 Web 样板，这让我可以在几周而不是几个月内审查语言设计。 目标：这并非旨在取代 DAW。它是一种为大型项目生成样本的紧凑方式。它目前处于“能否混合”的状态。我正在寻求来自数组语言和 DSP 社区的反馈——特别是在运算符选择和从右到左的求值逻辑方面。 源代码 (MIT 许可证)：<a href="https:&#x2F;&#x2F;github.com&#x2F;octetta&#x2F;k-synth" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;octetta&#x2F;k-synth</a>

嗨，各位 HN 用户， 我开发了 OpsOrch，因为运维工作分散在太多的工具中。 事故可能发生在 PagerDuty 中，日志在 Datadog 中，指标在 Prometheus 中，而运行手册又在其他地方。每个系统都有自己的 API 和数据模型，因此跨工具的工作流程通常会变成胶水代码。 OpsOrch 是我尝试将其标准化的尝试。 它定义了一个通用模式，用于处理诸如事故、日志、指标、警报、服务和运行手册之类的内容，然后使用适配器将不同的提供商连接到一个接口后面。 目标很简单：客户端无需编写特定于供应商的逻辑，就可以请求： - 影响服务的事故 - 相关的日志和指标 - 关联的运行手册上下文 我特别感兴趣的是关于这种抽象是否真正有用的反馈，或者它在实践中是否会变得过于通用。 很乐意回答有关模式、适配器模型和权衡的问题。

我构建了一个基于训练证明的 L1 区块链，矿工们训练一个共享的 MinGRU 神经网络，而不是计算 SHA-256 哈希值。每个区块都会让模型变得更智能。 与比特币的主要区别： - 矿工们竞争验证损失的改善，而不是哈希目标 - 每个区块包含一个可验证的模型检查点 - 网络产生一个公开可用的 AI 模型作为副产品 - MinGRU 架构比 Transformer 架构的参数效率高约 388 倍 技术细节： - 65000 行 C++20 代码，可在 Windows/Linux/macOS 上构建 - 4 个 GPU 后端：CUDA、Vulkan、Metal、CPU 备用 - Lightning Network 用于即时支付 - Ed25519 签名，Keccak-256d 哈希，Bech32 地址 - 模型持续增长：d_model 从 384 开始，每个区块增加 +2 - 供应上限：2100 万个币，10 分钟区块，基于供应量的减半 模型随着网络增长。早期的区块训练一个 2600 万参数的小模型。随着更多矿工在几年内加入，它会扩展到数十亿个参数——到那时，手机的性能将足以在本地运行它。没有 API 密钥，没有订阅，没有审查制度。 创世消息：“OpenAI 在 2026 年烧掉 140 亿美元，将广告添加到 ChatGPT 作为最后的手段” 白皮书：[https://kristian5013.github.io/resonancenet/ResonanceNet_Whitepaper_V2.pdf](https://kristian5013.github.io/resonancenet/ResonanceNet_Whitepaper_V2.pdf)

我偶然看到 shannoncc 的一篇文章，题为“我 60 岁了。Claude Code 重新点燃了我的热情”，这让我陷入了沉思。我也（快）60 岁了，但 AI 却扼杀了我的热情。我记得所有 AI 出现之前的日子，那时我白天、晚上、周末和假期都享受着编程的乐趣。现在这一切都已不复存在，而其他人却“重新点燃了热情”。 我认为这取决于你喜欢什么：过程还是结果。我一直喜欢过程，我认为现在玩得很开心的人喜欢的是结果。AI 给了我们更多的结果，但更少的过程。这并没有好坏之分，只是不同而已。

我构建了一个 Claude Code 技能，可以将你的终端变成扑克牌桌。你将与三个 AI 对手玩无限注德州扑克，每个对手都作为独立的 Claude 子代理运行，拥有自己的个性和隐藏的牌。主代理充当荷官，管理游戏状态，并可选择提供指导。<p>指导方面有三种模式：完全不提供帮助、在每次决策前提供实时提示，或仅在牌局结束后进行分析。<p>温馨提示：Claude 在每手牌中都会发挥到极致。预计会比任何真实的牌桌产生更多的同花顺和戏剧性的河牌。<p><pre><code> ╭─────────────────────╮ │ 底池：130 │ │ Q♥ 9♦ 4♠ │ Alex │ │ Jordan [990] ╰─────────────────────╯ [905] (小盲) (大盲) 弃牌 下注 50 你 &lt;- Sam [965] [1000] (按钮位) (UTG) ┌────────┐ 弃牌 │ K♠ Q♠ │ └────────┘ 教练的悄悄话：你翻牌中了顶对，带一个 K 踢脚——在这里是一手非常强的牌。Jordan 是翻牌前的加注者，并且正在对你进行持续下注，这是标准操作。跟注是稳妥的选择，可以保持底池可控。你也可以加注到大约 140 来获取价值和保护，但在位置上跟注并让 Jordan 继续下注也是一个非常好的策略。 [F] 弃牌 [C] 跟注 50 [R] 加注到 ___ </code></pre> 在第一个终端中 Claude 工作时，可以在你的第二个终端中做点事情。<p>代码库：<a href="https:&#x2F;&#x2F;github.com&#x2F;BohdanPetryshyn&#x2F;code-royale" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;BohdanPetryshyn&#x2F;code-royale</a>

我用 Go 语言构建了 Signet，目的是看看一个自主系统是否能够处理目前人们手动运行的野火监测循环——检查卫星数据、获取天气信息、查看地形和燃料情况，并判断某个探测是否真的是值得追踪的火灾。 所有数据都已存在：NASA FIRMS 热点探测数据、GOES-19 影像、NWS 预报、LANDFIRE 燃料模型、USGS 海拔数据、人口普查数据、OpenStreetMap。问题在于，这些数据来自不同的来源，以不同的频率和格式到达。 该系统的大部分是确定性的管道——摄取、空间索引、去重。我使用 Gemini 在天气、地形、影像和事件追踪方面协调 23 个工具，处理那些清晰规则失效的部分：决定哪些微弱的探测值得调查，接下来应该提取什么上下文信息，以及如何将嘈杂的证据合成为结构化的评估。 它还会记录时间限定的预测，并根据后续数据对其进行评分，因此该系统正在做出可证伪的声明，而不是事后叙述。当前的预测指标在网站上可见，尽管样本量仍然很小。 它已经能够从原始的卫星探测数据中创建事件，并将其中一些与官方的 NIFC 报告进行匹配。但误报、探测延迟和事件匹配仍然可能存在问题。 我特别欢迎对以下方面的批评：哪些地方应该更多地采用确定性方法，而不是 LLM 驱动？这种自主监测真的有用吗，还是仅仅比手动操作更嘈杂？