小編精選 - 技術文章翻譯 · 05月06日

AI 編碼時代的 VR 編程——同時監控 5 個 AI Agents

太長不看

人工智慧編碼會造成時間浪費。當一個智能體在思考、建構或測試時，很容易就會想著要啟動另一個智能體。

這樣很快就變成多智能體編碼了。四、五個工單可以同時處理，但它們之間的差異仍然需要人工審核。

終端資訊不夠。我需要查看程式碼以及代理程式更改的差異，而不僅僅是命令列介面 (CLI) 的記錄。

實體顯示器遇到了瓶頸。一張普通的桌子可以放幾個顯示器，但五個就開始佔用空間，影響視覺角度了。

所以我從事VR編程。我並不是推銷VR，它並非萬能的解決方案。我使用它的原因在於，它能讓我在一個視野範圍內同時看到4-5個智能體。

我使用 Immersed 和 Overay 來建立工作空間。前者快速且固定；後者則需要手動操作，但更靈活。

前言

鍵盤旁邊放著一個VR頭顯，背景可以看到正在執行的程式碼視窗。

AI 編碼出現了一種奇特的空閒時間。智能體開始編輯，停下來思考，執行測試，等待建置完成，或在執行計劃的過程中卡住。坐在那裡看著一個任務緩慢進行實在無聊，所以我發現自己會用啟動另一個智能體來處理另一個任務來填補這段時間。在我的工作流程中，這很快就成了常態：一個開發人員，多個智能體，多個任務同時進行。

啟動它們很容易，但觀察它們執行卻很煩人。

我說的「觀察」並非指盯著五個代理終端。終端記錄的是代理的運作過程；編輯器和差異比較是證據。為了確保工作流程的安全性，我需要程式碼、差異比較和代理程式日誌能夠同時顯示。

如今我的工作流程很簡單。同時啟動四到五個 AI 代理，給每個代理程式分配不同程式碼庫中的不同typia ，並保持它們的 VSCode 視窗可見。 typia、 nestia 、 autobe和ttsc目前輪流使用的這些程式碼庫——並非玩具程式碼庫。它們分別位於編譯器、框架、代理和工具鏈的邊界，這意味著一個錯誤的捷徑可能會影響到代理摘要所未顯示的範圍之外。

所以顯示器設定比我想像的更重要。 AI 編碼不僅改變了我能寫多少程式碼，它還改變了我的工作空間必須顯示的內容。一個開發者可以啟動多個代理；限制因素變成了它們工作中危險的部分是否始終可見。

但這一切要真正奏效，必須滿足一個物理條件：

所有 5 個 VSCode 視窗都必須在一個視野範圍內。

我不可能同時閱讀5份文件。我是人，一次只能專注在一個地方。但是，當5個智能體在重寫程式碼時，這5個差異就需要出現在我的視野範圍內。

我遇到的典型 Go 程式碼遷移災難只是其中一個例子。代理程式可能會刪除測試、引入隨機庫、繞過困難部分重寫程式碼，或用綠色摘要掩蓋糟糕的差異。這種情況並非我獨有；這是執行多個編碼代理程式卻不經常檢查的常見風險。

我從那場混亂中得到的教訓很簡單：不要相信摘要，要閱讀差異，不要在通宵達旦地對一個倉庫進行大規模修改，然後醒來就期望它能合併。

問題在於：我還沒找到一張桌子──無論是家裡的還是辦公室的──能同時容納5台顯示器，而且這還是在符合人體工學的前提下。通常來說，最多也就兩台外接顯示器加一台筆記型電腦。桌子的寬度、可視角度，都差不多到此為止了。而且這套設備根本沒辦法搬動。

所以我去體驗了VR。

我並非在鼓吹VR技術。就我自己的多智能體工作流程而言，這恰好就是能讓所有智能體都可見的設定。

工作區

我仍然使用實體鍵盤打字。筆記型電腦仍然是我的主力機。 VR 只是顯示層：我在這裡安排 VSCode 視窗、終端、差異比較、日誌以及我需要查看的代理腳本。

實際上，我通常將每個 VSCode 視窗分成兩部分：一邊是執行 Codex 或 Claude Code 命令列介面的終端，另一邊是正在編輯的原始程式碼或產生的差異。具體使用哪個代理並不重要，重要的是代理的文字和程式碼變更能夠並排顯示。

我的工作空間更接近這個，而不是一整面終端牆：

VSCode 分割畫面檢視顯示 AI 編碼代理程式及其正在修改的程式碼。

將每個 VSCode 視窗以這種方式分割後，VR 功能就會接手。沉浸式或 Overay 模式會將這些視窗變成獨立的虛擬顯示器，這樣我就可以同時開啟多個程式碼和代理程式組合，而不是把它們堆放在一個擁擠的桌面上。

我不認為它們是 VR 應用，而更像是建立監管佈局的兩種方式。

