我交付的代碼我自己都不讀！Clawdbot沖上10萬星，作者揭秘開發內幕

智東西
編譯 陳駿達
編輯 云鵬

智東西1月30日報道，最近，開源個人AI助手Moltbot（原名Clawdbot）儼然成為AI圈內熱度最高的項目之一。作為一個來自個人開發者的獨立項目，Moltbot的搜索熱度甚至要超過Cowork這樣來自頭部AI玩家的類似產品。其GitHub星標數更是已經突破10萬大關，直奔Next.js這樣的傳奇開源項目。

▲Moltbot GitHub星標數量變化（圖源：X平臺）

Moltbot背后的開發者Peter Steinberger在項目爆火后也頻繁接受采訪，就在昨天，他在一場時長近2小時的深度播客中，深入剖析了他對AI時代軟件開發的思考。

Steinberger的技術生涯始于十四歲那年，一臺偶然出現的電腦開啟了他的編程自學之路。在第一份工作中，他在公司里“先斬后奏”地重構整個技術棧，也是在這一階段他開始形成一個關鍵判斷：使用感覺勝過行業標準。

后來，Steinberger開啟創業，最后以超1億歐元的價格出售了他在PDF技術公司PSPDFKit的股份。財富自由后，這位曾經的技術狂熱愛好者選擇徹底切斷與代碼的聯系，進入了漫長的“減壓期”。這種狀態，直到他重新坐回電腦前，遇到新一代AI編程工具時才被徹底打破。

重歸戰場的Steinberger發現，編程世界已經發生了代際躍遷。他敏銳地察覺到，軟件構建的邏輯已經從逐行敲擊代碼轉向了編織式的系統構建。

在開發新項目Clawdbot時，他同時調度5-10個AI Agent協作。在他看來，AI編程是“能力的放大器”。過去，編程工作和“管道工”的工作一樣枯燥，但AI編程的新范式讓他不再糾結于具體細節，而是將精力傾注在模塊化設計、自動化測試和系統架構的取舍上。他坦言：“我交付的代碼我自己都不讀的。”

面對許多資深工程師對AI的抵觸，Steinberger認為，真正的秘訣在于建立反饋循環，也就是讓Agent能夠自動編譯、測試并自行修正錯誤，而不是期待它一次性寫對。

他類比道，那些認為AI無法處理復雜邏輯的人，往往是“仍在使用彈吉他的方式去嘗試鋼琴”。在AI的加持下，代碼質量不僅沒有下降，反而因為模型對“自證正確”的需求，逼出了更優質、更模塊化的架構設計。

以下是對Steinberger最新訪談精華內容的梳理：

一、軟件的價值，取決于“使用感覺”

Steinberger出生在奧地利的鄉下。真正讓他與技術產生聯系的是一次偶然經歷。十四歲那年，一群游客來到鄉下，其中一位游客帶來了一臺電腦。

這是Steinberger第一次接觸到這種可以被命令和邏輯控制的機器，很快被吸引。他說服母親為他買下一臺電腦，從此開始了持續多年的自學與實踐。

這一階段并不存在系統訓練，Steinberger說自己更像是在“瞎搗鼓”。他寫腳本、做網站、玩游戲，也修改游戲。他記得自己最早做過的一件事，是從學校偷走一個舊的DOS游戲，為軟盤編寫拷貝保護程序，再將其轉賣。

在大學階段，由于家庭條件有限，Steinberger必須自行承擔學費。假期并不意味著休息，而是全職工作。與同齡人相比，他更早進入了長期、高強度的工作節奏。

他的第一份正式工作在維也納，原本只是服兵役與大學之間的短暫過渡，卻持續了近五年。入職第一天，公司給了他一本厚重的《微軟基礎類庫》，但他卻拋棄了這一技術棧，轉而使用.NET。

這也成為了他早期最鮮明的工作方式：表面遵循組織安排，實際按自己的判斷執行。在這家公司，他在未告知的情況下，將部分系統遷移到.NET技術棧。幾個月后，他才向管理層說明“做了一些現代化改造”，但那時已經太晚了。

雖然在.NET 2.0時代，應用啟動緩慢、編譯冗長、硬盤頻繁讀寫，他仍然對底層機制保持興趣，并愿意投入時間打磨細節。這種對細節的關注，在之后的一次項目中被進一步放大。

