每個人都有 AI，為什麼團隊還是這麼慢？

TL;DR：快的不只是寫程式，而是整段交付

Coding Agent 可以在人喝杯咖啡的時間完成工作，產品卻未必更快上線。MeetAndy AI 共同創辦人薛良斌（hlb／布丁）指出，團隊的速度常卡在人與人之間：等待決策、補充背景、反覆審查，以及交接時流失的取捨理由。真正的加速，不只是每人多一個 AI，而是讓人與 Agent 沿著同一份脈絡往前工作。

• 交付瓶頸往往藏在等待與重工；個人產出加速，不等於從需求確認到上線的時間等比例縮短。
• 共享脈絡要留下目標、決策理由、限制與驗收方式，而不只是堆放文件。
• 人負責價值排序、工程判斷與風險承擔，Agent 負責整理、規劃與執行；主動性提高，護欄不能放鬆。
• 績效應同時看整體交付時間、等待原因與上線品質，而不是只數文件、程式碼或 PR。

光速打字機，撞上交接的灰色地帶

以前得埋頭一整天的工作，現在交給 Coding Agent，去喝杯咖啡回來就完成了。但當每個人的螢幕前都發生這種加速，產品從需求確認到上線，也跟著變快了嗎？MeetAndy AI 共同創辦人布丁以這個問題開場，把目光從個人的工作桌，拉向整條團隊交付線。

「為什麼團隊都用AI的每個人變快，但是交付速度可能並沒有變快」
— 布丁

現場的舉手提問分成兩輪：先問大家，與一年前相比，自己做事是否快了一倍；再問團隊從需求確定到上線，是否也快了一倍。布丁說，自己使用 AI 時，甚至感覺做事快了十倍，但這份個人體感不能直接換算成團隊成果。研究、PM、設計師、工程師、QA 都能用 AI 加速，角色之間的交接卻不是把各自省下的時間相加，就會自然順暢。

把一個功能從研究到上線畫成長線，就能看見兩種時間：藍色區段是大家真正動手做事的時刻；灰色區段則是工作停在半路，等待決策、討論、補充脈絡、review，或在會議與修改之間來回。AI 能讓藍色區段縮短，卻不代表灰色區段也會一起消失。

• 動手工作的時間：PM 撰寫 PRD、製作 Prototype，設計師產出設計稿，工程師寫程式，QA 產生測試案例，以及進行 code review。
• 交接與協調的時間：等別人做決定、補齊背景、確認取捨、等待 review，再依討論結果修改。這些時間同樣占據了從需求到上線的路程。

布丁用「大概快 30%」描述整段流程的加速幅度，並說明這是他平常做調查時收到的概略結果，不是所有團隊都適用的定律。這個數字所指向的落差是：個人工作可能明顯加快，但只要交接中的等待沒有縮短，整體交付就不會等比例加速。

瓶頸往往藏在交出去的文件背後。PM 可能已經和自己的 AI 討論半個鐘頭，排除幾個方案、做過幾次取捨；工程師收到 PRD，卻不知道這些決定怎麼來，工程師的 AI 當然也不知道。設計師做過數個版本，哪些沒被採用、為什麼沒被採用，也未必跟著設計稿一起傳出去。下一位同事接到的是結果，卻得重新追問理由。

於是，大家開會問「當時為什麼這樣做」，會後各自回去修改，再與自己的 AI 繼續埋頭工作。為了補上斷掉的脈絡，只好問更多人、開更多會、寫更多文件，或在通訊軟體裡補上更長的說明。交接看似完成了，理解卻又從頭開始。

「大家好像都獲得光速打字機」
— 布丁

這台光速打字機讓「再生一個版本」變得輕而易舉，卻也可能讓「再開一次會」變得更加頻繁。布丁接著借用訪談中的 AI手榴彈比喻：有人生成一大包 AI Slop 丟給同事，對方只能再用 AI 讀完，然後生成一份回覆丟回去。文件與版本飛快增加，閱讀、回覆與協調的負擔也跟著堆高。真正卡住交付的，不一定是產出不夠多，而是那些讓下一個人能繼續工作的資訊，在交接時遺失了。

