最新

我花了 20 年时间构建后端系统，过去 12 年则专注于云基础设施。现在我押注于相反的方向。 我的观点并非“本地 AI 更好”，而是构建可靠替代方案的窗口正在关闭。苹果、谷歌、亚马逊都在关注本地推理变得可行。他们的应对之策将是“本地” AI，但会回传数据——设备端处理结合云端必备功能，以隐私为卖点，实则需要遥测数据。 一旦这些默认设置发布，即使存在替代方案也无关紧要。大多数人在已经拥有方便的东西后，永远不会去寻找其他选择。搜索、社交、移动、云——这种模式不断重复。 我一直在问的问题是：如果本地优先的替代方案无法赢得市场份额，那么构建它们是否重要？我目前的答案是肯定的——即使大多数用户从未选择它，可靠的退出方案的存在也会改变平台行为方式。 但我也意识到这可能只是自我安慰。自托管群体输掉了每一场重大战役。电子邮件、消息传递、社交——私人选项每次都保持小众地位。也许 AI 会有所不同，因为模型终于能够在小规模上实现。也许不会。 正在这个领域构建一些东西。好奇是否有人看到了同样的窗口，或者我只是将一种偏好合理化成一个市场。

Go 1.26 通过 GOEXPERIMENT=simd 增加了原生 SIMD 支持。该库提供了一个可移植层，因此同一代码可以在 AVX2、AVX-512 上运行，或者回退到标量模式。<p>灵感来自于 Google 的 Highway C++ 库。<p>包含向量化数学函数（exp, log, sin, tanh, sigmoid, erf），因为它们在机器学习/科学代码中经常出现，而标准库中没有 SIMD 版本。<p>例如：algo.SigmoidTransform(input, output)<p>需要 go1.26rc1。欢迎提供反馈。

大家好，我是 Akshay，我正在推出 Seer——又一个具有细粒度 OAuth 范围的 AI 工作流构建器。 GitHub: [https://github.com/seer-engg/seer](https://github.com/seer-engg/seer) 演示视频: [https://youtu.be/cmQvmla8sl0](https://youtu.be/cmQvmla8sl0) 问题： 过去一年，我们一直在构建 AI 工作流，并反复遇到同样的问题：现有的平台（n8n、Langflow、Flowise）即使对于只读操作也需要完全访问您的 Google 服务。想总结邮件？您也同时授予了发送权限。想阅读文档？您也同时授予了编辑权限。 如果您想要细粒度的范围，您需要： - 创建您自己的 Google OAuth 应用程序（需要 1-2 周的审批时间） - 修改源代码以支持只读范围 我们在 Discord 频道和 GitHub 问题中看到了这种模式的重复——开发者们要求更好的范围支持，维护者们说“您可以自己配置”。 我们的解决方案：Seer 默认使用只读身份验证范围进行常见操作。它是自托管的，因此您的数据永远不会离开您的基础设施。演示展示了一个简单的邮件摘要工作流（Gmail + LLM API），但该原则适用于任何集成。 为什么这很重要：通过最小权限实现安全性不仅仅是最佳实践——当您向 AI 代理授予对生产数据的访问权限时，这一点至关重要。一个受损的工作流不应该意味着您的整个 Google Workspace 都会面临风险。 向 HN 提问： 1. 您目前是如何在 AI 自动化工作流中处理 OAuth 范围的？ 2. 您是否会觉得一个审计您现有工作流的范围验证器有价值？ 3. 您希望看到哪些具有细粒度权限的其他集成？ 唯一一个支持细粒度范围的类似平台是 Make.com，但它是闭源的。我们认为这应该是标准，而不是例外。 期待您的反馈！