AI / ENGINEERING SYSTEMS

AI 把實作變快後，
團隊真正卡在哪裡？

Andrew Yuan · 網站長文改寫 · 編輯草稿

依 LinkedIn 公開觀點延伸，結合我目前的管理原則；文中假設情境與討論例子不代表已驗證的實務成果。

我不只看 AI 讓實作快了多少，也看團隊能否把產出接成交付，以及工程師是否仍能理解、判斷並承擔責任。

AI 帶來的實作速度很容易看見。一個想法可以更快變成程式，一段不熟悉的程式也可以更快得到解釋。這些能力有用，但從程式碼到產品交付，中間仍有一段需要人理解與判斷的路。

所以我想把問題往外看一點。除了實作花多少時間，一個變更還會在哪裡等待？

先分開產出能力與承接能力

假設團隊明天開始，實作時間縮短成原來的三分之一。review 的時間、整合的條件、測試環境與發布節奏都維持原狀。

更多變更可能排進 review，也可能在測試或整合時等待。這裡有兩種能力：一種是把工作做出來；另一種是讓工作經過理解、驗證與整合，成為能交付的結果。前者增加，不代表後者已經一起增加。

瓶頸也不一定永遠在 review。AI 可能協助審查與測試，原有的等待可能消失，限制可能移到發布條件或跨團隊承諾。這是思考用的情境，不能只因程式碼變多，就判定團隊一定塞車。

管理者需要看的是：更多工作已經走完交付路徑，還是只是換了一個地方排隊？

等待裡面，有資訊

如果一個變更反覆等待 review，「等待」本身還不足以解釋原因。reviewer 是否缺少背景？變更是否太大？需要拍板的人是否清楚？還是驗證結果尚未足以支持決策？

可以先挑一個實際變更，沿著它的路徑看：最後完成了哪一步、下一步由誰接手、還缺什麼條件，以及是否反覆退回修改。這些紀錄比一句「大家太忙」更接近問題。

缺脈絡時，安排更多 reviewer 可能只是讓更多人重新理解；缺測試環境時，要求 RD 再快一點也不會釋放環境；範圍還沒決定時，團隊可能正在把尚未被選定的答案做得更完整。

支援也要對準原因。補齊變更說明、縮小一次整合的範圍、協調測試資源，或先做範圍取捨，承接的是不同的限制。

這是依原文延伸的觀察方式。比較調整前後時，要一起看等待是否減少、返工是否改變，以及問題是否只是被推到下一關。等待有時也在保護必要的驗證，不能只為了縮短時間就拿掉。

讓判斷的依據能被檢查

AI 可以很快給出完整的實作。工程師仍需要掌握足以承擔責任的脈絡：它解決什麼問題、依賴哪些假設、改動哪些邊界，以及什麼證據支持它可以進入下一步。

「我看過了」是一個結論。讓下一個人看得到來源、重現步驟、驗證結果與尚未排除的風險，才有機會檢查這個結論。例如，測試通過的是哪個版本、哪組相依性與哪些情境？沒有覆蓋到的部分，是否也被說清楚？

可檢查不等於每個人都要從頭重做。對局部、容易回復的改動，既有檢查與清楚的變更說明可能足夠；涉及共用介面、跨 repo 相依性或難以回復的行為時，就需要針對影響範圍增加證據與審查。具體深度仍要依產品風險與既有要求決定。

當 review 失敗，團隊能回到哪個假設？當測試通過，還剩下什麼未知？這些答案讓人知道該在哪裡投入判斷，也讓後續接手的人有調查的起點。

下一次討論，可以先做這三件事

找出卡點、確認證據、由有權調整的人承接取捨，是我目前的管理原則，不是每個情境都要照表執行的固定流程。討論時，先帶一個具體變更及已有紀錄，把問題收斂到能決定的範圍。

1. 找出工作停在哪裡，為什麼停。
   列出最後完成的步驟、下一位接手者與缺少的條件。分開看資源不足、資訊缺口與尚未做出的決定，避免只把它們合稱為進度落後。
2. 說清楚往下走需要什麼證據。
   把已驗證、仍未知與要補的檢查分開，確認由誰提供、誰判斷是否足夠。依影響範圍安排審查，讓依據能被接手的人檢查。
3. 由有權調整的人承接取捨。
   如果要縮小範圍、延後工作或調整資源，說清楚誰能決定、犧牲什麼、誰接住後續結果，以及什麼新證據會讓團隊重新比較選項。

討論的結果不一定是加人，也可能是暫停新的工作，把已開始的變更完成；或先補關鍵驗證，再接受其餘工作延後。每個選擇都有代價，Manager 要接住的是這個代價與共同進度。

我想繼續追的問題

AI 改變實作成本之後，我更想知道省下的能力去了哪裡：變成更多已交付的工作，還是更多等待被承接的變更？

下一次看到團隊產生了更多程式碼，我會繼續往下問：最重要的工作是否更接近交付？驗證的依據能不能被檢查？這一次處理問題之後，團隊留下了什麼能力？

內容修訂：2026.10.09 — 確認團隊承接與人的判斷兩項核心主張，釐清三個動作為目前管理原則；保留假設與成果界線。