第三大腦：讓工作延續，而不是只交文件

同樣把 AI 請進團隊，有人明顯加速，有人卻變慢。布丁引用一份 McKinsey 調查：受訪者是三百多位產品與工程主管，其中約 25% 的總監級以上主管回報團隊顯著加速，卻也有 30% 回報生產力下降。這是演講中轉述的調查結果，不能直接拿來推論 AI 導入必然帶來什麼成效；但兩種截然不同的回報，讓問題從「有沒有工具」轉向「工作究竟怎麼運作」。

在他轉述的後續提問中，高加速團隊可以從一串因素裡勾選兩項，回答哪些事情最重要。排第一的是重新設計整個工作流程，第二是實驗文化，第三才是導入工具。這個排序不是因果證明，卻點出了買工具之外的組織功課：願不願意調整合作方式，並透過更多實驗摸索新的工作節奏。

布丁對工作流程重設的理解，不是把原本的文件交得更快，而是讓同一份工作持續往前走。PRD、設計稿、程式碼與 review 意見仍然重要，但如果交出去的只有產物，接手者仍可能不知道它為何長成這個樣子。真正需要一起往下傳的，是產物背後的判斷。

「我們從這交付產物這件事情呢，變成是說我們在延續工作，讓整個脈絡可以往前進。」
— 布丁

• 目標與原因：這份工作要達成什麼，為什麼選擇這樣做。
• 技術限制：有哪些條件必須遵守，哪些方向受到限制。
• 驗收條件：做到什麼程度，才算符合需求。
• 驗證方式：如何測試、如何確認結果，以及如何判定已經完成。

當這些資訊能跟著工作留下來，新同事或新的 Agent 加入時，就不必把已經討論過的問題再問一遍。否則，即使團隊早已做過取捨，AI 看不見那些脈絡，仍得回頭向人追問；原本應該接續的工作，又停在補背景的門口。

布丁把這層共用脈絡稱為「第三大腦」。第二大腦幫助個人思考，每個人可以有自己的 AI、自己的知識整理方式；但個人的腦袋再強，沒有連在一起，團隊仍然缺少共同記憶。第三大腦要承接的，是大家共同知道哪些資訊、已經做了哪些決策、為什麼這樣決定，以及接下來應該發生什麼事。

這種記憶最有價值的時刻，往往不是決策當天，而是三個月後：當初為什麼選 A、不選 B？為什麼定下 42，而不是另一個數字？如果只留下結論，團隊就得重新拼湊現場。從這個角度看，看板也可以成為第三大腦的載體；重點不在於有沒有一塊看板，而在於它是否能承接決策理由與工作脈絡，讓人與 AI 都知道如何繼續往前走。

一個 ZIP 需求，如何在同一串討論中走到上線

「我們可不可以支援ZIP檔格式啊？」一個附件上傳的提問，看起來只是多支援一種格式。布丁向團隊的 Agent 提出需求後，Agent 先寫出實作規劃：如何支援 ZIP、如何解壓縮，以及預估的複雜度。但有了規劃，不代表就該立刻開工；真正決定方案的討論，才剛開始。

CTO 加入同一串討論，要求先做資安評估。Agent 隨即列出潛在風險，包括惡意攻擊與解壓縮炸彈：看似小小的壓縮檔，解開後可能把整個資料夾塞滿。原先標示為 Medium 的複雜度，也因此升成紅色的 High。需求沒有變，對需求的理解卻已經不同。

接著，人提出新的取捨方向：能不能兼顧安全，又讓實作更容易？這不是單純要求 Agent「再快一點」，而是把設計問題攤開來看：哪些不安全的情況需要處理，又有哪些現成能力可以沿用？Andy 查閱既有程式與工具，朝不新增相依、處理例外的方向調整方案，讓複雜度降了下來。

「我們做的是工程判斷」
— 布丁

布丁與 CTO 在這段過程中都沒有親自下去寫程式。他們看規劃、辨識風險，決定想要什麼、不想要什麼；Agent 則查閱程式、整理方案，承接後續執行。人機分工的界線，不是誰負責打字，而是誰做取捨、誰把決定落實。

