一周热榜

我最近读了几篇关于人工智能公司盈利机会的文章，发现作为创始人或运营者，大致有六种赚钱方式。我不确定风险投资界的共识是否完全滞后于实际发展，所以提出这个问题。 以下是我最近看到的一些想法： 1. **AI整合收购（AI Roll-ups）**：这是一个非常热门，有时甚至被过度炒作的话题。它涉及收购那些尚未深度整合AI但急需人工服务的公司。例如，小城镇的会计师事务所、IT托管服务（有时是外包的）、法律服务（不一定是顶级律所，而是为现有客户提供服务的本地律所）以及保险业。这个模式之所以病毒式传播，是因为有人可能认为收购和优化公司比销售软件更好。如今的软件可能需要重新定位来建立护城河，而许多可以自动化的任务都围绕着服务业，尤其是在价值链的低端。风险投资公司也在寻找新的资产，因为传统的SaaS模式已不再能带来高投资回报率。 表面上看，这似乎说得通。但随后我想到，如果真是这样，我们还需要风险投资吗？风险投资公司的存在似乎有点滞后于当前的发展，其商业模式可能也无法很好地运作。风险投资的黄金时期是在移动和云计算时代。 2. **AI自动驾驶/AI原生服务公司（AI Autopilot / AI-Native Service Companies）**：这涉及开发AI自动驾驶系统，其中服务被视为软件，或者建立AI原生服务公司。公司正在探索保险经纪、会计或税务审计等领域，构建基于“行动系统”（system of action）的公司。这意味着集成SAP、Salesforce或ServiceNow等产品，让用户无需在20个不同的页面之间切换来管理采购、入职、期末结账、工单升级等。 3. **公司大脑（Company Brains）**：这条路径涉及将Slack、电子邮件、工单、会议和数据库整合到一个代理中，使其成为公司的“大脑”。这可能是组织重塑的一种方式，因为代理将能更好地理解公司。 4. **可验证工作（Verifiable Work）**：大家都知道开发可验证工作的公司，而编码是第一个用例。但自2024年我首次尝试使用Cursor以来，我没有看到比编码更具病毒式传播性的用例。这让我觉得公司和投资者正在试图找到下一个编码用例，但我们尚未找到。我们在合同红线修改、支持问题解决、质量保证或IT事件摘要等领域看到了尝试，公司也正在这些方面进行开发。 我的问题是，我们能否说自2022年以来投入AI的数万亿美元，都是为了提高效率和降低成本这个更大的目标？我知道公司有很多问题需要解决，但如果这是最大的用例，那么风险投资规模的回报在哪里？从我的角度来看，其中许多事情可以由私募股权公司来完成。一家成长型股权或私募股权公司可以利用杠杆收购，投资于这些用例。一家私募股权公司可以利用其投资组合公司收购大量旨在简化工作流程的AI业务。与目前被炒作的估值相比，回报可能会慢得多，也许3倍或4倍就已经是非常好的消息了。 我是否遗漏了什么重要的事情？这就是我在这里提问的原因。 顺便说一下，我不是专业人士，也不住在湾区，我目前在上海，所以可能有些信息我没有掌握。谢谢。

