“我一行代碼都沒讀就發(fā)布了”，被OpenAI收購后，uv工具創(chuàng)始人開始反思AI編程

編譯 | 宇琪

策劃 | Tina

過去三年，Python 開發(fā)者工具領域發(fā)生了一場靜悄悄的革命。一個叫 Charlie Marsh 的年輕工程師，從一家計算生物學公司辭職后，在“不知道自己要做什么”的狀態(tài)下，花了 9 天時間搭出了 Ruff 的原型，一個比當時最快的 Python linter 還要快 10 到 100 倍的代碼檢查工具。Ruff 成功后，他順勢成立了 Astral 公司，并用 Rust 打造了 uv，一個快到讓 pip 看起來像慢動作回放的包管理器。這兩個項目迅速席卷了 Python 社區(qū)，GitHub 星標數(shù)以萬計增長，最終讓他在今年三月把整家公司賣給了 OpenAI。

這不僅僅是一個“技術(shù)天才靠 Rust 征服世界”的故事。日前，Charlie Marsh 在播客中，與主持人 Ryan Peterman 一起探討了 AI Agent 如何重塑軟件工程的每一個環(huán)節(jié)。除了技術(shù)本身，他還談到了軟件工程行業(yè)正在集體經(jīng)歷的困惑：當提交一個”看起來合理”的 PR 的成本降到零、而審查它的成本依然高昂，我們該信任什么？當你自己寫代碼的樂趣被”指揮 Agent 干活+逐行審查 Agent 輸出”的工作流取代，編程還值得熱愛嗎？

這些問題沒有標準答案，不過 Charlie Marsh 給出了一個一線實踐者最誠實的思考。最近 X 上流行"I read the code"梗，調(diào)侃程序員已從"寫代碼"淪為"讀代碼"。Charlie 在給自己用的工具上反著來——一行代碼沒讀，全扔給 AI。不過，他坦陳了自己從“全 AI 模式”中被同事打醒的經(jīng)歷，也去看了Bun的倉庫——頭號貢獻者是一個bot，他發(fā)現(xiàn)Bun的倉庫跟他們的倉庫是完全不同的世界。他還分享了團隊對抗 AI slop 的具體策略，也聊到了從普通工程師轉(zhuǎn)向創(chuàng)業(yè)的經(jīng)歷、以及為什么他覺得”現(xiàn)在是早期職業(yè)工程師最難的時刻”。本文基于該播客視頻整理，經(jīng) InfoQ 編輯。

太長不讀版：

Q：Python 工具鏈為什么該被顛覆？

A：隔壁 JS 圈早把工具用 Go/Rust 重寫了，快到飛起。Python 圈還在用 Python 寫工具，慢得理所當然。我就想問：憑啥我們不能擁有同樣爽的東西？

Q：Ruff 是怎么火起來的？

A：先寫博客畫大餅，然后構(gòu)建出能用的 linter。核心策略：10 秒抓住眼球——一個亮眼的標題、一張精心打磨的圖片，不用廢話，一看就懂。然后瘋狂響應社區(qū)，今天提 issue 明天發(fā)修復，圈粉速度拉滿。

Q：為啥選 Rust？

A：坦白說，當初就是跟風。但回頭看香爆了——Cargo 一把梭，git clone 完就能跑，不用跟 C++ 那堆構(gòu)建系統(tǒng)斗智斗勇。內(nèi)存安全？當初根本不在乎，現(xiàn)在覺得真香。

Q：AI 時代還會考慮全部重寫嗎？

A： 不會。代碼如果完全重寫，作為人類你可能就不再理解任何代碼了。而且用已知問題換未知問題太蠢，測試全過不代表行為一致，最終坑的是用戶。而且現(xiàn)在 AI 寫 PR 成本為零，審查成本卻更高，開源生態(tài)快被淹死了。

Q：性能提升全怪 Rust？

A：Rust 給你個高起點，但真正的殺手锏是架構(gòu)創(chuàng)新。UV 快是因為緩存設計得聰明，重復安裝幾乎零成本，這跟語言沒關(guān)系，純屬腦子好用。

Q：跟 AI 結(jié)對編程啥感覺？

A：以前同事閉眼合我 PR，現(xiàn)在逐行細審——因為代碼不是我的了，是 Agent 的。信任崩塌了。但我也在適應，現(xiàn)在整天讓 AI 跑各種實驗，以前不敢想的問題隨手就能驗證，這種解鎖感挺爽的。

Q：初級工程師會被 AI 坑慘嗎？

A：會。他們沒能力給 AI 當教練，只能被 AI 帶溝里去。我們傾向于招資深工程師，因為優(yōu)秀的工程師用 AI 更猛。如果我是初期工程師，太容易掉進使用 Agent 時發(fā)生的那些壞事情里了。

以下是原文：

Python 工具鏈需要一場“Rust 革命”

Ryan：你最初開始構(gòu)建這些開發(fā)工具時，整個領域是什么樣子的？為什么你覺得它能做得更好？

Charlie：在創(chuàng)辦 Astral 之前，我在一家計算生物學公司工作。我沒有生物學和機器學習背景，但我的任務是用 Python 搭建所有支持機器學習運行的軟件系統(tǒng)。那段時間我一邊學 Python，一邊接觸了 Go 和 Rust，在多個不同的技術(shù)棧之間來回切換。

我們團隊很小，但對一個只有幾個軟件工程師的團隊來說，代碼庫規(guī)模相對較大。我們這些人要服務整個團隊，包括機器學習研究員和科學家。我接觸了各種生態(tài)系統(tǒng)的工具鏈，發(fā)現(xiàn)我們一直在試圖從工具中榨取更多效率，無論是類型檢查器、代碼檢查工具，還是包管理器，但隨著規(guī)模增長，我們不斷撞上工具能力的天花板。

我觀察了一遍 Python 生態(tài)，發(fā)現(xiàn)它缺少其他生態(tài)中那種實驗精神。比如 Web 生態(tài)里，很多瘋狂的想法在被嘗試，而且大家對性能有很強的執(zhí)念。從用 Go 寫的 ESBuild，到用 Rust 寫的 SWC，再到 Bun、Deno 等等，原生工具鏈對于 JavaScript 來說已經(jīng)成了理所當然的事情，尤其是當應用越來越大、開發(fā)者機器上跑的活兒越來越多的時候。

但 Python 生態(tài)里沒有這個趨勢。所以對我來說，核心問題就是：為什么我們不能擁有同樣的東西？我親眼看到 Web 領域發(fā)生的一切，我自己也寫過 Rust 和 Go，知道這些不同工具鏈的工作方式和用戶體驗。再看 Python，工具集更小，很多來自其他生態(tài)的有趣想法完全沒被引入，而且所有工具都是 Python 寫的。