• 先提出可討論的規劃，而不是收到需求就直接實作。
• 在同一串討論中補上資安要求，讓風險影響方案與複雜度判斷。
• 由人確定安全與實作難度的取捨，Agent 查閱既有程式與工具、調整做法。
• 方向確定後，由 Agent 完成修改、開 PR，再由人與 Agent 一起 code review，最後走到上線。

對照傳統流程，差別更鮮明：PM 先規劃，再找工程師討論，接著補做風險評估；如果問題發現得晚，就可能已經開始做，卻又得重做。工程師正進入心流時，突然收到一句「你現在有五分鐘嗎」，短短一場討論，也可能打斷半天的工作節奏。每往前一站，都有一次交接，也有一次重新補背景的機會。

在這個 ZIP 案例裡，布丁與 CTO 不必另開一場會，重新說明需求背景或轉述彼此的判斷。所有討論都留在同一串內容中，人與 Agent 都能閱讀：為什麼要做、擔心什麼、方案為何改變，都跟著工作一起往前走。人的注意力因此可以放在「這件事該怎麼做」，決定後再交給 Agent 執行與整理，而不是反覆搬運已經說過的話。

「這個溝通的判斷就不用再被轉述，因為它都在同一個脈絡裡面。」
— 布丁

從訪談到功能：AI 整理線索，人決定值得做什麼

一場接一場的使用者訪談，存進 NOTION 後，真正費工的事情才開始：逐份讀完、找出反覆出現的問題，再把零散的聲音整理成可討論的線索。布丁把這道整理工作交給 Agent，請它將最近幾場訪談匿名化、彙整成 insight。人不必先讀遍所有文件，才能開始比較哪些問題值得追下去。

但列出十條 insight，不代表十條都該變成功能。這次讓布丁停下來的，是「決策記憶失傳」：受訪者不知道當初為什麼做出某個決定，也找不到決策文件放在哪裡；有人甚至認為，就算寫下來，也沒有人會看。問題不只是少了一份文件，而是做過的判斷沒有被後來的工作接住。

「我們都不知道我們當初那件事情為什麼做決定」
— 布丁轉述受訪者

挑出這條值得追進的 insight 後，布丁再請 AI 對照現有產品功能與程式碼：目前是否已經滿足這個需求？缺口在哪裡？可以有哪些候選功能？Agent 把線索往實作方向推進，人的工作則是比較選項，而不是照單全收。

• 使用者價值：每個候選功能能替使用者解決什麼問題？
• 工作量：完成這個功能需要多少工作？其中有多少需要人親自投入？
• 人工介入：哪些環節仍需要人參與、確認或補充判斷？

布丁在評估時特別關注人的工作量與介入需求。這是一種安排有限人力的視角，不能解讀成 AI 執行沒有實際成本。AI 的作用是把候選功能與比較依據整理清楚，讓人決定先做哪個、哪些暫時不做；列得再完整，優先順序仍要有人拍板。

選定功能後，Agent 才進一步提出規劃。這份 plan 被刻意保持簡單，並不是因為工程改動可以含糊帶過，而是它首先要讓不同角色的人看懂、討論同一件事。背景、取捨與驗證方式若藏在各自的腦中，再詳細的實作清單也難以承接判斷。

• 背景與問題：為什麼要做這件事？現在遇到什麼問題？
• 討論內容：已經討論過哪些事情，讓參與者理解方案形成的脈絡。
• 改動範圍：程式需要變更哪些地方、涉及哪些關鍵函式，讓人與工程師看懂工作範疇。
• 驗證方式：如何確認改動有效，需要增加哪些驗證相關函式與 test case。

整條工作線於是連了起來：訪談由 AI 彙整成 insight，人挑選值得做的問題；AI 提出規劃，人補上偏好的做法與外部限制；接著由 AI 實作，人與 AI 一起 code review，再走到上線。人不需要包辦每一步，卻必須在選擇方向與補充限制的時刻進場，避免「能做」直接滑成「值得做」。

