一周热榜

简而言之：ActorCore 是一个有状态的无服务器框架，可以部署到 Rivet、Cloudflare、Bun、Node.js 等多个平台。它是构建有状态的 AI 代理、协作或本地优先应用程序的最简单方式。 大家好，HN！ 几个月前，我们推出了 Rivet Actors（[链接](https://news.ycombinator.com/item?id=42472519)），作为 Cloudflare Durable Objects 的开源替代品。推出后不久，我们意识到我们的目标不是争取现有 Durable Objects 开发者，而是推动有状态无服务器生态系统的发展。 为了提供一些背景——“有状态无服务器”实际上是带有持久状态的 Actor 模型。可以想象成带有本地存储并且可以无限运行的 Lambda 函数。这是一项正在获得关注的技术，旨在更快交付、更高性能，并超越 Postgres。最广泛使用的实现是 Cloudflare Durable Objects。 在与开发者交流的过程中，我们不断听到三个常见的担忧： - 供应商锁定：如果没有明确的退出方案，开发者对采用新的编程模型持谨慎态度。虽然迁移 Postgres 数据库相对简单，但像 Rivet Actors 或 Durable Objects 这样的有状态无服务器平台由于缺乏可行的替代方案，可能会让人感到被锁定。 - 生态系统：选择像 Postgres 这样知名的数据库意味着拥有成熟的生态系统。采用新模型意味着需要从头开始重建工具和模式。 - 概念差距：许多开发者在职业生涯中一直在设计状态和计算分离的系统。将两者合并的模型起初可能会让人感到不适应。 在一次次听到这些担忧后，我们得出结论，最佳解决方案是构建一个与尽可能多的平台兼容的框架，以减少锁定（担忧 #1）并推动共享工具生态系统的发展（担忧 #2）。事实证明，我们已经有一个经过实战检验的框架，基于 Rivet Actors，我们多年来一直在使用它。（它在 Rivet 之外的游戏领域有着悠久而独特的历史，这里就不多说了。） 因此，我们将这个框架拆分到一个新的代码库中，增加了对四个平台的支持（这并不容易），并将其命名为 ActorCore。它为开发者在采用有状态无服务器时提供了多个选择的平台，并为更广泛的跨平台生态系统奠定了基础。 然而，这仍然留有担忧 #3：概念差距。虽然这不是我们能通过框架解决的问题，但我个人大约花费 40% 的时间在文档、内容和示例上，以帮助解决这个问题。ActorCore 也如我们所希望的那样，逐渐变成一个社区驱动的项目，使更多人能够尝试并分享他们对有状态无服务器的体验。 欢迎尝试 ActorCore，阅读我们的路线图，并告诉我们在哪里可以改进文档。如果您对尝试有状态无服务器感到犹豫，我很想在评论中了解更多。 考虑在 GitHub 上给我们一个星标：[链接](https://github.com/rivet-gg/actor-core)

很长一段时间以来，我总是点击“接受所有”，因为如果我要查看像维基解密这样的内容，我会使用隐身模式，而且我显然想使用请求权限的网站，所以我不想让它崩溃。出于好玩，我开始总是点击“拒绝所有”或“仅必要”或任何非“接受所有”的选项，结果……没有一个网站在任何方面功能变得更差。 这对许多人来说可能是旧闻，但我觉得这有点好笑。

我制作了一个网站变更检测工具，因为错过了一个重要产品的补货。现在它可以实时跟踪页面变化，使用人工智能验证变更，通过多种集成方式发送警报，并捕捉截图。这个工具是为了帮助我解决自己的问题而开发的，希望也能帮助到其他人。

我在过去的五年里担任产品经理，与工程团队紧密合作，设计解决方案，并流利地使用技术术语——但我厌倦了只在白板上画图而不写实际代码的角色。 我的背景： - 担任产品经理五年 - 计算机科学基础扎实 - 参与过各种黑客马拉松项目（前端和后端） - 能够在梦中勾勒出系统架构（共同发明了一项软件专利） - 定期参与技术讨论和决策 - 但：没有专业的生产代码经验 我特别对全栈开发和人工智能集成感兴趣。我对产品方面非常了解，明白什么是良好的用户体验，并且能够弥合业务与技术之间的差距。现在我想成为构建者，而不仅仅是指定者。 目前的就业市场并不理想，这使得这个转型更加困难。我在寻找那些重视尊重、诚信、紧迫感，并且（至关重要的是）有资金支持的环境。 对于那些成功完成这一转型的人： 1. 你推荐的路径是什么？ 2. 你是如何克服“没有专业工程经验”这一障碍的？ 3. 有没有具体的公司以支持这种转型而闻名？ 4. 我应该瞄准可以身兼多职的小公司吗？ 谢谢HN！