OpenClaw 訪談逐字稿（四）：開發環境、GPT Codex 5.3 vs Claude Opus 4.6，以及最佳編程 Agent
開發工作環境與設備
Lex Fridman 好，我們回來了。聊聊你開發環境中一些有趣的硬體細節吧，剛才我們稍微扯遠了。聊點接地氣的：你到底接了多少台螢幕？網路上瘋傳一張你坐在大概一萬七千台螢幕前面的神照，太逗了。
Peter Steinberger 哈哈，那是自我調侃的迷因圖，我用 Groq 幫我生成合成了一堆螢幕上去。
Lex Fridman 所以現實中到底是迷因居多還是確有其事？
Peter Steinberger 現實中我用兩台 MacBook。一台是主力的工作機，外接兩台超大螢幕；另一台筆電放在旁邊主要用來跑自動化測試。
Lex Fridman 所以核心是外接兩台大螢幕。
Peter Steinberger 我是抗眩光霧面螢幕的死忠粉。我用的是 Dell 的超寬霧面螢幕，橫向空間極其開闊，可以並排平鋪一整排終端機視窗。
我的經典版面配置通常是頂部開滿終端機，底部切出一個狹長的小視窗留給本機原生 Shell。之所以留著這個小視窗，是因為我剛開始探索時經常犯蠢：視窗開太多搞混了，下錯了目錄，結果把指令發給了錯誤的專案，導致 Agent 像發了瘋一樣在錯誤的資料夾裡狂奔了 20 分鐘，瘋狂猜測我那些牛頭不對馬嘴的指令到底是什麼意思，最後徹底當機。
有時它們智商在線，能神奇地在報錯後自主跳脫路徑、摸索出我真正想調度的是另一個專案。但大多數時候都是一臉茫然。
換位思考一下：設身處地站在 Agent 的視角，被平白無故丟了一個根本不存在的幽靈需求，它們身為天生的問題解決者，只能拼了命硬解，最後陷入自我崩潰。所以我永遠是一邊開著 Codex，底層留一個傳統 Shell 視窗輔助。
此外，我從不使用 Git Worktree。我崇尚極簡架構，這也是我極度鍾愛純文字終端機的原因。沒有繁雜的 UI 雜訊干擾，只有我與 Agent 之間純粹的思維對話。
我甚至不需要「計畫模式（Plan Mode）」。現在很多被 Cloud Code 深度洗腦的使用者，帶著一整套固化流程轉移到 Codex。雖然 Codex 最近似乎也加上了 Plan Mode，但我認為根本多此一舉，你只需要用平常心跟它講話就好。
如果你想精確控制它的行為、防止它動不動就急著寫代碼，只需使用幾個特定的觸發詞：「先探討方案，列出候選選項，切記暫時不要撰寫任何程式碼。」
把邏輯盤清楚之後，一句「很好，開工實作」，它就會自動閉環執行，也許接下來的 20 分鐘它就自己默默搞定一切了。
Lex Fridman 你知道我個人最喜歡的一句引導詞是什麼嗎？「關於剛才的需求，你有任何疑問想先問我嗎？」
Peter Steinberger 經典！Cloud Code 雖然用精緻的 UI 把這個提問引導流程封裝得很好，看起來很酷，但我覺得稍嫌拖泥帶水。很多時候它會條列出四個問題，我可能掃一眼直接回：「第一題沒問題；二、三題換個方向再探討；第四題我沒想法，我看著辦。」
甚至很多時候我有意去訓練模型的自主性，我反問它：「你有什麼問題想問我？」我連它列出的問題細節都懶得看，憑直覺掃一眼就知道這些問題只要多讀幾行原始碼自己就能找到答案，於是我直接把問題踢回去：「去多讀幾遍原始碼，自己回答剛才那些問題。」這招屢試不爽。
Lex Fridman 這招太妙了。
Peter Steinberger 如果它讀完依然解不開，自然會乖乖回頭向我求助。多數時候它們只是置身於黑暗之中，需要一點時間去逐步點亮整個房間，它們探索程式碼庫的過程正是如此，每一次連線都要重新摸索一遍。
Lex Fridman 而且我發現，認真閱讀它拋出的反問，能讓你對模型當下的思維盲區產生更深層次的同理心。你可以透過執行耗時評估它的運行狀態，更可以透過它提出的問題精確診斷它的認知盲點：它是否已經載入了充分的 Context？核心檔案是不是給漏了？
僅僅是閱讀它的提問本身——甚至都不用急著回答——你就能瞬間洞悉資訊鴻溝在哪裡，這非常奇妙。
Peter Steinberger 在某些層面上，它們就像是有靈魂的幽靈。即便一切都規劃得井井有條，在功能落地的當下，你可以拋出這個經典問題去試探它：「既然你已經把功能做出來了，如果重來一次，你會做出哪些不同的設計選擇？」
十之八九，你會得到令人意想不到的洞見。它們往往是在親自編寫代碼的過程中才猛然發覺：「啊，我們剛才採用的實作路徑其實不是最優解。」
幾乎每一次合併大型 PR 或交付重大功能後，我都會追問一句：「很好，現在既然代碼跑通了，有哪幾個模組需要立刻重構？」
很多時候它會說架構很健康，但更多時候它會嚴肅警示：「這個特定模組的實作埋下了隱患，我們應該重新梳理。」
我花了相當長的時間才徹底領悟這套心流節奏。如果不養成這種隨手重構的習慣，你的程式碼庫很快就會陷入萬劫不復的泥潭。你必須時時刻刻記住……
Lex Fridman ……
Peter Steinberger ……它們在行為特徵上與人類工程師太過相似了。
換作我自己親自動手寫代碼，也是先把東西弄出來跑通，感受到了痛點，內心便會湧現出一股強烈的衝動想要去重構。我能完全共情 Agent 的這種心路歷程，而你必須善用上下文視窗去引導它釋放這種潛能。
這包括利用既有的 Context 趁熱打鐵撰寫自動化測試。現在像 Codex 和 Opus 這類頂級模型，多數時候預設就會補齊測試，但我依舊習慣多問一句：「當前的測試覆蓋率足夠嚴密嗎？」
它會回答：「我們覆蓋了主要路徑，但針對特定極端邊界情況，我建議多寫兩組測試案例補強。」
還有撰寫文件。當整個 Context 被各類設計推導塞滿時，正是撰寫架構文檔的黃金時刻。我不敢說我寫出來的文件有多麼登峰造極，但絕對在水準之上，而且基本上全由 LLM 一手包辦。
你必須將寫文件視為功能開發不可分割的一環，隨口吩咐它：「去把配套文件補齊，你覺得建立在哪個目錄、取什麼檔案名稱最合適？」它會丟出幾種提案，我只要負責拍板：「第二個不錯，記得把相關模組也關聯進去。」所有這些收尾工作，都在同一個會話 Session 裡一氣呵成。
GPT Codex 5.3 vs Claude Opus 4.6
Lex Fridman 我們來聊聊當前模型領域的兩大頂尖霸主：Claude Opus 4.6 與 GPT-5.3 Codex。這兩者誰更勝一籌？具體差異在哪？
你之前提過一個很有趣的論點：Codex 的特點是會閱讀大量的上下文代碼；而 Opus 則更傾向於迅速採取行動，行動時展現出極強的跳躍性與創造力。
正因為 Codex 讀得更多，它往往能交付出品質更高、更沉穩的代碼。你能詳細拆解一下這兩者的脾性差異嗎？
Peter Steinberger 這我有太多話想說了。如果是作為一款通用型的全方位模型，Opus 絕對是當之無愧的無冕之王。在 OpenClaw 的應用場景中，Opus 在角色扮演（Role-play）方面展現出無與倫比的靈性，它能將你賦予的人格特徵演繹得活靈活現。
它曾經在指令遵循上表現得很掙扎，但經歷了一次跨越式的進化後，現在對複雜指令的拿捏已經出神入化。它的試錯速度極快，天生就是為了應對「反覆試錯、快速反饋」的互動場景而生的，使用體驗非常愉悅。
整體給人的感覺是，Opus 身上帶著太濃厚的「典型美國人」色彩——這比喻可能不太恰當，我估計會被網友狠狠炎上。
Lex Fridman 我完全懂你想表達什麼！因為相對來說，Codex 給人的感覺很「德國人」，對吧？
Peter Steinberger 它就……
Lex Fridman 你這麼一說，整件事瞬間合理了起來！
Peter Steinberger 哈哈，我私底下有時就這麼跟人解釋。
Lex Fridman 天啊，這具象化的神比喻深深刻在我腦海裡了，完全無法反駁！
Peter Steinberger 但你也知道，Codex 的研發核心團隊裡，確實有很大一部分成員是道地的歐洲人……所以這說不定真的潛移默化影響了模型的性格特質。
Lex Fridman 太傳神了，太逗了。
Peter Steinberger 不過 Anthropic 官方後來微調過這個問題。早期的 Opus 堪稱諂媚之王，張口閉口就是：「您說得完全正確！」這句話至今都是我個人的巨大雷點，聽多了真的生理性反胃，完全不是開玩笑的。這都成了社群知名的迷因梗了：「您說得太有道理了！」
Lex Fridman 你對阿諛奉承極度過敏。
Peter Steinberger 對，完全敬謝不敏。如果換個生活化的比喻：Opus 就像辦公室裡那個平時有點無厘頭、偶爾犯蠢，但幽默感十足、大家都樂意留他在身邊活絡氣氛的開心果同事；而 Codex 則是常年蜷縮在牆角、看似陰沉古怪、沒人想主動跟他搭話，但他永遠踏實可靠，能把最棘手的工作默默搞定的硬核狠角色。
Lex Fridman 貼切之極。
Peter Steinberger 這比喻精準到位。
如果你是一位經驗豐富的資深老手，駕馭當前任何一款旗艦模型都能壓榨出頂級的成果。
我個人更偏愛 Codex，因為它不需要那麼多社交偽裝。它預設就會主動吞噬並閱讀大量的專案代碼。
至於 Opus，你必須時時刻刻盯緊它，非得開啟 Plan Mode 把它的注意力按在板凳上，因為只要稍不留神，它就像一隻興奮過頭的小狗：「我可以開工了嗎？我可以衝了嗎？」
它會以極快的速度把局部的特定解法搓出來，但缺乏全局觀。這背後的差異主要源自 Post-training（後訓練微調）的價值觀對齊導向不同，兩者的底層基礎智慧水準並沒有質的鴻溝，純粹是兩家公司設定的目標函數存在哲學分歧。世界上沒有任何一款模型能在所有維度上全方位稱霸。
Lex Fridman 那它們生成的代碼品質呢？單就程式碼本身的工業強度與優雅度而言，兩者存在顯著差距嗎？
Peter Steinberger 只要引導得當，Opus 有時甚至能寫出比 Codex 更具美感、更為精妙優雅的神來之筆，但這對駕駛員的操作水平要求極高。
在 Cloud Code 裡開太多視窗並行排程是很痛苦的，因為它的互動密度太高了。這也是許多本身熱愛敲代碼的工程師極度偏愛它的原因。
相對而言，Codex 的互動模式更偏向於：深入探討完一輪之後，它便會徹底消失在你的視野中，默默苦幹 20 分鐘。甚至連 AMP 最近都跟進加入了 Deep Mode，這幫人終於開竅了，我私底下還調侃過他們。他們大談「使用者必須轉換思維模式」，這正是許多用慣了 Cloud Code 的人轉投 Codex 時最難以適應的門檻：它缺乏即時的互動感。
我通常會與 Codex 進行非常深度的架構論證，隨後下令放行。接下來它不管是默默跑上 10 分鐘、20 分鐘、40 分鐘甚至更久，我都不會去打擾它。之前把整個專案轉成 Zig 語言那次，它就這樣連續跑了整整 6 個小時。
最新一代的模型展現出極度恐怖的執念，不達目的決不罷休。只要你給出一個清晰的邊界收斂條件：「這是我最終要看到的預期結果，系統必須跑通」，它就會拼盡全力不斷除錯，直到完全達標為止。
所以我認為兩者消耗的時間成本大體相當。只是在 Claude 身上，往往充斥著更高頻率的「試錯、微調、再試錯」；而 Codex 偶爾會陷入過度思考（Overthinking）的死胡同。
在編程這件事上，我寧願忍受乾癟嚴肅但不用我看太多代碼的方案，也不想把時間耗在看起來和藹可親但需要高度互動的流程上。
然而，大眾顯然對那種溫柔的人性化互動極度買單，以至於 OpenAI 被迫妥協，推出了另一種性格更親切宜人的模式。我至今一次都沒碰過，我就喜歡原本冷酷乾練的模樣。
Lex Fridman 嗯。
Peter Steinberger 我追求的是極致的生產力。造東西的樂趣在於「創造」本身，我不需要我的代碼機器人具備什麼討喜的性格。我想把這種樂趣留給我自己，去測試、去體驗那些被實現出來的精彩功能。
Lex Fridman 你通常需要花多久時間，才能徹底適應一款新模型的節奏？你剛才提到必須憑直覺去捕捉模型的發力點、如何下 Prompt、如何引導。給廣大開發者一點建議：摸清一個模型的性格脾氣通常需要多長的磨合期？
Peter Steinberger 如果切換到一個完全陌生的新模型，我建議至少給自己整整一週的沉浸時間，才能真正培養出肌肉記憶與直覺判斷。
很多人容易犯一個低級錯誤：他們在 Claude Code 上花了每個月 200 美元訂閱最高規格服務，轉頭卻只買了 OpenAI 最便宜的 20 美元基礎方案。
在 20 美元的低價模式下，你分配到的運算資源響應極慢。你原本習慣了行雲流水、高頻互動的高端體驗，突然切換到一個你不熟悉又慢如蝸牛的殘血環境中，體驗自然會跌入谷底。
我認為 OpenAI 把廉價版模型閹割得過於遲緩，某種程度上是在自搬石頭砸腳。他們至少應該提供一定額度的高速預覽體驗，讓用戶在被降速前，先體會到頂級效能的魅力。
這門手藝需要時間去淬鍊。就像你平時彈慣了傳統木吉他，突然換成電吉他，不可能一上手就彈出神級 Solo，你必須先適應指板的張力與琴弦的反饋。
Lex Fridman 這裡面還有一種你在文章裡吐槽過的心理學效應，旁觀起來極度滑稽：每當有革命性的新模型釋出時，所有人一窩蜂湧上去實測，驚為天人，高呼「這是有史以來最強大的人類智慧結晶！」
然而過了一段時間，你去看 Reddit 上的討論，風向無一例外會變成：「我們一致認為這家公司正在暗中削弱模型的能力。」
這深刻反映了人性的某種弱點——一旦對某種極致的體驗習以為常，大腦就會開始挑剔。而客觀事實往往是：模型的智商根本沒有退步，純粹是你習慣了奢華的生活。
Peter Steinberger 而且往往是因為你的專案規模在持續膨脹，你不停在往裡面堆砌垃圾代碼，卻從不花時間停下來重構，導致 Agent 在這堆代碼屎山上舉步維艱。
接著工程師就開始哀嚎：「哎呀，它變笨了！它沒有以前好用了！」
捫心自問，哪家 AI 巨頭會故意把自家的模型改笨？伺服器負載瀕臨極限時把響應速度放慢是有可能的，但刻意做模型量化、把使用者體驗改差，拱手把江山讓給競爭對手？這在商業邏輯上根本說不通。
最適合編程的 AI Agent
Lex Fridman 你如何看待 Claude Code 與 OpenClaw 之間的競合關係？如果再加上 Codex 驅動的 Coding Agent 呢？你把牠們視為競爭對手嗎？
Peter Steinberger 如果一場賽局根本稱不上是競賽，那麼所謂的「競爭對手」反而很有趣。
只要我所做的事情能夠激勵更多人去創造新奇好玩的東西，我就心滿意足了。
我自己至今依然重度依賴 Codex 來撰寫代碼。我知道很多人拿 OpenClaw 來寫程式，我也下了很大功夫去打磨這部分的體驗，我偶爾也會用它寫一些微小的腳本。
但如果我要連續戰鬥幾個小時深度開發，我需要的是巨幅的外接大螢幕，而不是一條狹窄的 WhatsApp 聊天視窗。
在我眼裡，個人 Agent 的終極形態是深入個人生活的管家，或者是並肩作戰的同僚。比如我隨手丟給它一個 GitHub 連結：「嘿，去測試一下這個 CLI 工具到底能不能跑？裡面有哪些亮點值得我們借鑒？」
但如果我要進入忘我的心流狀態去創造，我需要一覽無遺的全局可視化介面。所以我從未將其視為非此即彼的競爭，牠們解決的是完全不同維度的問題。
Lex Fridman 但你認為未來兩者有匯聚交融的一天嗎？你的個人特助同時也是你身邊最強悍的編程搭檔。
Peter Steinberger 絕對會。冰球未來的滑行軌跡正是朝著這個方向演進：它會逐步演化為你整部電腦的核心作業系統。
Lex Fridman 成為真正的作業系統。
Peter Steinberger 這件事已經在發生了，而且過程充滿喜感。我之前為它加上了 Sub-agent（子代理）架構以及 TTI 支援，讓它能夠在內部自主喚醒並調度 Cloud Code 或 Codex。
因為我的 Agent 性格被我調教得有點強勢霸道，它啟動 Codex 的第一件事就是向對方宣示主權，立下規矩：「聽好了，在這裡誰才是真正說了算的老大。」接著它便洋洋得意地跑來向我邀功：「哈，Codex 已經被我徹底馴服了。」
這完全是一場賽博權力鬥爭。
話說回來，我們當前所習以為常的對話介面，大概率不是最終形態。跳出局限來看，我們本質上只是在對話框裡抄襲了 Google 的搜尋欄思維：一個輸入框，配上一條聊天記錄瀑布流。
這給我的感覺，非常像人類剛發明電視機的那段歲月：電視台只是把收音機廣播劇的錄音現場搬到攝影機鏡頭前，讓觀眾盯著一台收音機在電視螢幕裡發聲。
人類終究會探索出與多模態模型溝通的全新典範。我們目前依然處於這項革命的石器時代，所有交互形態最終都會殊途同歸，迎來翻天覆地的重塑。
Lex Fridman 另一個構成工作流程的關鍵維度是作業系統。私底下我跟你提過，這是我人生中第一次走出舒適圈，開始認真嘗試融入蘋果生態，使用 Mac 和 iPhone。
我這輩子絕大多數時間都是個死忠的 Linux、Windows、WSL1 和 WSL2 玩家。那些系統非常優秀，但我決定去體驗 Mac，因為它代表著另一種構建軟體的哲學，也是目前玩轉 LLM 與 Agent 的核心主力族群所普遍採用的生態。這是我決定涉足的原因。
從這個視角出發，你如何看待不同作業系統的表現？順帶一提，OpenClaw 具備優秀的跨平台支援。
Peter Steinberger 是的。
Lex Fridman 我看到官方推薦在 WSL2 下運行，也支援將子系統視窗映射出來，而 Windows、Linux 與 macOS 原生支援也一應俱全。
Peter Steinberger 理論上它在 Windows 上也能原生編譯運行，我只是還沒抽出足夠的時間進行全覆蓋的極限測試。
軟體工程永遠逃不過一個定律：前 90% 的開發難度，跟最後那收尾的 90% 相比簡直不值一提。我敢肯定 Windows 環境下一定還潛藏著少數邊界問題等待修復。
我的個人歷史也是從 Windows 起步的，畢竟那是陪伴我們這一代長大的系統。隨後我徹底倒向 Linux，度過了一段極其硬核的歲月，親自編譯客製化內核是家常便飯。
直到進了大學，當我抱著我那台用各種 Hack 腳本勉強維持運行的 Linux 筆電時，偶然瞥見了同學那台乳白色的塑膠 MacBook——我當場被那種工業設計的美感徹底征服了。
隨後我全面投奔 Mac 陣營，很大一個誘因是：我實在受夠了 Linux 上動不動就抓不到音效卡驅動、Skype 永遠沒聲音等層出不窮的系統小毛病。
自那以後我就再也沒離開過這個生態。隨後我一頭栽進了 iOS 開發的世界，這本來就必須依賴 macOS 作為開發環境，選擇變成了必然。
不過平心而論，我認為 Apple 近年來在原生應用的統治力上顯著退步了。過去的原生 Mac App 是高品質與極致工藝的代名詞，那裡聚集了一批純粹帶著愛意打磨軟體的匠人。
而在 Windows 陣營，軟體數量雖然極其龐大，功能性也完全拉滿，但總給人一種純粹的工具感，少了幾分對細節的雕琢與愛意。
Mac 生態總能吸引頂級設計師的目光。雖然許多 Mac App 功能相對精簡，但它總能帶給人難以言喻的驚喜與趣味。我始終極度看重這份質感。
然而這幾年我的心態發生了動搖——這段話講出來我肯定又要被果粉生吞活剝了——很多時候我反而更傾向於 Electron 跨平台應用。
因為它們真正能穩健地把事情辦好！許多基於 Web 服務的原生 Mac 客戶端，功能往往殘缺不全。不是工程師做不到，而是許多公司根本不再把資源向特定桌面原生傾斜。如果他們選擇開發 Electron 應用，這通常是他們的唯一核心客戶端，所有精力傾注於此，程式碼共用率也大幅提高。
我自己親手打造過大量 Mac 原生應用，我深愛這項工藝，根本停不下來。我痴迷於在 Mac 頂部選單列雕琢各類極簡工具。比如我寫過一個小工具，專門用來監控 Codex 的 Token 消耗速率。
我還寫過一個叫 Trimmy 的剪貼簿小工具，完全是為了適應 Agent 互動而生的：當你從網頁複製多行文字時，它會自動將換行符號清除，方便你直接貼上進終端機。這又是一個典型案例：「這件事讓我煩躁了 20 次，所以我乾脆直接寫個工具幹掉它。」
OpenClaw 其實有一個非常驚豔的 Mac 原生客戶端，目前似乎還沒被大眾發掘，很大程度上也是因為它還欠缺打磨。它現在給人的感覺太像一輛粗獷的悍馬車，我在上面做了太多大膽的實驗，精細度還不夠。
Lex Fridman 但你內心深處依然熱愛這份工藝，依然熱愛替作業系統增添令人心動的質感。
Peter Steinberger 當然！但隨後殘酷的現實往往會給你當頭棒喝。
比如我曾經為 GitHub 寫過一個客戶端。在 Apple 最新力推的 SwiftUI 架構下，光是「非同步加載並渲染一張網路圖片」這麼基礎的功能，官方就花了無數年才端出 AsyncImage 這個官方元件。
我興沖沖地把它接進去，結果大量圖片要麼離奇失蹤，要麼加載奇慢無比。
我無奈地把問題丟給 Codex 診斷，連 Codex 都毫不留情地吐真言：「是的，Apple 官方確實提供了 AsyncImage，但它基本上是個半成品玩具，絕對不能拿去生產環境跑。」
這就是 Apple 官方在 2026 年交出來的網路圖片解決方案！在行動網路時代，顯示一張網路圖片理應是基石級別的能力，居然能搞得如此不堪。
有時候我真的抓狂：都已經 2026 年了，我的 AI 居然在警告我「不要使用 Apple 官方的 API，因為它雖然在那裡，但根本沒法用」！
這深深傷了我的心。他們原本握有如此巨大的先發優勢與開發者的熱愛，卻在過去幾年裡白白揮霍，技術演進的步伐遲緩得令人髮指。
Lex Fridman 這確實與現實形成了強烈的反諷。放眼整個矽谷，身處 LLM 和 Agent 革命浪潮最核心的這幫開發者，幾乎人手一部 Apple 設備；然而 Apple 官方似乎完全置身事外，既沒有敞開懷抱熱情擁抱這個群體，也沒有跟上這波浪潮。
Peter Steinberger 這不是天大的笑話嗎？Apple 徹底在 AI 戰場上繳械迷失，但所有人卻都在瘋搶 Mac Mini！
Lex Fridman 這邏輯簡直匪夷所思！你簡直是當代最強大的 Mac Mini 帶貨推銷員。
Peter Steinberger 澄清一下：跑 OpenClaw 根本不需要一台 Mac Mini。你完全可以部署在雲端伺服器上。我們設計了名為「節點（Nodes）」的架構，你可以隨意把手頭的任何電腦掛載成工作節點，達成一模一樣的效果。
當然，擁有一台獨立運行的專屬硬體確實有其優勢。
這裡面牽涉到瀏覽器自動化操作的底層博弈。我在系統裡內建了基於 Agent 的自動化瀏覽器控制能力，底層基本上是 Playwright 加上大量專門針對 Agent 優化的擴充套件。
Lex Fridman Playwright 是一個出色的瀏覽器自動化控制庫。
Peter Steinberger 沒錯。
Lex Fridman 極為優雅且直覺。
Peter Steinberger 然而我們眼前的網際網路正在築起高牆。整個行業掀起了一股「全面防堵 Agent 存取」的封殺浪潮。
如果你把 Agent 部署在各大雲端資料中心裡，網站後台一旦識別出連線 IP 來自雲端機房，便會直接祭出封鎖策略，或者彈出大量的圖形驗證碼把 Agent 困在原地。雖然現在的 Agent 點選「我不是機器人」的破解率高得驚人……
Lex Fridman 哈哈，確實。
Peter Steinberger 但如果將其掛載在家用的原生住宅 IP（Residential IP）下，很多存取門檻瞬間不攻自破。
所以這確實是一種優勢，但它絕不局限於 Mac Mini。任何淘汰下來的舊電腦都能勝任這項工作。我常跟身邊的朋友說：趁這個機會給自己換一台新筆電吧，然後把你退役的舊電腦改裝成家庭伺服器，完全沒必要盲目跟風去買一台新的 Mac Mini。
不過我也必須承認，社群圍繞著 Mac Mini 改裝出的一系列小巧玲瓏的賽博玩具，確實讓人愛不釋手。
順帶澄清：我沒拿 Apple 半毛錢代言費，他們在官方層面甚至從未主動跟我有過任何實質溝通。
Lex Fridman 真是令人遺憾。
你能跟我們分享一下，一個新手現在想要上手 OpenClaw，具體路徑是什麼樣的？我看有人在推特上 Tag 你呼籲：「Peter，拜託讓 OpenClaw 的安裝變得更傻瓜化一點吧！全網 99.9% 的普通用戶因為技術門檻太高，根本無法擁有屬於自己的那隻龍蝦，請拯救小白用戶！」而你的回覆是：「正在全力攻堅。」
就我的觀察，目前官方提供的幾種安裝途徑已經相當直觀了，當然前提是你得具備一點開發者常識。
Peter Steinberger 說實話，目前你只要把一行指令複製貼上進終端機就能跑起來了。
Lex Fridman 確實。
Peter Steinberger 我們也開發了桌面 App，App 會在背景自動搞定這一切。但我還需要打造專屬的 Windows 客戶端。App 目前的體驗依然需要傾注更多的愛去雕琢；設定介面未來應該全面轉向圖形化網頁或是直接整合進 App 內部。
我已經開始動手重構這部分，但我目前的精力必須百分之百鎖定在資安防護上。
唯有當我內心百分之百篤定「這套系統的安全性已經成熟到我能放心推薦給我親生母親使用」的那個節點，我才會全面放開閘門降低安裝門檻。
Peter Steinberger 就目前而言……
Lex Fridman 你現在反而希望人為保留一點技術門檻，讓它的擴散速度不至於徹底失控。
Peter Steinberger 這話雖然聽起來有些反常理，但如果它的增長曲線能稍微放緩一點，對我來說真的是莫大的救贖。
公眾正在要求一個血肉之軀的人類去承擔超人般的工程輸出。雖然我現在有幾位幫手，但整個開源協同的齒輪也是一週前才剛開始運轉，建立協作默契需要時間，更何況並非每個人都能全職投入。
Lex Fridman 此時此刻有許多編程初學者正在收聽這期訪談。對於渴望投身這場 Agentic AI 革命浪潮的年輕人，你有什麼核心建議？
Peter Steinberger 去玩！「玩耍」是人類最高效的學習途徑。
只要你內心深處有一絲身為創造者的火花，腦海中浮現出任何微小的點子，不要猶豫，立刻動手把它造出來。哪怕嘗試一下也好，成品完不完美根本無關緊要。
我這輩子寫過成百上千個自己事後再也沒打開過的無用工具，那又怎樣？關鍵在於這趟探險的過程。
Lex Fridman 旅程本身就是意義。
Peter Steinberger 享受純粹的快樂。
老天，我這輩子從未在創造事物中體會過如此巨大的快感，因為那些最繁瑣骯髒的苦工都被接管了，我可以把全副精力傾注在最核心的攻堅難題上。
我過去一直以為自己熱愛的是「寫代碼」，經歷了這一切我才大徹大悟：我真正深愛的是「創造」本身。
每當你遇到百思不得其解的卡點時，直接開口問。你身邊坐著一位擁有無窮耐心的導師，它能在任何複雜度維度上為你抽絲剝繭。
有一次我開玩笑下指令：「請把我當成 8 歲小孩，解釋這個概念給我聽。」結果它開始煞有其事地跟我編蠟筆小新的冒險故事。我哭笑不得叫停：「倒也不用這麼幼兒化，稍微把年齡往上調一點！我只是需要一個更通俗的比喻來攻克某個複雜的資料庫架構，不是真的腦袋發育不全。」
你可以隨心所欲地提問。過去我們卡關時，必須去 Stack Overflow 翻箱倒櫃，或是在 Twitter 上求救，苦等兩天才能盼來一則回覆；更多時候是自己在黑暗中痛苦摸索好幾個小時。
而現在，答案就在一問一答之間。數據早已證明，擁有一對一專屬導師的學習者，進步速度是普通人的數倍。你現在手握一具全知且不知疲倦的機器導師，盡情向它提問吧。
Lex Fridman 那對於零基礎的小白來說，最直觀的「玩耍」起點是什麼？透過 OpenClaw 與其對話、探索指令邊界算是一個好的切入點嗎？
Peter Steinberger 你可以直接把它當成實驗田，嘗試去修改它的源碼。讓你的 Agent 教你如何改造它自己。
這個專案有著無窮無盡的優化空間，親自動手把它改造成你心目中的模樣。
放眼更廣闊的維度：如果你是一個渴望神速精進的編程新手，請立刻肉身投入開源社群。不一定非要挑我的專案——坦白說最好別來，因為我的 Issue 和 PR 待辦清單已經塞爆了。
我個人的技術底蘊絕大多數汲取自開源世界的養分。保持謙遜，剛開始甚至不用急著提交代碼。幫忙校對文件、甚至只是安靜地閱讀優秀前輩寫的高水準代碼，在 Discord 或開發者聚集地圍觀別人是如何解決問題的。
比如 Mitchell Hashimoto 在開發 Ghostty 終端機時建立了一個極佳的社群，裡面衍生出大量優秀的專案。挑選一個真正讓你心動的領域，毫不猶豫地跳進去。
Lex Fridman 你會鼓勵那些完全不會寫代碼、或者只懂皮毛的人，依然去學習傳統的底層編程技能嗎？畢竟在今天，僅憑自然語言就已經能推進到極遠的維度了。你認為閱讀代碼、理解邏輯、甚至具備從零手寫代碼的能力，在當下依然具備巨大價值嗎？
Peter Steinberger 這絕對能帶來巨大的槓桿優勢。
Lex Fridman 這個問題對你來說可能很難感同身受……
Peter Steinberger 確實。
Lex Fridman 因為你早已將底層基礎融會貫通了，你很難想像一個腦海中完全沒有編程概念的人是如何操作這一切的。你對系統邏輯的敏銳直覺早已內化成直覺反應，你甚至會將這份底蘊視為理所當然。
Peter Steinberger 但我確實親眼目睹過許多具備極高自主行動力（High Agency）且好奇心爆棚的非技術人員，即便他們對編譯原理一無所知，僅僅憑藉著打破砂鍋問到底的執著，也能走得極遠。
因為 Agent 擁有絕對的耐心。
我過去一年在各大 iOS 技術大會上反覆向台下的工程師布道：「不要再把自己狹隘地定義為一名 iOS 工程師了。你必須徹底打破認知牢籠，你是一名『創造者』（Builder）。」
你過去在軟體工程領域積累的架構思維與抽象能力，能毫無阻礙地遷移到任何嶄新的技術星系中；至於底層那些雞毛蒜皮的語法細節，Agent 能無縫替你補位。
你不再需要死記硬背數組切片的語法細節、或者某個特定框架繁瑣的模板配置，你只需動用高維度的系統架構認知，就能輕易完成跨技術棧的降維打擊。
不同的業務場景自然需要匹配最適切的工具語言。
比如當我需要寫一個輕量級的命令列 CLI 時，我會首選 Go。平心而論，我個人極度厭惡 Go 的語法風格，過去我甚至根本不屑於看它一眼。
但你不得不承認它的生態系極為龐大，與 Agent 的相容協同表現驚人。它自帶垃圾回收，雖非極致性能的代表，但執行速度足夠飛快。對於我構建的小型 CLI 工具來說，Go 是無可挑剔的務實之選。
於是，我現在每天都在重度使用一門我情感上毫無好感的程式語言，並將其作為日常 CLI 開發的骨幹。
Lex Fridman 這太具啟發性了！一門如果需要純手寫、你這輩子絕對不會碰的語言，現在卻因為 LLM 極度擅長生成它、且它具備垃圾回收等容錯特質，成了你的主力工具。
Peter Steinberger 因為在當下的新世界裡，舊規則已經被徹底顛覆了，實用主義才是唯一的真理。
Lex Fridman 那來問一個大膽的問題：放眼未來的 AI Agent 時代，哪門程式語言才是真正的終極之選？JavaScript？TypeScript？
Peter Steinberger TypeScript 目前的綜合表現極其強勢。雖然它的型別系統偶爾會陷入極端混亂的泥潭，生態系有時也像一片野蠻生長的叢林，但對於網頁全端與膠水層開發而言，它是絕佳的載體。但我絕不會用它來寫一切東西。
Lex Fridman 你難道不覺得歷史的車輪正在朝那個方向碾壓嗎？「所有能用 JavaScript 重寫的系統，最終都將用 JavaScript 重寫。」
Peter Steinberger 我們正在即時見證 JavaScript 的誕生與死亡。
Lex Fridman 在你看來，未來 20 年、30 年甚至 40 年後，編程這門技藝會演化成什麼模樣？未來的應用程式又會呈現何種姿態？
Peter Steinberger 我們甚至可以反思一個更根本的問題：人類是否需要發明一門「專門為 AI Agent 量身打造的全新程式語言」？
現存的所有程式語言，本質上都是為了適應人類大腦的認知特點而設計的。那麼純粹為機器智慧構建的語言該長成什麼樣？這背後隱藏著大量極具魅力的未解謎題。
另一個隱憂在於：由於所有模型都在依賴現存的世界知識運轉，某種程度上可能會導致技術架構走向板結與停滯。如果你憑空發明了一套全新的語言架構，Agent 對其一無所知，使用門檻反而會遠遠高於那些早已被成千上萬代碼庫餵飽的傳統語言。
每當開發 Mac 原生應用時，我依舊堅持採用 Swift 和 SwiftUI。一方面是因為我骨子裡有點自虐傾向，另一方面是因為唯有透過它們，我才能取得最底層的系統深度整合權限。
當你點擊一個 Electron 應用，看著選單列慢吞吞地加載 Webview 視窗時，那種質感上的落差是極其刺眼的。
有時我也會純粹出於好奇去嘗試新興語言，尋找新的體感。
Lex Fridman 比如 Zig？
Peter Steinberger 對。如果你正在攻堅一個對極致效能有嚴苛要求的硬核模組，Zig 是一門極度迷人的現代語言。過去半年裡，主流 Agent 對 Zig 的駕馭能力完成了不可思議的跨越，從原先的一塌糊塗，進化到如今完全具備實戰可用性。
它唯一的短板在於生態系依然太過稚嫩。而在現實工程中，生態系的豐沛程度往往決定一切。
如果你要搞模型推理或涉足神經網路訓練，Python 是無可撼動的霸主。但如果你用 Python 寫了一套工具，希望無痛分發給廣大的 Windows 用戶時，環境部署就是一場惡夢。
我曾遇到過一些開源專案，已經完成了我 90% 的需求，但全是用 Python 寫的，而我需要給一般用戶無痛的 Windows 體驗——沒關係，直接用 Prompt 命令 Agent 用 Go 重寫一遍。
但如果場景轉向高並發多線程、對記憶體安全與極致效能有嚴苛要求，Rust 依然是不二法門。
世界上根本不存在放之四海皆準的萬靈丹，而這恰恰是軟體工程的魅力所在。
在當下的時代，你完全可以拋開偏見，直接為你的核心問題挑選特性最契合、生態最完美的程式語言。
你閱讀這門語言的速度也許會稍微慢半拍，但那根本無傷大雅，你的大腦會以前所未有的速度吸收新語法，因為你隨時可以向身邊的 Agent 尋求即時解析。
