AI WBS 排程健檢教學：找出隱藏依賴、關鍵路徑與資源衝突

原內容日期：2026-09-24。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

甘特圖排滿了，為什麼還是會延？用 AI 找出 WBS 的隱藏依賴與關鍵路徑

許多專案並不是沒有計畫。相反地，任務、負責人、開始日和完成日都填得很完整，甘特圖也畫得很漂亮。但真正開始執行後，日期仍然一再往後滑。

原因往往不是某個人少做了一天，而是排程漏掉了等待、核准、共同資源與隱藏依賴。

例如，「開發登入功能需要兩天」這句話可能沒有錯；但如果開始前要等權限模型核准五天，完成後還要等測試帳號三天，那麼兩天只是工作時間，不是日曆上的完成時間。

AI 很適合協助整理這類排程問題。它可以從任務表、會議紀錄和依賴清單中找出缺口、矛盾與可能的路徑。不過，AI 不知道團隊真正的工作速度，也無法替供應商承諾交期。因此正確用法不是叫它「算出一個日期」，而是讓它幫你把排程的假設攤開。

先從交付物開始，不要從部門待辦開始

常見 WBS 寫法是「IT 開發、使用者測試、主管核准」。這種分類方便分工，卻不容易判斷成果。

比較好的方法是先定義最終交付物，再拆成可驗證的子交付物與工作包。每個工作包都要能回答：產出是什麼、誰主要負責、如何判斷完成、要用什麼證據。

「處理告警」不是好的工作包；「完成共用告警介面，通過三種嚴重度與離線重送測試」才容易估算、追蹤與驗收。

把工作、等待、核准與里程碑分開

排程最容易低估的，通常不是工作，而是沒被寫出來的時間。

工作需要人投入；等待可能只是日曆時間流逝；核准需要特定角色決定；里程碑則是零工期的狀態標記。把這些項目混在一起，就會出現「工程師只要兩天，為什麼專案要一週」的爭論。

清楚拆開之後，團隊才能真正討論：能否縮短的是工作本身，還是審查窗口？可以增加人力，還是只能提早送件？

每個依賴都要有開工證據

「A 完成後做 B」還不夠。應補上 B 開始前需要的具體條件，例如：核准版規格、可登入測試帳號、到貨設備、通過的 API 測試或正式資料樣本。

有了證據，就不必靠一句「應該可以開始」判斷。也可以在開工前提早發現缺件，而不是到了排定日期才臨時追問。

外部依賴尤其要獨立追蹤。供應商、採購、客戶資料、資安審查與產線窗口，都可能控制整條路徑。每項外部依賴至少要有窗口、要求日期、最新回覆、完成證據與最後確認日。

邏輯可平行，不代表資源可平行

兩個任務沒有前後關係，看起來可以同時開始；但如果它們共用同一位工程師、同一套測試設備或同一個審查者，實際上仍然會排隊。

因此，AI 健檢不能只看任務之間的箭頭，也要檢查資源容量。把每個角色的可用期間、同時作業上限與已占用工作一併提供，才能找出「表面平行、實際衝突」的工作。

關鍵路徑只是起點，近關鍵路徑同樣重要

從專案開始到最終里程碑，總工期最長且浮時最少的路徑，通常是關鍵路徑。這條路徑上的任務一旦延誤，最終日期也可能跟著延誤。

但管理時不能只盯著一條線。另一條路徑若只短一兩天，很容易在一次供應商延誤或一次返工後成為新的關鍵路徑。多條工作流匯合的整合測試、沒有替代人員的單點資源，以及低信心估算，也值得放進每日或每週追蹤。

若資料不足，AI 應該寫「關鍵路徑候選」，並說明需要哪些工作日曆、資源限制和實際日期才能正式計算。這比輸出一個看似精準卻不可驗證的日期更負責任。

用三種情境代替單一承諾

排程不是只有一個未來。至少可以建立：

• 基準情境：目前已確認的工期與資源。
• 受阻情境：外部依賴、低信心任務或核准延後。
• 救援情境：縮小首版範圍、部分平行或增加指定資源。