這對我來說就是一個有趣的假設。當我發(fā)布 Ruff 時，那篇博客的標題就是《Python 工具鏈可以快得多得多》。對我來說，這本質(zhì)上就是一個待驗證的假設：Python 工具鏈能不能更快？ 我搭了一個原型，結(jié)果證明：是的，完全可以。

Ryan：你寫了一篇關(guān)于 myPy 性能分析的文章，然后僅僅 9 天后就發(fā)布了那篇“可以快得多”的博客。你是在那 9 天里做出來概念驗證的嗎？

Charlie：對。我先寫了一篇關(guān)于大規(guī)模類型檢查的博客，想搞清楚瓶頸到底在哪。然后我開始構(gòu)建一個 linter，因為我覺得 linter 比類型檢查器容易得多，而且 linter 能讓我用更小的體量驗證同樣的想法。做創(chuàng)業(yè)或做工具，核心就是盡快把東西交到用戶手上，讓他們真正用起來，證明價值，同時也能快速迭代。linter 恰好是個完美的形態(tài)：核心邏輯很簡單，但規(guī)則可以無限擴展。用戶從一個小核心加若干規(guī)則就能立刻獲得價值。

我們很快做出了可用的版本，然后持續(xù)迭代，發(fā)布更多規(guī)則和功能。人們可以把它和其他工具配合使用。它從一開始就是有用的，這一點非常關(guān)鍵。相比之下，一個完成了 75%的類型檢查器幾乎毫無用處，包管理器也一樣，這些工具必須做到足夠完整才能產(chǎn)生價值。所以，能夠迭代式地交付、同時保持對用戶有用，是建立工具勢能的核心能力之一。

開發(fā)者營銷“10 秒法則”

Ryan：那篇博客發(fā)出去后，反響怎么樣？

Charlie：博客發(fā)出去后上了 Hacker News 首頁，在 Twitter 上也被大量轉(zhuǎn)發(fā)，制造了相當多的興奮和關(guān)注。上 Hacker News 首頁這件事，我覺得一半靠運氣，一半靠實力。它有幫助，但不是成功的必要條件，更不是保證，關(guān)鍵是你如何利用這波流量。

我當時采取的策略是極度積極地響應社區(qū)。有人提 issue，我會盡量在一天之內(nèi)確認問題、修復并發(fā)布新版本。這種“一天內(nèi)響應-修復-發(fā)布”的循環(huán)非常強大，你每完成一次，就贏得一個支持者，項目勢能就增加一分。

同時，一些生態(tài)里的大人物也開始關(guān)注這個項目，比如 FastAPI 的作者 Sebastián Ramírez。他早期就說“這個挺有意思，我想用用”。我當時就問自己：“要讓他真正用起來，需要做些什么？”然后我就去逐一實現(xiàn)那些條件。

我其實一直在思考開發(fā)者營銷這件事。在工程師圈子里，“營銷”這個詞幾乎是個臟話。很多人覺得技術(shù)產(chǎn)品就該靠實力說話，最好的技術(shù)方案就應該自動勝出。但我有個可能很蠢的假設：GitHub 上有成千上萬個非常棒的項目，它們根本不知道怎么營銷自己，所以永遠沒人發(fā)現(xiàn)，永遠沒發(fā)展起來。我不知道這是不是真的，但至少看 Ruff 這個項目，我覺得營銷是值得認真對待的。

那么，具體怎么做呢？關(guān)鍵在于“10 秒內(nèi)抓住注意力”。無論是寫博客、寫 README，還是做任何宣傳材料，核心問題是：當一個人打開這個頁面，我只有 10 秒鐘讓他對我的項目產(chǎn)生興趣，讓他明白“這對我有什么用”。不需要一堆 emoji 和截圖，你需要的是在 10 秒內(nèi)講清楚“為什么這個項目值得你花時間”。

說起來有點沮喪，但這就是注意力經(jīng)濟的現(xiàn)實。我當年在 Spring 做生物醫(yī)藥的機器學習時，研究過 OpenAI 的博客。特別是 DALL-E 的那些老文章，即使你一個字都不讀，光看圖片和標題，你也能理解他們做了什么，而且會被震撼到。這就是我追求的：讓那些只讀標題、只看第一張圖的人也能帶走一個印象。當然也會有人從頭讀到尾，所以每個字都要精心打磨。但你必須接受：大多數(shù)讀者只會掃一眼。所以，你要想清楚：如何用誠實、真誠的方式，在幾秒鐘內(nèi)告訴別人“為什么你應該關(guān)心這個”。

Ryan：能舉個具體的例子嗎？比如你在 Ruff 的博客里具體做了什么？

Charlie：最典型的例子是那張 benchmark 圖。我們在博客里放了一張非常清晰的性能對比圖，在 Twitter 上被瘋狂轉(zhuǎn)發(fā)。那張圖本身就能說明一切，它不需要任何文字解釋，你一看就知道 Ruff 比競爭對手快多少。一張好的 benchmark 圖，在注意力經(jīng)濟里是無價的。我不是說它能賣錢，而是說它能瞬間抓住人們的注意力。你看到那張圖，腦子里立刻就會冒出一個念頭：“這太明顯了，發(fā)生了什么一目了然。”

Ryan：但我經(jīng)常看到那種圖，軸的起點不是零，而是故意從 50 或 100 開始。

Charlie：這就是所謂的“圖表犯罪”（chart crime），我們不會這樣。benchmark 本身其實非常復雜且充滿爭議，也許大多數(shù)用戶根本看不到這些爭議，但我每天都身處其中，因為性能優(yōu)化這件事太微妙了。你不得不思考：是帶緩存還是不帶緩存？這兩種情況下的性能表現(xiàn)天差地別。在不同的項目上運行，性能特征也會完全不同。我們在 UV 上就深有體會，有時候 UV 快得像閃電，但有時候安裝一個包時，瓶頸卻出在一個完全不相干的 C++編譯流程上。這時候你怎么準確地說“UV 快”？你幾乎不可能用一個數(shù)字或一張圖，準確捕捉所有不同場景下的真實表現(xiàn)。

但另一方面，如果你完全不向用戶傳達性能差異的意義，那又是一種失職。用戶需要知道：這個工具到底快多少？為什么快？這對他意味著什么？所以你必須在這兩者之間找到平衡。我覺得這其實非常難，很多人在這方面都栽過跟頭。但無論如何，不加任何方式去快速告訴用戶“這東西用起來是什么感覺”，那才是最大的失職。

為什么選擇 Rust？

