“我一行代码都没读就发布了”，被OpenAI收购后，uv工具创始人开始反思AI编程

过去三年，Python 开发者工具领域发生了一场静悄悄的革命。一个叫 Charlie Marsh 的年轻工程师，从一家计算生物学公司辞职后，在“不知道自己要做什么”的状态下，花了 9 天时间搭出了 Ruff 的原型，一个比当时最快的 Python linter 还要快 10 到 100 倍的代码检查工具。Ruff 成功后，他顺势成立了 Astral 公司，并用 Rust 打造了 uv，一个快到让 pip 看起来像慢动作回放的包管理器。这两个项目迅速席卷了 Python 社区，GitHub 星标数以万计增长，最终让他在今年三月把整家公司卖给了 OpenAI。 这不仅仅是一个“技术天才靠 Rust 征服世界”的故事。日前，Charlie Marsh 在播客中，与主持人 Ryan Peterman 一起探讨了 AI Agent 如何重塑软件工程的每一个环节。除了技术本身，他还谈到了软件工程行业正在集体经历的困惑：当提交一个”看起来合理”的 PR 的成本降到零、而审查它的成本依然高昂，我们该信任什么？当你自己写代码的乐趣被”指挥 Agent 干活+逐行审查 Agent 输出”的工作流取代，编程还值得热爱吗？ 这些问题没有标准答案，不过 Charlie Marsh 给出了一个一线实践者最诚实的思考。最近 X 上流行"I read the code"梗，调侃程序员已从"写代码"沦为"读代码"。Charlie 在给自己用的工具上反着来——一行代码没读，全扔给 AI。不过，他坦陈了自己从“全 AI 模式”中被同事打醒的经历，也去看了Bun的仓库——头号贡献者是一个bot，他发现Bun的仓库跟他们的仓库是完全不同的世界。他还分享了团队对抗 AI slop 的具体策略，也聊到了从普通工程师转向创业的经历、以及为什么他觉得”现在是早期职业工程师最难的时刻”。本文基于该播客视频整理，经 InfoQ 编辑。 太长不读版： Q：Python 工具链为什么该被颠覆？ A： 隔壁 JS 圈早把工具用 Go/Rust 重写了，快到飞起。Python 圈还在用 Python 写工具，慢得理所当然。我就想问：凭啥我们不能拥有同样爽的东西？ Q：Ruff 是怎么火起来的？ A： 先写博客画大饼，然后构建出能用的 linter。核心策略：10 秒抓住眼球——一个亮眼的标题、一张精心打磨的图片，不用废话，一看就懂。然后疯狂响应社区，今天提 issue 明天发修复，圈粉速度拉满。 Q：为啥选 Rust？ A： 坦白说，当初就是跟风。但回头看香爆了——Cargo 一把梭，git clone 完就能跑，不用跟 C++ 那堆构建系统斗智斗勇。内存安全？当初根本不在乎，现在觉得真香。 Q：AI 时代还会考虑全部重写吗？ A： 不会。代码如果完全重写，作为人类你可能就不再理解任何代码了。而且用已知问题换未知问题太蠢，测试全过不代表行为一致，最终坑的是用户。而且现在 AI 写 PR 成本为零，审查成本却更高，开源生态快被淹死了。 Q：性能提升全怪 Rust？ A： Rust 给你个高起点，但真正的杀手锏是架构创新。UV 快是因为缓存设计得聪明，重复安装几乎零成本，这跟语言没关系，纯属脑子好用。 Q：跟 AI 结对编程啥感觉？ A： 以前同事闭眼合我 PR，现在逐行细审——因为代码不是我的了，是 Agent 的。信任崩塌了。但我也在适应，现在整天让 AI 跑各种实验，以前不敢想的问题随手就能验证，这种解锁感挺爽的。 Q：初级工程师会被 AI 坑惨吗？ A： 会。他们没能力给 AI 当教练，只能被 AI 带沟里去。我们倾向于招资深工程师，因为优秀的工程师用 AI 更猛。如果我是初期工程师，太容易掉进使用 Agent 时发生的那些坏事情里了。 以下是原文： Python 工具链需要一场“Rust 革命” Ryan：你最初开始构建这些开发工具时，整个领域是什么样子的？为什么你觉得它能做得更好？ Charlie：在创办 Astral 之前，我在一家计算生物学公司工作。我没有生物学和机器学习背景，但我的任务是用 Python 搭建所有支持机器学习运行的软件系统。那段时间我一边学 Python，一边接触了 Go 和 Rust，在多个不同的技术栈之间来回切换。 我们团队很小，但对一个只有几个软件工程师的团队来说，代码库规模相对较大。我们这些人要服务整个团队，包括机器学习研究员和科学家。我接触了各种生态系统的工具链，发现我们一直在试图从工具中榨取更多效率，无论是类型检查器、代码检查工具，还是包管理器，但随着规模增长，我们不断撞上工具能力的天花板。 我观察了一遍 Python 生态，发现它缺少其他生态中那种实验精神。比如 Web 生态里，很多疯狂的想法在被尝试，而且大家对性能有很强的执念。从用 Go 写的 ESBuild，到用 Rust 写的 SWC，再到 Bun、Deno 等等，原生工具链对于 JavaScript 来说已经成了理所当然的事情，尤其是当应用越来越大、开发者机器上跑的活儿越来越多的时候。 但 Python 生态里没有这个趋势。所以对我来说，核心问题就是：为什么我们不能拥有同样的东西？我亲眼看到 Web 领域发生的一切，我自己也写过 Rust 和 Go，知道这些不同工具链的工作方式和用户体验。再看 Python，工具集更小，很多来自其他生态的有趣想法完全没被引入，而且所有工具都是 Python 写的。 这对我来说就是一个有趣的假设。当我发布 Ruff 时，那篇博客的标题就是《Python 工具链可以快得多得多》。对我来说，这本质上就是一个待验证的假设：Python 工具链能不能更快？ 我搭了一个原型，结果证明：是的，完全可以。 Ryan：你写了一篇关于 myPy 性能分析的文章，然后仅仅 9 天后就发布了那篇“可以快得多”的博客。你是在那 9 天里做出来概念验证的吗？ Charlie：对。我先写了一篇关于大规模类型检查的博客，想搞清楚瓶颈到底在哪。然后我开始构建一个 linter，因为我觉得 linter 比类型检查器容易得多，而且 linter 能让我用更小的体量验证同样的想法。做创业或做工具，核心就是尽快把东西交到用户手上，让他们真正用起来，证明价值，同时也能快速迭代。linter 恰好是个完美的形态：核心逻辑很简单，但规则可以无限扩展。用户从一个小核心加若干规则就能立刻获得价值。 我们很快做出了可用的版本，然后持续迭代，发布更多规则和功能。人们可以把它和其他工具配合使用。它从一开始就是有用的，这一点非常关键。相比之下，一个完成了 75%的类型检查器几乎毫无用处，包管理器也一样，这些工具必须做到足够完整才能产生价值。所以，能够迭代式地交付、同时保持对用户有用，是建立工具势能的核心能力之一。 开发者营销“10 秒法则” Ryan：那篇博客发出去后，反响怎么样？ Charlie：博客发出去后上了 Hacker News 首页，在 Twitter 上也被大量转发，制造了相当多的兴奋和关注。上 Hacker News 首页这件事，我觉得一半靠运气，一半靠实力。它有帮助，但不是成功的必要条件，更不是保证，关键是你如何利用这波流量。 我当时采取的策略是极度积