他用 Rust 重寫了 Python 的半壁江山，卻在智能體時代感到窒息。

編譯 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

剛被 OpenAI 用數億美元買下公司的查理·馬什（Charlie Marsh），最近在一個技術播客里，聊了聊他自己寫代碼時的焦慮。

查理是 Python 極速工具鏈 Astral（旗下有 Ruff、uv）的創始人，現在并入了 OpenAI 的智能體（Codex）團隊。作為寫出過最硬核開源工具的頂級工程師，他坦言自己現在已經很久不在編輯器里親手寫代碼了，全靠提示詞讓 AI 幫他干活。

但這帶來了一個很尷尬的代價——組里的成員直接對大老板說：“查理，以前你提交 PR，我們掃一眼就敢過；現在我們必須打起十二分精神盯著，因為這代碼是你用 AI 自動生成的。”

這種對效率和工具的折騰，貫穿了查理的創業史。在創辦 Astral 之前，他只是一家生物公司的普通工程師，因為受夠了原版 Python 工具的緩慢，動了自學系統編程的念頭。他坦言，當時選 Rust 語言幾乎完全是因為“跟風”（Hype），他甚至連什么是內存安全都不懂。但靠著極簡的邏輯和對極致速度的執念，他寫出的極速分析工具在 Hacker News 上一炮而紅。

今年被 OpenAI 收購，其實也是因為大模型正在走向實體工程和智能體，OpenAI 極度需要他們團隊在編譯器和極速工具鏈上的物理工程積累，來撐起大模型寫代碼的底層邏輯。

在這場與 The Peterman Pod 主持人 Ryan Peterman 的對話中，查理聊到了一個工程師在智能體時代的真實困境：比如自動重寫代碼庫背后隱藏的未知崩潰風險，以及營銷能力對一個開源項目的生死影響。在他看來，當 AI 批量生產代碼的時候，程序員的工作重心必須發生根本性的轉變。以下是查理基于一線的開發體驗，分享的幾個極其真實的行業細節：

• AI 讓提交 PR 的門檻降到了零，但人類審核的成本卻一點沒少。以前新人向開源項目提交代碼，是一個“收到反饋、糾錯、下一次寫得更好”的個人成長過程。但現在，任何人都能用 AI 在兩秒鐘內生成一個看起來能跑的合并請求。維護者需要花一個小時去人工排錯，而提交者并沒有從中學到任何東西，這正在破壞開源社區最健康的成長契約。

• 用 AI 自動重構整個代碼庫，是在拿已知的 Bug 去賭未知的崩潰。雖然大模型能把一個龐大的代碼庫自動重寫成另一種語言（比如 Bun 從 Zig 轉向 Rust），甚至通過所有測試。但測試套件永遠只能證明代碼在特定情況下的正確。自動重寫極易改變那些未被測試覆蓋的“隱性代碼行為”（Hyrum 定律），最后把未知的 Bug 直接甩給真實的用戶。

• 成千上萬個驚艷的開源項目，因為不懂營銷而爛在了 GitHub 的角落里。很多程序員傲慢地覺得“只要代碼寫得好，自然會有人用”。但現實是，這是一個注意力極度稀缺的時代，你只有 10 秒鐘時間在 Readme 頁面吸引讀者的興趣。不會做“開發者營銷（Developer Marketing）”的優秀工具，注定無法被世界發現。

領取地址：https://s.csdn.cn/4nPsOp

為什么 Python 工具鏈不能像 JS 那樣快？

主持人：你剛開始做這些開發工具的時候，那個領域是什么樣的？你為什么會覺得它本來可以做得更好？

Charlie Marsh：在創辦 Astral 之前，我在一家計算生物學公司工作，當時我是第二位工程師。我沒有生物學背景，也沒有機器學習背景，所以我負責搭建做機器學習所需的各種軟件系統。當時那一套基本全是 Python，所以我也是在那個過程中學習 Python。

后來我們也用了 Go 和 Rust。所以我其實橫跨過很多不同的生態系統。我覺得，那個時候在 Python 這邊，我們作為一個小團隊，想做很多事情。我們的代碼庫——當然不能和那些超大型代碼庫相比——但相對來說已經算挺大了，而真正負責寫軟件、支撐整個團隊的工程師，其實只有我們幾個人。團隊里的其他人可能是機器學習研究員，也可能是科學家。

所以我等于是在很多不同生態里都待過，見過很多工具，而當時我又正在做 Python。我們一直都在努力從工具中榨取盡可能多的杠桿效應，不管是類型檢查器、linter，還是包管理器。隨著項目規模變大，我們團隊又很小，我們就希望能有非常好的靜態分析、非常好的工具鏈，但在這個過程中我們總是不斷碰到各種限制。

我覺得，某種程度上，我當時看 Python 生態，會覺得它不像其他生態那樣有那么多實驗性的東西，尤其不像 Web 生態。那邊當時有很多看起來相當瘋狂的事情在發生，而且大家對性能也更加重視。最開始是 ESBuild，用 Go 寫的；接著有 SWC、Rust，然后又有 Bun、Deno，還有一大堆后來出現的工具。于是，“JavaScript 可以擁有原生工具鏈”這個想法就越來越被接受了，尤其是當應用越來越大、大家在本機上做的事情越來越多之后。

但這種事情在 Python 世界里并沒有真正發生。所以對我來說，核心問題其實就是：為什么 Python 不行？因為我看到了 Web 世界里發生的這些事，也寫過一些 Rust、寫過一些 Go，知道這些工具鏈是怎么工作的，也知道它們在用戶體驗層面大體上是什么樣。

然后再回頭看 Python，就會覺得它的工具更少，很多別的生態中很有意思的想法，在這里都沒有體現出來。而且那些工具幾乎全都是用 Python 本身寫的。所以對我來說，這就是一個很有意思的問題。

這幾乎是我開始做這件事時最先問自己的問題。Ruff 剛發布的時候，我博客文章的標題大概是《Python 工具鏈本來可以快得多得多》。對我來說，這其實更像是一個假設：Python 工具鏈能不能快很多？后來我做了一個原型，而那個原型給出的答案是：可以，我覺得完全可以。

主持人：你當時寫過一篇文章，算是在研究 MyPy，或者說發布你基于 MyPy 的一些結果。而那篇文章的發布日期——大概九天之后——你就發了你剛才提到的那篇文章，說 Python 工具可以快得多。

Charlie Marsh：這就挺有意思的。我之前都沒意識到這兩件事離得這么近。

主持人：那個概念驗證就是在那九天里做出來的嗎？

Charlie Marsh：對。我當時寫那篇博客，主要是在講“大規模類型檢查”，因為我在想：有哪些是我學到但別人很少寫出來的東西？然后我決定先做一個 linter，因為我覺得這會容易很多。我現在仍然這么認為：它確實比做類型檢查器要容易得多。我們現在也在做類型檢查器，也已經有類型檢查器了，所以我可以明確地說，做類型檢查器難多了。

但我先做 linter，是因為我覺得它能以一個更小的形態，驗證很多相同的想法。無論是做創業公司，還是做一個工具，你都希望盡快把某個真正能讓人上手使用、而且能證明其價值的東西交到用戶手里；同時你也希望它能支持你快速迭代。

結果很奇怪，linter 最后反而成了一個近乎完美的產品形態。它的核心很簡單，但規則可以有非常非常多，對吧？所以它在很多維度上都具有可擴展性，而用戶又能通過一個小核心加上一些規則，很快獲得價值。

所以我們很快就把東西發出去了，然后不斷迭代、增加更多規則和更多功能。用戶還能把它和其他工具一起配合使用。它幾乎是立刻就有用了，我覺得這一點特別重要。相比之下，像類型檢查器就是個很好的反例：一個只完成了 75% 的類型檢查器，其實沒什么太大用處。包管理器也是一樣。

這些東西往往必須——當然，我也不想把這話說得太絕對，很多情況是可以挑戰這種說法的——但重點在于，像這類產品更難以“持續可用”的方式迭代發布。可我認為，恰恰是這種能力，才是真正建立勢能的關鍵屬性之一，不管你做的是工具還是別的什么。

主持人：你發出那篇文章之后，反響怎么樣？

Charlie Marsh：那篇博客本身，我發出來之后上了 Hacker News，也在 Twitter 上被很多人轉發，整體上確實激起了不少興奮和興趣。

這種事——尤其是登上 Hacker News 首頁——我其實有很多想法。它當然有一部分是運氣，一部分是能力。它確實有幫助，但也絕不是成功的必要條件。反過來說，就算你上了 Hacker News 首頁，也不代表你就一定會成功。能上當然很好，但這件事里隨機性非常大。