Ryan：你提到那張圖，我作為工程師，看到它的第一反應是：“你是怎么做到這么快的？”然后我注意到你們的標語里寫著“用 Rust 寫的 Python 開發(fā)工具”。所以，我第一個好奇的問題是：為什么選擇 Rust？它的優(yōu)點和缺點分別是什么？

Charlie：坦白地說，我當初選擇 Rust 很大程度上就是因為跟風（hype）。當時 Rust 在開發(fā)者社區(qū)里非常火，大家都在談論它。在那個時候，我對不同生態(tài)系統(tǒng)之間的技術(shù)權(quán)衡了解得并不多，也沒有做過太多系統(tǒng)編程。我的印象就是：Rust 是一種編寫高性能軟件的、更易上手的方式，所以我因為這個原因開始了。

但回過頭來看，我認為這是一個極其正確的決定。現(xiàn)在我對 Rust 有了更多的經(jīng)驗，我確實覺得，如果當時我嘗試用 C 或 C++來寫這個項目，我可能早就放棄了。因為即使到現(xiàn)在，我仍然覺得那些生態(tài)系統(tǒng)更令人望而生畏、更難上手、更難學習。

我經(jīng)常覺得，Rust 一個被嚴重低估的優(yōu)勢就是它的工具鏈。因為你一上來就用 Cargo，所有事情都通過它來做。如果我看到一個我們使用的 crate，我想給它的倉庫提交一個 PR，我極其有信心，我克隆下來就能弄清楚如何運行和構(gòu)建，幾乎不需要做任何額外工作。能做到“git clone然后cargo run、cargo build、cargo test”就能跑起來，這其實非常了不起。

尤其對于像我這樣剛接觸系統(tǒng)編程的人來說，我不想去搞清楚整個 C++工具鏈、構(gòu)建系統(tǒng)那一堆亂七八糟的東西。Rust 在這些方面非常“有主見”（opinionated），確實有很多東西很難學，但它讓我可以把精力集中在那些真正應該難學的事情上，而不是花時間在“我怎么讓這個東西編譯通過、跑起來”這種你根本不想花時間的事情上。

這對我們來說是一個非常成功的賭注。Rust 隨著項目規(guī)模的增長，擴展性非常好。而且，OpenAI 也在大量使用 Rust。作為一個為開發(fā)者構(gòu)建工具的人，我對 Rust 非常看好。它已經(jīng)增長得非常迅猛，我認為它還會繼續(xù)快速增長。

但同時，我從來不是一個對生態(tài)系統(tǒng)特別教條的人，我認為所有這些生態(tài)系統(tǒng)都有可取之處。比如 Zig 正在發(fā)生的事情就非常有趣，我希望有更多時間去深入研究它，形成更細致的觀點，我確信它在某些方面比 Rust 做得更好，Rust 也應該向它學習。同樣，很多人用 Go 也取得了巨大的成功，這也很棒。我喜歡用 Rust，不過也有不少抱怨，但我把這些抱怨看作是需要改進的地方，尤其是隨著 LLM 改變了我們構(gòu)建軟件的方式。

Ryan：所以聽起來，你今天根本不會考慮 C 和 C++？因為它們的工具鏈不夠好。而 Zig、Rust 和 Go，你是在它們之間做不同的權(quán)衡？

Charlie：沒錯。我真的不太理解，除非有非常特定的技術(shù)原因，或者你正在維護現(xiàn)有軟件，否則我基本不明白為什么要在新項目里用 C 或 C++，我本人肯定不會這么做。當然，如果你對那個生態(tài)系統(tǒng)非常熟悉，那另當別論。但如果你是一個想學系統(tǒng)編程的新手，或者你對這些語言同樣熟悉，那我真的不理解你為什么要選 C/C++。我知道這么說會被罵，但我無所謂。

我現(xiàn)在非常在意 Rust 給我的那些東西，而這些是我以前根本不在乎的，比如內(nèi)存安全。 當我開始做 Ruff 的時候，我甚至不知道內(nèi)存安全是什么，也完全不在乎。但現(xiàn)在我覺得這簡直太棒了。我想構(gòu)建安全的東西，不會在用戶面前崩潰，速度極快，性能極強，不需要做任何妥協(xié)。在 Rust 里我可以做到這些，所以對我來說，它雖然不是完美的語言，但它是目前我最喜歡用的語言。

AI 時代的代碼重寫

Ryan：在當今世界，你幾乎可以把現(xiàn)有代碼完全轉(zhuǎn)譯到你選擇的任何語言里，比如我見過有人把 Zig 一次性轉(zhuǎn)成 Rust。如果你覺得另一種語言更好，你會考慮把你構(gòu)建的那些開發(fā)工具全部重寫嗎？比如從 Rust 轉(zhuǎn)成 Zig 或 Go？

Charlie：這個問題很微妙，是因為現(xiàn)在構(gòu)建軟件的方式變化太快了。我直到去年圣誕假期才開始真正用 Agent 編程，到現(xiàn)在也不過幾個月。但如今我?guī)缀醪辉诰庉嬈骼镏苯痈拇a了，所有修改都通過 Codex 完成，即使是小改動也是用提示詞驅(qū)動。這完全是另一種工作方式，而且變化發(fā)生得如此之快，我甚至無法預測六個月后會是怎樣。

所以對于 Bun 那樣的重寫，我現(xiàn)在不會做，但我很欣賞他們敢于實驗和突破邊界的精神。這引發(fā)了我?guī)讉€層面的思考，首先是代碼理解問題：如果代碼被完全重寫，作為人類你可能就不再理解任何代碼了。雖然他們嘗試做非常直接的轉(zhuǎn)譯來保留抽象層，但問題是，如果團隊已經(jīng)重度依賴 Agent 開發(fā)，理解代碼到底還重不重要？

第二個更核心的問題是：當你做這樣的重寫時，你是在用已知問題交換新的未知問題。假設合并后你關(guān)閉了 GitHub 上的 50 個 issue，這很好，但你可能同時引入了 50 個之前不存在的新 issue。因為即使是最好的測試套件，也只是程序正確性的近似逼近。希拉姆定律（Hyrum's Law）告訴我們：任何實現(xiàn)細節(jié)最終都會變成某些人依賴的行為。即使沒被編碼為行為的東西，也會成為你 API 的一部分。這意味著即使測試全部通過，程序隱含的行為可能已經(jīng)改變。而最糟糕的是，你最終把這個問題推給了用戶，他們不得不先遇到問題、再報告、再幫你去排查，這是我對自動重寫最大的擔憂。我其實相當信任模型的能力，但真正可怕的是如何安全地推出這種變更。

