跳到主要內容
METHOD · 專案與任務管理

AI 活動/專案結案檢討

檢討不用每一項都講一遍:先對事前目標,只追落差最大的一項,每一項都要做出留、改或砍的決定。

直接拿快速版 Prompt ↓三分鐘版:濃縮成 5 步 ↓外部佐證 1 則 ↓
情境:專案與任務管理也用於:會議與協作也用於:決策與問題解決配方:兩份比差異難度:進階|要先備料起手工具:ChatGPT
三分鐘版濃縮成 5 步;要細節再往下讀
  1. 收兩樣東西:事前寫下的目標與實際數字(每個數字標明來源),以及過程紀錄與回饋。達成率先在試算表算好。
  2. AI 排出實際對目標表:只用貼上的數字,事前沒定目標的標「事前未定目標」,平台或廠商後台的數字標「自報」。
  3. AI 只對達成率最低的一項問為什麼,每一層引用紀錄;找不到依據就停下來寫待查。
  4. AI 對每一項提出留、改、砍或資料不足的建議,並列出 3 到 5 條下次要改的做法。
  5. 檢討會只討論最大落差與每一項的決定,由人拍板、指派負責人。
這一篇用的是兩份比差異這一招——兩組資料先對齊口徑,機械比對差異,AI 只分類不解釋,查不出依據的一定標出來。
同一招還能做這幾件事(共 8 篇):
這是專案與任務管理情境下的方法之一(共 6 個)· 看這個情境全部 →
一、這是什麼三十秒判斷關不關你的事

先確認這一篇解的是不是你的問題。看完這兩節如果覺得不像,就不用再往下讀——省下的時間比讀完更值錢。

01解決的工作問題

活動或專案結束後的檢討會,常見的開法是每個人輪流講:哪裡辛苦、哪裡做得不錯、下次可以更好。講完大家都同意,下一次照樣辦。檢討要有用,先把事前寫下的目標和實際結果攤成一張表,只追達成率最低的那一項,再對每一項做出留、改或砍的決定。AI 適合排表、對照紀錄、整理成初稿,但它有兩個習慣要先防:一是自己算數字、補數字,二是為了把為什麼問滿五層,用聽起來合理的推測接上去。所以達成率先在試算表算好,每一層為什麼都要引用得出紀錄,引用不出來就停。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

  • 活動或專案已經結束,手上有實際結果的數字。
  • 事前有寫下目標,就算只有幾項也可以。
  • 有過程紀錄或回饋可以對照,例如會議紀錄、問卷、電話抽訪。

什麼情況下別用

拿來評個人表現或打考績
檢討不能拿來追究個人責任。原因寫到做法和流程;一旦變成找誰的錯,下一次大家只會交好看的數字。
事前完全沒有目標
沒有目標就沒有落差可追。可以先做一次事後補定目標的檢討,但每一項都要標明是事後補的,下一次開工前先寫目標。
要它直接寫成對上的結案報告
這一頁是給團隊做決定用的初稿。要交給長官的版本,用寫報告的做法另外整理。

誰會用到

PM
寫結案報告前先做這一步。最大落差那一節,通常就是結案報告裡最該寫清楚的一段。
行銷
活動與投放的檢討最適合。各管道的數字先分清楚是自己量的、還是平台後台自報的,再來比。
主管
主持檢討會時,只把時間花在最大落差和每一項的決定,其他項目看表就好。
營運
例行活動每辦一次就檢討一次,把上一次的改進事項放進這一次的輸入,看有沒有做到。

所屬工作情境

二、整件事怎麼跑先看圖,再看逐步

先用一張圖抓全貌,再看逐步展開。圖看不懂沒關係,下一節會把每一步實際在做什麼、誰做,一條一條講清楚。

03流程圖

這張圖是整篇的骨架:輸入 → 步驟 → 困難點 → AI/Agent/Tool 介入 → 人工檢查 → 產出。紅框是最常出事的位置,綠框是不能下放的人工檢查點,粗框是中止條件。後面每一節都是在展開圖上的某一格。