不過我確實覺得有幾點挺重要。第一，這件事發生之后，開始有一些人真的注意到這個項目了。于是我就非常努力地去接住這波關注，盡量保持高度參與。比如有人提 issue，我就會非常積極地爭取盡快確認問題、盡快修復、盡快發版本。如果你能在一天之內完成這個閉環，它會是一個非常、非常強大的反饋循環。別的小伙伴會成為你的支持者，也會給項目帶來更多勢能。

另外，生態里也有一些比較有影響力的人開始注意到這個項目，比如 Sebastian Ramirez——他做了 FastAPI 以及很多別的東西。他后來也一直是我們項目非常好的支持者。早期的時候他就會說：“哦，這個挺有意思，我想試試看。” 然后我基本上會反問自己：那要做到什么程度，他才會真正用它？然后我就努力把那些事情都做到。所以我們確實盡量去放大這波勢能。

但我還會想到另一件事：我確實經常思考“開發者營銷”這件事。這個詞多少有點像個臟詞，或者說聽起來不那么體面。我覺得很多工程師都希望，技術產品和工具只憑自身實力勝出。好像最好的技術方案就應該自然勝出、自然增長。

但我其實有一個有點傻的假設：GitHub 上可能有成千上萬個非常驚艷的項目，它們只是根本不知道怎么營銷自己，于是從來沒被發現，也從來沒真正走出去。我也不確定這是不是事實，但我對很多技術工作就是有這種感覺。

所以當我想一篇博客該寫什么，或者 README 里該寫什么時，我的想法并不是堆一百萬個 emoji，也不是塞一百萬張截圖。真正重要的是：好，一個人要落到這個頁面上了，而我大概只有 10 秒鐘時間讓他對我在做的事情產生興趣，并且幫助他理解，為什么這件事和他有關、為什么它有用。所以這幾乎成了我做任何事情時都會帶進去的核心想法。

當然，這多少有點讓人沮喪，因為這意味著：好吧，我可能只有 10 秒——但事實就是，人們真的沒有太多注意力。這就是注意力經濟，對吧？博客也是一樣。說來也巧，我以前在 Spring 做生物機器學習的時候，我們也想發布一些內容來解釋我們在做什么。我們有很多很有意思的洞見，于是會去看 OpenAI 的博客文章，尤其是 DALL·E 的那些早期文章。我們當時會想：哇，這真是非常厲害的博客，因為哪怕你一行正文都不看，你也能明白他們做了什么，而且你還是會覺得很震撼。哪怕一個人只是隨便點進那個頁面，他離開時也會帶著一種印象，帶著一些理解。我當時就覺得：哇，這真的太厲害了。

所以現在我寫博客時，也會想：如果有人只是落到這個頁面上，我必須做好準備，因為絕大多數人可能只會看 TL;DR，或者看第一張圖，或者只讀標題。當然，也會有人把全文讀完。所以我當然應該很認真地打磨每一個字、每一句話，但大多數人其實幾乎什么都不會讀。

所以，再次抱歉，這聽起來有點讓人沮喪。但我確實覺得，認真考慮你的受眾、思考你該如何真誠而誠實地告訴他們：為什么他們應該在意你做的這件事，這很值得。不是誤導，不是騙術，而是你必須認真思考，怎樣才能在非常短的時間內，把“為什么這件事重要”傳達給別人。

主持人：能舉個你自己的例子嗎？

Charlie Marsh：我覺得就 Ruff 來說，我們在博客里放了一張非常好的 benchmark 圖，那張圖后來也在 Twitter 上傳播開了。基本上，那張圖可以說是無價的——抱歉，我不是說金錢意義上的無價，我的意思是在“吸引注意力”這件事上，它幾乎無可替代。因為人一看就明白：哦，這里發生了什么非常清楚。

我覺得 benchmark 圖非常有力量。當然，所有 benchmark 從某種意義上說都不完美，也都會有誤差，所以關于這個還有很多可說的。但我確實覺得，如果你能有一個視覺上的“鉤子”，讓人迅速明白為什么該在意這件事、它到底是什么，再加上一句非常有力的標語——我們當時的核心就是說：我們會兼容你現有的東西，而且速度快得多，這幾乎就是全部了。

然后你再往下推：好，如果它兼容、而且快很多，那為什么你該在意？因為它可能快上幾個數量級，而且還能給你一樣的體驗。你要盡可能快地把這件事傳達出去，對吧？

主持人：甚至連那篇博客的標題，《Python tooling could be much faster》，本身都挺有挑釁意味的。

Charlie Marsh：對。不過我其實一直挺反對標題黨，或者任何帶誤導性的表達。你真正想做的，是盡可能有效地把最有意思的部分傳達給別人，前提是，這些內容必須是你自己相信的、真實的、真誠的。

你當然可以胡吹一通，發一些非常刺激眼球、很有煽動性的東西，但我不知道。對我來說，那簡直就是一場必輸的仗。我根本不明白自己為什么要那么做。

主持人：你怎么看另一個問題——比如你們有那張圖，但我也經常看到一種情況：圖表的坐標軸不是從零開始的。

Charlie Marsh：哦，對。

主持人：所以整個范圍其實只是在 50 到——

Charlie Marsh：圖表犯罪。對，圖表犯罪。我不會那樣做。

不過我確實認為，benchmark 本身是一個很復雜、也很容易引發爭議的話題。也許大多數人根本感受不到這種爭議，但我感受得到，因為性能這件事本來就很細膩。你得考慮很多東西，比如有緩存和沒緩存，這兩種情況差別就非常大。又比如，你在哪個項目上跑，性能特征也會完全不同。

我們在 UV 上就深有體會。這件事特別難，因為有時候 UV 會非常快，但有時候你的包安裝過程真正的瓶頸，其實是某個完全發生在它之外的 C++ 構建。那你就會想：好，那我該怎樣準確地覆蓋所有這些不同場景？而答案往往是：根本不可能準確覆蓋所有場景。

但與此同時，如果你完全不去嘗試向用戶傳達性能的重要性，或者不去真實地呈現“性能差異看起來會是什么樣”“為什么它重要”，那也是對用戶的不負責。所以你必須在兩者之間取得平衡，而我覺得這其實很難。很多人都會把這件事做錯。也許我們自己也錯過幾次，我愿意接受這一點。

但我確實覺得，這比人們想象的要復雜得多。而且我也認為，如果你不提供某種方式，幫助用戶迅速感知一件東西“用起來是什么感覺”，那同樣是一種很大的失職。

選 Rust 的最誠實原因：因為當時它最紅

主持人：我最感興趣的一點之一是——你提到了那張圖。我看到那張圖時，作為工程師的第一反應是：你們到底是怎么把它做得這么快的？你們的標語里有一句是“用 Rust 編寫的 Python 開發工具”。所以我第一個很好奇的問題就是：為什么你會選擇 Rust？它的優缺點又是什么？

Charlie Marsh：老實說，當時我之所以給那個項目選 Rust，很大程度上是因為“熱度”。那時候我其實并沒有對這些不同生態之間的技術取舍有多深入的理解，而且我也沒真正做過很多系統編程。

所以，這是最誠實的答案。我是在很多地方都看到 Rust，它發展很快，大家都說它是寫高性能軟件的一種相對容易上手的方式。所以我就是因為這個開始的。

回過頭看，我覺得那真是一個非常棒的決定，我絕對不會改，而且我認為它就是我們這類產品最好的選擇。現在我也積累了更多 Rust 編程經驗。

但這件事也挺有意思的，因為我有時候會想：如果我當初嘗試用 C 或 C++ 來寫這個東西，我大概很可能中途就放棄了。因為哪怕到現在，我依然覺得那兩個生態更讓人望而生畏，更難接近，也更難學。我常常覺得，Rust 一個很大的、但經常被低估的優勢，其實就是工具鏈本身。因為你一進來就用 Cargo，而 Cargo 幾乎就是你做所有事情的方式。

如果外面有個我們依賴的 crate，而我可能想給它提個 PR，我會非常有信心：我把它 clone 下來之后，幾乎不用額外折騰，就能搞明白怎么運行、怎么構建。你只要 clone，然后跑cargo run、cargo build或cargo test就行，這真的很了不起。

尤其像我這種當時剛接觸系統編程的人，我根本不想先去搞明白整套 C++ 工具鏈、構建系統，以及各種亂七八糟的東西。而 Rust 在這些方面是帶有明確意見的。于是很多東西雖然學起來仍然很難，但我至少可以把時間花在那些“本來就應該難”的地方，而不是浪費在那些你根本不該花時間的地方，比如“怎么才能把這玩意兒編起來、跑起來”之類的問題。

