AI coding 的速度，要從建議算到放心接受
AI 建議幾乎立刻就出現在編輯器裡。你按下接受，接著才發現它順手改了另一個 state、把原本的例外處理拿掉，還讓手機版的版面多出一條橫向捲軸。
建議出現得很快，這次編輯卻一點也不快。
這種落差正在變得更常見。過去的 inline completion 通常只補完眼前幾個 token，改動範圍小，開發者也容易預測。現在 completion、next edit 和較長距離的修改開始共用模型與入口。同一次 Tab，有時只完成一行，有時會跨過幾個區塊，甚至牽動另一個檔案。
底層當然還是要追求低延遲。Diff patch、cache 和更有效率的傳輸都能減少等待。但從開發者的角度看，候選改動出現只是起點。最後決定交付速度的，是人要花多久才敢把它留在程式庫裡。
一次 AI 編輯，其實還有後半段
我習慣把一次 AI 輔助編輯看成五段時間。
第一段是等待。從游標停下、指令送出或某個觸發條件發生，到第一個可用的建議出現。這是大家最熟悉的 suggestion latency，也是模型、cache 與網路最直接影響的部分。
第二段是辨認範圍。工具準備動哪個元件、哪些檔案、哪一份 state？它是在補完我已經開始寫的東西，還是在替我猜下一個任務？如果要讀完整份 diff 才知道這次動作有多大，介面就已經把理解成本丟回給人。
第三段是理解 patch。改動能不能分段看、分段留？我可能同意新的 empty state，卻不同意它順便改寫資料取得邏輯。若只能整包接受，再手動拆掉不要的部分，生成端省下的幾秒會在 review 裡加倍還回去。
第四段是取得證據。小幅型別修正也許跑 typecheck 就夠；牽動互動狀態的前端修改，可能還要窄範圍測試、指定 viewport 的 preview，以及鍵盤操作和 a11y 檢查。驗證不是完成之後才附加的儀式，它本來就是這次編輯的一部分。
第五段是修正與復原。方向錯了，能不能乾淨回到改動前，又不蓋掉我同時寫下的內容？拒絕的理由能不能留給下一輪，而不是讓我重新解釋一次？一秒生成、十五分鐘清理的建議，不該在生產力報表裡算成一次成功。
接受率很容易把成本藏起來
許多工具會看建議接受率。這個數字有用，但單獨看很危險。
使用者可能先接受一個大 patch，只因為局部挑選很麻煩，接著再花時間修回來。團隊也可能因為建議出現得太積極，養成先按 Tab、看到測試失敗再說的習慣。這些情況都會提高接受率，卻沒有讓工作更快。
比較誠實的做法，是把接受後的動作也算進去：剛接受就修改了多少、多久之內發生 revert、驗證失敗幾次、人工 review 花了多久。還要依改動大小與風險分層。一行 import、一個元件的狀態轉換，以及跨檔案的資料流調整，不該塞進同一個平均值。
這些數字的用途也要說清楚。它們應該用來比較工具或版本改變前後，成本究竟降在哪一段；不該拿來評分哪位工程師按 Tab 按得比較勤。否則團隊很快就會得到漂亮的接受率，以及更糟的程式碼。
前端工作最容易看見這條路有多長
假設一個小型 SaaS 團隊要替營運後台新增任務狀態面板，而且面板會依 agent 的執行狀態改變。前期探索時，可以到生成式 UI 資源比較 SDK、開源專案與 agent-native UI 的做法。進到程式庫開工後，資源清單不能替團隊決定這個 patch 是否可接受。
候選改動至少要讓人一眼看出：它動了哪些元件與 state schema，純顯示部分能不能先留下，正式環境操作是否仍由既有權限控制。接著還要確認 loading、failure 和 partial result 是否都能顯示，窄螢幕會不會跑版，鍵盤能不能走完整個流程。
如果 AI 一次把元件、資料流和 action 都改完，畫面看起來也能運作，第一印象通常很快。但 review 者為了分辨哪些部分安全，可能得把整條狀態流重新走一遍。反過來說，一個生成稍慢、範圍標示清楚、可以局部接受的工具，總時間反而更短。
這也是為什麼 time-to-first-suggestion 不夠。更值得追的是 time-to-understand，以及 time-to-validated-acceptance：人何時理解這次改動，又何時拿到足夠證據把它留下。兩者之間的差距，往往就是 AI 工具沒有出現在宣傳數字裡的成本。
把計時器放在編輯完成的地方
模型與 API 會更新，preview 會進入 GA，也會被新版本取代。若團隊只追某個模型當下的速度或 benchmark，工作流的品質就會跟著版本名稱漂移。
比較耐用的記錄其實很小：候選多久出現、範圍多久看懂、驗證等了多久、接受後是否立刻修正，以及失敗時能否完整復原。累積幾週後，團隊就能看出新版本是真的省時間，還是只把等待移到了 review、測試或清理。
AI coding 工具會繼續把更多編輯型態收進同一個入口，速度也會繼續改善。一次編輯要等到開發者看懂改動、驗完該驗的部分，並決定把它留下，才算完成。計時器應該停在那裡，而不是停在模型結束輸出的那一刻。