AI 專案週報教學:把工作流水帳改成有證據的管理報告

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

為什麼工作做很多,週報卻看不出進度?

不少週報寫滿「開會、討論、追蹤、持續開發」,看得出團隊很忙,卻看不出專案是否真的向前。主管最後只能再問一次:所以目前到底完成到哪?會不會延誤?需要我做什麼?

問題通常不在文字能力,而在資訊結構。活動不等於產出,產出不等於成果,成果也不一定已經產生對專案目標的影響。

生成式 AI 可以快速整理一週的大量紀錄,但如果提示詞只有「幫我寫週報」,它很可能把文字修得順,卻把「已開發」寫成「已完成」,把「預計」寫成「將於某日交付」。真正好用的 AI 週報,必須先建立證據與判斷規則。

一、先有基準,才看得出偏差

週報不是單純描述本週發生什麼,而是比較本週原計畫與實際結果。因此,報告開始前要先確認報告期間、資料截點、有效里程碑、本週原計畫與上週承諾行動。

如果沒有原計畫,「完成三台設備測試」看似正面;但原計畫若是完成五台,就已經出現偏差。反過來,原計畫只是完成基本連線,三台都成功,就可能符合預期。

二、活動、產出、成果與影響要分開

「與供應商開會」是活動;「取得通訊指令清單」是產出;「三台設備完成基本連線」是成果;「可以進入完整指令測試」才是對後續工作的影響。

週報不是不能寫活動,而是不能停在活動。每項重要工作都可以追問:產生了什麼可驗證的東西?它改變了什麼?它對下一步有什麼價值?

三、「完成」至少有七種

開發人員說完成,可能只是程式已寫好;測試人員說完成,可能是測試已執行;使用者說完成,可能是已驗收。

建議把完成拆成已製作、已自檢、已提交、已測試、已驗收、已部署與穩定觀察。如此一來,「標籤功能已製作、待測試」就不會被誤寫成「標籤功能完成上線」。

四、用四格說清楚重要進度

每項重要里程碑都可以用四格表達:計畫、實際、偏差、影響。

例如,原計畫完成三台電子秤全部通訊指令測試;實際完成三台基本連線,但部分指令結果異常;偏差是完整指令測試尚未通過;影響是整合測試開始時間可能延後。

這比「三台都已測試,部分指令還有問題」更容易讓管理者判斷優先順序。

五、綠黃紅灰必須有規則

最危險的綠燈,是團隊沒有足夠資料卻不敢標黃。建議加入灰燈,代表資料不足、無法可靠判斷。

綠燈表示本期里程碑按計畫且不需要額外資源;黃燈代表已有偏差但仍可在容忍範圍修正;紅燈代表關鍵承諾、品質或安全已受影響,需要決策或額外資源。

燈號不是情緒,而是依規則得出的管理訊號。每次變色都要保留原因與日期。

六、把問題、風險、依賴與決策拆開

已發生的阻塞是問題;未來可能造成的影響是風險;需要外部提供資料是依賴;要選擇改期或部分測試則是決策。

如果全部都塞進「風險與問題」欄位,主管很難看出哪一項需要排除、哪一項需要監控、哪一項需要他拍板。

七、下週計畫不能只是願望

「持續開發」「繼續追蹤」幾乎無法驗收。下週計畫應寫成交付物,包含負責角色、期限、前置依賴、完成證據與替代行動。

例如:「完成三台秤剩餘指令測試,保存每台結果與異常清單;若現場參數未取得,先完成可離線驗證部分並在週三升級。」

這樣下週回顧時,才有明確基準。

八、主管最需要看的,是決策請求

一個好的決策請求應說明要決定什麼、為何現在要決定、有哪些選項、交換條件、建議方案、截止時間,以及不決定的影響。

「請主管協助」太模糊;「若參數未在測試日前兩個工作天取得,請決定維持日期做部分測試,或延後等資料齊備」才是可回答的決策題。

九、AI 週報最重要的防錯機制

在發布前,逐句反問:這句話能回到哪個來源?完成是哪個層級?日期是預計、希望、承諾還是實際?百分比的分母是什麼?是否把沉默當同意?是否隱藏了未執行測試?

AI 最適合做的是整理、比對與提醒,不是替團隊美化現況。

讓週報成為管理工具,而不是每週作文

一份好的週報,主管看完不需要再問「所以呢」。他會清楚知道目前狀態、與計畫的差距、最大的風險,以及自己是否需要在某個時間前做決定。

