AI 進度百分比校正：把專案「80%」改成可驗證的完成預測

AI 辦公實戰｜原內容日期：2026-10-21；補刊日期：2026-10-23。

專案會議上最常聽到的答案之一是：「目前大約 80%，應該快好了。」

但下一週它可能仍是 80%，再下一週變成 85%，直到交付日前才發現：程式雖然寫完，測試環境還沒準備；測試雖然開始，關鍵案例仍失敗；文件雖然有初稿，真正要接手的人還沒確認。

問題不一定是團隊刻意美化，而是大家對「完成」的理解不同。有人把開始做算 20%，有人把程式寫完算 90%，也有人認為通過驗收才是 100%。沒有共同規則，百分比就只是多個主觀感覺的平均。

百分比不是證據

一個可信的進度更新，至少應回答五件事：

1. 已完成什麼交付物？
2. 哪些證據能證明完成？
3. 還剩哪些具體工作？
4. 目前卡在哪裡、等待誰？
5. 在哪些假設下，何時可能完成？

如果這五題答不出來，85% 和 65% 的管理價值幾乎沒有差別。

先定義完成，再計算進度

「測試完成」不是好定義。更可靠的寫法是：「指定版本的 20 個驗收案例已執行，阻斷級缺陷為 0，測試報告由 QA 核准並附連結。」

完成定義必須能被第三人核對。常見證據包括核准紀錄、交付檔案、測試結果、部署紀錄、簽收或系統狀態。只有口頭回報時，不代表對方說錯，而是應先標示「待驗證」。

不要把已花工時當成果

投入 80 小時，只能證明成本已經發生，不能證明成果已完成。尤其遇到返工、等待或方向變更時，已花工時可能增加，真正完成的交付物卻沒有增加。

因此進度計算應以交付物或明確階段為基礎。若採階段加權，就要先定義每個階段的權重與通過條件，而不是看到「做了一半」就填 50%。

工作量與日曆時間要分開

剩餘工作 12 小時，不代表兩天後一定完成。若負責人每天只能投入 3 小時，還要等待一次主管審查與一次環境部署，日曆時間可能超過一週。

AI 很適合協助拆分這些資訊：實際工作、外部等待、核准時間、返工機率與可用產能。它可以產生基準、保守與不利三種預測，但每個日期都必須附假設，不能被包裝成承諾。

六種值得立刻追查的進度假象

• 百分比上升，卻沒有新增證據。
• 任務投入很多時間，但沒有新增交付物。
• 子任務完成率很高，關鍵項目卻尚未開始。
• 進度連續兩期沒有變化。
• 狀態維持綠燈，預測完成日卻不斷後移。
• 整體平均好看，但高風險或關鍵路徑工作落後。

這些訊號不一定代表有人隱瞞，而是提醒 PM：應把對話從「你到底做了多少」改成「剩下什麼、卡在哪裡、需要什麼決定」。

一個 85% 變成 58% 的例子

以下為虛構教學案例；85% 是原始回報值。檢查後發現，畫面開發尚未部署至測試環境、離線重送衝突未完成、權限功能沒有測試證據、10 個驗收案例僅 3 個通過。為示範計算，假設團隊已先核准以下階段與子階段認列規則；這些比例不能由 AI 從零散敘述自行推定：

工作	專案權重	依示範規則認列的進度
欄位與流程設計	15%	100%
App 畫面開發	30%	70%
離線補登功能	20%	50%
權限與稽核紀錄	15%	40%
使用者驗收	15%	30%
教育與上線交接	5%	20%

加權為 15%×100%＋30%×70%＋20%×50%＋15%×40%＋15%×30%＋5%×20%＝57.5%，對外摘要寫約 58%。若沒有核准的認列規則，先列缺口，不計算此比例。

這不是把團隊的成果打折，而是把「程式寫了多少」與「整體交付離完成還有多遠」分開。校正後，團隊能更早安排測試環境、驗收人力與離線情境修正，而不是在週五才發現無法上線。

週報應該怎麼寫