我覺得，對我們來說 Rust 一直是一筆非常好的下注。它隨著項目擴張也擴展得非常好。我的意思是，OpenAI 現在也大量使用 Rust，而且在非常堅定地押注 Rust。至于我自己，作為一個做開發工具的人，或者說試圖為“造軟件的人”去造軟件的人，我對 Rust 是非常看好的。它的增長非常快，而且我覺得它還會繼續大幅增長。

與此同時，就像我一開始說的，我從來不是那種對生態系統特別教條的人。我覺得每個生態都有很多可取之處。我也覺得 Zig 正在發生的事非常有意思，我只是希望自己有更多時間深入研究它，形成更細致的看法，看看它到底在哪些地方做得比 Rust 更好。我相信一定有一些地方它做得更好，也相信 Rust 也能從那個生態里學到東西。

類似地，也有很多人用 Go 做出了非常成功的東西。我也覺得這很好。我覺得這些都很好。但我真的很喜歡用 Rust。雖然我也會抱怨它的一些問題，但我更愿意把這些抱怨看成：這是我們應該繼續改進的地方，尤其是在 LLM 正在改變我們構建軟件方式的當下。

主持人：所以聽起來你的意思是：如果是今天，C 和 C++ 因為工具鏈不夠好，你不會考慮；但 Zig、Rust 和 Go，則更像是在不同的取舍光譜上。

Charlie Marsh：對。我知道很多人可能不會同意我，但除非有非常具體的技術原因，或者你必須處理現有的軟件資產，否則我確實不太明白，為什么我要從零開始一個全新的 C 或 C++ 項目。

至少從我個人角度來說，我肯定不會。除非那就是你最熟悉的生態，那當然就很合理。但如果我是個剛想學系統編程的新手，或者說我對這些語言的熟悉程度差不多，那我真的不明白自己為什么會選 C 或 C++。我知道這話說出來可能會被很多人噴，但我其實沒那么在乎。

而且現在我確實開始在意 Rust 給我的一些東西，而這些是我以前沒有那么在意的，比如內存安全。說實話，我剛開始做 Ruff 的時候，甚至都不太明白“內存安全”到底是什么，也沒多在乎它。而現在我覺得這件事真的非常棒。

我想造的是安全的東西，不會在用戶手上崩掉、同時又非常快、性能很好，而且基本不需要為了這些目標做妥協。我覺得 Rust 能讓我做到這一點。所以對我來說，我不知道，它有點像一種“接近完美”的語言。當然，它不是完美語言，但它確實是我現在最喜歡使用的語言。

用已知的 Bug，去交換未知的 Bug

主持人：在今天這個時代，幾乎把整個現有代碼庫完整地轉譯或者轉換成你想要的任何語言，這聽起來都不算離譜。比如我記得——好像是在 Bun 那邊——我有點記不清了，好像是從 Zig 到 Rust。

Charlie Marsh：對。

主持人：就是一口氣全做了。如果你后來研究了另一門語言，并覺得它更好，你其實完全可以把現在所有 Rust 代碼再改寫成——我不知道——Zig 或 Go。比如對你已經做出來的這些開發工具來說，你會考慮這么做嗎？

Charlie Marsh：現在真的是一個特別有意思的軟件構建時代，因為一切都在變化。這不是什么新鮮觀點，但變化真的太快了。

其實直到去年圣誕節，也就是大概 12 月假期那會兒，我才開始真正大量用 agent 編程。這其實離現在并不久。我的意思是，我之前也在用 Cursor 之類的東西，但現在我已經很久沒有在編輯器里親手改代碼了。我做的所有事情都通過 Codex 完成，哪怕只是很小的修改，我也是直接寫 prompt。完全不一樣了。而這一切發生也不過是最近的事，對吧？所以六個月之后會是什么樣，我真的不知道，很難說。

我之所以提這個，是因為對于 Bun 做那種重寫——我自己現在不會這么做，但我反而很高興他們在推動這件事。他們在實驗、在拓寬“什么是可能的”的邊界，而且是在面對很多批評的情況下這么做。最后用戶會怎么感受這件事，會很有意思。

我覺得這里面有幾件不同的事。先說為什么不這么做。第一點是：好，可能你最后已經不理解這份代碼了，對吧？如果代碼真的被“徹底重寫”了，那么作為人類，你可能已經看不懂其中的大部分內容了，而這會成為一個大問題。當然，這里也有一些緩解因素，比如他們盡量做得非常直接地“轉譯”——我加引號是因為它不完全等同于翻譯——但他們確實盡量一一對應地去做。這樣至少有希望讓人還保有對各種抽象的理解。

但如果他們本來就已經高度依賴 agent 來開發，那這件事還重要嗎？他們到底需要在多大程度上理解代碼的不同部分？說實話，我并不知道答案，而這正是我說“一切變化太快”的原因之一。現在我真的有點說不清，這種理解到底還重要到什么程度。

如果他們真的把整個代碼庫都轉譯了，那他們還需要在多深的抽象層級上理解系統？這其實是個非常復雜的問題。所以，第一層就是：你到底有多理解這份代碼——這件事本身就已經很讓人困惑了。

第二層是：做這種重寫，本質上是在用已知問題去交換新的未知問題。想象一下，你合并了那個重寫 PR，字面意義上它可能一口氣關掉 GitHub 上 50 個已知 issue。好，這當然很好。但與此同時，你也可能引入了另外 50 個之前根本不存在、而你自己還不知道的新問題。

因為你的測試套件——哪怕是很好的測試套件——本質上也只是程序正確性的一種近似。還有個著名的 Hyrum 定律，大意是：軟件中的任何實現細節，最終都會有人依賴它。具體原話我可能說不準，但核心就是：哪怕某些行為你本來并不打算作為正式行為暴露出去，它們最后也會在事實上變成 API 的一部分，不管你愿不愿意。

這聽起來有點可怕，但意思就是：哪怕你整個測試套件都通過了，程序里仍然很可能有很多被隱式編碼的行為已經改變了。更糟糕的是，這種代價最后往往會被轉嫁到用戶身上。是他們在使用過程中撞上這些問題，然后再來報 bug、再來幫你定位到底哪里出了問題。

所以，這其實才是我對自動化重寫最擔心的地方。說實話，我對模型本身已經足夠信任，到了“如果條件合適，我會考慮讓它們這么做”的程度。但真正更讓我害怕的是：這會對用戶造成什么影響？你要怎么安全地把這樣的改動發布出去？

所以我也不知道。我們目前沒有計劃在自己的項目上這么做，但這個問題確實非常有意思。

另外還有第三點，是我現在也常常會想的，尤其是在當下這個“一切變化都非常快”、而“寫軟件的方式光譜突然變得極寬”的時期——這個比喻可能不太好，但現在做軟件真的有太多不同方法了。從 Andrej Karpathy 所說的那種真正意義上的 vibe coding——也就是“完全別看代碼”——一直到“完全不用 LLM”這種極端，中間其實有非常多不同層次的做法。

而且我現在對不同項目，確實會采取非常不同的策略。比如我上周寫了一個工具，本質上就是個人軟件：一個自定義的 Rust linter，用來幫助我們在項目里強制執行一些我一直想執行、但現有工具不太好表達的規則。那個項目我一行代碼都沒讀，是 GPT-5 整個做完的。

這就意味著，我可以對它采用一種和 UV 完全不同的標準。因為那個項目只有我們自己在用。它對不對，非常容易判斷。不是說要把項目細節講得太深，但我們一眼就知道輸出是否正確，而且也沒有別的用戶。

但 UV 不一樣。它被數百萬工程師和大量公司依賴，所以我們必須非常小心地決定：往里面發布什么、怎么發。可我確實覺得，當前有很大的空間去探索“我們到底怎樣構建軟件”。你只是必須根據項目本身、以及你對用戶承擔的責任，來決定你能把邊界推到哪里。順便說一句，這不是在影射 Bun 做得對不對，只是我自己思考“我們應該在哪些地方試探邊界”的方式。

主持人：聽你這么說，我會想到那個永恒不變的權衡：代碼改動的風險有多高，以及你要用多大力度去驗證它。因為如果風險不高，比如只是一個只有你我在用的內部開發工具——

Charlie Marsh：對。

主持人：那可能你就直接發了，蓋章通過，不用太擔心，反正也不會影響什么。但如果它是會阻塞客戶下單的關鍵系統，那可能就得兩個人一起審，那個區域還會加很多額外檢查。所以我感覺，本質上還是同一條風險光譜，只不過現在光譜上又多了一層“更少的人為介入”——以前至少還是人寫的；現在甚至可以是人根本不碰，直接發，甚至只是蓋個章，可能根本都沒人真正看過，對吧？

