Andy Jassy 談 AI 小團隊：六人七十六天的案例，該學的是哪些工作方式？
AI 小團隊如何改變工作？從 Andy Jassy 的新訪談、Bedrock 六人七十六天案例與 Amazon 工程角色更新，看跨職能、交付責任及成果衡量。
AI 小團隊的新聞很吸引人：幾個人搭配程式代理，就能完成過去需要更大團隊的專案。但人數變少之後，產品的判斷、驗證與交付由誰承接，同樣需要答案。
Andy Jassy 在 2026 年 10 月 23 日上架的 a16z 訪談中，談到 Amazon Bedrock 團隊以六名工程師、七十六天交付新推論引擎的案例。
這是 Amazon 自述的單一專案，不能直接換算成所有工作的生產力倍數。它更值得研究的地方，是小團隊如何取得跨職能能力，並縮短等待其他部門的時間。
Jassy 認為，AI 會讓團隊從較完整的起點開始工作，成員也需要跨出原本負責的一小塊。他同時預期，未來部分既有工作需要的人數會減少。
但把工作做得更快，與只追求產生更多程式碼，仍是不同目標。Amazon 隨後更新的工程角色指引，也把長期成果與人的判斷放在工具使用量之前。
對正在調整流程的團隊，可先檢查工作如何從需求走到交付，再決定哪些步驟適合交給 AI，以及誰負責確認結果。
六人七十六天，這個 AI 小團隊案例證明了什麼？
這個案例顯示 Amazon 能在特定條件下用小組重建引擎，無法單獨證明通用的效率倍數。因為專案難度、人員經驗與既有資源，都會影響交付速度。
完整訪談在 37 分鐘後談到這個專案。Jassy 說，團隊經驗讓公司內部重新思考，成功企業的工作是否一定要切成愈來愈小的專業片段。
Bedrock 是 AWS 提供模型與建置 AI 應用的服務。推論引擎則負責執行模型、產生回應，是使用者發出要求之後，服務能持續運作的重要部分。
依Amazon 四月的官方說明，團隊認為既有引擎需要不同架構，於是另外組成六名有經驗工程師的小組，運用 Kiro 交付名為 Mantle 的新引擎。
公司拿這項成果對照原本估計的約四十人、一年工作。兩者並非同時進行的控制實驗，因此不能直接算成一個普遍適用的生產力比例，也無法只把差距歸因於 AI。
案例裡容易被忽略的條件
六個人並非從零開始理解雲端服務。他們面對的是一個已有需求、客戶與運作經驗的系統，並且被安排成專注重建的小組，這些條件都與新手獨力建立整套服務不同。
所以，對一般團隊有用的問題，是哪些工作不再需要等待、哪些人能獨立處理較完整的任務，以及原系統提供了哪些可重用的知識。
Jassy 在同一段也舉出四至五人用一個週末做出消費代理原型的例子，形容它已接近可交付。這仍是他的內部觀察，原型成熟度與正式服務上線不能當成同一件事。
要理解可借鏡的部分，必須把人數背後的組織方式拆開。
跨職能團隊，如何減少等別人接手的時間？
小組能處理較完整的工作，才有機會減少需求在不同專業之間來回傳遞。成員數量少，只描述組織大小，並沒有自動說明工作為何變快。
Jassy 回憶，自己早期同時負責多項產品。公司成長後，產品經理可能只負責某個產品的一小部分，例如定價。他認為，AI 讓成員跨職能處理工作的可能性增加。
跨職能是指一個人或一個小組，能共同把需求、設計、開發與交付接起來。它不要求每位成員都成為所有領域的專家，但需要有人能辨認不同步驟彼此的影響。
例如，一個假設的內部報表專案，若需求人員先寫規格，再等設計、程式與資料團隊依序接手，小修改就可能多跑一輪。具備必要技能的小組，則能直接討論修改對整張報表的影響。
AI 可能協助產生查詢或介面草稿，使討論更早有實物可看。但如果小組仍無法確認欄位定義，或沒有權限取得資料，草稿變快也不代表完整交付時間會縮短。
AWS 對產品管理方法的說明也把小組的技能、完整責任與自主執行放在一起。管理者提供任務，小組需要對工作範圍內的產品與業務結果負責。
這個背景讓「小團隊」超過單純減少人頭。小組必須有足夠能力完成任務，也要理解使用者需要什麼，否則原本跨部門的等待，可能只是移到小組裡繼續發生。
但步驟變少後，原本由交接帶出的檢查也必須有人承接。
AI 做完初稿，人的責任落在哪裡？
AI 提高草稿完成度之後，團隊仍需確認需求、例外與實際交付品質。這些責任不會因為模型已經寫好大部分內容而消失。
Jassy 在訪談中預期，模型會讓多種職能更快到達較完整的起點。他也預測，同樣類型的工作未來可能需要較少人，並出現新的工作種類；這些是對組織變化的預期，並非所有企業已發生的共同結果。
對工作者而言，較完整的起點可以是一份程式、一份資料分析，或一個新介面。它讓人較早開始檢查，但檢查內容仍取決於要交付的產品。
延續報表專案，AI 產生的頁面也許能正常顯示總額，團隊卻仍要確認資料範圍、重複計算與更新方式。若使用者會拿數字安排工作，錯誤的定義就可能比畫面問題更重要。
能說明理由，才有辦法修正
Jassy 給年輕人的建議，把使用 AI 與批判思考放在一起。他認為工具能更快整理資料，但把線索組合成策略、產品或顧客體驗，仍需要人的判斷與實驗。
這個區分也適用於交付。團隊若只知道模型說可以，就很難在結果出錯時辨認原因；若能說明採用哪個資料、放棄哪個方案，後續修正才有依據。
因此，負責確認的人需要理解產出，而不只是替一個看似完整的成果按下同意。遇到暫時不能判斷的部分，也要能把問題帶回熟悉業務的人。
把工作交給代理後，保留這種理解能力，已有實務方法可參考。
延伸閱讀：AI 代理接手工作，如何保留批判性思考？Addy Osmani 的交辦與驗證方法
團隊衡量成效時，也需要能看見這些後續工作，才不會只把草稿完成時間當成整體交付速度。
為何不能把 AI 使用量當成唯一成績？
工具使用量能反映採用情況，但它與顧客得到的成果並不相同。若只追蹤模型產生多少內容，團隊就可能忽略後面增加的查核與重做。
Amazon 在 10 月 27 日公開的工程角色指引強調，工具與技術持續改變，長期成果仍是衡量重點。
文件也討論 token 用量、AI 工具採用率與程式碼產出等指標。Token 是模型處理文字的基本單位，用量能顯示使用情況，卻不直接表示工作價值。
Amazon 沒有把這些指標一律排除。文件允許謹慎觀察它們與成果的關係，同時提醒，若把用量本身變成目標，可能增加費用或複雜度。
這讓 Jassy 的小組案例有另一個閱讀角度：七十六天的意義是交付了一個引擎，而不是單純創造大量程式碼。若只複製用量指標，就可能把案例裡較重要的成果條件漏掉。
看起來忙碌，與解決問題不同
假設 AI 協助產生了更多報表版本，但每一版都要人工花更多時間對帳。這時內容產出增加，總交付速度卻未必改善，使用者也可能仍在等待可信的數字。
因此，一次流程實驗可以把等待、製作與修正時間一起記錄，再看交付後是否仍有重大錯誤。這些觀察用來理解流程，不需要先把結果套成個人的績效結論。
衡量標準拉回成果，才有辦法安排一場有用的流程實驗。
一般團隊如何試行，才不會只剩縮編口號？
先選一條可完整交付的工作，對照改善前後的總時間與重做原因，比先訂人數目標更有判斷依據。因為工作邊界清楚，才知道哪些改變確實有幫助。
以固定週期的內部報表為例，可以先記下原本如何取得資料、誰確認數字，以及最後交給誰。接著只讓 AI 介入其中適合的一段，保留原有的判定依據。
若最耗時的是部門對欄位沒有共識，先產生更多草稿通常無法解決。反過來，若規則已清楚，主要時間都花在重複整理，AI 才比較容易留下可辨認的改善。
試行後，也要看使用者是否真的拿到可用結果。需求不清楚、重做太多與等待權限，是不同問題，不能全部歸成成員沒有多用 AI。
Amazon 的工程指引也容許開發者說明工具何時沒有幫助。能辨認限制與有效情境，本身就是團隊需要累積的判斷能力，避免把嘗試工具變成只求表面採用。
從代理產生程式到交回可審查成果，中間如何安排工作，也有具體範例。
延伸閱讀：AWS 公開 Claude Code 遠端代理範例：AgentCore 如何交回 PR，費用與資料邊界怎麼看？
當團隊能清楚說明節省了什麼、保留了什麼責任，組織調整才有具體內容。
AI 小團隊常見問題
六人七十六天，代表其他公司也能照做嗎？
這是 Amazon 自述的特定專案，與有經驗人員、既有服務及工作安排有關。它提供研究方向，無法保證其他專案有相同結果。
Jassy 是否說專業能力不再重要？
他談到成員跨職能工作的可能，也強調人的判斷與批判思考。跨職能需要理解更多工作之間的關係，不能只靠模型產出取代專業判斷。
Amazon 是否禁止用 AI 使用量衡量採用？
官方工程指引允許謹慎使用這類指標，但提醒要接回長期成果，避免把用量本身當成目標。
小團隊能走多快，要看它能完整承接多少工作
Jassy 的案例值得帶回的是工作範圍與責任安排。AI 讓草稿更快出現，團隊仍要把它接成正確、可用的結果。
對準備試行的團隊，可以先用一條熟悉流程，找出交接、等待與重做的原因。免費訂閱 AI 郵報，持續閱讀 AI 如何改變實際工作與交付方式。