AI 活動/專案結案檢討:先對目標,只追最大落差,每一項做決定
AI 活動/專案結案檢討:先對目標,只追最大落差,每一項做決定直向流程圖。輸入是事前寫下的目標、實際數字與來源、過程紀錄與回饋,達成率先在試算表算好。第一步由人收齊資料,標明目標出處與每個數字的來源。第二步由 AI 排實際對目標表,事前沒定目標的不評達成,平台自報的數字另外標。第三步由 AI 只對達成率最低的一項問為什麼,每一層引用紀錄,沒有依據就停下來寫待查。第四步由 AI 對每一項提出留、改、砍或資料不足的建議,並列出下次要改的做法。第五步是人工檢查點,檢討會只討論最大落差與每一項的決定,由人拍板並指派負責人。輸出是檢討結論與改進清單。右側標示四個困難點:目標是事後補的、平台自報數字被當成成效、原因硬湊到第五層並寫成某人的錯、每一項都講卻沒有決定。中止條件是要求判斷誰該負責或拿來打考績時不執行。檢查點有退回線回到追原因的步驟,表示補查後重跑。補查後重跑INPUT / 輸入事前目標 + 實際數字與來源 + 過程紀錄與回饋達成率先在試算表算好HUMAN / 人工步驟人收齊資料,標明目標出處與每個數字的來源AI / AI 介入AI 排實際對目標表:未定目標不評、自報另標AI / AI 介入AI 只對最大落差問為什麼,每層引用紀錄,沒有依據就停AI / AI 介入AI 提出每一項留、改、砍或資料不足,列下次要改的做法CHECKPOINT / 人工檢查檢討會只談最大落差與每項決定,人拍板、指派負責人OUTPUT / 產出檢討結論與改進清單RISK / 困難點目標是事後補的,每一項都剛好達標RISK / 困難點平台自報的數字被當成成效RISK / 困難點原因硬湊到第五層,寫成某人的錯STOP / 中止條件要求判斷誰該負責、拿來打考績 → 不執行RISK / 困難點每一項都講一遍,沒有一項做出決定
看圖重點:這張圖只有一個 AI 步驟在找原因,而且只針對達成率最低的那一項。找不到下一層依據的時候,就停在那一層,交給人去查。右邊第一個紅框最容易被忽略:目標要是事前寫的,事後補的目標會讓每一項都剛好達標,後面整張表就沒有意義。
純文字流程表(手機/螢幕閱讀器建議看這張)
AI 活動/專案結案檢討:先對目標,只追最大落差,每一項做決定(純文字流程表)
序類型/角色流程步驟這一步的困難點/中止條件
1Human事前目標 + 實際數字與來源 + 過程紀錄與回饋
達成率先在試算表算好
—
2Human人收齊資料,標明目標出處與每個數字的來源
困難點/風險目標是事後補的,每一項都剛好達標
3AIAI 排實際對目標表:未定目標不評、自報另標
困難點/風險平台自報的數字被當成成效
4AIAI 只對最大落差問為什麼,每層引用紀錄,沒有依據就停
困難點/風險原因硬湊到第五層,寫成某人的錯
失敗與中止條件要求判斷誰該負責、拿來打考績 → 不執行
5AIAI 提出每一項留、改、砍或資料不足,列下次要改的做法—
6Checkpoint檢討會只談最大落差與每項決定,人拍板、指派負責人
困難點/風險每一項都講一遍,沒有一項做出決定
7Output檢討結論與改進清單—

回流線:檢討會只談最大落差與每項決定,人拍板、指派負責人 → AI 只對最大落差問為什麼,每層引用紀錄,沒有依據就停(補查後重跑)

Mermaid 原始碼(貼進 Mermaid Live 或 draw.io 可再編輯)
可直接複製,改成你自己的流程
flowchart TD
    in1(["<b>Human</b><br/>事前目標 + 實際數字與來源 + 過程紀錄與回饋<br/><small>達成率先在試算表算好</small>"])
    s1["<b>Human</b><br/>人收齊資料,標明目標出處與每個數字的來源"]
    a1[/"<b>AI</b><br/>AI 排實際對目標表:未定目標不評、自報另標"/]
    a2[/"<b>AI</b><br/>AI 只對最大落差問為什麼,每層引用紀錄,沒有依據就停"/]
    a3[/"<b>AI</b><br/>AI 提出每一項留、改、砍或資料不足,列下次要改的做法"/]
    c1{{"<b>Checkpoint</b><br/>檢討會只談最大落差與每項決定,人拍板、指派負責人"}}
    o1(["<b>Output</b><br/>檢討結論與改進清單"])
    r1>"<b>Risk</b><br/>目標是事後補的,每一項都剛好達標"]
    r2>"<b>Risk</b><br/>平台自報的數字被當成成效"]
    r3>"<b>Risk</b><br/>原因硬湊到第五層,寫成某人的錯"]
    x1[/"<b>Stop</b><br/>要求判斷誰該負責、拿來打考績 → 不執行"\]
    r4>"<b>Risk</b><br/>每一項都講一遍,沒有一項做出決定"]

    in1 --> s1
    s1 --> a1
    a1 --> a2
    a2 --> a3
    a3 --> c1
    c1 --> o1
    s1 -.->|風險| r1
    a1 -.->|風險| r2
    a2 -.->|風險| r3
    a2 ==>|中止| x1
    c1 -.->|風險| r4
    c1 -.->|補查後重跑| a2

    classDef clsIn fill:#FFFFFF,stroke:#2C4459,stroke-width:2px,color:#141E2B
    classDef clsHuman fill:#FBFCFD,stroke:#7A8CA0,stroke-width:2px,color:#141E2B
    classDef clsAI fill:#FFF6EA,stroke:#DE9A45,stroke-width:2px,color:#141E2B
    classDef clsAgent fill:#FDEBD2,stroke:#B87A2E,stroke-width:2px,color:#141E2B
    classDef clsTool fill:#EDF2F6,stroke:#2C4459,stroke-width:2px,color:#141E2B
    classDef clsCheck fill:#E8F2EC,stroke:#3F7A5A,stroke-width:2px,color:#123024
    classDef clsOut fill:#141E2B,stroke:#141E2B,stroke-width:2px,color:#F2F6F9
    classDef clsRisk fill:#FCEFEA,stroke:#C0552F,stroke-width:2px,color:#5E2110
    classDef clsStop fill:#F7E1DB,stroke:#8E2F17,stroke-width:3px,color:#5E2110
    class in1 clsIn;
    class s1 clsHuman;
    class a1 clsAI;
    class a2 clsAI;
    class a3 clsAI;
    class c1 clsCheck;
    class o1 clsOut;
    class r1 clsRisk;
    class r2 clsRisk;
    class r3 clsRisk;
    class x1 clsStop;
    class r4 clsRisk;

