AI 專案週報教學:把工作流水帳改成有證據的管理報告
原內容日期:2026-09-29。本文為既有教學內容補發;範例依原文標示使用,實際權限與規則請以所屬組織核定資料為準。
為什麼工作做很多,週報卻看不出進度?
不少週報寫滿「開會、討論、追蹤、持續開發」,看得出團隊很忙,卻看不出專案是否真的向前。主管最後只能再問一次:所以目前到底完成到哪?會不會延誤?需要我做什麼?
問題通常不在文字能力,而在資訊結構。活動不等於產出,產出不等於成果,成果也不一定已經產生對專案目標的影響。
生成式 AI 可以快速整理一週的大量紀錄,但如果提示詞只有「幫我寫週報」,它很可能把文字修得順,卻把「已開發」寫成「已完成」,把「預計」寫成「將於某日交付」。真正好用的 AI 週報,必須先建立證據與判斷規則。
一、先有基準,才看得出偏差
週報不是單純描述本週發生什麼,而是比較本週原計畫與實際結果。因此,報告開始前要先確認報告期間、資料截點、有效里程碑、本週原計畫與上週承諾行動。
如果沒有原計畫,「完成三台設備測試」看似正面;但原計畫若是完成五台,就已經出現偏差。反過來,原計畫只是完成基本連線,三台都成功,就可能符合預期。
二、活動、產出、成果與影響要分開
「與供應商開會」是活動;「取得通訊指令清單」是產出;「三台設備完成基本連線」是成果;「可以進入完整指令測試」才是對後續工作的影響。
週報不是不能寫活動,而是不能停在活動。每項重要工作都可以追問:產生了什麼可驗證的東西?它改變了什麼?它對下一步有什麼價值?
三、「完成」至少有七種
開發人員說完成,可能只是程式已寫好;測試人員說完成,可能是測試已執行;使用者說完成,可能是已驗收。
建議把完成拆成已製作、已自檢、已提交、已測試、已驗收、已部署與穩定觀察。如此一來,「標籤功能已製作、待測試」就不會被誤寫成「標籤功能完成上線」。
四、用四格說清楚重要進度
每項重要里程碑都可以用四格表達:計畫、實際、偏差、影響。
例如,原計畫完成三台電子秤全部通訊指令測試;實際完成三台基本連線,但部分指令結果異常;偏差是完整指令測試尚未通過;影響是整合測試開始時間可能延後。
這比「三台都已測試,部分指令還有問題」更容易讓管理者判斷優先順序。
五、綠黃紅灰必須有規則
最危險的綠燈,是團隊沒有足夠資料卻不敢標黃。建議加入灰燈,代表資料不足、無法可靠判斷。
綠燈表示本期里程碑按計畫且不需要額外資源;黃燈代表已有偏差但仍可在容忍範圍修正;紅燈代表關鍵承諾、品質或安全已受影響,需要決策或額外資源。
燈號不是情緒,而是依規則得出的管理訊號。每次變色都要保留原因與日期。
六、把問題、風險、依賴與決策拆開
已發生的阻塞是問題;未來可能造成的影響是風險;需要外部提供資料是依賴;要選擇改期或部分測試則是決策。
如果全部都塞進「風險與問題」欄位,主管很難看出哪一項需要排除、哪一項需要監控、哪一項需要他拍板。
七、下週計畫不能只是願望
「持續開發」「繼續追蹤」幾乎無法驗收。下週計畫應寫成交付物,包含負責角色、期限、前置依賴、完成證據與替代行動。
例如:「完成三台秤剩餘指令測試,保存每台結果與異常清單;若現場參數未取得,先完成可離線驗證部分並在週三升級。」
這樣下週回顧時,才有明確基準。
八、主管最需要看的,是決策請求
一個好的決策請求應說明要決定什麼、為何現在要決定、有哪些選項、交換條件、建議方案、截止時間,以及不決定的影響。
「請主管協助」太模糊;「若參數未在測試日前兩個工作天取得,請決定維持日期做部分測試,或延後等資料齊備」才是可回答的決策題。
九、AI 週報最重要的防錯機制
在發布前,逐句反問:這句話能回到哪個來源?完成是哪個層級?日期是預計、希望、承諾還是實際?百分比的分母是什麼?是否把沉默當同意?是否隱藏了未執行測試?
AI 最適合做的是整理、比對與提醒,不是替團隊美化現況。
讓週報成為管理工具,而不是每週作文
一份好的週報,主管看完不需要再問「所以呢」。他會清楚知道目前狀態、與計畫的差距、最大的風險,以及自己是否需要在某個時間前做決定。
今天可以先從一個小改變開始:把週報裡所有「持續」與「已完成」圈起來。前者補上交付物與期限,後者補上完成層級與證據。你的週報可信度會立刻提升。
行動呼籲
拿出上週週報,選三項最重要的工作,分別寫出「原計畫、實際、偏差、影響」。再請 AI 檢查是否把活動誤寫成成果。這比增加更多文字更有管理價值。
逐步操作
第 1 步:先確認讀者與用途
同一組資料,面向不同讀者要呈現不同深度:
- 主管版:整體健康度、偏差、前三項風險、需要決策。
- 執行版:任務、負責人、依賴、期限與完成證據。
- 客戶版:承諾交付、已確認成果、影響與下一次更新。
- 團隊版:具體行動、阻塞與協作需求。
版本可以不同,但日期、數字、狀態與正式決議不能不同。
第 2 步:建立本週報告期間與基準
先寫清楚:
- 報告期間
- 資料截點
- 專案目標
- 本週原計畫
- 目前有效的里程碑
- 上週承諾的行動
- 本次不納入的範圍
沒有基準,就無法判斷超前、正常或落後。
第 3 步:蒐集來源並編號
建議來源包括:
- WBS 或任務管理系統
- 測試報告與缺陷清單
- 會議紀錄與決策台帳
- 供應商或跨部門回覆
- 系統紀錄、版本發布與產出檔案
- 工時、容量與資源安排
每項重要結論保留來源編號。例如「三台設備完成連線測試」應能回到測試紀錄,而不是只有群組訊息。
第 4 步:區分活動、產出、成果與影響
| 層級 | 定義 | 例子 |
|---|---|---|
| 活動 Activity | 做了什麼 | 與供應商開會 |
| 產出 Output | 產生什麼 | 取得通訊指令清單 |
| 成果 Outcome | 改變了什麼 | 三台電子秤完成基本連線 |
| 影響 Impact | 對目標的價值 | 可進入完整指令與異常測試 |
週報可以保留必要活動,但主要篇幅應放在產出、成果與影響。
第 5 步:為「完成」建立層級
建議將完成拆成:
- 已製作
- 已自檢
- 已提交
- 已測試
- 已驗收
- 已部署
- 已穩定觀察
「功能已寫完」只能代表已製作,不能直接寫成「功能完成」。
第 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,請使用匿名摘要或公司允許的環境。
使用注意事項
- 正式週報仍需由專案負責人確認後發布。
- 客戶版不得透露內部責任歸屬、未核准成本或敏感風險細節。
- 同一事實在不同版本可調整深度,不能調整成相反結論。
- 發布後若發現重大錯誤,應保留修訂紀錄,不要無痕覆蓋。
- 安全、法規、品質與重大承諾事項應由專業角色複核。
- 週報應促進決策,不應用來公開責備個人。
留言