一周热榜

想收集一些关于因人工智能被解雇的人的故事。不是那种通用的“重组”，也不是新闻稿中所说的，而是因为人工智能的真实原因。有没有相关的证据？

大家好， 我正在建立一个名为Persona的平台，旨在将电子邮件调度委托给人工智能。最近，我一直在努力吸引第一批用户，但这确实很具挑战性。 我已经尝试了大家常说的典型策略：冷邮件、LinkedIn InMail、精准定位、写出不错的文案。但结果大多是死胡同，打开率很低，几乎没有回复。 在这个阶段，我并不想听到那些在博客或reddit上常见的建议。我特别想知道那些非常规或不明显的做法，哪些在早期确实对你们有效，尤其是那些当时看起来有点粗糙、奇怪或反直觉的做法。 如果你经历过这个阶段，什么方法真正有效并帮助你获得了第一批用户呢？

使用Anthropic API运行OpenClaw，结果一天内消耗了大约50美元。<p>其他OpenClaw用户的情况如何？有没有人找到有效的降低成本的方法（例如模型分层、缓存等）？

你好，仍然在阅读论坛的朋友们。 我最近刚从大学毕业，开始作为一名初级开发者工作（现在努力从资深同事那里吸收尽可能多的知识），感觉现实世界与大学的实践有些不同。 在大学里，我们学习了设计模式以及诸如领域、应用、基础设施和用户界面等各种职责。领域绝不应该依赖于基础设施或应用层等等。但是我参与的项目中，领域却依赖于基础设施，还有一个项目中应用直接引用了基础设施，并被告知这是正确的实现……真是让人无奈。 我觉得自己在听课上还算不错，但现在开始怀疑，学习这些东西是否真的值得，哈哈，因为外面的情况实在是太矛盾了。当然，我没有资格质疑资深开发者，但你们觉得——大学里所谓的“最佳实践”真的就这样被扔进垃圾桶了吗，还是我只是误解了现实工作的背景？

在过去几天里，我提交的任何链接都停留在“加载”状态，似乎从未进入队列，而且看起来新文章的HN提交也没有任何归档链接被发布。

嗨，HN！我们是TensorPool。我们帮助公司获取和优化大规模计算资源，以训练基础模型。 <p>问题</p> 自从我们完成YC项目以来，已经快一年了，我们的平台上运行的多节点训练GPU小时数刚刚突破了100,000小时。 <p>在这些训练过程中，我们经历了无数次凌晨3点的作业崩溃，原因包括不稳定的GPU导致的Xid错误或S3超时导致的检查点保存损坏。当你醒来并注意到时，已经损失了8个小时以上的计算时间。你急忙诊断问题，手动从最后一个检查点重新启动，并希望这种情况不会再次发生。如此反复。 <p>对于需要数天到数周的训练任务，这种不断的监控既令人疲惫又成本高昂。失去的研究迭代周期可能会影响模型的发布（尤其是在短期预定的情况下）。 <p>我们构建的解决方案</p> 这个代理程序监控你的训练作业，并在出现问题时自动恢复。它与Kubernetes、Slurm和TensorPool作业兼容。 <p>我们最初将TensorPool代理作为内部工具，帮助我们调试与客户的故障。随着时间的推移，我们意识到它的性能非常出色，可以自动化整个分类处理过程。我们现在正在发布公共测试版供大家使用。 <p>最佳情况：TensorPool代理检测到故障，诊断根本原因，修复问题，并从最后一个检查点重新启动你的作业——这一切都在你睡觉的时候完成；） <p>最坏情况：如果TensorPool代理无法自动修复问题，它会提供初步的根本原因分析（RCA）和它尝试的操作列表，帮助你更快地进行调试。 <p>工作原理</p> 1) 注册——你通过我们的仪表板向作业调度程序提供凭据。权限基于白名单授予；你可以明确控制代理可以采取的操作。 2) 监控——代理持续监控你的作业是否出现故障条件。 3) 恢复——在发生故障时，代理分析日志并尝试诊断问题。如果成功，它将从最后一个检查点重新启动作业并继续监控。如果不成功，你将收到包含完整上下文的警报。 <p>目标故障模式</p> 该代理专门针对训练过程中深层次发生的运行时错误设计，例如： - CUDA OOM：内存泄漏，梯度爆炸 - Xid错误：GPU硬件故障（Xid 79、63、48等） - 分布式通信故障：NCCL超时，排名失败 - 存储I/O错误：检查点损坏 - 网络问题：挂载对象存储时的S3请求超时

