如何用 AI 建立項目狀態報告：對照獲批基準核實進度與偏差

用 AI 建立項目狀態報告，要把獲批基準與實際數值和預測作比較。每項偏差和決定都必須由負責人核實。

先建立受控的 AI 流程。狀態報告是一份註明日期的管理紀錄，它不能取代已批准的項目計劃，亦不是在結果出來之後改寫基準的地方。

關鍵要點

• 先固定報告週期、狀態日、受眾、決策需要和報告負責人。
• 把基準、實際和預測數值放在不同欄位，並附上證據和可信程度。
• 風險、現有問題、依賴、變更和決定分開記錄。
• 只使用預先批准的 RAG 定義和升級門檻。
• 保留未知資料和分歧，而不是要 AI 把敘述寫得看似完整。
• 規定要有具名的數據負責人和一位最終問責的批准人。

用 AI 建立項目狀態報告要證明甚麼？

一份有用的報告要回答三個問題：在狀態日項目處於甚麼位置；這個位置與已批准的計劃相比如何；現在需要哪項獲授權的決定或行動。英國政府職能標準 GovS 002 把管治、規劃、控制和可追溯性視為互相關連的項目交付實務。［1］

報告應能按其來源紀錄冊重現。審核人需要看到每項陳述分別由哪個進度計劃版本、成本分類帳、品質紀錄、效益量度、風險登記冊、問題紀錄和變更紀錄支持。沒有這些引用的潤飾敘述，並不是可靠的控制手段。

不要混淆不同的時間概念：

欄位	含義	例子
基準	用作比較的已批准承諾	已批准的里程碑日期為 9 月 30 日
實際	狀態日經核實的情況	驗收測試於 10 月 3 日完成
預測	現時以證據為本的預期	預計 10 月 18 日部署
偏差	按已批准規則計算的差異	比基準遲 18 日
可信程度	預測所依據證據的質素	中等；供應商日期未確認

GAO 把可靠的進度計劃形容為一種工具，用來對照已批准的計劃量度表現，並了解延誤和變更的影響。［2］因此，預測不是經修訂的基準。更改基準必須經過項目正式的變更控制程序。

先收集甚麼？

就確切的報告截數點建立一份來源紀錄冊。既快又安全的做法，是請每位數據負責人提交一份簡短的結構化更新，而不是把一大堆未經控制的文件直接交給模型。

最少收集：

• 已批准的範圍、里程碑、進度、預算、品質和效益基準；
• 實際完成的證據和已驗收的交付成果；
• 附有假設和可信程度的預測日期或成本；
• 來自權威登記冊的未結風險、問題、依賴和變更要求；
• 自上次報告以來已作出的決定，以及現在需要作出的決定；
• 過往的承諾、負責人、到期日和完結證據；
• 機構的 RAG 定義和升級政策。

現行的 Gate 2 審查指引要求控制進度、風險、問題、依賴、限制、決定、成本、效益和正式變更。［3］請使用與你的管治制度相關的欄位；不要未經調整負責人和審批安排，便把政府的檢查清單照搬到私營項目。

記錄衝突，而不是悄悄把它們化解。如果交付負責人說某個里程碑已完成，但品質部門仍未驗收，便同時保留這兩項事實，並把驗收標為未完成。如果財務部和項目辦公室使用不同的成本截數日，便標示兩個日期，並詢問問責的負責人報告應採用哪一個基礎。

刪除報告決策不需要的資料。個人資料、合約敏感細節、登入憑證、原始客戶紀錄和私人通訊應留在已批准的系統。只要可行，便只給模型提供最小化的摘錄或合成例子。

如何設計狀態報告範本？

每個報告週期一項紀錄，每個重要狀態項目一行。以下這組欄位可令遺漏一目了然：

分組	必填欄位
控制	報告 ID、版本、週期、狀態日、負責人、審批者
基準	基準 ID、批准日、範圍、里程碑、預算、品質、效益
當前情況	計劃、實際、預測、偏差、可信程度、證據引用
例外	風險、問題、依賴、變更要求、假設
行動	待決事項、行動負責人、期限、升級路徑
審批	數據覆核、質疑紀錄、批准日、分發範圍、變更日誌

