最新

嗨，HN， 我上周在这里发布了 Out Plane。想分享一个更新，因为我最近有很多进展。 我开始这个项目是因为部署副项目让我失去了动力。周末做一些有趣的事情，然后浪费两天时间在 Dockerfile、nginx 和 SSL 上。所以我构建了我想要的——连接 GitHub，推送代码，获取一个 URL。完成。 自去年12月以来，我增加了托管的 PostgreSQL、内置 RedisInsight 的托管 Redis、自动检测 Dockerfile 并预填配置、实时指标以及零规模——没有流量就没有账单。按秒计费，而不是按小时。相同的 Next.js + Postgres 应用在我这里每月只需 $2.40，而其他平台则需要 $12 到 $47。 目前还没有命令行工具，文档需要改进，用户大约有 200 个。只有我一个人，没有团队，也没有资金。但人们在上面运行真实的项目。 提供 $20 的免费信用额度，无需信用卡。我亲自阅读所有反馈——这里只有我一个人。

我想用一个替代品来替换我的Alexa，要求能够使用实时模型，比如Gemini，或者一个语音转文本（STT）- 大语言模型（LLM）- 语音合成（TTS）的流程。最好能用Arduino轻松搭建，或者我也乐意购买一个现成的解决方案。<p>基本功能应包括播放Spotify、提问和设置定时器。

我们接到了一份模糊的客户请求，内容是“团队生产力仪表板”，并通过两种不同的发现流程进行了处理：一种是传统的人类分析师方法，另一种是基于人工智能的询问工作流程。 结果令人不安。人类分析师写了一段礼貌的总结，概述了“理想路径”。而人工智能则生成了一份包含127个技术规范的详细文档，突出了每一个边缘案例、安全漏洞和我们通常会在第八周才想起的缺失功能。 以下是实验的详细分析，以及我认为“范围蔓延”主要是发现失败的原因。 问题： “假设盲点” 我们都经历过“第八周危机”。在一个为期12周的项目中，当你完成了75%时，客户突然问：“管理用户的管理面板在哪里？”开发团队假设这超出了范围；而客户则认为这是隐含的，因为“所有应用都有登录功能”。 人类有很高的上下文理解能力。当我们听到“仪表板”时，我们会假设标准的身份验证、标准的错误处理和标准的规模。我们不会把这些写下来，因为这感觉有些啰嗦。 而人工智能则没有上下文。它不知道“身份验证”是隐含的。它不知道我们对原型的速率限制并不在意。因此，它会询问。 实验 我们将相同的输入提供给了一位资深人类分析师和一个作为技术询问者的LLM工作流程。 输入：“我们需要一个仪表板来跟踪团队的生产力。它应该从Jira和GitHub中提取数据，并显示谁在阻碍谁。” 路径A：人类分析师 输出：约5个要点。 专注于用户界面和“商业价值”。 假设：标准的Jira/GitHub API、单租户、标准安全性。 结果：一份干净、易读但技术上空洞的总结。 路径B：人工智能询问者 输出：127个独立的技术需求。 专注于：失败状态、数据治理和边缘案例。 结果：一份庞大、乏味但详尽的文档。 结果 数量差异（5与127）令人震惊，但内容差异才是关键。人工智能明确列出了人类完全“盲点”的需求： - 细粒度的RBAC：“如果一名初级开发者试图删除一个仓库链接，会发生什么？” - API速率限制：“我们如何处理同步时来自GitHub的429错误？” - 数据保留：“我们是否无限期存储Jira票据？是否有清除政策？” - 空状态：“对于一个没有任何票据的新用户，仪表板会是什么样子？” 人类的规范暗示这些是“实施细节”。而人工智能将其视为需求。在我的经验中，将RBAC视为实施细节正是项目超出预算的原因所在。 权衡与局限性 公平地说，阅读一份127点的规范是非常痛苦的。这其中存在严重的信号与噪声问题。 - 膨胀：人工智能可能过于严谨。它建议为本应是单体的项目采用微服务架构。在不存在复杂性的地方，它产生了幻觉。 - 瘫痪：给开发者提供一份127点的清单用于原型开发，是打击士气的好方法。 - 过滤：你仍然需要人类来审视这个清单，并说：“我们还不需要多租户，删除第45到60点。” 然而，我宁愿在项目开始时删除20个不必要的要点，也不愿在发布前两周发现20个缺失的需求。 讨论 这个实验让我意识到，我们对编写规范的厌恶——以及对“隐含”上下文的依赖——是技术债务的主要来源。人工智能之所以有用，并不是因为它聪明，而是因为它足够细致，能够提出我们认为太显而易见而不去问的问题。 我很好奇其他人是如何处理这个“隐含需求”问题的： 1. 你是否有一个关于RBAC/身份验证/速率限制等内容的清单可以重复使用？ 2. 一份超过100点的规范真的有帮助吗，还是只是提前引发争论？ 3. 你如何从“人工智能噪声”中筛选出关键的缺失规范？ 如果有人想查看我们用来触发这种“询问者”模式的具体提示，欢迎在评论中分享。

