最新

当我担任产品分析师时，我们使用 Notion 来创建事件跟踪计划。但我总觉得这与用户界面脱节——粘贴截图，试图解释“当用户点击这个按钮时，我们触发事件 XYZ，并带有这些属性”……然后前端开发人员又来问我某些内容的含义。 于是我在一个周末编写了一个 Figma 小部件。这个小部件允许分析师直接在设计上添加结构化的事件跟踪规范——就像评论，但针对事件，包含名称、描述和属性。前端开发人员可以清楚地看到具体需要实现的内容以及何时发送每个事件，而无需翻阅文档或电子表格。 你可以在 Figma Community 上免费试用。希望能收到分析师、产品经理或处理混乱分析文档的开发人员的反馈！

嘿，HN！<p>我是Dan Zaitsev，一名独立创业者，也是LiftmyCV的创始人，这是一款AI求职助手，可以为您找到相关的职位空缺并自动申请。<p>在2024年初，我的小型营销团队开始因AI工具的兴起而失去客户。因此，我开始自己找工作，并再次感受到这个过程是多么令人沮丧和低效——浏览数十个求职平台，填写无尽的表格，得到的回应却寥寥无几。<p>我开始使用ChatGPT来加快这个过程，并意识到这个过程可以被自动化。这就是LiftmyCV的诞生。<p>我构建了一个简单的原型，向一小部分早期用户发布，并迅速得到确认——人们发现这个想法很有帮助，并且愿意为此付费。在早期测试中，我个人在使用该产品的一周内收到了几次面试邀请。<p>是的，我知道有些创作者已经尝试（或仍在尝试）构建类似的产品——而且，确实有很多竞争者。但我真心认为我可以做得更好。以下是我的方法：<p>- 质量胜于数量：我看到有一个人发帖说他在一周内申请了1000个工作……但实际上重要的是每个申请的质量。因此，我专注于优化GPT的自动填充响应和服务器逻辑，使每个申请更加上下文相关和人性化。本周将推出AI代理的重大升级——希望你会喜欢 :)<p>- 没有订阅陷阱：虽然其他人提供高价的终身解锁（100美元以上）或每次自动申请收费2.50美元以上，但LiftmyCV采用的是免费增值/按需付费模式。先试后买——没有锁定。<p>自2025年2月的测试版发布以来： - 942个注册用户 - 70个付费用户 - 收入1225美元 - 在Product Hunt上获得“今日产品”第三名 *所有用户均为自然增长，广告支出为0：YouTube视频、SEO内容和直接推广<p>技术栈： - Web应用：Java + Spring Boot + TypeScript + React JS + Effector + OpenAI API - Chrome扩展/AI代理：JavaScript - 营销网站/着陆页：Wordpress/PHP<p>在MVP中提供的核心功能： - 支持7个求职网站和ATS平台 - 自动化求职 - 不间断AI自动申请（自动在不同的求职平台之间切换） - 基于GPT-4o的职位申请自动填充 - 自动申请历史和统计数据 - 高级支持并开放功能请求 - 先试后买 - 免费计划包含3次简历提交<p>它是如何工作的？ 1. 访问www.liftmycv.com并创建您的免费账户 2. 从Chrome网上应用店安装官方Google Chrome扩展 3. 完善您的个人资料并上传简历（确保您的个人资料尽可能详细，以获得更好的结果） 4. 激活AI自动申请功能，让LiftmyCV为您处理职位申请<p>我面临的挑战： - 微调AI自动填充逻辑一直很棘手（这仍在持续改进中）。 - GPT生成的响应需要不断调整，以避免出现尴尬或不相关的表格填写。 - 人性化AI输出对于绕过ATS系统并使申请看起来真实至关重要。

简而言之：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)