最新

嗨，HN—— Tambo 是一个 React SDK（600 星），可以让你的应用根据自然语言输入渲染和控制 UI 组件。 我们非常喜欢 Cursor，希望我们所有的应用（Stripe、Vercel、GitHub）都能拥有相同的体验。我应该能够输入 `update env key` 并获得一个添加它的 UI。 Tambo 允许 AI 助手渲染或更新注册的 React 组件的状态。 它可以通过 MCP（模型上下文协议）或客户端获取（类似于 OpenAI 的工具调用）来获取上下文。 该 SDK 处理流消息和属性更新，维护线程历史，并在对话中传递上下文。它是 BYOM（自带模型），可以与 Next.js、Remix、Vite 和 React Native 一起使用。 如果你正在构建一个“Cursor for X”（电子表格、视频、设计等），可以看看这个。 昨天，我们实现了 100% 开源。 文档： [https://docs.tambo.co](https://docs.tambo.co) GitHub： [https://tambo.co/gh](https://tambo.co/gh) —— Michael x2, Alec, Akhilesh

嘿，HN， 多年来，我创建了不少 OpenAPI 规范，但随着时间的推移，这些规范常常被忽视，最终接口与规范之间会出现偏差。 我想开发一个超级轻量级的工具，可以在开发过程中随时使用，以便检查我的接口是否仍然符合预期的规范。 SpecGate 是一个轻量级的代理，它会将 API 响应与给定的 OpenAPI 规范进行对比。它会告诉你是否存在未记录的接口，或者响应是否与规范不符。我在使用它时，及时发现了我最近一个规范中的大约 10 个问题。 当然，这个工具也可以在生产环境中运行，但目前它只会将日志输出到 stdout/stderr，所以如果你决定在生产环境中使用，请记住这一点。 我很想听听你们对这个工具的反馈。

想知道被使用的感觉是什么样的吗？一种体验方式是发现你的终端悄悄开始将命令输出发送给大型语言模型（LLMs）。 今天，在尝试运行一个测试后，我收到了一个关于如何修复语法错误的LLM建议。 于是，我去了Warp的Discord询问发生了什么，果然，他们的“友好支持机器人”也发现了这一点。 > Warp引入了像提示建议和下一个命令这样的功能，利用LLMs提供上下文建议。这些功能是Warp的主动AI系统的一部分，能够根据你的终端会话主动推荐修复方案和后续操作，包括错误、输入和输出。 这里的“主动”也意味着在没有明确用户同意的情况下。 我确实喜欢Warp，但这种信任的破裂实在太大了，我现在就决定卸载它。 这件事充分说明了伦理和重要性的问题。 参考链接：https://docs.warp.dev/agents/active-ai

厌倦了那些在会话之间忘记一切的AI编码工具吗？每次我打开与Claude的新聊天或启动Copilot时，我都得重新解释我的代码库结构。 所以我构建了一个解决方案，叫做In Memoria。它是一个MCP服务器，为AI工具提供持久的记忆。AI不再需要在每次对话中从头开始，而是能够记住你的编码模式、架构决策以及你所积累的所有上下文。 设置非常简单：只需运行 `npx in-memoria server`，然后连接你的AI工具。无需注册账户，数据不会离开你的机器。 在技术实现上，它是基于TypeScript和Rust，使用tree-sitter进行解析，并利用向量存储进行语义搜索。目前支持JavaScript/TypeScript、Python和Rust。 最初它是作为一个文档工具开始的，但我意识到——AI并不需要更好的文档，它需要记住信息。过去几个月我一直在从零开始重建这个记忆层。 对我来说，它的效果相当不错，但我很好奇其他人的看法，尤其是关于模式学习的部分。你希望下一个支持哪些语言？ 代码链接： [https://github.com/pi22by7/In-Memoria](https://github.com/pi22by7/In-Memoria)

我一直在研究一种压缩算法，以便在大型集合中快速随机访问单个字符串。<p>这个问题出现在处理大型内存数据库列（如电子邮件、URL、产品标题等）时，这些场景对低延迟的点查询至关重要。对于短字符串，基于LZ77的压缩算法表现不佳。块压缩有所帮助，但块大小在压缩比和访问速度之间造成了权衡。<p>一些现有的选项：<p>- BPE：压缩比不错，但速度慢且占用内存较多。<p>- FSST（在这里讨论：<a href="https://news.ycombinator.com/item?id=41489047">https://news.ycombinator.com/item?id=41489047</a>）：速度非常快，但压缩效果较弱。<p>这个解决方案提供了一个有趣的平衡（详细信息见论文）：<p>- 压缩比：与BPE相似。<p>- 压缩速度：100–200 MiB/s。<p>- 解压速度：6–7 GiB/s。<p>我很想听听你的想法——无论是你认为这可以帮助的工作负载、API改进的想法，还是一般讨论。欢迎在HN上或通过电子邮件与我交流。<p>---<p>资源：<p>- 论文：<a href="https://arxiv.org/pdf/2508.02280" rel="nofollow">https://arxiv.org/pdf/2508.02280</a><p>- Rust：<a href="https://github.com/gargiulofrancesco/onpair_rs" rel="nofollow">https://github.com/gargiulofrancesco/onpair_rs</a><p>- C++：<a href="https://github.com/gargiulofrancesco/onpair_cpp" rel="nofollow">https://github.com/gargiulofrancesco/onpair_cpp</a>

你好，最近我一直在开发这个项目，现在我很高兴它终于可以与大家见面了。我热爱Tor，但我认为Tor最大的一个问题在于节点都是陌生人，这本身就需要一定的信任基础。 基于这个原因，我决定构建一个受洋葱路由器启发的私有网络。与其他公共网络不同，GiralNet并不是为了与陌生人进行匿名连接。它是为那些希望保持隐私但又需要一定信任的小团队或小组而设计的。它假设网络中运行节点的人是已知且可验证的。这为一个小组创建自己的私密安全网络提供了一种方式，在这个网络中，基础设施是可控的，节点背后的人也是可以追责的。我们的目标是在不依赖于大型匿名公共网络的情况下提供隐私保护。 在技术细节方面，它是一个SOCKS5代理，通过一系列其他计算机来路由互联网流量。它通过将您的数据包裹在多层加密中来实现这一点，就像洋葱路由器一样。路径中的每台计算机解开一层以找到下一个目的地，但永远不知道完整的路径。这使得任何单一方都难以同时看到流量的来源和去向。 如果您有任何问题，我会很乐意回答，谢谢。