我正在尝试了解“氛围编码”在今天的实际情况。<p>我目前正在进行的项目接近6万行代码，业务逻辑相当复杂。根据我所听到的，在这个规模下，只有少数工具（比如Claude的桌面应用）真正有帮助，所以我没有尝试过其他的AI编码服务。<p>与此同时，我不断看到有人在一个40小时的周末里构建出2万行代码并推出SaaS。这让我开始怀疑自己是否过于谨慎，或者只是基于过时的假设在运作。<p>我已经相当依赖AI，一个明显的好处是我现在理解了之前写的代码库中的一些部分，而当时并没有完全掌握。不过，以我目前的进度来看，我感觉还需要几个月的开发时间，再加上几个月的测试，才能将其变成真正的生产服务。而且，这个测试似乎并不是可选的。<p>与此同时，被描述为“氛围编码”的产品似乎并没有受到特别负面的评价。<p>所以我在想，大家现在是如何看待这个问题的。“你并不真正理解代码，所以这会在后面给你带来麻烦”这个批评是否仍然有意义？还是说我们已经到了一个需要改变构建软件默认方法的时刻？<p>我特别希望听到在更大或更复杂系统上工作的人的观点。

我一直在努力让 NixBSD（Nix 包管理器 + FreeBSD）能够与 NixOS 一起在共享的 ZFS 池上启动。最终的结果是一个小于 2GB 的磁盘映像，您可以在 QEMU 或 virt-manager 中尝试。 **已实现的功能：** - GRUB 链接到 FreeBSD 的引导加载程序 - 两个系统共享一个 ZFS 池 - 所有内容都在一个 Nix flake 中定义 - 完全可重现的构建（一些依赖项现在已在 Cachix 上缓存） **计划中的功能：** - 支持 NixBSD 的本地编译（目前在 Linux 上交叉编译） - 为了使其工作，采取了许多捷径，需要大量清理 - 添加一个类似于 nixos-wizard 的半自动安装程序 **尝试方法：** ```bash qemu-system-x86_64 -enable-kvm -m 2048 \ -bios /usr/share/ovmf/OVMF.fd \ -drive file=nixos.root.img,format=raw ``` 登录：nixos/nixos 或 root/toor 最困难的部分是使挂载在启动时正常工作，使引导加载程序设置具有幂等性，以及调试早期初始化。这个磁盘映像在经过一些额外工作后，可能可以在 USB 闪存驱动器上运行。 这仍然是一个实验性项目。我的目标是最终制作一个正式的 NixBSD 安装 ISO，并将所有配置整合到一个代码库中，同时仍然使用上游的 NixBSD 作为 flake。 **下载链接：** [https://github.com/jonhermansen/nixbsd-demo/releases/tag/build-1](https://github.com/jonhermansen/nixbsd-demo/releases/tag/build-1) 欢迎在这里或 GitHub 上留下反馈！谢谢！

大家好，我们是 Haakam、Michael 和 Adi。我们正在构建 AgentMail（<a href="https://agentmail.to">https://agentmail.to</a>），这是为代理人设计的电子邮件收件箱 API。我们不是在谈论为您的电子邮件提供 AI，而是为您的 AI 提供电子邮件。 <p>电子邮件是长时间运行的代理的最佳接口。它支持多线程和异步操作，完全支持富文本和文件。它是一种通用协议，内置身份和认证。此外，许多工作流程中关键的上下文信息已经存在于电子邮件中。 <p>我们希望构建可以将工作转发给并返回已完成任务的电子邮件代理。这些代理可以完全自主行动，因为您无需委托您的身份。如果它们遇到问题，可以直接给您或其他人发送电子邮件。 <p>使用 Gmail 时，我们不断受到其 API 限制的困扰。无法以编程方式创建收件箱。存在速率和发送限制。每个收件箱都需要 OAuth。关键词搜索无法理解上下文。按座位计费的定价模式不适合代理。 <p>因此，我们构建了我们希望存在的东西：一个为开发者提供的电子邮件服务。提供创建收件箱和配置域名的 API。电子邮件解析和线程处理。从附件中提取文本。实时网络钩子和 WebSocket。跨收件箱的语义搜索。基于使用量的定价，适合代理。 <p>开发者、初创公司和企业已经在使用 AgentMail 部署电子邮件代理。这些代理可以将对话和文档转换为结构化数据。可以获取报价、谈判价格并获得最佳交易的代理。模拟互联网用户以训练端到端任务模型的代理。 <p>这是 Clawdbots 使用 AgentMail 进行通信的演示：<a href="https://youtu.be/Y0MfUWS3LKQ" rel="nofollow">https://youtu.be/Y0MfUWS3LKQ</a> <p>您可以在 <a href="https://agentmail.to">https://agentmail.to</a> 免费开始使用 AgentMail。 <p>期待听到您的想法和反馈。