每個情境都要說明假設、影響、代價與需要誰決定。若只寫「加派人力可提前五天」，卻沒有說哪些工作能切分、增加多少協調成本，這仍然不是可以採用的方案。

專案提前的三種常見方法

第一種是分段交付，把最小可用範圍先完成；第二種是讓部分工作重疊，但接受較高返工風險；第三種是在可切分的工作增加人力、設備或外部支援。

三種方法都不是免費。分段交付會增加版本管理；平行作業可能造成介面返工；增加資源則帶來成本、溝通與上手時間。AI 的價值是把交換條件寫清楚，而不是自動選出「最佳答案」。

每週只追最有影響的下一步

完成健檢後，產出未來兩週的前瞻清單。優先列出即將到期的外部依賴、尚未取得的核准、關鍵與近關鍵任務、低信心估算，以及需要主管決策的交換條件。

這能讓進度會議從「每人輪流報告做了什麼」，改成「哪些條件若沒有在何時完成，會改變哪個交付日期」。

最後提醒

AI 可以協助你找到排程盲點，但不能替團隊承諾日期。任何工期都應有來源，任何依賴都應有完成證據，任何加速方案都應說明代價。

真正可靠的排程，不是日期填得最滿，而是當一項條件改變時，團隊知道它會影響哪條路徑、有哪些選項，以及誰需要做決定。

Blogger／WordPress CTA

你可以先從目前最容易延誤的一個專案開始，把任務表貼入本文提示詞。不要急著要求 AI 重排所有日期，先看它能否找出三個沒寫進甘特圖的等待、核准或資源依賴。若結果有幫助，再把確認後的資料更新到正式排程工具。

逐步操作

步驟 1：先寫「要交付什麼」，不要急著列活動

先完成這句話：

這個專案要讓誰，在什麼情境下，得到什麼可驗證成果？

例如，不要只寫「整合系統」，而要寫：

交付一套可在指定設備啟動、登入、切換模組、接收告警並留下操作紀錄的整合版本，通過核准測試案例。

同時列出本次不包含的範圍，避免排程默默膨脹。

步驟 2：把成果拆成可驗證的交付物

可用以下結構拆解：

• 最終交付物
• 子系統或工作流
  • 可驗證工作包

好的工作包通常具備四項資訊：

• 明確產出
• 單一主要負責角色
• 可判斷完成的標準
• 能合理估算的大小

「處理登入」太模糊；「完成統一登入介面，通過有效、無效與權限不足三類測試」比較可用。

步驟 3：為每個工作包補上完成證據

完成不能只寫 100%。可使用：

• 已核准文件版本
• 測試紀錄或截圖
• 簽收單
• 可重現的展示環境
• 已合併的版本編號
• 對帳結果
• 決策紀錄

如果拿不出完成證據，就先標記「完成定義待確認」。

步驟 4：分開五種排程元素

不要把所有東西都當成一般任務。至少分成：

類型	說明	例子
工作	需要投入人力完成	開發登入介面
等待	期間流逝但不一定持續投入	等候硬體到貨
核准	由有權限者確認	資安審查通過
里程碑	零工期的狀態標記	試行啟動
緩衝	吸收不確定性的保護時間	整合測試緩衝

這一步會讓「兩天工作、五天等待」不再被誤寫成兩天完成。

步驟 5：記錄工期來源與信心

每個工期都要標示來源，例如：

• 類似專案實績
• 負責人估算
• 供應商承諾
• 合約服務時間
• 尚待確認的暫定值

再加上信心等級：高、中、低。低信心估算要配一個重新估算觸發點，例如「原型完成後重估」。

步驟 6：替每個任務寫前置條件

不要只問「前一項任務是什麼」，還要問：

• 開始前必須取得什麼資料？
• 需要哪個版本、設備、帳號或環境？
• 誰要先做決定或核准？
• 必須全部完成才能開始，還是部分完成即可？
• 用什麼證據判斷已具備開工條件？

最常見的是「前項完成後才能開始」。若使用較進階的排程工具，也可能遇到同步開始、同步完成或後項開始後前項才能結束等關係；非技術使用者先把實際邏輯寫成白話，再由工具設定即可。

步驟 7：把外部依賴獨立列出

外部依賴包含：

