原內容日期：2026-09-09。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。
「三天做得完嗎？」為什麼這麼難回答？
因為主管問的是日曆日期，而執行者腦中想到的通常只有實作工時。
一項工作也許真正操作只需八小時，但開始前要等資料，完成後要等審查，中間還有固定會議、例行維運與其他專案。最後經過時間可能是三個工作日，甚至更久。
AI 可以協助我們把這些隱藏時間找出來，但前提是不要直接問：「這個專案要多久？」
資料不足時，AI 給出的單一日期往往只是流暢的猜測。
先確認交付物，再開始估時間
「完成月報自動化」不是可估算的範圍。它可能只是匯入一種表格，也可能包含多種格式、異常處理、權限、排程、通知、測試、文件與正式上線。
比較好的描述是：「建立可匯入三種既有報表、產生部門摘要與異常清單的試行流程，並由使用部門以兩期匿名樣本完成驗證。」
同時列出不包含範圍、完成標準與驗收角色。範圍不清時，最合理的答案不是硬給日期，而是先標示低信心並安排小型驗證。
工作量不等於經過時間
工作量是實際投入的時數；經過時間是從開始到完成的工作日或日曆日。
若一名成員每天名義工作八小時，但扣除會議、維運、溝通及其他專案後，真正可投入本任務只有 4.5 小時，那麼 34.5 小時的工作量約需 7.7 個工作日。還沒有算進外部等待。
這項區分能避免最常見的交期誤解：用工時除以八，就當成完成天數。
三點估算，比單一數字更誠實
每項工作可以估樂觀 O、最可能 M 與悲觀 P。
樂觀不是零風險的夢想，悲觀也不是世界末日；兩者都應是合理可描述的情境。若需要一個輔助值，可以使用（O＋4M＋P）÷6，但仍要保留原始三個數字與估算依據。
真正重要的不是公式，而是迫使團隊說清楚：什麼條件會讓工作更快？什麼情況會造成返工？目前的判斷來自歷史資料、試做，還是純粹經驗？
別把未知當成零
樣本尚未取得、需求名詞未定義、權限未核准、供應商尚未回覆，這些都不是零天。
可以將它們列為依賴與等待，標示最晚需要時間及延後影響。若等待時間無法估，應呈現為交期信心低的原因，而不是讓它消失在表格之外。
多一個人，不一定快一倍
有些工作能並行，例如文件整理與測試資料準備；有些工作共用同一位專家，仍然只能排隊。新成員加入也需要理解背景、取得權限、接受交接及完成整合。
因此，增加人力的方案要回答：新增的是哪種能力？何時真正可投入？誰負責交接？整合成本是多少？
如果這些問題沒有答案，「加兩個人」只是另一個未驗證假設。
用三種情境代替假裝精準
一份可用的預測應包含順利、基準與不利情境，每個情境都有日期區間、成立前提與觸發條件。
例如完整範圍在樣本立即到位、一次審查通過時，可能需要 8～9 個工作日；正常等待與一次主要修正下為 11～12 日；若樣本延遲且需第二輪驗證，可能是 15～16 日。
這些不是精準機率，而是讓決策者看見不同條件與交期的關係。
期限固定，不代表只能回答「做不到」
如果希望日期早於基準預測，可以提出四種槓桿：縮小範圍、分段交付、調整資源，或降低其他工作負荷。
每個方案都要說明對品質、成本、風險及其他專案的影響。不能默默拿掉必要測試，再把原本的品質承諾保留在簡報上。
好的協商不是把困難丟回主管，而是提供可決定的選項。
估算完成後，還要設定何時重估
如果樣本晚兩天、規則新增、關鍵人員可用時間降低，或首輪測試未達門檻，就應重新預測。
每週更新不只報完成百分比，還要列出已完成交付物、剩餘工作、目前預測、與上次差異及原因。這樣團隊能在交期失守前做範圍或資源決定。
AI 幫你建立模型，人負責承諾
AI 很適合找出漏項、整理三點估算、換算產能、比較情境與草擬協商訊息。
但它不知道真實團隊速度，也不能替外部審查者承諾回覆，更不能把主管希望的日期改寫成正式交期。
好的估算不是永遠猜中，而是讓範圍、依據、不確定性與變動都可以被看見。當新證據出現，團隊能及早更新，而不是最後一天才說來不及。
文章 CTA： 下次有人問「三天能不能做完」，先不要急著回答日期。把交付物、可用時數、依賴與三點估算放進本文提示詞，先產出三種情境，再談正式承諾。
逐步操作
第一步：先寫清楚要交付什麼
不要估「做月報自動化」；先寫成可驗收的成果：
建立一個可匯入三種既有報表、產生部門月報摘要並列出異常資料的試行流程，由使用部門以兩期匿名樣本完成驗證。
同時列出：
- 本次包含什麼
- 本次不包含什麼
- 誰負責驗收
- 用什麼證據算完成
範圍不清時，任何精準日期都只是猜測。
第二步：辨識日期的身分
| 日期類型 | 意義 | 可以直接當正式承諾嗎 |
|---|---|---|
| 希望日期 | 主管或客戶期待 | 不行，需評估 |
| 初步預測 | 根據目前資料推估 | 不行，需附假設 |
| 目標日期 | 團隊努力方向 | 不一定，要說明風險 |
| 正式承諾 | 權責雙方確認的日期 | 可以，但仍需變更機制 |
| 最晚需要日 | 下游工作所需的依賴日期 | 代表風險，不等於上游已答應 |
AI 不得把「希望星期五前」改寫成「團隊承諾星期五交付」。
第三步：把工作拆成 0.5～2 天可完成的單位
每項工作應能回答：
- 產出是什麼？
- 誰執行？
- 開始前需要什麼？
- 怎樣知道完成？
- 誰要審查？
若一項工作寫成「完成系統」，仍太大。可以拆成資料定義、樣本取得、欄位對照、原型、例外規則、測試、修正、使用者驗證與上線準備。
第四步：補上最容易漏掉的六類工作
- 準備：權限、環境、樣本與工具
- 澄清：名詞、規則、邊界與例外
- 執行：真正製作或分析
- 品質：自我檢查、測試、同儕審查
- 溝通：說明、培訓、文件與交接
- 驗收：使用者確認、修正與正式核准
AI 特別適合用這六類反問漏項，但要由實際執行者確認。
第五步：分開「工作量」與「經過時間」
- 工作量（effort）： 真正投入工作的時數或人天。
- 經過時間（duration）： 從開始到完成經過的日曆或工作日。
例如撰寫報告需要 6 小時，但若中間等待主管審查兩天，經過時間可能是三個工作日。
第六步：做三點估算
對每項工作估三個數字：
- 樂觀 O： 條件順利、沒有明顯返工。
- 最可能 M： 依正常中斷與常見問題估算。
- 悲觀 P： 合理的不利情境，但不是世界末日。
可選擇使用加權平均：
預期工時 =（O ＋ 4M ＋ P）÷ 6
這只是輔助，不是保證。資料很少時，保留 O／M／P 三個值往往比只顯示平均更誠實。
第七步：列出估算依據
每個數字至少有一種依據：
- 過去相似工作
- 小型試做
- 執行者判斷
- 供應商回覆
- 標準作業時間
- 尚無依據的初始假設
若沒有任何依據，信心應標成低，並優先安排小型驗證。
第八步：畫出依賴與可並行關係
逐項標記：
- 必須等前一步完成
- 可部分重疊
- 可完全並行
- 需要同一稀缺角色
- 依賴外部回覆
兩項各五天的工作若可並行，交期不一定是十天；但若都依賴同一位人員，也不能假設只要五天。
第九步：計算真實可用產能
不要直接用「每天八小時」。先扣除：
- 固定會議
- 例行維運
- 其他專案
- 行政與溝通
- 任務切換
- 已知請假
例如每天工作八小時，能投入本任務的專注時間可能只有 4.5 小時。34.5 小時工作量約需 7.7 個工作日，而不是 4.3 天。
第十步：分開工作緩衝與專案緩衝
- 工作內不確定性： 已反映在 O／M／P。
- 專案緩衝： 保護整體交期，應對跨工作累積風險。
- 管理保留： 處理範圍外重大事件，需由有權角色決定。
不要重複加緩衝，也不要把緩衝當成可任意挪用的空白時間。
第十一步：產生三種交期情境
不要只回答「九月二十日」。改成：
- 順利情境： 關鍵資料準時、一次審查通過。
- 基準情境： 包含正常等待與一次修正。
- 不利情境： 資料延遲、規則新增或需要第二次驗證。
每個情境都要列出日期、前提與觸發條件。
第十二步：用信心等級表達不確定性
| 信心 | 建議判斷 |
|---|---|
| 高 | 範圍穩定、有相似歷史資料、主要依賴已確認 |
| 中 | 主要工作可估，但仍有一至兩項重要依賴 |
| 低 | 範圍、資料、技術或決策角色仍不明 |
信心低時，不應用更多小數點製造精準感；應指出如何用試做或補件提高信心。
第十三步：期限固定時，提出四種選擇
如果期限不能動，可以協商：
- 縮小範圍： 先交付最小可用成果。
- 分段交付： 核心功能先完成，其餘排第二階段。
- 調整資源： 增加具備相應能力的人，但評估交接成本。
- 降低其他負荷： 延後或轉移既有工作。
不能默默把測試與驗收刪掉，卻仍宣稱品質不受影響。
第十四步：設定重新估算的觸發條件
例如：
- 樣本資料比預定晚兩個工作日
- 新增資料來源或例外規則
- 關鍵人員可用時間下降 25%
- 首輪測試失敗超過核准門檻
- 審查者要求第二輪重大修改
- 外部核准日期改變
觸發後要更新預測，不是等到原期限才宣布延期。
第十五步：每次回顧「估錯在哪一層」
完成後比較：
- 範圍差異
- 工作量差異
- 等待時間差異
- 資源可用率差異
- 返工差異
- 未預見事件
目的不是責怪估算者，而是讓下一次的範圍、歷史資料與風險判斷更好。
可直接複製的完整提示詞
你是一位資深專案經理、交付規劃顧問、工作分解與風險估算專家。你擅長協助非技術使用者把模糊任務拆成可估算工作，分開工作量與日曆時間，辨識等待、依賴、返工與資源限制，產生有條件的交期區間及協商方案。
【任務】
請根據我提供的交付目標、範圍、工作、資源、依賴及歷史資料，建立一份可追溯的任務估時與交期預測。
你的任務不是給出看似精準的單一日期，而是說明估算依據、不確定性、情境與可調整槓桿。不得替任何人承諾期限，也不得捏造團隊速度、工時、資料或核准規則。
【基本資料】
專案／任務名稱：[填寫]
今天日期：[YYYY-MM-DD]
希望日期：[填寫；沒有則填無]
希望日期提出者：[角色]
正式承諾日期：[填寫；尚未承諾則填無]
交付物：[填寫]
完成標準：[填寫]
驗收角色：[填寫]
本次包含範圍：[填寫]
本次不包含範圍：[填寫]
品質、法規或安全底線：[填寫]
估算單位：[小時／人天／工作日]
工作日與假日規則：[填寫]
【目前已知工作】
編號｜工作｜產出｜執行角色｜前置條件｜審查角色｜完成標準
[貼上資料；不知道的欄位填待確認]
【初步估算】
工作編號｜樂觀 O｜最可能 M｜悲觀 P｜估算單位｜估算者｜依據｜信心
[貼上資料；若沒有，請只建立待估表，不得自行編造數字]
【資源與可用率】
角色｜人數｜每日名義工時｜本任務可用比例或小時｜固定會議／維運｜請假或限制
[貼上資料]
【依賴與等待】
工作編號｜等待對象｜需要的輸入｜最早可取得｜最晚需要｜一般等待時間｜是否已確認
[貼上資料]
【可並行與資源衝突】
工作 A｜工作 B｜可完全並行／部分並行／不可並行｜原因｜是否使用同一稀缺角色
[貼上資料]
【歷史參考】
相似任務｜當時範圍｜預估工作量｜實際工作量｜預估交期｜實際交期｜差異原因
[貼上資料；沒有則填無]
【已知風險與變更】
風險／變更｜發生條件｜影響工作｜可能增加的工作量或等待｜處理方式
[貼上資料]
【分析限制】
1. 先檢查交付物、範圍、完成標準及驗收角色是否足以估算。
2. 缺少關鍵資料時，先列待確認事項，不得直接產生精準日期。
3. 區分希望日期、初步預測、目標日期、正式承諾及最晚需要日。
4. 提出者希望的日期不等於執行者已接受的承諾。
5. 將工作拆成約 0.5～2 個工作日可完成、可驗證的單位；過大工作需再拆分。
6. 補查準備、澄清、執行、品質、溝通及驗收六類漏項。
7. 不得自行創造工作量；沒有執行者估算或歷史依據時，建立估算問題與待填表。
8. 每個估算保留樂觀 O、最可能 M、悲觀 P 與依據。
9. 如資料齊全，可使用（O＋4M＋P）÷6 做輔助加權平均，但必須同時保留原始三點估算。
10. 不得把公式結果描述為保證、精準機率或正式承諾。
11. 分開工作量與經過時間，不能把等待時間算成實作工時。
12. 計算日曆時間時，使用我提供的真實可用率、工作日及請假資料。
13. 不得假設名義八小時都能投入本任務。
14. 多人工作不得直接用總工時除以人數；需考慮技能、交接、溝通與整合成本。
15. 標出可並行、部分並行、不可並行與共享稀缺資源的工作。
16. 找出關鍵路徑候選，但資料不足時不得宣稱已確認唯一關鍵路徑。
17. 區分實作、等待、審查、返工與發布所需時間。
18. 避免同一風險同時出現在悲觀估算與額外緩衝中，造成重複計算。
19. 產生順利、基準與不利三種情境，每種都列出前提與觸發條件。
20. 信心以高／中／低呈現，並說明判斷理由及如何提高信心。
21. 如果希望日期早於基準情境，不得只回答做不到；提出縮小範圍、分段交付、調整資源及降低其他負荷的方案。
22. 不得以刪除必要測試、法規、安全或驗收工作換取表面準時。
23. 若建議增加人力，必須列出交接、協調、技能匹配及開始生效時間。
24. 所有方案列出對範圍、品質、成本、風險與其他工作的影響。
25. 設定里程碑、最晚開始時間、早期警訊與重新估算觸發條件。
26. 進度不得只以百分比表達；同步列出已完成交付物、剩餘工作與新增風險。
27. 不得替未確認的外部團隊、供應商或審查者承諾回覆日期。
28. 涉及法務、財務、資安、安全、合約、人事或客戶承諾時，標示需由相應角色確認。
29. 對外協商訊息必須經人工檢查後才能發送。
30. 使用繁體中文，語氣專業、透明、可協商，不責怪估算者或執行者。
【輸出格式】
一、估算可行性診斷
以 200 字內說明目前資料是否足以估算、最大不確定性及希望日期的性質。
二、範圍與完成定義
| 項目 | 已確認內容 | 尚待確認 | 對估算影響 |
三、日期身分
| 日期 | 類型 | 提出／確認角色 | 是否構成承諾 | 備註 |
四、工作分解表
| 編號 | 工作 | 交付物 | 執行角色 | 前置條件 | 完成標準 | 審查角色 |
五、漏項檢查
依準備、澄清、執行、品質、溝通、驗收六類列出已包含與可能漏項。
六、三點估算表
| 編號 | O | M | P | 加權值 | 依據 | 信心 | 待驗證 |
若缺少數字，保留空白並產生給執行者的估算問題。
七、工作量彙總
依角色與工作階段彙總，不把等待時間列入工作量。
八、依賴與等待表
| 工作 | 依賴 | 等待對象 | 最早取得 | 最晚需要 | 是否已確認 | 延後影響 |
九、並行與關鍵路徑候選
用文字及表格說明哪些可並行、哪些因前置或資源衝突無法並行。
十、產能換算
| 角色 | 名義產能 | 真實可用產能 | 使用假設 | 對交期影響 |
十一、三種交期情境
| 情境 | 預計範圍／日期區間 | 前提 | 主要風險 | 觸發條件 | 信心 |
十二、希望日期差距
說明希望日期與三種情境的差距，不得自行宣告正式延期。
十三、期限固定時的協商方案
| 方案 | 範圍 | 資源 | 品質／風險 | 預計交期 | 需要誰決定 |
至少比較縮小範圍、分段交付、調整資源、降低其他負荷及維持現狀。
十四、建議方案
列出建議、理由、成立前提、不可犧牲底線及需要核准的事項。
十五、里程碑與預警
| 里程碑 | 目標時間 | 完成證據 | 最晚開始 | 早期警訊 | 觸發後行動 |
十六、重新估算規則
列出範圍、資料、資源、測試、審查與外部依賴的觸發條件。
十七、交期協商訊息
提供：
- 給主管的精簡版
- 給客戶或跨部門的正式版
- 希望日期可達成但有條件版
- 希望日期無法達成的替代方案版
十八、每週預測更新
提供可直接貼入週報的格式：已完成交付物、剩餘工作、目前預測、與上次差異、原因、風險及需要決策。
十九、估算回顧模板
| 項目 | 原估算 | 實際 | 差異 | 原因分類 | 下次調整 |
二十、人工確認清單
列出正式承諾日期、調整範圍、增加人力、降低品質或通知外部前必須確認的內容。
可替換欄位提醒
[希望日期]：保留提出者與用途，避免不知不覺變成正式承諾。[完成標準]：應能由第三方判斷完成，不要只寫「做好」。[本任務可用比例或小時]：使用真實排程，不要填理想狀態。[初步估算]：最好由實際執行者提供；沒有資料就留白。[一般等待時間]：可根據近期實績或審查者確認，不要讓 AI 猜。[品質底線]：例如必要測試、法規審查或資料正確性，不因趕期任意刪除。
實際教學範例
情境
主管問：「三個資料來源的月報自動彙整，兩週內能上線嗎？」
團隊目前只知道：
- 要匯入三種既有報表。
- 需要產出部門摘要與異常清單。
- 使用部門尚未提供兩期完整匿名樣本。
- 開發者每天可投入約 4.5 小時。
- 使用部門審查通常需要一至三個工作日。
- 「兩週」是主管的希望日期，尚未成為正式承諾。
工作分解與三點估算
| 工作 | O | M | P | 加權工時 | 主要不確定性 |
|---|---|---|---|---|---|
| 確認三種報表定義 | 2 | 4 | 8 | 4.3 | 名詞與欄位定義 |
| 建立欄位對照 | 3 | 5 | 10 | 5.5 | 樣本格式差異 |
| 製作匯入與摘要原型 | 6 | 10 | 18 | 10.7 | 例外資料處理 |
| 測試兩期樣本 | 4 | 8 | 16 | 8.7 | 資料品質與漏項 |
| 首輪修正 | 2 | 5 | 10 | 5.3 | 使用者回饋幅度 |
| 合計 | 約 34.5 小時 | 不含等待時間 |
以每天真實可投入 4.5 小時計算，基準工作量約需 7.7 個工作日。這還不包含樣本等待、使用部門審查及可能的第二輪修正。
三種交期情境
| 情境 | 估計 | 前提 | 信心 |
|---|---|---|---|
| 順利 | 約 8～9 個工作日 | 樣本首日取得、規則穩定、一次審查通過 | 低至中 |
| 基準 | 約 11～12 個工作日 | 樣本正常取得、一次主要修正、審查 2 日 | 中 |
| 不利 | 約 15～16 個工作日 | 樣本延遲、格式差異大、需要第二輪驗證 | 中 |
這些區間是規劃情境，不是統計保證；實際日期仍應依工作日、資源與資料到位時間換算。
如果兩週不能動
| 方案 | 作法 | 代價或風險 |
|---|---|---|
| A：縮小範圍 | 先支援一種主要報表，另兩種排第二階段 | 第一階段覆蓋率較低 |
| B：分段交付 | 先交人工匯入＋摘要，異常規則後補 | 初期仍需人工檢查 |
| C：增加支援 | 增加一位熟悉資料規則的人協助對照與測試 | 需確認交接成本與可用時間 |
| D：降低其他負荷 | 暫停開發者本週部分例行工作 | 其他任務延後，需主管決定 |
| E：維持完整範圍 | 接受基準 11～12 工作日或不利情境 | 無法保證兩週內完成 |
可直接使用的主管回覆
依目前已知範圍，實作與測試的基準工作量約 34.5 小時；以每日可投入 4.5 小時計算，單純工作量約 7.7 個工作日。由於匿名樣本尚未取得，另有使用部門審查與修正等待，完整範圍的基準預測為 11～12 個工作日，目前信心為中。若兩週為固定期限，建議先支援主要報表並完成摘要流程，其他格式與進階異常規則列入第二階段。待樣本到位並完成首輪欄位盤點後，我們會更新預測，再確認正式承諾日期。
AI 不能自行做的事
- 不能因主管說兩週，就倒推每項工作必須幾小時。
- 不能假設使用部門一定一天內回覆。
- 不能把 34.5 小時直接除以兩人，宣稱四天完成。
- 不能刪除測試與驗收，卻仍說交付品質相同。
- 不能將基準預測寫成團隊正式承諾。
常見錯誤、隱私與使用注意事項
常見錯誤
- 讓 AI 直接回答多久： 沒有範圍與歷史資料，只會得到漂亮的猜測。
- 先有期限再分配工時： 這是排願望，不是估算。
- 只估製作不估驗證： 測試、審查、修正與發布都是交付的一部分。
- 把等待當工作量： 容易錯估人力成本；但若完全忽略等待，又會低估交期。
- 過度拆解： 每項只剩幾分鐘，管理成本反而大於好處。
- 悲觀值無上限： 悲觀情境應是合理不利狀況，不是所有災難同時發生。
- 重複加緩衝： 三點估算已含風險，專案緩衝又把相同風險算一次。
- 多人等比例加速： 知識型工作存在交接、同步與整合成本。
- 忽略其他工作： 人員不是只做這一個專案。
- 用完成百分比推算： 最後的整合與驗收可能比前 80% 更難。
- 低信心卻報精確日期： 小數點不會讓未知變少。
- 把預測當績效承諾： 會鼓勵隱藏風險與刪減品質。
資料隱私
- 貼入 AI 前移除姓名、Email、客戶名稱、合約金額、內部報價及帳號。
- 不要上傳密碼、API 金鑰、內網位址、未公開漏洞或可識別設備的敏感資訊。
- 人員產能可能涉及績效與健康資訊，僅使用必要的角色與可用時數。
- 客戶合約、法務期限、財務預測及人事排程應使用組織核准的工具與流程。
使用注意事項
- 三點估算與加權公式只是輔助，不代表真實機率分布。
- 最接近工作的執行者應參與估算，不能完全由管理者或 AI 代估。
- 正式交期需確認範圍、資源、依賴、品質底線與變更規則。
- 估算不是一次性文件；範圍或證據改變後應重新預測。
- 對外協商時，清楚區分「希望、預測、目標、承諾」。
- 若涉及安全、法規、資安或重大財務影響，不能以趕期為由刪減必要控制。