最新

大家好，我是拉尔夫。我拥有软件开发学位，过去 15 年来一直从事网站开发和 SEO 工作，其中最近 6 年经营着一家机构。 几年前，我意识到人工智能可以用于自动化我们机构的许多初级 SEO 任务和手动工作。我详细阐述了我们的流程，绘制了人工智能可以发挥作用的领域，并开始将它们全部整合起来。 由此创建了一个 AI 驱动的 SEO 平台，该平台可以自动化关键词研究、元标题/描述、图片 alt 文本和页面级内容，并带有审批工作流程和基于 token 的使用方式。我还在探索自动化链接建设、全面的技术审核以及 AI 生成的修复建议。 最大的挑战之一是如何管理上下文相关性，为系统提供足够的信息以全面了解网站，同时又不会让模型过载或稀释相关性。 该平台目前处于 Beta 测试阶段，但我一直在纠结是继续朝着“完美”的方向努力，还是把精力放在尽早分享它，让真正的用户来指导真正重要的东西，所以我来这里征求反馈意见。 我非常感谢任何见解，特别是关于这个平台是否适合以及如何融入工作流程，对返回结果的质量的反馈，以及任何可能阻碍用户采用的因素。 为了在 Beta 测试期间保持可预测的成本，用户可以使用一个 token 预置的工作区进行测试，适用于 100 页或更少的网站。

好吧，我当然尝试了。我必须这样做，因为它有一个受“数字极简主义”启发的特定特性。 这个特性是它每天（或每 X 天）只允许你获取一次新文章。 为什么？让我来解释一下... 我希望我的互联网内容像一份无聊的报纸。你早上拿到它，一边喝着早晨的咖啡，一边读完所有内容，然后就结束了！今天不再有新的信息了。没有提示，没有警报，平静，安静，禅意等等。 但有了这个，我需要它能够一次性从我数百个订阅源中获取所有文章。这就是 Zig 和 curl 优化发挥作用的地方。我尝试了所有能想到的技巧。如果我遗漏了什么，请告诉我！ 首先，我在网络层使用了 curl multi。很酷的是它会自动进行 HTTP/2 多路复用，这意味着如果你的订阅源托管在同一个 CDN 上，它会重用相同的连接。我已将其配置为总共处理 50 个连接，每个主机最多 6 个连接，这似乎是服务器开始变得可疑之前的最佳点。此外，还有条件 GET。如果订阅源自上次以来没有更改，服务器只会说“未修改”，我们立即退出。 当 curl 正在下载订阅源时，我不希望 CPU 闲置，所以当 curl 完成下载单个订阅源时，它会触发一个回调，立即将 XML 扔进一个工作线程池进行解析。主线程继续管理所有网络事务，而工作线程并行处理 XML。Zig 的内存模型非常适合这个。每个订阅源都有自己的 ArenaAllocator，它基本上是一个游乐场，你可以在解析期间分配字符串，然后当我们完成时，我们只需一次性清除整个 arena。 对于解析本身，我正在使用 libexpat，因为它不会像 DOM 解析器那样将整个 XML 加载到内存中。这很重要，因为一些播客订阅源尤其是 10MB+ 的 XML。因此，通过智能截断，我们下载前几个 X mb（可配置），向后扫描以找到最后一个完整的 item 标签，在那里截断它，然后只解析它。即使订阅源大小变得很大，也能保持内存使用量合理。 对于 UI，我只是将所有内容管道到系统的“less”命令。你可以免费获得 vim 导航、搜索和分页。此外，我正在使用 OSC 8 超链接，因此你实际上可以单击链接以在浏览器中打开它们。不需要任何 TUI 框架。我还包括了 OPML 导入/导出和订阅源组作为附加功能。 结果：在几秒钟内从数百个 RSS 订阅源中检索内容，并且在一天剩下的时间里安心。 代码是开源的，并获得 MIT 许可。如果你有关于如何使其更快或更好的想法，请在下面评论。也欢迎在此处或 GitHub 上提出功能请求和其他建议。

这太不真实了。我用谷歌 `genai` 提出的请求，大部分都因为 503 错误而失败。有人遇到同样的问题吗？

我构建了一套完全在浏览器中运行的开发者工具。无需账户，无服务器端处理，无追踪。 包含：JSON格式化/验证器、CSV转JSON/SQL转换器、正则表达式测试器、Base64编码器、哈希生成器、UUID生成器、JWT解码器、Cron表达式解析器、时间戳转换器、差异比对工具等。 技术：纯HTML/CSS/JS。刻意保持简单，以实现快速加载和易于维护。 开源：<a href="https:&#x2F;&#x2F;github.com&#x2F;GhDj&#x2F;dev-tools" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GhDj&#x2F;dev-tools</a> 欢迎提供反馈，告诉我接下来添加什么工具会更有用。