• 採購與物流
• 供應商交付
• 客戶提供資料
• 法務、資安或財務核准
• 機房、產線或測試窗口
• 第三方 API、憑證與帳號

每一項至少記錄：依賴內容、窗口、要求日期、對方回覆、完成證據、最後確認日、失效條件。

步驟 8：檢查資源能否真的平行

兩個任務在邏輯上可以同時做，不代表資源上可以同時做。檢查：

• 是否共用同一位關鍵人員？
• 是否只能使用同一套測試環境？
• 同一供應商能否同時處理多項交付？
• 人員是否有固定會議、休假或其他專案？
• 審查者每天能處理多少件？

若同一人同時被排滿，應做資源平衡，而不是假設他能分身。

步驟 9：畫出依賴網路

對每項工作至少列：

任務編號 → 前置任務 → 工期 → 後續任務

接著尋找從專案開始到最後里程碑的所有主要路徑。總工期最長、可用浮時最少的路徑，是關鍵路徑候選。

若沒有專業工具，也可以先請 AI 用表格整理「路徑候選」，再把確認後的資料輸入正式排程工具計算。

步驟 10：同時找近關鍵路徑與匯流點

除了最長路徑，也要找：

• 只比關鍵路徑短 1 至 3 天的路徑
• 多條工作流匯合的整合測試
• 一個延誤會影響多個後續任務的節點
• 沒有替代人員或替代環境的單點

這些項目常比「目前最晚的任務」更值得每日追蹤。

步驟 11：檢查三類結構錯誤

請 AI 特別找：

1. 循環依賴：A 等 B、B 又等 A。
2. 孤兒任務：沒有前置、沒有後續，也無法解釋如何連到交付物。
3. 不合理平行：兩項任務都假設能開始，但其實共用同一資源或尚未取得共同輸入。

另外檢查是否出現「里程碑有工期」「摘要任務和子任務重複計時」「把緩衝藏在每項工期」等問題。

步驟 12：建立三種情境

建議至少比較：

• 基準情境：目前已確認的工期、資源與依賴。
• 受阻情境：低信心任務、外部交付或核准延後。
• 救援情境：縮小首版範圍、合理平行、增加指定資源或改用替代方案。

每個情境都要列出假設，不要只輸出一個看似精準的完成日期。

步驟 13：比較三種壓縮方法

如果需要提前，常見選項是：

• 分段交付：先完成最小可用範圍，其餘後補。
• 快速跟進：讓原本串行的工作部分重疊，但增加返工風險。
• 增加資源：在可切分的工作上增加人力或設備，但會增加協調與成本。

AI 應說明每個方案能影響哪條路徑、交換了什麼風險；不能只寫「多派人就能更快」。

步驟 14：產出兩週前瞻清單

每週更新未來兩週：

• 應完成的交付物
• 即將到期的外部依賴
• 尚未取得的核准
• 低信心工期
• 關鍵與近關鍵任務
• 需要主管決策的交換條件
• 觸發升級的日期或狀態

這份清單比每天追所有任務更有行動價值。

步驟 15：保留基準線，不要直接覆蓋日期

至少保留：

• 原始基準開始／完成日
• 目前預測開始／完成日
• 實際開始／完成日
• 偏差天數
• 偏差原因
• 核准的變更紀錄
• 下次重估日期

排程更新不是把舊日期擦掉，而是讓團隊知道「變了什麼、為什麼變、誰接受了影響」。

可直接複製的完整提示詞

以下提示詞可搭配任何能處理長文字與表格的生成式 AI。若資料量很大，先分批整理，再做總體依賴檢查。

【角色】
你是一位謹慎的專案排程分析助理。你擅長 WBS、任務依賴、資源限制、關鍵路徑候選、風險情境與排程溝通，但你沒有權力替專案負責人承諾日期、指派人員、核准加班、變更範圍或接受風險。

【任務】
請根據我提供的專案資料，完成 WBS 與依賴健檢。找出拆解不足、完成定義不清、等待與核准未列、外部依賴、循環依賴、孤兒任務、不合理平行、資源衝突、關鍵路徑候選與近關鍵路徑。最後提出可供人類決策的改善方案與兩週前瞻清單。

