--- schemaVersion: 1 slug: mp-268-20260409-trq212-claude-code-viewport-cli-ide ticketId: MP-268 lang: zh-tw title: Claude Code 的終端機革命——虛擬 Viewport 讓 CLI 變成 IDE summary: Claude Code 團隊重寫了終端機 renderer，用虛擬 viewport 實現零閃爍、滑鼠支援、固定輸入框——把 terminal 變成真正的 app。 originalDate: 2026-04-02 translatedDate: 2026-04-09 source: "@trq212 on X" sourceUrl: https://x.com/trq212/status/2039453692592873587 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-268-20260409-trq212-claude-code-viewport-cli-ide status: published replacementTicketId: null replacementUrl: null --- # Claude Code 的終端機革命——虛擬 Viewport 讓 CLI 變成 IDE > **來源:** [@trq212 on X](https://x.com/trq212/status/2039453692592873587) 用過 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 的人大概都有一個共同的痛苦記憶：問了一個大問題，Claude Code 開始噴輸出，整個畫面像抽風一樣狂跳。[Prompt](https://gu-log.vercel.app/glossary#prompt) 被推到不知道哪裡去了，想打個字中斷它，還得先找到游標在哪。2026 年了，AI 可以幫忙重構整個 codebase，但它連穩定顯示文字都做不到？ 這件事的荒謬之處在於：問題不在 Claude Code 本身，而是在終端機這個五十年前設計的介面。終端機的世界觀是「打字機」——一行一行往下吐，紙帶越來越長，沒人預期過這條紙帶上面會有一個 AI 在即時產出幾千字的回應。 Anthropic 的 [Thariq](https://gu-log.vercel.app/glossary#thariq)（@trq212）在四月一號直接在推特上宣布：「不是愚人節玩笑——Anthropic 重寫了 Claude Code 的 renderer。」 > **Mogu 忍不住說：** > > 「不是愚人節玩笑」——四月一號發這種東西，不加這句的話大概會有一半的人直接滑掉。但說真的，Claude Code 的 flicker 問題之前有多嚴重呢？2025 年 12 月那次 patch 已經減了 85% 的閃爍，結果大家還是在抱怨。可見剩下的 15% 才是最讓人抓狂的那部分——就像家裡有一隻蟑螂跟有一百隻蟑螂的差別不是數量，是「明明知道還有一隻但找不到」的心理折磨 ┐(￣ヘ￣)┌ --- ## 打字機的詛咒 要理解這次更新為什麼是「革命」而不是「修補」，得先搞懂終端機的致命限制。 傳統的終端程式靠 **scrollback buffer** 在運作——每一行新輸出就往下推，舊的東西往上滾。這套機制在 1970 年代設計的時候完全合理：那時候終端機就是打字機，一行一行吐字，吐完就吐完了。但 scrollback 有一個在那個年代無關緊要、在 2026 年卻致命的問題：**終端機不知道「畫面上現在看到什麼」**。它只知道「目前吐到第幾行了」。 所以當 Claude Code 需要更新畫面上的內容時——spinner 在轉、進度條在動、diff 在展開——它只能把整塊內容重新輸出一遍。結果就是閃爍。不是 Claude Code 寫得爛，是打字機模型根本不是設計來做這件事的。 好，既然打字機模型是問題的根源，Anthropic 的選擇是什麼？在打字機上面貼更多膠帶？ 不。他們把打字機丟了。 --- ## 從打字機到電視機 新 renderer 的核心想法用一句話就能講完：**不要再假裝終端機是打字機了，把它當成一台電視。** 技術上，新 renderer 使用了 **alternate screen buffer**——跟 vim、htop 這些「全螢幕」終端程式用的是同一招。打開 vim 的時候，原本的 terminal 畫面會「暫存」起來，vim 接管整個螢幕；關掉 vim 後，原本的畫面就回來了。Claude Code 現在做一模一樣的事：接管整個畫面，自己決定每個像素——不對，每個字元——要顯示什麼。 這代表 Claude Code 不再是「往 stdout 吐字串然後祈禱終端機好好顯示」了。它自己管理一個虛擬畫面，只渲染目前螢幕上看得到的東西。不在螢幕上的訊息？不渲染、不佔記憶體。需要更新？只更新有變化的那幾個 cell，其他地方不動。 > **Mogu 忍不住說：** > > 整條渲染管線長這樣：React → layout elements → 光柵化成 2D screen buffer → diff 前後兩幀 → 只輸出有差異的 ANSI sequences。這不就是瀏覽器的 virtual DOM diffing 搬到 terminal 裡嗎？React 生態系的人看到這個應該會覺得既荒謬又親切——React 從 web 打到 mobile 打到 VR，現在連 terminal 都不放過。下一步是不是 React for 微波爐 (⌐■\_■) 但「電視機模型」帶來的不只是零閃爍。一旦 Claude Code 掌控了整個畫面，很多以前不可能的事突然變得理所當然了。 --- ## 掌控畫面之後，事情開始變有趣 零閃爍是技術成就，但真正改變使用體驗的是接下來這兩件事。 **第一件：prompt 固定在底部。** 以前 Claude Code 的 prompt 是跟著輸出一起往下滾的。Claude 一邊輸出，prompt 就一邊被推到畫面外面。等它講完了，才能回到底部繼續打字。現在 prompt 永遠釘在畫面最底部。Claude 的輸出在上面滾，輸入區在下面不動。這跟所有現代通訊軟體的 UI 一樣——LINE、[Slack](https://gu-log.vercel.app/glossary#slack)、Discord 都是訊息往上長、輸入框不動。為什麼一個本質上就是「跟 AI 聊天」的工具，之前用的卻是打字機模型？因為它活在終端機裡，而終端機的預設行為就是打字機。現在這個枷鎖被打破了。 > **Mogu 畫重點：** > > 這裡有一個很反直覺的洞察：「輸入框固定在底部」這件事在任何 GUI 框架裡大概是第一堂課的作業題，但在終端機裡卻需要重寫整個 renderer 才能實現。這就是打字機詛咒的威力——不是做不到，是整個底層假設就不允許。有時候最簡單的功能需要最根本的架構變革，這件事在軟體工程裡反覆發生 (¬‿¬) **第二件：滑鼠可以用了。** 對，在終端機裡用滑鼠。點一下就能移動游標到 prompt 的任意位置；Claude 呼叫了工具、輸出一大段結果太長了，點一下收合起來；拖曳選取文字自動複製到剪貼簿；雙擊選字、三擊選行，跟一般編輯器行為一致。連滾輪速度都能調（`CLAUDE_CODE_SCROLL_SPEED` 環境變數）。 > **Mogu 真心話：** > > 終端機裡面用滑鼠，聽起來像在對 vim 信徒傳教——技術上沒問題，信仰上過不去。但認真想一下使用情境：跟 AI 對話不是在寫 code，是在看一堆工具輸出和長文回應。這時候硬要用鍵盤導航，就像堅持用遙控器打字搜尋 Netflix——可以，但何必呢？正確的工具配正確的場景，這不是背叛鍵盤，是尊重效率 (๑•̀ㅂ•́)و✧ 如果不想要滑鼠——比如 tmux 重度使用者需要 tmux 自己的滑鼠行為——可以只開零閃爍、不開滑鼠： ```bash CLAUDE_CODE_DISABLE_MOUSE=1 CLAUDE_CODE_NO_FLICKER=1 claude ``` --- ## 遊戲引擎等級的效能焦慮 當然，「接管整個畫面」聽起來很美好，但有一個很現實的問題：效能撐得住嗎？終端機如果每一幀都要重新計算整個虛擬畫面，那不就從閃爍地獄換成了卡頓地獄？ Anthropic 的 TUI 工程師在 Hacker News 上透露了答案。終端機要做到「看起來滑順」，每一幀的渲染預算大約是 **16 毫秒**（60fps）。目標是把渲染核心壓進 **約 5 毫秒**——留下 11 毫秒的餘裕給其他事情。 兩個關鍵招數讓這件事成為可能。第一，**Memoization**：如果一段內容沒有變化，不重新計算 layout，直接用快取。第二，**TypedArray screen buffer**：原本的 buffer 用一般的 JavaScript 物件和陣列，每次更新都產生大量短命物件，逼著 V8 的 GC 頻繁跑垃圾回收——GC 一跑，畫面就頓一下。改成 TypedArray 之後，記憶體是預先分配好的一整塊連續空間，GC 幾乎不需要介入。 > **Mogu 插嘴：** > > TypedArray 這招本質上就是在 JavaScript 裡模擬 C 語言的記憶體管理。預先分配固定大小的連續記憶體、每個 cell 佔固定 bytes、不會產生 GC 壓力——這在遊戲引擎的 web 版本裡很常見，但用在 terminal renderer 上確實是第一次見。一個 terminal app 的效能優化策略跟 3D 遊戲引擎同一個層級，這件事本身就說明了 Claude Code 正在把終端機推到什麼樣的邊界 ╰(°▽°)╯ 而且因為只渲染「目前可見的訊息」，不管對話開到第幾百輪，記憶體和 CPU 使用量都保持平穩。以前 scrollback 模式下對話越長畫面越卡的噩夢，正式結束。 --- ## 終端機還是終端機嗎？ 把這次更新放在更大的 context 裡看，會發現一件有趣的事。 2025 年 12 月，Claude Code 做了一次 flicker reduction patch，在舊架構上把閃爍減少了 85%。那是在打字機模型上面做的「盡力修補」——膠帶貼得很漂亮，但打字機還是打字機。 這次？打字機直接進博物館了。從 scrollback buffer 換成 virtual viewport、從被動輸出換成主動管理畫面、從純文字流換成可互動的 2D render surface。渲染管線 React → layout → rasterize → diff → ANSI，基本上就是在終端機裡面蓋了一個微型的 GUI framework。 這回答了一個 AI coding assistant 領域最根本的問題：**這些工具到底應該活在哪裡？** IDE 外掛？獨立桌面 app？Web app？Anthropic 的回答是：terminal，但要讓 terminal 的體驗追上 GUI。策略很明確——terminal 是開發者最熟悉的環境，進入門檻最低，但 UX 上限一直很低。所以做的事情不是換戰場，是把天花板拆了。 > **Mogu 插嘴：** > > 這個策略選擇比技術細節更值得關注。Cursor 選了 IDE、Windsurf 選了 IDE、Devin 選了 Web app——幾乎所有競爭者都在說「開發者需要更豐富的 GUI 體驗」。Anthropic 偏偏反其道而行：不是把開發者拉到 GUI 的世界，而是把 GUI 的能力推進 terminal 的世界。這是一個賭注——賭 terminal 的分佈優勢（每台電腦都有、每個開發者都會用）比 GUI 的體驗優勢更重要。從這次更新來看，這個賭注至少目前站得住腳 (ﾉ◕ヮ◕)ﾉ\*:･ﾟ✧ --- ## 結語 [Boris Cherny](https://gu-log.vercel.app/glossary#boris-cherny)（Anthropic 工程師）在公告裡用了一句精準的描述：「在終端機 renderer 的限制裡生存，同時給出更豐富、更高效能的體驗。」Renderer 還很早期、有 tradeoffs——但已經讓 Anthropic 內部大多數使用者回不去舊版了。 最低版本 v2.1.89，一行指令就能試： ```bash CLAUDE_CODE_NO_FLICKER=1 claude ``` 五十年前，終端機被設計成打字機。2026 年，有人決定不接受這個前提了。搜尋用 `Ctrl+o` → `/`，tmux 相容（iTerm2 的 `-CC` 模式除外），不滿意隨時關掉。但大概不會想關——畢竟誰用過聊天室之後，還會想回去用打字機呢 (◕‿◕)