Immersed－一款快速、固定的監控面板。它為我提供了一個可重複使用的五螢幕工作空間，而且設定非常簡單。
Overay 控制台－它真的就叫Overay 。在我的配置中，它是一款手動監聽控制台：佈置起來比較費時費力，但佈局方面也更自由。

原理在兩者上是一樣的。在筆記型電腦上安裝串流應用，在頭顯上安裝用戶端應用，將它們配對，筆記型電腦的顯示輸出就會傳輸到虛擬顯示器上。我並不太在意VR技術本身。我更在意的是，顯示器的數量、距離、曲率和位置都能成為我觀看特務操作方式的可調節選項。

2.1. 浸入式

如果我想快速建造工作區，我會選擇「沉浸式」模式。它的五螢幕吸附佈局是一大優勢。我只需將螢幕放置到位，它們就會自動吸附成整齊的排列，然後就可以開始監控客服人員，而無需花費五分鐘手動調整浮動矩形。對於監控而言，固定位置至關重要，因為客服人員會保持在可預測的位置。下面的截圖正是這種設定的體現。

五個 VSCode 視窗懸浮在 Immersed 中

權衡之處在於，便利性源自於模板。對於高解析度螢幕，螢幕比例基本上固定為 16:9 或 9:16 等形狀。我可以從支援的佈局中選擇，但無法像在 Overay 中自由調整寬度、高度和寬高比。免費版和專業版的分割也很重要：免費版足以測試工作流程，但我的五螢幕高解析度設定需要更專業的工作流程，因此我更傾向於付費版。

令人驚訝的是，Immersed 的氛圍營造非常出色。它擁有優秀的虛擬背景，這一點比聽起來更重要。當我要連續三個小時盯著程式碼執行時，一個乾淨的視覺環境至關重要。它讓頭顯感覺不像是個除錯頭盔，而更像是個私密的工作室。

沉浸式虛擬工作空間背景

2.2. 覆蓋

Overay 則恰恰相反。在我的設定中，我可以放置多達六個螢幕，而且控制介面更加開放。寬度、高度、解析度、寬高比、距離、角度、曲率——幾乎所有參數我都可以調整。無論是垂直螢幕、寬螢幕或儀表板的方形顯示器，Overay 都能滿足我的需求。

Overay 六屏工作區

這種自由也是代價。它需要更多的手動設定。 Immersed 給了我五個插槽，並告訴我「使用這些插槽」。 Overay 則給了我更大的手動設定空間，並告訴我「自己安排」。

覆蓋螢幕配置控制

嘗試過多種佈局後，我發現其實不喜歡在編碼時混用垂直螢幕和橫屏顯示器。對我來說，最舒適的佈局依然是簡單的：四個螢幕呈現矩形排列，需要時旁邊還有額外的螢幕。這四個螢幕組成的矩形區域用來顯示正在執行的程式；額外的螢幕則用來顯示日誌、低優先順序執行的程式或一些無關資訊。這樣既能滿足我想要的密集視野，又不會讓整個工作區顯得雜亂無章。

想像一下，如果真的把五、六個實體顯示器放在桌上，視角很快就會變得很糟糕。人的頭部會左右轉動；而VR讓我能夠利用頭部的這種運動，而不是與之對抗。工作空間不再侷限於桌面，而是可以環繞著我。

監視特工

增加監控人員並非目標，維持執法人員的可見度才是。

我曾經因為讓一個代理長時間處於不受控制的狀態而吃過虧。那次涉及 80 億個代幣的事件——它把整個轉換器都查了個遍——發生在我睡覺的時候。這個數字很荒謬，但教訓很普通：當檢查間隔過長時，代理可能會在我不注意的時候走得很遠。

所以我目前的循環是：

幾乎同時啟動 5 個代理，分別負責 5 個專案。每個代理程式都分配不同的任務。
在頭顯內的五個窗口間來回掃視。我不僅盯著代理終端，還要看編輯器和差異對比，因為真正的問題先在那裡顯現。我一次只能看一個窗口，但我的周邊視覺很擅長捕捉動態和突如其來的大幅變化。當一個窗口裡突然閃過一個100行的差異對比時，我的目光會本能地被吸引過去。
當發現任何異常時，我就會停下來。 「等等，為什麼它要修改測試文件？」——憑直覺，停止程序，仔細查看差異。

五個虛擬代理工作區中有一個可疑差異已突出顯示

我不會同時深入審查五個差異。我關注的是異常情況：測試檔案變更、出現新的依賴項、出現大量不相關的差異、快照重寫、刪除測試案例，或任何表明代理程式優化的是測試而不是任務的情況。深入審查仍然是逐個代理程序進行的。 VR 只是讓這些早期預警訊號更加可見。

在每個視窗中，我同時查看日誌、已更改的檔案、差異、終端輸出和測試輸出。當觸發訊號時，我不會讓代理給出簡單的總結就繼續執行。我會暫停程序，將日誌與已更改的文件進行比較，親自查看差異，檢查修改過的測試和依賴項，並在必要時執行一個範圍較小的測試。如果執行結果明顯有問題，我會直接放棄。我希望在小的差異演變成需要重寫的大版本之前就發現問題。