【專案基本資料】
- 專案名稱：［填入］
- 業務目標：［填入］
- 最終交付物：［填入］
- 本次包含範圍：［填入］
- 本次不包含範圍：［填入］
- 目標日期及性質：［硬性期限／內部目標／希望日期／尚待確認］
- 工作日曆：［工作日、假日、每日可用時段］
- 允許使用的資源：［角色、人數、設備、環境］
- 禁止假設事項：［例如不可假設加班、不可假設供應商提前］

【WBS 資料格式】
請依下列欄位貼入，每列一項：
任務ID｜上層交付物｜任務名稱｜類型（工作／等待／核准／里程碑／緩衝）｜主要負責角色｜預估工期｜工期單位｜工期來源｜信心（高／中／低）｜完成標準｜完成證據｜預定開始｜預定完成｜目前狀態

［在此貼上 WBS］

【依賴資料格式】
後續任務ID｜前置任務ID｜依賴邏輯的白話說明｜需要的輸入或條件｜條件擁有者｜要求日期｜完成證據｜目前狀態｜最後確認日

［在此貼上依賴資料］

【資源與行事曆格式】
資源名稱或角色｜可用期間｜每日或每週容量｜同時作業上限｜已占用工作｜休假或不可用時段｜是否有替代資源

［在此貼上資源資料］

【限制與判斷規則】
1. 只能使用我提供的資料；不得虛構工期、容量、日期、責任人、核准狀態或供應商承諾。
2. 缺少資料時標示「未知」，並列出需要向誰確認的問題。
3. 將事實、已核准決定、估算、假設、風險與建議分開。
4. 不得把希望日期、預定日期或低信心估算寫成正式承諾。
5. 不得把里程碑當成有工期的工作，也不得把等待時間藏進人工工時。
6. 若無法真正計算關鍵路徑，請標示「關鍵路徑候選」，說明欠缺哪些資料；不要假裝已用排程引擎計算。
7. 檢查邏輯依賴與資源依賴。邏輯上可平行但共用同一人或環境者，必須提出警示。
8. 檢查循環依賴、孤兒任務、重複任務、摘要與子任務重複計時，以及不合理的零工期。
9. 若提出壓縮方案，必須說明影響的路徑、前提、成本、返工風險與需要誰核准。
10. 所有日期使用［YYYY-MM-DD］，並註明時區［填入時區］；若資料沒有年份或時區，列為待確認。
11. 對低信心估算提出重新估算的觸發點。
12. 保留原始基準與目前預測，不建議直接覆蓋歷史日期。

【輸出格式】
A. 一分鐘主管摘要
- 目前最可能影響最終日期的 3 至 5 項因素
- 需要決策的事項
- 不確定性與信心說明

B. WBS 品質檢查表
欄位：任務ID｜問題類型｜問題說明｜影響｜建議修正｜需要確認者

C. 依賴健檢表
欄位：後續任務｜前置條件｜證據｜擁有者｜狀態｜缺口｜最晚確認點

D. 路徑分析
- 列出主要路徑候選及總工期計算方式
- 標示關鍵路徑候選、近關鍵路徑、匯流點與單點資源
- 說明哪些是邏輯判斷，哪些需正式排程工具驗證

E. 資源衝突表
欄位：資源｜衝突期間｜競爭任務｜容量缺口｜可能影響｜可選處理方式

F. 三種情境
欄位：情境｜主要假設｜可能完成區間｜影響範圍｜代價與風險｜所需決策
情境至少包含基準、受阻、救援。

G. 兩週前瞻清單
欄位：日期｜交付物或條件｜負責角色｜完成證據｜目前狀態｜阻塞｜升級觸發點

H. 高價值確認問題
依「若不確認，最可能改變排程」排序，最多 10 題。

I. 對外溝通草稿
產出一段 150 至 250 字的繁體中文進度說明，清楚區分基準、目前預測、風險與待決策事項，不將預測寫成保證。

【最後自我檢查】
輸出前，逐項確認：
- 是否發明了任何工期、資源、核准或日期？
- 是否把等待時間誤當人工工時？
- 是否把邏輯可平行誤當資源可平行？
- 是否把候選關鍵路徑寫成已正式計算？
- 是否說清楚每項建議需要的交換條件？
若有，請修正後再輸出。

