編譯｜宇琪、Tina
上一個世代的開發工具，是經過精雕細琢、一步步打磨出來的：行為穩定、互動克制，出了問題大多也在預期之內。可到了今天，Claude Code、Codex 這些軟體產品，把「用 AI 寫自己」當成預設路線。雖然 AI 的確讓寫程式更快了，但它並沒有自動解決「怎樣把一個複雜的軟體長期維護好」這件事。
Claude Code 就是一個很典型的例子。Anthropic 這套工具幾乎是從零開始做的，但團隊又長期堅持一種非常激進的內部方式：他們強調「Claude Code 的 100% 程式碼都要由 Claude Code 自己寫」，並且內部工程師和研究人員的各項任務，從大型程式碼重構、squash commit，到各種瑣碎的編碼工作，都依賴 Claude Code。
問題在於，當底層模型本身就是非確定性的，而承載這些能力的產品程式碼又是在這樣的開發方式下快速堆疊出來的，系統很容易陷入一種惡性循環。這一兩年裡，Claude Code 一直在快速擴展能力，互動邏輯越來越複雜，於是這個產品本身變得越來越不穩定：各種崩潰、各種詭異報錯，bug 越來越多，速度越來越慢。
事情甚至發展到一種頗為荒謬的狀態——與其回過頭去系統性修復這些效能問題，還不如直接收購核心依賴 Bun，把希望寄託在底層 runtime 團隊身上。換句話說，就是買下一整支 runtime 團隊，只為了盡量別讓自家的 CLI 工具動不動就吃掉 2GB 記憶體。
Cursor 的處境則是另一種複雜。它一開始面對的，就是一個極其龐大、極其複雜，而且並非自己從零塑造出來的程式碼底座——他們直接 fork 了 VS Code。這個起點決定了，它從第一天起就在打一場高難度戰役：你不是在空白紙面上做產品，而是在一個超大工程體系上做增量改造；你不僅要持續改出自己的差異化能力，還要長期維護這個分叉版本，並盡可能跟上游同步必要更新。只要做過大型工程的人都知道，這種事本來就極其痛苦，而且隨著時間推移，分叉只會越來越深，維護成本只會越來越高。
如果把這些現象放在一起看，一個越來越清晰的趨勢是：AI 編程工具，很可能會經歷一輪「大規模重寫潮」。
因為其程式碼庫本身在早期高速疊代中已經被帶進了一種越來越難逆轉的狀態。繼續往上疊功能，只會讓系統更加脆弱；真正的解法，往往只能是承認舊底盤已經失控，然後從零再做一套新的。
但這並不意味著所有團隊都會走到這一步。
OpenCode 提供了一個很有意思的對照。它同樣是在 AI 編程浪潮中構建出來的工具，但團隊採取了完全不同的策略：他們比過去更強調程式碼庫的一致性和約束，盡量確保沒有任何檔案偏離既定規範；同時，也大量採用那些約束更強、設計哲學更明確的工具與框架，並更堅定地踐行領域驅動設計。
他們認為在大模型參與開發的情況下，程式碼庫一旦變「髒」，後果會被放大。大型語言模型無法區分「舊模式」和「新模式」，它會將舊寫法當成正確示範並繼續生成不符合當前規範的程式碼。因此，不乾淨的程式碼庫帶來的負面影響，反而比過去更嚴重。
於是出現了一個有些反直覺的結果：他們的程式碼庫反而比以往任何時候都更乾淨，「甚至可能是我們寫過的品質最高的一批程式碼。」OpenCode 創辦人之一 Dax Raad 在播客中這樣說。
與此同時，他也並沒有放棄「手寫程式碼」這件事本身。「當我設計新功能或複雜架構時，寫程式碼本身就是思考過程。我不擅長寫一大段詳細規格說明，相反，我喜歡寫型別定義，嘗試函數組合，調整檔案結構，透過編寫程式碼來理解問題，這是大多數程式設計師長期以來的工作方式。我看不出有什麼理由要放棄這種方式，寫程式碼是我思考的方式。」
另外，他還從程式碼品質角度小小鄙視了一番 Claude Code：「Claude Code 做了一個原型，產品市場配對度極高，即便體驗不完美也會成功。但這並不意味著，所有人都必須犧牲品質，才能達到那個速度。」
基於該播客影片，InfoQ 進行了部分刪改。
OpenCode 的起源
Host：從去年 12 月開始，OpenCode 的發展非常迅猛。能不能帶我們回顧一下 OpenCode 是如何誕生的？
Dax： 我們公司做開源已經很多年了，一直以來我們都在為開發者構建工具，也經歷過不同公司在這個領域的興衰更替，因此在開源產品的構建方面積累了很多經驗。
我們之前的專案是 SST，雖然遠不如 OpenCode 現在的規模，但也算相當受歡迎。它給了我們完整的實踐經驗：如何啟動一個開源專案，如何讓它成功，日常如何運營，開源的優勢和劣勢分別是什麼。可以說，我們在這個領域深耕已久。
2025 年 2 月左右，我們實現了獲利。當時公司只有三個人。實現獲利之後，我們開始反思下一步該做什麼：是繼續深耕現有產品，還是探索新的方向？AI 顯然是這個時代的重要趨勢，如果完全忽視它會顯得非常不理智。
於是我們開始嘗試一些想法，探索 AI 能為開發者做什麼、在更廣泛層面又可以做什么。我們試過幾種方向，但都沒有真正形成產品。有些點子對我們自身很有幫助，但始終無法打磨成成熟產品。
差不多就在那個時候，我們開始用 Claude Code。其實在這之前，我們已經看過很多 AI 編程工具，比如 Cursor，當時已經挺火了。但我們團隊裡沒有人真正用下去。我們也試過，但感覺是在放棄一些我們原本喜歡的東西，同時又沒有獲得足夠多的收益，所以沒有堅持下來。
但 Claude Code 是第一次讓我們覺得，「这才是對的工作流」。在那之前，我們一直在做的事情就是把程式碼複製到 ChatGPT 裡，再複製出來，反覆來回。我們一直在想，為什麼這些東西不能直接連接到檔案系統？為什麼要這麼手動？
而 Claude Code 在這點上是一個很聰明的整合方式，把這些流程串在了一起。於是我們就覺得，如果這是第一個真正讓我們「用下去」的工具，那這件事可能就很重要了。
接下來我們就開始想：如果我們把自己在開源上的經驗用起來會怎麼樣？當時有一個很明顯的空白點——居然還沒有一個開源的 coding agent。於是我們就在想，能不能做一個開源的 coding agent，同時支援多種模型，因為我們知道這些模型之間的競爭會長期存在，而且會越來越激烈。
這個切入點，對我們來說是一個很自然的延伸。
Host：現在你的日常開發工作流是什麼樣的？發生了多大變化？畢竟你既是開發者，也是開發開發者工具的人，這種視角很特別。
Dax： 我們團隊成員都是 Vim 用戶，几乎所有工作都在終端完成，非常享受 Vim 的編輯體驗。遷移到 Cursor 對我們來說成本很高，因為雖然還能編輯程式碼，但文字編輯體驗在我們看來變差了，而獲得的收益又不足以彌補這種損失。
Claude Code 能「用下去」的原因在於，我們可以繼續用原來的編輯器，同时在一個單獨的空間裡做 AI 相關的事情，兩者不會互相干擾。這對我們來說很重要。
我覺得 Cursor 更像是一個過渡產品，它試圖把你從傳統編輯器直接帶到 AI 編程的那套新範式上。這當然有一些好處，但對我和很多人來說，它處在一個有點尷尬的中間狀態——我其實只想用編輯器來寫程式碼，不想讓各種 AI 功能到處彈出來。
用 Cursor 的時候，我會感覺各種建議無處不在，還有一堆新的 UI 面板，讓我很不適應。我更喜欢把 agent 當成一個「坐在旁邊的笨同事」：我偶爾看一眼它在幹嘛，給點反饋，然後讓它繼續幹，我自己也可以做別的事情，工作是可以拆開的。
所以 Claude Code 最大的優勢，其實就是它在編輯器之外提供了一個獨立空間。我們在做 OpenCode 的時候，也是在延續這個方向：在這個「獨立空間」裡，能把和 agent 互動這件事做得多豐富、多好。
現在我的工作流依然是：用 Neovim 編輯程式碼，用 Agent 處理需要 Agent 的任務。我們確實越來越多地使用 Agent，在編輯器裡的時間相對減少，但我遠沒有完全放棄手寫程式碼。我仍然大量使用編輯器，手動寫程式碼。
不再寫程式碼？
Host：現在有很多頂尖開發者聲稱自己已經不再從零寫任何一行程式碼了，很多人聽到這句話會理解為「編程已死」，你怎麼看？
Dax： 我對這種說法感到困惑。如果你問我手寫程式碼的比例是多少，我其實很難回答。我在不同工具之間不斷切換，很難量化。
如果有人說他們幾乎不用編輯器，完全在這些 agent 工具裡工作，不管是 OpenCode、Codex 還是其他類似工具，我會很驚訝。因為這些工具其實並不適合閱讀程式碼。那他們是完全不做程式碼審查嗎？還是把程式碼推到 GitHub 上再看？
另外，當我在設計新功能，或者做一些比較複雜的事情時，寫程式碼本身就是我思考的一部分。如果只是加一個按鈕、做一個簡單改動，那當然可以直接 prompt 一下，甚至都不用怎麼看生成的程式碼，因為它大概率和周圍的程式碼是類似的。
但當我在做全新的東西、或者在設計一個系統時，我需要透過寫程式碼來搞清楚到底該怎么做。我很難坐在那裡寫一大段詳細的 Spec，然後就讓 AI 去實現。我更習慣寫型別定義，嘗試不同函數怎麼組合，調整檔案結構，從這些過程中去理解問題，這其實也是大多數程式設計師一直以來的工作方式。
所以我看不出有什麼理由讓我停止這樣做，因為這是我搞清楚事情的方式。
所以當有人說「我完全不寫程式碼了」，我會有一點偏懷疑的態度。我覺得這裡面有一種心理因素：大家都感覺到一個巨大的變化正在發生，也擔心自己被淘汰，於是會傾向於說服自己「我已經在最前線了」。
再加上現在有一種敘事，說這個變化會淘汰很多人，只留下少數人。所以大家會有一種傾向，把某些局部的成功放大成「現在一切都可以這樣做」。會有一點誇張。
所以很難從這些說法裡判斷真實情況，因為背後摻雜了很多情緒和心理因素。
Host： 我覺得這點很好，因為我甚至不覺得這是「故意行銷」。比如 Claude Code 的早期作者之一 Boris，他說過自己幾乎不再從零寫程式碼，但他最近也說過「為什麼 Anthropic 仍然在招聘開發者」，說明人類仍然有大量參與，所以確實很讓人困惑。
Dax： 我同意，這並非出於惡意，而是興奮與不安交織下的結果，使人們難以準確表達現實情況。類似現象在以往新技術或新框架出現時也屢見不鮮，人們常宣稱其「徹底改變了工作方式」。對此，一個有效的判斷標準是直接檢驗其產出：許多情況下並無真正落地的產品，僅停留在嘗試層面；即便已有產品，品質也未必更優，甚至可能更差。在當前的 AI 編程實踐中亦是如此，一些人聲稱「完全依賴 AI 寫程式碼」，但其產出品質並不理想，這在一定程度上反映了當下的真實水準。
Host：OpenCode 和 Claude Code 似乎是直接競爭關係，你怎麼看？尤其是在 Anthropic 限制訂閱使用之後，你的看法有變化嗎？
Dax： 我不認為世界是零和的，大多數系統允許多方共贏。但在商業領域，競爭是真實存在的。商業更像體育比賽，大家爭奪對世界的不同願景。可能不會完全一方勝出，但競爭確實存在。不過，更重要的是「定位」。即便產品看似相似，定位可能完全不同。
OpenCode 的成功更多來自定位，而不僅僅是產品品質。我們判斷模型之間的競爭會持續，包括閉源模型和開源模型。價格會下降，競爭會越來越激烈。所以我們選擇：做一個不綁定單一模型的工具，這樣我們可以從模型競爭中受益。其次，我們要佔據「開源 coding agent 第一」的位置。歷史經驗表明，大多數開發工具最終都會走向開源，資料庫、編譯器、編輯器都是如此。
Claude Code 走的是垂直整合路線，這和我們的定位不同。從定位角度看，我們不一定直接競爭。但在價值觀層面，我們確實存在分歧，也希望證明我們的價值觀會帶來更好的結果。
Host： 作為一個同時使用過 Open Code 和 Claude Code 的用戶，我肯定會說 Open Code 的體驗非常好，我總結下來就是開源、可以在不同模型之間自由切換、沒有鎖定，以及先發優勢。
Dax： 這些確實是核心方向，並不只是口號，而是體現在大量具體細節裡。比如為什麼堅持開源？因為開源意味著會有更多人在不同環境中嘗試它。Open Code 從一開始就被設計成可以適配各種環境。哪怕是在企業強限制的筆記型電腦上，只能使用 Amazon Bedrock，也確保可以正常運行。開源的好處在於，雖然無法在內部復現所有環境，但社群可以。別人可以在真實環境裡測試、提交問題、甚至提交修復，因此能夠很好地覆蓋各種長尾場景。如果產品只有現在一半好，我們可能依然會取得類似的成功，因為成功更多來自定位，而不是單純的產品品質。
Host：OpenAI 至少在與你們的合作關係上採取了一條不同的路線。你們之間到底是什麼關係？為什麼 OpenAI 會採取不同的做法？
Dax： 這其實還是回到我們的定位。如果我們是開源選項，就有機會成為一種「標準」，讓其他人基於我們構建或把我們嵌入到他們的體系中。因此，在與 OpenAI 合作之前，我們已經在和 GitHub、GitLab、JetBrains 等溝通，希望他們將 Open Code 作為使用其大模型服務的一種推薦方式，因為我們在這方面投入更多，用戶反饋也更好。說服了部分公司後，我再去找 OpenAI，表示行業已有支持，詢問他們是否願意加入。
之所以選擇 OpenAI，是因為他們與 Anthropic 存在競爭，而在編碼領域 Anthropic 的心智份額更高。對 OpenAI 來說，支持我們既有公關收益，也能吸引更多用戶使用 Codex。我聯繫他們的時間點也恰逢 Anthropic 封禁 Cloud Max 和 Open Code 前後，他們因此看到了一個反向佈局的機會。
至於 OpenAI 是否真正認同這種模式，還是出於短期競爭動機，我並不確定。但我們擅長洞察各方激勵，在關鍵節點施加影響，促成對自身、用戶以及開源社群都有利的局面。本質上，就是理解激勵機制，並在博弈中創造更優結果。
Host：最近行業內有不少收購案例，OpenCode 會是下一個嗎？
Dax： 我們花了很多年尋找一個真正巨大的市場，而現在我們找到了。全球有三到五千萬開發者，我們的產品理論上可以服務所有人，這種機會很難得。因此，輕易把它交出去是很困難的決定。我們確實收到過不少收購邀約，但沒有認真推進。除非對方開出很高的價格，而 AI 領域確實存在誇張的收購案例。
有一次我在團隊群裡提到某家公司想收購我們，大家完全無視，繼續討論產品。我又提醒一次，有人說「讓他們多加一個零再來」。團隊真的想把事情做到底，而不是快速套現。
當然，幾年後如果增長停滯，我的態度可能會變。公司能做大，是因為創辦人多年保持動力。很多收購發生，是因為創辦人動力下降或前路太漫長，目前我們想走到最後。
Host：AI 讓我們速度更快，但是否積累了更多技術債？這種權衡是否發生了本質變化？
Dax： 這種權衡一直存在。很多時候，人們用「為了速度做了權衡」來解釋品質問題。但回頭看，大多數問題並非刻意權衡，而是經驗不足。
當我第一次做某件事時，95% 的問題來自經驗不足，而非有意識的取捨。下一次再做，同樣的時間內我能做得更好。
AI 也是如此，它提升了每個人的能力上限，但不應成為偷懶的藉口。我們仍然應該反思、改進，而不是因為「能跑起來」就覺得沒有問題。
有些人會說：「程式碼很糟，但我們寫得很快。」實際上，更有經驗的人可以在同樣速度下寫出更好的程式碼，這本質上還是能力問題。
Host：那從產品和用戶角度看，短期內定位和速度可能比品質更重要。比如 Claude Code，當時快速發布是不是合理？後來是不是應該做得不同？
Dax： 我認為每個人都會盡可能快地前進，並根據經驗做出不同的取捨。Claude Code 的情況是，他們做了一個原型，產品市場配對度極高，即便體驗不完美也會成功。這種情況很常見，但這並不意味著「所有人都必須犧牲品質才能達到那個速度」。
我們做 Open Code 的時間差不多，也構建了終端框架、Zig 實現、React 和 SolidJS 綁定、編譯為 bun 二進位等。我們之所以能在相似速度下交付更高品質，是因為這是我們熟悉的領域。當然，也一定有人可以做得比我們更好。總的來說，這個行業裡永遠存在比你差十倍的人，也永遠存在比你強十倍的人。
開發者的選擇
Host：當大量程式碼由 AI 生成時，你們如何在提升效率和保證品質之間取得平衡？比如在程式碼 review 方面，你會在不閱讀程式碼的情況下直接提交嗎？
Dax： 一個有些反直覺的現象是，我認為我們現在的程式碼庫比以往任何時候都更乾淨，甚至可能是我們寫過的品質最高的一批程式碼。原因在於，不乾淨的程式碼庫帶來的負面影響如今比過去更嚴重。
過去，程式碼庫的典型生命週期是這樣的：最初我們制定一套模式，幾個月後發現更好的實踐，於是通知團隊今後按新方式開發，但舊程式碼不會立刻重構。時間一長，程式碼庫中就形成多層歷史遺留風格。這在以前尚可接受，但現在不行了。因為大型語言模型無法區分「舊模式」和「新模式」，它會將舊寫法當成正確示範並繼續生成不符合當前規範的程式碼。
因此，我們比以往更加重視明確並嚴格執行統一模式，確保程式碼庫中沒有任何檔案偏離規範。某種程度上說，我們現在更在意程式碼品質，因為我們「僱傭」了一群勤奮但缺乏理解能力的 LLM，它們記憶力極強，卻無法自行判斷哪種模式更優。我們大量採用帶有強約束和明確設計哲學的工具與框架，並更堅定地踐行領域驅動設計。
至於是否閱讀所有程式碼，我的做法是基於風險判斷。在模式成熟且穩定的模組中，我對輸出結果有較強的預期感，通常只做快速檢查；而在結構尚未穩定的區域，我會更加謹慎地逐行確認，團隊大體也採取類似策略。
Host： 有些人聽到你不會逐行審查所有程式碼，可能會感到震驚。但回顧過去，即便在大型科技公司，也並非每一行程式碼都會被認真閱讀。很多時候，只要對開發者建立了信任，review 也會較為快速。某種程度上，你似乎是在說，也可以對 LLM 建立某種「信任」。
Dax： 我仍然算是偏保守的。即便在大型公司裡，至少有一個人真正理解程式碼——也就是編寫它的人。而如果是 AI 生成程式碼且沒有任何人理解它，那會令人不安。
我更傾向於用「風險感」來判斷。例如最近一次我較少審查的情況，是實現一個終端介面的新對話框。我從用戶角度做了充分測試，確認功能正常。由於底層構建對話框的基礎元件非常成熟，我判斷風險較低。雖然技術實現上可能存在細節瑕疵，之後也確實進行了清理，但短期內問題不大。不過，我仍會盡快修復，因為不規範的程式碼可能污染後續模型生成。
這本質上和過去一樣：你可以適當「偷懶」，但要記得回來修。
Host：如今很多人認為，編程的樂趣被削弱了，開發者變成了「提示詞工廠」。你怎麼看？AI 是否讓你失去了對編程的興趣？
Dax： 對我而言，答案是否定的。但我可能屬於少數情況，因為我經營自己的公司，可以自主選擇工作方向。AI 工具讓我能更快探索新想法，把時間投入到更有創造性的部分，而不是重複性勞動。
但我理解很多人為何會產生挫折感：如果你只是被分配任務，輸入提示後等待結果，而沒有更具挑戰性的工作，那確實容易感到無聊。事實上，編程中本就有大量重複性工作，如今正好由 Agent 接管。
真正有趣的部分，系統設計、方向判斷、問題界定，仍然是人類主導，而且往往並不頻繁發生。也許每月一次，而不是每天都有。
Host：我個人覺得 AI 反而提升了樂趣。它讓我專注於更高層抽象，而不必糾結語法細節。但我也擔心，如果過度依賴工具，技能是否會退化？
Dax： 這種擔憂是真實存在的。我記得小時候心算能力很強，如今卻明顯退化。類似地，如果長期依賴 AI，某些編碼能力可能會萎縮。雖然現實中這或許影響有限，就像計算器取代心算一樣，但在遇到複雜問題時，這種能力落差可能顯現。
問題在於，這就像「精靈已經從瓶子裡放出來」。只要有工具能讓少花力氣，人們就會一直使用它。關鍵在於：節省下來的精力是被用來做更有價值的事情，還是只是刷 TikTok？
我在兩種狀態之間都體驗過，有時很投入，有時也會讓 AI 工作，自己放空。這種現象如果在數百萬程式設計師身上同時發生，長期生產力到底提升多少，其實不好判斷。尤其如果只是打一份自己不太關心的工，人很難主動多付出努力。
Host：那喜歡寫程式碼，會不會反而成為一種劣勢？比如有人過度沉迷技術，而忽視更重要的能力？
Dax： 這並非新問題，過去也有開發者沉迷技術細節，而忽視產品和業務判斷。優秀的人往往懂得平衡：何時深挖技術，何時關注產品方向。
在我看來，編程能力可以帶來不錯的職業位置，但真正突破上限，往往來自第二項專長。如果你既是優秀程式設計師，又深諳某個行業（例如金融、醫療或能源），那你就處在極其稀缺的位置。程式設計師可以進入所有行業，這是巨大優勢。若能在所在領域積累深刻理解，就能發現被忽視的結構性機會。
Host：你曾拒絕多次收購與高薪邀請。為何沒有選擇更穩定的路徑？
Dax： 我年輕時看到 Snapchat 拒絕 Facebook 數十億美元收購時，覺得創辦人瘋了，但後來我理解了。隨著職業發展，你的「安全網」變大。早年如果有不錯 offer，你可能無法拒絕。但當你積累、有能力、有退路時，野心也會隨之增長。接受收購意味著放棄原有夢想，那種「所有願景就此終止」的感覺，遠比短期輕鬆更強烈。因此，除非條件極端優厚，否則我很難做出那樣的選擇。
Host：很多人認為你是「精英開發者」。你認為自己的核心優勢是什麼？
Dax： 坦率地說，我身邊有不少同事在技術執行層面比我更強。我未必是最優秀的程式設計師。我的優勢更多體現在具備整體視角，能夠預判發展趨勢並做出合理判斷，我的另外兩位共同創辦人也同樣擅長此方面，我們彼此相互促進。我們致力於在複雜的行業環境中梳理規律，區分長期成立的基本邏輯與暫時成立的認知，團隊在這方面投入了大量時間，我也常與朋友就此展開深入探討。這種思維方式具有可遷移性，能夠應用於編程、業務運營、個人決策與人才招聘等多個方面，這或許就是我真正的優勢。
Host：你剛才提到的這些能力，是天生的嗎？還是你後來刻意培養出來的？如果是刻意培養的，是不是任何人都可以透過努力提升？
Dax： 與行業內頂尖人才交流時，會覺得他們似乎擁有與生俱來的天賦，但深入溝通後會發現，他們大多起步普通，只是透過持續投入逐步提升。對我而言，這項能力的核心在於真正在意自身認知的最終正確性，而非追求當下爭論的勝負，即建立準確認知世界的模型。若以此為目標，便會倒推所需付出的行動，核心在於保持思維清晰，認清自我與自身的不安全感。很多時候，不安全感會影響判斷，使人因主觀期待而刻意採信片面證據，這需要長期的成長積累。
年輕時我安全感不足，看待問題的能力較弱，隨著自信心與成果的積累，思維方式也不斷完善。同時，需要謹慎對待接收的資訊，避免資訊過載導致思維受限，陷入單一認知環境。保持自我覺察與持續反思是一項需要長期堅持的事，在當下的社會環境中，維持思維清晰面臨諸多干擾，真正做到這一點，需要始終堅守對最終正確的追求。
Host：談到招聘，你怎麼看「捷徑」？比如學歷或大廠背景重要嗎？
Dax： 很多人會用一個憑證，比如「我在 Google 工作過」。從經驗來看，這種憑證確實會帶來巨大影響。但讓我不舒服的是，它的影響被放大了。很多人看到 Google、Meta、Amazon、Apple 這樣的品牌，就會自動附加某些能力假設。雖然確實存在一定相關性，但遠遠沒有大家想像的那麼強。
我們處於獨特位置：產品面向開發者，且開源，因此潛在候選人往往是用戶或貢獻者。能在混亂的開源環境中做出高品質貢獻，本身就是極強篩選機制。我們近期招聘的十餘人，沒有進行傳統面試，也未查看履歷，我們更關注實際成果。
從宏觀角度看，大規模招聘確實需要「捷徑」，如學歷或公司背景。但從個體角度看，這種標籤在正負兩個方向都可能帶來偏見。當我看到履歷上寫著 Google，我反而會本能地產生負面預設。我會聯想到他們選擇那條職業路徑的動機、價值觀以及日常合作方式。同樣地，如果有人因為這個憑證而自動高看對方，那也是不公平的。歸根究柢，和一個人聊一兩次，很容易就能感受到對方的真實狀態。對我來說，要嘛我非常興奮，要嘛就是沒有共鳴。在我們的規模下，這種方式完全可行。最終，最有效的方式仍然是展示成果。如果你足夠優秀，世界遲早會糾正對你的低估。
參考連結：https://www.youtube.com/watch?v=IGsbARhERqc
今日好文推薦
黃仁勳 GTC 2026 演講實錄：所有 SaaS 公司都將消失；Token 成本全球最低；「龍蝦」創造了歷史；Feynman 架構已在路上
Anthropic 工程師都離不開！深夜隨手擼出的開源神器，被 OpenAl 高價收購，23 人創業逆襲
OpenClaw 之父驚嘆中國速度！大廠集體殺入新戰場：用 AI 批量製造「一人公司」
會議推薦
OpenClaw 出圈，「養蝦」潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自託管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背後也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發/維運流程並形成穩定收益。
針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立品質/效率指標體系，最終把自託管 Agent 從可用的 Demo 升級為可靠的生產系統。