我们（Nebula Security）刚刚披露了一个 Nginx 远程代码执行 0-day 漏洞。该漏洞影响了数十家财富 500 强公司，我们已立即通知 Nginx 团队。这是自 2014 年以来第三个被评为“重大”的 Nginx 漏洞。（[https://x.com/nebusecurity/status/2067623683427045541](https://x.com/nebusecurity/status/2067623683427045541)） 要检查您的服务器是否受到影响： 1. 您正在运行 NGINX Open Source v1.31.0 或 v1.31.1 2. 您的 NGINX 配置启用了 HTTP/3 / QUIC 立即采取行动： 1. 将 NGINX 升级到 v1.31.2 或更高版本 2. 如果您无法立即升级，请在修补之前禁用 QUIC / HTTP/3 （不请自来地宣传一下：这是我们在一个月内发现的第二个 Nginx RCE 0-day 漏洞，利用了我们的安全代理 VEGA。（请参阅我们发现的第一个 Nginx RCE：[https://x.com/nebusecurity/status/2057071579876753643](https://x.com/nebusecurity/status/2057071579876753643)）。我们将在 HN 上发布详细信息，但想尽快将此 RCE 的消息传达出去。） 同时，如果您有兴趣在您的代码库上试用 VEGA，请联系 etenz@nebusec.ai。

我开始意识到，在工作中很难找到能说出有用话或说话简洁的人。（我也有责任）。我部分归咎于裁员，因为人们觉得需要不断表现出非常高效的样子。 有什么最好的方法可以提高我的演讲能力，使我既简洁又能言之有物？我想在说话时保持人们的注意力。我希望成为一个言简意赅的人，同时在保持安静的同时，也能显得很投入。

我们正在构建一个虚拟机，帮助您模拟真实的生产环境、延迟、不同的交错方式、用户请求，并找出其中的 bug。 每一个非确定性属性都被转化为您可以或代码代理可以控制的旋钮。我们已经帮助团队完美地重现了支持事件，并在一些世界上经过最严格测试的软件（包括一个数据库）中发现了 bug。 如果您想试用，我将为前 100 名注册用户提供 100 美元的免费额度。

神经元元胞自动机（Neural CAs）模拟自组织模式形成。 现在，通过将每个元胞自动机单元转变为神经场（Neural Field），它们能够实时生成高清分辨率的图案。 请尝试以下 3 个演示：从种子图案开始生长（并对其进行破坏，它会自我修复），合成可再生的 PBR 纹理，或创建如云朵般的 3D 纹理。

在提价约 30% 几个月后，Hetzner 再次提高了裸金属服务器的价格，这次涨幅高达 3-4 倍： AX102：124 欧元 -> 454 欧元 AX162 (256GB)：244 欧元 -> 844 欧元

我越是使用 Claude Code 来生成大块的系统，就越觉得我们缺少很多实践和工具。 第一个让我非常恼火的问题是缺乏对提示（prompts）的跟踪。有很多小的输入信息会影响系统应该做什么，而这些信息似乎非常短暂。从那以后，我开始在代码库中跟踪这些提示。 另一个观察是，如果你想获得良好的代理（agentic）输出，你需要在上下文窗口（context window）中提供大量的信号。看来，对进入上下文窗口的内容保持严谨是关键。使用 AI 生成输入文件可能会很危险，因为它会给人类信号增加熵/噪声。 我开始实践的一种方法是按照特定的方式组织我的项目： * `/specs` - 纯粹的人类信号，如产品愿景、需求、设计等。 * `/prompts` - 代理的“食谱”，如技能、任务、AI 模式。 * `/references` - 可用于上下文窗口的参考资料（品牌资产、文档、Figma 导出、数据集等）。 * `/plans` - 项目的代理计划。这些计划通常会有迭代。 * `/build` - 从计划和提示交互中构建的代码库和传统的单体仓库。 （我在 rekallai/craft 的公共 GH 仓库中有一个包含上述内容的 AGENTS.md 文件） 我对这个结构还不完全满意。我觉得 `/plans` 这个名字随着我使用它的增多，有点名不副实（例如，我经常需要生成关于代码库或其他数据集的报告）。 我非常想知道其他（拥抱代理编码的）开发者是如何组织他们的项目的。我的目标是在我的团队中标准化这一点。

大家好！我一直对抖音和微信这类应用不允许我保存或下载动态 GIF 感到非常沮丧，所以我制作了一个小工具，可以将屏幕录制转换成适合 Slack 的表情符号。希望大家能从中受益！

我一直在致力于 Deconvolution，这是一个全面的 Rust 图像去卷积和复原库。Deconvolution 实现了 28 种不同的图像去卷积/复原方法，涵盖了从实用的模糊去除技术到研究级的科学成像算法。 特性： - 顶层函数使用 `image::DynamicImage` 并返回图像 - 逆滤波、维纳滤波、Richardson-Lucy、约束滤波、近端滤波、Krylov 方法、最大似然估计复原 - 盲 Richardson-Lucy、盲最大似然估计、参数化 PSF 估计 - Kernel2D、Kernel3D、Transfer2D、Transfer3D、Blur2D/Blur3D - 高斯模糊、运动模糊、散焦模糊、显微成像模型、支持工具、PSF/OTF 转换 - 边缘渐缩、归一化、范围归一化、NSR 估计 - 确定性模糊、噪声、合成固定件生成 - 支持 ndarray 用于 2D 图像数组和 3D 体积 当然，这个项目还在进行中 :)