今天可以先從一個小改變開始:把週報裡所有「持續」與「已完成」圈起來。前者補上交付物與期限,後者補上完成層級與證據。你的週報可信度會立刻提升。

行動呼籲

拿出上週週報,選三項最重要的工作,分別寫出「原計畫、實際、偏差、影響」。再請 AI 檢查是否把活動誤寫成成果。這比增加更多文字更有管理價值。

逐步操作

第 1 步:先確認讀者與用途

同一組資料,面向不同讀者要呈現不同深度:

  • 主管版:整體健康度、偏差、前三項風險、需要決策。
  • 執行版:任務、負責人、依賴、期限與完成證據。
  • 客戶版:承諾交付、已確認成果、影響與下一次更新。
  • 團隊版:具體行動、阻塞與協作需求。

版本可以不同,但日期、數字、狀態與正式決議不能不同。

第 2 步:建立本週報告期間與基準

先寫清楚:

  • 報告期間
  • 資料截點
  • 專案目標
  • 本週原計畫
  • 目前有效的里程碑
  • 上週承諾的行動
  • 本次不納入的範圍

沒有基準,就無法判斷超前、正常或落後。

第 3 步:蒐集來源並編號

建議來源包括:

  • WBS 或任務管理系統
  • 測試報告與缺陷清單
  • 會議紀錄與決策台帳
  • 供應商或跨部門回覆
  • 系統紀錄、版本發布與產出檔案
  • 工時、容量與資源安排

每項重要結論保留來源編號。例如「三台設備完成連線測試」應能回到測試紀錄,而不是只有群組訊息。

第 4 步:區分活動、產出、成果與影響

層級 定義 例子
活動 Activity 做了什麼 與供應商開會
產出 Output 產生什麼 取得通訊指令清單
成果 Outcome 改變了什麼 三台電子秤完成基本連線
影響 Impact 對目標的價值 可進入完整指令與異常測試

週報可以保留必要活動,但主要篇幅應放在產出、成果與影響。

第 5 步:為「完成」建立層級

建議將完成拆成:

  1. 已製作
  2. 已自檢
  3. 已提交
  4. 已測試
  5. 已驗收
  6. 已部署
  7. 已穩定觀察

「功能已寫完」只能代表已製作,不能直接寫成「功能完成」。

第 6 步:用計畫、實際、偏差與影響描述進度

每個重要里程碑至少回答:

  • 原計畫是什麼?
  • 截至資料截點實際完成什麼?
  • 差異是多少?
  • 為什麼有差異?
  • 對後續造成什麼影響?
  • 需要採取什麼行動?

例:原計畫完成三台秤全部通訊指令;實際三台完成連線,但部分指令仍失敗;偏差是完整指令測試尚未完成;影響是整合測試無法如期開始。

第 7 步:建立有規則的狀態燈號

示例:

狀態 判定規則
綠 本期里程碑按計畫,無需額外決策或資源
黃 已有偏差或依賴風險,但仍可在既有容忍範圍內修正
紅 關鍵里程碑、品質、安全或正式承諾已受影響,需要決策或額外資源
灰 資料不足,不能可靠判斷

灰燈比假綠燈更誠實。燈號變化要附原因與日期。

第 8 步:把問題、風險、依賴與決策分流

  • 問題:已發生,需要排除。
  • 風險:未來可能發生,需要預警與應變。
  • 依賴:需要外部人員、資料、設備或核准。
  • 決策:需要有權者選擇。

例如「供應商尚未提供 I/O 位址且已逾期」是問題;「若再延後三天,通訊測試可能錯過進廠窗口」是風險;「需要供應商提供資料」是依賴;「是否改期或先測其他設備」是決策。

第 9 步:檢查數字、分母、日期與單位

AI 產出後,逐項核對:

  • 件數是否有正確分母
  • 百分比與百分點是否混用
  • 日期是預計、目標、承諾還是實際
  • 工時與日曆天是否混用
  • 金額是否含稅、幣別與期間一致
  • 測試通過率是否排除未執行項目

不要把「已測 3 台」自動改寫成「3 台全部通過」。

第 10 步:顯示不確定性與信心

每個重要預測可標示:

  • 高信心:依賴已確認、近期表現穩定、有足夠緩衝
  • 中信心:仍有一項關鍵假設或外部依賴
  • 低信心:資料不足、依賴未承諾或測試尚未開始

預測不是承諾。若前提改變,要寫出重新預測的條件。

第 11 步:把下週計畫寫成可驗證交付物

不要只寫「持續開發」「繼續追蹤」。改寫成:

