如何用 AI 制訂項目計劃：依賴、估時及負責人逐項核實

要用 AI 制訂項目計劃，應由已批准的項目說明開始，而不是給模型一個空白問題。請 AI 把既定結果拆成交付物、里程碑、依賴、負責人、風險和開放假設；計劃成為基準版本前，再由真正負責工作的人逐項確認依賴與估時。

AI 擅長整理零散筆記、找出缺失欄位和提出不同結構，但除非獲授權的人提供並核實，它不會知道團隊實際產能、審批隊列、供應商周期或隱藏技術限制。PMI 的規劃指引把使命、範圍、持份者、資源、里程碑與風險視為連貫計劃的重要部分。［1］ NIST 亦提醒生成式系統可能自信地輸出錯誤或不一致內容。［2］ 看似合理的排程只能先當作假設。

關鍵要點

• 由獲批項目說明中的結果、範圍、限制和決策負責人開始。
• 先拆可驗收交付物，再列活動和任務。
• 把依賴寫成可確認陳述，並指定確認人。
• AI 生成的工期、人員和次序必須進入假設登記表。
• 每個交付物只有一個最終負責人，並有清晰驗收準則。
• 在確定基準版本前定義範圍、排程和資源變更如何審批。

通用的帶人手覆核的 AI 工作流程仍然適用。本文聚焦一項更具體的交付物：令不確定性足夠可見、團隊能真正挑戰的項目計劃。

交給 AI 的項目說明應包含甚麼？

計劃無法彌補含糊的授權。提示前，準備一份一至兩頁的項目說明，包含以下欄位：

• **問題和期望結果：**項目完結時，甚麼狀況應有所不同？
• **發起人和決策負責人：**誰能批准基準版本和各種取捨？
• **範圍內：**包括的產品、團隊、市場、系統或流程。
• **範圍外：**明確排除、容易順手做進去的相鄰工作。
• **限制：**固定日期、預算上限、政策、技術、合約和質素門檻。
• **已知持份者：**貢獻者、審批人、受影響用戶、營運人員和外部各方。
• **證據：**已批准的研究、會議決定、估算和現有承諾。
• **未知項：**必須保持開放、而不是靠猜測填補的問題。

用精確的名詞。「改善入職流程」不是結果。「在不取消保安審查的前提下，減少新客服人員處理受監督個案前必須完成的步驟」則指明了一個工作流程和一條界線。它仍需可量度的驗收準則，但已給了計劃者可分解的真實對象。

不要把合約、客戶紀錄、憑證、人事細節或保密財務資料上載到未獲批准的服務。只概括計劃所需的內容，把敏感對照資料留在擁有它的系統，並遵守所屬機構批准的資料處理規則。

怎樣由交付物樹出發用 AI 制訂項目計劃？

活動清單看似高效，卻常掩蓋工作存在的理由。先由交付物開始：推動項目邁向結果、可供審查的產出。交付物可以是一份已批准的設計、一個已遷移的資料集、一支受過培訓的營運團隊、一項經測試的整合，或一份已簽署的政策。

要求 AI 只根據項目說明提出交付物樹：

把已批准的結果分解為最少的一組可審查交付物。每項交付物都要說明目的、驗收證據、可能的負責人角色，以及它滿足說明中的哪項要求。不要加入範圍以外的功能或承諾。含糊的項目放進待解決問題清單。暫時不要估算時間。

與發起人和各範疇負責人一同審查這棵樹，留意互相重疊、描述持續活動而非產出，或悄悄擴大範圍的交付物。「每週協調」是一項活動；如項目確實需要，「已批准的整合決策紀錄」才是交付物。

為每項交付物寫下審查者能觀察到的驗收準則。「完成培訓」含糊不清。較好的準則會指明已批准的課程、目標角色、完成紀錄、知識測驗、例外程序，以及接受證據的負責人。準則應描述成功，而不規定不必要的實施細節。

交付物穩定後，再把它們分解為工作包和任務。每項任務都應有明確產出，並只屬於一項交付物。如某項任務同時支援幾項交付物，便界定一項共用的支援性交付物，或把關係寫清楚，而不是重複隱藏的工作。

把里程碑定義為決策或證據點

里程碑不是每一個限期，而是一次有意義的狀態轉變：範圍獲批、設計獲接納、關鍵依賴獲證實、試行獲授權、遷移完成，或營運交接簽署。好的里程碑能讓發起人問：「有甚麼證據容許我們跨過這條界線？」

每個里程碑都要記錄：

• 屆時將成立的狀態；
• 所需的交付物和驗收證據；
• 決策者或審批人；
• 目標時段，以及該日期的來源；
• 阻止跨越的條件；
• 錯過里程碑時會怎樣。