Charlie Marsh：對。這個問題我其實有很多反應。

還有一點我想順帶說一下：有時候我會去看他們的倉庫，它和我們的倉庫風格真的非常不一樣，挺有意思的。因為你看一眼就會發現，頭號貢獻者基本上就是那個機器人。有時候你點開一些人類賬號發的 PR，會看到里面是人類賬號在來回對話，但你又很明顯能感覺到，所有評論其實都是 agent 寫的。你就會覺得：哇，這真的非常——

所以我會去看這些東西。但我自己的態度基本上是：好，我很高興有人在嘗試不同的軟件構建方式。我不確定自己現在是否準備好了去那樣做，但我確實認為，未來會有很多事情改變，而這種實驗本身非常有意思。所以我的結論就是：我很高興他們在做實驗。

PR 提交成本降到了零，但審查成本一點沒變

主持人：那如果有人在你們的倉庫里，直接提交整段由 agent 生成的內容，你們會攔嗎？

Charlie Marsh：會，我們會。對。所以我們現在有一套 AI policy。它的目的不是反 AI——因為我們自己確實大量使用 LLM開發——但更重要的是，它是為了回答一個問題：我們怎樣保留那些真正有用的貢獻，同時過濾掉那些對倉庫整體來說凈負面的互動？

因為一個貢獻者跑過來，貼一段 agent 寫的評論；然后我們問他一個問題；接著他又把 agent 的回復原樣貼回來——這里面其實沒什么價值，對吧？我們自己也可以直接去問 agent。我們真正想保留下來的，是人類貢獻者能帶來的那些有用東西：洞見、復現方式、以及那些能幫助我們把問題喂給自己的 agent 的信息。在 GitHub issue 里跟一個 LLM 來回對話，對我們來說其實沒有意義。

所以我們的政策大概是：你必須理解你貼進來的內容，或者你提交的內容。聽起來像是個很低的門檻，但其實并不是。

主持人：你們怎么判斷、怎么執行這個政策？

Charlie Marsh：如果我們看不出來，而它確實是 agent 寫的，那我猜也沒什么問題，對吧？但至少現在，還是有很多明顯的痕跡。比如它比人類會寫得詳細得多，細節多得過頭，格式化得太過了，用一些人類不太會用的術語，發明一些奇怪的行話，塞大量鏈接——最明顯的信號就是：它在很多根本沒必要的地方投入了過量精力，而這種方式通常不是人類會做的。這樣的內容，幾乎總是 agent 寫的。

不過這件事確實很難處理。Zig 的 LLM 政策就比我們嚴格得多，基本上就是：項目里不接受 LLM 寫的代碼，或者干脆不接受任何 LLM 輔助代碼。這和我們差異非常大。我的意思是，我現在所有的 PR 幾乎也都是 LLM 寫的，對吧？LLM 寫的。

他們還寫過一篇博客，提到一個概念，大意類似“貢獻者撲克”——也就是你其實是在對貢獻者下注。過去在開源世界里，一個貢獻者來了，他可能對項目還不熟，但你能從他身上看到潛力，或者能感覺到他真的很投入、很感興趣。你給他反饋，他吸收反饋、修改 PR；下次再提 PR 時，他已經從上次反饋里學到了東西，對吧？

這里也是一樣的：人會從反饋中學習，這種學習會復利，他們會越來越好，未來甚至還能去指導別人，對吧？所以你是在投資于人。從開源角度也是一樣：你會希望把精力投入在優秀的貢獻者身上，讓他們逐步成長，未來既能幫助別人，也能成為自己的維護者。

但對那些由 agent 寫出來的 PR 來說，這種機制基本上就失效了，因為人們實際上并沒有學到什么。一個人可以提交一個 agent 寫的 PR，你留下評論，然后他把評論貼回 agent，再讓 agent 改一版，最后合并。整個過程里沒有任何反饋復利。

所以我其實非常理解那種觀點：維護者和貢獻者之間的契約，現在已經和過去很不一樣了。

另外，還有一個也不算新鮮的觀察：提交一個“看起來合理”的 PR，成本已經降到零；但審查并驗證一個“看起來合理”的 PR，成本還是一樣高，甚至很高。尤其是像我們做的那些項目——我不是想夸大它們，只是它們真的很難。TY 是我們的類型檢查器，可能是我做過的技術上最難合并改動的項目之一，因為它的架構非常復雜，問題域本身也非常復雜，真的特別特別難。

所以，如果有人給 TY 提一個“看起來合理”的 PR，他可能只花了兩分鐘，而我們可能要花一個小時才能把它看明白。于是這就給開源帶來了非常糟糕的互動結構。我也不知道這個問題該怎么解決。我覺得在我們找到解決方式之前，它大概率還會繼續惡化，直到某個時候也許會好起來。但這確實是我們在自己項目里已經切身感受到的事情。

主持人：聽起來，review 正在越來越成為瓶頸。像 Bun 那次重寫，你知道有沒有人類真正看過那些代碼嗎？還是說就是——

Charlie Marsh：不，我覺得那應該沒有經過人類審查。

主持人：對。所以就是 YOLO 式地把整個東西重寫掉。

Charlie Marsh：對。某種意義上說，我覺得他們確實有——而且我也很期待——至少在我們錄制這期的時候，Jared 還沒把博客發出來。他一直在開玩笑，說那篇博客寫得比重寫本身還久。

但我其實真的很想看那篇博客，因為我覺得他們對于“怎么做這次重寫”應該有一套相當成熟的方法，這會很值得讀。它不是那種“給一個 prompt：把這段東西改寫成 Rust”就完了。我從那個 PR 里看到的印象是，整個重寫似乎分成了不同階段，而且每個文件都要經過幾輪不同的階段，每一階段還有對應的驗證方式，用來判斷它是否正確。

所以答案依然是否定的：我不覺得有人類真正讀了大量那部分代碼。基本上是不可能的。

主持人：如果今天我們倆都一致認為，Zig 在客觀上比 Rust 更好，然后你團隊里有人說：“我可以把這些代碼都重寫成 Zig。” 你會攔嗎？

Charlie Marsh：我覺得我會攔。至于我這么做對不對，我不知道。但我覺得，至少以我們團隊現在的狀態來說，我們還沒有準備好。而且未來也許會準備好，也許最終我們真的會這么看。但就現在而言，我覺得我們仍然相信：深入理解自己的代碼、工具鏈和生態系統，依然非常有價值。所以我會說，我們現在不想這么做。當然，這可能也要看具體項目。我也不敢說得太絕對。

別讓 AI 的微優化，掩蓋了原本能快 100 倍的系統設計

主持人：你們做出來的這些東西，幾乎都比當時已有的方案快一個數量級。Rust 在那張圖里，到底貢獻了多大一部分？

Charlie Marsh：我覺得這得看具體項目。比如在 Ruff 上，很大一部分確實就是 Rust 帶來的。然后隨著時間推移，我們又在那之上做了很多優化。你甚至可以去看項目歷史。希望現在還是這樣，但總體上，項目會隨著時間越來越快——當然有時候也會出現回退。

也許我換個說法：同樣是用 Rust 寫 Ruff，你可以有很多不同寫法，而它們的性能特征會非常不一樣。所以我的總體看法是，Rust 更像是一個下限，或者說一個基礎盤——你一旦使用 Rust，默認性能起點就會顯著更高。但即便如此，真正深入思考性能和設計，仍然能帶來更多收益。

如果你把同一個程序分別用 Rust 和 Python 實現——盡可能接近的同一種實現——那 Rust 版一定會更快。但在 Rust 這個前提之上，你依然還能繼續優化它，也許再快很多倍——我不確定是不是 10 倍，但我的重點是：哪怕都是用 Rust 寫的，里面依然有巨大的空間，去思考怎樣讓它更高效，怎樣去寫真正高性能的軟件。

再說一次，我剛開始做 Ruff 的時候，目標之一也是順便學 Rust，所以我當時確實寫了很多“爛代碼”，這沒關系。因為我已經把一個真正對別人有幫助的東西發出去了。但它隨著時間推移變得越來越好，我們也讓它越來越高效。

而在 UV 上，除了 Rust 本身之外，還有更多架構層面的創新。因為 UV 是包管理器，而包管理器會處理大量 I/O：通過網絡下載文件、解壓、寫磁盤、挪文件。linter 不太需要做這些——當然它也要讀你所有文件，但總體 I/O 量沒那么大。包管理器則基本上就是 I/O 密集型場景，同時你還要盡可能高效地完成這一切。

