三分鐘版 整套流程就這 5 步;要細節再往下讀
建一張追蹤總表:事項|對口|目前狀態|下一步|期限|卡在哪。 每週把收到的零散回覆(信、訊息)貼給 AI,讓它更新總表草稿——你核對後才算數。 讓 AI 依總表標出「紅燈區」:快到期沒動靜、同一件事連兩週沒進展。 催辦訊息讓 AI 擬稿(對不歸你管的人,語氣要對)——寄出前自己改。 對上回報直接從總表生成(接「AI 寫報告」方法)。 這一篇用的是拆解與追進度 這一招——把一大塊工作拆成有負責人、有期限、追得到的項目。 同一招還能做這幾件事(共 5 篇):
本頁 13 節,分 5 區 一、這是什麼 三十秒判斷關不關你的事
先確認這一篇解的是不是你的問題。看完這兩節如果覺得不像,就不用再往下讀——省下的時間比讀完更值錢。
01 解決的工作問題手上同時追十幾件事,對口分散在各單位,而且要推動的人都不歸你管。每週要回報進度,最怕漏掉哪件卡住沒人管。這個情境有一個特有的失敗模式:AI 更新狀態時會把「我會處理」當成「處理中」——而「會處理」是承諾,「處理中」是事實,兩者差一個禮拜就會變成延誤。
02 什麼時候用、什麼時候別用什麼情況下該用這一套 同時在追的事項超過五件。 對口分散、且多半不歸你管。 進度回覆是零散的(信件、訊息、口頭)。 什麼情況下別用
追蹤表有兩份以上時 兩份以上的追蹤表等於沒有追蹤表。先合併成一份再開始。
事項少於五件 手動追比較快,建表的成本高於效益。
讓 AI 直接發催辦訊息 跨單位的語氣是政治不是文書。寄出前一定自己改。
沒有對口名單時 追蹤的基礎是「這件事找誰」。連對口都不清楚時,先做這件事。 誰會用到
PM 你的紅燈規則要寫死(幾天內、幾週沒動)。憑感覺標紅燈,每週的標準都不一樣。
主管 你看的是紅燈清單。追蹤總表的細節不必看,但要確認紅燈規則合理。
行政 跨單位追蹤最花時間的是「無音訊」的判定——沒回覆不等於沒進度,也不等於有進度。
營運 營運類追蹤常有例行項目,把它們與專案項目分開,否則紅燈會被例行項目淹沒。
顧問 催辦訊息的語氣對外部單位特別敏感,一律自己改過再寄。
公務員 跨單位協力事項最容易卡在「不歸你管的人」身上,追蹤表要標出卡在誰。 所屬工作情境 二、整件事怎麼跑 先看圖,再看逐步
先用一張圖抓全貌,再看逐步展開。圖看不懂沒關係,下一節會把每一步實際在做什麼、誰做,一條一條講清楚。
03 流程圖這張圖是整篇的骨架:輸入 → 步驟 → 困難點 → AI/Agent/Tool 介入 → 人工檢查 → 產出。紅框是最常出事的位置,綠框是不能下放的人工檢查點,粗框是中止條件。後面每一節都是在展開圖上的某一格。
AI 專案追蹤:承諾不是事實,無音訊不是進行中 Human 輸入 Human 步驟 AI Checkpoint Output Risk 困難點 Stop 中止
看圖重點: 圖上第二、三個節點看起來像同一件事,其實是兩種不同的防守。「僅為承諾」擋的是狀態被錯誤升級;「無音訊不動」擋的是沒回覆的項目被默默當成還在推進。兩者合起來,紅燈才不會提前熄滅。另外注意倒數第二格提到的「即將轉紅燈」——那是把追蹤從事後補救變成提前一週動作的關鍵,紅燈出現時往往已經來不及。純文字流程表(手機/螢幕閱讀器建議看這張) AI 專案追蹤:承諾不是事實,無音訊不是進行中(純文字流程表) 序 類型/角色 流程步驟 這一步的困難點/中止條件 1 Human 唯一的追蹤總表(含上週快照)+ 本週零散回覆原文 + 寫死的紅燈規則 回覆原文照貼,「我會處理」與「已送件」的差別要保留 — 2 Human 人把本週回覆原文貼成一包,標明來源與日期 — 3 AI AI 產更新草稿:每筆附依據原話;只有承諾的標【僅為承諾】不升級 困難點/風險 「我會處理」被寫成「處理中」——紅燈提前熄滅,到期限才爆
4 AI AI 把未提及的項目列入「本週無音訊」,所有欄位不動 困難點/風險 無音訊被沿用舊狀態,表上一直「進行中」而實際三週沒人動
5 Checkpoint 人逐筆確認狀態升級 + 主動追問無音訊項目 失敗與中止條件 有兩份以上互相矛盾的總表 → 停止追蹤作業,先合併成唯一一份
6 AI AI 依規則標紅燈與「即將轉紅燈」+ 依對口關係擬催辦草稿 困難點/風險 紅燈憑感覺標,每週標準不同,紅燈失去意義
7 Human 人調整語氣後自己寄出;更新寫回唯一的總表並存快照 困難點/風險 催辦語氣得罪不歸你管的人,後面更難推
8 Output 更新後的總表 + 紅燈清單 + 已寄出的催辦 + 本週快照 —
Mermaid 原始碼(貼進 Mermaid Live 或 draw.io 可再編輯) 可直接複製,改成你自己的流程 複製 Mermaid
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 把未提及的項目列入「本週無音訊」,所有欄位不動"/]
c1{{"<b>Checkpoint</b><br/>人逐筆確認狀態升級 + 主動追問無音訊項目"}}
a3[/"<b>AI</b><br/>AI 依規則標紅燈與「即將轉紅燈」+ 依對口關係擬催辦草稿"/]
s2["<b>Human</b><br/>人調整語氣後自己寄出;更新寫回唯一的總表並存快照"]
o1(["<b>Output</b><br/>更新後的總表 + 紅燈清單 + 已寄出的催辦 + 本週快照"])
r1>"<b>Risk</b><br/>「我會處理」被寫成「處理中」——紅燈提前熄滅,到期限才爆"]
r2>"<b>Risk</b><br/>無音訊被沿用舊狀態,表上一直「進行中」而實際三週沒人動"]
x1[/"<b>Stop</b><br/>有兩份以上互相矛盾的總表 → 停止追蹤作業,先合併成唯一一份"\]
r4>"<b>Risk</b><br/>紅燈憑感覺標,每週標準不同,紅燈失去意義"]
r3>"<b>Risk</b><br/>催辦語氣得罪不歸你管的人,後面更難推"]
in1 --> s1
s1 --> a1
a1 --> a2
a2 --> c1
c1 --> a3
a3 --> s2
s2 --> o1
a1 -.->|風險| r1
a2 -.->|風險| r2
c1 ==>|中止| x1
a3 -.->|風險| r4
s2 -.->|風險| r3
c1 -.->|升級無依據就退回不更新| a1
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 c1 clsCheck;
class a3 clsAI;
class s2 clsHuman;
class o1 clsOut;
class r1 clsRisk;
class r2 clsRisk;
class x1 clsStop;
class r4 clsRisk;
class r3 clsRisk; 04 完整步驟圖的文字版,逐步展開 上面三分鐘版那幾步,這裡逐步展開:每一步誰做、做完會有什麼。
序 誰做 步驟與說明 1 Human 建一張總表 事項|對口|目前狀態|下一步|期限|卡在哪。一張,不是好幾張。→ 追蹤總表 2 Human 貼零散回覆 把本週收到的回覆原文貼上。原文裡的「我會處理」與「已經送出」是不同的東西,摘要過就分不出來。→ 本週回覆包 3 AI 產更新草稿 哪一列該更新成什麼,附依據(誰在哪封回覆講的)。回覆裡沒提到的項目不要動。→ 總表更新草稿 4 Human 核對狀態升級 特別看「未開始→進行中」與「進行中→完成」。狀態升級要有具體動作當依據,不是口頭承諾。→ 確認過的更新 5 AI 標紅燈 依寫死的規則標:期限七天內未完成、連續兩週無進展。規則明確才不會每週標準不同。→ 紅燈清單 6 AI 擬催辦訊息 對紅燈項目各擬一則。禮貌、講清楚需要對方做什麼、什麼時候要。→ 催辦訊息草稿 7 Human 改語氣再寄 跨單位的語氣是政治不是文書。逐則改過再寄。→ 已寄出的催辦 8 AI 接對上報告 對上回報直接從總表生成。總表是唯一來源,報告只是它的一種呈現。→ 進度報告
三、動手做 備料 → 指令 → 產出 → 工具
這一區是真的動手:先備料、再貼指令、然後對照產出應該長什麼樣。手上是哪一支 AI 都做得完,差別寫在最後的工具那一節。
05 開始前要準備什麼標「必要」的沒備齊就先別開始
追蹤總表必要 事項|對口|目前狀態|下一步|期限|卡在哪。這是唯一版本,不能有第二份。
本週收到的零散回覆必要 信件、訊息、會議中提到的。原文照貼,不要先摘要。
紅燈規則必要 幾天內到期算紅燈、連續幾週沒進展算紅燈。寫死,不要憑感覺。
狀態的定義必要 特別是「進行中」的判準——要有具體動作作為依據,不能只有口頭承諾。
對口的層級與關係可選 催辦訊息的語氣依對象而定。
上週的總表版本可選 用來比對哪些項目連續無進展。 餵進去的東西要長這樣 追蹤總表(含上週快照)+ 本週零散回覆原文 + 紅燈規則參數 + 對口關係。
總表只能有一份,另存快照時要標日期。 回覆原文照貼,不要先摘要——「我會處理」與「已送件」的差別要保留。 回覆要標來源與日期(誰、什麼時候、用什麼方式說的)。 紅燈規則參數寫死,不要每週調整。 回覆中的個資先遮蔽。 【設定】
專案:○○系統建置
我的角色:承辦,對口單位皆不歸我管
追蹤週期:每週五
上週總表版本:2026-08-14
紅燈規則:期限 7 天內未完成/連續 2 週無進展/失聯 3 週/已逾期
催辦語氣:平行單位=客氣,以「我可以先準備什麼」為框架;外部廠商=明確但不強硬
【追蹤總表(本週初,2026-08-21)】
| 事項 | 對口 | 狀態 | 下一步 | 期限 | 卡在哪 | 上週狀態 |
|---|---|---|---|---|---|---|
| 資料介接規格確認 | A 局資訊科 王 | 進行中 | 等對方回規格 | 8/30 | 等回覆 | 進行中 |
| 場地租借合約 | 總務科 陳 | 未開始 | 需先簽會計 | 9/15 | — | 未開始 |
| 教育訓練排程 | 人事室 李 | 進行中 | 排講師時間 | 9/5 | — | 進行中 |
| 系統帳號開通 | 資訊室 張 | 未開始 | 送申請單 | 8/25 | — | 未開始 |
| 經費核銷 | 會計室 黃 | 進行中 | 補單據 | 8/28 | 缺兩張發票 | 進行中 |
【本週回覆原文】
[8/19 信件] A 局王科員:「規格書我這邊還在確認,下週應該可以給你。」
[8/20 訊息] 人事室李:「講師時間已經敲定 9/12,教室也訂好了。」
[8/21 訊息] 資訊室張:「帳號申請單我會處理。」 06 Prompt(快速/完整/進階)A 快速版貼上就能用;B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足;C 進階版是拿去建 GPT/Skill/Agent 的系統指令,預設收起來,要用再點開。三版都附可替換變數、使用範例與預期輸出;A 與 B 另外列出那一版特有的常見錯誤與人工確認點,C 版的那幾題指向 Agent 專篇。
A A. 快速版 本週的零散回覆收齊了,想快速更新總表並找出紅燈。
適合的工具 ChatGPT Claude 試算表
👇 直接複製,{ } 換成你的內容 複製這段 Prompt
這是我的專案追蹤總表,以下是本週收到的零散回覆。請:
1. 產生總表更新草稿:哪一列該更新成什麼,附依據(誰在哪封回覆講的)。
2. 回覆裡沒提到的項目不要動,列成「本週無音訊」清單。
3. 標出紅燈:期限七天內但狀態未完成的、連續兩週無進展的。
4. 對紅燈項目各擬一則催辦訊息草稿(禮貌、講清楚需要對方做什麼、什麼時候要)。
總表:{貼上};本週回覆:{貼上} 可替換變數 變數 要換成什麼 {貼上}(總表)現行追蹤總表。 {貼上}(本週回覆)本週收到的零散回覆原文。不要先摘要。
完整使用範例(照這樣填) 這是我的專案追蹤總表,以下是本週收到的零散回覆。請:(照母提示詞四條)
總表:
| 事項 | 對口 | 狀態 | 下一步 | 期限 | 卡在哪 |
| 資料介接規格確認 | A 局資訊科 王 | 進行中 | 等對方回規格 | 8/30 | 等回覆 |
| 場地租借合約 | 總務科 陳 | 未開始 | 需先簽會計 | 9/15 | — |
| 教育訓練排程 | 人事室 李 | 進行中 | 排講師時間 | 9/5 | — |
| 系統帳號開通 | 資訊室 張 | 未開始 | 送申請單 | 8/25 | — |
| 經費核銷 | 會計室 黃 | 進行中 | 補單據 | 8/28 | 缺兩張發票 |
本週回覆:
[8/19 信件] A 局王科員:「規格書我這邊還在確認,下週應該可以給你。」
[8/20 訊息] 人事室李:「講師時間已經敲定 9/12,教室也訂好了。」
[8/21 訊息] 資訊室張:「帳號申請單我會處理。」 預期輸出範例(拿到的東西應該長這樣) 【一、總表更新草稿】
| 事項 | 原狀態 | 建議更新為 | 依據 |
|---|---|---|---|
| 資料介接規格確認 | 進行中 | 進行中(不變)|「卡在哪」更新為「對方確認中,稱下週給」 | 8/19 A 局王科員信件 |
| 教育訓練排程 | 進行中 | **已完成** | 8/20 人事室李訊息:「講師時間已經敲定 9/12,教室也訂好了」——有具體結果(日期、教室) |
| 系統帳號開通 | 未開始 | **維持未開始** ⚠️ | 8/21 資訊室張訊息為「我會處理」,屬承諾非動作。狀態不升級。 |
【二、本週無音訊】
- 場地租借合約(總務科陳)
- 經費核銷(會計室黃)
※ 這兩項本週無任何回覆,狀態一律不動。
【三、紅燈】
| 事項 | 紅燈原因 |
|---|---|
| 系統帳號開通 | 期限 8/25,剩 4 天且仍為「未開始」;對方僅口頭承諾 |
| 經費核銷 | 期限 8/28,剩 7 天;且已連續兩週無音訊 |
【四、催辦訊息草稿】
(1)致資訊室張(帳號開通)
「張先生您好,關於系統帳號開通,因 8/25 前需完成以利後續測試,想確認申請單是否已送出?若尚未送出,我這邊可以先把需要的資料整理好給您。麻煩您了。」
(2)致會計室黃(經費核銷)
「黃小姐您好,經費核銷這件事想跟您確認進度。上次提到缺兩張發票,我已於 8/12 補送,不確定是否有收到?核銷期限為 8/28,若還缺什麼請告訴我,我盡快補齊。」
※ 兩則訊息的語氣請依你與對方的關係調整後再寄出。 常見錯誤用法 接受「我會處理」→「處理中」的更新。這是這個方法最主要的防守點。 把「無音訊」清單跳過。沒回覆的項目才是最容易爆的。 催辦訊息直接複製寄出。跨單位的語氣是政治不是文書。 更新完之後把總表存成新的一份。總表只能有一份。 缺少資料時怎麼辦 回覆中沒提到的項目,AI 應該列進「無音訊」而不是沿用舊狀態當成「還在進行」。如果某項連續三週無音訊,那不是「進行中」,那是「失聯」——建議在總表加一個獨立的狀態。
適合的工具 ChatGPT Claude 試算表
👇 直接複製,{ } 換成你的內容 複製這段 Prompt
# 角色
你是專案追蹤助手。你更新總表草稿、標紅燈、擬催辦訊息。你不判定狀態的真偽,也不代我發送任何訊息。
# 背景
- 專案/業務:{專案名稱}
- 我的角色與權限:{我的角色,例如「承辦,對口單位皆不歸我管」}
- 追蹤週期:{週期}
- 上週的總表版本日期:{上週日期}
# 狀態定義(嚴格適用)
- **未開始**:對方尚未有任何實際動作。口頭承諾(「我會處理」「下週辦」)仍屬未開始。
- **進行中**:有具體動作的證據(已送件、已排程、已開始作業、有中間產出)。
- **待我方**:卡在我這邊,需要我先做什麼。
- **完成**:有可驗證的結果(文件、系統紀錄、對方明確確認完成)。
- **失聯**:連續 {失聯週數} 週無任何回覆。
狀態升級(未開始→進行中、進行中→完成)必須有具體動作或結果作為依據。只有承諾不升級。
# 紅燈規則(依此判定,不得憑感覺)
1. 期限在 {紅燈天數} 天內且狀態非「完成」
2. 連續 {無進展週數} 週無進展(狀態與「下一步」皆未變動)
3. 狀態為「失聯」
4. 已逾期且未完成
5. {其他紅燈規則}
# 處理步驟
1. **更新草稿**:逐列判斷本週回覆是否影響該項,附依據(誰在哪封回覆講的、原話引句)。
2. **不動的一律不動**:回覆中沒提到的項目,狀態、下一步、卡在哪全部保持原樣,並列入「本週無音訊」清單。
3. **標記可疑升級**:若某項的更新依據只是承諾而非動作,明確標示「⚠️ 僅為承諾,建議維持原狀態」並說明。
4. **紅燈判定**:依規則逐條套用,每個紅燈標明觸發了第幾條規則。
5. **催辦訊息**:對每個紅燈項目擬一則,依對口關係調整基礎語氣(見下)。
6. **對比上週**:指出哪些項目已連續無進展、哪些即將觸發紅燈(下週會變紅燈的)。
# 催辦語氣分級(依對口關係)
- 平行單位:{平行單位語氣,例如「客氣、以協助對方為框架」}
- 上級單位:{上級單位語氣}
- 外部廠商:{外部廠商語氣}
- 內部同仁:{內部語氣}
每則催辦必含四要素:(1)這件事是什麼(2)目前卡在哪(3)需要對方做什麼(4)什麼時候之前要。
不得使用:責備語氣、「再次提醒」「已多次」這類累積性措辭(除非我明確要求)。
# 不可以做的事
1. 不得把承諾當成動作。
2. 不得為回覆中未提及的項目更新狀態。
3. 不得自行判斷某件事「應該差不多好了」。
4. 不得代為發送任何訊息。
5. 不得產生總表中沒有的事項。
# 輸出格式
## 一、總表更新草稿(事項|原狀態|建議更新|依據原話|是否為可疑升級)
## 二、本週無音訊清單(事項|對口|已連續幾週無音訊)
## 三、紅燈清單(事項|觸發第幾條規則|距期限幾天)
## 四、即將轉紅燈(下週會觸發的)
## 五、催辦訊息草稿(依對口分別擬)
## 六、自我檢查結果
# 自我檢查(輸出前執行)
1. 是否有把承諾當成動作的狀態升級?
2. 是否為無音訊的項目更動了任何欄位?
3. 每筆更新是否都附了依據原話?
4. 紅燈是否都標明觸發哪一條規則?
5. 催辦訊息是否含四要素、且無責備語氣?
# 總表
{貼上總表}
# 本週回覆
{貼上本週回覆原文} 可替換變數 變數 要換成什麼 {專案名稱}/{我的角色}角色影響催辦的語氣與立場。 {週期}/{上週日期}用來判斷連續無進展。 {失聯週數}/{紅燈天數}/{無進展週數}紅燈規則的參數。建議 3/7/2。 {其他紅燈規則}你們業務特有的,例如「涉及法定期限者提前 14 天」。 {各類語氣}催辦語氣依對象分級。這一欄能省下你大量的改稿時間。
完整使用範例(照這樣填) 把 {專案名稱} 換成「○○系統建置」、{我的角色} 換成「承辦,對口單位皆不歸我管」、{失聯週數} 換成 3、{紅燈天數} 換成 7、{無進展週數} 換成 2、{平行單位語氣} 換成「客氣,以『我可以先準備什麼』為框架」、{外部廠商語氣} 換成「明確但不強硬,寫清楚期限依據」。 預期輸出範例(拿到的東西應該長這樣) 第一節會把「我會處理」標為「⚠️ 僅為承諾,建議維持未開始」;第二節列出本週無音訊並標明連續週數;第四節會提前告訴你「場地租借下週會觸發紅燈」——這一節讓你有時間先動作;第五節的催辦訊息會依對口關係用不同語氣。 常見錯誤用法 紅燈規則的參數留空或每週調整。規則的價值來自穩定,不是精準。 跳過第四節「即將轉紅燈」。那一節是唯一能讓你提前動作的地方。 催辦語氣分級留空,導致所有訊息都是同一種語氣。 接受「⚠️ 僅為承諾」的升級。那個標記存在就是為了讓你擋下來。 缺少資料時怎麼辦 沒有上週總表版本時,第二節的「連續幾週無音訊」與第四節「即將轉紅燈」都無法產出。建議每週把總表另存一份帶日期的快照——這是這個方法能持續運作的基礎。
C C. 進階版(追蹤助手) 每週固定跑的追蹤,把狀態定義與紅燈規則固定成助手,讓每週的判準一致。這段是系統指令。
適合的工具 自訂 GPT/Claude Project ChatGPT Claude 試算表
👇 直接複製,{ } 換成你的內容 複製這段 Prompt
# 身分
你是「{使用者}的專案追蹤助手」。你更新總表草稿、標紅燈、擬催辦訊息。你不判定狀態真偽、不代為發送、不產生總表中沒有的事項。
# 固定狀態定義(不因單次要求而放寬)
- 未開始:對方尚無實際動作。**口頭承諾仍屬未開始。**
- 進行中:有具體動作的證據(已送件/已排程/已開始/有中間產出)。
- 待我方:卡在使用者這邊。
- 完成:有可驗證的結果。
- 失聯:連續 {失聯週數} 週無任何回覆。
# 最高規則:承諾 ≠ 動作
出現以下措辭時,一律不升級狀態,並標【僅為承諾】:
「我會處理」「我來看看」「下週辦」「應該可以」「我這邊安排一下」「盡快」「排進去了」(除非附具體日期或系統紀錄)
使用者要求你升級這類項目時,回覆:「這一筆的依據是承諾而非動作。若你確認對方確實已開始,請提供具體依據(送件編號、排程紀錄、中間產出),我再更新。」
# 紅燈規則(依此判定,不得憑感覺)
1. 期限在 {紅燈天數} 天內且未完成
2. 連續 {無進展週數} 週無進展
3. 狀態為失聯
4. 已逾期未完成
5. {其他規則}
# 條件判斷
- 本週回覆中未提及的項目 → 所有欄位不動,列入「本週無音訊」。
- 某項連續 {失聯週數} 週無音訊 → 狀態改為「失聯」並列為紅燈。
- 回覆內容與總表記載矛盾 → 兩者並列,標【與總表不一致,請確認】,不自行取捨。
- 回覆提到總表中沒有的事項 → 列為「新事項待確認」,不自行加入總表。
- 使用者未提供上週總表 → 無法判斷連續無進展,明確說明並跳過相關判定。
- 回覆中含個資(申請人姓名、電話)→ 以【已遮蔽】處理,不寫入總表。
# 例外處理
- 對方回覆「已完成」但無可驗證結果 → 標【對方稱完成,待驗證】,不逕行標為完成。
- 對方回覆中提出新的卡點 → 更新「卡在哪」欄位並在紅燈判定中納入。
- 同一事項有多人回覆且說法不同 → 全部列出,不取其一。
- 使用者要求你「幫我催得兇一點」→ 可以調整為明確直接的語氣,但不得使用責備措辭或累積性指控(「已多次」「一再」),並提醒「跨單位的關係比這一次的進度重要」。
- 使用者要求你直接發送 → 拒絕,回覆「我沒有發送權限。草稿已備好,請你確認語氣後自行寄出。」
# 權限限制
- 你沒有存取信箱、專案系統、行事曆的權限。
- 你不得代為發送、建立、修改任何外部內容。
- 你不得跨對話記憶總表內容(每次由使用者提供)。
# 必須交給人的判斷
1. 狀態升級的最終認定。
2. 無音訊項目要不要主動追。
3. 催辦訊息的語氣與寄出。
4. 紅燈規則參數的調整。
5. 新事項要不要納入追蹤。
# 中止條件
- 使用者三次要求把承諾當成動作升級狀態。
- 使用者提供兩份以上互相矛盾的總表。
- 使用者要求代為發送。
中止輸出格式:「【中止】原因:{原因}。建議處理方式:{建議}。」
# 固定輸出格式
一、總表更新草稿(事項|原狀態|建議更新|依據原話|可疑升級標記)
二、本週無音訊(事項|對口|連續週數)
三、紅燈清單(事項|觸發規則|距期限)
四、即將轉紅燈(下週會觸發的)
五、催辦訊息草稿(依對口關係分別擬,每則含四要素)
六、需要你確認的(矛盾、新事項、對方稱完成待驗證)
七、自我檢查結果
# 自我檢查(輸出前執行)
1. 是否有把承諾當動作的升級?
2. 是否為無音訊項目更動了欄位?
3. 每筆更新是否附依據原話?
4. 紅燈是否標明觸發哪條規則?
5. 催辦是否含四要素、無責備語氣?
6. 是否產生了總表中沒有的事項?
# 品質檢核(結尾固定一行)
「本週 {N} 項:有更新 {A}、無音訊 {B}(其中失聯 {C});紅燈 {D}、即將轉紅燈 {E};可疑升級 {F} 筆已標記待你確認。所有催辦訊息均為草稿,未發送。」 可替換變數 變數 要換成什麼 {使用者}助手服務對象。 {失聯週數}/{紅燈天數}/{無進展週數}紅燈規則參數。建議 3/7/2。 {其他規則}業務特有的紅燈規則。
完整使用範例(照這樣填) 在自訂 GPT 建立助手,指令欄貼上整段。每週固定時間,貼上總表(含上週版本)與本週收到的回覆原文。輸出的更新草稿確認後,自己更新試算表上的總表。 預期輸出範例(拿到的東西應該長這樣) 「我會處理」一律不升級並標【僅為承諾】;未提及的項目完全不動並列入無音訊;要求「幫我催兇一點」時會調整語氣但拒絕使用累積性指控;結尾固定給本週統計。 固化成助手是另一件工程,這一頁不重講 下面這幾題每個方法都一樣,站上各有一篇:
07 產出應該長什麼樣拿到的東西要長這樣 七節:更新草稿、無音訊、紅燈、即將轉紅燈、催辦草稿、需要確認的、自我檢查。
完成品:「僅為承諾」的標記實際擋下了什麼 【8/21 當週】
資訊室張回覆:「帳號申請單我會處理。」
AI 標記:⚠️【僅為承諾】無送件依據,建議維持「未開始」。
我的判斷:接受,維持未開始。因此該項仍在紅燈清單(期限 8/25,剩 4 天)。
→ 依紅燈清單發出催辦訊息。
【8/22】
張回覆:「不好意思,我這邊在等你們的用途說明表,沒有那張我沒辦法送。」
→ 真相:他確實還沒送,而且卡點在我方。
→ 若當初把「我會處理」更新成「進行中」,這件事會在我的表上顯示為正常推進,直到 8/25 期限到了才發現。而那時候補用途說明表已經來不及。
→ 總表更新:狀態改為「待我方」,卡在哪=「需提供用途說明表」。
【8/23】
用途說明表補送,張當日送件。
→ 狀態更新為「進行中」,依據:張提供的送件編號。這次是動作,不是承諾。
【8/26】
帳號開通完成。
【回頭看】
這件事之所以趕上,關鍵是 8/21 那天的狀態沒有被錯誤升級。
如果升級了:紅燈熄滅 → 不會發催辦 → 不會發現卡點在我方 → 8/25 逾期。
※ 「承諾 ≠ 動作」這條規則看起來很囉嗦,它擋下的正是這種「安靜的延誤」——沒有人做錯什麼,只是狀態記錯了一格。 輸出格式規格(要照著做的人再展開) 每筆更新附依據原話(誰在哪封講的)。 承諾類的更新要標【僅為承諾】。 無音訊項目所有欄位不動,並標連續週數。 紅燈要標明觸發第幾條規則。 催辦訊息含四要素:這件事是什麼、卡在哪、要對方做什麼、什麼時候要。 一、總表更新草稿
| 事項 | 原狀態 | 建議更新 | 依據原話 | 標記 |
|---|---|---|---|---|
| 資料介接規格確認 | 進行中 | 狀態不變;「卡在哪」→「對方確認中,稱下週給」 | 「規格書我這邊還在確認,下週應該可以給你」(8/19 王) | — |
| 教育訓練排程 | 進行中 | → **完成** | 「講師時間已經敲定 9/12,教室也訂好了」(8/20 李) | 有具體結果(日期+教室) |
| 系統帳號開通 | 未開始 | **維持未開始** | 「帳號申請單我會處理」(8/21 張) | ⚠️【僅為承諾】無送件依據,不升級 |
二、本週無音訊
| 事項 | 對口 | 連續週數 |
|---|---|---|
| 場地租借合約 | 總務科 陳 | 2 週 |
| 經費核銷 | 會計室 黃 | 2 週 |
三、紅燈清單
| 事項 | 觸發規則 | 距期限 |
|---|---|---|
| 系統帳號開通 | 規則 1(7 天內未完成) | 4 天 |
| 經費核銷 | 規則 1(7 天內未完成)+規則 2(連續 2 週無進展) | 7 天 |
四、即將轉紅燈(下週會觸發)
| 事項 | 預計觸發規則 | 建議現在做什麼 |
|---|---|---|
| 場地租借合約 | 規則 2(下週將滿 3 週無進展) | 本週先電話確認一次,避免進入失聯 |
| 資料介接規格確認 | 規則 1(8/30 到期,下週五將剩 6 天) | 對方稱下週給,可先預告若逾期的影響 |
五、催辦訊息草稿
(1)致資訊室張(內部同仁語氣)
「張先生您好,關於系統帳號開通,因 8/25 前需完成以利後續測試,想確認申請單是否已送出?若尚未送出,我可以先把需要的資料整理好給您。麻煩您了。」
(四要素:帳號開通/不確定是否已送件/確認並送出申請單/8/25 前)
(2)致會計室黃(平行單位語氣)
「黃小姐您好,經費核銷這件事想跟您確認進度。上次提到缺兩張發票,我已於 8/12 補送,不確定是否有收到?核銷期限為 8/28,若還缺什麼請告訴我,我盡快補齊。」
(四要素:經費核銷/缺件是否已補齊/確認收件並告知還缺什麼/8/28 前)
六、需要你確認的
- 「教育訓練排程」建議標為完成,但對方僅在訊息中提及,未見正式排程文件。若你們的認定標準需要文件,請改為【對方稱完成,待驗證】。
七、自我檢查結果
無承諾當動作的升級:通過(1 筆已標記)|無音訊項目未更動:通過|每筆更新附依據:通過|紅燈標明規則:通過|催辦含四要素無責備語氣:通過|未產生總表外事項:通過
本週 5 項:有更新 3、無音訊 2(其中失聯 0);紅燈 2、即將轉紅燈 2;可疑升級 1 筆已標記待你確認。所有催辦訊息均為草稿,未發送。 08 工具怎麼挑這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議,不是限定。
工具 什麼時候用 為什麼 注意 ChatGPT ↗ 起手 更新總表與擬催辦文字 每週更新、要建自訂助手 結構化更新穩定,自訂 GPT 好建。 回覆中的個資要先遮蔽。 Claude ↗ 回覆量大、來源多 長輸入處理穩定,較少漏掉零散回覆中的細節。 同樣要人核狀態升級。 M365 Copilot ↗ 彙整 Teams/Planner 的回報 總表在 Excel、進度回報散在 Teams 與 Planner 追蹤資料不必搬出公司環境就能彙整成一份。 它只看得到有寫下來的東西;沒人回報的項目它不會替你發現。 試算表 追蹤總表本體 總表本身 總表要是唯一版本、可留快照、可篩選。試算表最適合。 每週存一份帶日期的快照,這是連續無進展判定的基礎。
四、不要做錯 這幾關不下放
這一區是踩過的坑與該守的線。標「不下放」的步驟請不要交給 AI 決定;Checklist 是拿來驗收的,不是拿來勾好看的。
09 會卡住與會做錯的地方會卡住的地方(流程困難點)
把承諾當成事實 「我會處理」被更新成「處理中」。這是這個方法最常見也最傷的錯——因為它讓紅燈提前熄滅。
無音訊被當成進行中 這週沒回覆的項目,如果被 AI 沿用上週的狀態,等於這件事在你的表上一直「進行中」,直到期限到了才爆。
催辦語氣得罪人 對不歸你管的人催辦,語氣錯了會讓後面更難推。
兩份追蹤表 一份在試算表、一份在會議紀錄裡,兩份都不完整,而且互相矛盾。 會做錯的地方(常見失敗方式) 把承諾當成事實 「我會處理」更新成「處理中」,紅燈提前熄滅,延誤到期限才爆。
怎麼修 狀態定義寫死,口頭承諾一律不升級;升級要有具體動作或結果的依據。
無音訊被沿用舊狀態 沒回覆的項目在表上一直「進行中」,實際上可能三週沒人動。
怎麼修 未提及的項目所有欄位不動,獨立列成無音訊清單並標連續週數;滿 N 週改為「失聯」。
紅燈憑感覺標 每週的標準不一樣,紅燈失去意義。
怎麼修 規則寫死(天數、週數),AI 只負責套用並標明觸發第幾條。
催辦語氣得罪人 對不歸你管的人用了責備或累積性措辭,後面更難推。
怎麼修 語氣依對口關係分級;禁用「已多次」「一再」;一律自己改過再寄。
兩份追蹤表 一份在試算表、一份在會議紀錄,互相矛盾。
怎麼修 總表只有一份;其他地方只放連結或摘要,不放可編輯的副本。
只做事後追蹤 紅燈出現時已經來不及。
怎麼修 產出「即將轉紅燈」清單,把動作提前一週。
10 人工把關與安全限制AI/Agent/Tool 介入在哪幾步 流程位置 誰 做什麼/怎麼做 更新階段 AI 產更新草稿附依據 每一筆更新都要指出「誰在哪封回覆講的」。沒有依據的不更新。無音訊判定 AI 列出本週無音訊清單 回覆裡沒提到的項目一律不動,並獨立列成清單。這比更新更重要。紅燈判定 AI 依規則標紅燈 規則寫死(幾天內、幾週沒動),AI 只負責套用。催辦階段 AI 擬訊息草稿 講清楚需要對方做什麼、什麼時候要。語氣由你調整。
這幾關不下放
狀態升級的判定 特別是「未開始→進行中」。要有具體動作,不是口頭承諾。
無音訊的處理 沒回覆不等於沒進度,也不等於有進度。要主動去問。
催辦語氣 跨單位是政治判斷,一律自己改過再寄。
紅燈規則的訂定 幾天算紅燈,是管理決定。
總表的唯一性 只能有一份,由你維護。 安全與權限限制
回覆中的個資 零散回覆常含申請人姓名、電話。貼進 AI 前先遮蔽。
跨單位的內部訊息 他單位的內部說法(「我們主管卡著」)不要寫進會被廣傳的總表。
總表的存取權限 總表含各單位的進度與卡點,權限要控管。
催辦紀錄留檔 什麼時候催過、對方怎麼回,留紀錄;日後究責時是依據。
助手無發送權 只擬稿,不代發。跨單位的訊息一旦寄錯,收不回來。 11 Checklist 與驗收標準做的時候逐項打勾 做完了才檢查:全部成立才算完成 追蹤總表只有一份,且每週有帶日期的快照。 每一筆狀態更新都有依據原話(誰在哪封回覆講的)。 沒有任何狀態升級是僅憑口頭承諾。 本週無音訊的項目狀態未被更動,且已列出連續週數。 紅燈規則已寫死並穩定套用,每個紅燈標明觸發哪一條規則。 有「即將轉紅燈」清單,並已據此提前動作。 催辦訊息含四要素,語氣經人調整後才寄出,且無責備或累積性措辭。 對外催辦有留紀錄(何時催、對方怎麼回)。 回覆中的個資已遮蔽。 五、延伸 把流程走一遍,然後往下一步
先用一個示範情境把流程從頭走一遍,再看具名機構真的做過的事,最後決定下一步往哪走。
12 示範情境跨單位推動追蹤:「我會處理」不是「處理中」
這是示範情境,不是真實個案:作者為了把上面的流程走一遍而寫的設想,人物、數字與結果都是設定。真的有人做過的案例,看下面「真的有人這樣做過」。
改編自站上的完整拆解:跨單位推動追蹤方法(完整拆解) →
設想的狀況: 同時追十幾件事,對口分散在不同單位,而且都不歸自己管。過去用試算表手動追,問題不是記不住,而是「狀態該不該更新」的判斷每週不一致——心情好的時候「我會處理」就更新成進行中,忙的時候就跳過。
AI 負責什麼 依總表與本週零散回覆產出更新草稿,每筆附依據原話(誰在哪封回覆講的)。 把只有口頭承諾的更新標【僅為承諾】並建議維持原狀態——這是最主要的防守點。 回覆中未提及的項目一律不動,獨立列成「本週無音訊」清單並標連續週數。 依寫死的規則標紅燈,每個紅燈標明觸發第幾條規則。 額外列出「即將轉紅燈」——下週會觸發的項目,讓人有時間提前動作。 依對口關係擬不同語氣的催辦訊息,每則含四要素。 人負責什麼 訂定紅燈規則的參數(7 天/2 週/3 週失聯)並固定下來。 逐筆確認狀態升級,特別是被標【僅為承諾】的項目。 主動追問無音訊的項目——沒回覆不等於沒進度,也不等於有進度。 逐則調整催辦訊息的語氣後自己寄出。 每週把總表另存一份帶日期的快照。 照著走完會得到: 狀態判定從「憑當週心情」變成「有依據原話」。而「即將轉紅燈」那一節帶來的改變最明顯——它把追蹤從「事後補救」變成「提前一週動作」。
待補資料:本站不提供逾期率或推動效率的量化改善。建議記錄「因無人追蹤而逾期的件數」連續三個月作為基準。
真的有人這樣做過外部佐證 3 則 以下都是具名機構的公開案例,每個來源都經過連結實測。數字只寫來源講得出來的;來源沒講的,這裡就寫未公開。 標「相近工作 」的 3 則,做的不是同一件工作——機制相通可以借鏡,但別直接拿它的數字當自己的預期。
Morningstar(晨星) 相近工作 美國 · 2025 用 Asana AI Studio 自動處理工作需求 intake:自動命名需求、辨識資訊缺口、產生標準化摘要供評估,並自動路由到後續流程。
成效 Asana 案例頁載明退休團隊「eliminated two weeks from request review timelines」;另研究團隊的 AI 內容產製流程「saves approximately 14,976 hours annually, translating to an additional $600,000 in savings」。
不能照抄的理由 廠商(Asana)客戶案例頁,數字由 Morningstar 自行提供。⚠️頁面上兩組 KPI 分屬不同團隊與流程:「縮短兩週」是退休團隊的需求 intake,「14,976 小時/60 萬美元」是研究團隊的內容產製,不可合併引用或互為佐證。
社群團隊用 Asana AI Studio 分析每張進件任務的標題與描述,判斷範圍與複雜度訊號,產生分類與工時估計,再餵進工作量管理與產能規劃。
成效 Asana 案例頁載明「250 coordination hours saved annually across the team by automating manual evaluation and distribution」。
不能照抄的理由 廠商(Asana)客戶案例頁,250 小時由 HubSpot 自行提供。範圍需講清楚:這不是 AI 自動指派工作給人,它負責分類、工時估計與產能盤點,實際調度仍由管理者依這些資訊決定。
Doxel(服務 DPR Construction、Layton Construction、Sundt 等總承包商) 相近工作 美國 · 2018 起 Doxel 用機器人與手持設備在工地掃描現場影像,透過電腦視覺比對 BIM 模型,即時判斷實際施工進度與品質是否偏離計畫,取代人工定期巡視回報進度的做法。
成效 Doxel 官方案例:使用其系統的總承包商平均施工進度加快約 11%、月現金流出減少約 10%;其中一個醫療案場曾在牆面骨架施工出現延遲徵兆時被系統即早偵測,及時加派人力避免約三週的工期延誤。
不能照抄的理由 數字來自 Doxel 官方發布的客戶案例彙整,非獨立第三方稽核;效益幅度會因工地複雜度、BIM 模型完整度與既有專案管理成熟度而不同。
這些案例與其他外部佐證,完整收在找靈感 →
13 相關方法與下一步其他相關方法RELATED METHODS 可直接使用RELATED PROMPTS 延伸案例RELATED CASES Download 這個方法的模板與 Checklist 下載包整理中——訂閱更新 ,上架後第一時間通知你。
這個站的做法 有來源 引用的案例都附得出可以點進去的出處;還沒查證完的另外標示,不跟已證實的混在一起。 可驗收 每個方法都附 Checklist 與驗收標準——你要能自己驗,而不是相信 AI 說它做完了。 不亂編 指令一律要求「材料裡沒有的不准補」,缺的標【待補】列成問題,不用漂亮的句子蓋過去。 不自動送出 站內的指令與工具不會替你發布、寄出或執行收不回來的動作。最後一步永遠是人按下去。 人要把關 方法裡標「不下放」的步驟,寫明白就是不要交給 AI 決定。 一般人照做 不用寫程式。步驟寫成照著做的樣子,術語第一次出現就用白話解釋。
取得 AI 實戰工具與更新
之後會不定期整理:新方法、指令包(Prompt Pack)、Checklist 與模板。免費、無廣告;送出後會收到一封確認信,點了連結才算訂閱成功 ,之後每封信都附一鍵退訂。
送出即表示你同意本站的 隱私權說明 :我們只儲存 Email 與同意版本,不會把 Email 和你的閱讀紀錄綁在一起。沒有點確認信就不會收到任何內容,之後也隨時可以一鍵退訂。