這個流程還有一個重要細節：候選選項與討論都留在對話裡，Agent 可以記錄下來。當新的使用者回饋出現，先前累積的知識也能留下，成為下一輪工作的脈絡。訪談不再只是一次性的整理成果，而能持續把回饋帶進後續的功能判斷與實作。

Agent 先備料，人守住判斷與護欄

讓 Agent 成為工作夥伴，不只是把指令交出去，再等一份成果回來。布丁整理出四項基礎：人與 Agent 要知道彼此為何而做、能在行動前檢視計畫，也要把每次工作的經驗留下來，讓合作不必一再從零開始。

• 共享脈絡：需求與決策在交接時一路傳下去，讓人與 Agent 都能承接工作的背景。
• 依目標規劃：在指定範疇內提出可審查的計畫，讓人有機會確認方向，而不只是接收結果。
• 自主行動：讓 Agent 能實際推進工作，而不只停留在建議。
• 累積知識與經驗：記下工作中學到的事、公司的 SOP 與內部用語，成為下一次合作可用的脈絡。

「每一次留下來，脈絡就是下次的起點。」
— 布丁

公開的協作空間，讓這種累積有了具體載體。布丁轉述 Shopify 的 Rivered Engine 案例：這個 Agent 住在公司的 Slack，只能在公開頻道被 tag，可以讀程式碼、跑測試、開 PR，也能查數據。依他轉述的文章，30 天內有 7000 人使用過，每八個 PR 約有一個由 River 開出，但仍經過人的審核。

有趣的不只是 Agent 做了多少事，而是同事看得見彼此怎麼使用它。提問、討論與互動不再藏在個人的對話視窗裡，每個人都有機會從別人的做法學習，這些交流也能累積成團隊的知識脈絡。布丁轉述 Shopify CEO 的觀點：AI 不會取代學徒，也不會取代師父，而是讓所有人都有機會更快學習。

布丁也提到其他業界數字：Stripe 每週有一千個 PR，其中 30% 由 agent 完成；Shopify 則提及運用 agent 做 migration，節省 60 到 90% 的時間。這些是演講中轉述的案例數據，呈現企業正在探索的方向，而不是每個團隊導入後都能得到的保證。

更往前一步，Agent 能不能在人開口之前，先找出值得注意的問題？布丁分享 MeetAndy AI 正在嘗試、但還未確定如何產品化的做法：讓 Agent 讀系統日誌，主動整理問題。服務看起來正常，不代表執行過程一路順暢；日誌可能堆滿 warning，Agent 也可能到處撞牆、繞路，甚至嘗試逃脫 sandbox，失敗後才回傳正確結果。只看最後的答案，這些成本與潛在風險就容易被忽略。

但找出異常，不等於每一項都該立刻修。Agent 可以先列出問題，至於風險是否嚴重、修正是否必要，仍由人判斷。即使每天跳出大量 warning，團隊也可能認為沒有修正的必要；主動巡查的價值，是讓人更容易看見問題，而不是用告警數量替人做決定。

這就像 Overcooked：有人先把材料備好、送到手邊，掌廚的人才能更快進入料理。人類的注意力有限，每天還要做決定、開會；若 Agent 先整理好問題，人就能更快進入規劃與推進，而不必把力氣全花在翻找線索。

布丁期待的下一步，是 Agent 能主動往前推進，真正碰到需要判斷的路障才找人：例如需要 PM 的 buy-in，或遇到資安風險，必須由人 approve。這仍是對未來的期待，不是已經完成的運作模式；人的角色，是在關鍵時刻判斷取捨，協助排除路障。

Agent 越主動，責任的界線就越不能模糊。布丁明確指出，責任與風險仍在人身上：Agent 可以研究、起草、執行，但 MeetAndy AI 的 PR 必須由人 merge，不會交給 Agent 自行完成。

要讓速度真正跑起來，還得把護欄架好。Plan 如何制定、採用哪些 SDD 方法，包括 Spec Kit、SPMtron，以及 CI、lint 如何運作，都是規劃與驗證機制的一部分。這些護欄不是免除審查的理由，而是讓人能在 Agent 加速行動時，仍然守住方向、品質與風險判斷的必要條件。