AI 可以把里程碑次序與交付物樹比較，標示缺失的關卡。它不能批准關卡，也不能斷定不完整的證據可以接受。避免使用「第一階段完成」這類里程碑，除非該階段有明確無歧義的產出和驗收負責人。

把外部固定的日期與計算得出的日期分開。監管申報或已預訂的活動可能是固定的；模型建議「設計需要十日」則是未經確認的工期。把兩者混在一起，會令生成的排程看來比實際更確定。

把依賴寫成可驗證主張

依賴是句子，不是箭嘴。把每項依賴寫成：「在條件 A 成立之前，交付物 B 不能開始或完成，原因是 R；由 P 在 D 日期前確認。」這種格式會揭示該依賴屬技術、資源、合約、資訊層面，還是只出於習慣。

這張圖把計劃的流向與確認關卡分開。交付物之間透過明確條件相連；里程碑是證據點；未經核實的工期和關係會留在假設登記表，直至負責人確認。

要求 AI 質疑第一版依賴圖：

根據交付物樹和限制，提出可能的依賴關係。每一項都要引述暗示該依賴的輸入。如依賴屬推斷而非明確陳述，標示為 ASSUMPTION，並寫出應由哪個角色核實。找出可並行的工作和循環依賴。不要分配日期。

然後訪談實際執行這些工作的人。技術主管可能知道兩項任務可以並行；採購可能發現說明中遺漏的交貨周期；營運可能要求上線前進行演練。以已確認的關係更新計劃，並保留決定的來源。

檢查三個陷阱。第一，偽裝成依賴的偏好：「我們一向先完成所有文案再做設計」可能只是習慣，而非必需。第二，遺漏的外部隊列：法律、保安、採購、本地化或供應商審查。第三，資源依賴：兩項並行任務需要同一位專家，因此日程仍然衝突。

誰負責交付物與決策？

每項交付物都需要一位最終負責人，即使有很多人參與。列出五個名字，並不能說明由誰解決歧義。記錄負責人角色、已知時的具體人名、貢獻者、審查人或審批人，以及上報途徑。

AI 可以按模式建議角色，但它不知道誰有權限。使用 OWNER TO CONFIRM 這類佔位符，而不是虛構某個人，或假定某個部門會接受這項責任。擬定的負責人必須同意範圍和驗收準則。

把「執行」和「批准」分開。撰寫遷移計劃的人未必有權授權遷移；估算任務的工程師未必能控制人手分配；想要某項功能的產品經理未必能批准合規例外。在計劃中顯示這些分別。

會議紀錄常包含隱含的分工。用會議記錄轉行動項目流程擷取候選行動，但要與被點名的人確認。會上沉默並不等於接受責任。

用範圍和假設估時

不要問「這個項目要多久？」，而要索取一份團隊可以填寫的估算工作表。每個工作包都要包括範圍依據、估算人、最短／最可能／最長工期、工作量、所需角色、可用性假設、外部等候時間、可信程度，以及參考的同類工作。

AI 可以統一單位、找出缺失的估算，或為已確認的輸入做運算。它亦能提出問題：是否包括審查時間？工期假設的是一個人還是三個人？供應商的回應時間是否與實際動手的工作量分開？即使模型自己的數字不可靠，這些問題仍有價值。

把工作量、工期和等候時間分開。八小時的工作可能因審批而橫跨五日。多加一個人未必能令工期減半。按未確認的可用性計算出的日期，應繼續標示為暫定。

對於數字化的計劃，維護一份結構化的來源表，並使用 AI 試算表分析流程檢查公式、篩選、單位和缺失值。人手重新計算關鍵路徑和預算總額。不要讓一段生成的敘述成為這些數字的唯一紀錄。

建立風險、假設與決策登記表

一份精簡的項目計劃應連結到三份持續更新的登記表：

**風險登記表：**不確定事件、成因、潛在影響、機率與影響的評級方法、觸發跡象、緩解措施、應變方案、負責人和覆核日期。

**假設登記表：**未經核實的陳述、計劃目前為何依賴它、所需證據、確認人、確認日期，以及假設不成立時的影響。AI 生成的工期和依賴在核實前都屬於這裏。

**決策紀錄：**決策、考慮過的選項、準則、審批人、日期、理由和受影響的計劃元素。這可防止模型——或之後的編輯者——悄悄重新打開已定下的取捨。

要求 AI 掃描各登記表與計劃之間的矛盾。例如，某個里程碑依賴供應商，風險登記表卻遺漏供應商延誤；某項範圍排除與某條驗收準則衝突；某項資源假設與會議決定相矛盾。把掃描結果當作問題來源，並逐一核實每個配對。

