最新

大家好，我是Sokuji的开发者，我开发了一款开源的实时语音翻译应用，它既是一个Electron桌面应用，也是一个Chrome/Edge浏览器扩展程序。 最新版本（v0.15）增加了本地推理模式——完全在设备上进行ASR（自动语音识别）、翻译和TTS（文本转语音），使用WASM和WebGPU。无需API密钥，无需联网，数据也不会离开你的设备。它包含： * 48个ASR模型，涵盖99种以上语言（sherpa-onnx WASM + Whisper WebGPU） * 55+翻译语言对（Opus-MT）以及多语言LLM（Qwen 2.5/3/3.5），通过WebGPU实现 * 136个TTS模型，涵盖53种语言（Piper、Coqui、Mimic3、Matcha） 对于那些喜欢云服务提供商的用户，它也支持OpenAI实时API、Google Gemini Live、Palabra.ai、火山引擎ST、豆包AST 2.0以及任何兼容OpenAI的端点。 浏览器扩展程序与Google Meet、Teams、Zoom、Discord、Slack等集成——它可以捕获参与者的音频，并通过虚拟麦克风注入翻译后的语音。 技术栈：React + Zustand + Vite，Electron Forge，sherpa-onnx编译为WASM，HuggingFace Transformers.js用于WebGPU推理。模型按需下载并缓存在IndexedDB中。 我开发这个应用是因为现有的翻译工具要么需要昂贵的API密钥，要么将你的音频发送到云端，或者不支持足够的语言。本地推理模式使其适用于对隐私敏感的用例以及没有可靠互联网连接的人。 AGPL-3.0许可。可在Windows、macOS、Linux、Chrome Web Store和Edge插件商店中使用。 GitHub：[https://github.com/kizuna-ai-lab/sokuji](https://github.com/kizuna-ai-lab/sokuji) 官方网站：[https://sokuji.kizuna.ai](https://sokuji.kizuna.ai)

看起来 GitHub Actions 又出故障了：https://www.githubstatus.com 我们已经在使用 blacksmith 来避免使用 GitHub Runners。强烈推荐你试试，如果你还没用过的话。但我们仍然依赖 GitHub 来实际触发工作流程。考虑到他们频繁的故障，我想知道是否有可用的替代方案？迁移到 GitLab 是一项相当大的工程，所以我想知道是否有办法暂时缓解这个问题，并且不再依赖 GitHub Actions 来定期触发工作流程和执行操作（例如，合并到 main 分支时）？

我开发 Entropy 是为了解决一个特定问题：传统的 API 扫描器经常会遗漏业务逻辑漏洞，因为它们依赖于静态的攻击列表。Entropy 使用 LLM（大型语言模型）来分析你的 API 模式（OpenAPI/GraphQL），并像攻击者一样思考，从而生成定制的攻击序列。 注意：我目前正在修复一个小型的打包问题，因此“pip install”在接下来的几个小时内可能暂时无法使用。与此同时，你可以通过克隆代码库直接从源代码运行它。我很乐意听取你的想法和反馈！

大家好，HN， 我觉得把 traceroute 的路径在地图上可视化呈现会很有意思。我知道这个想法已经有人做过了，但我还是想自己动手试试。 最初的版本只能让你粘贴 traceroute 的结果，然后在地图上绘制出经过的节点。后来我发现了 Globalping (<a href="https://globalping.io" rel="nofollow">https://globalping.io</a>)，它允许你从世界各地的探测器上运行 traceroute 和 MTR，所以我把这个功能集成到了我的工具里。 在使用过程中，我注意到了一些有趣的事情： * 很容易发现错误的 IP 地理位置。如果一个节点的延迟显示为 1-2 毫秒，但却跨越了洲际，那么它的地理位置很可能是不准确的。 * 视觉上更容易注意到次优路由，而不仅仅是看延迟数字。 * 即使有了 IPinfo 这样优秀的数据库，IP 地理位置仍然不是完美的，所以路径的某些部分偶尔可能会产生误导。 特别感谢 Globalping 和 IPinfo 团队——Globalping 提供了测量基础设施，IPinfo 提供了地理位置数据。 欢迎提出反馈。

AI 编码代理生成的代码还不错。问题在于代码之外的一切——检查进度、捕捉偏差、判断它是否真的完成了。我花了几个月的时间尝试让自主代理工作。瓶颈永远是我自己。 尝试 1 - 直接使用 Claude/GPT：适用于小项目，但你需要无休止地重新解释上下文。 尝试 2 - Copilot/Cursor：出色的自动补全，但仍然需要我完成 95% 的思考。 尝试 3 - 持续代理：无需提示即可持续工作，但“无错误”并不意味着“功能正常”。 尝试 4 - 并行代理：更快的墙钟时间，但现在你需要手动审查更多的输出。 常见的失败：没有人验证输出是否满足目标。而那个人永远是我。所以我自动化了这项工作。 OmoiOS 是一个规范驱动的编排系统。你描述一个功能，它会： 1. 运行一个多阶段的规范流水线（探索 > 需求 > 设计 > 任务），并使用 LLM 评估器对每个阶段进行评分。失败时重试，通过时推进。当代理开始编码时，需求已经具备机器可检查的验收标准。 2. 为每个任务生成隔离的云沙盒。你的本地环境不受影响。代理获得具有完全 git 访问权限的临时容器。 3. 持续验证——一个单独的验证器代理根据验收标准检查每个任务。失败会反馈以进行重试。步骤之间没有人工干预。 4. 发现新的工作——验证可以在代理发现缺失的边缘情况时生成新的任务。任务图随着代理的学习而增长。 难点（实话实说）： - 规范质量是瓶颈。模糊的规范 = 代理空转。 - 验证是特定于领域的。 API 的正确性很容易。 UI 质量则不然。 - 发现分支可能会意外地扩大任务图。 - 沙盒开销增加了每个任务的延迟。值得，但需要权衡。 - 合并具有真实冲突的并行分支是最难的问题。 - 守护进程监控（每个代理的轨迹分析）仍然存在一些问题。 技术栈：Python/FastAPI，PostgreSQL+pgvector，Redis（约 19 万行）。Next.js 15 + React Flow（约 8.3 万行 TS）。Claude Agent SDK + Daytona Cloud。自 2025 年 11 月以来有 686 次提交，由我个人构建。Apache 2.0 协议。 我一直在回到同一个问题：结构化的规范生成，它能产生真正可机器检查的验收标准。有没有人找到一种适用于非平凡功能的方法，还是这从根本上就很难？ GitHub: [https://github.com/kivo360/OmoiOS](https://github.com/kivo360/OmoiOS) 在线演示: [https://omoios.dev](https://omoios.dev)

过去几年我一直在构建 AgnosticUI。它最初是一个 CSS 优先的单体仓库，其逻辑在各个框架包之间手动复制。后来，它变成了一场维护噩梦。 最近，我用 Lit 进行了彻底的重写，以符合 Web 标准并统一核心。一个主要的架构转变是转向“源码优先”模式。UI 源码不再位于 node_modules 中的黑盒里，而是位于你的本地项目工作区中。 这使得组件对 LLM 完全可见，从而避免了 AI 试图猜测隐藏库 API 时常见的幻觉。我写了一篇关于 Frontend Masters 的技术性事后分析文章，详细介绍了这次迁移的障碍（Shadow DOM 可访问性、表单参与以及 @lit/react 与 React 19 的对比）：<a href="https://frontendmasters.com/blog/post-mortem-rewriting-agnosticui-with-lit-web-components/" rel="nofollow">https://frontendmasters.com/blog/post-mortem-rewriting-agnos...</a>

为人类和 AI 智能体设计的智能代码阅读工具。Tilth 将 ripgrep、tree-sitter 和 cat 的能力融于一体，协同工作。 -- v0.4.4：为调用者搜索添加了自适应的二阶影响分析——当一个函数有 ≤10 个独特的调用者时，tilth 会在一次扫描中自动追踪调用者的调用者。首次完整 26 任务 Opus 基线（之前仅有 5 个困难任务）。Haiku 采用率从 42% 提升至 78%，使 Haiku 从成本回归转变为 -38% $&#x2F;正确。 v0.4.5：将 TOKEN_THRESHOLD 从 3500 提升至 6000 预估 tokens（约 24KB），因此中等大小的文件会返回完整内容，而不是智能体随后通过 5-7 次连续的 --section 调用读取的提纲。修复了两个主要的回归问题：gin_radix_tree（+35% → 接近持平）和 rg_search_dispatch（+90% → -26% 胜出）。Sonnet 达到了 100% 的准确率（52&#x2F;52）和 -34% $&#x2F;正确的整体表现。 -- <a href="https:&#x2F;&#x2F;github.com&#x2F;jahala&#x2F;tilth&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jahala&#x2F;tilth&#x2F;</a> 完整结果：<a href="https:&#x2F;&#x2F;github.com&#x2F;jahala&#x2F;tilth&#x2F;blob&#x2F;main&#x2F;benchmark&#x2F;README.m" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jahala&#x2F;tilth&#x2F;blob&#x2F;main&#x2F;benchmark&#x2F;README.m</a>... -- 附言：我没有足够的预算进行大量的基准测试（尤其是使用 Opus），所以如果有任何拥有大量 token 的人有能力运行一些基准测试，请随时提交 PR 结果。