就每個狀態範疇，都問同一組嚴謹的問題：批准了甚麼？截至狀態日，經核實的情況是甚麼？之後預期會怎樣？偏差是由哪條規則得出的？答案有甚麼證據支持？誰能更正或批准它？

在為任何項目數值分類之前，先寫好 RAG 規則。例如，機構可以用特定的預測偏差和恢復條件來界定黃色。如果沒有已批准的規則，便展示事實並寫明「未分配評級」，不可讓 AI 根據語氣猜顏色，亦不可讓它自訂門檻。

如何約束 AI？

向 AI 提供報告契約、來源紀錄冊、容許的轉換方式和禁止作出的決定。要求它輸出一份結構化草稿，另加一份例外清單。

有清晰邊界的指令應要求模型：

1. 只使用所提供的紀錄，並保留其識別碼；
2. 區分基準、實際和預測數值；
3. 除非提供了確定性的計算結果，否則不作任何計算；
4. 把無根據或互相衝突的陳述標為 NEEDS_REVIEW；
5. 把風險、問題、依賴、變更和決定分開；
6. 只套用所提供的 RAG 定義；
7. 不引用已批准摘錄以外的任何機密資料；
8. 產生一份證據對照表，把每條摘要主張對應到其來源紀錄。

要明確寫出：不得虛構 RAG 狀態、完成百分比、偏差原因、預測、恢復日期、負責人、批准或決定。模型可以建議較清楚的字眼，但不能把欠缺的證據變成事實。

只要一份草稿，而不是五個具說服力的版本。多個版本會誘使人按自信程度或語氣而非證據來揀選。報告事關重大時，保存提示、模型輸出、來源紀錄冊版本和審核人的修改。

如何核對數值？

在語言模型以外執行確定性的核對。日期、總數、偏差、實獲值指標、門檻和匯總，應由試算表或受控的報告系統以鎖定的公式計算。

就每一項重要紀錄：

1. 把基準數值與某個已批准的基準識別碼對應；
2. 把實際數值與完成、驗收、分類帳或量度紀錄對應；
3. 找出預測背後的假設和負責人；
4. 以已批准的公式重現偏差；
5. 確認報告截數點和數據的新鮮程度；
6. 把現時的預測與上一份報告比較；
7. 以引用的問題、風險、依賴或變更紀錄解釋任何變化。

不要只因十項任務完成了九項，便報告「完成 90%」。各項任務的工作量、關鍵程度、驗收準則或依賴可能都不同。如果項目沒有已批准的進度量度方法，便直接報告已完成和未完成的交付成果。

同樣，只有評級定義容許時，綠色的進度狀態才能與一個未解決的驗收缺陷並存。要把品質例外展示出來，而不是讓一個整體顏色把它抹去。

如何分開例外？

風險是不確定的未來事件；問題是已經發生的事情。依賴是項目所倚靠的事物；變更要求建議修改已批准的基準；決定要求則請獲授權的人作出選擇或批准。把它們合併成一段「關注事項」，會掩蓋責任誰屬和時間。

使用一張精簡的例外表：

類型	證據	影響	負責人	期限／觸發條件	需要的決定
風險	風險紀錄	日後可能的影響	風險負責人	觸發日期	批准應對措施
問題	問題紀錄	現時的影響	問題負責人	解決日期	逾期時升級
依賴	依賴紀錄	所需的輸入／輸出	介面負責人	需要日期	優先次序衝突
變更	變更要求	對基準的擬議影響	變更負責人	委員會會議日期	批准或否決

AI 草稿可以縮短文字，但不能把風險改為問題，不能暗示擬議的變更已獲批准，亦不能把沉默形容為同意。把每一項決定要求與項目的授權安排和管治日程比較。

面向管理層時，先寫決定、按已批准方案衡量的交付信心，以及影響結果的少數例外。只有在底層狀態通過審核之後，才使用管理層摘要流程。

如何批准及更正？

採用三層審核。第一層，由工作流程和數據負責人確認證據、截數日期和計算。第二層，由報告負責人檢查各部分是否一致，並質疑過份樂觀或無根據的字眼。第三層，由問責的決策者批准版本和分發範圍。

審核紀錄應包括：