04完整步驟圖的文字版,逐步展開

上面三分鐘版那幾步,這裡逐步展開:每一步誰做、做完會有什麼。

序誰做步驟與說明
1Human收資料
目標(含出處)、實際數字(含來源)、過程紀錄;達成率在試算表先算好;事後補的目標標明。→ 檢討資料包
2AI實際對目標表
只用貼上的數字排表;事前未定目標的項目不評達成;平台或廠商自報的數字另外標。→ 實際對目標表
3AI追最大落差
只對達成率最低的一項問為什麼;每一層引用一則紀錄;沒有依據就停,寫待查;原因寫到做法。→ 落差原因鏈(含待查)
4AI每項建議與下次要改
每一項給留、改、砍或資料不足的建議與依據;列 3 到 5 條下次要改的做法,負責人寫待指派。→ 建議表 + 改進清單
5Human檢討會決定
只討論最大落差與每一項的決定;人拍板、指派負責人與期限;待查的那一層指定誰去查。→ 檢討結論
三、動手做備料 → 指令 → 產出 → 工具

這一區是真的動手:先備料、再貼指令、然後對照產出應該長什麼樣。手上是哪一支 AI 都做得完,差別寫在最後的工具那一節。

05開始前要準備什麼標「必要」的沒備齊就先別開始

事前寫下的目標必要
企劃書、專案計畫或開工會議紀錄裡的目標,附上出自哪一份文件、哪一天寫的。
實際數字與來源必要
每個數字寫明從哪裡來:報名後台、簽到表、CRM、平台後台。達成率先在試算表算好。
過程紀錄與回饋必要
會議紀錄、問卷、電話抽訪、同仁的觀察。原因的每一層都要從這裡找依據。
上一次檢討的改進事項可選
例行活動或同類專案,把上次說要改的放進來,看這次做到沒有。
成本或人力投入可選
判斷某一項值不值得留的時候用,例如一個攤位占了幾位同仁多久。

餵進去的東西要長這樣

目標與實際(含目標出處、每個實際數字的來源、試算表算好的達成率)+過程紀錄與回饋。人名改成職稱或代號。

  • 目標寫明出處:哪一份文件、哪一天。事後補的標「事後補定」。
  • 每個實際數字寫來源;平台或廠商後台算的數字屬於自報。
  • 達成率在試算表算好再貼,AI 不計算。
  • 過程紀錄一條一行,寫明是誰的紀錄或哪一份回饋。
  • 不放同仁的考核資料或個人評價。
【目標與實際】
活動:11/8 新品說明會(台中場);目標取自 10/1 的活動企劃書;檢討會 11/25。
達成率由試算表計算。
| 項目 | 目標 | 實際 | 達成率 | 實際數字來源 |
|---|---|---|---|---|
| 報名人數 | 120 | 134 | 112% | 報名表後台匯出 |
| 實際出席 | 90 | 54 | 60% | 現場簽到表 |
| 會後問卷回收 | 50 | 47 | 94% | 問卷系統 |
| 攤位試用登記 | 30 | 21 | 70% | 攤位登記表 |
| 會後兩週內詢價 | 15 | 10 | 67% | 業務 CRM |
| 粉專活動貼文觸及 | (企劃書沒寫) | 8,200 | — | 粉專後台 |

【過程紀錄與回饋】
- PM 紀錄:報名確認信只在報名當下寄一次,活動前沒有再寄提醒。
- PM 紀錄:攤位由 2 位同仁顧一整天。
- 攤位登記表:21 位登記者中,18 位本來就已報名說明會。
- 會後電話抽訪(業務):打給 20 位報名未到者,接通 12 位;7 位說「忘記了」,3 位說「當天臨時有事」,2 位說「以為是線上活動」。
- 報名頁:標題只寫「新品說明會」,地點寫在第三段。
- 詢價登記沒有記錄客戶是從哪一段活動來的。

06Prompt(快速/完整/進階)

A 快速版貼上就能用;B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足;C 進階版是拿去建 GPT/Skill/Agent 的系統指令,預設收起來,要用再點開。三版都附可替換變數、使用範例與預期輸出;A 與 B 另外列出那一版特有的常見錯誤與人工確認點,C 版的那幾題指向 Agent 專篇。

三種版本共通的紅線
三版都不適合用在
  • 要拿檢討結果評個人表現或打考績時。
A
A. 快速版

活動剛結束,檢討會前想先有一份實際對目標表與原因初稿。