完成三台電子秤剩餘指令測試,保存每台測試結果與異常清單;若現場參數未取得,先完成可離線驗證部分並在週三升級。

每項計畫包含:交付物、負責角色、期限、依賴、完成證據及失敗時的替代行動。

第 12 步:把決策需求放到前面

一個完整的決策請求應包含:

  • 要決定什麼
  • 為什麼現在要決定
  • 選項與交換條件
  • 建議方案與依據
  • 決策截止時間
  • 不決定的影響
  • 決策者

不要把「請主管協助」當成決策題。

第 13 步:加入本週變化與趨勢

至少比較:

  • 本週與上週燈號
  • 里程碑預測是否改變
  • 新增與關閉問題
  • 風險是否升高或降低
  • 範圍、資源與依賴是否變更

一份單週快照不一定能看出問題,連續趨勢才能辨識慢性惡化。

第 14 步:產出三種長度

建議同時產生:

  • 30 秒版:一句狀態、三項變化、一個決策。
  • 一頁版:主管可在一分鐘內掌握。
  • 完整版:保留證據、任務、風險與附錄。

三種版本共用同一份事實底稿,避免各說各話。

第 15 步:發布前進行反向查證

要求 AI 或人工逐句檢查:

  • 這句話能回到哪個來源?
  • 「完成」是哪一個完成層級?
  • 日期是什麼性質?
  • 是否把沉默當同意?
  • 是否隱藏了未執行測試?
  • 誰需要採取什麼行動?

若無法回答,就應標示待確認或刪除。

可直接複製的完整提示詞

【角色】
你是一位審慎、重視證據與管理決策的專案週報分析助手。你要協助我把零散的任務、測試、會議及溝通紀錄整理成可信週報,但不得誇大成果、捏造數字、替任何人承諾日期,或把未驗證內容寫成完成。

【任務】
1. 依資料截點整理本週實際成果,不要只列活動。
2. 比較本週原計畫、實際、偏差、原因、影響與修正行動。
3. 將完成狀態區分為已製作、已自檢、已提交、已測試、已驗收、已部署、穩定觀察。
4. 區分問題、風險、依賴與待決策事項。
5. 檢查日期、數字、分母、百分比、單位與來源是否一致。
6. 依我提供的規則判定綠、黃、紅、灰燈,並說明變化原因。
7. 將下週計畫改寫成可驗證交付物。
8. 產出主管30秒版、一頁版與執行完整版。
9. 找出矛盾、缺口及最多7個高價值確認問題。

【專案基本資料】
- 專案名稱:[專案名稱]
- 報告期間:[起訖日期]
- 資料截點:[日期時間]
- 專案目標:[可驗證成果]
- 目前有效里程碑:[里程碑與日期]
- 本週原計畫:[項目]
- 上週承諾行動:[項目]
- 主要讀者:[主管/客戶/跨部門/團隊]
- 本次不納入範圍:[範圍]

【輸入資料格式】
來源編號|日期|類型|工作項目|原始內容|狀態|負責角色|證據位置
[S01]|[日期]|[任務/測試/會議/決策/Email/系統紀錄]|[項目]|[內容]|[狀態]|[角色]|[連結或備註]

本週紀錄:
[貼上任務、會議、測試與溝通資料]

已知問題與風險:
[貼上內容]

下週草案:
[貼上內容]

【狀態燈號規則】
- 綠:本期里程碑按計畫,無需額外決策或資源。
- 黃:已有偏差或依賴風險,但仍可在既有容忍範圍內修正。
- 紅:關鍵里程碑、品質、安全或正式承諾已受影響,需要決策或額外資源。
- 灰:資料不足,無法可靠判斷。

【限制與判斷規則】
1. 不得捏造日期、數字、分母、來源、負責人、完成狀態或決策。
2. 「已討論」「已開會」「已追蹤」只能算活動,不得直接寫成成果。
3. 「已開發」不等於已測試;已測試不等於已驗收;已驗收不等於已部署。
4. 「預計」「希望」「目標」「承諾」「實際」必須分開標示。
5. 口頭回報標示為口頭回報,不得改寫成已驗證。
6. 未執行、阻塞與不適用的測試不得算入通過率分母,除非正式定義另有規定。
7. 沉默、被副本或參與會議不代表同意。
8. 狀態燈號必須引用判定規則與證據,不能只靠語氣判斷。
9. 若資料互相衝突,同時列出並標示待確認,不得自行選擇有利版本。
10. 涉及安全、資安、法規、個資、重大財務或對外承諾時,標示需人工複核。
11. 資料不足時使用灰燈或待確認,不要為了完整而猜測。