所以在 UV 上，更多是——當然 Rust 也很重要——但我確實覺得，UV 里有更多是我們在架構上做的事，或者說我們在性能層面深思熟慮的設計。比如緩存設計就是非常有意為之的。正是這種設計，才使得在同一臺機器上反復安裝同一個包時，速度幾乎是瞬時的，因為我們在緩存布局、以及從緩存安裝到項目中的方式上，做了特殊設計。

它基本上意味著：如果某個包你之前已經安裝過，那么再次安裝它的代價會極低——無論從磁盤占用還是時間上看，都是如此。這和之前其他 Python 包管理器的設計方式都很不一樣。

所以說到底，還是得看具體項目。但我總體上確實覺得，不管你是在 Rust 里寫代碼，還是在 Python 里寫代碼，性能這件事永遠值得你去思考。你總能把東西寫得更快，也總能把它寫得更慢。哪怕你是在 Python 里寫，只要你在性能和設計上想得更深入，也完全可以把它提速很多很多。所以最終總是一個混合因素，只是不同項目里占比不同。

主持人：OpenAI、Anthropic、Cursor 和 Vercel 都在用這個產品來提升他們的工作效率。它解決的問題是：當你在構建 SaaS 或 AI 產品，并且想賣給其他公司時，你會遇到很多必須滿足的企業級要求，比如 SSO、SCIM、RBAC、審計日志。這些都需要集成時間，但它們又不是你應用的核心重點。WorkOS 提供了一個 API 層，只需幾行代碼，就能幫你滿足所有這些要求。比如說，你有一個新的 SaaS產品，想賣給其他企業，WorkOS 就能幫你補上這些關鍵功能缺口。你可以訪問 workos.com 了解更多并開始使用，也感謝他們支持我的工作，并在這個項目期間贊助這檔播客。

你能不能講幾個在項目里實現過、你覺得技術上最有挑戰或者最有意思的點？

Charlie Marsh：我特別喜歡我們團隊里的 Andrew——也就是 BurntSushi，ripgrep 和很多其他項目的作者，他是個非常厲害的工程師——做的一個關于“版本表示方式”的優化，真的很酷。

簡單來說，如果你想象一下解析并安裝一個非常復雜的 Python 項目，你會發現程序內部要反復解析、創建大量版本號，比如 1.0.1、1.0.2 這種。我們會在程序里構造非常多這樣的 version 對象。結果發現，考慮到規模之大，僅僅是為這些對象分配內存，本身就已經很昂貴了。

然后他想出了一種表示方法：對于百分之九十幾的版本號，我們都可以只用一個u64整數來表示。這樣效率就高太多了。圍繞這個優化做出來的 benchmark，以及它本身的實現，我都覺得特別酷。那可能是我讀過最酷的 PR 之一。

而在 TY——也就是我們的類型檢查器——里，則有大量非常有意思的性能工作，尤其是為了讓它支持增量更新。TY 的目標是同時成為一個類型檢查器和語言服務器，所以整個系統從一開始就是高度增量化設計的。

這里的核心思想是：如果你在文本編輯器里打開一個文件，你其實不一定希望為了給這個文件做分析，就先把整個項目、所有依賴、項目里的每個文件類型檢查一遍，因為你根本不需要。所以問題就變成：怎么讓系統做到這一點？我會把這種方式叫作“懶”，你就是要盡量懶。

但除此之外，另一層需求是：如果你打開著一個文件并編輯它，或者你同時打開兩個文件，只改了其中一個，你就只希望重新計算那些必須重算的部分。你不希望又把整個代碼庫完整地重新類型檢查一遍。特別是當你在一個像 PyTorch 這樣的大項目里工作時，你打開兩個文件、改其中一個，總不能每次都等兩秒鐘，系統才重新把整個項目檢查一遍并給你新的分析結果。

所以整個系統是圍繞 query 來構建的，這一點很有意思。更多是一種宏觀架構設計。我們是構建在一個叫 Salsa 的框架之上的，Rust Analyzer——也就是很流行的 Rust 語言服務器——也是基于它構建的。而現在，無論是有意還是無意，我們都已經成了 Salsa 的非常重要貢獻者之一。整個系統圍繞它來建，這在架構上一直都很有意思。

主持人：明白了。所以它既是 lazy 的，不會去檢查整個代碼庫；同時又是 incremental 的。

Charlie Marsh：對。真正難的是 incremental 這一部分，因為你實際上需要一種方式，去建模代碼里所有事情之間的依賴圖。然后當你改動某個東西時，我們希望只把數據沿著那些真正相關的節點回流，只更新那些必要的部分。

這件事花了很多功夫，但最后確實成型了。最近我也在大量用 Codex 做優化，因為它在微優化方面往往特別擅長。尤其是在 TY 里，我們還必須非常關注內存，而不僅僅是速度。因為如果你在一個非常大的項目上工作，你不會希望僅僅為了跑一個語言服務器，就占掉好幾個 GB 內存。理想狀態下，它應該足夠高效。

所以我現在花了很多時間，幾乎是在持續不斷地優化內存占用和性能。我甚至可以直接設一個目標，比如：“試著把這個項目里 Salsa 的內存占用降低 1%。”它通常都很擅長給出一些相當合理的改進方案。

所以我覺得這特別酷，因為某種意義上，你幾乎可以對軟件進行一種持續性的——我不想把話說得太大，不想叫它“自我優化”——但確實有點像“持續優化”。我很享受這個過程。不過這里大多數工作，還是在想辦法找到更省內存的數據表示方式，或者從更宏觀的層面做重構，去修復那些病態性能問題。

主持人：像剛才那個版本號優化，能想到把它限制為u64來表示——如果回頭看這些更有創造性的優化，它們都還是“人類時代”的產物。你覺得如果只是，比如跑一遍 Codex，然后跟它說“別搞壞功能，但把內存降下來”，你會相信它自己能想出這種點子嗎？還是說這種優化已經高出目前能力一個層級了？

Charlie Marsh：這是個非常有意思的問題。至少就我的經驗而言，如果你只是讓這些工具去降低內存占用，或者把性能提升一個中等幅度，它通常會先給你一些邊邊角角的小優化，而不是更大的重構，或者對系統設計本身做重新思考。但如果你通過 prompt 和 agent 協作，是可以一步步逼近那種更大級別的改造的。

所以，如果你進一步追問：“我們是不是應該從更大的層面想想，為什么非得用現在這種方式來表示數據？” 那么你就有機會走到更大的點子上去。像剛才那個版本表示法，也許如果你是通過不斷提示來推進，最后確實可能抵達。比如你先說：好，我們先 profile 一下，看看時間到底花在哪。然后它可能最終會回來說：大量時間花在版本解析、版本對象分配之類的事情上。接著你再追問：那我們怎么才能把這些表示得更緊湊？

而它大概率會先從表示層面做微優化開始，比如“這個字段可以壓縮一下”“那兩個字段可以合并一下”之類。但如果你持續往前推，我覺得它是有可能走到那個層級的。只是，那不會是它默認第一時間就想到的事。

HashiCorp 的創始人之一 Mitchell Hashimoto，現在在做 Ghostty。他上周還是這個周末發過一篇很有啟發的東西，講的是他寫的一個渲染器。大意可能會被我轉述走樣，但基本意思是：他故意先寫了一個非常糟糕的渲染器，然后讓一個 LLM 去優化它，結果性能提升了大概 10 倍。他說：“太好了，對吧？” 實際上并不是。因為他自己手寫的版本，快了 100 倍。

如果你不自己動腦，不從第一性原理去思考“它理論上應該有多快”“這個系統本來應該怎么工作”，那你最后只是把一堆不斷累積的——我未必想把它叫“糊代碼”，但差不多——你就是在不斷堆這些東西，然后說：“哇，我把它提速了 10 倍！”可實際上，它本來應該提速 100 倍才對。

全自動測試：對抗 AI “糊代碼”的唯一解法

主持人：如果你生成的是徹底的垃圾，那還比較容易識別。我覺得更麻煩的是那種灰色地帶：部分是 AI 生成的“糊代碼”，或者說它也還過得去，但達不到你們以前的標準。你們團隊里有沒有什么有效的方法，能對付這種灰色地帶的 AI 糊代碼？

Charlie Marsh：所以我確實覺得，現在要做一個職業生涯早期的軟件工程師會非常困難。只是我現在接觸這類工程師不算多，因為 Astral 本身團隊很小，而且我們招人通常也偏資深。所以我很難具體想象：如果是我，我到底會怎么學？我的迭代閉環會是什么樣？

