自從 AI 輔助編碼工具和各類 Agent 興起以來(lái)，“IDE 已死”的說(shuō)法層出不窮，仿佛傳統(tǒng)代碼編輯器已經(jīng)毫無(wú)存在價(jià)值。

然而，Addy Osmani——這位在 Google 工作近 25 年、曾在 Chrome 團(tuán)隊(duì)主導(dǎo) DevTools、Lighthouse 和 Core Web Vitals 的資深工程師，結(jié)合自己日常使用的多種 AI 工具給出了更細(xì)致的觀察。

他表示，IDE 的確正在失去過(guò)去作為開(kāi)發(fā)“重心”的獨(dú)占地位，開(kāi)發(fā)者的工作流程正向多 Agent 協(xié)作、調(diào)度和審查界面遷移，但這并不意味著它消失了。

代碼編輯器仍然存在，只是對(duì)于越來(lái)越多的開(kāi)發(fā)者而言，它不再是編程時(shí)打開(kāi)的第一個(gè)界面而已。

來(lái)源：https://addyo.substack.com/p/death-of-the-ide

作者 | Addy Osmani 編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

開(kāi)發(fā)者的工作“重心”正在發(fā)生變化。注意，不是消失，而是轉(zhuǎn)移。

過(guò)去，我們習(xí)慣在一個(gè)代碼編輯器窗口里一行一行地改代碼。現(xiàn)在，越來(lái)越多的時(shí)間被花在“看著 Agent 干活”上，因?yàn)檫@些 Agent 會(huì)自己做規(guī)劃、批量改文件、跑測(cè)試，然后把改動(dòng)整理好，等人類來(lái)審核。

傳統(tǒng)意義上的 IDE，可能不再是軟件開(kāi)發(fā)的絕對(duì)核心，要么被邊緣化，要么徹底進(jìn)化成另一種形態(tài)。

看看很多開(kāi)發(fā)者（包括我）已經(jīng)在日常使用的這些工具：Conductor、Claude Code Web、GitHub Copilot Agent、Jules、Vibe KanBan，甚至 cmux，你會(huì)發(fā)現(xiàn)一個(gè)共同趨勢(shì)——真正的“主界面”正在變成調(diào)度和控制這些 AI Agent 的那一層，而代碼編輯器，反而退居成底層的一種“工具組件”。

Cursor 最近發(fā)布了 Glass——一個(gè)全新的界面，其設(shè)計(jì)宗旨是讓“與智能代理協(xié)作”這件事變得更清晰、更直觀，而且始終在你的掌控之中。在這個(gè)界面設(shè)計(jì)里，管理 Agent 本身成了核心體驗(yàn)，而傳統(tǒng)的代碼編輯器，則變成你在需要深入細(xì)節(jié)時(shí)才會(huì)打開(kāi)的工具。

這個(gè)工具發(fā)布之后，開(kāi)發(fā)者的反饋也來(lái)得很快：

現(xiàn)在的 Cursor，更像一個(gè)“代理調(diào)度中樞”（Agent Orchestrator），而不是傳統(tǒng)意義上的 IDE。并行管理多個(gè) Agent，也變得輕松多了。

但 Glass 只是更大趨勢(shì)中的一個(gè)縮影。像 cmux 這類終端界面也在說(shuō)明一件事：我們熟悉的那些操作界面，正在被重新塑形，更好地服務(wù)于“多 Agent 協(xié)作”這種新的工作方式。

從“改文件”，到“控流程”

以前，IDE 都是圍繞一套固定流程優(yōu)化的：打開(kāi)文件 → 改代碼 → 編譯 → 調(diào)試 → 再來(lái)一遍?，F(xiàn)在業(yè)界經(jīng)常有人說(shuō)“IDE 已死”，是因?yàn)橐坏?Agent 能自動(dòng)干完大部分事，這套循環(huán)就不再是決定效率高低的關(guān)鍵了。