新的 KPI：衡量整條交付線，而非個人產量

每週開出更多 PR，產品就真的更好用了嗎？布丁提到，一場專訪下方的留言，直接戳中了這個落差：團隊報出 PR 數量，使用者卻說，自己似乎沒有感受到變化。產出的計數器不停跳動，不代表使用者感受到的價值也同步增加；這正是 KPI 必須重新思考的起點。

布丁轉述同一份 McKinsey 調查時指出，在交付速度約快兩倍的公司，工程師花在執行工作的時間減少了 4.5 個百分點，策略工作的時間則增加了 2.4 個百分點。另一組被他稱為 Plan 的角色，也呈現執行時間下降、策略時間上升的方向；他口述的變化分別為下降百分之二、上升百分之一，但沒有進一步釐清職稱。這些是演講轉述的調查結果，不宜直接推論為導入 AI 必然造成的效果。

當執行逐漸交給 Agent，人的時間往判斷移動，評量人的方式也得跟著改變。過去盯著工程師寫程式多快、設計師出稿多快、文件進度推得多快，量到的是各自工作站的產量；布丁期待的，卻是整條交付線更快把成果送到使用者手上。速度依然重要，只是衡量的單位不再停留在個人。

「我可以讓大家用AI都可以寫出更好程式」
— 布丁

這句話把工程師的貢獻從「我寫得多快」，拉向「我讓團隊能做到什麼」。當大家都能使用 AI，專業能力不只體現在親手完成多少產出，也體現在能否建立讓產出更可靠、更一致的工作機制。布丁提出的角色重心，各自保留了不能只靠生成速度取代的判斷。

• 工程師：建立 coding guideline、護欄與測試支援，思考 QA 的 test case 怎麼寫、後續如何追進，讓團隊都能用 AI 寫出更好的程式；同時仍負責架構與技術取捨。
• 設計師：透過 design token 等機制，讓 AI 產出一致的設計；要往什麼樣的產品體驗前進，仍需要設計師掌握方向。
• PM：把焦點放在驗收標準，以及交付的成果是否真正滿足客戶需求，而不只是文件推進了多少。

落到團隊層級，布丁提出的衡量方向，是沿著一個需求走完全程：從確認到上線，到底花了多久？途中又在哪裡停住？這不是只替交付時間按下碼表，而是要把等待也攤開來看，辨認速度究竟卡在哪個人與人之間的環節。

• 交付時間：從需求確認到上線的時間，是否真的縮短。
• 等待時間與原因：中間到底等待多久，以及為什麼需要等待。
• 上線品質：把速度與上線時的品質一起評估，不能只看產量或完成得有多快。

這些是布丁提出的 KPI 方向，而不是已經驗證的績效成果或固定目標值。它要求團隊把視線從忙碌的工作站移到交付路徑上：不只問誰做得更快，也問成果是否更快抵達使用者手中，以及抵達時的品質是否過關。

「每一次留下來，脈絡就是下次的起點。」
— 布丁

重點回顧：讓下一棒不必重新起跑

• 先找灰色時間：真正拖慢交付的，可能是等決策、補背景與反覆重做，而非產出本身。
• 把理由一起留下：共享脈絡的價值，是讓下一個人或 Agent 接得住工作，不必再追問為什麼選 A、不選 B。
• 分工不等於卸責：Agent 可以主動整理與執行，人仍須決定做什麼、接受哪些風險，並守住審查與 merge。
• 把績效拉回交付：看整體週期、等待原因與上線品質，也看個人是否建立了讓全隊更有效工作的機制。

布丁最後把畫面拉回團隊：各自衝得快，方向卻不一致，仍不會自然形成更快的交付。從 ZIP 需求到訪談洞察，這場分享最鮮明的轉變，是讓工作不再一站站重新交代，而是在共同脈絡中持續向前；每次判斷留下的理由，也替下一次合作少鋪一段路。

Coding Agent共享脈絡第二大腦第三大腦AI Slopinsightplancode reviewguardrailSDDCIdesign tokenKPI