2010年前后，iPad發布，雜志類應用成為創業熱點。有團隊請他修復一款頻繁崩潰的雜志閱讀器。檢查代碼后，他發現問題并非局部缺陷，而是整體結構失控：代碼高度集中、耦合嚴重，幾乎不存在可維護性。

在放棄修補方案后，他選擇重寫應用，用時兩個月完成原本預計半年的工作。他沒有使用蘋果的PDF渲染器轉而自研，系統性地處理PDF渲染問題。最后，這一應用可在內存極其有限的情況下上加載大體積文檔。

項目結束后，他將PDF相關代碼模塊獨立出來，最初只是供朋友復用，隨后嘗試以組件形式出售，收入已超過其全職工作的薪水。幾個月后，原本的公司要求他在工作與個人項目之間做出選擇。

Steinberger選擇全職投入該項目。他認為，PDF是一個“無趣但極難”的領域，正因如此，才具備長期價值。這一判斷，最終成為他的創業項目PSPDFKit的起點。同時，他也意識到，軟件的價值，更多體現在最終的“使用感覺”上，而非由規范、標準或權威決定。

二、長期親自參與技術支持，厭倦成為“垃圾桶”后出售股份

公司成立之初，Steinberger就意識到，在自己的老家奧地利很難找到他所需要的工程人才。因此，PSPDFKit從一開始就是一家遠程優先的公司，后來逐漸演變為混合模式。隨著團隊規模從三十人增長到六七十人，再到接近兩百人，組織復雜度也隨之上升。

Steinberger并非典型意義上的CEO。他從未主動追求管理職位，始終把主要精力放在寫代碼、解決技術問題和產品決策上。銷售、商務和運營，則交由其他合伙人和高管負責。

PDF是一個較為復雜的技術領域。Steinberger舉了一個例子：PDF文檔中的鏈接。最初的設計假設是，一個文檔可能包含上百個鏈接。但某次，一位重要客戶提交的PDF文件達到五萬頁，每頁超過一百個鏈接，總量超過五十萬個。原有的數據模型在這種規模下徹底失效。

這類問題，恰恰是Steinberger最享受的部分。他長期親自參與技術支持，并有意倒序處理工單，優先回復最新提交的問題。

他的邏輯很簡單：5分鐘內得到CEO的回復，會對開發者產生極強的信任感。這種“創始人直接支持”的方式，也在無形中限制了公司的擴張速度，但增強了產品與用戶之間的黏性。

然而，隨著公司進入成長期，工作內容逐漸從“解決難題”轉向“維護系統”，人員規模擴大帶來的組織摩擦開始顯現。Steinberger發現自己越來越多地消耗在協調沖突、承接風險和維持情緒穩定上。

他形容，CEO像一個“垃圾桶”：所有別人無法處理的事情，最終都會落到這里。長期高強度工作、周末無休，加上對公司方向和管理方式的內在沖突，最終導致了明顯的精疲力竭。

在以大約1億歐元的價格出售PSPDFKit股份后，他幾乎完全離開了技術世界。一段時間里，他不再寫博客，也很少打開電腦。那是一個漫長的減壓過程。他補償式地參加聚會、社交，甚至有幾個月沒有任何“我接下來要做什么”的念頭。

對他而言，真正困難的不是退出，而是在成功之后重新找到驅動力。

三、“我交付的代碼我自己不讀”，判斷力與品味更有價值

幾年后，Steinberger重新坐回電腦前。在這個過程中，他第一次系統性地接觸到新一代AI編程工具Claude Code。由于錯過了早期階段，他直接體驗到能力躍遷后的版本。這種體驗對他產生了強烈沖擊。

他逐漸意識到，軟件構建的阻力正在急劇降低，真正重要的不再是寫代碼，而是系統層面的判斷力與品味。判斷結構是否合理、方向是否正確，本身就是一項核心技能。

Steinberger認為，AI編程真正的轉折點出現在今年夏天。AI已經強大到，開發者可以不再親手寫代碼，就能構建完整軟件系統。而讓他徹底信服的，是他眼中被嚴重低估的GPT?5.2和Codex。