感覺實在太容易掉進那些使用 agent 時會出現的壞模式里了。我也在很大程度上改變自己的寫軟件方式。團隊里也有人跟我說過——而且我很高興他們愿意這么跟我說——因為我現在大量在用 agent，而且某種程度上也在推動團隊更多地去用 agent。

我之所以這么做，部分原因是：我們是在給軟件工程師做工具，而現在我們的很多用戶也已經在用 agent 了。如果我們所有做得好的事情，都建立在“我們足夠理解用戶以及他們的工作方式”這個前提上，那么我們自己大概也應該去用 agent，這樣我們才知道“用 agent 做軟件”到底是什么體驗，進而才能為用戶做出更好的工具。這是我一部分動機。另一部分動機則是，想看看它到底會怎樣改變你的工作方式。我覺得自己現在確實交付了更多東西。

但這個過程并不輕松。團隊里有人直接跟我說——我覺得這很好——他們說：“以前你提 PR 的時候，我其實不太需要花很多力氣審，因為我對你、對你的工作質量很有信心。可現在，你提 PR 時我必須非常仔細地審，因為那已經不是你自己寫的了，而是 agent 寫的。”

我當時就覺得：哇，這很有意思。而且他們完全說得對。同樣的事也會發生在我自己身上。如果我晚上提了一個 PR，第二天早上起來再去看，我會想：等等，這也太糟了吧。你懂我意思嗎？人真的很容易被自己騙過去，以為一份其實達不到你原先標準的工作，也已經足夠好了。

而我們其實還不知道該怎么徹底解決這個問題。我自己也在不斷學習、不斷變好。我覺得自己現在比大概今年 2 月的時候要好很多。那時候我幾乎已經完全沉迷 agent 了。現在我稍微——但我的重點是，當團隊里有人跟我說那句話時，那對我是個非常強烈的時刻，我會意識到：哇，你說得沒錯。而且我在團隊其他人的工作里也會看到同樣的問題。這并不只是我一個人的情況。它確實把很多東西都徹底打亂了。

我希望最終能走到一個世界——雖然我們現在還沒到，而且我也不知道能不能到——在那里，如果你提一個 PR，而且它已經全綠了，那么它被合并的概率應該非常高。因為那意味著：你已經對大多數真正重要的東西做了自動化驗證。

我們在自己的項目里已經有不少這樣的東西，而且一直在努力增加，我覺得這很有幫助。尤其是在 TY 里，我們有大量 benchmark，會在每一個 PR 上通過 Valgrind 和 CodSpeed 運行。所以我們會在每個 PR 上測試內存占用、模擬時間和 wall time。除此之外，我們還有一個非常大的生態測試套件。基本上每次你提一個 PR，我們都會在一堆生態項目上跑改動前和改動后的結果，然后生成一份 diff 報告，把所有新增或消失的診斷信息、錯誤等都列出來。

所以這些年我們一直在做越來越多這樣的事情。說實話，這些東西的重要性甚至早在我們開始用 agent 之前就已經很高了。沒有這些東西，我們本來也很難繼續構建這些項目。我的重點是：我希望有更多自動化驗證，并不斷把這件事做得更好。

這還包括一些事情，比如現在我們基本默認：團隊里任何人提 PR 之前，大概率都已經先讓 Codex review 跑過幾輪了。這基本上已經成了默認前提。

主持人：這個流程本身也可以自動化吧？不過所謂 Codex review，本質上就是讓 agent 去 review 一遍代碼、做二次檢查？

Charlie Marsh：對，就是跑 Codex，然后執行 slash review。

主持人：明白。

Charlie Marsh：就這么簡單。它也沒多復雜，但因為現在如果有貢獻者提了 PR，這是我們做的第一件事。因為它通常確實能發現一些不錯的問題。

所以我覺得，一類辦法是：你怎么建立更多自動化系統，幫助確保事情是對的。這也包括像持續改進agents.md文件。如果有一些東西是你在 review 里反復給反饋、但 agent 總是學不會的，那就盡量想辦法把這些經驗顯式傳達給庫。甚至可以固化成 skill。我們團隊里就有一些共享 skill，諸如此類。順便說一句，這些其實都不復雜，很樸素。

另一類問題則是：我怎么確保自己真的投入了必要的努力，去保證我提交的是一個高質量 PR？對我來說，這意味著我真的應該理解 PR 里的每一行代碼——我知道，這聽起來像是一個低到不能再低的要求，但確實如此。

另外，我也會盡量自己在 GitHub UI 里把每個 PR 再審一遍。這其實是我一直都覺得很有幫助的事。你如果真的打開 PR，點進 Files，用一個 reviewer 的視角把它讀一遍，通常會發現一些在本地 diff 里很容易漏掉的問題。我一直覺得這價值。

還有一點，是盡量把“技能”編碼出來。某種程度上這也屬于第一類，但比如把那些我自己總是犯、agent 也總是犯的錯誤，盡量整理成 skill。最近一個例子是：我發現自己經常收到一種 PR 反饋，形式基本都是：“這里這個條件、這個if語句，到底是想捕獲什么情況？因為我把它注釋掉之后，所有測試都還通過。”

于是我就想：好，那在我提任何 PR 之前，大概應該加一道檢查，讓 agent 先過一遍：這些條件現在到底還有沒有意義，還是說它們只是上一次重構后遺留下來的廢代碼？

所以，我也還在學習，但這些就是我現在正在做的一些事情。

對，我還是覺得，現在真的是一個很難的軟件構建時代。很長一段時間里，我其實一直有個擔心：AI 會讓我們更高效，但編程本身可能會變得沒那么有趣，因為我是真的很喜歡編程。

我當時會想：完了，以后我是不是得把所有時間都花在 review 代碼上，天天給這個總是出錯的笨 agent 寫 prompt？雖然它整體上可能還是更高效，但這種工作聽起來一點都不好玩。可現在我的感覺已經比幾個月前好多了。我也不完全確定為什么。

我想一方面是 agent 變強了，工具鏈也變好了，我自己也更適應了。另一方面，是我越來越能體會到：和 agent 一起工作，到底打開了什么樣的新可能。現在做實驗的成本低得驚人。

有太多我一直想試的事情、一直想回答的問題，現在幾乎可以立刻得到答案。因為在軟件開發里，最難的事情就是反饋環太長。如果你想驗證一個想法，你得先花兩周把它寫出來，然后部署、收集數據，最后發現：啊，我錯了，方向不對。而現在，我可以在一個下午跑五個這樣的實驗。

舉個有點傻的例子：在 UV 里，我們幾乎所有東西都是 snapshot test。也就是說，我們的測試方式基本就是運行 UV，然后驗證輸出。整個程序幾乎都是這么測的。

這意味著我們有很多測試，也意味著我們有很多測試輸出。而這些測試輸出實際上就存放在測試文件里。比如我們有個 Rust 文件，像lock.rs這種，用來測試 UV 的各種 lock 場景。它特別特別長，其中一個原因就是，所有 lock 輸出的快照都直接放在測試里。

然后我就會想：嗯，如果我們把這些 snapshot 放到單獨的文件里，會怎么樣？編譯會不會因此更快一點？因為現在它們 technically 都是 Rust 代碼，那如果這些內容不再在 Rust 文件里，會不會讓構建更快之類的。

這件事我一直都想試，但如果讓我自己來做，這個實驗會非常痛苦，因為你得把所有那些測試都改掉。于是我就讓 agent 在后臺幫我做了，同時我去做別的事情，然后很快就拿到了很多數據。最后答案是否定的——不過也不完全否定。更準確地說，如果你只是反復修改 snapshot 輸出，那么這樣做其實是有幫助的。因為這些輸出放到別處之后，你就再也不需要為了它們重新編譯整個程序了。總之，它影響的是這個環節。

我的重點是：我現在整天都在跑這種實驗，嘗試那些過去很難做、很貴才能回答的問題。而真正把一個實驗結果變成生產級方案，這中間當然還是有真實工作的。但一方面是工具和 agent 在變得更強，另一方面是有許多以前我根本做不到的事情，現在已經能非常輕松地做到了。

第三點是，我越來越意識到：我從“做軟件”中獲得的很多價值，其實并沒有失去。因為其中一部分價值來自于認真思考數據結構該怎么布局；還有很大一部分價值來自于合并一個 PR，真正解決了用戶的問題。我從“修好某個東西、把某個東西變得更好”這件事本身獲得很大滿足感，而不一定只是從“親手把代碼敲出來”這件事里獲得滿足。

所以我非常能理解那些覺得“和 agent 一起工作，好像失去了什么”的人，因為我自己也確實有這種感覺。但和幾個月前比起來，我現在對“作為軟件工程師與 agent 共事”這件事，心態已經好很多了。