新的工作節(jié)奏，更像這樣：明確目標(biāo) → 交給 Agent → 觀察執(zhí)行 → 審查改動(dòng) → 合并結(jié)果。它和“帶聊天框的自動(dòng)補(bǔ)全”最大的區(qū)別在于：Agent 不僅能用工具自主完成任務(wù)，而且配套的界面，也在圍繞“如何把這種自主能力管住、用好”來(lái)設(shè)計(jì)。

這種變化，其實(shí)已經(jīng)在一批高頻工具中落地了。比如 Claude Code（Web 或桌面版）和 Codex，可以讓開(kāi)發(fā)者把結(jié)構(gòu)清晰的任務(wù)直接交給運(yùn)行在云端隔離環(huán)境里的 Agent 來(lái)完成，進(jìn)度在瀏覽器里一目了然——不需要終端，也不用本地折騰環(huán)境。

GitHub Copilot 的 Agents 更進(jìn)一步：它能自己規(guī)劃并完成跨多個(gè)文件的修改，自動(dòng)建分支、跑測(cè)試，最后把結(jié)果整理成一個(gè) PR 交給你審。開(kāi)發(fā)者的角色，從“手把手指揮每一步”，變成“看結(jié)果、提反饋、再迭代”。

Conductor 則走了另一條路：它是一個(gè)桌面應(yīng)用程序，可以同時(shí)跑多個(gè) Claude Code Agent，每個(gè)在獨(dú)立工作空間里執(zhí)行任務(wù)，你可以實(shí)時(shí)看到它們各自的進(jìn)展。

而 Google 的 Jules 更像“異步外包”：你把任務(wù)分派出去，它在后臺(tái)慢慢跑，完成后你再回來(lái)驗(yàn)收結(jié)果。

這些工具的核心思路都一樣：干活的主體是 Agent，不是文件本身。真正值得優(yōu)化的界面，是幫你分配任務(wù)、跟蹤進(jìn)度、審核結(jié)果的界面，而不是讓你把代碼敲得更快的編輯器本身。

正在成型的“代理調(diào)度層”

只有當(dāng)你仔細(xì)觀察這些工具中趨同的界面模式時(shí)，“IDE 被替代”的說(shuō)法才顯得有說(shuō)服力。

工作隔離被當(dāng)成了一項(xiàng)基礎(chǔ)能力。并行運(yùn)行的 Agent 之間必須避免互相干擾。在這一點(diǎn)上，幾乎所有認(rèn)真做這類工具的團(tuán)隊(duì)，都選擇了 git worktree 或類似機(jī)制作為解決方案。Conductor 為每個(gè) Agent 會(huì)話分配獨(dú)立工作空間；Vibe Kanban 在其看板驅(qū)動(dòng)的 Agent 工作流中也采用同樣方式。這個(gè)模式幾乎普遍存在，因?yàn)閱?wèn)題是真實(shí)存在的：沒(méi)有隔離，多個(gè) Agent 同時(shí)工作只會(huì)帶來(lái)混亂。

以計(jì)劃和任務(wù)狀態(tài)為核心界面。像 Vibe Kanban 這樣的工具，將傳統(tǒng)的“標(biāo)簽頁(yè)和文件”頂層思維模型替換為“任務(wù)與狀態(tài)”。你創(chuàng)建任務(wù)卡片（比如一個(gè)落地頁(yè)、后端服務(wù)或郵件集成）時(shí)，把它們分配給具體 Agent 和模型，然后像管理輕量級(jí)項(xiàng)目看板一樣管理整個(gè)工作——唯一不同的是，“團(tuán)隊(duì)”是自動(dòng)運(yùn)作的。這種界面其實(shí)就是項(xiàng)目管理板，只是 Agent 在執(zhí)行實(shí)現(xiàn)部分。

后臺(tái) Agent 與異步優(yōu)先設(shè)計(jì)。一些最有意思的工具，根本不要求你在執(zhí)行過(guò)程中全程盯著它們。Cursor、GitHub Copilot 和 Antigravity 都支持后臺(tái)運(yùn)行的 Agent——你定義目標(biāo)，然后可以離開(kāi)，完成后再回來(lái)查看結(jié)果就行。Jules 也是類似方式：分派任務(wù)，完成后再看差異。這里隱含的理念是：你的注意力太寶貴，不值得用來(lái)看進(jìn)度條。這和 IDE 的實(shí)時(shí)同步反饋循環(huán)截然不同。