【輸出格式】
A. 主管30秒版
- 整體狀態與一句理由
- 本週三項最重要變化
- 最大問題/風險
- 需要決定的一件事與期限

B. 一頁式主管摘要
- 整體健康度
- 里程碑摘要
- 本週成果與證據
- 主要偏差及影響
- 前三項問題/風險
- 決策需求
- 下週焦點

C. 計畫對照表
項目|本週原計畫|實際結果|完成層級|偏差|原因|影響|修正行動|來源

D. 里程碑與狀態燈號
里程碑|目標日期|目前預測|燈號|與上週差異|判定依據|信心|重新預測條件

E. 問題、風險、依賴、決策分流
編號|類型|描述|影響|負責角色|期限/觸發條件|下一步|來源

F. 決策請求
決策題|背景事實|選項|交換條件|建議與依據|決策者|截止時間|不決定的影響

G. 下週可驗證計畫
優先序|交付物|負責角色|期限|前置依賴|完成證據|替代行動

H. 趨勢與變更
- 新增、升高、降低、關閉的問題與風險
- 里程碑預測變化
- 範圍、資源、決策與依賴變更

I. 資料品質檢查
敘述|疑點|需要的證據|風險|建議修正

J. 執行完整版
依序包含成果、詳細任務、問題、風險、依賴、決策、下週計畫與附錄來源。

K. 高價值確認問題
最多7題,依「回答後最能改變週報判斷」排序。

【最後自我檢查】
- 是否把活動誤寫成成果?
- 是否把已製作誤寫成已完成?
- 是否每個重要結論都有來源?
- 是否正確區分預計、承諾與實際日期?
- 是否有正確分母、單位與期間?
- 是否把問題、風險、依賴及決策混在一起?
- 是否清楚說明誰需要在何時做什麼?
- 是否忠實呈現未完成、阻塞與資料不足?

可替換欄位速查

  • [專案名稱]:例如「原料秤量系統導入」
  • [資料截點]:週報中所有狀態的共同時間基準
  • [本週原計畫]:來自上週週報或正式 WBS
  • [主要讀者]:決定摘要深度與決策資訊排序
  • [證據位置]:測試紀錄、版本、核准信或文件編號

實際教學範例

原始流水帳

  • 秤量系統持續開發中,功能包含標籤與原料標示卡。
  • 三台電子秤都已測試,部分指令還有問題。
  • 滅菌釜通訊評估可以走 Modbus TCP。
  • 等客戶提供參數與 I/O 位址。
  • 下週持續測試電子秤。
  • 下週進行 UI 說明。

這些內容不是錯,但主管仍很難判斷:到底完成什麼?哪裡偏差?會影響什麼?需要誰決定?

整理後的主管30秒版

專案整體為黃燈。標籤與原料標示卡仍在開發;三台電子秤已完成基本連線,但部分指令尚未通過,因此不能寫成完整測試完成。滅菌釜已確認可評估 Modbus TCP 路徑,但客戶參數與 I/O 位址尚未取得,屬外部依賴。下週重點是完成可執行指令測試、確認失敗項目,以及在 UI 說明後凍結本輪畫面範圍。若參數未在進廠測試前取得,需要決定改期或先執行不依賴參數的項目。

計畫、實際、偏差與影響

項目 本週原計畫 實際結果 完成層級 偏差與影響
標籤功能 完成本輪開發 持續開發,未提供驗證證據 進行中 無法判定是否可進入測試
原料標示卡 完成本輪開發 持續開發,未提供驗證證據 進行中 需補版本與完成標準
電子秤通訊 三台完成指令測試 三台完成基本測試,部分指令異常 已測試但未全部通過 整合測試開始時間可能受影響
滅菌釜通訊 確認介面 初步評估可走 Modbus TCP 已評估、待驗證 缺少參數及 I/O 位址,無法安排完整測試

問題、風險、依賴與決策分流

類型 描述 下一步
問題 部分電子秤指令測試失敗 建立指令、設備、輸入、預期、實際結果清單
依賴 客戶需提供滅菌釜參數與 I/O 位址 確認交付格式、窗口與期限
風險 若資料未在進廠日前取得,完整通訊測試可能延後 設定取得門檻與替代測試範圍
決策 資料未到時要改期,或先進行其他測試 由專案負責人於門檻前決定

證據式成果改寫

錯誤:

三台電子秤測試完成。

