一周热榜

在 Postman 和 Dbeaver 之间切换，然后又跳到任何随机的 JSON 查看器、在线 PDF 解析器，这既无聊又令人沮丧——尤其当你不得不一次又一次地测试同样的情况时。<p>所以我构建了一个一体化的 API 客户端、数据库客户端和数据检查器。<p>你可以用它来做：<p>1. 数据检查器工具<p>这一切始于一个用于运行多个 JSON 查询的简单 Web 工具。 当我使用 REST API 时，我厌倦了反复测试相同的端点，并使用 Ctrl+F 搜索同一组字段。<p>主要功能： - 支持 JSON、XML 或 base64 编码的 JSON - 按键、值搜索 - 格式化/压缩 - 多个 JSONPath 查询 - 数据预览（图像、PDF、表格）<p>2. API 客户端<p>手动将 API 响应复制到数据检查器仍然很麻烦，所以我添加了一个内置的 API 客户端，并将数据检查器直接集成到其中。<p>现在，你可以立即检查响应，而无需切换工具。<p>3. 数据库客户端<p>将数据（通常是 otpCode 或某种你无法从 REST API 获取的密钥）从数据库工具复制到 API 客户端很无聊。 当你需要从 API 响应中复制一个对象 ID 并在数据库中查询它时，也是如此。<p>所以我添加了一个简单的数据库客户端。 没什么特别的——只是一个模式浏览器和 SQL 查询支持。<p>4. 共享变量<p>应用程序的所有部分——API 客户端、数据库客户端和数据检查器——都可以提取和重用共享变量，就像 Postman 一样。<p>---<p>所以，是的，最初只是一个小小的 JSON 工具，慢慢发展成了一个完整的开发工具。 目标很简单——让日常开发任务不那么烦人。<p>关于下载的小提示：该应用程序仍处于早期阶段，用户还不多，因此你可能会在下载过程中看到安全警告。 Windows 版本使用我的个人个人证书签名，因此你将看到“Lac Tran An”作为发布者。<p>它提供 14 天免费试用（无需信用卡），并且有一个早鸟价 40 美元的终身许可证。<p>我非常感谢任何反馈——尤其是哪些功能有用或令人讨厌。 希望它能帮助你完成日常工作流程。<p>感谢你的阅读。

我正在构建一个小型文本转语音模型，专门针对ASMR和放松内容进行调优。 大多数TTS模型都旨在清晰度和活力。为了获得那种特定的“酥麻”效果，我使用ASMR录音数据集对该模型进行了微调，以捕捉标准模型通常会过滤掉的呼吸感、耳语和柔和的动态。 目前，控制仅限于文本（还没有速度或音调滑块），但出现了一种有趣的涌现行为： 由于训练数据，该模型有时会“幻觉”或生成环境背景声音——比如噼啪作响的火焰、海浪或柔和的静电——以及声音，这取决于您输入的文本的上下文。它不是一个背景音轨混合器；该模型实际上是在生成这些声音作为音频输出的一部分。 我搭建了一个简单的网络演示来测试它。我很想听听您对声音质感的看法，以及您是否遇到任何有趣的环境生成。 在这里查看：<a href="https://www.aiasmrvoice.com/en" rel="nofollow">https://www.aiasmrvoice.com/en</a>

Hi HN， 我制作了“电现神社”，一个基于网络的传统日本神道仪式的体验。 主要特点： 隐私设计：您的“言灵”（信息/祈愿）不会存储在任何数据库中。它们只存在于动画中，并在完成后消失。 无需登录：您可以立即体验仪式，无需账户。 数字供奉：对于希望支持该项目的人，我通过 Stripe 集成了“数字供奉”（Osaisen）。这完全是可选的——您可以免费体验核心仪式，无需任何支付。这并非捐款，而是一种付费的数字体验，为支持者解锁独特的“完成信息”。 我为什么制作这个：我想探索像神道这样的古老传统如何以数字、短暂的方式被重新诠释。在神道中，言语具有灵魂（言灵），我觉得网络的“短暂”特性非常适合这一点。 我很想听听您对 UI/UX 和“短暂数字仪式”概念的看法。

buquet (桶队列) 是一款仅使用兼容 S3* 的对象存储的队列和工作流编排工具。S3 作为控制平面，使其比其他方案更简单。当然，这也有一些权衡（参见文档），但我相信它能很好地服务于一个特定的领域。 <p><a href="https:&#x2F;&#x2F;horv.co&#x2F;buquet.html" rel="nofollow">https:&#x2F;&#x2F;horv.co&#x2F;buquet.html</a> <a href="https:&#x2F;&#x2F;github.com&#x2F;h0rv&#x2F;buquet" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;h0rv&#x2F;buquet</a><p>* 参见 <a href="https:&#x2F;&#x2F;github.com&#x2F;h0rv&#x2F;buquet&#x2F;blob&#x2F;main&#x2F;docs&#x2F;guides&#x2F;s3-compatibility.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;h0rv&#x2F;buquet&#x2F;blob&#x2F;main&#x2F;docs&#x2F;guides&#x2F;s3-comp...</a>

我一直在探索如何有效地向大型语言模型（LLM）描述 UI 布局。<p>问题：当你要求 AI 生成或修改 UI 时，如何描述当前状态？ - 自然语言（“顶部是标题，下面是表单”）具有歧义性 - ASCII 艺术在编辑时会出错（对齐问题） - HTML 精确但冗长<p>我进行了一些测量。对于一个简单的登录表单： - 自然语言：102 个 token - ASCII 艺术：84 个 token - HTML：330 个 token<p>我尝试了一种基于网格的文本格式，使用类似 Excel 的单元格引用：<p><pre><code> grid: 4x3 A1..D1: { type: txt, value: &quot;Login&quot; } A2..D2: { type: input, label: &quot;Email&quot; } D3: { type: btn, value: &quot;Submit&quot; } </code></pre> 这用了 120 个 token – 比 HTML 少，比自然语言更精确。<p>构建了一个 CLI 用于将其渲染成 SVG/PNG：npx ktr input.kui -o output.png<p>很好奇其他人对这个问题尝试了什么方法。我是否遗漏了已经很好地解决了这个问题的方法？<p>代码：<a href="https:&#x2F;&#x2F;github.com&#x2F;enlinks-llc&#x2F;katsuragi" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;enlinks-llc&#x2F;katsuragi</a>