適合的工具ChatGPTClaude
👇 直接複製,{ } 換成你的內容
以下是一場活動(或一個專案)結束後的資料。請幫我整理檢討初稿:
1. 實際對目標表:每一項列目標、實際、達成率、實際數字的來源。只用我貼的數字,不要自己計算或補數字;事前沒有定目標的項目標「事前未定目標」,不評達成;平台或廠商後台自己算的數字標「自報」。
2. 找出達成率最低的一項,只對這一項問「為什麼」:每一層都要引用我貼的紀錄或回饋;引得到紀錄、但紀錄沒寫出因果的,標「關聯待確認」;資料裡找不到下一層的依據就停下來,寫「待查」,不要硬湊到五層。原因寫到做法或流程,不寫成某個人的錯。
3. 每一項給一個建議:留、改、砍,或「資料不足,先不決定」,並寫出依據。這只是建議,決定由我們的檢討會做。
4. 列出 3 到 5 條下次要改的做法,每條寫成做得到的動作;負責人一律寫「待指派」。
5. 最後列出你沒有做的事。
不得評論任何人的表現,不得推測資料裡沒有的原因。
目標與實際(含來源):{貼上};過程紀錄與回饋:{貼上}

可替換變數

變數要換成什麼
{貼上}目標、實際、試算表算好的達成率、每個實際數字的來源。
{貼上}過程紀錄與回饋,一條一行,寫明是誰的紀錄或哪一份回饋。
完整使用範例(照這樣填)
(照母提示詞)

【目標與實際】
活動:11/8 新品說明會(台中場);目標取自 10/1 的活動企劃書;檢討會 11/25。
達成率由試算表計算。
| 項目 | 目標 | 實際 | 達成率 | 實際數字來源 |
|---|---|---|---|---|
| 報名人數 | 120 | 134 | 112% | 報名表後台匯出 |
| 實際出席 | 90 | 54 | 60% | 現場簽到表 |
| 會後問卷回收 | 50 | 47 | 94% | 問卷系統 |
| 攤位試用登記 | 30 | 21 | 70% | 攤位登記表 |
| 會後兩週內詢價 | 15 | 10 | 67% | 業務 CRM |
| 粉專活動貼文觸及 | (企劃書沒寫) | 8,200 | — | 粉專後台 |

【過程紀錄與回饋】
- PM 紀錄:報名確認信只在報名當下寄一次,活動前沒有再寄提醒。
- PM 紀錄:攤位由 2 位同仁顧一整天。
- 攤位登記表:21 位登記者中,18 位本來就已報名說明會。
- 會後電話抽訪(業務):打給 20 位報名未到者,接通 12 位;7 位說「忘記了」,3 位說「當天臨時有事」,2 位說「以為是線上活動」。
- 報名頁:標題只寫「新品說明會」,地點寫在第三段。
- 詢價登記沒有記錄客戶是從哪一段活動來的。
預期輸出範例(拿到的東西應該長這樣)
【一、實際對目標】
| 項目 | 目標 | 實際 | 達成率 | 實際數字來源 |
|---|---|---|---|---|
| 報名人數 | 120 | 134 | 112% | 報名表後台 |
| 實際出席 | 90 | 54 | 60% | 現場簽到表 |
| 會後問卷回收 | 50 | 47 | 94% | 問卷系統 |
| 攤位試用登記 | 30 | 21 | 70% | 攤位登記表 |
| 會後兩週內詢價 | 15 | 10 | 67% | 業務 CRM |
| 粉專活動貼文觸及 | 事前未定目標 | 8,200 | 不評 | 粉專後台(自報) |

【二、最大落差:實際出席(60%)】
第一層:為什麼出席只有 54 人?→ 電話抽訪接通的 12 位報名未到者中,7 位說「忘記了」〔會後電話抽訪〕
第二層:為什麼會忘記?→ 報名確認信只在報名當下寄一次,活動前沒有再寄提醒〔PM 紀錄〕。關聯待確認:紀錄裡有這件事,但沒有寫它就是忘記的原因,請檢討會確認。
第三層:為什麼活動前沒有提醒?→ 資料裡沒有依據,停在這裡。待查:提醒是漏做,還是原本就沒有排進流程。
注意:抽訪只打了 20 位、接通 12 位,只能當線索,不能當成所有未到者的比例。另有 2 位說「以為是線上活動」,報名頁的地點寫在第三段,兩者有沒有關係資料不夠,列為待查。

【三、每一項的建議(決定由檢討會做)】
| 項目 | 建議 | 依據 |
|---|---|---|
| 報名人數 | 留 | 達成 112% |
| 實際出席 | 改 | 見第二節:活動前沒有提醒 |
| 會後問卷回收 | 留 | 達成 94% |
| 攤位試用登記 | 改 | 21 位登記者中 18 位本來就已報名說明會,看不出攤位帶來新的人;攤位由 2 位同仁顧一整天〔攤位登記表、PM 紀錄〕。要不要整個砍,請檢討會決定 |
| 會後兩週內詢價 | 資料不足,先不決定 | 未達(67%),但詢價登記沒有記錄客戶從哪一段活動來,看不出原因 |
| 粉專活動貼文觸及 | 資料不足,先不決定 | 事前未定目標,且是平台自報 |

【四、下次要改的做法】
1. 除了報名確認信,活動前再寄提醒;寄幾次、什麼時候寄由檢討會決定。負責人:待指派
2. 報名頁標題與第一段寫清楚是實體活動與地點。負責人:待指派
3. 詢價登記加一欄「從哪一段活動來的」。負責人:待指派
4. 粉專觸及若要算成效,企劃書先寫目標。負責人:待指派