可替換欄位快速表

欄位	替換內容
［專案名稱］	例如：智慧邊緣盒整合專案
［目標日期及性質］	例如：2026-12-18，內部目標，尚未對客戶承諾
［工作日曆］	例如：週一至週五，國定假日不工作
［時區］	例如：Asia/Taipei
［禁止假設事項］	例如：不可假設週末加班、不可假設測試設備可同時共用
［完成證據］	例如：測試紀錄、核准文件、版本編號

實際教學範例

以下為教學用的虛構資料。工期只是示範假設，不代表任何實際專案承諾。

專案背景

團隊要把 AIE 的 AIoT、EAP、RPA、RCM，以及 AZL 的 SPC 整合到「PC＋KVM」智慧邊緣盒。已知資訊包括：

• RPA 現有版本以 WinForms 為主，完整改寫成本高。
• 其他模組可能需要提供精簡 WinForms 版本。
• GPU 不在本期範圍。
• SPC 後端預計使用 Python。
• 需要處理硬體 BOM、採購、KVM 整合、統一登入、設定、告警、儀表板、模組介面、封裝、系統測試及試行。

初版任務清單的問題

原本只有：

1. 確認需求，5 天
2. 開發各模組，20 天
3. 整合，10 天
4. 測試，5 天
5. 上線，1 天

看似總共 41 天，但無法回答：

• 哪些模組能平行？
• 誰先定義共用介面？
• 硬體何時到貨？
• KVM、登入與告警是否都有驗收標準？
• RPA 是否真的要改寫？
• 測試要用幾套設備？
• 「上線」是內部試行還是正式商用？

健檢後的部分 WBS

ID	工作包	類型	假設工期	主要前置	完成證據
W01	凍結本期整合範圍與排除項	核准	2 工作日	無	核准的範圍基準
W02	定義共用登入、設定、告警與儀表板介面	工作	5 工作日	W01	介面規格 v1 核准版
W03	確認硬體 BOM 與相容性	工作	4 工作日	W01	BOM 與相容性紀錄
W04	採購與到貨	等待	15 日曆日	W03	收貨與檢驗紀錄
W05	KVM 整合原型	工作	6 工作日	W03、測試設備可用	原型展示與測試紀錄
W06	RPA 精簡版範圍確認	核准	3 工作日	W01	已核准功能清單
W07	RPA 精簡版製作	工作	8 工作日	W02、W06	可安裝版本與測試紀錄
W08	AIoT／EAP／RCM 精簡介面	工作	10 工作日	W02	三模組整合版本
W09	SPC Python 後端與介面	工作	9 工作日	W02	API 測試紀錄
W10	整合封裝	工作	5 工作日	W05、W07、W08、W09、W04	安裝包與版本清單
W11	系統測試	工作	7 工作日	W10、測試案例核准	測試報告
W12	缺陷修正與回歸	工作	5 工作日	W11	回歸測試紀錄
M01	試行準備完成	里程碑	0 天	W12、操作手冊、現場窗口確認	Go／No-Go 決策紀錄

AI 找出的五個重點

1. 介面規格是隱藏的共同前置

RPA、AIoT、EAP、RCM 與 SPC 表面上可平行，但若共用登入、設定與告警介面未定義，各模組會用不同假設開發，最後在整合階段返工。

2. 有兩條主要路徑候選

軟體路徑候選：

範圍凍結 → 共用介面 → 最慢模組精簡版 → 整合封裝 → 系統測試 → 回歸 → 試行準備

硬體路徑候選：

範圍凍結 → BOM與相容性 → 採購到貨 → KVM整合 → 整合封裝 → 系統測試 → 回歸 → 試行準備

哪一條是真正關鍵路徑，仍要配合工作日曆、實際開始日、資源限制與正式排程工具計算。

3. 「可平行」受到共同資源限制

若 W05、W08 與 W09 都需要同一套測試設備，即使邏輯上可平行，實際仍須排序或增加設備。這是資源依賴，不會從單純的前後關係中自動看出來。

4. 整合封裝是高風險匯流點

