Day 25 那個 Knowledge Agent 順利上線後，你終於鬆了一口氣——Brent 的獨門知識不再被牢牢鎖在一個人腦袋裡了。但今天週一早上的跨團隊站會（Standup），卻讓你發現了一個更加嚴峻的大問題。

還記得 Day 3 嗎？那時你剛接下這爛攤子，發現團隊絕大部分時間都被各種不透明的「隱形工作」吃掉——那時你用人工方式費盡心力把所有工作攤到實體牆面上，才看清了系統的真相。

現在，隨著組織擴張到 50 人、三個團隊，那個「不可見」的問題以 10 倍的混亂規模捲土重來。

場景：可視化本身變成不可能的任務

「Platform 團隊這邊進度如何？」你在跨團隊站會上問。

「進度正常，」Platform Lead 說，「我們正在做 IDP 的自助服務門戶（Self-service Portal）。」

你隨即點開 Jira。那張 Epic 史詩任務上週標註著「80% 完成」，這週依然卡在 80%。你進一步查看子任務（Sub-task）——一共 15 張票，其中 12 張都在 In Progress 狀態，而最老的一張已經處於 In Progress 長達 3 週。

「Data 團隊呢？」

「我們正在全力支援 AI 產品的 RAG 資料管線（RAG Pipeline），」Data Lead 說。「但……呃，測試環境的向量資料庫（Vector DB）昨天下午又無故掛了，我們今天得花時間修復。」

你轉而點開 GitLab。上週 Data 團隊一共提交了 63 個 Commit，但仔細一看，只有 18 個與 RAG 相關。剩下的呢？有人在修改遺留（Legacy）的 ETL 腳本、有人在忙著幫 BI 團隊拉報表數據、有人在緊急修復 Production 的 Data Pipeline。

「AI 團隊呢？」

「我們在調優模型的 Prompt，」AI Lead 說。「不過產品經理昨晚又臨時改了需求，我們得重做很大一部分的實驗。」

你再點開 Slack。昨天 AI 團隊的 Channel 裡彈出了三條「十萬火急的緊急需求」：一個是銷售團隊要的客戶 Demo 演示、一個是行銷要的 Case Study 技術數據，還有一個是 CEO 週末要展示的原型。

你突然冷汗直流：當組織擴大到 50 人的規模時，Day 3 那個靠人工一點點把工作攤開的方法已經徹底失效了。

• Jira 看板永遠對不準，因為根本沒有工程師有時間去手動更新 Ticket。
• 站會上大家口頭彙報的，與背地裡實際在忙的完全是兩碼事。
• 真正吃掉產能的「隱形工作」，全散落在 Slack、Email、臨時會議與高層的口頭交代中。
• 沒有任何一個人類——包括技術總監你——有能力手動維護一個「即時且準確的工作全貌」。

當組織規模大到沒有人能看得見全貌，你根本連系統「現在最大的瓶頸在哪」都無法判斷。

兩難：依靠人工填寫更新？還是交給系統自動攤開？

會後，你盯著三個團隊名存實亡的 Jira 看板，腦中浮現兩條路：

先別往下捲。

如果是你，現在就要做出決定。你敢不敢把管理上的「工作全貌可視化」交給 AI？

翻牌：為什麼人工維護注定失敗

正確答案是 選項 B。

這聽起來很激進，對吧？把整個組織的工作進度可視化交給一個 AI Agent？

但仔細想想：Day 3 你學到的那個黃金教訓——「工作不可見就無法管理」——在 50 人的組織規模下，已經不是「嚴格要求大家填寫 Ticket」能解決的問題了。

原因其實很簡單：

• 認知負荷過載：當一個工程師同時在處理三件事（Jira 上的指派 + Slack 臨時請求 + 生產環境救火），他根本不可能有餘力即時去更新每張 Ticket 的進度。
• 資訊碎片化：真實工作散落在 Jira、GitLab、Slack、Email 以及會議記錄中，缺乏一個單一且一致的視圖。
• 報告延遲：人工更新的進度表永遠比真實代碼提交落後至少三到五天。

這導致你身為管理者所看到的全貌，永遠是「三週前的報告狀況」，而不是「現在的真相」。

《鳳凰專案》裡，Bill Palmer 花了幾個星期的時間才好不容易把 IT 部門的所有工作攤開，看清楚「隱形工作」到底吃掉了團隊多少產能。但那是十人左右的規模，而且是「一次性攤開」。

而在 2026 年，你面對的是快速變化的 AI 時代，你需要的不是「一次性攤開」，而是「持續性自動化攤開」。

這就是 AI PM Agent 的價值：它不是來搶專案經理的工作，而是做那件「人類做不到」的事——從十幾個異質系統中持續進行數據彙整、智能分類並動態更新工作全貌，讓你隨時擁有上帝視角。

AI PM Agent：能做什麼、不能做什麼

讓我們把話說清楚：AI PM Agent 的定位是助理，而不是決策者。

它所做的是這些「人類認知負荷過高」的資料彙整工作：

graph TD
    A[Jira tickets] --> E[AI PM Agent]
    B[Git commits & PRs] --> E
    C[Slack 訊息] --> E
    D[Calendar 會議] --> E
    E --> F[自動分類:<br/>業務專案/內部專案/變更/計畫外工作]
    F --> G[即時工作全貌儀表板]
    G --> H[預警系統]
    H --> I1[預警:某個 PR blocked 五天]
    H --> I2[過載:某人同時 owner 八張票]
    H --> I3[被遺忘:ticket 三週無更新]

AI Agent 能做的事

