一周热榜

我开发了 depup，一个命令行工具，用于扫描 Python 依赖项、检查 PyPI 版本、分类升级影响，并支持 CI 工作流程。 文档：<a href="https:&#x2F;&#x2F;saran-damm.github.io&#x2F;depup&#x2F;" rel="nofollow">https:&#x2F;&#x2F;saran-damm.github.io&#x2F;depup&#x2F;</a> 代码库：<a href="https:&#x2F;&#x2F;github.com&#x2F;saran-damm&#x2F;depup&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;saran-damm&#x2F;depup&#x2F;</a>

Tambourine 是一个开源的、完全可定制的语音听写系统，它允许你控制 STT/ASR、LLM 格式化和提示，以便将干净的文本插入到任何应用程序中。 我已经在业余时间构建这个系统几周了。 促使我构建它的原因是，我想要一个可定制的 Wispr Flow 版本，在那里我可以完全控制模型的行为、格式化和系统的运作方式，而不是依赖于一个黑盒。 Tambourine 直接构建在 Pipecat 之上，并依赖于其模块化的语音代理框架。 后端是一个本地 Python 服务器，它使用 Pipecat 将 STT 和 LLM 模型拼接成一个单一的管道。 这种模块化使得交换提供商、试验不同的设置以及对语音 AI 进行细粒度控制变得容易。 我与朋友分享了一个早期版本，最近还在我当地的 Claude Code 聚会上进行了展示。 反响非常积极，这鼓励我更广泛地分享它。 桌面应用程序是用 Tauri 构建的。 前端用 TypeScript 编写，而 Tauri 层使用 Rust 来处理底层系统集成。 这使得全局热键的注册、音频设备的管理以及在 Windows 和 macOS 上光标处的可靠文本输入成为可能。 从高层次来看，Tambourine 为你提供了一个跨操作系统的通用语音界面。 你按下全局热键，说话，格式化后的文本就会直接在你的光标处输入。 它适用于电子邮件、文档、聊天应用程序、代码编辑器和终端。 在幕后，音频通过 WebRTC 从 TypeScript 前端流式传输到 Python 服务器。 服务器使用可配置的 STT 提供商进行实时转录，然后将转录文本传递给 LLM，LLM 会删除填充词、添加标点符号，并应用自定义格式化规则和个人词典。 STT 和 LLM 提供商以及提示可以在不重启应用程序的情况下切换。 该项目仍在积极开发中。 我正在处理边缘情况并完善用户体验，并且可能会有重大更改，但大多数核心功能已经运行良好，并已成为我日常工作流程的一部分。 我非常感谢反馈，特别是来自任何对语音作为界面未来感兴趣的人。

PhotoToVideoAI 是一款由人工智能驱动的工具，可以将您的照片转化为动态视频。上传一张照片和一个提示词，大约 30 秒后，您将获得一个高质量的视频，分辨率高达 1080p，时长为 5 或 10 秒。该工具专为内容创作者、市场营销人员和摄影师设计。欢迎提供反馈！

我对大家使用代码审查（PR review）的体验很感兴趣，包括人工审查和自动化审查。 对于使用过 PR 审查工具或机器人的人： * 你们觉得哪些功能真正有帮助？ * 哪些功能最终变得令人讨厌或适得其反？ * 你们在什么时候开始不再关注反馈意见？ 我特别想了解大家是如何在审查中平衡“有效信息”和“噪音”的，以及摘要、行内注释或选择性深度审查哪种方式在实践中效果更好。 我只是想了解真实的使用模式和痛点，而不是为了推广任何东西。 欢迎大家分享经验。

以下是我们创业公司使用 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 切换上下文时存在摩擦，但这可以管理。 你们在生产系统中如何进行氛围编码？