Hi HN， WindMouse 是一个相当古老且众所周知的算法，用于生成类似人类的鼠标移动（曲线路径、可变速度、自然减速）。它经常在自动化讨论中被提及，但令人惊讶的是，我找不到一个干净、经过良好测试、可重用的 Python 库实现。 所以我决定自己实现它。 该项目现已作为 <i>WindMouse</i> 发布： * 强类型（坐标使用 <i>NewType</i>，支持 mypy） * 两个后端： ``` * PyAutoGUI（跨平台） * AutoHotkey（Windows） ``` 算法本身并不新鲜——实现是。我的目标是创建一个可以下载并立即在项目中使用的东西。 我正在寻求以下方面的帮助： * <i>在不同的操作系统设置上进行测试</i>（特别是 macOS 边缘情况） * <i>新的后端</i>（例如，原生 macOS、Wayland、低级 Windows API、游戏引擎、远程桌面） * 关于 API 设计和参数默认值的反馈 很乐意回答关于算法、设计决策或权衡的问题。

以下是我们创业公司使用 LLM 的方式。 我们有一个单体仓库，其中包含已排程的 Python 数据工作流程、两个 Next.js 应用程序和一个小型工程团队。我们使用 GitHub 进行 SCM 和 CI/CD，部署到 GCP 和 Vercel，并高度依赖自动化。 本地开发： 每位工程师都获得 Cursor Pro（加上 Bugbot）、Gemini Pro、OpenAI Pro，以及可选的 Claude Pro。我们并不在意大家使用哪个模型。实际上，LLM 相当于每位工程师配备了大约 1.5 位优秀的初级/中级工程师，因此为多个模型付费是完全值得的。 我们高度依赖 pre-commit hooks：ty、ruff、TypeScript 检查、跨所有语言的测试、格式化和其他保护措施。所有内容都自动格式化。LLM 使编写类型和测试变得容易得多，尽管复杂的类型仍然需要一些人工指导。 GitHub + Copilot 工作流程： 我们主要为 GitHub Enterprise 付费，因为它允许将问题分配给 Copilot，然后 Copilot 会打开一个 PR。我们的规则很简单：如果你打开一个问题，就把它分配给 Copilot。每个问题都会附带一个代码尝试。 对于大量的 PR，我们没有任何顾虑。我们经常删除不使用的 PR。 我们使用 Turborepo 管理单体仓库，并且在 Python 方面完全使用 uv。 所有编码实践都编码在 .cursor/rules 文件中。例如：“如果你正在进行数据库工作，只编辑 Drizzle 的 schema.ts，不要手写 SQL。” Cursor 通常会遵守这一点，但其他工具很难始终如一地读取或遵循这些规则，无论我们添加多少 agent.md 风格的文件。 我个人的开发循环： 如果我在旅途中看到一个 bug 或有一个想法，我会通过 Slack、移动设备或网页打开一个 GitHub 问题，并将其分配给 Copilot。有时问题很详细，有时只有一句话。Copilot 会打开一个 PR，我稍后会进行审查。 如果我在键盘前，我会在 Cursor 中以 Git 工作树中的 agent 身份开始工作，使用最佳模型。我迭代直到满意为止，要求 LLM 编写测试，审查所有内容，然后推送到 GitHub。在人工审查之前，我让 Cursor Bugbot、Copilot 和 GitHub CodeQL 审查代码，并要求 Copilot 修复它们标记的任何问题。 仍然很痛苦的事情： 要真正知道代码是否有效，我需要运行 Temporal、两个 Next.js 应用程序、几个 Python worker 和一个 Node worker。其中一些已 Docker 化，有些则没有。然后我需要一个浏览器来运行手动检查。 据我所知，没有服务可以让我：提供提示、编写代码、启动所有这些基础设施、运行 Playwright、处理数据库迁移，并让我手动检查系统。我们用 GitHub Actions 来近似实现这一点，但这无助于手动验证或数据库工作。 Copilot 在分配问题或代码审查期间不允许你选择模型。它使用的模型通常很糟糕。你可以在 Copilot 聊天中选择一个模型，但在问题、PR 或审查中不行。 Cursor + 工作树 + agents 简直糟透了。工作树从源仓库克隆，包括未暂存的文件，因此如果你想要一个干净的 agent 环境，你的主仓库必须是干净的。有时感觉直接将仓库克隆到一个新目录中比使用工作树更简单。 运行良好的地方： 由于我们不断启动 agents，我们的单体仓库设置脚本经过了充分的测试并且可靠。它们也可以干净地转换为 CI/CD。 大约 25% 的“打开问题 → Copilot PR”结果可以直接合并。这并不惊人，但总比零好，并且在添加一些注释后可以达到约 50%。如果 Copilot 更可靠地遵循我们的设置说明或允许我们使用更强大的模型，这个比例会更高。 总的来说，每月花费大约 1000 美元，我们相当于每位工程师增加了 1.5 位初级/中级工程师。这些“LLM 工程师”总是编写测试、遵循标准、生成良好的提交消息，并且 24/7 全天候工作。在审查和跨 agents 切换上下文时存在摩擦，但这可以管理。 你们在生产系统中如何进行氛围编码？