第三個層面關(guān)乎開發(fā)方式的選擇。現(xiàn)在的軟件開發(fā)光譜已經(jīng)變得非常寬，從 Andrej Karpathy 定義的 Vibe Coding，到完全不使用 LLM，中間有無數(shù)種可能。我對不同項目采取完全不同的方法，比如上周我寫了個個人用的自定義 Rust linter，全程由 GPT-5.5 完成，我一行代碼都沒讀。因為那是只有我們內(nèi)部使用的工具，很容易判斷正確性。但 UV 被數(shù)百萬工程師和無數(shù)公司依賴，對它的任何變更都必須極其謹慎。關(guān)鍵在于你做的項目是什么、你對用戶負有多大責任。這不是在評價 Bun 的做法，而是我思考如何在不同領域突破邊界的方式。

Ryan：這讓我想到代碼變更的風險管理。如果是只有你我使用的內(nèi)部工具，我可能直接打上“沒問題”的戳就發(fā)布了。但如果是影響客戶結(jié)賬的關(guān)鍵系統(tǒng)，我們可能需要兩人審核、多重驗證。所以這個光譜現(xiàn)在多了一個新層級——人類一眼都不看，直接發(fā)布。

Charlie：我有時候會去 Bun 的倉庫看看，發(fā)現(xiàn)它跟我們的倉庫完全是兩個世界。最明顯的是，Bun 倉庫的頭號貢獻者是一個 bot。有時候你點開人類提交的 PR，看到人類賬號在來回評論，但很明顯那些評論全是 agent 寫的。你會忍不住感嘆：“這太不一樣了。”我很高興有人在嘗試不同的軟件構(gòu)建方式，不過我不確定自己是否準備好那么做，但我認為很多事都會改變。

Ryan：那你們會在自己的倉庫里屏蔽這種純 agent 提交的貢獻嗎？

Charlie：會的。我們現(xiàn)在有一套 AI 政策，目的不是反 AI，而是要過濾掉那些凈負面貢獻，保留真正有用的東西。你想，一個貢獻者進來，貼了一條 agent 寫的評論，我們問他問題，他直接把 agent 的回復粘貼過來。這有什么價值？我們還不如直接問 agent 本身。我們需要的是人類貢獻者的洞察力、復現(xiàn)步驟、以及我們能喂給 agent 的關(guān)鍵信息，在 GitHub issue 上跟 LLM 對話毫無意義。所以我們的政策很簡單：你提交的東西，你自己得理解。我知道這聽起來門檻很低，但實際并不低。

Ryan：那你怎么監(jiān)管呢？

Charlie：如果看不出來它是 agent 寫的，那我覺得應該沒事。

目前還是有很多“特征”可以識別，agent 寫的回復往往過于詳盡、格式過于規(guī)范、用詞過于學術(shù)，甚至會編造一些人類不會用的術(shù)語，塞滿各種鏈接。簡單說，在沒必要的地方投入了遠超人類的“努力”，那幾乎就是 agent。

Zig 項目的 LLM 政策比我們嚴格得多，完全禁止任何 LLM 編寫的代碼進入項目。而我們這邊，我自己的 PR 現(xiàn)在全是 LLM 寫的。Zig 團隊發(fā)過一篇博客，提出了一個概念叫“貢獻者撲克”——你像下注一樣在貢獻者身上下注。傳統(tǒng)開源模式下，一個新貢獻者來了，你給他反饋，他學習、改進，下一次提交的 PR 質(zhì)量就提升了。這種反饋會累積，他會成長為未來的維護者，本質(zhì)上是在投資“人”。但 agent 寫的 PR 完全打破了這種循環(huán)：你給反饋，他把反饋塞回 agent，生成一個新版本，然后合并。沒有累積，沒有成長。

更關(guān)鍵的是，提交一個“看起來合理”的 PR 的成本已經(jīng)降到了零，但審查和驗證一個“看起來合理”的 PR 的成本依然很高，甚至更高。以我們的類型檢查器 TY 為例，這是我做過最難的項目之一，架構(gòu)極其復雜。如果有人給 TY 提交了一個“看起來合理”的 PR，他可能只花了 2 分鐘寫，但我們需要花 1 小時去理解它，這種不平衡正在嚴重破壞開源社區(qū)的生態(tài)。我不知道怎么解決，它只會越來越糟，直到我們找到新的方法。

Ryan：聽起來審查正在成為越來越大的瓶頸。那 Bun 的重寫呢？你知道那些代碼是人類審查過的，還是直接就是 YOLO 式的……？

Charlie：我覺得沒有經(jīng)過人類審查。至少在我錄制這期節(jié)目的時候，Jared 還沒發(fā)布那篇博文。他一直在開玩笑，說那篇博客文章花的時間比重寫還長。我其實對那篇博文很感興趣，因為我認為他們確實有一套相當成熟的重寫方法論，讀起來會很有意思。這絕不是那種“用 Rust 重寫這個”的單一 prompt。從我看到的 PR 來看，我印象中重寫實際上分了不同的階段，每個文件都要經(jīng)過幾個不同的階段，每個階段都有驗證正確性的方法。所以答案是：沒有人類審查。我不認為有人真正讀過那些代碼的實質(zhì)性部分，這基本上是不可能的。

Ryan：那如果我們倆今天都同意 Zig 客觀上比 Rust 更好，然后你團隊里有人說“我可以把這個用 Zig 重寫一遍”，你會阻止嗎？

Charlie：我想我會阻止。我不確定這樣做對不對，但我覺得我們團隊還沒到那個階段。也許有一天我們會走到那一步，但現(xiàn)在我們?nèi)匀挥X得深入理解我們的代碼、工具鏈和生態(tài)有巨大的價值。

性能優(yōu)化與代碼質(zhì)量

Ryan：你構(gòu)建的所有東西，都比當時可用的方案快一個數(shù)量級。Rust 在多大程度上貢獻了這種性能提升？

Charlie：這取決于項目。在 Ruff 中，很大一部分功勞確實歸 Rust。但隨著時間的推移，我們在這方面又有了很大改進。你可以看看項目的歷史，基本上項目是越來越快的。有時候也會有回退，但總體趨勢是向上的。即便都用 Rust 寫，不同的實現(xiàn)方式也會帶來截然不同的性能表現(xiàn)。所以我的看法是，Rust 更像是一個性能地板或基線，你用它寫出來的程序，基線性能會顯著高于其他語言。

但即便如此，你仍然需要深入思考性能和架構(gòu)設計才能獲得更多收益。比如同一個程序，用 Rust 和 Python 實現(xiàn)最接近的版本，Rust 版本肯定更快。但你完全可以在這個 Rust 版本上繼續(xù)優(yōu)化，可能還能再快 10 倍。即使在 Rust 生態(tài)內(nèi)，仍有巨大的優(yōu)化空間。我剛開始做 Ruff 時，目標之一就是學習 Rust，所以寫了很多爛代碼，這沒關(guān)系，我發(fā)布的產(chǎn)品對人們很有幫助。但隨著時間的推移，它變得越來越好，性能也越來越高。