比起「整體 85%，進度正常」，更好的寫法是：

目前可驗證完成約 58%。設計已核准，主要畫面已完成開發；但測試環境未部署、離線重送衝突未處理，10 個驗收案例僅 3 個通過。若週三前完成部署並關閉衝突問題，保守預測下週二完成；否則需重新估算。今日需要確認環境負責人與驗收人力。

這段話同時提供成果、缺口、條件、預測與決策，比單一百分比更能支持管理。

結語

進度管理的目的不是得到一個漂亮數字，而是提早知道是否需要調整範圍、資源、順序或交期。

AI 可以快速整理任務、比對證據、重算加權進度與找出異常，但最後仍需要負責人確認事實、由有權責者接受風險。下一次有人說「目前 80%」時，不必立刻質疑他；先問五件事：完成了什麼、證據在哪、還剩什麼、卡在哪裡、哪些假設成立才會如期完成。

逐步實作教學

第 1 步：先選擇要校正的範圍

先處理一個專案、一個里程碑或未來兩週內的重要工作，不要一開始就把整間公司的任務全部丟給 AI。

第 2 步：定義「完成」

為每項任務寫出可驗證的完成條件，例如「測試報告由 QA 核准並附報告連結」，不要只寫「測試完成」。

第 3 步：拆開工作與等待

將實際執行、等待資料、等待核准、等待供應商、等待環境分開。等待雖不一定消耗工時，卻會影響日曆交期。

第 4 步：選定計量方式

優先使用下列方式之一：

• 里程碑加權：依交付重要性給權重。
• 完成規則：未達完成定義為 0，達成才是 100。
• 階段加權：例如設計 20%、建置 35%、測試 30%、驗收 15%。
• 剩餘工作量：比較已花工時與仍需工時，但不可把已花時間直接當成果。

同一層級不要混用多種算法。

第 5 步：收集基準資料

記錄原始開始日、原始完成日、目前預測日、負責人與上次更新時間。沒有基準，就無法判斷是否滑動。

第 6 步：收集完成證據

每個「已完成」至少要有一項證據：核准紀錄、交付檔案、測試結果、部署紀錄、簽收或系統連結。只有口頭回報時，標示為「待驗證」。

第 7 步：盤點剩餘工作

不要問「還剩 20% 是什麼」，改問：還有哪些具體交付物、誰要做、需多少工作量、有哪些前置條件、完成證據是什麼。

第 8 步：辨識六種狀態

將每項工作標記為：未開始、進行中、待外部、受阻、待驗收、已完成。不要用「差不多」「快好了」當狀態。

第 9 步：找出進度假象

請 AI 特別檢查：

• 百分比增加但沒有新證據。
• 已花很多時間但交付物未增加。
• 子任務完成很多，關鍵子任務卻未開始。
• 任務連續兩期維持同一百分比。
• 狀態為綠燈，預測日卻持續延後。

第 10 步：重新計算加權進度

只使用有證據的完成項目計算。部分完成若沒有客觀階段規則，先列為進行中，不要任意填 50%。

第 11 步：估算剩餘時間

把工作量與日曆時間分開：剩餘工作 12 小時，不代表兩天後完成；還要納入可用產能、等待、審查與返工。

第 12 步：做三種預測

• 基準：依目前速度與已知等待。
• 保守：加入常見返工與排隊時間。
• 不利：加入高風險依賴失敗或關鍵人員不可用。

所有日期都要附假設，不能寫成保證。

第 13 步：設定預警觸發條件

例如：

• 連續 7 天沒有新完成證據。
• 關鍵前置工作晚於最晚啟動日。
• 待外部回覆超過 3 個工作天。
• 剩餘工作量增加超過 20%。
• 基準完成日滑動超過 2 個工作天。

第 14 步：產出主管可讀摘要

摘要只需回答：整體狀態、已完成成果、最大缺口、完成預測、需要誰在何時做什麼決定。

第 15 步：保留每次校正紀錄

