AI編碼工具應超越編輯器

AI輔助編碼工具正在改變軟體開發的方式，但它們大多被限制在程式碼編輯器內。本文將探討為什麼這些工具應該超越編輯器，覆蓋整個開發迴圈。

AI輔助編碼的本質

在傳統開發中，開發者手動將意圖轉化為程式碼：你在大腦中保持目標，然後鍵入實現。AI輔助編碼在這一路徑中插入了一個新層——你用自然語言描述需求，工具將其轉化為程式碼，然後你審查並最佳化結果。這種形式的最鬆散版本被稱為“氛圍編碼”，但底層的機制是相同的：自然語言成為與程式碼庫互動的主要介面，由工具作為中介。

傳統開發直接將開發者與程式碼連線。AI輔助開發則插入了一個AI助手，由自然語言驅動，開發者審查其產出。這是一個看似微小的變化，卻帶來了實踐上的巨大不同。而且，幾乎毫無例外，這個變化被限定在編輯器內。

開發不僅僅是編碼

這幅圖景預設了有趣的工作就是寫程式碼。退一步看，構建軟體實際上涉及什麼，編碼只是更大迴圈中的一個環節。

大多數開發工作圍繞三個支柱迴圈：

• 專案管理：計劃、討論和記錄工作的地方，包括路線圖、功能和bug。這是意圖在程式碼存在之前被捕獲的地方。
• 編碼：在開發環境中實現意圖。
• 基礎設施：將程式碼部署到生產環境、執行和觀察的地方。

這些不是一條直線；它們是一個迴圈。你在專案管理工具上計劃和記錄變更，轉到開發環境實現它，然後推向生產——而在那裡學到的東西（bug、指標或投訴）會迴流到計劃中，作為下一項工作。

開發者位於這三個支柱的中心，在它們之間移動，形成一個連續的迴圈——計劃工作、構建它、交付並觀察，然後回到計劃。在這個迴圈中每繞一圈，就是一次真正的進步。寫程式碼只是中間的三分之一。

在迴圈中放置助手

現在，將AI助手放在這張地圖上。今天，它幾乎完全存在於編碼支柱內——在編輯器中，幫助編寫下一個函式。它在這方面很擅長，這裡不是要把它趕走。關鍵是，將它限制在一個支柱中會使它對其他兩個支柱視而不見，從而無法判斷自己的工作是否重要。

AI輔助編碼已經使自然語言成為程式碼庫的介面。將同樣的舉措擴大到整個迴圈，助手就成為開發本身的介面：你表達一次意圖，它就會將該意圖貫穿所有三個支柱——開啟工單、編寫程式碼、交付並讀取生產環境的反饋。開發者仍然做出決策；助手成為他們透過其作用於整個迴圈的層，而不是侷限於一個站點的程式碼生成器。

編碼

這是助手已經佔據的支柱——直接在開發環境中，無論是透過終端的命令列工具，還是內建於VS Code等編輯器中。必須坦白地說，這非常有效。生成函式、重構、解釋不熟悉的程式碼、編寫測試——編輯器內的助手已經贏得了它的位置。論點不是要離開編碼支柱，而是不要將其誤認為是整個工作。

專案管理

程式碼很少是為了自身而存在；它存在於滿足人類在專案管理工具（如Jira、Asana或Trello）中描述的內容——一個工單、一個問題、一個路線圖項。能夠讀寫專案管理層的助手可以將變更與其意圖連線起來：從工單中提取驗收標準，在接觸程式碼前起草計劃，隨著工作進展更新狀態，並立即提交它發現的bug，而不是留待某人注意。計劃和程式碼不再漸行漸遠，因為同一個參與者確保兩者誠實。這種連線透過團隊已經使用的工具執行：大多數工具暴露命令列介面，並且越來越多的工具提供了模型上下文協議（MCP）伺服器——這是一個開放標準，允許助手讀寫外部系統——因此將助手接入越來越像配置而非定製粘合。

基礎設施

助手能做的最有價值的事情通常不是寫程式碼——而是關閉已編寫程式碼的迴圈。這意味著能夠部署、讀取日誌、檢查執行中的資源，以及在實際重要的地方觀察變更的效果。從diff猜測與從生產環境讀取之間的區別，就是希望修復起作用與知道它起作用之間的區別。接入方式已經存在：主要的雲提供商——Google Cloud、AWS——提供全面的CLI，因此部署、跟蹤日誌和檢查資源都是助手可以執行的普通命令，而不是定製的整合。

閉合迴圈帶來的好處

三個獨立的工具——一個用於規劃，一個用於編碼，一個用於運維——強迫人類成為它們之間的整合層，手動跨每個邊界攜帶狀態和交接。跨越所有三個支柱的助手自己承擔這個負擔——而且這種跨度也讓它能夠檢查自己的工作。侷限於編輯器的工具提出一個變更就停止了；它無法判斷部署是否成功，它目標的指標是否移動，或者它是否重新引入了上週的bug。能夠看到生產環境的工具可以做到這一點。使迴圈成為迴圈的反饋——現實報告——正是編輯器邊界切斷的東西。

在這之下有一個更基本的事實：大語言模型（LLM）的好壞取決於其上下文視窗——它推理所依據的決策、歷史和當前狀態的工作集。讓LLM產生有用工作的關鍵是，將正確的資訊放入那個視窗中。其他兩個支柱不僅是行動的地方；它們也是助手所能擁有的最豐富的上下文。專案管理包含變更背後的意圖；基礎設施包含系統實際執行時的行為。程式碼說明構建了什麼——那些支柱說明為什麼以及是否有效。侷限於編輯器，助手在大部分證據不可見的情況下進行推理。

這種擴充套件伴隨著一個紀律。更多的上下文並不自動是更好的上下文——關鍵的是視窗內的訊雜比，這個問題現在被稱為上下文工程。擴大範圍會提高兩者的供應：連線工單上決定性評論的能力可能同樣容易地拉入十個過時的評論，而確認修復的日誌行旁邊有更多不相關的日誌行。目標不是將所有三個支柱都倒入上下文——而是在正確的時間從每個支柱中提取正確的切片。範圍使得正確的上下文可達；它並不免除你選擇它的責任。

風險與防護

當然，觸及生產環境和專案管理工具正是爆炸半徑所在。能夠部署的助手也可能破壞部署；能夠關閉工單的也可能關閉錯誤的工單。危險並不均勻分佈。錯誤的工單編輯尷尬但可逆；錯誤的生產操作可能兩者都不是。基礎設施是不可逆的所在——丟失的資料庫、未修復的不良部署——這使得它成為需要最嚴格防護措施的支柱。答案不是退回到編輯器，那裡工具安全是因為它無能為力。答案是我們應用於人類訪問的相同方法：範圍許可權、明確的讀寫分離、在不可逆或面向外部的操作前明確的確認，以及所做操作的審計追蹤。設計得當，這些防護措施使廣泛訪問變得安全；設計不當，狹窄的訪問只會使其無用。

邊界是一個選擇

編輯器邊界是一個歷史偶然——這些工具恰好從這裡開始，而不是它們必須停止的地方。開發工作是一個跨越三個支柱的迴圈，只參與一個支柱的助手將始終在幫助完成三分之一的工作，同時猜測其餘部分。值得構建的未來方向是跨越整個週期的助手。這一未來的真正約束是信任和控制——而不是範圍。