【我沒有做的事】
- 沒有自己計算或補任何數字,達成率照你貼的。
- 沒有推測活動前沒寄提醒的原因。
- 沒有評論任何人的表現。
- 沒有替你決定攤位要不要整個砍。

常見錯誤用法

  • 目標沒寫出自哪一份文件、哪一天。事後才補的目標混進來,每一項都會剛好達標。
  • 叫它「順便幫我算一下達成率」。它算錯你不一定看得出來,換算請在試算表做。
  • 要它「一定要問滿五個為什麼」。後面幾層會變成它自己想的原因。
  • 把同仁的名字和個人表現貼進去,請它分析誰該負責。
這一版另外不適合

沒有額外的,看上面「三種版本共通的紅線」那一段就好。

缺少資料時怎麼辦

沒有過程紀錄時,AI 要明講「沒有紀錄可以引用」,原因鏈只寫第一層看得到的現象,其餘標待查。不要讓它用常見原因補上。

這一版另外要人確認
  • 確認目標是事前寫的,標明出處。
  • 檢討會上決定每一項與負責人。
B
B. 完整實戰版

跨部門的專案結案、或同類活動每季都辦,要對上一次的改進事項,並排出檢討會的議程。

適合的工具ChatGPTClaude
👇 直接複製,{ } 換成你的內容
# 角色
你是結案檢討的整理者。你的工作是把目標、實際結果與過程紀錄整理成檢討初稿,讓檢討會把時間花在做決定。你不計算數字、不推測原因、不評論任何人。

# 背景
- 活動或專案:{名稱或代號}
- 性質:{活動/專案結案/例行活動第幾次}
- 目標出處:{哪一份文件、哪一天}
- 檢討會時間:{多久}
- 這次要追的落差:{達成率最低的項目/延誤最多的里程碑}

# 可以使用的資料
只有【目標與實際】【里程碑】【過程紀錄與回饋】【上次改進事項】四段。你對這類活動的一般印象、你覺得「通常」的原因,一律不得寫成原因。

# 不可以做的事(違反任何一條就是失敗)
1. 不得自行計算或補任何數字;達成率、延誤天數照我給的。
2. 不得把事後補定的目標當成事前目標來比。
3. 原因鏈每一層都要引用一則紀錄;沒有就停,寫待查。
4. 不得寫出任何人的名字、不得評論個人表現。
5. 不得替檢討會做決定,只能給建議與依據。

# 處理步驟
1. 上次改進事項對帳:每一條標「這次做了/沒做/看不出來」,並引用紀錄。
2. 實際對目標表:標出事前未定目標、事後補定、自報。
3. 里程碑:計畫日期與實際日期照抄,延誤的標出來,不推測原因。
4. 依背景指定的落差類型,找達成率最低的一項或延誤最多的里程碑,只對它問為什麼;引得到紀錄、但紀錄沒寫出因果的,標「關聯待確認」。
5. 每一項給留、改、砍或資料不足的建議與依據。
6. 下次要改的做法 3 到 5 條,負責人寫待指派。
7. 依檢討會時間排議程:最大落差與決定事項放前面,其他項目只看表。

# 輸出格式
## 一、上次改進事項對帳
## 二、實際對目標
## 三、里程碑
## 四、最大落差的原因鏈
## 五、每一項的建議
## 六、下次要改的做法
## 七、檢討會議程
## 八、我沒有做的事

【目標與實際(含來源、達成率)】
{貼上}

【里程碑(計畫日期/實際日期)】
{貼上或留白}

【過程紀錄與回饋】
{貼上}

【上次改進事項】
{貼上或留白}

可替換變數

變數要換成什麼
{名稱或代號}對外名稱敏感時用代號。
{活動/專案結案/例行活動第幾次}例行活動才有上次改進事項可以對帳。
{哪一份文件、哪一天}目標的出處,事後補的就寫事後補定。
{多久}會議時間決定議程能排幾項討論。
{達成率最低的項目/延誤最多的里程碑}一次只追一條原因鏈,由你指定追哪一種。
完整使用範例(照這樣填)
背景填法示例:活動=新品說明會(台中場);性質=例行活動第 3 次;目標出處=10/1 的活動企劃書;檢討會時間=一小時;這次要追的落差=達成率最低的項目。目標與實際照 A 版的表格貼上。
【上次改進事項】(上次檢討會紀錄原文)
1. 報名確認信之外,活動前再寄提醒。
2. 報名頁寫清楚實體活動與地點。
3. 詢價登記加一欄「從哪一段活動來的」。
【里程碑】
- 報名頁上線:計畫 10/6,實際 10/13。
- 活動前提醒信寄出:計畫 11/6,實際未寄。
預期輸出範例(拿到的東西應該長這樣)
與 A 版的差別:多出「上次改進事項對帳」、里程碑與檢討會議程。以這個範例來說,上次說要改的「活動前再寄提醒」,里程碑寫著實際未寄,對帳會標成「沒做」;A 版表格裡的報名頁標題與詢價登記也還是舊做法,另外兩條同樣標「沒做」。議程把討論時間集中在最大落差與這三條,其他項目只看表。