這就是我的桌上型顯示器的弱點所在。試著把一個外接顯示器分成四個視窗——每個視窗的字體都會縮小，直到你一眼都看不清楚發生了什麼變化。 VR就不同了。每個虛擬顯示器都足夠大，可以像真正的桌面顯示器一樣清晰閱讀。只需轉動一下頭部，就能看到全尺寸的螢幕。

生產性摩擦

我寫這類文章時總會被問到：這樣難道不會讓人感到不舒服嗎？

沒錯，我不會說謊。

穿戴這套設備需要一些時間。拿出頭顯，打開電源，在筆記型電腦上啟動串流播放器，在VR中啟動用戶端，然後將兩者配對。即使你已經習慣了，也需要1-2分鐘。而顯示器在你打開筆記型電腦的那一刻就啟動了。
離開一會兒也是有代價的。上廁所、買零食——摘下耳機本身就很麻煩。頭髮會被壓扁，眼鏡會留下印記，重新戴上就得重新調整。
重量。這因人而異，但有些人戴久了會覺得脖子有點不舒服。即使是「輕便」的耳機，畢竟也是綁在頭上的。

這些都是實實在在的缺點。 VR要達到實體顯示器那樣的即時體驗，還有很長的路要走。

一位開發者戴著VR頭顯，沉浸在漂浮的程式碼視窗中。

但這種不適感卻有著意想不到的好處。對我來說，啟動成本——也就是戴上頭戴裝置和啟動應用程式所需的那1-2分鐘的摩擦——反而是抵銷的。

一旦戴上，我就不想摘下來了。所以我就一直坐在那裡。

想想我在普通筆記型電腦上的工作方式。建置開始，代理暫停，測試套件運作30秒，上下文就開始洩漏。我打開另一個任務，回覆一則訊息，查看一個無關的標籤頁，原來的線程就逐漸冷卻下來。

VR 並不能完全杜絕分心。我仍然可以打開聊天視窗、瀏覽器標籤頁以及其他所有東西。改變的是預設的操作路徑。一旦戴上頭顯，螢幕佈局就位，程式碼環繞在我周圍，繼續編碼就成了阻力最小的選擇。而且，由於摘下頭戴裝置需要重新調整，所以我乾脆就不摘了。

結果就是：在VR裡，我常常可以連續3-4小時坐在同一個座位上寫程式碼。測試結果始終在我面前，所以我可以隨時查看它們，而不是分心回來面對一大堆莫名其妙的差異。

正是這令人惱火的地方讓我留了下來。

和在咖啡館工作一樣。到達咖啡館前的種種不便，恰恰促使你一旦到達那裡，就要充分利用時間。 VR 就像是戴在我頭上的咖啡館。

結論

這是我最終採用的工作流程：每個代理程式都有一個 VSCode 窗口，每個窗口都將 CLI 保留在程式碼或差異旁邊，而 VR 為這些視窗提供了足夠的空間以保持可讀性。

這就是我一直堅持使用它的全部原因。我並不是想讓程式設計看起來很未來，也不是想讓大家去買頭戴裝置。我只是想防止多智能體程式設計變成一堆事後我才去查看的、自以為是的總結。

安裝過程並不順利。它比打開筆記型電腦更重、啟動更慢、更別提操作了。但一旦坐進去，這些摩擦反而成了我的優勢。我可以保持坐姿，始終將特工納入視野，並縮短巡檢間隔。

對我來說，VR編程不是為了逃離辦公桌。而是為了在糟糕的改動造成更大影響之前，讓代理程式、程式碼、差異和測試輸出始終可見。

以下所有內容都是實際的設定細節：耳機、綁帶，以及一個與主題無關的額外配件，它恰好讓我能夠將這個裝置融入我的日常生活中。

附錄

6.1. 耳機

對於那些看到這裡並想知道我實際使用什麼的讀者。

我現在用的是Meta Quest 3。 Overay和 Immersed 兩款軟體在上面運作都很流暢，而且它能可靠地滿足我日常五螢幕工作空間的需求。價格、重量、螢幕直通效果、應用程式相容性以及能否隨時查看實體鍵盤都是我考慮的重要因素。如果新機價格太高，買二手的也是個不錯的選擇，前提是機器狀況良好——我的這台就是 300 美元淘來的二手貨。

我的直言不諱的建議是：不要僅憑原廠腕帶就對 Quest 3 下定論。如果是短時間玩遊戲，它或許還能勉強接受；但如果是用來編程，我建議立刻更換。

最難的選擇是錶帶。大多數人追求的是“輕量化”，但實際花了幾個小時編寫程式碼後，我發現我更關心兩件事：總重量和重量分佈。它們並不相同。

Meta Quest 3 配有輕量錶帶