他直言，相比仍被大量使用的Claude Code，OpenAI當前的產品體驗很好，幾乎每一個提示，都能直接得到可用結果。在復雜工程中，他認為Codex明顯優于 Claude Code，兩者的區別主要在工作方式上。

Claude Code速度快，但往往在只讀少量文件后就開始生成代碼，需要人不斷糾偏。Codex會“安靜地讀代碼10分鐘”，再動手，一次成功率更高，這使得Codex更適合復雜系統、深度重構和長期維護型項目。

其最新項目Clawdbot中，他并行運行5～10個編程Agent，整個開發流程從寫代碼轉向了與模型對話、共同規劃。

目前，Clawdbot使用了CLI方案，而非MCP。Steinberger直言，在他看來MCP就是一根拐杖。

MCP需要預加載所有工具功能和說明，導致上下文冗余，數據傳輸依賴固定JSON格式，缺乏靈活性，也無法進行數據篩選和鏈式調用，限制了復雜任務的處理能力。

而CLI的天然優勢在于，模型天生擅長使用Bash命令，也可通過編寫腳本實現自動化鏈式操作。

Steinberger稱：“我交付的代碼我自己是不讀的。”但這并不代表他不重視代碼質量。恰恰相反，他投入大量精力進行重構和架構設計。

絕大多數應用的本質是枯燥的數據流轉與格式轉換，從API到解析，再到存儲與呈現，如同管道工的工作。Steinberger認為，真正的復雜問題往往已被底層技術解決，因此，工程師更應關注系統整體的結構與設計，而非糾結于每一行具體的實現細節。

在這種新范式下，Steinberger判斷人的角色不再是逐行實現邏輯，而更像是一個系統建造者（Builder）。人負責系統結構、產品形態、架構取舍，模型負責具體實現、代碼生成與調試，責任仍然完全在人，Agent只是“能力放大器”。

由于AI的借入，Steinberger的工作方式，已經完全顛覆了傳統開發流程。他不再沉迷于pull request和代碼審查，而是“編織式”地將功能融入現有系統，有時候甚至需要改動架構來讓新功能契合。

不過，Steinberger并不喜歡“Vibe Coding”這一說法，他更愿意將自己的工作描述為智能體工程。他也刻意回避“架構師”這個詞，而強調自己仍是最終責任人。與傳統企業中“脫離代碼的架構師”不同，智能體工程的前提是：代碼是你自己的，事故也由你負責。

Steinberger認為，AI編程真正的秘訣在于實現反饋循環，Agent必須能夠驗證自己的工作，自動編譯、自動測試、命令行替代圖形界面、可復現的執行路徑，一旦驗證閉環建立，就能自行發現競態條件、配置錯誤、工具調用順序問題，甚至在數小時內完成原本需要數周的人類調試工作。

更有意思的是，AI反而逼出了更好的架構。為了讓模型能夠自證正確，系統設計必須更加模塊化、更加可測試。測試和文檔成為了設計流程的一部分，架構決策的重要性被前置并放大。

Steinberger坦言，他從未喜歡寫測試或文檔，但在AI時代，這些工作可以完全交給模型完成，而代碼質量卻達到了職業生涯的新高度。智能體編程正在讓經驗豐富的開發者寫出“更優質的代碼”，即便他們不再親自敲每一行。

那么，為什么大量資深工程師仍然抗拒AI？在Steinberger看來，反對者常犯三個錯誤：把AI當作“一次性寫對的程序員”、只發一個提示而不建立持續對話與反饋循環、不了解模型的知識分布與默認假設。

結語：代碼貶值，品味升值？

從十四歲自學編程的少年，到功成名就的創業者，再到如今在AI浪潮中“重歸戰場”的獨立開發者，Steinberger的經歷揭示了一個真相：在AI時代，代碼正在變得廉價，而對系統的判斷力、對產品邏輯的品味正變得更具價值。

從這個維度來看，這場變革與其說是工具的更迭，不如說是思維的洗禮。Steinberger形象地類比，如今拒絕AI編程的人，就像會彈吉他的人，試了兩下鋼琴就說樂器不行。”

延續這一類比，那些愿意放下“吉他”去嘗試“鋼琴”的人，或許能在與AI協作過程中，探索出一種新的構建方式與思維方式。