最新

我偶然看到一篇来自shannoncc的帖子，标题是“我60岁了。Claude Code重新点燃了我的热情”，这让我深思。我也快60岁了，但人工智能却让我失去了热情。我记得在人工智能出现之前的日子，那时我白天、晚上、周末和假期都在享受编程的乐趣。而现在，这种乐趣不复存在，而其他人却重新找到了他们的“热情”。 我认为这取决于你喜欢什么：旅程还是目的地。我一直以来都享受旅程，而我觉得现在那些乐在其中的人是在享受目的地。人工智能给了我们更多的目的地，但旅程却少了。这并不是好或坏，只是不同而已。

我创建了一个Claude Code技能，可以将你的终端变成一张扑克桌。你将与三位AI对手进行无限注德州扑克游戏，每个AI对手作为独立的Claude子代理运行，拥有自己的个性和隐藏的牌。主代理充当发牌员，管理游戏状态，并可以选择性地为你提供指导。 指导方面有三种模式：完全不提供帮助、在每次决策前提供实时提示，或仅在手牌结束后进行分析。 温馨提示：Claude在每一手牌上都非常激进。你可以期待比任何真实扑克桌产生的更多的口袋A和戏剧性的转牌。 ``` ╭─────────────────────╮ │ 彩池: 130 │ │ Q♥ 9♦ 4♠ │ Alex │ │ Jordan [990] ╰─────────────────────╯ [905] (小盲) (大盲) 弃牌 加注 50 你 <- Sam [965] [1000] (按钮) (早位) ┌────────┐ 弃牌 │ K♠ Q♠ │ └────────┘ 教练的低语：你在翻牌中得到了顶对，带有国王的踢脚牌——在这里是非常强的手牌。Jordan是翻牌前加注者，并且在对你进行持续下注，这是标准的玩法。跟注是稳妥的选择，可以让彩池保持可控。你也可以加注到大约140以获取价值和保护，但在位置上跟注并让Jordan继续下注也是一个非常好的策略。 [F]弃牌 [C]跟注50 [R]加注到 ___ ``` 在你的第二个终端中做些事情，而Claude在第一个终端中为你工作。 仓库链接： [https://github.com/BohdanPetryshyn/code-royale](https://github.com/BohdanPetryshyn/code-royale)

我用Go语言构建了Signet，目的是看看一个自主系统能否处理目前由人工进行的野火监测循环——检查卫星数据、获取天气信息、观察地形和燃料情况，判断某个检测是否真的值得跟踪的火灾。 所有的数据都已经存在：NASA的FIRMS热检测、GOES-19影像、NWS天气预报、LANDFIRE燃料模型、USGS海拔数据、人口普查数据、OpenStreetMap。问题在于这些数据来自不同的来源，以不同的节奏和格式到达。 系统的大部分是确定性的基础设施——数据摄取、空间索引、去重。我使用Gemini来协调23个工具，涵盖天气、地形、影像和事件跟踪，尤其是在清晰规则失效的部分：决定哪些弱检测值得进一步调查、接下来应该提取什么上下文，以及如何将嘈杂的证据综合成结构化评估。 它还记录时间限制的预测，并将其与后来的数据进行评分，因此系统所做的声明是可证伪的，而不是事后叙述。尽管样本仍然较小，但当前的预测指标在网站上是可见的。 它已经能够从原始卫星检测中开启事件，并将一些事件与官方的NIFC报告进行匹配。但假阳性、检测延迟和事件匹配仍然存在问题。 我特别欢迎对以下方面的批评：在什么地方应该更具确定性，而不是依赖大型语言模型？这种自主监测是否真的有用，还是比手动操作更嘈杂？

你好，我刚刚推出了一款SaaS分析平台。在这个平台上，你可以连接Stripe和Google Ads以及其他一些工具，准确了解你在广告上的支出、从中获得的客户数量，以及你赚了多少钱或亏了多少钱。

我做了一件事，觉得可能会有用，因为我肯定不是唯一遇到这个问题的人。我也很想知道其他人是如何解决这个问题的，所以如果你曾经做过类似的事情，并且保持了对开发者友好和易于扩展的特性，请告诉我。

抱歉，我无法直接访问或翻译网页内容。不过，如果你能提供网页上的具体文本或信息，我很乐意帮你翻译成中文。

我正在构建一个用于外发邮件的人工智能代理管道，但遇到了一个我没有看到过太多讨论的基础设施问题。 当你同时运行多个代理进行外联时，大多数人默认的设置是让所有代理共享一个电子邮件域名和发送身份。这在规模化时会出现几个问题： 1. 声誉隔离：如果某个代理因发送过于频繁而被标记或触发垃圾邮件过滤器，整个域名的声誉都会下降。即使其他代理运行正常，它们的投递率也会受到影响。 2. 回复归属：所有的回复都会集中到一个收件箱中，无法干净地将其路由回发起对话的特定代理。这使得转化跟踪几乎变得不可能。 3. 代理级别的A/B测试：当所有代理共享同一身份时，无法在代理级别测试不同的消息传递方法。 看起来正确的做法是为每个代理提供一个专用的发送地址，这样每个代理的声誉就可以隔离，回复也能正确路由。但实现这一点的工具——特别是入站路由的部分——似乎并不存在于适合代理工作流程的即插即用形式。 我很好奇其他人是如何解决这个问题的。你们是手动管理不同的身份，还是使用我遗漏的某些现有工具，或者目前只是接受共享域名的限制？

在构建AI代理时，我不断遇到同样的问题：每个需要使用电子邮件的代理最终都要共享我的个人收件箱或一个单一的公司域名。这会破坏归属，增加投递风险，并使得无法对每个代理进行发件人身份的测试。 因此，我开发了AgentMailr。你可以通过API创建一个收件箱，你的代理将获得一个独特的电子邮件地址，回复会直接路由到该特定代理。它适用于入站（一次性密码解析、回复路由）和出站（冷邮件、通知）。 支持自带域名，这样电子邮件将来自你的域名，而不是我们的。REST API和MCP服务器已经上线，Node/Python SDK正在开发中。 欢迎询问有关架构或我如何处理多代理路由的问题。

我们现在大约有15个人，以前“自然而然”能运作的事情开始出现问题。大家都知道的决策变得模糊不清。新员工的适应期变得漫长。不同团队在不同的假设上进行工作。 对于经历过这个阶段的人来说，最初出现问题的是什么？你们是如何应对的？