常見錯誤用法

  • 上次改進事項留白。例行活動最常見的問題就是同一件事每次都說要改。
  • 同時追達成率最低和延誤最多兩條原因鏈。一次只追一條,另一條下次再追。
  • 議程照項目順序排。討論時間會被排在前面、達標的項目吃掉。
這一版另外不適合

沒有額外的,看上面「三種版本共通的紅線」那一段就好。

缺少資料時怎麼辦

上次改進事項留白時,AI 要明講「沒有上次的改進事項可以對帳」,並在第六節提醒這次的改進清單要存下來,下次檢討時貼進來。

這一版另外要人確認
  • 指定這次要追的是達成率最低的項目還是延誤最多的里程碑。
  • 會後把決定與負責人寫回紀錄。
C
C. 進階版(做成結案檢討助手)

部門每個月都有活動或專案要結案,做成助手讓來源標示與停止規則固定,不會因為趕時間被省略。

適合的工具自訂 GPT/Claude ProjectClaude Skill
👇 直接複製,{ } 換成你的內容
# 你是誰
你是「結案檢討助手」。使用者貼上目標、實際數字、過程紀錄與上次改進事項,你整理成檢討初稿。你不計算、不推測、不評論任何人。

# 你的資料來源
只有使用者這次貼上的內容,以及建置時附上的兩份文件:檢討格式、部門的數字來源規則(哪些來源算自己量的、哪些算自報)。

# 絕對規則(違反就是失敗)
1. 數字與達成率照使用者給的,不自行計算。
2. 每個實際數字都標來源;依數字來源規則標出自報。
3. 只對一項追問原因;每一層引用紀錄,沒有就停,寫待查。
4. 不寫人名、不評論個人表現。
5. 每一項給建議,不做決定。

# 條件判斷(依序檢查,先中的先套用)
1. 使用者要求分析是誰的責任、或要拿來評考績 → 回覆「檢討只寫做法與流程;個人表現不在這份檢討的範圍」,其餘照常整理。
2. 目標沒有寫出處 → 每一項標「目標出處不明」,並在最上方提醒先確認是不是事前定的。
3. 實際數字沒有來源 → 標「來源不明」,不列入最大落差的判斷。
4. 過程紀錄裡找不到任何一條跟最大落差有關 → 原因鏈只寫表上看得到的落差,其餘標待查,並提醒補紀錄。
5. 使用者要求寫成給長官的報告 → 回覆「這份是團隊決定用的初稿;對上的版本請在檢討會決定後另外整理」。

# 每次回覆的格式
【實際對目標】
【最大落差的原因鏈】
【每一項的建議】
【下次要改的做法】
【我沒有做的事】(固定:未計算數字、未推測原因、未評論個人)

# 固定結尾
每次回覆最後一行固定加註:「留、改、砍與負責人請在檢討會決定;待查項目請指定專人查證,由 {權責} 追蹤。」

# 建置參數
檢討格式:{附檔}
數字來源規則:{附檔}
權責:{職稱}

可替換變數

變數要換成什麼
{附檔}檢討格式、數字來源規則兩份,建置時上傳為知識檔案。
{職稱}誰追蹤待查項目與改進事項。
完整使用範例(照這樣填)
建置時上傳兩份文件。上線前用幾份舊的檢討資料測過,其中刻意放幾種陷阱:一份目標沒有寫出處、一份只有平台自報數字、一份過程紀錄跟最大落差完全無關、一份要求「分析是誰的責任」,確認它分別標目標出處不明、標自報、原因鏈只寫落差並標待查、拒絕評個人。
預期輸出範例(拿到的東西應該長這樣)
與 B 版的差別:來源標示與停止規則固定在助手裡,趕時間的時候也不會省略;拒絕評個人那一條寫成固定回覆,主持人不用每次自己擋。
固化成助手是另一件工程,這一頁不重講

下面這幾題每個方法都一樣,站上各有一篇:

07產出應該長什麼樣拿到的東西要長這樣

實際對目標表、最大落差的原因鏈、每一項的建議、下次要改的做法、我沒有做的事。

完成品:同一場活動的兩種檢討

【版本一:叫 AI「幫我寫這場活動的檢討」】

本次說明會整體成效良好,報名人數超標,顯示市場對新品興趣濃厚。出席率略低,主要原因可能是天候與交通因素,建議未來加強宣傳。粉專觸及 8,200,曝光效果佳。整體而言團隊表現優異,下次可再接再厲。

這份檢討的問題:
1. 「天候與交通因素」在資料裡找不到。
2. 「加強宣傳」不是做得到的動作,也沒有負責人。
3. 粉專觸及沒有事前目標,又是平台自報,被當成成效。
4. 攤位那一項完全沒提。
5. 沒有任何一項做出留、改、砍的決定。

─────────────────────────────
【版本二:照規則整理】