在 UV 這個項目上，架構(gòu)創(chuàng)新帶來的貢獻甚至超過了 Rust 本身。UV 是一個包管理器，它要做大量的 I/O 操作，下載網(wǎng)絡文件、解壓縮、寫入磁盤、移動文件。而 linter 不需要做這么多 I/O，它只需要讀取所有文件。包管理器幾乎全是 I/O，你需要以極高的效率完成這些操作。所以在這里，Rust 固然重要，但 UV 中更多的性能提升來自于我們對架構(gòu)的深入思考，比如緩存的設計就非常刻意，重復安裝同一個包幾乎是瞬間完成的，這完全得益于緩存布局的方式以及從緩存安裝到項目的方式。這意味著如果你之前安裝過某個包，再次安裝的成本極低，無論是磁盤空間還是時間。這種設計思路與之前所有的 Python 包管理器都截然不同。

所以，無論你用 Rust 還是 Python 寫代碼，永遠都有思考性能的空間。你總是可以讓東西更快或更慢。即使是用 Python 寫，通過更深入地思考性能和設計，你也可以讓事情快得多。這是多種因素的混合，取決于具體項目。

Ryan：在整個項目開發(fā)過程中，有沒有哪幾件事在技術(shù)實現(xiàn)上最具挑戰(zhàn)性，或者讓你覺得最有趣？

Charlie：我特別喜歡我們團隊 Andrew（網(wǎng)名 BurntSushi，Ripgrep 作者）做的一個優(yōu)化，關(guān)于我們?nèi)绾伪硎景姹咎枴?/p>

當解析和安裝一個非常復雜的 Python 項目時，我們需要解析并創(chuàng)建大量的版本對象，比如 1.0.1、1.0.2 這種，我們程序內(nèi)部會生成海量的版本對象。結(jié)果發(fā)現(xiàn)，分配這些內(nèi)存的開銷大得驚人，尤其是考慮到我們操作的次數(shù)。Andrew 想出了一個表示方式：用單個 u64 整數(shù)就能表示 90%以上的版本，效率高太多了。

在 TY 方面，有很多非常有趣的性能工作正在進行，尤其是讓它支持增量檢查。TY 的設計目標就是一個類型檢查器加語言服務器，整個系統(tǒng)是高度增量化的。核心想法是：如果你在文本編輯器里打開一個文件，你肯定不希望為了分析這一個文件，就必須把整個項目、所有依賴、每個文件都重新類型檢查一遍，因為你根本不需要。但另一塊是：如果你同時打開兩個文件，編輯了其中一個，你只希望重新計算必須重新計算的部分。你不想因為保存了一個文件，就讓整個代碼庫重新類型檢查一遍。尤其是你在 PyTorch 這種大項目里工作時，如果每次保存都要等兩秒鐘才能拿到分析結(jié)果，那體驗就太糟糕了。

這有點像宏觀設計層面，整個系統(tǒng)基于一個叫 Salsa 的框架構(gòu)建——這也是 Rust Analyzer（Rust 的流行語言服務器）使用的框架，我們后來有意無意地成了 Salsa 的主要貢獻者。整個架構(gòu)圍繞查詢展開，這在架構(gòu)層面非常有意思。增量部分確實很難，因為你需要一個方式，當數(shù)據(jù)變化時，只讓數(shù)據(jù)流經(jīng)依賴圖中受影響的那部分節(jié)點，這花了很多功夫。

我最近花了很多時間在 Codex 上做優(yōu)化，因為它特別擅長那種微觀層面的調(diào)優(yōu)。在 TY 里，我們不僅要考慮速度，還要考慮內(nèi)存，如果你在一個超大型項目上工作，你不會希望語言服務器吃掉幾十 GB 的內(nèi)存。所以理想情況下，它必須既快又省。比如我可以設定一個目標：“試試在這個項目上把 Salsa 的內(nèi)存占用降低 1%。”然后它就能想出非常合理的方案。我覺得這非常酷，因為它幾乎能持續(xù)地優(yōu)化你的軟件。

Ryan：關(guān)于版本號的優(yōu)化，你覺得如果你直接丟給 Codex，說“嘿，別搞壞東西，但把內(nèi)存降下來”，它自己能想到那個方案嗎？還是說那超出了它的能力范圍？

Charlie：以我的經(jīng)驗，如果你只是簡單地要求降低內(nèi)存或提升性能，它通常只會給出邊緣性的改進，而不是更大的重新設計或根本性的重新思考。但如果你通過提示去引導和協(xié)作，你是可以到達那些更大的設計的。比如你可以問：“我們是不是應該更大膽地想想，為什么非要用這種方式來表示數(shù)據(jù)？”這樣你就能引導它產(chǎn)生更大的想法。

如果通過提示一步步來，先做性能分析，找出時間花在哪兒，比如“版本解析和版本分配占了大量時間”，然后問“我們怎么能更緊湊地表示這些？”它可能會先給出一些微觀優(yōu)化，比如“這個字段可以和那個字段合并”之類的。但如果你不斷追問，它是有可能到達那個方案的。不過，這不是它默認就能想到的。

這讓我想起 Mitchell Hashimoto（HashiCorp 的聯(lián)合創(chuàng)始人，現(xiàn)在在做 Ghostty），他上周發(fā)了一條很有洞察力的推文。他寫了一個渲染器，故意寫得很糟糕，然后讓 LLM 去優(yōu)化，結(jié)果 LLM 把它優(yōu)化快了 10 倍。但實際上，他自己手寫的版本比 LLM 優(yōu)化后的版本還要快 100 倍。如果你不先用大腦從第一性原理去思考“這個東西理論上應該有多快”、“系統(tǒng)應該怎么工作”，那你就會把那些積累起來的，我不會稱之為“slop（垃圾代碼）”，但就是那些東西，直接交付出去，然后說“哦天哪，我把它優(yōu)化快了 10 倍”，但實際上它應該能快 100 倍。所以我覺得，仍然有很大的空間需要你用大腦去思考。

我在這方面其實也很掙扎。我大量使用 Agent，也在某種程度上推動團隊更多地使用 Agent，其中一部分原因，是因為我們?yōu)檐浖こ處煒?gòu)建工具，而我們的很多用戶現(xiàn)在也在用 Agent。如果我們做的一切好事，都源于對用戶的深刻理解，那我們就必須跟上這個趨勢。