W10 必須等待五項輸入。任何一項延誤都可能使整合無法開始，因此應設置「整合就緒清單」，而不是到預定開工日才逐項詢問。

5. GPU 應明列為排除範圍

若只在會議中口頭提過「這一期先不做」，後續容易被誤當遺漏。排除範圍也應有版本與核准紀錄。

三種情境示範

情境	假設	結果表達方式	主要風險
基準	工期採目前負責人估算；硬體準時到貨；一套測試設備	形成目前預測區間，待資源平衡後確認	共同設備造成排隊
受阻	硬體晚 5 天；介面規格多一次審查	硬體路徑可能成為控制最終日期的路徑	整合與測試連續後移
救援	先交付 RPA＋SPC＋共用告警的最小版本；增加第二套測試設備	可望提前啟動有限範圍試行	範圍分段、成本增加、後續二次整合

這裡不直接宣布確切完工日，因為缺少資源日曆、實際開始日、假日、審查窗口及各工期的可靠來源。

可直接使用的進度說明範例

目前排程健檢顯示，專案主要受兩條路徑影響：共用介面完成後的模組整合，以及硬體到貨後的 KVM 驗證。兩條路徑都匯入整合封裝與系統測試；其中硬體交期與共用測試設備容量仍待確認，因此目前日期屬預測，不是正式承諾。建議本週先完成範圍基準、介面規格與整合就緒清單，並由主管決定是否採取「限縮首版範圍」或「增加第二套測試設備」。確認後再更新正式排程與完成區間。

常見錯誤、隱私與使用注意事項

常見錯誤

錯誤 1：請 AI 直接排出一個完成日

若未提供工作日曆、資源容量與依賴，AI 只能產生外觀合理的猜測。

改善方式：要求輸出完成區間、假設、信心與缺少資料。

錯誤 2：把工作量當成日曆時間

16 小時工作不一定等於兩天完成，因為負責人可能每天只能投入四小時，也可能要等待審查。

改善方式：分開記錄工作量、投入比例、等待與核准時間。

錯誤 3：所有任務都設為前後串接

這會造成不必要的長排程；反過來，全部平行也會忽略介面、資源與環境限制。

改善方式：每個依賴都附白話原因與開始證據。

錯誤 4：以任務完成百分比判斷進度

五個小任務完成、關鍵交付物仍未開始，專案可能不是完成 50%。

改善方式：看交付物、路徑與完成證據，不做簡單平均。

錯誤 5：偷偷把緩衝加進每項工期

這會讓團隊無法知道哪裡是真實工作、哪裡是不確定性。

改善方式：保留估算依據，並在適當層級明列緩衝。

錯誤 6：只催關鍵路徑，不處理近關鍵路徑

今日非關鍵的路徑，明天可能因一項延誤成為新的關鍵路徑。

改善方式：追蹤浮時小、低信心或外部依賴高的路徑。

錯誤 7：增加人力就等比例縮短工期

審查、等待、不可切分工作或新成員上手時間，通常無法靠加人線性縮短。

改善方式：說明哪些工作可切分，以及協調成本與品質風險。

資料隱私

送入 AI 前，先移除或代碼化：

• 客戶與供應商真實名稱
• 人員姓名、Email、電話與帳號
• 合約價格、付款條件與未公開交期
• 內部系統網址、IP、API 金鑰與密碼
• 資安架構、弱點細節與存取權限
• 未公開產品代號、圖紙、程式碼與商業機密

建議把「王小明」改成「工程角色 A」，把供應商改成「外部供應商 V1」。若公司有核准的企業 AI 環境與資料分類政策，依該政策使用；不確定時，只提供足以完成分析的最小資料。

使用注意事項

• AI 的路徑分析應視為健檢與候選結果，正式排程仍要由專案工具或人工驗算。
• 工期必須由實際負責人確認；AI 不知道團隊真實速度。
• 外部依賴要向實際窗口確認，不可把「通常五天」當成本次承諾。
• 任何縮範圍、加資源、平行作業或風險接受，都需要有權限的人決定。
• 不要讓 AI 直接改寫正式基準線；先產出變更建議與差異，再經核准更新。
• 重新排程時，保留原始承諾與變更紀錄，避免事後看不出偏差。