我写了一份关于将 Playwright 集成到三种最常见 CI 系统的指南。该指南涵盖了每个平台在可靠运行 Playwright 时所需的实际要求：浏览器依赖处理、playwright.config.ts CI 设置、并行分片以及失败测试的工件收集。 大多数团队面临的核心问题是：默认的 CI 镜像并不包含 Playwright 浏览器所需的系统库（GTK、NSS、ALSA）。该指南涵盖了两种方法——Playwright 官方 Docker 镜像与手动安装带依赖的方式，并说明了在何种情况下使用每种方法更为合适。 每个平台的部分都包括一个可直接复制的工作配置文件： <p>GitHub Actions：使用矩阵分片的 YAML，跨 4 个运行器 Jenkins：使用 Playwright 的 Docker 镜像作为代理的 Jenkinsfile GitLab CI：包含本地并行关键字的 .gitlab-ci.yml <p>此外，还涵盖了在 CI 中如果忽略会导致问题的 playwright.config.ts 设置：forbidOnly、重试次数、工作线程数量和追踪收集策略。 完整文章请见：<a href="https://testdino.com/blog/best-playwright-ci-cd-integrations/" rel="nofollow">https://testdino.com/blog/best-playwright-ci-cd-integrations...</a> 如有任何关于特定平台设置步骤的问题，欢迎提问。

嘿，Hacker News， 我为自己搭建了一个“蜂巢”。现在我的工作主要是监督多个问题的OC或CC劳动任务并行进行。我的设置以前是使用Zellij，打开几个标签页，每个标签页在不同的目录中工作，这样管理起来非常麻烦。我知道可以使用Git工作树，但它们有点复杂，如果你不知道怎么使用，很容易搞砸。我更喜欢让代理在各自的目录中运行，拥有自己的.git，这样就不会有风险。虽然我喜欢Zellij并在蜂巢中使用它，但我不喜欢标签页，常常忘记自己在哪里。 “蜂巢”是我抽象这一切的方式。这个概念很简单——蜂巢就是代码库，所以你基本上有一堆与工作相关的蜂巢。每个蜂巢可以有多个“蜂窝”。“蜂窝”是一个目录，里面有你正在工作的代码库的副本。完全隔离、独立，没有共享的.git。因此，无论是工作还是个人项目，我通常会设置一个蜂巢，然后在多个蜂窝之间切换，监督代理们完成他们的工作。如果你有一个大的代码库，克隆需要一点时间，而且你还需要GitHub和Git，因为我喜欢检查代码库是否存在等这些小功能。 这个应用是开源的，采用MIT许可证。我选择了Tauri，因为我讨厌Electron。此外，我有朋友和同事更新到了macOS 26，我不知道Electron应用的内存泄漏问题是否已经修复。这个应用大约9MB，这也很不错。大部分是用C++编写的，但我指导了美学和整体思路。它在Mac上运行，并且有一个已签名和公证的DMG（我重新激活了我的Apple开发者凭证）。 分享这个是想了解一下这个想法的反馈，也许对你有用。关于工作树和目录之间的争论有很多合理的观点。我只是知道工作树对我来说太复杂了，我喜欢简单的东西。如果你喜欢这个应用，请告诉我，如果你想帮忙（比如添加Linux支持，或者添加主题、其他酷功能），请提交PR或打开一个问题。