這半年，我們接觸了大概十多個開發團隊。
大家用的工具不完全一樣。有些團隊用 Cursor，有些開始把 Claude Code 放進日常流程，也有人在嘗試各種 agent framework、MCP 或自動化工作流。
整體來說，幾乎沒有人懷疑 AI coding 有沒有幫助。
很多 RD 的確已經用得很好。一個人可以很快把原型做出來、把重複工作處理掉，也可以在不熟悉的技術領域裡更快找到方向。
但走進團隊實際合作後，我們反而一直看到幾個很相似的問題。
而且通常不是只發生其中一個，是三個一起出現。
第一個現象：個人變快了，但團隊不知道怎麼一起變快
有些 RD 很會用 AI。
他知道怎麼拆 task、怎麼下 prompt、怎麼讓 AI 幫忙查 codebase、補測試、重構，甚至可以自己串出一套相當完整的工作流。
但這種能力一旦從個人擴大到團隊，事情就開始不一樣。
有人用 AI 很快做出一個功能，但其他人不知道它改了哪些假設；有人試了新的 framework，下一個人接手時卻很難理解；PR 的產出量變大了，可是 review 的品質和時間沒有一起跟上。
最後看起來就是：每個人都更有效率，但整個團隊反而到處在起火。
這不一定是 AI 的問題。
很多時候，是 AI 把原本就存在、但還沒那麼痛的協作問題放大了。
需求原本沒有講清楚，現在 AI 可以更快地把模糊需求實作成一大段 code。架構原本沒有共識，現在每個人都可以更快地走出不同方向。測試與 review 原本就比較依賴少數人，現在產出速度一拉高，那些瓶頸也會更明顯。
AI 讓寫程式變快了。
但「我們要做什麼」、「怎樣才算完成」、「誰來承擔這個決策」，這些事情不會自動變清楚。
第二個現象：大家都說效率提升了，但估時沒有變短
這件事一開始很讓人困惑。
RD 都說自己有用 AI，寫 code 的速度也確實快很多；但進到排程、估時、交付日期時，數字卻沒有明顯改善。有些團隊甚至覺得，事情好像比以前更難估。
其實這件事很合理。
一個開發任務，從來不只有把 code 寫出來。
還有需求理解、系統脈絡、例外情境、資料處理、整合、測試、上線、維運，以及那些一開始沒有被看見的問題。
AI 可以很快給你一個看起來可用的版本，但它不會替你判斷這段邏輯是否符合真正的商業規則；也不會知道某個看似合理的改法，會不會影響到三年前留下來、但現在仍在運作的流程。
所以很多團隊不是沒有提升效率，而是效率提升發生在「產出 code」這一段；但後面的確認、整合、修正與承擔風險，沒有因此一起變少。
甚至因為能更快做出更多東西，後面需要確認的東西反而更多。
如果團隊還是用以前的工作切法、以前的驗收方式、以前的責任分工去承接 AI 的速度，那最後感受到的，很可能不是交付加速，而是混亂加速。
第三個現象：以前有錯是組內互推，現在大家比較有共識了
以前系統出了問題，常見的情況是組內互相確認：
是需求沒講清楚？
是 RD 寫錯？
是 QA 沒測到？
還是 PM 沒有把情境補完整？
現在這件事有時候變得簡單一點。
大家比較有共識：是 AI 的鍋。
當然，這句話有時候是玩笑。但它背後其實有一個值得注意的問題。
AI 可以幫忙產生 code、提出做法、補文件，甚至幫忙分析錯誤；但它不是團隊成員。它不理解客戶真正的處境，不知道你們系統背後的歷史，也不會替一次 production incident 承擔責任。
有很多因為AI而知名的社群領袖人物，也曾宣稱，他們被客戶問到現在有AI幫忙開發以後，能不能降一降報價？他們的理由也比較一致，AI不會幫忙背鍋，雖然有點威脅的意味，但其實後面通常也代表著AI沒讓他們有降價空間，甚至成本還比較高。
這件事的本質，還是交付一定品質的服務內容時，我們的成本有多高，以及現在團隊成員還有沒有辦法付出足夠的精力去輸出這樣的時間成本。
身為管理者，真正該問的，通常不是「這是不是 AI 的錯」。
而是：為什麼一段沒有被理解、驗證或挑戰過的內容，可以一路進到系統裡？
如果把焦點從工具拉遠一點
真正需要處理的，其實是團隊協作。
工具一直會變，模型也會一直進步。今天大家在比較哪一個 agent 比較強，明天可能又有新的工作方式出現。
但團隊真正需要處理的問題比較基本：
- 哪些事情可以讓 AI 大量協助，哪些事情仍然需要人做明確判斷？
- 當產出速度變快時，需求、設計、review 與測試要怎麼一起調整？
- 團隊是否真的對架構、品質與完成條件有共識？
- 出問題時，我們有沒有能力回頭知道是哪一個決策造成的？
為什麼我們做 Teams
這也是為什麼，我們去年開發自己的 Agent framework 時，特別把它命名為 Teams。
它一開始不是被設計成讓 AI 自己一路往下跑的工具，而是人與 AI 共同決策的節點。當任務跨過需求、設計、開發、測試與上線，每一個環節都可能帶著不同的假設、限制與責任。AI 可以很快完成很多事，但它不會自動知道哪些判斷可以交出去，哪些地方仍然需要人進來確認。
所以 Teams 裡面保留了許多關鍵的審批與盤點環節，要求相應的責任人真正進到流程裡。這些環節表面上看起來像是多了一些確認，實際上是在讓團隊把原本散落在個人經驗、口頭共識或事後補救裡的判斷，慢慢放到可以被看見、討論與承擔的位置。
經過半年的優化與調整，現在 Teams 裡已經有超過 60% 的決策，可以完全交由 AI 處理。
但這不是因為我們一開始就知道哪些事情能自動化，而是在實際運作中，一點一點把條件、例外、驗證方式與責任邊界看清楚之後，才敢把它交出去。
很多時候不是做不到，而是一開始看得還不夠清楚。太早相信一個看起來順暢的流程，太快把事情往外推，最後不一定是效率提升；有時候，只是把原本還沒理解的風險，也一起交了出去。
Teams 不是一次把責任交給 AI；而是在可驗證的條件逐漸清楚後，讓決策一步一步轉移。
Teams 想做的，是一種過渡設計：先讓人和 AI 在關鍵節點一起決策；當團隊對事實、規則與例外有足夠理解後，再一步一步把責任轉移到已經被定義、被驗證，也能被追溯的 AI 決策上。
這樣 AI 的自主性不是建立在一時順利的結果上，而是建立在團隊真的知道：它為什麼可以被信任、在哪些條件下可以被信任，以及出了問題時，能回頭找到哪一個環節需要修正。
問題從來不只是運氣
有些團隊會說，現在先讓 AI 跑，做得出來就繼續；有問題再修。
短期來看，這種方式有時候確實能成功。剛好碰到熟悉的問題、剛好需求沒有太多例外、剛好負責的人看得出哪裡不對，事情就過了。
但這很容易讓人對一時的結果產生太多信任。
我們看到的，可能只是某一次剛好成功的抽樣，而不是一套真正可複製的能力。運氣好，功能順利上線；運氣不好，問題卡在需求、架構、測試或責任邊界之間，最後每個人都知道哪裡怪怪的，卻沒有人能明確說出該由誰處理。
但這真的是運氣問題嗎？
很多時候不是。
它只是團隊還沒有把那些本來就需要被確認的事情，放進一個足夠清楚的流程裡。當責任、審批與驗證都只靠少數人的經驗撐住時，AI 只是讓這個風險更早被放大。
真正穩定的 AI 協作，不是期待每一次都剛好成功，而是讓團隊知道：在什麼地方該停下來、該由誰判斷，以及判斷之後，責任要往哪裡走。
結語
個人會用 AI，當然很重要。
但如果一個團隊想真正因為 AI 而變得更穩、更快，它需要建立的不是更多 prompt，也不只是更多 framework。
它需要重新把協作、責任與判斷放回正確的位置。
不然 AI 只會讓大家更快地做出更多東西。
也更快地起火。