最大落差:出席 60%。接通的 12 位報名未到者中 7 位說「忘記了」〔抽訪〕;報名確認信只寄一次、活動前沒提醒〔PM 紀錄,關聯待確認〕;為什麼沒提醒:待查。
建議:出席,改;攤位,改(21 位登記者中 18 位本來就已報名);詢價,資料不足;粉專觸及,不評。
下次要改:活動前寄提醒;報名頁寫清楚實體活動與地點;詢價登記加來源欄。負責人待指派。

─────────────────────────────
【差別在哪】

版本一讀起來比較正面,但原因是猜的、建議做不到。版本二每一句都指得出依據,散會前就知道要改哪裡。
輸出格式規格(要照著做的人再展開)
  • 表格的數字與達成率照輸入,不自行計算。
  • 原因鏈每一層附出處;紀錄沒寫出因果的標關聯待確認;沒有出處就停,寫待查。
  • 每一項都有建議:留、改、砍或資料不足。
  • 下次要改的做法 3 到 5 條,負責人寫待指派。
  • 不出現任何人的名字或個人評價。
## 一、實際對目標
| 項目 | 目標 | 實際 | 達成率 | 實際數字來源 |
|---|---|---|---|---|
| 實際出席 | 90 | 54 | 60% | 現場簽到表 |
| 攤位試用登記 | 30 | 21 | 70% | 攤位登記表 |
| 粉專活動貼文觸及 | 事前未定目標 | 8,200 | 不評 | 粉專後台(自報) |
(其餘各項照輸入列出)

## 二、最大落差:實際出席
第一層:接通的 12 位報名未到者中,7 位說「忘記了」〔電話抽訪〕
第二層:活動前沒有再寄提醒〔PM 紀錄〕;關聯待確認
第三層:待查(提醒是漏做,還是沒排進流程)

## 三、每一項的建議
- 實際出席:改
- 攤位試用登記:改(21 位登記者中 18 位本來就已報名,看不出攤位帶來新的人;要不要整個砍,請檢討會決定)
- 會後兩週內詢價:資料不足,先不決定

## 四、下次要改的做法
1. 活動前加寄提醒。負責人:待指派
2. 報名頁寫清楚實體活動與地點。負責人:待指派
3. 詢價登記加來源欄。負責人:待指派

## 五、我沒有做的事
- 未計算數字、未推測原因、未評論個人。

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議,不是限定。

工具什麼時候用為什麼注意
ChatGPT ↗起手
檢討會前整理實際對目標表與原因鏈初稿
活動剛結束,想在檢討會前出一份初稿實際對目標表、原因鏈與建議表一次整理出來。它會順手幫你算達成率或補一個說得通的原因,要在提示詞裡禁止。
Claude ↗
專案很長、會議紀錄很多時
專案很長,紀錄很多一次貼進多份會議紀錄與回饋,逐層找原因的依據。紀錄裡有同仁姓名與客戶資料,貼入前改成職稱或代號。
試算表
達成率先在試算表算好,AI 只讀不算
算達成率目標、實際、達成率在試算表算好再貼,AI 只讀不算。達成率的分母是目標,不是上一個階段的人數;出席率除以報名人數是另一個指標,不要混在同一欄。
四、不要做錯這幾關不下放

這一區是踩過的坑與該守的線。標「不下放」的步驟請不要交給 AI 決定;Checklist 是拿來驗收的,不是拿來勾好看的。

09會卡住與會做錯的地方

會卡住的地方(流程困難點)

事後補的目標
看到結果才寫目標,每一項都剛好達標,檢討沒有東西可以談。
自報數字當成果
平台後台的觸及數字很漂亮,但那是平台自己算的,跟你要的結果不一定有關。
原因硬湊五層
第三層開始沒有紀錄可引,AI 用合理的推測接上,最後一層寫成某人不夠用心。
每項都講、沒有決定
會開了兩小時,每一項都討論過,散會時沒有一項說要留還是砍。

會做錯的地方(常見失敗方式)

目標事後才補

結果出來才寫目標,每一項都剛好達標。

怎麼修目標標明出自哪一份文件、哪一天;事後補的標「事後補定」,不跟事前目標混在一起比。

自報數字當成果

平台後台的觸及數字很漂亮,被寫成成效。

怎麼修實際數字分成自己量的與自報的;事前沒定目標的不評達成。

原因硬湊到第五層

後面幾層沒有紀錄,AI 用推測接上,最後一層寫成某人不夠用心。

怎麼修每一層引用紀錄,找不到就停在那一層寫待查;原因寫到做法。

每一項都講、沒有決定

會開完,每一項都討論過,沒有一項說要留還是砍。

怎麼修會議只討論最大落差與每一項的決定,其他項目看表。

10人工把關與安全限制

AI/Agent/Tool 介入在哪幾步

流程位置誰做什麼/怎麼做
排表階段AI排實際對目標表
只用使用者貼的數字與達成率,不自行計算;事前未定目標與自報數字分別標出。
追原因階段AI對最大落差問為什麼
每一層引用一則紀錄;找不到就停在那一層並寫待查;不寫個人的錯。
建議階段AI提出每項建議與改進清單
每項附依據;資料不夠的寫資料不足;負責人一律寫待指派。

這幾關不下放