但現(xiàn)在出現(xiàn)了一個很有意思的現(xiàn)象。我們團隊有人直接跟我說：“以前你提 PR，我基本掃一眼就過了，因為我對你的工作有很高的信任度。但現(xiàn)在你提 PR，我得逐行細審，因為那些代碼不是你寫的，是 Agent 寫的。”我當時的第一反應是：“這真的很值得深思。”他們說得完全對。這種信任的瓦解不只發(fā)生在別人身上，我自己也經(jīng)歷同樣的事。有時候我晚上睡一覺，第二天早上起來看自己昨晚提的 PR，心里想的卻是：“等等，這代碼寫得也太爛了吧？”你很容易就騙過自己，以為自己交付了和之前同樣標準的工作，但實際上根本不是。

Ryan：如果生成的是純粹的 slop，那反而好識別。但最難的是那個灰色地帶，代碼看起來能用、可接受，但它根本達不到你以前為自己設定的那個質(zhì)量門檻。你團隊里有哪些策略，真正有效地對抗了這種“灰色地帶 AI slop”？

Charlie：我希望未來能到一個狀態(tài)——如果你提的 PR 全是綠色通過，那它被合并的概率極高，這意味著大部分重要的事情都有自動化驗證來兜底。我們在項目中做了很多這類工作，比如在 TY 項目中，每個 PR 都會在 Valgrind 和 CodSpeed 上運行大量 benchmark ，覆蓋內(nèi)存使用、模擬時間、墻鐘時間。還有一整套生態(tài)測試，每次提 PR，都會對比前后生態(tài)項目中所有診斷信息的差異，新增了哪些錯誤、修復了哪些錯誤。這些自動化驗證在 Agent 出現(xiàn)之前就很重要，沒有它們我們幾乎沒法開發(fā)。

現(xiàn)在還有一個新假設：團隊成員提 PR 之前，應該已經(jīng)用 Codex Review 審核過好幾輪了。 這其實很簡單，就是在 Codex 里跑個/review命令。因為現(xiàn)在提交 PR 后，第一件事就是讓 Codex Review 跑一遍，它確實能發(fā)現(xiàn)不少問題。

所以，一個方向是建立更多自動化系統(tǒng)來保證代碼正確性，包括持續(xù)優(yōu)化agents.md文件，如果審核中反饋的問題 Agent 沒有解決，就要想辦法讓 Agent 學會，甚至培養(yǎng)一些團隊共享的 skill，這些都不復雜。另一個方向是確保自己投入精力去創(chuàng)建高質(zhì)量的 PR。聽起來標準很低，但我真的應該理解 PR 里的每一行代碼。我還會在 GitHub UI 里自己審核一遍 PR，如果你像審閱者一樣打開文件從頭讀到尾，往往能發(fā)現(xiàn)本地 diff 時忽略的問題，這非常有用。

還有就是把 skill 編碼化，把我和 Agent 經(jīng)常犯的錯誤寫進 skill 里，比如最近我常收到這樣的反饋：“這個 if 語句想捕獲什么場景？如果我把它注釋掉，所有測試都能通過。”于是我就在提 PR 前加了一道工序：讓 Agent 檢查“這些條件判斷是否仍然相關(guān)，還是之前重構(gòu)時遺留的？”我還在學習，但這些是我正在做的事情。

我覺得現(xiàn)在做軟件開發(fā)真的挺難的。很長一段時間里，我一直有個恐懼：AI 會讓我們更高效，但編程會變得沒那么有趣，因為我就是熱愛編程本身。我當時想，“天哪，以后我得把所有時間花在審查代碼和提示這個總犯錯、但最終確實更高效的蠢 Agent 上。”

不過，我現(xiàn)在的感受其實比幾個月前好多了。我想 Agent 在變好、工具在變好、我自己也更適應了，這是一方面。另一方面是，我越來越欣賞與 Agent 協(xié)作所解鎖的那些事情。比如運行實驗的成本變得極低，有太多事情我一直想嘗試，或者一直想回答的問題，現(xiàn)在幾乎可以瞬間得到答案。

舉個有點傻的例子：在 UV 項目中，所有東西都是快照測試，基本上我們所有的測試就是運行 UV 然后驗證輸出。這意味著我們有大量的測試，測試輸出最終會留在測試文件里。所以我們有一個叫lock.rs的 Rust 文件，里面全是 UV lock 的測試，非常長，因為所有 lock 輸出的快照都嵌在測試里。我當時想：“如果我們把快照存在單獨的文件里呢？這樣會不會讓編譯更快？因為從技術(shù)上講，那些快照也是 Rust 代碼，如果移走它們，構(gòu)建會不會變快？”

我一直想做這個實驗，但作為人類手動去做會極其痛苦，因為你得轉(zhuǎn)換所有測試。結(jié)果我只是讓一個 Agent 在后臺做這件事，同時我去干別的。然后，我得到了一大堆數(shù)據(jù)，答案有點微妙：如果你只是在迭代快照輸出，確實有好處，因為不再需要重新編譯整個程序。但我說這個的重點是，我現(xiàn)在整天都在做這種實驗：嘗試那些以前很難、成本很高才能回答的問題。從實驗到生產(chǎn)還有真正的工作要做，但能做的事情完全不一樣了。

我越來越意識到，我從構(gòu)建軟件中獲得的大量價值其實被保留了下來。因為其中一部分是仔細思考一個數(shù)據(jù)結(jié)構(gòu)的布局，很大一部分是合并一個關(guān)閉用戶問題的 PR，我從真正修復和改進某個東西中獲得巨大滿足感，而不僅僅是敲出代碼。所以，對于那些覺得與 Agent 協(xié)作失去了什么的人，我真的很能共情。但比起幾個月前，我現(xiàn)在對與 Agent 一起工作的感覺好多了。

初級工程師在 AI 時代的困境

Ryan：你剛才在性能優(yōu)化那個例子里提到，如果直接放 Codex 出來，它擅長做局部優(yōu)化，但不太擅長系統(tǒng)級的優(yōu)化。這讓我想起你發(fā)過的一條推文。你說：“我有點擔心，如果我在沒有扎實軟件工程基礎的情況下使用這些工具，會產(chǎn)出多少垃圾代碼。”

Charlie：我現(xiàn)在仍然擔心這一點。

Ryan：這讓我想起 Mitchell Hashimoto 發(fā)的那條推文——“Codex，去干這個”和“你像工具一樣揮舞它，不斷往正確方向戳”之間，存在巨大的差別，你怎么看？