1. 持續資料彙整

• 每小時自動掃描 Jira、GitLab、Slack、Calendar 等協作工具。
• 把「隱形工作」（如 Slack 裡的「幫個忙修個 Bug」、臨時緊急會議決議、Git 提交日誌裡的 Hotfix）自動捕捉出來。
• 產生一個「實際在做的工作清單」，而非「Jira 上假裝存在的進度」。

2. 智能歸類

• 根據語意自動將工作歸入：業務專案（Business Projects）、內部 IT 專案（Internal Projects）、變更（Changes）與計畫外工作（Unplanned Work）。
• 自動標記工作的真實狀態：進行中 / 受阻（Blocked） / 已完成 / 被遺忘。

3. 主動預警

• 「Platform 團隊本週的計畫外工作占比高達 62%，已遠超 30% 的健康閾值。」
• 「這張 PR 已經被 Blocked 超過 5 天，依賴的 API 變更尚未發布。」
• 「Sarah 同時被指派為 8 張 Ticket 的 Owner，存在嚴重的過載風險。」
• 「這三張 Ticket 已長達 3 週無任何更新紀錄，可能已被遺忘。」

AI Agent 不能做的事

同樣重要的是，AI PM Agent 絕對不做「管理決策」：

• 它不決定優先順序：它只攤開事實，優先級仍由你與團隊共同決定。
• 它不替你拒絕需求（Push back）：它只忠實告訴你「本週團隊又被迫接了 5 個臨時請求」，是否敢說「不」是你的責任。
• 它不替你調配或解僱人力：它只指出「Sarah 疑似過載」，如何協調是管理者的決策。

AI 的核心定位是：把事實攤在陽光下。而進行決策，永遠是人類的工作。

這個邊界至關重要，因為它決定了團隊是否願意信任這個 AI。如果 Agent 開始代替你做管理決策（例如自動調降某張票的優先級），人就會產生防衛心。但如果它只是「把看不見的暗湧變成看得見的圖表」，團隊就會由衷覺得它是在提供幫助。

現場推演：第一次看見「即時且準確」的工作全貌

我們來看一個業界真實的組織轉型場景（綜合改編，數據為示意）：

想像一個包含三個不同職能團隊、共 42 人的 AI 產品研發組織。Jira 看板上永遠塞著 180 張 Ticket，但 PM 和技術總監始終無法掌握「真實進度」到底到哪了——每次詢問，得到的都是「快好了」、「差不多了」。

技術總監決定指派兩位工程師，花費三週時間打造了一個輕量級的 AI PM Agent。

它每小時自動掃描協作系統，用 LLM 識別出隱形工作（例如：Slack 對話中的「我正在幫忙改 Bug」、Git Commit Message 裡的 urgent fix for prod 等），並將所有工作歸納分類。

一個月後，這個 Agent 產生的第一份「工作健康報告」讓整個管理層瞠目結舌：

• Jira 看板上標記為「進行中」的 180 張 Ticket 中，有整整 41 張已經超過兩週沒有任何代碼提交或討論，實際上處於被遺忘的停滯狀態。
• 三個團隊的「計畫外工作（臨時救火）」占比分別高達 38%、52% 與 61%——這意味著大半的人力根本沒有在做 Roadmap 上的事。
• 有 7 張 PR 被 Blocked 超過 5 天，原因是跨團隊依賴未齊，但沒有任何人進行跟進。
• 三位核心資深工程師同時是超過 10 張 Ticket 的 Owner，而 Jira 上看起來他們只分攤了 3 張。

技術總監拿著這份報告，立刻召開了全體 Lead 的緊急會議：

「我們的研發進度不是慢，而是我們在矇眼狂奔，根本不知道自己在忙些什麼。」

接下來的兩週內，他們迅速採取了三項行動：

1. 清理 Backlog：將那 41 張被遺忘的 Ticket 關閉或重新排定優先順序。
2. 過濾臨時請求：針對計畫外工作占比高達 61% 的團隊，強行建立過濾機制，所有臨時請求必須先過 PM，拒絕「順手幫個忙」。
3. 消除 Block：將被 Block 的 PR 獨立出來建立「依賴看板」，在每日站會上最優先處理。

三個月後，他們重新比對數據，迎來了驚人的改進：

🏢 AI PM Agent 導入三個月效益指標：

• 🚨 計畫外工作（Unplanned Work）占比：由平均 50% 大幅下降至 28% ── 得益於建立了有效的臨時請求過濾機制。
• ⏱️ PR 平均受阻時間（Blocked Time）：由平均 5.2 天縮短至 1.8 天 ── 跨團隊依賴能被即時追蹤與消滅。
• 📉 Jira 看板滯留「被遺忘」Ticket 數：由原本的 41 張驟降至 6 張 ── 看板真實反映當下核心進度。

這一切並不是因為工程師變得更加自律填單，而是因為系統自動讓真相變得無法逃避。

今日金句

「當組織規模大到沒有人能看得清全貌時，將工作攤在陽光下的任務，就必須交給那個永遠不會累的 AI。」

留給你的問題

你目前每天在盯的那個專案進度看板，反映的真的是當下的真實狀況，還是只是幾週前的落後數據報告？

如果你不確定，那你可能就找到為什麼你們每次都「以為下週快上線了，結果又遲更兩個月」的根本原因了。

明天，我們要面對一個更加大膽的靈魂拷問：當開發量爆增、主管代碼審查變成效率瓶頸與流於形式的橡皮圖章時，你敢不敢讓 AI 成為你的變更審查員？

Day 27 見。