主持人：你剛才提到性能優化時說過，如果只是把 Codex 放出去，它往往更擅長做這些局部優化，但對一些——至少在今天看來更依賴人類創造力的——系統級優化，它還不太行。這讓我想到你發過的一條推文。你說：“一想到如果沒有足夠的軟件工程經驗，我會用這些工具產出多少垃圾，我就有點擔心。”

Charlie Marsh：我現在依然很擔心這個問題。

主持人：對。這讓我想到你剛提到的 Mitchell Hashimoto 那條推文——“Codex，你去把這個做了”和“你把 Codex 當成一個工具來駕馭，并不斷把它往正確方向推”，這兩者之間差別非常大。

我也挺想聽聽你對這個問題的看法，因為那條推文傳播得很廣，我覺得很多人都在思考這件事。

Charlie Marsh：成為一名優秀的軟件工程師，比以往任何時候都更有用了。現在依然是這樣：我覺得我們團隊里工程能力最強的那些人，即便是在使用 agent 這件事上，也仍然是最有效率的。

有意思的是，現在大家經常會談論一個詞，叫 token maxing。我不知道你熟不熟這個說法。比如說，有些地方會討論要不要搞一個排行榜。這事最近在 Twitter 上也很常見——有些公司有 token 排行榜——然后它會制造出非常糟糕的激勵，讓人為了上榜而拼命多用 token。

好玩的是，token 使用量本身，在內部通常確實是可以查到的。雖然不一定真的有排行榜，但你是能看到誰用了多少 token 的。這件事其實挺值得看一眼。因為我并不在乎團隊里誰用的 token 最多。甚至有些同事會刻意提醒自己不要在意自己在 token 排行榜上的位置，我覺得這很好。我真的不在乎。他們只要把工作做好就行，用不用很多 token，我都不在乎。

但去看這個排行榜依然挺有意思，因為團隊里一些最有生產力的人，確實也用了很多 token，對吧？這里是有相關性的。我不是說這一定是因果關系，但我確實覺得，很多優秀工程師都能非常有效地使用 agent，并希望借此放大自己的能力。

我其實挺規避風險的，但被投資人“說服”創辦了公司

主持人：你用 Rust 做出了這個概念驗證，而且反響很好。但你為什么會決定圍繞它創辦一家公司？融資過程又是怎么進行的？你的動機是什么？

Charlie Marsh：對。所以我后來離開了 Spring。其實是一個非常親密的朋友說服我離開的，他差不多同一時間也離開了 Meta，然后跟我說：“我們應該一起創辦家公司。” 我當時就說：“好吧，行。”

當然，事情也沒有那么簡單。但我確實離開了。然后我們就某種程度上進入了所謂的“創意迷宮”，開始思考：我們到底想做什么？我們一開始其實并不知道自己想做什么，于是花了很多時間去探索一個“想法的維恩圖”。有些東西他感興趣、我不感興趣；有些東西我感興趣、電我不感興趣；中間還有一些交集，我們就去探索那些交集中的東西。

但與此同時，我在所有空閑時間里都在做開發工具，因為那才是我真正覺得特別有意思的東西。而那條路跟他并不完全契合。那段時間我正在做 Ruff，也在做 GitHub 上還能看到的另外幾個項目，可能沒那么有意思，但我當時確實在試很多不同的方向。我對 WebAssembly 很感興趣，也寫過一個某種意義上的 TypeScript CI/CD 工具包，有點像你用 TypeScript 寫流水線，然后它會把它們轉譯成 Docker。我當時會想：“哦，這可能挺酷。” 總之，我當時在做很多東西。

到了那個階段，我決定開始和投資人建立關系，但我并不打算立刻融資，因為我還不知道自己到底要做什么。我的思路是：先試著認識一些愿意投這類東西的人，等三到六個月之后，我再回頭聯系他們，說：“嘿，我們之前聊得很愉快。現在我正在做 X。”

這就是我當時的思路。后來我認識了一些投軟件基礎設施和開發工具的投資人，聊得也不錯。問題在于，事情有時候會發展得非常快。所以我其實并沒打算這么早開始融資，但最后某種程度上是被“說服”了。與此同時，Ruff 也在快速增長，于是我就逐漸被說服：這里面確實已經有足夠多的東西，足以支撐一家公司。這整個過程其實很有意思。

我當時的想法是：我還不太確定這東西怎么變成一家公司，但我后來基本上被說服了——這里面已經有足夠的基礎，可以圍繞它建立一家真正的公司。

主持人：是投資人說服了你？

Charlie Marsh：對。對此我其實很感激。

另外一件讓我放下顧慮的事也挺有意思：“如果你發現這并不適合你，你是可以把錢退回去的”。我其實覺得這句話特別高明，因為我九成九本來也不會真的這么做，但它確實讓我的心里負擔小了很多。

所以，中間有很多繞來繞去的細節，但總之，后來我逐漸開始更全職地做 Ruff。與此同時，我和那些潛在的早期投資人之間也形成了一種協作關系：我們會進行很長時間的交流，討論我的各種想法。然后慢慢地，這件事就變得很清楚了：這里面已經足夠成熟了。我還寫了一個大致的產品路線圖，說實話，其中很多內容到目前為止都和我們后來真正做出來的東西大體一致。再后來，事情基本上就變成：是的，我們想投你；這是我們愿意給出的條款。我當時就想：哇，原來事情真的要發生了。

所以整個過程挺有意思，因為我以前從來沒做過這種事。我之前的整個職業生涯都只是一個 IC 軟件工程師，然后突然之間，我要開始創業了。

有趣的是，我其實覺得“全力投入去創辦公司”這個決定本身并沒有那么大壓力。反而很多壓力是在后面，公司開始真的運轉起來、開始成功之后才來的。因為一開始，我某種程度上沒什么可失去的。但隨著公司開始變得成功，我會想：哇，公司好像真的在運轉了。那接下來會發生什么？而且我還有 20 個人的團隊在依賴我。

所以我不知道。至少對我這個創始人來說，我其實挺規避風險的，但我反而覺得，創辦公司本身比后面那些需要處理的復雜局面更容易做決定。整個過程發展得非常快，也有些出乎意料，而且某種程度上是和投資人形成了一種共生關系，這些都是我之前沒預料到的。

主持人：我還真沒想到會是投資人主動——因為我原本以為一般都是創始人特別想融資，到處說“請投我”，但你這里反而是投資人來——

Charlie Marsh：我覺得這件事可能有一百萬種不同發生方式。我們后來一共融了三輪：種子輪、A 輪和 B 輪。其實 A 輪和 B 輪我們甚至都沒有正式對外宣布。我的意思是，它們最后在收購博客里被提到了，但整體情況有點復雜。簡單說，就是我們一直沒真正騰出手來做這件事。

主持人：你們為什么不公布？因為這不是對招聘很有幫助的營銷嗎？

Charlie Marsh：這當然是好的營銷。但基本上總會有一些理由讓我們覺得：再等等吧。然后對我來說，它看起來也總像是一件挺費勁的事。再加上我會覺得：說實話，它從來都不像是最重要的事情。因為我們當時正在做很多產品，公司發展也不錯，我就會想：我們其實不太需要這波營銷。

后來我們確實計劃過要宣布，但還沒來得及，我們就被收購了，所以最后也沒發。

不過那三輪融資基本都是搶投式的，都是投資人主動發起的。我們確實很幸運，因為公司發展得不錯，大家愿意投。但從我的角度看，這種位置也挺有意思的。

我覺得我一直都偏保守，不是那種會非常積極主動地跑出去大規模融資的人。但我們也確實很幸運，恰好在做一些讓大家非常有信心、也非常愿意下注的東西。

主持人：這大概也讓你在談判里占了很大優勢，因為最好的位置之一就是：你其實愿意轉身走人，你并不非要這筆錢不可。甚至從定義上講，你一開始都不是為了這件事去的，是他們來找你，說“請收下這筆錢”。

Charlie Marsh：這話倒是沒錯。雖然我不會說自己是個很會談判的人，但對，我至少確實算是手里握著一副不錯的牌。

不過我們在投資人這件事上真的非常幸運。我們的投資人都特別棒，非常支持我們，而且和我想建公司的方式高度一致。幾乎沒有沖突，也從來沒有什么“你必須做這個”“你必須做那個”的壓力，就是純粹的支持。

也許唯一一類持續性的反饋是：我其實本可以更激進一點，比如擴張得更快、增長得更快、多做一些事情。但我自己其實很喜歡我們當時的運作方式。總之，我們和投資人的合作體驗非常好，所以我一直覺得自己挺幸運的，因為這件事完全可能走向另一面。