Charlie：成為一名優(yōu)秀的軟件工程師，比以往任何時候都更有用。我們團隊里那些工程能力最強的人，即使在使用 Agent 時也是最有效的。現(xiàn)在有很多關(guān)于“Token 最大化”的討論，公司應該搞 Token 排行榜嗎？我覺得，Token 排行榜會創(chuàng)造糟糕的激勵，讓人們盡可能多地消耗 Token。我們內(nèi)部確實可以查 Token 使用量，但我并不關(guān)心誰用了最多的 Token。你會發(fā)現(xiàn)團隊里最高效的人，往往確實用了很多 Token。這不是因果關(guān)系，但很多優(yōu)秀工程師能夠非常有效地使用 Agent，從而放大自己的技能。

現(xiàn)在對初級工程師來說，真的非常難。我目前跟初級工程師接觸不多，Astral 團隊很小，我們傾向于招聘資深工程師。我很難想象，如果我是一個剛?cè)胄械墓こ處煟业膶W習迭代回路會是什么樣？我大概只能從 Codex 那里學習，而不是反過來。對我來說，很多時候其實是我在指導 Codex，糾正它，為它提供安全護欄。而如果我是初期工程師，太容易掉進使用 Agent 時發(fā)生的那些壞事情里了。

沒預料到的快速創(chuàng)業(yè)歷程

Ryan：你當初用 Rust 構(gòu)建了那個概念驗證，反響很好，但為什么圍繞它創(chuàng)辦了一家公司？融資過程又是怎樣的？背后的動機是什么？

Charlie：其實是我離開 Spring 的時候，被一個非常親密的朋友說服了，他差不多同一時間從 Meta 離職，他說：“我們應該一起創(chuàng)辦一家公司。”我說：“行。”當然，事情沒那么簡單。我離職后，我們進入了所謂的“想法迷宮”，不知道具體要做什么。我們花了很多時間探索想法的維恩圖，有些東西他感興趣而我覺得沒意思，反之亦然。中間有一些交集，我們就去探索那些交集。

但在所有業(yè)余時間里，我都在搞開發(fā)者工具，因為那才是我真正感興趣的，這和他的方向不太合拍。那時我在做 Ruff，還搞了好幾個 GitHub 上的其他項目，我對 WebAssembly 很感興趣，寫過一個 TypeScript 的 CI/CD 工具包，可以把 pipeline 轉(zhuǎn)譯成 Docker。

關(guān)鍵轉(zhuǎn)折點在于：我決定先和投資人建立關(guān)系，但不想急著融資，因為我還沒想清楚到底要做什么。我的策略是：先認識一些喜歡投這類東西的人，等三到六個月后再聯(lián)系他們，說“我們之前聊得很好，現(xiàn)在我在做 xxx”。我確實聯(lián)系到了幾位投軟件基礎設施和開發(fā)者工具的投資人，聊得不錯。但問題是，事情發(fā)展得太快了。

我實際上沒預料到這么快就開始融資。Ruff 在快速成長，但當時我心里想的是：“我不知道這怎么變成一家公司”，但投資人們讓我相信了，我挺感激的。他們還說服了我另一件事，如果我不喜歡，六個月后可以退出，把錢還回去。這招很聰明，因為我大概率永遠不會那么做，但它讓我感覺壓力小了很多。

于是我開始全職搞 Ruff。我和早期投資人進行了很多長時間的對話，討論我的想法，后來我寫了一個產(chǎn)品路線圖。然后他們說：“我們想投你，這是條款。”我當時想：“哇，好吧，看來這事真要成了。”我從來沒做過這種事，整個職業(yè)生涯就是個普通軟件工程師，突然就要創(chuàng)辦公司了。

有趣的是，決定全力以赴創(chuàng)辦公司這件事，其實沒那么大壓力，真正的壓力是在公司開始成功后到來的。一開始我沒什么可失去的，但后來公司走上正軌，我有了一個 20 人的團隊依賴我，我就開始想：“公司真的在運轉(zhuǎn)了，接下來會怎樣？”作為一個創(chuàng)始人，我其實挺風險厭惡的，但創(chuàng)辦公司的決定比后來那些壓力大的決定更容易做得多。整個過程發(fā)生得非常快，幾乎是無意的，和投資人形成了一種共生關(guān)系，這完全出乎我的意料。

Ryan：我以為創(chuàng)始人會渴望融資，求著“請投我”，但投資人反而是主動來找你的？

Charlie：我們做了三輪融資：種子輪、A 輪和 B 輪。我們甚至從未公開宣布過 A 輪和 B 輪，它們是在收購公告里才被提到的。原因很復雜，基本上就是一直有理由讓我們想再等等。對我來說，這總感覺是很多額外的工作，而且我覺得這不是最重要的事。公司運營得很好，我們不需要那種營銷。我們最后確實計劃過宣布，但還沒做就被收購了。每一輪融資基本上都是投資人主動發(fā)起的，因為公司發(fā)展得好，人們想投。我一直有點保守，沒有很激進地去籌錢。但我們很幸運，在做的東西讓人們有很強的信心。

Ryan：這給了你很大的談判籌碼，最好的位置就是你可以隨時走人，你甚至不需要它，他們來找你說“請收下這筆錢”。

Charlie：我不會說自己是個優(yōu)秀的談判者，但至少我手里有張好牌。而且我們很幸運，投資人非常棒，超級支持。他們和我想要的公司發(fā)展方向完全一致，從來沒有沖突，從來沒有壓力讓我做任何特定的事情，只有支持。可能唯一的持續(xù)反饋是：我本可以在規(guī)模擴張和增長方面更激進一些，但我喜歡我們運營的方式。

開源與商業(yè)產(chǎn)品的平衡

Ryan：我猜投資人投資時，看的是未來的收入承諾。但你們公司怎么賺錢呢？畢竟你們把軟件免費送出去了。

Charlie：我們在去年八月推出了商業(yè)產(chǎn)品，叫 PYX，它有點像 UV 的托管版本。很多 UV 用戶會購買私有注冊表軟件，而不是使用公共注冊表，要么是出于安全考慮，要么是需要發(fā)布自己的私有工件。于是，我們建了自己的私有注冊表，對 UV 有一流支持。這讓我們能解決 issue 跟蹤器里用戶用其他方案時遇到的一堆問題，也讓我們能做得很快，因為客戶端和服務器是垂直整合的，它們可以做一些特殊操作，變得非常快、非常易用。

我們花了一段時間來銷售這個產(chǎn)品，收入增長得相當不錯。當然，在這個 AI 時代，你總聽到“最快做到 1 億美元收入的公司”之類的故事，我們沒到那個級別，但我們確實能賣給一些大企業(yè)。最酷的是，因為我們做了開源，每個人都在用我們的開源工具，所以我們的銷售漏斗非常好，我們有一小批質(zhì)量極高的客戶。

