一周热榜

Hi HN， 我们开源了 Voiden。 大多数 API 工具都像平台一样构建。它们很笨重，因为它们针对账户、同步和抽象进行了优化，而不是简单的本地 API 工作。 Voiden 将 API 工具视为文件。 它是一个离线优先、Git 原生的 API 工具，基于 Markdown 构建，规范、测试和文档作为可执行 Markdown 存在于你的仓库中。Git 是事实的唯一来源。 没有云。没有同步。没有账户。没有遥测。只有 Markdown、Git、热键和你的规范。 Voiden 可以通过插件（包括 gRPC 和 WSS）进行扩展。 仓库：<a href="https:&#x2F;&#x2F;github.com&#x2F;VoidenHQ&#x2F;voiden" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;VoidenHQ&#x2F;voiden</a> 在此处下载 Voiden：<a href="https:&#x2F;&#x2F;voiden.md&#x2F;download" rel="nofollow">https:&#x2F;&#x2F;voiden.md&#x2F;download</a> 我们希望收到厌倦了过于复杂和臃肿的 API 工具的用户的反馈！

核心理念是：最小任务模型 + 可编程行为——一个小的核心实现无限的功能，因为每个任务都可以携带可执行脚本。 近期更新： * 虚拟机现在使用 NaN-boxing 技术。 * 所有栈值都是 64 位 (u64)，但编码了 5 种不同的类型：布尔值、字符串、CallData、U32 和 MemSlice（25 位偏移量 + 25 位大小）。 * 添加了 InlineVec——一种由固定大小数组支持的类似向量的结构。虚拟机栈、控制栈、调用栈和跳转栈现在都使用它，并有明确的限制。 * 虚拟机现在有内存（堆）。内存是简单的 Vec&lt;u64&gt;，动态增长，但从技术上讲，长度受 mem\_slice\_val 格式的限制：25 位有效载荷用于偏移量和大小。 该项目仍处于绝对的早期阶段。 代码仓库在这里：https://github.com/tracyspacy/spacydo

Hi HN， 我正在开发用于软件开发的 AI 智能体。这些智能体可以自动启动短生命周期的应用实例——例如，针对每个拉取请求、每个任务或每个实验——每个实例都有自己的临时 URL。 身份验证的处理方式如下： * OAuth2 / OIDC * 外部身份提供商 * 重定向 URL 必须预先注册且是静态的 这与短生命周期应用产生了严重冲突： * URL 是动态且不可预测的 * 重定向 URL 无法实际预先注册 * 身份验证成为唯一一个在其他方面完全自动化的工作流程中非短暂的部分 我看到团队通常采用以下做法： * 在预览环境中禁用真正的身份验证 * 将所有回调路由到单个稳定的环境 * 使用通配符重定向或代理设置，感觉像是黑客行为 对于 AI 开发智能体来说，这尤其尴尬，因为它们假设基础设施是可抛弃的且完全自动化的——不需要手动配置 IdP。 所以，我很感兴趣： 1. 如果你使用短生命周期的预览应用，你如何处理真正的身份验证？ 2. 是否有适用于动态 URL 的干净的 OAuth/OIDC 模式？ 3. 静态重定向 URL 的假设在这里仍然是正确的模型吗？ 4. 在生产环境中，什么才是真正有效的？ 我正在寻找实际的设置和失败案例，而不是理论。

嗨，HN， 我构建了 Claude Commander，它是一个围绕 Cloud Code 的小型封装器，允许你从 Cloud Code 内部（通过钩子或脚本）以编程方式发出指令。<p>主要功能：在运行时切换模型。<p>原因：对于规划或困难的调试，开始时使用昂贵的模型，然后在执行时降级以降低成本。

嗨 HN 我正在构建 ÆTHRA — 一种专门为创作音乐和情感音景而设计的编程语言。 ÆTHRA 并非专注于通用编程，而是一种纯粹的 DSL（领域特定语言），其代码直接代表音乐意图：节奏、情绪、和弦、进行、力度和乐器。 目标是让音乐创作感觉更像是在撰写故事或表达情感，而不是操控底层的音频 API。 关键理念： - 基于文本的音乐创作 - 和弦和进行作为一级概念 - 时间、节奏和结构由语言处理 - 专为氛围、电影、情感和极简音乐而设计 - 解释器用 C# (.NET) 编写 ÆTHRA 代码示例（简化）： tempo 60 instrument guitar chord Am for 4 chord F for 4 chord C for 4 chord G for 4 这会生成一个缓慢、忧郁的进行，适合用于氛围或电影场景。 ÆTHRA 目前： - 生成 WAV 音频 - 支持音符、和弦、节奏、持续时间、力度 - 使用简单的解释器（无需外部 DAW 或 MIDI 工具） - 刻意保持极简和可读性 它**不是**： - 不是 DAW 的替代品 - 不是以 MIDI 为中心 我为什么创建它： 我想要一种以音乐为主要输出的语言——而不是事后才考虑的。一种介于代码、情感和声音设计之间的东西。 该项目是开源的，处于早期阶段（v0.8）。我主要在寻找： - 关于语言设计的反馈 - 值得添加的音乐功能的想法 - 对 PL 设计、音频或生成艺术感兴趣的人的想法 代码库：&lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;TanmayCzax&#x2F;AETHRA" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;TanmayCzax&#x2F;AETHRA</a>&gt; 感谢阅读——很乐意回答问题或讨论想法。

我在此快速提醒一下，针对任何正在研究小型加密货币交易平台的人。 如果你遇到CZR交易所，请务必谨慎。加密货币领域常见的失败模式不是“价格风险”，而是“权限风险”：一旦你将钱包连接到未知的去中心化应用（dApp）或将资产发送到未经验证的地址，你可能无法找回任何东西。 这里（以及任何地方）都适用的通用安全措施： 不要将你的钱包连接到你无法独立验证的网站。 不要仅仅因为某个页面或支持账户告诉你，就向平台发送USDT/BTC。 将“即时提款”、“限时验证”或“紧急存款以解锁资金”视为主要危险信号。 在测试任何新服务时，使用一个全新的钱包/少量资金，并撤销你不认可的授权。 如果有人有可验证的证据（交易哈希、存档页面、签名消息、带有时间戳的清晰截图），请分享。如果没有，请保持事实陈述，避免猜测。