主持人：我能理解投資人投資是期待未來的收入回報，但你們這家公司到底是怎么賺錢的？因為你們的軟件不是免費送的嗎？

Charlie Marsh：對。所以我們在去年 8 月推出了一個商業產品。它叫 Py——本質上可以看成是 UV 的托管版配套產品。很多 UV 用戶不會使用公共 registry，而是會購買私有 registry 軟件，可能是出于安全考慮，也可能是因為他們需要發布自己的私有制品，諸如此類。

于是我們自己做了一個私有 registry，而且對 UV 做了很多一等支持。這樣一來，我們可以解決大量在 issue tracker 里看到的、用戶使用其他方案時遇到的問題。另一方面，因為客戶端和服務端都是我們自己做的，所以可以做一些縱向一體化的優化，讓整個體驗特別快、特別好用之類的。

我們圍繞這個賣了一段時間，收入增長其實還不錯。當然，它不是那種——你知道，現在 AI 時代里大家總在講“史上最快做到一億美元收入的公司”之類的故事。我們不是那種速度。但我們確實成功賣進了一些大型企業。

有意思的是，因為我們先有開源項目，而且大家都在用我們的開源工具，所以我們的銷售漏斗其實質量非常高。我的表述會是：我們的客戶數量雖然不算特別多，但客戶質量極高。

所以我們想賺錢的總體邏輯一直是：繼續做開源，工具本身保持免費、開源、完全非商業化；然后我們圍繞這些工具，去做一些“當你開始用我們的工具后，自然接下來就會需要”的軟件。比如你在用 UV，那么你大概率就會遇到一些我們可以通過私有 registry 幫你解決的問題。這樣一來，漏斗前端就是使用 UV 的人，等他們出現這些問題后，我們再賣 registry 給他們。而 registry 也只是一個更大平臺中的一部分。我們原本的目標，是圍繞 Python 去做一個平臺，賣很多不同的東西，有點像“Python 云”。那是我們當時在構建的方向。

而收購帶來的一個很酷的變化是：這個平臺中的一些能力，現在我們反而可以直接免費開放給所有人。舉個例子，這個平臺里有很大一部分工作，是圍繞 Python 和 GPU 的生態做的。因為在 Python 社區里，有很大一部分用戶會把 Python 用在 GPU 場景里，比如 PyTorch，以及圍繞 PyTorch 構建起來的一整套軟件生態。

出于各種原因，這一套的使用體驗并不算好。很多時候它很難裝、很難用，也很難選對版本；還跟你的 GPU 型號、安裝的 CUDA 版本等因素強相關。于是我們當時是用一種特定方式去嘗試解決它：我們做了自己的發行體系。你可以把它類比成一種 Linux 發行版，因為我們會預先把很多彼此兼容、能協同工作的東西都構建好，然后把它作為能力提供給客戶。

而現在，我們實際上可以把這部分東西直接免費開放給所有人，因為我們不再需要作為獨立公司去構建一個獨立商業模式了。我們現在只需要專注于做出很棒的工具，去帶動一個更廣泛的生態。所以后面還會有更多動作，但這確實是一個讓我很興奮的點。

主持人：作為第一次創業、而且還是工程背景出身的人，有沒有哪類經驗讓你覺得很意外？如果有工程師也準備走創始人這條路，你會特別想跟他說什么？

Charlie Marsh：創業的方法有太多種了。老實說，我其實不太喜歡別人給創業建議，因為這個行業里太多都是“幸存者偏差”。你完全可能去聽兩場分享，然后兩個都極其成功的創始人給出完全相反的建議。你聽完只會想：那我到底該怎么做？

所以我更傾向于認為：你得搞清楚什么是真正適合你的。這里面有大量決策要做，比如要不要線下辦公、要不要遠程，對吧？關鍵是你要有自己的原則，并堅持它。兩種方式都可以很好。我們整個公司就是遠程搭建起來的，而且效果非常好，真的很棒。那我認不認同線下辦公也有好處？當然認同。但如果我們必須線下辦公，我能不能招到后來那支團隊？絕對不可能。

所以這類事情永遠都存在取舍。你只能盡量有原則地判斷，搞清楚什么和你自己真正契合。像這樣的決策有一百萬個，你都得認真想清楚。

從很多方面說，我覺得自己很幸運，能夠按自己想要的方式來經營公司。比如我會盡量把花在融資和投資人身上的時間壓到最低；我會優先選擇那些我真正信任的投資人，而不是去和一大堆投資人周旋、互相壓價，只為了拿到最好的條款。我的目標一直是：找到一個我真正信任的合作伙伴，拿到一份足夠好的條款，然后盡快推進，好把融資這件事本身占用的時間降到最低。

所以，想清楚你真正看重什么，不要太執著于“你覺得自己應該怎么做”，而是多想想“你真正想怎么做”，以及什么樣的方式才真正適合你的工作方式。

主持人：你最推薦的一本書是什么？

主持人：不管是技術類的，還是作為創始人對你有幫助的都行。

Charlie Marsh：我其實不怎么看太多技術書。但我確實看過幾場對我影響非常大的演講，這可能算是另一種形式。

主持人：是哪些演講？

Charlie Marsh：Zig 的作者 Andrew Kelley 有一場關于“面向數據設計（data-oriented design）”的演講，我從中學到了很多。其實不僅僅是學到具體內容，它甚至在某種程度上啟發了我，讓我開始用一種完全不同的視角去看軟件。所以我到現在還是會經常想到那場演講。

主持人：挺有意思。

Charlie Marsh：對，像這種就很棒。真的非常好。它大概是講——不過我有陣子沒看了，可能會講錯——很多內容基本上是在講他們在 Zig 編譯器里做的一些設計決策，以及他們如何思考內存、分配等問題。

我是在自己系統編程生涯還比較早期的時候看到那場演講的，當時就有一種感覺：哇，這些人真的非常在意他們正在做的東西。我當時想，這太酷了。

主持人：對。最后一個問題，如果你可以回到職業生涯最開始的時候，比如大學剛畢業那會兒，以你現在知道的這些事情，你會給那時的自己什么建議？

Charlie Marsh：我也不知道。要在沒有強烈“事后諸葛亮偏差”的情況下給自己提建議，真的很難。

不過，我想還是有一些事情，我可能會告訴自己：你做的是對的，不要那么擔心。但如果把人生重來一千次，它到底會怎么發展，也很難說。

比如說，我離開學校后去了 Khan Academy。那時候我心里確實有一部分會想：哇，我是不是應該去一家更典型的大科技公司？我以后會不會很后悔，錯過那樣的經歷？再比如，Khan Academy 的薪水其實不錯，但大廠薪水肯定更高，我還看著朋友們拿到巨額獎金之類的。我心里會有點不安：我是不是也應該這么選？

但我覺得，從長期來看，那次選擇其實回報非常大。我的意思是，也許去大廠也會很好，但我后來得到的那種經歷，恰恰是我真正想要的，而我當時做這個決定，本來也是出于我認為正確的理由。

所以我覺得，這里面很多事情都像是——我也不知道——一切自有其因吧。只要你是基于原則做決定，我覺得最終還是有可能走通的。

主持人：我們一開始聊的時候，你說你之所以會走上這條路，是因為你嘗試了很多不同的生態，所以才有了更寬的視角。我猜如果你當時去了 Google，只在 Google 那套封閉體系里工作，你可能就不會有同樣的洞察。

Charlie Marsh：對。我其實也會想到 Spring，因為我在那里待了四年半。后來我剛離開，他們就決定做戰略轉向，最后加入了 Genentech。但我們一開始的目標，是想做一家某種意義上非常瘋狂的藥物發現公司。我們聚焦在衰老方向，而且是用計算機視覺來做。我們當時想做的事情真的非常、非常有野心。

后來我也會想：啊，這家公司最終沒有獲得那種巨大的退出，或者我們沒有實現最初全部的夢想。那我是不是把時間都浪費了？但最終我會覺得：沒有。因為作為早期員工，我經歷了公司不同階段，也因此學到了太多關于如何經營自己公司、以及各種技術上的東西，而這些后來我都帶進了自己的公司里。

所有事情最后都像是匯聚成了一條線，把我帶到真正熱愛的事情上——也就是構建工具——并不斷為它輸送養分。

CSDN 寵粉福利炸裂組合！

送 AMD 200小時硬核算力 + 滿血版 DeepSeek-V4 Pro 300萬Token

本地重負載+云端最強推理，一步到位解鎖 AI 自由！