當編輯器變成閱讀器：Amp Code 對開發者工作流的重新想像

本文整理自 Beyang Liu 在 AI Engineer World’s Fair 的演講。

「我現在已經很少手動編輯程式碼了。」這句話出自 Amp Code 的創辦人 Beyang Liu。對於一個專門打造 coding agent 的人來說，這聽起來可能有點諷刺，但這正是他觀察到的現實——當你真的開始重度使用 AI coding agent，你的工作內容會發生根本性的轉變。

這個轉變是什麼？從「寫程式碼」變成「審核程式碼」。而這個洞察，直接影響了 Amp 整個 UI 的設計方向。

編輯器的新身份

Liu 說，他現在把編輯器當成「閱讀器」（reader）而不是「編輯器」（editor）。這個說法乍聽有點奇怪——編輯器不就是用來編輯的嗎？但仔細想想，當你大部分的程式碼修改都是透過 agent panel 發出指令完成時，編輯器的主要功能確實變成了讓你「看」程式碼發生了什麼變化。

這種工作模式的轉變帶來了一個瓶頸：code review 的速度。Liu 觀察到，限制他「並行處理」多個 agent 任務的關鍵因素，不是 agent 的運算速度，而是他自己審核程式碼的速度。如果一個 agent 完成了一個任務，產出了一堆程式碼修改，你需要花時間去理解這些修改、確認它們是正確的、沒有引入奇怪的副作用。在你完成這個審核之前，你很難放心地讓 agent 繼續做下一個相關的任務。

這意味著，傳統的編輯器 UI——那種針對「寫程式碼」最佳化的介面——其實不太適合這種新的工作流程。

專為 Agent 產出設計的 Diff Viewer

基於這個觀察，Amp 團隊在編輯器擴充套件中內建了一個客製化的 diff viewer。這不是那種 Git 內建的簡單 diff 顯示，而是專門為「審核 agent 產出的大量程式碼修改」這個場景設計的。

首先，你可以選擇任意的 commit 範圍來檢視。這很重要，因為 agent 在處理一個任務的過程中可能會產生多個 commit，你可能想一次看完所有相關的修改，而不是一個一個 commit 去翻。

其次，這個 diff viewer 是可以直接編輯的。如果你在審核過程中發現某個地方需要微調，你不需要跳出 diff 視圖、找到對應的檔案、做修改、再回來——你可以直接在 diff 上面改。這個看似小的設計選擇，實際上大幅減少了審核過程中的摩擦。

第三，完整的程式碼導航功能仍然可用。你可以 go to definition、find references，就像在正常編輯程式碼一樣。這讓你在審核一個修改時，可以快速理解它影響的其他部分。

Tour of Changes：解決「從哪裡開始看」的問題

但最有意思的功能是「Tour of Changes」。Liu 說，審核一個大型程式碼修改時，最難的部分往往是決定從哪裡開始看。你面對著 15 個被修改的檔案，到底要先看哪一個？如果順序錯了，你可能會花很多時間去理解一個依賴其他修改才能看懂的程式碼，然後發現自己必須先回頭去看另一個檔案。

Tour of Changes 會自動分析這些修改，然後建議一個閱讀順序。它會告訴你：「你可能應該先看這個檔案，因為它定義了一個新的資料結構；然後看這個檔案，因為它使用了那個資料結構；最後再看測試檔案。」這種引導大幅減少了審核時的認知負擔。

這個功能反映了一個更深層的設計理念：在 agent 時代，好的開發者工具不只是要讓你「能做到」某件事，而是要降低你做這件事的認知成本。當 agent 每天產出的程式碼量遠超過你手寫的程式碼量時，你的瓶頸不再是「能不能寫出這段程式碼」，而是「能不能快速理解並信任這些程式碼」。

Thread 分享：團隊如何學習新的工作方式

除了個人的審核流程，Amp 還設計了一個團隊層面的功能：thread 分享。每一次你跟 agent 的對話——你給的 prompt、agent 的回應、產生的程式碼修改——都可以被儲存成一個 thread，然後分享給團隊成員。

這個功能解決的是一個新出現的問題：怎麼學習使用 coding agent。傳統的程式開發技能有大量的書籍、課程、最佳實踐可以參考。但「怎麼跟 agent 協作」這件事太新了，沒有人真的知道最佳實踐是什麼。每個人都在摸索，而且每個人摸索出來的技巧可能都不一樣。

有了 thread 分享，團隊成員可以互相看到對方是怎麼使用 agent 的。「嘿，我發現這個 prompting 技巧很有用，你看一下這個 thread。」或者「我卡在這個問題上了，你能幫我看看這個 thread 嗎？」這種透明度讓整個團隊可以更快地收斂到有效的工作模式。

Liu 提到，團隊儀表板上甚至會顯示每個人用 Amp 改了多少程式碼。這不是為了監控，而是為了創造一種「我們都在學習這個新工具」的氛圍，讓大家更願意分享自己的經驗。

終端機與編輯器：兩種介面，兩種使用情境

值得一提的是，Amp 同時提供了 CLI（終端機介面）和編輯器擴充套件。這不是為了多一個選項，而是因為這兩種介面服務的是不同的工作情境。

終端機版本適合那種「開著好幾個 terminal tab，每個 tab 跑一個 agent 任務」的工作流程。你可能同時處理三四個不相關的小任務，每個 agent 各自運行，你輪流去檢查進度。終端機的輕量和可複製性（開一個新 tab 就是一個新的 agent session）很適合這種場景。

編輯器版本則適合需要更深度整合的場景——你需要看到即時的 diagnostics、需要隨時跳到定義、需要用到各種編輯器快捷鍵。特別是在審核大型修改的時候，編輯器的 GUI 能力（視覺化的 diff、可互動的 Tour of Changes）比純文字終端機強大得多。

這種「多介面」的設計策略，本身也反映了 Amp 團隊對開發者工作流的細緻觀察。他們不是在問「哪種介面更好」，而是在問「在什麼情境下，哪種介面更合適」。

新工作模式需要新工具

回到最開始的那個觀察：當編輯器變成閱讀器，當開發者的主要工作從「寫程式碼」變成「審核程式碼」，我們需要的工具也必須跟著改變。

傳統的 IDE 是為「手動編寫程式碼」這個場景精心設計了幾十年的產物——語法高亮、自動完成、重構工具、除錯器。這些功能在新的工作模式下當然還是有用，但它們不再是最關鍵的。最關鍵的變成了：怎麼讓審核 agent 產出的程式碼變得更快、更可靠、更不容易漏掉問題。

Amp 的這些設計選擇——專為 agent 產出設計的 diff viewer、Tour of Changes、thread 分享——都是在回應這個新需求。這不代表他們的答案一定是對的，但他們至少在問對的問題。