每週保留舊版的百分比、預測日、假設與證據。不要覆蓋歷史，否則無法辨識進度倒退或反覆展延。

完整提示詞與輸入格式

可替換欄位

• [專案／里程碑名稱]
• [報告日期]
• [計量方式]
• [風險容忍度]
• [預警門檻]
• [工作日曆與每日可用產能]
• [任務資料]
• [證據資料]
• [已知依賴與等待]

完整提示詞

你是一位審慎的專案控制與交付管理顧問。你的任務不是讓進度看起來更好，而是把模糊的進度百分比校正成可驗證、可預測、可採取行動的狀態。

【任務】
請分析「[專案／里程碑名稱]」截至 [報告日期] 的進度。核對每項工作的完成定義、證據、剩餘工作、等待、依賴與預測日期，找出進度假象及早期預警，最後產出主管摘要與執行清單。

【計量設定】
- 計量方式：[里程碑加權／完成規則／階段加權／其他明確規則]
- 風險容忍度：[低／中／高]
- 預警門檻：[例如連續 7 天無新證據、完成日滑動 2 天]
- 工作日曆與產能：[例如週一至週五，每人每日可投入 4 小時]

【輸入資料格式】
請用下列表格欄位提供資料；未知請填「未知」，不要留白：

任務編號｜任務名稱｜負責人｜權重｜原始開始日｜原始完成日｜目前回報百分比｜目前狀態｜完成定義｜已完成交付物｜證據編號｜剩餘工作｜剩餘工時估計｜前置依賴｜等待對象｜預測完成日｜上次更新日｜備註

證據資料格式：
證據編號｜證據類型｜名稱或連結｜日期｜提供者｜核准者｜適用任務｜版本｜是否可驗證

【分析規則】
1. 不得把已花工時直接視為完成比例。
2. 沒有符合完成定義的證據，不得判定為已完成；請標示「待驗證」。
3. 不得因文字相似就認定證據與任務正式對應。
4. 部分完成只有在有明確階段權重時才能計入；否則列為進行中。
5. 分開計算工作量與日曆時間，納入等待、審查、返工與可用產能。
6. 不得自行補造工時、日期、責任人、核准或測試結果。
7. 發現資料衝突時，並列原始說法、來源與需確認者。
8. 所有預測日期都要列出假設、信心等級與重新估算條件。
9. 不替負責人承諾交期，不替主管接受風險。
10. 涉及個資、客戶名稱、帳號、商業機密時，以代碼取代。

【請依序輸出】
A. 資料品質檢查
- 缺少欄位
- 衝突資料
- 過期或無法驗證的證據
- 需要人工確認的問題

B. 進度校正表
欄位：任務編號｜回報進度｜可驗證進度｜差異｜狀態｜有效證據｜剩餘工作｜阻塞／等待｜信心｜判斷理由

C. 進度假象清單
至少檢查：無證據增長、長期不動、忙碌但無交付、關鍵項目落後、綠燈但日期滑動、平均值掩蓋風險。

D. 整體進度
- 依指定規則計算可驗證的加權進度
- 顯示公式與分母
- 將未知與未驗證項目單獨列出
- 不要提供看似精確但沒有依據的小數點

E. 完成預測
以表格提供基準、保守、不利三種情境：預測日期｜主要假設｜關鍵依賴｜信心等級｜重新估算條件。

F. 早期預警
欄位：訊號｜目前值｜門檻｜可能影響｜立即行動｜負責角色｜最晚處理日。

G. 主管一分鐘摘要
120 至 180 字，依序寫：目前狀態、完成成果、最大缺口、預測區間、需要的決策。避免空泛語句。

H. 未來 5 個工作天行動清單
欄位：優先序｜行動｜負責角色｜期限｜完成證據｜若未完成的影響。

I. 需要追問的問題
只列會實質改變進度判斷或完成預測的問題，依影響程度排序。

【輸入資料】
[貼上任務資料]

【證據資料】
[貼上證據資料]

【已知依賴與等待】
[貼上依賴、外部回覆、核准與環境限制]