最新

英特尔®侧带技术 英特尔服务器可管理性接口概述 英特尔®局域网接入部门 法律声明 本文件中的信息与英特尔产品相关提供... BunnyPeople、Celeron、Celeron Inside、Centrino、Centrino 标志、Chips... 英特尔、英特尔标志、Intel386... Xeon Inside 和 Xircom 是英特尔的商标或注册商标。 https://cdrdv2-public.intel.com/321786/sideband-technology-appl-note.pdf

几周以来，我一直收到冒充Gmail的垃圾邮件。这些邮件总是包含指向 https://storage.googleapis.com/rightsmoves/... 的链接。邮件的样子是这样的：<p>https://imgur.com/xyXfPI8<p>甚至连谷歌自己的Gemini也知道这是个骗局：<p>&gt; URL https://storage.googleapis.com/rightsmoves/ 指向一个名为“rightsmoves”的特定Google Cloud Storage存储桶。根据最近的安全数据和网页扫描，这个存储桶与恶意活动有关，特别是网络钓鱼和“流量窃取”计划。<p>我已经通过Google Cloud Platform的滥用报告表单多次举报，但他们对此置之不理。<p>这是谷歌的完全无能吗？为什么他们会允许自己域名下的骗局存在？

嗨，HN， 最近我一直在处理大量的法规文件，有一件事让我感到困扰。常规的RAG（检索增强生成）管道往往无法将相关的文章一起检索出来，即使它们通过引用、定义或条款明显相关。 在尝试了几种RAG设置后，我主观上觉得GraphRAG是处理这类数据的更好思维模型。微软的GraphRAG论文和参考实现为我提供了很好的起点。然而，在实际操作中，我发现一个反复出现的问题：图形存储和向量索引通常由不同的系统处理，这对于短期分析任务来说显得过于繁重。 为了探索这种权衡，我构建了GibRAM（图形内存检索与关联记忆）。这是一个实验性的内存中GraphRAG运行时，其中实体、关系、文本单元和嵌入在一个进程中并存。 GibRAM是故意设计为短暂的。它旨在用于探索性任务，如在有限文档集上进行摘要或对话查询。数据存储在内存中，按会话范围划定，并通过TTL自动清理。没有持久性保证，重新计算被认为比持久化更便宜，适用于预期的使用场景。 这不是一个数据库，也不是一个生产就绪的系统。它是一个随意的项目，主要是基于感觉编码，旨在探索当内存是主要限制而不是存储时GraphRAG的样子。技术债务是存在的，许多权衡是显而易见的。 该项目是开源的，我非常欢迎反馈，特别是来自从事RAG、搜索基础设施或基于图形的检索的人的意见。 GitHub: [https://github.com/gibram-io/gibram](https://github.com/gibram-io/gibram) 很高兴回答问题或听取关于这种方法可能存在缺陷的意见。

最近我在很多网站上（在Firefox中）看到这个提示，为什么会这样？在过去一个月里，我已经看到过六七次了，以前从未注意到过。 “您无法使用语音合成，因为缺少语音调度程序库。” 有一个“了解更多”的链接，但它只是讲述如何在我的浏览器中启用语音合成。搜索这个错误信息也返回了类似的讨论。我不想这样做（尤其是如果这只是某种新的营销潮流）。显然这是语音合成，但*它在说什么？* 最近一次是在这里的dell.com产品页面上发布的： https://www.dell.com/en-us/shop/dell-ultrasharp-52-thunderbolt-hub-monitor-u5226kw/apd/210-bthw/monitors-monitor-accessories 由于很多HN的用户可能访问过这个链接，我想知道有没有人能告诉我他们听到了什么？

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

我希望听取那些真正构建或运营过长期企业软件的人的观点。 背景（故意保持通用）： 我们有一款成熟的、能够产生收入的企业应用程序，已经在生产环境中运行多年。 半技术领导层（没有工程背景）正在积极考虑启动一款新产品，该产品将使用基于大型语言模型（LLM）的工具（如AI代码生成、快速原型制作等）构建，认为： - 现代AI工具显著降低了构建成本，LLM在未来将会有所改善。 - 新系统试图复制一家成熟竞争对手在大约10年内构建的大部分功能。 - 客户可以选择逐步迁移（旧系统仍然得到支持）。 - 这是一款软件产品，旨在用以替代当前应用程序的所有操作复杂性，目标是使其成为可再销售的产品。 - 使用LLM工具创建的早期演示版本是最终生产就绪的良好代理。 向所有者的推介是，这一过程可以比历史上所需的时间和成本快得多，主要因为“AI改变了软件构建的经济学”。 我并不是反对LLM——我每天都在使用它们，并且看到了实际的生产力提升。我的担忧更偏向结构性： - LLM在加速搭建和迭代方面似乎表现出色，但不清楚它们在多大程度上减少了： - 操作复杂性 - 数据正确性问题 - 迁移风险 - 长尾客户的边缘案例 - 支持和责任成本 - 演示看起来令人信服，但并没有揭示失败模式。 - 感觉我们是在将一家成熟竞争对手的最终状态与一个全新系统的初始构建成本进行比较。 我试图对自己的思考进行理性检查。 向社区提出的问题： - 你们见过基于LLM的企业产品重建在实践中成功吗？ - “便宜和快速”的叙述通常在哪里崩溃？ - AI是否实质性地改变了长期成本曲线，还是主要影响了早期的速度？ - 如果你在为非技术背景的所有者提供建议，你会坚持让他们明确承认哪些风险？ - 有没有一种原则性的方式来支持或反对这一策略，而不显得像“传统悲观主义者”？ 我特别希望听到以下人士的回答： - 拥有大规模生产系统的人 - 尝试进行全部或部分重写的创始人 - 在演示已经售出后加入AI优先的全新项目的工程师 感谢分享任何真实的经验、成功故事或警示案例。