最新

嗨，HN， 最近一直在处理大量涉及法规的文件，有一件事一直困扰着我。扁平的 RAG 管道常常无法一起检索相关的文章，即使它们通过引用、定义或条款明确地联系在一起。 在尝试了几种 RAG 设置后，我主观地认为 GraphRAG 才是处理这类数据的更好模型。微软的 GraphRAG 论文和参考实现是很好的起点。然而，在实践中，我发现一个反复出现的摩擦点：图存储和向量索引通常由不同的系统处理，这对于短期的分析任务来说，感觉过于笨重了。 为了探索这种权衡，我构建了 GibRAM（Graph in-buffer Retrieval and Associative Memory，即内存内图检索和关联记忆）。它是一个实验性的、内存中的 GraphRAG 运行时，其中实体、关系、文本单元和嵌入都并排存在于单个进程中。 GibRAM 刻意设计为短暂的。它专为探索性任务而设计，例如对有限的文档集进行摘要或对话式查询。数据驻留在内存中，按会话进行范围限定，并通过 TTL 自动清理。它不提供持久性保证，并且对于预期的用例，重新计算被认为比持久化更便宜。 这不是一个数据库，也不是一个可用于生产的系统。这是一个休闲项目，很大程度上是凭感觉编写的，旨在探索当内存是主要约束而不是存储时，GraphRAG 的样子。存在技术债务，并且许多权衡都是明确的。 该项目是开源的，我非常欢迎反馈，特别是来自从事 RAG、搜索基础设施或基于图的检索的人。 GitHub：<a href="https:&#x2F;&#x2F;github.com&#x2F;gibram-io&#x2F;gibram" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gibram-io&#x2F;gibram</a> 很乐意回答问题或听取关于这种方法可能存在缺陷的意见。

最近为什么我在这么多网站（在 Firefox 中）上看到这个？过去一个月左右的时间里，我看到了好几次，之前从未注意到过。<p>“您无法使用语音合成，因为缺少语音调度程序库”<p>有一个“了解更多”的链接，但它只是在谈论如何在我的浏览器中让语音合成功能正常工作。搜索错误字符串会返回类似的讨论。我不想这样做（特别是如果它是一些新的营销噱头）。显然是语音合成，但*它在说什么？*<p>最近的一个例子是 dell.com 的产品页面，发布在 HN 上：<p>https://www.dell.com/en-us/shop/dell-ultrasharp-52-thunderbolt-hub-monitor-u5226kw/apd/210-bthw/monitors-monitor-accessories<p>由于 HN 上有很多人访问过该链接，我想也许有人能告诉我他们听到了什么？

我是 Dan，我开发了一个 CLI，让 AI 助手可以在 Figma 中进行设计。 它的功能：提供 100 个命令，用于创建形状、文本、框架、组件，修改样式，导出资源。JSX 导入速度比任何插件 API 导入快约 100 倍。可与任何 LLM 编码助手配合使用。 我为什么开发它：官方的 Figma MCP 服务器只能读取文件。我希望 AI 能够真正地进行设计——创建按钮、构建布局、生成整个组件系统。现有的解决方案要么是只读的，要么需要冗长的 JSON 模式，这会耗尽 token。 演示（45 秒）：[https://youtu.be/9eSYVZRle7o](https://youtu.be/9eSYVZRle7o) 技术栈：Bun + Citty 用于 CLI，Elysia WebSocket 代理，Figma 插件。render 命令通过 Chrome DevTools 连接到 Figma 的内部多人协议，以便在处理大量对象时获得额外的性能。 试用：bun install -g @dannote/figma-use 正在征求关于 CLI 人体工程学、缺失命令以及 JSX 语法是否自然的反馈。

我正在寻找来自真正构建或运营过长期企业软件的人的观点。 背景（有意保持通用）： 我们有一个成熟的、正在产生收入的企业级应用程序，已经投入生产多年。 半技术领导层（没有工程背景）正在积极考虑启动一个新产品，该产品使用 LLM 驱动的工具（AI 代码生成、快速原型设计等）构建，他们认为： 现代 AI 工具可以显著降低构建成本，LLM 将在未来得到改进 新系统旨在复制一个已建立的竞争对手在约 10 年内构建的大部分内容 客户可以随着时间的推移选择迁移（旧系统仍然受支持） 纯软件产品，旨在用新产品取代当前应用程序的所有运营复杂性，目标是使其成为可转售产品。 使用 LLM 工具创建的早期代码演示是最终生产就绪性的良好代表 向管理层的推销是，这可以比过去更快、更便宜地完成，这在很大程度上是因为“AI 改变了构建软件的经济性”。 我并不反对 LLM——我每天都在使用它们，并且看到了真正的生产力提升。我的担忧更多是结构性的： LLM 似乎非常擅长加速脚手架和迭代，但尚不清楚它们能减少多少： 运营复杂性 数据正确性问题 迁移风险 长尾客户的边缘情况 支持和责任成本 演示看起来令人信服，但它们没有揭示故障模式 感觉我们正在将一个成熟竞争对手的最终状态与一个全新系统的初始构建成本进行比较 我正在努力验证我的想法。 向社区提出的问题： 您是否见过企业产品的 LLM 优先重建在实践中取得成功的案例？ “便宜又快”的说法通常在哪里破裂？ AI 是否从根本上改变了长期成本曲线，或者主要影响了早期速度？ 如果您要为非技术所有者提供建议，您会坚持让他们明确承认哪些风险？ 是否有原则性的方法来支持或反对这种策略，而不会听起来像“遗留悲观主义者”？ 我特别感兴趣的答案来自： 拥有大规模生产系统的人 尝试过全部或部分重写的创始人 在演示已经售出后加入 AI 优先的全新项目的工程师 感谢任何真实的经验、成功案例或警示故事。

我于 1 月 14 日花了 20 美元购买了 Cursor Pro。3 天后，Token 耗尽，性能变得无法使用。我于 1 月 17 日（7 天内）申请了退款。他们的 AI 机器人“Sam”多次拒绝，然后人工客服“Charlene”以“反映了 3/30 天的使用情况”为由拒绝了退款。现在他们又把我踢回给了 AI 机器人。<p>现在 SaaS 行业都这样吗？用了 3 天就不能退全款？<p>交易单号：#395540957397