較精確:

三台電子秤均已執行基本通訊測試;連線可建立,但部分指令結果與預期不符,完整通過狀態待下週複測。證據:測試紀錄 T-01 至 T-03。

錯誤:

滅菌釜可用 Modbus TCP 串接。

較精確:

依目前介面確認結果,Modbus TCP 為候選串接方式;尚待取得參數與 I/O 位址並完成實機驗證,因此不能標示為已完成串接。

下週可驗證計畫

優先序 交付物 前置依賴 完成證據 替代行動
1 三台秤剩餘指令測試結果與異常清單 設備可用、測試時段 每台測試紀錄及問題編號 先完成可離線重現的指令分析
2 UI 說明與確認事項清單 使用者代表出席 會議紀錄、畫面項目與待決事項 未確認項目標示待決,不自行凍結
3 滅菌釜通訊測試準備包 參數與 I/O 位址 接線、參數、測試案例與窗口清單 資料未到則提出改期與部分測試兩方案
4 標籤與標示卡版本驗證 開發版本可交付 版本號、自檢結果與待測範圍 明確列出未完成項目

決策請求示例

若客戶未在進廠測試前兩個工作天提供滅菌釜參數與 I/O 位址,請專案負責人決定:A. 保留進廠日期,只測電子秤與可獨立項目;B. 延後進廠,等待資料齊備後一次測試。A 可維持部分進度,但會增加一次後續測試;B 可提高單次完整性,但會影響原排程。請於門檻日下班前決定,以便安排人員與設備。

主管一頁版範例

整體狀態:黃燈

原因: 三台秤已完成基本測試,但部分指令未通過;滅菌釜串接仍缺參數與 I/O 位址。

本週實際成果:

  • 三台電子秤均完成基本通訊測試。
  • 已定位需要複測的指令範圍。
  • 滅菌釜確認 Modbus TCP 為候選方案。
  • UI 說明會已排定,待形成確認事項清單。

主要偏差:

  • 電子秤尚未達到「全部指令通過」。
  • 滅菌釜尚未達到「可執行實機測試」。

需要決策:

  • 若外部資料未如期取得,選擇部分測試或改期。

下週焦點:

  • 完成剩餘指令複測與異常清單。
  • 完成 UI 說明並區分已確認與待決事項。
  • 取得或升級追蹤滅菌釜參數與 I/O 位址。

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

常見錯誤

1. 把忙碌當成果

開會、追蹤、溝通都是必要活動,但週報必須說明產出與影響。

2. 所有項目都寫完成

未測試、未驗收或未部署的工作,不能只因開發者說完成就標綠。

3. 用百分比掩蓋關鍵缺口

「完成 90%」可能剩下最困難的整合、資安或驗收。改列剩餘交付物。

4. 把預計日期寫成承諾日

日期性質要明確,且保留前提與信心。

5. 只報問題,不報影響與下一步

管理者需要知道是否要介入、何時介入及有哪些選項。

6. 狀態燈號每週重置

燈號要保留歷史與變化原因,才能看出趨勢。

7. 只報好消息

週報不是績效宣傳。隱藏阻塞會讓團隊錯過處理窗口。

8. 複製上週內容但未更新截點

日期、狀態與風險可能已失效;每次發布都要更新資料截止時間。

9. AI 補齊不存在的證據

來源不明就標示待確認,不得生成看似合理的測試編號或決議。

10. 主管要求藏在附件

需要決策的事項應放在摘要前段,並寫明期限與不決定的影響。

資料隱私

送入 AI 前,請移除或代碼化:

  • 客戶與員工個資
  • 未公開合約、價格、成本與營收
  • 系統帳密、Token、內網位址與安全設定
  • 未公開缺陷、弱點與事故細節
  • 個人績效、申訴、健康與人事資訊
  • 未公告產品、客戶與上市時程

如公司未核准外部 AI,請使用匿名摘要或公司允許的環境。

使用注意事項

  • 正式週報仍需由專案負責人確認後發布。
  • 客戶版不得透露內部責任歸屬、未核准成本或敏感風險細節。
  • 同一事實在不同版本可調整深度,不能調整成相反結論。
  • 發布後若發現重大錯誤,應保留修訂紀錄,不要無痕覆蓋。
  • 安全、法規、品質與重大承諾事項應由專業角色複核。
  • 週報應促進決策,不應用來公開責備個人。

留言

這個網誌中的熱門文章

空心菜的故事

BURBERRY CEO 2000 年至今 上任卸任原因列表

家有中等生