避免「項目可能延誤」這類籠統風險。寫明因果條件和先行指標：「如數據流程圖未能在 9 月 12 日前獲接納，保安審查可能會晚於預留時段開始。」實際日期必須來自獲授權的排程，而不是模型。

在確定基準版本前設定變更邊界

計劃不是承諾一切不變，而是就「變更如何變得可見」達成的協議。界定哪些變更需要正式批准：範圍增加、驗收準則改變、里程碑移動超出容許範圍、預算改變、新的資料處理方式、供應商變更，或取消控制措施。

變更要求應寫明要求的變更、原因、受影響的交付物、對進度和成本的影響、風險、替代方案、建議和決策負責人。AI 可以整理要求格式並比較版本，但不得批准變更，也不得悄悄改寫基準版本。

為計劃做版本管理。記錄基準日期、批准角色、相關證據和已被取代的版本。不要把一段對話紀錄當作權威計劃。把獲批的成果匯出到團隊的紀錄系統，並控制誰可以編輯。

批准前，按需要召集交付、技術、營運、保安、財務或法律代表，對計劃進行一次質詢。請每位審查者專注於自己的界線。籠統的綜合審查會往往只帶來客氣的認同，卻遺漏專業限制。

計劃何時可以確定為基準版本？

當審查者能從這份成果回答以下所有問題時，計劃便可以確定為基準版本：

• 已批准的結果和範圍是甚麼，排除了甚麼？
• 哪些交付物證明了進展，每項如何驗收？
• 哪些里程碑代表真正的決策或證據關卡？
• 哪些依賴已由誰確認，哪些仍是假設？
• 誰負責每項交付物、審批、風險和待解決問題？
• 哪些日期是固定、計算得出或暫定的？
• 假設不成立或有人提出變更要求時會怎樣？
• 來源證據、登記表和決策紀錄存放在哪裏？

進行一次簡短的桌面推演：某位關鍵負責人無法到位、某家供應商延誤，或某項要求改變。團隊能否在不重建計劃的情況下，找出受影響的交付物和決策途徑？如不能，這個結構只是裝飾，並不可運作。

當項目日後需要一套可重複的操作程序時，只把觀察到並獲批准的流程，用 AI 輔助 SOP 或檢查清單流程轉換出來。計劃描述的是協調推進的變化；SOP 描述的是如何執行一個周期性流程。兩者不應混淆。

常見問題

小型項目也可用 AI 規劃嗎？

可以，但成果要與規模相稱：一頁項目說明、交付物清單、里程碑檢視、負責人表，以及小型的風險／假設紀錄，可能已經足夠。不要只因模型能生成就增加形式。對估算、依賴和審批仍要保持同樣的真實性界線。

AI 能自動生成甘特圖和排程嗎？

它可以按已確認的任務、依賴、日曆和工期整理出甘特圖，但預設並不知道這些輸入。在工作負責人核實之前，把生成的次序和日期標示為暫定，然後在項目的紀錄系統重新計算排程。

如何核實 AI 建議的依賴？

要求模型指出暗示每項依賴的輸入，並標示推斷。與實際執行工作的人以及外部隊列的負責人一同審查。記錄確認人和理由，而不只是一個箭嘴。

每個任務都要一個負責人嗎？

每項交付物都應有一位最終負責人。執行開始時，任務也應有清晰的負責人或角色。貢獻者和審批人可以有多個，但要避免令決策懸而未決的共同負責。

多久更新一次 AI 輔助項目計劃？

當獲批的範圍、證據、估算、負責人、依賴、風險或決策改變時，更新紀錄系統。按項目情況設定覆核節奏，但不要讓周期性的 AI 摘要繞過變更控制，覆寫已批准的基準版本。

哪些項目資訊不應交給 AI？

除非工具和用途獲明確授權，否則不要提供密鑰、憑證、個人紀錄、保密合約、受限財務資料或敏感客戶資料。盡量減少輸入，把詳細的來源紀錄保存在受控系統。

延伸閱讀

• 如何使用 AI 並保留人手覆核
• 如何用 AI 分析試算表
• 如何把會議記錄轉成行動項目
• 如何把流程轉成 SOP 或檢查清單
• 如何核查 AI 答案中的事實
• 將任務計劃用於搬屋安排
• 對照既定基線匯報項目狀況

來源

1. PMI, Section D: Project Planning Guidelines — https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/ugcr-vol-three.pdf?v=140b6f67-0460-4920-b12a-13b965c893b2
2. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 2026 年 8 月 24 日。