1作者: spola25大约 1 个月前原帖
嘿,HN, 我制作了RAMsey——一个混乱的小桌面伴侣,它会“吞噬”你的文件,生成立方体,并在你与它互动时给予你成就。它就像Clippy、电子宠物Tamagotchi和数字熵的结合体。 它是用PyQt6构建的,支持动画移动、喂食行为和文件互动。你甚至可以把东西拖到它的嘴里,它会做出反应! GitHub: [https://github.com/Githubuser1122bruh/RAMsey](https://github.com/Githubuser1122bruh/RAMsey) (演示视频和截图在README中) 我想制作一些有趣而搞笑的东西,让它驻留在你的桌面上,让你微笑——有点像2000年代初期那些奇怪的工具。非常欢迎反馈或功能建议! 请在GitHub上给我留个星星! 谢谢!
5作者: winzamark12大约 1 个月前原帖
首篇经过同行评审的人工智能研究文章刚刚获得批准。人工智能的发展真是令人惊讶,竟然能够取代研究人员。 我最近在使用ChatGPT和Perplexity进行深度研究,撰写复杂的技术报告给我的老板。他非常喜欢这些报告,这大大减轻了我的工作负担,但我仍然对此有一些不满。这些工具都没有提供一个API,能够让我获得与应用程序相同质量的输出。 我希望能够对大型语言模型(LLMs)有更多的控制,能够与新推出的推理模型进行切换。 我不仅仅想要简单的提示→响应;我想要塑造推理的过程。包括提示的设计、过程的构建、模型应该经过多少层思考,以及LLM应该从互联网上提取哪些信息。 基本上,我想要以下几点功能: - 选择使用哪些LLM模型以及它们的组合方式 - 调整探索的深度或广度 - 指定报告格式:令牌数量、结构,甚至语气 - 显示在整个过程中使用的经过验证的来源 但我使用的大多数深度研究工具都不支持这些功能,或者存在一些奇怪的边缘案例。它们大多数是封闭系统/来源或面向最终用户的商业API,而不是开发者。 因此,我构建了Deep Research——一个完全可定制的开源深度研究框架。它旨在为希望全面控制研究过程的开发者提供便利,而无需从头开始构建一切。 它支持: - 多模型编排——可以插入自己的LLM或使用默认的(内置GPT-4.1) - 自定义深度和广度——可以将研究调节为浅层摘要或多层深度探讨 - 令牌级控制——定义输出的长度 - 透明引用——所有内容都可以追溯到其来源 - 内置网页搜索——集成JigsawStack的网页搜索,将检索与推理结合起来 它运行在Vercel的AI SDK之上,易于配置! 这里有一篇完整的博客介绍: [https://jigsawstack.com/blog/introducing-jigsawstack-deep-research](https://jigsawstack.com/blog/introducing-jigsawstack-deep-research) 试试吧!期待听到其他黑客的反馈!有什么好的,坏的,或者令人担忧的地方。
1作者: furaar大约 1 个月前原帖
我构建了一个一体化的黑客仪表板。可以在10秒内部署虚拟机,点击一下即可安装热门应用程序,提供23种不同的AI模型供使用(无处不在,不仅限于Swiftor)。我们即将推出一个语音聊天系统,允许您通过一键选择MCP工具与任何部署进行聊天。 您好,我是一名软件工程师和网络安全学生,厌倦了为了管理我的开发和学习工作而在Docker命令行和无数浏览器标签之间切换。像Portainer这样的工具确实有帮助,但在更改时重启容器、手动管理机密和评估文档都让我感到非常沮丧!我需要一个统一的界面来提高工作效率。 Swiftor([https://swiftor.io](https://swiftor.io))是一个云原生的一体化界面,旨在快速且无缝地运行。它配备了网络和机密管理器,能够自动更新容器并为服务分配子域名。Webview组件会自动映射这些网络路由,以便快速在iFrame中显示输出——这样您就不必再打开其他浏览器标签。布局管理器允许您通过可拖动的标签和窗口自定义工作区。存储采用智能集中设计,将所有虚拟机、个人资料和工作区数据封装在一个主用户文件夹中。Codemirror6嵌入式编辑器支持多种语言语法,便于快速操作任何部署中的文件。 默认情况下,每个用户都有自己的个人工作区,其中包含笔记和Vibecoding应用程序、AI搜索引擎和Glance仪表板。笔记应用是功能丰富的知识管理软件,支持导出为PDF、Word和HTML。Bolt.diy用于定制新闻、更新和指标。Swiftor非常适合学生、开发者和黑客。云部署确保您可以在任何带浏览器的设备上访问您的部署。 我提供的是生产力、统一性和便利性。您可以在本地自行部署所有这些工具,但正是这种统一且现代的界面,与其他组件相互连接,使其成为一个如此有价值的平台。同行竞争者提供的是简化的工作区,互动性极低。计算的未来在于云,而这是您能获得的最便宜且完全可控的计算资源。开源软件在这个平台的创建中起到了重要作用,我们将继续支持和优先考虑那些由社区主导的项目,以丰富其目录,无论项目规模大小。作为感谢,我计划在未来通过市场和部署的分成来实现盈利,并考虑在盈利后将整个平台开源。届时,您可以在本地以完全相同的功能进行部署。 尽管是闭源的,但它是一个社区驱动的项目,这意味着您可以决定它的发展方向。它尚不完美,但绝对是一个值得分享的高效体验。我有一个发展路线图,想要从现在开始公开构建这个项目。我在运营时利润空间非常紧张,因此如果您喜欢这个项目,请考虑支持。您不会找到比这更便宜的计算资源,同时享受如此无缝且强大的体验。请查看一下,并给我一些反馈。
2作者: odinellefsen大约 1 个月前原帖
许多团队喜欢不可变事件日志的想法,但由于经典事件溯源需要聚合、每个实体的流和深度领域驱动设计,往往不予采纳。每次写入通常意味着需要重放数千个事件,以在内存中重建聚合,然后才能附加新事件。这确保了完美的一致性,但也提高了入门的门槛。 在领域驱动开发与事件溯源中,你需要设计一个聚合,例如订单(Order)。对于这个聚合,你设计领域事件,如订单创建(OrderCreated)、订单信息更新(OrderInfoUpdated)、订单归档(OrderArchived)和订单完成(OrderCompleted)。这意味着存储在订单聚合中的每个事件都是这些设计好的领域事件之一。在这一点上,你创建订单聚合的实例(系统中每个实际产品订单一个实例),例如 Order-001、Order-002,依此类推。对于每个实例,例如 Order-001,你附加与该订单在其事件流中发生的事件相对应的领域事件。 在将领域事件附加到事件流(即你的真实来源)之前,你必须确保用户操作是有效的。验证用户操作/命令是通过重新加载/重放相关聚合实例的每个过去事件来完成的。对于名为 BankAccount 的聚合及其聚合实例,例如 BankAccount-1234,可能会有数百万个领域事件/事件,这意味着每当有人对其银行账户进行操作时,验证该操作可能需要很长时间,这就是快照(snapshots)概念的用武之地,以加快这一过程。 重新加载整个事件历史的目的是为了重建你的应用程序当前状态,或者更具体地说,重建实体/聚合实例的当前状态,即 BankAccount 或 Order。这样做是为了确保你在验证新的用户操作时是基于最新的应用状态,而不是旧的应用状态。 还有另一种方法可以实现验证(并实现事件溯源的核心概念),它不需要你处理重新加载整个事件流的复杂性,也不需要设计聚合来验证新的用户操作。我将要解释的这种替代方案降低了 CQRS + 事件溯源的入门门槛,因为它消除了领域驱动设计的复杂性,并显著扩大了使用案例和可及性(一些经典用例可能不适合这种方法)。但同时,它需要一种不同且强大的基础设施。 我所建议的方法是重新利用领域事件,使其成为我们所称的事件类型(Event Types)的事件流。与其为每个单独的订单创建事件流,不如将每个创建、更新、归档或完成的订单归类到相应的事件类型中。这意味着在提供的示例中,你将为订单聚合拥有 4 个事件流,而不是为系统中的每个订单拥有一个事件流。 我实现事件溯源的方法是通过对实时读取模型进行简单的 SQL 业务逻辑检查。这些读取模型包含了我应用程序的最新状态,在高吞吐量的关键情况下,延迟为个位数毫秒,而在较小吞吐量的较少关键情况下,延迟为个位数秒。 这两种方法都使用应用程序的当前状态,要么通过调用读取模型,要么通过重新加载所有过去的事件来重建当前状态。重新加载只有在不同步的读取模型不可接受时才显得重要。生产数据库在 CQRS 中是下游服务,因此总会存在轻微的延迟。在高争用或超低延迟的领域,如真实货币转账,你应该重放单个账户流以避免风险。如果读取模型在几毫秒到几秒内更新,那么对其进行验证对于绝大多数应用程序来说是完全足够的。
5作者: dwaltrip大约 1 个月前原帖
“参与度”是一个糟糕的指标。 如果你所使用的指标可以被毒贩和赌场老板同样轻松地应用,那你就真的搞砸了。 是的,这是一篇低投入的文章,但我刚花了5分钟在LinkedIn的动态上,实在需要发泄一下。 感谢你来听我的TED演讲。
1作者: bilaal_dc5631大约 1 个月前原帖
你好,这是我过去18个月一直在努力的项目。目前有很多工具可以在桌面上本地运行大型语言模型(例如ollama、LM Studio),但其他设备却被忽视了。这个项目旨在将这些模型运行在iOS和visionOS上,结果效果非常好。甚至一部iPhone 14 Pro也能轻松运行3B参数版本的Llama 3.2。CLIP模型的表现也很好! 它还具有实时语音聊天功能,提供双向对话体验,类似于谷歌提供的基于云的Gemini Live功能。 在技术层面上,它可以运行大多数GGUF模型,使用的是 heavily forked 和 diverged 版本的 llama.cpp,这提升了移动设备上的性能。 接下来的步骤是整合苹果的设备本地3B模型,希望他们能在一周后的WWDC上开放访问。我也正在添加对Gemma 3和Qwen 3的支持。 请告诉我你的想法!