• 來源紀錄冊和基準的版本；
• 仍未補足的證據缺口，以及由誰接受；
• 數據負責人審核後所作的修改；
• RAG 和升級規則的版本；
• 批准人、批准時間和分發名單；
• 發佈後發出的更正。

不要覆寫已發出的報告。建立一個寫明原因的更正版本，並按政策保留原件。把決定和已批准的變更輸入相關系統，而不只是寫進下一期的敘述。

項目完結後，在另一個經驗總結流程中分析反覆出現的報告缺口。如果報告引發向持份者發放訊息，便把已批准的事實移入一份變更溝通計劃；狀態報告本身不應變成宣傳稿。

攔截哪些錯誤？

出現以下情況時，退回草稿：

• 以最新預測而非已批准的基準來比較實際數值；
• 在沒有引用批准的情況下更改基準；
• 把「未知」變成零、已完成、綠色或按計劃進行；
• 混淆風險、問題、依賴、變更和決定；
• 未檢查時效便重複上一期的敘述；
• 聲稱證據無法證明的原因；
• 指派的負責人沒有相應權限，或仍未接受該行動；
• 以平均值、顏色或籠統的安撫語掩蓋分歧；
• 升級事項遺漏了決定、期限或後果；
• 暴露的敏感來源資料超出決策所需。

NIST 的生成式 AI 設定檔列出的風險包括虛構內容、資料私隱、資訊完整性和人類過度依賴。［4］把流暢的字眼視為需要核實的輸出，而不是項目健康的證明。

總結

• 固定週期、狀態日、受眾、基準和報告規則。
• 向 AI 發出提示之前，收集經最小化、由負責人核實的證據。
• 把計劃、實際、預測、偏差、可信程度和證據分開。
• 保持風險、問題、依賴、變更和決定之間的區別。
• 使用確定性計算和預先批准的 RAG 門檻。
• 只發出經數據負責人和問責批准人審核的版本。

常見問題

只靠會議紀錄可以嗎？

不可以。會議紀錄可以提示可能的更新，但不能證明已批准的基準、實際完成情況、已認可的成本或預測。應先把每項主張與其權威紀錄核對一致。

AI 可選紅黃綠嗎？

只有當它是對經核實的輸入機械地套用已批准的規則，而且結果經獨立核對時才可以。如果規則或輸入欠缺，便不分配評級。

實際與預測有何分別？

實際描述的是狀態日經核實的情況。預測描述的是對未來結果的現時預期，應附上假設和可信程度。

可在報告裏改項目基準嗎？

不能只為了令偏差消失而修改。只有經過項目獲授權的變更控制程序才能更改基準，之後新基準會有自己的識別碼和批准紀錄。

管理層需要多少細節？

包括理解結果、例外、決定、負責人和期限所需的證據。把支持紀錄放在受控附錄或來源系統，而不是以原始細節塞滿摘要。

未知怎樣寫？

標明未知，寫出欠缺的證據及其負責人，說明對決策的影響，並定下解決日期。不要把未知轉為零或有利的狀態。

誰批准？

數據負責人確認各自負責的部分，問責的項目權力方則按管治模式批准整份報告。報告負責人負責統籌，但並不承襲所有批准權。

發出後發現錯呢？

保留已發出的版本，並按紀錄政策發佈一份可追溯的更正或替代版本。悄悄覆寫會破壞審計軌跡，亦可能令讀者使用不同的事實。

免責聲明：本文提供一般性的項目報告資訊。請遵守你所屬機構的管治、會計、紀錄、安全和保證要求。

來源：

1. GOV.UK — Government Functional Standard GovS 002: Project Delivery — https://www.gov.uk/government/publications/project-delivery-functional-standard
2. U.S. Government Accountability Office — Schedule Assessment Guide — https://www.gao.gov/products/gao-16-89g
3. GOV.UK — Gate 2 Review: Delivery Strategy — https://www.gov.uk/government/publications/gate-review-2-delivery-strategy/gate-2-review-delivery-strategy
4. NIST — Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

延伸閱讀

• 建立受控的 AI 使用流程
• 建立項目獲批基準
• 把已覆核指標整理成管理層摘要
• 在交付後記錄經驗
• 為獲批變更規劃溝通