一周热榜

嗨，HN！<p>我已经运行 GitHub Actions 工作流一段时间了，当 GitHub 宣布推出新的 ubuntu-slim 运行器作为比 ubuntu-latest 更便宜的替代方案时，我想进行迁移——但确定哪些工作流可以安全切换却出乎意料地繁琐。<p>你需要检查 Docker 的使用情况、服务、容器、因缺少软件包而导致的步骤失败，以及作业是否依赖于 slim 镜像中不可用的工具。<p>因此，我构建了 gh-slimify，这是一个 GitHub CLI 扩展，可以自动化这一切。它扫描你的代码库，检测哪些作业可以迁移，标记不兼容的模式，识别缺失的命令，并且可以通过一个命令仅更新安全的工作流。<p>gh extension install fchimpan&#x2F;gh-slimify gh slimfy # 分析工作流 gh slimfy fix # 仅更新可以安全迁移的作业<p>它是开源的（MIT 许可证）。 作为额外奖励：README 中还包含一个 AI 代理提示，可以重现相同的工作流迁移分析——如果你想将逻辑集成到 LLM 代理中或实验自动重构，这非常有用。<p>我很想听取反馈——特别是关于边缘案例、误报/漏报或它应该更好检测的模式。

独立创始人正在构建 *Vibe* — 三层 AI 副驾驶系统： 1. *Chrome 扩展*（当前 MVP — API 密钥，页面命令） 2. *Chromium 分支*（完整浏览器，内置 AI 副驾驶） 3. *Playwright 代理*（无头，完整的 DOM + 可访问性树访问） *关键见解：* - 扩展 = 有限（没有可访问性树，上下文较弱） - 浏览器 + Playwright = 全力（HTML 树，实时 DOM，自动化） 我 *原本* 打算将扩展开源（MIT 许可），以获得关注和贡献者。 但现在：*未来 90% 的价值在于浏览器 + 代理*，而不是扩展。 *两难境地：* - 开源扩展 → 社区增长外壳，但我失去对 *真正* 产品的控制 - 保持完全封闭 → 反馈较慢，验证更困难 *选项：* 1. *源代码可用的扩展*（公开代码，不允许分叉/商业使用） 2. *仅开源扩展 SDK*（用于接入 Vibe 浏览器的 API） 3. *保持完全封闭*，先发布浏览器测试版 LangFuse：MIT 核心 + 收费 EE Raycast：封闭核心，开放扩展 *HN：* - 我应该将 *弱* 部分（扩展）开源以建立影响力吗？ - 还是在浏览器 MVP 发布之前保持一切封闭？ - 如何在不泄露护城河的情况下获取早期用户？ 旧金山，2 个月的资金储备。 代码库（即将上线）：https://github.com/VibeTechnologies/VibeWebAgent 推介：pitch.vibebrowser.app 你会怎么做？

嗨，HN， 我创建了 Palettt，这是一款帮助设计师和前端开发者更轻松地处理颜色的工具。你可以直接在这里试用，无需注册： [https://palettt.com](https://palettt.com) 我之所以制作这个工具，是因为我作为一名开发者，对颜色的掌握并不出色，常常在不同的调色板工具之间切换。我希望能有一个可以在一个地方生成、提取、调整和应用颜色的工具。 **功能：** - 调色板生成器，支持锁定/解锁、拖放排序和和谐调整 - 对比度检查和可访问性提示 - 图像颜色提取（上传图像 → 获取调色板 → 制作拼贴） - 实际 UI 预览，以便在组件/布局中测试你的调色板 - 探索页面，展示社区调色板 - 导出为 CSS、Tailwind 或 PNG **我为什么要制作这个工具：** 最初我是为了自己而制作的，但在收到一些反馈和来自多个子版块的调侃后，我改善了用户界面并添加了更多实用工具。 **希望获得的反馈：** - 用户体验是否直观？ - 开发工作流程中还有什么缺失的？ - 在生成器或图像提取器中是否存在性能问题？ 我很乐意回答任何问题或深入讨论技术栈（Next.js、TypeScript、Tailwind、Prisma、tRPC）。 感谢你们的关注！ — Mustafa