Claude Code、Cursor 可能都躲不過一次“大重寫”，但 OpenCode 也許是例外

編譯｜宇琪、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 編程浪潮中構建出來的工具，但團隊采取了完全不同的策略：他們比過去更強調代碼庫的一致性和約束，盡量確保沒有任何文件偏離既定規范；同時，也大量采用那些約束更強、設計哲學更明確的工具與框架，并更堅定地踐行領域驅動設計。

他們認為在大模型參與開發的情況下，代碼庫一旦變“臟”，后果會被放大。大語言模型無法區分“舊模式”和“新模式”，它會將舊寫法當成正確示范并繼續生成不符合當前規范的代碼。因此，不干凈的代碼庫帶來的負面影響，反而比過去更嚴重。

于是出現了一個有些反直覺的結果：他們的代碼庫反而比以往任何時候都更干凈，“甚至可能是我們寫過的質量最高的一批代碼?！監penCode 創始人之一 Dax Raad 在播客中這樣說。

與此同時，他也并沒有放棄“手寫代碼”這件事本身?！爱斘以O計新功能或復雜架構時，寫代碼本身就是思考過程。我不擅長寫一大段詳細規格說明，相反，我喜歡寫類型定義，嘗試函數組合，調整文件結構，通過編寫代碼來理解問題，這是大多數程序員長期以來的工作方式。我看不出有什么理由要放棄這種方式，寫代碼是我思考的方式?！?/p>

另外，他還從代碼質量角度小小鄙視了一番 Claude Code：“Claude Code 做了一個原型，產品市場匹配度極高，即便體驗不完美也會成功。但這并不意味著，所有人都必須犧牲質量，才能達到那個速度。”

基于該播客視頻，InfoQ 進行了部分刪改。

OpenCode 的起源

Host：從去年 12 月開始，OpenCode 的發展非常迅猛。能不能帶我們回顧一下 OpenCode 是如何誕生的？

Dax：我們公司做開源已經很多年了，一直以來我們都在為開發者構建工具，也經歷過不同公司在這個領域的興衰更替，因此在開源產品的構建方面積累了很多經驗。

我們之前的項目是 SST，雖然遠不如 OpenCode 現在的規模，但也算相當受歡迎。它給了我們完整的實踐經驗：如何啟動一個開源項目，如何讓它成功，日常如何運營，開源的優勢和劣勢分別是什么?？梢哉f，我們在這個領域深耕已久。

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 也是如此，它提升了每個人的能力上限，但不應成為偷懶的借口。我們仍然應該反思、改進，而不是因為“能跑起來”就覺得沒有問題。

有些人會說：“代碼很糟，但我們寫得很快?！睂嶋H上，更有經驗的人可以在同樣速度下寫出更好的代碼，這本質上還是能力問題。

Host：那從產品和用戶角度看，短期內定位和速度可能比質量更重要。比如 Claude Code，當時快速發布是不是合理？后來是不是應該做得不同？

Dax：我認為每個人都會盡可能快地前進，并根據經驗做出不同的取舍。Claude Code 的情況是，他們做了一個原型，產品市場匹配度極高，即便體驗不完美也會成功。這種情況很常見，但這并不意味著“所有人都必須犧牲質量才能達到那個速度”。

我們做 Open Code 的時間差不多，也構建了終端框架、Zig 實現、React 和 SolidJS 綁定、編譯為 bun 二進制等。我們之所以能在相似速度下交付更高質量，是因為這是我們熟悉的領域。當然，也一定有人可以做得比我們更好?？偟膩碚f，這個行業里永遠存在比你差十倍的人，也永遠存在比你強十倍的人。

開發者的選擇

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

會議推薦

OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。

針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。