并行 Agent 的注意力管理。當(dāng)多個(gè) Agent 同時(shí)運(yùn)行時(shí)，真正的瓶頸是——你如何知道現(xiàn)在該關(guān)注哪個(gè) Agent。這就是為什么 Conductor 會(huì)展示所有會(huì)話的實(shí)時(shí)進(jìn)度，而 cmux 在終端面板中引入了通知圈和未讀徽章。“Agent 需要注意”正成為開(kāi)發(fā)環(huán)境中的一級(jí)事件——需要你進(jìn)行路由和分流，而不僅僅是看一眼。

嵌入軟件生命周期的Agent。GitHub 的 Copilot 編碼代理是異步的，由控制層保護(hù)，并由 GitHub Actions 提供支持。它不僅跟代碼的寫(xiě)作相關(guān)，更與實(shí)際發(fā)布流程緊密掛鉤（issues → PRs → CI → merge）。

這些工具均未宣稱 IDE 已過(guò)時(shí)——其中許多仍與 IDE 兼容互通。但上述反復(fù)出現(xiàn)的模式（并行工作區(qū)、基于差異的審閱、任務(wù)狀態(tài)管理、后臺(tái)執(zhí)行、生命周期集成），正是“IDE 已死”論者所說(shuō)的“開(kāi)發(fā)工作重心轉(zhuǎn)移”的核心體現(xiàn)。

為什么開(kāi)發(fā)者仍然離不開(kāi) IDE？

對(duì)“IDE 已死”最有力的反駁是：IDE 仍然把幾個(gè)真正復(fù)雜的問(wèn)題壓縮在一個(gè)高保真反饋循環(huán)里——精準(zhǔn)導(dǎo)航、本地推理、交互式調(diào)試，以及通過(guò)直接操作系統(tǒng)來(lái)理解它的能力。

即便是最前沿的 Agent 調(diào)度工具，也保留了手動(dòng)編輯的余地。例如，在工具里直接審查 diff、對(duì)改動(dòng)發(fā)表評(píng)論，然后再在編輯器里打開(kāi)結(jié)果進(jìn)行手動(dòng)調(diào)整。這本身就是對(duì)一個(gè)事實(shí)的承認(rèn)：人工干預(yù)仍然是工作流程的一部分。

Agent 工具本身也暴露了它的局限性。對(duì)于大型倉(cāng)庫(kù)的多文件重構(gòu)，仍然是軟件工程 Agent 最難應(yīng)對(duì)的挑戰(zhàn)之一。這正是交互式代碼導(dǎo)航和人類判斷依然最有價(jià)值的場(chǎng)景——你需要在腦中構(gòu)建系統(tǒng)模型，而 Agent 單憑上下文無(wú)法完整重建。

讓開(kāi)發(fā)者仍然依賴 IDE 進(jìn)行深度檢查的原因，是 Agent 往往“差一點(diǎn)就對(duì)”。當(dāng)結(jié)果 90% 正確但存在不易察覺(jué)的 Bug 時(shí)，發(fā)現(xiàn)問(wèn)題的成本往往比自己寫(xiě)一遍還高。

對(duì)于高風(fēng)險(xiǎn)改動(dòng)，IDE 仍然是進(jìn)行這種深度、精確檢查的最佳工具。

新的成本：審查疲勞與治理負(fù)擔(dān)

如果開(kāi)發(fā)變成“并行運(yùn)行多個(gè) Agent”，那么工作流繼承的問(wèn)題就不再像文本編輯，而更像分布式系統(tǒng)管理——可觀察性、權(quán)限管理、隔離以及治理。

Agent 工作流顛倒了勞動(dòng)方式。你不再是寫(xiě)代碼，而是在審查代碼。乍一聽(tīng)像是效率提升，但當(dāng)你一天結(jié)束時(shí)盯著十二個(gè)并行 Agent 的十二個(gè) diff 時(shí)，審查疲勞的感覺(jué)就非常真實(shí)。這也是為什么這一領(lǐng)域最用心的工具，更強(qiáng)調(diào)注意力分流、結(jié)構(gòu)化計(jì)劃和以審查為先的門(mén)檻，而不是默認(rèn)追求完全自主。