各位 HN 的朋友们： 我们是 MyDecisive.ai 的团队，今天我们向开发者们展示 Octant——为您的 OpenTelemetry 提供点按式控制和可见性。 您可能已经体会到了“可观测性税”的痛苦，尤其是在管理 K8S 集群时。目前行业标准是使用 OpenTelemetry 对一切进行检测，但将所有丰富的 OTLP 日志、指标和追踪直接传输到 SaaS 供应商（Datadog、Splunk、Honeycomb）会迅速变得昂贵。您最终会为嘈杂、低价值的数据支付巨额的摄取和存储成本，只是为了在出现问题时能够搜索到它们。有了 Octant，您可以在几分钟内完成 OTel 的部署。 我们构建 Octant 的目的是颠覆这种模式。Octant 不会盲目地将所有遥测数据发送到集群外，而是配置并帮助管理 OTEL 集群。它为您提供了一个可视化界面来管理 K8s 对象，更重要的是，它充当一个 OTLP 网关，在数据离开您的 VPC 之前就在源头进行过滤。 由于它原生支持 OpenTelemetry，您可以直接指向现有的 OTel SDK 或收集器，而无需修改应用程序代码。以下是它在后台的工作原理： - **OTel 原生追踪和日志采样：** 它能够轻松地摄取 OTLP 流量，并在传输过程中检查日志和追踪。通过等待追踪的完整上下文，然后决定保留哪些数据，它实现了将可操作信号（如错误和高延迟跨度）100% 保留，同时在数据进入您的 SaaS 账单之前丢弃无用信息。 - **实时状态告警：** Octant 可以处理遥测流，而无需等待数据被批处理、传输并由外部提供商索引后触发告警。这缩短了检测时间，并从根本上减少了对 SaaS 供应商的依赖。 - **传输中的 PII（个人身份信息）脱敏：** 它可以实时检测并从您的日志和追踪中移除敏感信息，然后再将其传输到互联网上，从而消除了“事后摄取”的清理成本和合规风险。 - **K8s 上下文注入：** 由于它与您的集群深度集成，它可以在统一的 UI 中将您的 OTel 流直接映射到您的 K8s 资源（Deployments、Pods、CRDs）。 API 使用 Go 编写（[github.com/mydecisive/octant]），整个堆栈可以通过我们的 Helm charts 直接部署到您的集群中。 我们非常希望您能在开发集群上部署并进行测试。我们最近刚刚合并了来自我们第一位社区贡献者的 PR，这对我们来说是一个巨大的里程碑！我们希望保持这种势头。如果您对 K8s 可观测性与自主性、OpenTelemetry 流水线或 Go/React 感兴趣，我们已经标记了一些“适合初学者的问题”，并非常乐意欢迎您加入该项目。 GitHub：<a href="https://github.com/MyDecisive/octant" rel="nofollow">https://github.com/MyDecisive/octant</a> 网站：<a href="https://www.mydecisive.ai/" rel="nofollow">https://www.mydecisive.ai/</a> 我今天会一直关注此帖，很乐意回答任何问题或深入探讨架构！

您好，我创建了 nanogram，一个以隐私为中心的社交媒体平台，旨在让用户完全掌控自己的数据。 nanogram 使用纯粹的开源替代方案，提供了一种强大而简洁的方式来模拟 Instagram 早期的体验，让朋友们可以分享彼此的瞬间，而无需任何冗余内容。 此外，还提供了与朋友玩拼字游戏、四子棋和国际象棋的功能。 该平台采用邀请制，这意味着服务器运营商必须生成邀请令牌才能允许新用户加入。 由于 Tor 的全球强大能力，托管完全免费，并且由于其作为洋葱服务运行，因此支持端到端加密 (E2EE)。 您可以在此处找到它：https://gitlab.com/here_gorawhile/nanogram-pi

你好 HN 在对 SQL 感到厌倦后，我在 Dgraph、Typedb 和 SurrealDB 中提交了 120 多个 issue，寻找完美的图数据库。但它们都不是为代理而设计的，也不是我们想要实现的目标的完美契合：完全抛弃 SQL 遗留，以正确地模拟现实。因此，我们决定构建 BlitzGraph。 在 BlitzGraph 中，记录（单元）可以属于多种类型（种类），并随时间演变。此外，多态关系是第一类公民，多种种类可以扮演相同的角色。这种设计有助于摆脱旧的表范式，并在不进行笨拙的自连接（在其他表中将实体与自身连接，但使用不同的 ID）的情况下，跟踪实体在其整个生命周期中的状态。 例如： ``` { "$id": "amazn", "$kinds": ["Company", "Prospect"], deal: ... } // Day 1 { "$id": "amazn", "$kinds": ["Company", "Customer"], contract: .. } // Day 7 { "$id": "amazn", "$kinds": ["Company", "Churned"], churnCause: "..." }, ... // Day 86 ``` BlitzGraph 的不同之处： ``` - 类似 GraphQL 的嵌套查询和变更 https://blitzgraph.com/docs - 多态记录和关系 - 双向 O(1) 关系 - 具有原生基数验证的引用完整性 - JSON 查询/变更语言，专为 AI 代理能够以编程方式构建而设计 - 批量查询/变更，无 N+1 问题 - 内置前端引擎，用于快速仪表板和 MVP - 原生全文搜索、文件存储、计算字段、临时子空间、单元历史记录... ``` 诚实的比较： - 对比 TypeDB：一个很棒的数据库，但并非理想的应用开发选择。另一方面，我们喜欢并借鉴了他们的推理思想以及变更如何智能地执行，而不是逐行执行。 - 对比 SurrealDB：存在多个核心差异，其中一个关键是我们在拓扑顺序中执行验证和转换，并且我们的边是第一类公民。 - 对比 Dgraph：他们很酷的功能，如提交后钩子，是附加在 GraphQL 层上的，而在 BG 中，它是基础性的。 - 对比 Neo4j：如果你尝试过，你就知道。 - 对比 Supabase/PG：BG 在扁平查询方面较慢，但在嵌套查询方面较快。但使用 BG，你主要可以摆脱表范式，进入图世界，同时能够构建应用程序。 尚未完成： - 虽然 BlitzGraph 已经是 AI 代理出色的内存后端，但我们仍需完成语义搜索引擎。 - 查询规划器尚未优化。 - 云前端目前还没有原生身份验证引擎。 Beta 版本已上线，请尽情测试！ - 公共 Playground：https://blitzgraph.com/#playground - MCP：https://blitzgraph.com/mcp