整體思路是：繼續(xù)做開源，工具保持免費、開源、完全非商業(yè)化，然后我們構(gòu)建一些東西，當你用我們的工具時，自然就會需要。比如你用 UV，你大概率會遇到私有注冊表的問題，我們就賣給你注冊表。這個注冊表只是平臺的一部分，我們計劃賣一整套東西，比如一個 Python 云，這就是我們正在構(gòu)建的方向。

收購的一個很酷的地方是，我們可以把平臺的一部分免費開放給大家。舉個例子：Python 社區(qū)有很大一部分人用 GPU，比如 PyTorch，整個 PyTorch 生態(tài)有很多軟件是構(gòu)建在它之上的。由于各種原因，這些工具的人機工程學不太好——安裝難，版本匹配難，還取決于你用什么 GPU、什么 CUDA 版本。我們嘗試用一種方式解決這個問題：構(gòu)建自己的發(fā)行版，有點像 Linux 發(fā)行版。我們預構(gòu)建了很多能協(xié)同工作的東西，提供給客戶。現(xiàn)在我們可以把這些東西免費開放給所有人，因為我們不再試圖建立一個獨立業(yè)務，而是想構(gòu)建能擴大整個生態(tài)的優(yōu)秀工具。

堅持原則，別信“標準答案”

Ryan：作為首次創(chuàng)業(yè)的工程師，有什么讓你驚訝的學習收獲，可以分享給其他想走這條路的人嗎？

Charlie：我其實不太喜歡別人給創(chuàng)業(yè)建議，因為這個行業(yè)太多幸存者偏差了。你給出完全相同的建議，可能會得到完全相反的結(jié)果。你去聽兩場演講，兩個極其成功的創(chuàng)始人給你完全矛盾的建議，你會想：“我真的不知道該怎么做。”我的看法是，你必須弄清楚什么對你來說是真的。

比如，遠程辦公還是線下辦公？你必須有一個原則并且堅持下去，兩者都可以很出色。我們整個公司都是遠程構(gòu)建的，進展非常順利。當然，我認為線下辦公有好處。但如果我們在線下，我絕對招不到我們組建的那個團隊。所以每件事都有取舍，你必須有原則，弄清楚什么與你產(chǎn)生共鳴。

我在這件事上很幸運。我盡量把最少的時間花在融資和見投資人上。我追求的是找到真正信任的投資人，而不是跟無數(shù)投資人周旋，讓他們互相競價來獲取最好條款。我的目標始終是：找一個真正信任的合伙人，拿到好條款，然后快速推進，把融資時間壓到最短。所以，想想你在乎什么，然后專注于此，這些事情沒有標準答案。

我剛開始創(chuàng)業(yè)時，很多人建議我找個聯(lián)合創(chuàng)始人，我基本沒聽。我知道他們可能是對的，但我心里沒有合適的人選。我不想強求，所以就沒找。后來我覺得，有個人和你一起在戰(zhàn)壕里摸爬滾打確實會有幫助，但你會用其他方式來彌補。比如，我經(jīng)常跟妻子傾訴，我對員工也比正常情況下更開放，這有好有壞，我會跟早期團隊分享很多東西，尤其是在需要建議的時候。我還嘗試建立其他創(chuàng)始人的圈子，特別是在紐約，我們有六七個人，每年爭取一起吃兩次飯。聽起來不多，但這成了一個非常有用的支持系統(tǒng)。

X 上很多人在討論“公司里每個人都應該每周工作七天嗎”之類的事情。我基本上一直在工作，這是我做的選擇，而且我非常滿意。但我不期望團隊里的人一直工作，我希望這是一個你可以通過正常工作時間取得巨大成功的公司，你的產(chǎn)出和表現(xiàn)會得到回報。我認為，沒有唯一正確的方式。不要過多關(guān)注你認為應該怎么做，想想你想怎么做，以及什么真正符合你希望的工作方式。

Ryan：你推薦什么書？技術(shù)類的，或者對創(chuàng)始人有幫助的。

Charlie：我讀的技術(shù)材料不多，但有幾場演講對我影響很大。比如 Zig 語言的創(chuàng)造者 Andrew Kelley 做過一場關(guān)于數(shù)據(jù)導向設計的演講，我學到了很多。那場演講講的是他們在 Zig 編譯器里做的設計決策，關(guān)于內(nèi)存、分配這些。我當時剛進入系統(tǒng)編程的職業(yè)生涯不久，看完之后心想：哇，這些人真的在乎他們在做什么，它讓我用完全不同的視角看待軟件。

Ryan：如果你能回到職業(yè)生涯的起點，剛畢業(yè)那會兒，你會給自己什么建議？

Charlie：這很難回答，因為有太多后見之明。我大概會告訴自己：你做的是正確的決定，別太焦慮。但很難說如果重來一千次會怎樣。比如，我離開學校去可汗學院工作時，心里有一部分在嘀咕：我是不是應該去大廠？我會不會后悔沒有大廠經(jīng)歷？可汗學院的薪水不錯，但大廠給的肯定更多。我看到朋友們拿著巨額獎金，心里有點不安，懷疑自己是不是選錯了。從長遠看，這個選擇回報了我。也許大廠也不錯，但可汗學院的經(jīng)歷才是我真正想要的。我覺得自己是基于正確的理由做的決定，所以很多事情，如果你基于原則做決定，最終會好起來的。

Ryan：我們開頭聊過，你之所以進入這個領域，是因為嘗試了各種不同的生態(tài)，有了更廣的視角。如果你去了 Google，只用 Google 的封閉系統(tǒng)，可能就不會有這種洞察。

Charlie：對。我在 Spring 待了四年半，離開時他們正要轉(zhuǎn)型，后來被 Genentech 收購。我們當初想建立一個瘋狂的藥物發(fā)現(xiàn)公司，專注于衰老，用計算機視覺，非常雄心勃勃。后來公司沒有達到所有夢想，我一度懷疑：我是不是浪費了時間？但最終我意識到：沒有。作為早期員工，我經(jīng)歷了所有階段，學到了如何運營自己的公司，所有技術(shù)積累都用到了我自己的公司里。所以，雖然我給出這些建議有點奇怪，因為一切最終都進展順利，但確實有很多時刻我懷疑過自己的職業(yè)選擇。事后看來，你只能回頭看才能把點串成線，所有東西加起來，讓我找到了我真正熱愛的事情，那就是構(gòu)建工具并為之投入。

訪談視頻原鏈接：

https://www.youtube.com/watch?v=Iw65FD4MGgs

聲明：本文為 InfoQ 編譯，不代表平臺觀點，也不構(gòu)成投資建議，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

大會限時早鳥票享 8 折專屬優(yōu)惠，現(xiàn)在報名立減 1160，更多詳情可掃碼或聯(lián)系票務經(jīng)理 13269078023 進行咨詢。