隨著 Agent 獲得更多工具、代碼庫(kù)和外部系統(tǒng)的訪問(wèn)權(quán)限，安全面也隨之?dāng)U大。Agent 可以瀏覽網(wǎng)頁(yè)、查詢數(shù)據(jù)庫(kù)、寫(xiě)入文件系統(tǒng)、觸發(fā)部署，因此它們“被允許做什么”變得和“能做什么”一樣重要。

在可觀察性和控制方面，IDE 集成的 Agent 模式已經(jīng)推動(dòng)了明確的工具日志和審批門(mén)檻。一旦 Agent 異步運(yùn)行并觸碰 CI 流程，治理問(wèn)題就不再可選。

未來(lái)存留下來(lái)的會(huì)是 IDE？還是控制層？亦或者兩者？

從整體趨勢(shì)來(lái)看，“IDE 消亡” 這一說(shuō)法在開(kāi)發(fā)重心轉(zhuǎn)移這個(gè)大方向上是對(duì)的，但從字面預(yù)測(cè)來(lái)看并不準(zhǔn)確。

這一觀點(diǎn)想要表達(dá)的是：IDE 不再是主要工作區(qū)，而是成為若干輔助手段之一——用于有針對(duì)性的檢查、調(diào)試和最終編輯——而規(guī)劃、調(diào)度、審查和 Agent 管理則轉(zhuǎn)移到儀表盤(pán)、Issue 跟蹤、可觀察終端和云端控制層。

“更大的 IDE” 這一表述同樣站得住腳。新一代 IDE 是一套完整系統(tǒng)，提供多 Agent 調(diào)度、隔離工作空間、權(quán)限與審計(jì)日志、以 diff 為核心的審查、可靠工具連接以及注意力分流的系統(tǒng)。代碼編輯器仍然存在，只是不再是開(kāi)發(fā)工作的入口。

IDE 并未消亡，只是被去中心化了。開(kāi)發(fā)工作正在向外擴(kuò)展——進(jìn)入那些由人定義目標(biāo)、分派給并行 Agent 運(yùn)行時(shí)、更多時(shí)間用于監(jiān)督、審查和治理的調(diào)度界面，而不只是手動(dòng)敲代碼。

在保障代碼正確性、理解復(fù)雜邏輯，以及處理智能代理仍難以勝任的難題時(shí)，IDE 依然至關(guān)重要。但它已不再是編程發(fā)生的唯一場(chǎng)所；并且對(duì)越來(lái)越多的開(kāi)發(fā)者而言，它也不再是打開(kāi)的第一個(gè)界面。

【活動(dòng)分享】"48 小時(shí)，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"由 CSDN&奇點(diǎn)智能研究院聯(lián)合舉辦的「全球機(jī)器學(xué)習(xí)技術(shù)大會(huì)」正式升級(jí)為「奇點(diǎn)智能技術(shù)大會(huì)」。2026 奇點(diǎn)智能技術(shù)大會(huì)將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開(kāi)，大會(huì)聚焦大模型技術(shù)演進(jìn)、智能體系統(tǒng)工程、OpenClaw 生態(tài)實(shí)踐及 AI 行業(yè)落地等十二大專題板塊，特邀來(lái)自BAT、京東、微軟、小紅書(shū)、美團(tuán)等頭部企業(yè)的 50+ 位技術(shù)決策者分享實(shí)戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風(fēng)險(xiǎn)、降低試錯(cuò)成本、獲取可復(fù)用的工程方法論，真正實(shí)現(xiàn) AI 技術(shù)的規(guī)?；涞嘏c商業(yè)價(jià)值轉(zhuǎn)化。這不僅是一場(chǎng)技術(shù)的盛宴，更是決策者把握 2026 AI 拐點(diǎn)的戰(zhàn)略機(jī)會(huì)。