📰 AI 资讯

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

2026-07-06 15:46

过去三年，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 时发生的那些坏事情里了。以下是原文：<h2 data-type="heading" data-id="heading0">Python 工具链需要一场“Rust 革命”</h2>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%的类型检查器几乎毫无用处，包管理器也一样，这些工具必须做到足够完整才能产生价值。所以，能够迭代式地交付、同时保持对用户有用，是建立工具势能的核心能力之一。<h2 data-type="heading" data-id="heading1">开发者营销“10 秒法则”</h2>Ryan：那篇博客发出去后，反响怎么样？Charlie：博客发出去后上了 Hacker News 首页，在 Twitter 上也被大量转发，制造了相当多的兴奋和关注。上 Hacker News 首页这件事，我觉得一半靠运气，一半靠实力。它有帮助，但不是成功的必要条件，更不是保证，关键是你如何利用这波流量。我当时采取的策略是极度积极地响应社区。有人提 issue，我会尽量在一天之内确认问题、修复并发布新版本。这种“一天内响应-修复-发布”的循环非常强大，你每完成一次，就赢得一个支持者，项目势能就增加一分。同时，一些生态里的大人物也开始关注这个项目，比如 FastAPI 的作者 Sebastián Ramírez。他早期就说“这个挺有意思，我想用用”。我当时就问自己：“要让他真正用起来，需要做些什么？”然后我就去逐一实现那些条件。我其实一直在思考开发者营销这件事。在工程师圈子里，“营销”这个词几乎是个脏话。很多人觉得技术产品就该靠实力说话，最好的技术方案就应该自动胜出。但我有个可能很蠢的假设：GitHub 上有成千上万个非常棒的项目，它们根本不知道怎么营销自己，所以永远没人发现，永远没发展起来。我不知道这是不是真的，但至少看 Ruff 这个项目，我觉得营销是值得认真对待的。那么，具体怎么做呢？关键在于“10 秒内抓住注意力”。无论是写博客、写 README，还是做任何宣传材料，核心问题是：当一个人打开这个页面，我只有 10 秒钟让他对我的项目产生兴趣，让他明白“这对我有什么用”。不需要一堆 emoji 和截图，你需要的是在 10 秒内讲清楚“为什么这个项目值得你花时间”。说起来有点沮丧，但这就是注意力经济的现实。我当年在 Spring 做生物医药的机器学习时，研究过 OpenAI 的博客。特别是 DALL-E 的那些老文章，即使你一个字都不读，光看图片和标题，你也能理解他们做了什么，而且会被震撼到。这就是我追求的：让那些只读标题、只看第一张图的人也能带走一个印象。当然也会有人从头读到尾，所以每个字都要精心打磨。但你必须接受：大多数读者只会扫一眼。所以，你要想清楚：如何用诚实、真诚的方式，在几秒钟内告诉别人“为什么你应该关心这个”。Ryan：能举个具体的例子吗？比如你在 Ruff 的博客里具体做了什么？Charlie：最典型的例子是那张 benchmark 图。我们在博客里放了一张非常清晰的性能对比图，在 Twitter 上被疯狂转发。那张图本身就能说明一切，它不需要任何文字解释，你一看就知道 Ruff 比竞争对手快多少。一张好的 benchmark 图，在注意力经济里是无价的。我不是说它能卖钱，而是说它能瞬间抓住人们的注意力。你看到那张图，脑子里立刻就会冒出一个念头：“这太明显了，发生了什么一目了然。”Ryan：但我经常看到那种图，轴的起点不是零，而是故意从 50 或 100 开始。Charlie：这就是所谓的“图表犯罪”（chart crime），我们不会这样。benchmark 本身其实非常复杂且充满争议，也许大多数用户根本看不到这些争议，但我每天都身处其中，因为性能优化这件事太微妙了。你不得不思考：是带缓存还是不带缓存？这两种情况下的性能表现天差地别。在不同的项目上运行，性能特征也会完全不同。我们在 UV 上就深有体会，有时候 UV 快得像闪电，但有时候安装一个包时，瓶颈却出在一个完全不相干的 C++编译流程上。这时候你怎么准确地说“UV 快”？你几乎不可能用一个数字或一张图，准确捕捉所有不同场景下的真实表现。但另一方面，如果你完全不向用户传达性能差异的意义，那又是一种失职。用户需要知道：这个工具到底快多少？为什么快？这对他意味着什么？所以你必须在这两者之间找到平衡。我觉得这其实非常难，很多人在这方面都栽过跟头。但无论如何，不加任何方式去快速告诉用户“这东西用起来是什么感觉”，那才是最大的失职。<h2 data-type="heading" data-id="heading2">为什么选择 Rust？</h2>Ryan：你提到那张图，我作为工程师，看到它的第一反应是：“你是怎么做到这么快的？”然后我注意到你们的标语里写着“用 Rust 写的 Python 开发工具”。所以，我第一个好奇的问题是：为什么选择 Rust？它的优点和缺点分别是什么？Charlie：坦白地说，我当初选择 Rust 很大程度上就是因为跟风（hype）。当时 Rust 在开发者社区里非常火，大家都在谈论它。在那个时候，我对不同生态系统之间的技术权衡了解得并不多，也没有做过太多系统编程。我的印象就是：Rust 是一种编写高性能软件的、更易上手的方式，所以我因为这个原因开始了。但回过头来看，我认为这是一个极其正确的决定。现在我对 Rust 有了更多的经验，我确实觉得，如果当时我尝试用 C 或 C++来写这个项目，我可能早就放弃了。因为即使到现在，我仍然觉得那些生态系统更令人望而生畏、更难上手、更难学习。我经常觉得，Rust 一个被严重低估的优势就是它的工具链。因为你一上来就用 Cargo，所有事情都通过它来做。如果我看到一个我们使用的 crate，我想给它的仓库提交一个 PR，我极其有信心，我克隆下来就能弄清楚如何运行和构建，几乎不需要做任何额外工作。能做到“git clone然后cargo run、cargo build、cargo test”就能跑起来，这其实非常了不起。尤其对于像我这样刚接触系统编程的人来说，我不想去搞清楚整个 C++工具链、构建系统那一堆乱七八糟的东西。Rust 在这些方面非常“有主见”（opinionated），确实有很多东西很难学，但它让我可以把精力集中在那些真正应该难学的事情上，而不是花时间在“我怎么让这个东西编译通过、跑起来”这种你根本不想花时间的事情上。这对我们来说是一个非常成功的赌注。Rust 随着项目规模的增长，扩展性非常好。而且，OpenAI 也在大量使用 Rust。作为一个为开发者构建工具的人，我对 Rust 非常看好。它已经增长得非常迅猛，我认为它还会继续快速增长。但同时，我从来不是一个对生态系统特别教条的人，我认为所有这些生态系统都有可取之处。比如 Zig 正在发生的事情就非常有趣，我希望有更多时间去深入研究它，形成更细致的观点，我确信它在某些方面比 Rust 做得更好，Rust 也应该向它学习。同样，很多人用 Go 也取得了巨大的成功，这也很棒。我喜欢用 Rust，不过也有不少抱怨，但我把这些抱怨看作是需要改进的地方，尤其是随着 LLM 改变了我们构建软件的方式。Ryan：所以听起来，你今天根本不会考虑 C 和 C++？因为它们的工具链不够好。而 Zig、Rust 和 Go，你是在它们之间做不同的权衡？Charlie：没错。我真的不太理解，除非有非常特定的技术原因，或者你正在维护现有软件，否则我基本不明白为什么要在新项目里用 C 或 C++，我本人肯定不会这么做。当然，如果你对那个生态系统非常熟悉，那另当别论。但如果你是一个想学系统编程的新手，或者你对这些语言同样熟悉，那我真的不理解你为什么要选 C/C++。我知道这么说会被骂，但我无所谓。我现在非常在意 Rust 给我的那些东西，而这些是我以前根本不在乎的，比如内存安全。当我开始做 Ruff 的时候，我甚至不知道内存安全是什么，也完全不在乎。但现在我觉得这简直太棒了。我想构建安全的东西，不会在用户面前崩溃，速度极快，性能极强，不需要做任何妥协。在 Rust 里我可以做到这些，所以对我来说，它虽然不是完美的语言，但它是目前我最喜欢用的语言。<h2 data-type="heading" data-id="heading3">AI 时代的代码重写</h2>Ryan：在当今世界，你几乎可以把现有代码完全转译到你选择的任何语言里，比如我见过有人把 Zig 一次性转成 Rust。如果你觉得另一种语言更好，你会考虑把你构建的那些开发工具全部重写吗？比如从 Rust 转成 Zig 或 Go？Charlie：这个问题很微妙，是因为现在构建软件的方式变化太快了。我直到去年圣诞假期才开始真正用 Agent 编程，到现在也不过几个月。但如今我几乎不在编辑器里直接改代码了，所有修改都通过 Codex 完成，即使是小改动也是用提示词驱动。这完全是另一种工作方式，而且变化发生得如此之快，我甚至无法预测六个月后会是怎样。所以对于 Bun 那样的重写，我现在不会做，但

🔗 查看原文 ↗

← 返回资讯列表