目標是不是事前寫的
只有你知道目標是哪一天寫進哪一份文件。事後補的要標出來,不然每一項都會剛好達標。
每一項的決定
留、改、砍由檢討會決定,AI 的建議只是起點。砍掉一項做法常牽涉到人力和預算,要由有權責的人拍板。
待查的那一層誰去查
原因鏈停在待查的地方,要指定一個人去查,下次檢討前回報。

安全與權限限制

同仁表現不進 AI
不要把考核、個人評價或誰負責哪一段貼進去請它分析;名字改成職稱或代號。
名單與客戶資料
報名名單、詢價客戶含個資,貼入前去識別化;檢討只需要統計後的數字。
內部檢討不外流
初稿裡的待查與原因鏈是內部討論用,對外說明另外整理。

11Checklist 與驗收標準

做的時候逐項打勾

    做完了才檢查:全部成立才算完成

    1. 每個實際數字都標了來源,自報的另外標出。
    2. 目標標明出處,事後補的已標出。
    3. 事前沒定目標的項目沒有被評達成。
    4. 達成率來自試算表,AI 沒有自行計算。
    5. 只對達成率最低的一項追問原因,每一層都有出處。
    6. 找不到依據的那一層寫了待查,並有人負責去查。
    7. 原因寫到做法,沒有寫成某個人的錯。
    8. 每一項都有留、改、砍或資料不足的決定,由檢討會拍板。
    9. 下次要改的做法有負責人。
    五、延伸把流程走一遍,然後往下一步

    先用一個示範情境把流程從頭走一遍,再看具名機構真的做過的事,最後決定下一步往哪走。

    12示範情境

    攤位那一項,是表排出來之後才看到的

    這是示範情境,不是真實個案:作者為了把上面的流程走一遍而寫的設想,人物、數字與結果都是設定。真的有人做過的案例,看下面「真的有人這樣做過」。

    設想的狀況:一個行銷團隊辦完一場新品說明會,檢討會原本的議程是每個人報告自己負責的部分。整理成實際對目標表之後,出席只達成 60%,是落差最大的一項;另一個原本沒人提的地方也浮上來:攤位登記的 21 位裡,有 18 位本來就已報名說明會。

    AI 負責什麼
    • 照試算表的達成率排表,粉專觸及標成事前未定目標、平台自報,不評。
    • 只對出席追問為什麼:引用電話抽訪與 PM 紀錄走到第二層,第二層標關聯待確認;第三層沒有紀錄,停下來寫待查。
    • 提醒抽訪只接通 12 位,只能當線索。
    • 攤位那一項建議「改」並寫出依據,要不要整個砍留給檢討會決定。
    人負責什麼
    • 確認目標取自 10/1 的企劃書,不是事後補的。
    • 達成率先在試算表算好再貼。
    • 檢討會只討論出席與攤位兩項,其他項目看表。
    • 指派一位同仁去查提醒信是漏做還是沒排進流程。

    照著走完會得到:檢討會的時間花在兩件事上:出席為什麼不到、攤位要不要繼續。散會時每一項都有決定,待查的那一層也有人負責。

    本例為說明用的設想情境,不是真實個案;本站不提供檢討之後下一次活動改善幅度的量化資料。

    真的有人這樣做過外部佐證 1 則

    以下都是具名機構的公開案例,每個來源都經過連結實測。數字只寫來源講得出來的;來源沒講的,這裡就寫未公開。 標「相近工作」的 1 則,做的不是同一件工作——機制相通可以借鏡,但別直接拿它的數字當自己的預期。

    美國能源部(Department of Energy)阿岡國家實驗室(Argonne National Laboratory)相近工作美國 · 2022 起(清冊 operational_date:2022-01-01)

    清冊登記的用途名稱為「AI for Operations Center」,要解決的問題是在規劃工作時,找出相關的經驗教訓(Lessons Learned)要花很多人力;系統會針對規劃中與進行中的工作專案,推薦相關的經驗教訓文件。

    成效未公開成效數字。清冊登記狀態為 Deployed(已部署)、Not High-impact,清冊寫的效益是提高經驗教訓被看到、被使用的程度。

    不能照抄的理由它做的是檢討之後那一段:把過去寫好的經驗教訓,在下一個專案規劃時找回來;不是主持檢討、也不是找原因,所以標為相近工作。可以借的是「檢討的產出要能在下一次開工時被找到」。同一個能源部清冊裡,洛斯阿拉莫斯國家實驗室也登記了同類用途(DOE-434「NLCOO AI for Lessons Learned tool」),清冊沒有公開兩者的使用成效。

    這些案例與其他外部佐證,完整收在找靈感 →

    13相關方法與下一步

    寫成結案報告

    檢討會決定之後,要交給長官的版本用寫報告的做法整理。

    追蹤改進事項

    下次要改的做法,變成有負責人、有期限的追蹤項目。

    確認改了有沒有用

    下一次活動結束後,用改善前後對比的做法看改進有沒有效果。

    其他相關方法RELATED METHODS

    可直接使用RELATED PROMPTS

    這個站的做法
    取得 AI 實戰工具與更新

    之後會不定期整理:新方法、指令包(Prompt Pack)、Checklist 與模板。免費、無廣告;送出後會收到一封確認信,點了連結才算訂閱成功,之後每封信都附一鍵退訂。

    ← 回「專案與任務管理」回找方法 →