24小时热榜

是的，就是那个Fortran。

嗨，HN！我们是来自sitefire的Vincent和Jochen（<a href="https://sitefire.ai">https://sitefire.ai</a>）。我们的平台使品牌能够轻松提升在AI搜索中的可见性。 我们已经合作多年，背景分别是斯坦福大学的强化学习/优化和软件工程。在与一些营销团队交流后，我们得出了这个想法，他们由于谷歌的AI概述而流量下降，却不知道该如何应对。 这个领域可能感觉有些深奥。许多案例研究，但实际研究却很少。我们不断与一些误解作斗争（例如，你需要一个llms.txt与不需要一个llms.txt的争论）以及“地理黑客”。我们努力以数据为驱动，勇于创新，构建一个不仅监控，而且能够真正改善AI搜索流量的系统。 在谷歌进行单次搜索时，AI搜索引擎会将用户的提示扩展为3-10个分支查询。获取的页面使用类似于互惠排名融合（RFF）的分类算法进行排名。最后，LLM会浏览这些页面并决定引用哪些片段。我们的目标是确保品牌拥有能够通过这个漏斗的正确内容。 以下是sitefire的工作原理： - 用户定义一组他们想要监控的提示。这些是合成提示——我们根据SEO关键词及其每月搜索量生成它们。 - 我们每天将这些提示提交给ChatGPT、Gemini、谷歌AI模式等，并捕获答案。我们提取分支查询、获取的页面、引用和品牌提及。 - 对于每个主题，我们的代理分析哪些网页被引用和获取的最多，以及原因。他们还会考虑您已经拥有的相似页面。 - 根据诊断结果，我们的内容代理会起草改进建议或创建新页面，并直接推送到客户的内容管理系统（CMS）。 - 我们与客户的网络日志和谷歌分析集成，以监测AI机器人请求和人类推荐到其页面的增加。 该系统会持续更新，因此始终显示哪些内容有效，以及如何调整现有的网站地图。对于一位使用sitefire优化其博客的客户，AI优化的文章在十天内将其AI机器人请求从约200次/天增加到约570次/天。 我们认识到的一个风险是，AI生成的内容可能会让品牌的网站充斥着低质量信息。尽管现在仍处于早期阶段，我们并不声称已经解决所有问题，但我们的意图是通过专注于特定、独特的信息来减轻这一问题：真实的产品能力、真实的定价、诚实的比较。客户在页面上线前仍会审核每一页，以确保内容符合他们的品牌。 一些客户自己使用我们的平台。对于其他客户，我们更像是一个代理机构，随着进展自动化各个步骤。我们的目标是让sitefire大部分时间独立运行，客户通过Slack、Claude或他们的CMS批准更改。 这里有一个视频演示：<a href="https://screen.studio/share/fw7VQQak" rel="nofollow">https://screen.studio/share/fw7VQQak</a> 如果您想尝试我们目前所构建的内容，请在<a href="https://sitefire.ai">https://sitefire.ai</a>注册。

这是给美国用户的一个公共服务公告，因为税季即将来临，有些人可能会使用 H&R Block Business 2025。我发现该软件会在您的本地计算机的受信任根证书存储中安装一个名为“WK ATX ServerHost 2024”（有效期至2049年）的根证书颁发机构（CA）。他们还在一个 DLL 文件中包含了该证书的私钥。这个证书并没有在任何地方标识为“H&R Block”，而且在您卸载软件时不会被自动删除。 我已经成功地在同一网络上的全新虚拟机上使用这个根 CA 和 mitmproxy 通过 DNS 欺骗攻击来操控 TLS 流量。演示视频链接：https://www.youtube.com/watch?v=5paxvYkz1QE 要测试您的机器是否存在漏洞，请访问此页面：https://hrbackdoor.yifanlu.com。如果您的浏览器没有发出任何警告或错误信息，那么您已经安装了后门。如果您的浏览器确实发出警告，您仍然可以选择访问该页面以获取有关漏洞的更多详细信息。 这是疏忽还是一个“真正”的后门？很难判断，既然私钥已经泄露，任何人都可以使用它，因此这个问题的意义就不大了。他们没有合理的理由在不同的名称下安装一个通配符根 CA。当我联系他们时，他们的声明中提到“通过内部安全评估发现了类似的问题”，这意味着他们知道这个问题但尚未修复。在这一点上，我不会信任 H&R Block 的软件。 如果您没有受到影响，恭喜您。请将此帖子视为审计您受信任根 CA 存储的提醒。

你的人工智能初创公司只是一个 Next.js 页面、一个 OPENAI_API_KEY 和一个 Stripe 发票，仅此而已。<p>Gemini、ChatGPT 等是独特的产品，能够增加价值。<p>你的人工智能初创公司只是空中楼阁。

随着我开始构建人工智能集成，我意识到对于许多项目来说，最佳的代理体验是能够让用户的个人代理在你的应用中执行操作。 现有的选项，如MCP或A2A，涉及的内容较多，对于那些已经基于URL参数驱动的简单应用而言，这些选项似乎显得过于复杂。 这促使我原型设计了代理使用接口（AUI）规范。 这个想法很简单：一个轻量级的开放规范，使任何应用都“可由代理导航”。你只需在 /agents/aui.xml 放置一个XML文件，描述你的应用支持的基于URL参数的操作，如搜索、创建、过滤等。这样，任何AI代理都可以读取aui.xml，理解可执行的操作，并代表用户构建URL。 就是这样。没有SDK，没有认证流程，没有API密钥。只有一个你的应用可以执行的操作目录，专为大型语言模型（LLMs）理解而编写。 是否已经存在类似的东西？这种方法是否过于简单而无用？ 如果你的应用已经支持通用链接或其他基于URL参数的功能，你可能在一个下午就能添加对AUI的支持。 查看一个工作示例： [https://habittiles.app/agents/aui.xml](https://habittiles.app/agents/aui.xml)

我厌倦了将 Langfuse 用于追踪、将 promptfoo 用于红队测试和评估，以及为 CI/CD 编写自定义脚本。这一切都很混乱，所以我创建了 EvalsHub。 EvalsHub 将所有功能整合到一个平台上。自动化的生产评分、红队测试、提示版本管理以及 CI/CD 集成。30 分钟内即可实现从零到全面评估覆盖。 希望能收到任何在生产环境中部署 AI 的人的严厉反馈。 evalshub.ai

电子邮件是我们每天都会查看的工具之一，但其基础体验并没有太大变化。我使用的是Gmail，可能大多数阅读这篇文章的你们也是如此。 Arc浏览器为上网带来了乐趣和美感。Cursor则在一个方便的右侧面板中创造了新的用户体验，让代理人随时为你服务。 我每天都在使用这三个工具。自从Arc被Atlassian收购后，我一直在思考：如果我构建一个新的界面，将Arc的用户体验应用于电子邮件，而不是浏览器标签，同时让AI代理轻松可用，以帮助管理电子邮件、事件和文件，会怎么样呢？ 我构建了一个前端概念验证（PoC）来展示这个想法。 试试吧：<a href="https:&#x2F;&#x2F;demo.define.app" rel="nofollow">https:&#x2F;&#x2F;demo.define.app</a> 不过，我对此并不太确定……继续探索这个想法值得吗？