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產生有用工作的關鍵是，將正確的信息放入那個窗口中。其他兩個支柱不僅是行動的地方；它們也是助手所能擁有的最豐富的上下文。項目管理包含變更背後的意圖；基礎設施包含系統實際運行時的行為。代碼説明構建了什麼——那些支柱説明為什麼以及是否有效。侷限於編輯器，助手在大部分證據不可見的情況下進行推理。

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

風險與防護

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

邊界是一個選擇

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