AI 利害關係人溝通教學：同一個專案更新，怎麼寫給主管、工程師與使用者？
原內容日期：2026-09-12。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。
不是每個人都要收到同一封信
專案發生變化時，我們常把同一段更新貼進 Email、群組與會議簡報，再一次寄給主管、工程師、使用者和供應商。
看起來很有效率，實際上每個人真正需要的內容不同。
主管想知道影響、風險與需要決定的選項；工程師需要條件、紀錄與完成標準；現場使用者只想知道工作會不會受影響、現在該怎麼做；供應商則需要交付範圍、資料格式與正式窗口。
如果所有人都收到同一版，結果通常不是資訊透明，而是每個人都要自己從長文裡找答案。
先鎖定共同事實，再改寫角色版本
使用 AI 產生多版本訊息前，第一步不是指定語氣，而是建立共同事實底稿。
底稿至少要包含目前狀態、已確認影響、正式與暫定日期、已完成處理、尚待決定事項，以及下一次更新時間。
所有角色版本可以有不同長度與排列順序，但核心事實不能改變。主管版可以不放完整日誌，卻不能把「原因待查」改成「原因已確認」；使用者版可以省略內部討論，卻不能提供另一個恢復日期。
不要用利害關係人地圖替人貼標籤
AI很容易根據少量文字推測某人支持或反對專案，甚至分析個性與動機。這既不可靠，也可能傷害合作關係。
比較穩妥的方式，是只記錄可查證的工作資訊：正式職責、決策權、受影響方式、需要的資訊與下一步。
溝通優先序可以用「決策影響力」與「受影響程度」安排，但這是為了分配溝通資源，不是替人排名。
主管、執行者、使用者在意的順序不同
主管版應先給結論，再說明業務影響、風險、選項、建議與決策期限。技術細節可以放附件。
執行版則要把任務寫清楚，包括已知條件、輸入資料、依賴、完成標準、回報位置與停止條件。
使用者版應回答最實際的問題：什麼功能受影響、現在要做什麼、是否有替代流程、遇到問題找誰，以及何時會有下一次更新。
外部合作方只需收到履約需要的資訊。內部對責任、風險與人員的討論，不應順手放進附件。
每一則訊息都要有明確行動要求
「以上供參」很安全，卻經常無法推動工作。
有效的行動要求要回答四件事：誰、做什麼、何時以前、在哪裡回覆。若日期尚未被接受，就應寫成要求期限或待確認，而不是正式承諾。
同樣地，被副本不代表接受任務，沉默也不代表同意。AI只能整理既有責任，不能替人承諾。
多版本最需要的是一致性檢查
訊息改寫完成後，建立一張簡單的交叉表，逐項比對狀態、影響數量、正式日期、暫定日期、決議、風險與下一次更新。
如果同一欄位在不同版本出現矛盾，不要叫 AI 猜哪個正確，而是回到來源確認。
這個步驟看似多花幾分鐘，卻能避免主管依 A 日期安排資源、使用者卻收到 B 日期公告的尷尬情況。
溝通有效，不等於通知越多
不同事件需要不同節奏。例行狀態可按週更新；風險超標、方案改變或狀態受阻時再觸發額外通知；重大決議完成後則應更新正式文件與舊公告。
真正要衡量的，不是 AI 一次生成幾封信，而是收件人是否理解自己的下一步、決策是否準時完成、澄清與重工是否下降。
AI負責整理，人負責權限與責任
AI很適合找出資訊缺口、調整表達深度、產生角色版本與檢查文字一致性。
但它不能自行判定誰有核准權、推測誰支持專案、宣布原因、承諾日期，或決定哪些敏感內容可以對外公開。
好的利害關係人溝通，不是把同一封信寫得更漂亮，而是讓正確的人在正確時間取得足夠資訊，並清楚知道下一步。
文末 CTA：
下次要寄專案更新前，先用本文的提示詞產生「共同事實底稿」與「一致性檢查表」。如果四個版本的日期和狀態對不起來，先別按下寄送。
逐步操作
第一步：先定義這次溝通要推動什麼
不要先叫 AI「幫我寫一封專案更新信」。先回答：
- 這次是單純知會、請求回覆、取得決策，還是要求執行？
- 收件人看完後，最晚何時要採取什麼行動？
- 如果沒有行動，會影響哪個里程碑、使用者或交付物？
一則訊息最好只有一個主要目的。若同時要主管核准、工程師查修、使用者配合，應拆成不同版本。
第二步：建立「共同事實底稿」
先把所有版本都必須一致的內容列出：
| 欄位 | 要填什麼 |
|---|---|
| 事件／專案 | 目前在談哪一件事 |
| 已確認事實 | 有來源或證據的內容 |
| 未確認資訊 | 假設、推測、待查項目 |
| 目前狀態 | 未開始、進行中、受阻、已提交、已驗收等 |
| 影響範圍 | 對象、數量、期間、功能 |
| 正式日期 | 已承諾或已核准的日期 |
| 暫定日期 | 尚待確認的預測 |
| 已有決議 | 誰在何時決定什麼 |
| 尚待決定 | 選項、期限及決策者 |
| 下一更新 | 何時、由誰更新 |
原始資料沒有的內容，一律標示「待確認」，不要讓 AI 補齊。
第三步：列出角色，不要急著替人貼標籤
可從這些角色開始：
- 決策者：能核准範圍、預算、資源或時程。
- 負責人：對成果負最終責任。
- 執行者：實際完成工作或查修。
- 諮詢者：提供專業意見、規則或審查。
- 受影響者：工作方式、服務或排程會改變。
- 外部合作方：供應商、客戶、顧問或承包商。
- 知會者：需要掌握結果，但不必參與細節。
如果某人的決策權沒有正式依據，就寫「待確認」，不要因職稱自行推定。
第四步：用兩個維度安排溝通優先序
比起用「支持／反對」評論個人，更安全的是評估：
- 決策影響力： 此角色能否改變範圍、資源、期限或風險處理？
- 受影響程度： 此角色的工作、服務或責任會受到多大影響？
可分成四區：
| 類型 | 建議溝通方式 |
|---|---|
| 高影響力＋高受影響 | 提前溝通、確認理解、保留回覆與決議紀錄 |
| 高影響力＋低受影響 | 提供短摘要、明確決策題與風險 |
| 低影響力＋高受影響 | 提供實際影響、操作方式、支援入口與更新時間 |
| 低影響力＋低受影響 | 里程碑式知會，避免過度通知 |
這個分類是工作設計，不是人物價值排名。
第五步：確認每個角色的三個問題
對每個角色回答：
- 他必須知道什麼，才能完成職責？
- 他需要決定或執行什麼？
- 哪些細節對他無幫助，甚至不應揭露？
例如主管需要知道影響、選項、風險與決策期限；工程師需要重現條件、日誌位置及驗證標準；現場使用者需要知道受影響功能、替代流程與支援窗口。
第六步：把資訊分成三層
- 必須知道： 不知道就無法決策、執行或避免風險。
- 需要時知道： 可放附件、連結或附錄，不必塞進正文。
- 不宜揭露： 個資、帳密、未公開財務、資安弱點、內部評論、合約限制資訊。
AI可以幫忙分類，但最終應由資料擁有者或主管確認揭露界線。
第七步：替不同角色設計訊息結構
主管／決策者版：
結論 → 業務影響 → 已做處理 → 選項 → 建議 → 最晚決策時間
執行團隊版：
任務 → 已知條件 → 輸入與證據 → 完成標準 → 依賴 → 回報方式
受影響使用者版：
發生什麼 → 影響什麼 → 現在要做什麼 → 替代方式 → 下一次更新
外部合作方版：
合約／交付範圍 → 待提供項目 → 格式與期限 → 驗收方式 → 正式窗口
第八步：選擇適當管道
- 即時聊天： 簡短協調、低風險確認、快速同步。
- Email： 正式請求、跨組織溝通、需要留存紀錄。
- 專案工具： 任務、狀態、依賴、驗收證據。
- 會議： 有取捨、異議或需同步理解的決策。
- 公告／知識頁： 多人需要一致查看的操作說明與最新狀態。
重要決議若先在聊天或口頭完成，仍應回寫正式紀錄。
第九步：設定溝通節奏，而不是一直群發
節奏應依事件與需求設定：
- 例行：每日、每週或里程碑更新。
- 事件觸發：狀態轉為受阻、風險超標、方案改變。
- 決策觸發：需要在某日期前選擇方案。
- 恢復觸發：技術恢復、業務驗證完成、正式結案。
不要因為「怕有人不知道」就每天寄給所有人。
第十步：先產生共同摘要，再產生角色版本
請 AI 先輸出 150 字內的共同摘要，再依角色改寫。這能減少多版本之間的漂移。
每個版本都要保留：
- 同一狀態
- 同一正式日期
- 同一數字與單位
- 同一決議
- 同一風險等級
- 同一下一更新時間
可省略細節，但不能改變事實身分。
第十一步：使用「行動要求」結尾
不要只寫「以上供參」。清楚說明：
- 誰要做什麼？
- 最晚何時？
- 用什麼格式或管道回覆？
- 不回覆時代表什麼？
除非已有正式規則，不能寫「未回覆視為同意」。比較安全的寫法是：「若期限前未取得決定，原定排程將維持待確認，並於下一次會議重新排定。」
第十二步：建立多版本一致性表
| 核心欄位 | 主管版 | 技術版 | 使用者版 | 外部版 | 是否一致 |
|---|---|---|---|---|---|
| 目前狀態 | |||||
| 影響數量 | |||||
| 正式日期 | |||||
| 暫定日期標示 | |||||
| 已有決議 | |||||
| 下一更新 |
只要出現差異，就回到共同事實底稿查證，不要讓 AI 自行選一版當正確答案。
第十三步：設置人工閘門
以下內容發布前必須人工確認：
- 正式承諾、交期、預算及範圍變更
- 人員責任與績效描述
- 客戶、合約、法律、財務及資安內容
- 對外事故原因與責任歸屬
- 可能造成停機、退款、賠償或重大營運影響的指示
- 收件人、密件副本與附件權限
第十四步：先小範圍試行
第一次使用時，挑一個低風險專案：
- 由 AI 產生四種角色版本。
- 由專案經理與一位熟悉背景的人交叉檢查。
- 記錄被修改的事實、語氣與行動要求。
- 下次把常見修改加入提示詞規則。
第十五步：每月檢查溝通是否有效
可以追蹤：
- 需要再次澄清的比例
- 因資訊不一致造成的重工次數
- 決策是否在期限內完成
- 收件人是否能說出自己的下一步
- 訊息被大幅人工改寫的比例
- 過度通知與漏通知事件
- 敏感內容或錯誤收件人的事件數
真正的成果不是「寄出更多訊息」，而是讓正確的人及時理解並採取正確行動。
可直接複製的完整提示詞
你是一位資深專案經理、利害關係人溝通顧問、技術寫作者與資訊治理審查者，擅長把同一組專案事實整理成適合不同角色的溝通版本，同時維持狀態、數字、日期、決議與風險的一致性。
【任務】
請根據我提供的原始資料：
1. 建立共同事實底稿。
2. 辨識利害關係人及其工作角色，不得臆測個性或政治立場。
3. 分析每個角色需要知道、需要決定、需要執行及不宜揭露的內容。
4. 建議溝通管道、節奏、責任人與回覆方式。
5. 產生主管、執行團隊、受影響使用者及外部合作方版本。
6. 檢查所有版本的事實、數字、日期、狀態與決議是否一致。
【專案基本資料】
專案／事件名稱：[填寫]
這次溝通目的：[知會／請求回覆／取得決策／要求執行／其他]
目前階段：[填寫]
下一個重要里程碑：[內容與日期]
正式資訊來源：[文件、系統、會議決議或連結]
本次內容負責人：[填寫]
正式核准人：[填寫；不明則填待確認]
允許使用的溝通管道：[Email／聊天／會議／專案工具／公告]
敏感資訊限制：[填寫]
【原始資料】
請使用以下格式貼入：
來源編號｜日期時間｜來源類型｜提供者角色｜原始內容｜證據／連結｜可信狀態
[貼上匿名化資料]
可信狀態只能使用：
- 已確認
- 待驗證
- 個人意見
- 假設
- 正式決議
【已知利害關係人】
角色編號｜角色／群體｜正式職責｜已知決策權｜受影響方式｜必須知會事項｜限制
[貼上資料；沒有則填無]
【需要產生的版本】
版本｜對象｜目的｜長度｜管道｜希望對方採取的行動｜最晚時間
[例如：主管版｜專案贊助人｜取得方案核准｜200字內｜Email｜回覆A或B｜9月18日17:00]
【共同事實欄位】
目前狀態：[填寫]
已確認影響：[填寫]
正式日期：[填寫；沒有則填無]
暫定日期：[填寫；沒有則填無]
已完成處理：[填寫]
已確認原因：[填寫；沒有則填尚未確認]
目前風險：[填寫]
已有決議：[填寫]
尚待決定：[填寫]
下一次更新時間：[填寫]
【分析與寫作限制】
1. 只使用我提供的事實，不得補造人名、日期、數字、原因、責任或決議。
2. 每項重要說法保留來源編號；無來源時標示待確認。
3. 區分已確認事實、待驗證資訊、意見、假設及正式決議。
4. 不得把暫定日期改寫成正式承諾。
5. 不得把技術恢復寫成業務已完全恢復，除非已有業務驗證。
6. 不得把「已寄出、已上傳、已處理」寫成已驗收完成。
7. 不得因職稱自行推定決策權、核准權或責任歸屬。
8. 不得用「支持、反對、難合作」等標籤評論個人，除非有正式紀錄且任務確實需要；即使有，也優先描述可觀察行為與未解問題。
9. 不得把沒有回覆視為同意、拒絕或消極。
10. 不得根據語氣推測情緒、動機或政治立場。
11. 可依角色調整順序、深度、用語與行動要求，但不得改變核心事實。
12. 主管版聚焦影響、選項、風險、建議與決策期限。
13. 執行版聚焦任務、輸入、條件、依賴、完成標準與回報方式。
14. 使用者版聚焦實際影響、現在要做什麼、替代流程、支援入口與下一更新。
15. 外部合作方版只保留與正式交付、依賴、期限、驗收及窗口相關的必要資訊。
16. 每個版本只設定一個主要目的；若有多個目的，建議拆分。
17. 行動要求必須包含對象、動作、期限及回覆管道；資料不足時標示待確認。
18. 不得自行設定「未回覆視為同意」。
19. 正式決議應包含決策者、日期、範圍及附帶條件。
20. 對外訊息不得揭露內部個人評論、未修補資安弱點、帳密、內網位址或不必要的系統細節。
21. 移除或遮罩姓名、Email、電話、帳號、客戶代碼、設備識別碼及機密金額。
22. 涉及法律、合約、財務、資安、職安、個資、人資或客戶責任時，標示需專責人員審查。
23. 所有寄送、公告、承諾、升級及對外說明都必須經人工確認。
24. 若來源互相衝突，列出差異，不得自行選擇看似最新的說法。
25. 若同一版本資訊過多，將補充資料移至附件或連結，不可直接刪除必要風險。
26. 使用繁體中文，語氣專業、友善、直接，不責怪個人，不浮誇。
【輸出格式】
一、共同事實摘要
以150字內說明目前狀態、影響、已做處理、尚待決定及下一更新。
二、事實與證據表
| 編號 | 內容 | 資訊類型 | 來源 | 日期 | 信心／狀態 | 可否對外使用 | 待確認 |
三、來源衝突
| 主題 | 來源A說法 | 來源B說法 | 可能影響 | 建議確認人 |
四、利害關係人清單
| 角色編號 | 角色／群體 | 正式職責 | 決策權依據 | 受影響方式 | 資訊需求 | 待確認 |
五、影響力與受影響程度
| 角色 | 決策影響力 | 受影響程度 | 判斷依據 | 建議參與方式 |
若沒有依據，不得給高低評分，請標示待確認。
六、資訊分層
| 角色 | 必須知道 | 需要時知道 | 不宜揭露 | 理由 |
七、溝通計畫
| 角色 | 溝通目的 | 管道 | 時機／頻率 | 內容負責人 | 期望行動 | 回覆期限 | 完成證據 |
八、主管／決策者版
依「結論、影響、已做處理、選項、建議、決策期限」輸出。若無正式建議權限，將建議標示為提案。
九、執行團隊版
依「任務、已知條件、輸入與證據、完成標準、依賴、回報方式」輸出。
十、受影響使用者版
依「發生什麼、影響什麼、現在要做什麼、替代方式、支援入口、下一更新」輸出，避免不必要的技術細節。
十一、外部合作方版
依「正式範圍、待提供項目、格式、期限、驗收方式、窗口」輸出；沒有外部對象則標示不適用。
十二、短訊版
提供100字內版本，適合聊天群組；仍須保留狀態、主要影響、行動要求與下一更新。
十三、多版本一致性檢查
| 核心欄位 | 共同底稿 | 主管版 | 執行版 | 使用者版 | 外部版 | 結果 |
至少檢查狀態、影響數量、日期、決議、風險及下一更新。
十四、敏感資訊與人工閘門
| 內容 | 風險 | 可採取處理 | 需要誰核准 |
十五、缺漏問題
依「不確認就可能造成的影響」排序，最多列出10題，不得自行回答。
十六、發布前人工確認清單
列出收件人、事實、附件權限、日期、行動要求、審查與一致性等檢查項目。
可替換欄位快速版
只要先準備這七項，就能開始：
[專案／事件名稱][這次溝通目的][共同事實與來源][對象、正式職責與已知決策權][希望各對象採取的行動][正式日期、暫定日期與下一更新][敏感資訊及核准限制]
實際教學範例
情境
半導體測試區的遠端 KVM 畫面偶爾無法取得，影響 RPA 自動操作。技術團隊已完成第一輪處理，需要同時更新主管、RPA 工程師、現場值班人員及 KVM 供應商。
原始資料
| 來源 | 時間 | 內容 | 狀態 |
|---|---|---|---|
| S-01 | 9/11 09:10 | 50 台設備中有 6 台無法取得 KVM 畫面 | 已確認 |
| S-02 | 9/11 09:25 | KVM 重啟一次後，4 台恢復 | 已確認 |
| S-03 | 9/11 09:40 | 剩餘 2 台重啟第二次仍未恢復，已轉人工操作 | 已確認 |
| S-04 | 9/11 10:20 | 工程師懷疑新版韌體與連線逾時有關 | 待驗證假設 |
| S-05 | 9/11 11:00 | 主管要求先維持生產，不核准全面停機升級 | 正式決議 |
| S-06 | 9/11 14:00 | 供應商預計 9/12 中午前回覆日誌分析 | 暫定預測，待對方確認 |
| S-07 | 9/11 15:00 | 下一次內部狀態更新為 9/12 15:00 | 已確認 |
共同事實摘要
50 台設備中有 6 台曾無法取得 KVM 畫面，首次重啟後 4 台恢復；其餘 2 台已切換人工操作，生產目前持續。原因尚未確認，韌體與逾時僅為待驗證假設。依主管決議暫不全面停機，下一次內部更新為 9/12 15:00。
利害關係人溝通地圖
| 對象 | 主要需要 | 不必放入正文 | 期望行動 |
|---|---|---|---|
| 主管 | 生產影響、目前風險、是否需決策 | 完整日誌與指令細節 | 確認維持現行處置；風險變化時再決策 |
| RPA 工程師 | 受影響設備、重現條件、處理紀錄、驗證標準 | 管理層背景說明 | 比對失敗時間與連線紀錄 |
| 現場值班人員 | 哪 2 台需人工操作、如何回報、停止條件 | 未驗證的韌體推論 | 依核准流程操作並記錄結果 |
| KVM 供應商 | 必要日誌、型號、版本、發生時間、待回覆問題 | 內部決策討論與人員評論 | 確認收件並提供回覆時間 |
主管版
主旨：KVM 畫面異常處理進度—目前生產維持，暫無需新增決策
50 台設備中有 6 台曾無法取得 KVM 畫面，4 台經首次重啟後恢復，其餘 2 台已切換人工操作，目前生產持續。原因仍在確認，尚不能判定為韌體問題。依 9/11 決議，現階段不全面停機升級。若受影響設備增加、人工操作無法維持，或出現品質風險，將立即提出停機或回復方案。下一次更新：9/12 15:00。
RPA 工程師版
任務：比對 6 台異常設備的 KVM 連線與 RPA 失敗紀錄
請以 S-01 至 S-03 的設備清單與時間為基準，整理：首次失敗時間、KVM 重啟結果、RPA 重連結果、逾時訊息及目前操作模式。韌體關聯仍屬假設，不得先列為根因。完成標準為每台設備都有時間線、日誌連結與可重現／不可重現狀態。建議要求於 9/12 13:00 前回寫專案紀錄；此時間是待負責人接受的提議，不是既有承諾。
現場值班版
目前有 2 台設備改採人工操作，請依既有核准 SOP 執行並記錄每次操作結果。若畫面再次中斷、人工流程無法完成，或出現品質與安全疑慮，請停止重複嘗試並通知值班主管及 RPA 窗口。請勿自行升級韌體。下一次狀態更新為 9/12 15:00。
供應商版
主旨：請協助確認 KVM 畫面中斷問題及回覆分析時程
我方 50 台設備中有 6 台於 9/11 09:10 前後發生畫面無法取得；首次重啟後 4 台恢復，另 2 台仍需人工操作。附件提供已匿名化的型號、版本、發生時間與必要日誌。請先確認資料是否足夠，並回覆預計可提供初步分析的時間。9/12 中午目前僅為我方紀錄的暫定時間，請貴方正式確認。若需其他資料，請依設備編號列出欄位與期間。
一致性檢查
| 欄位 | 四個版本是否一致 | 說明 |
|---|---|---|
| 影響數量 | 是 | 6 台發生、4 台恢復、2 台人工操作 |
| 根因狀態 | 是 | 尚未確認；韌體只是待驗證假設 |
| 生產狀態 | 是 | 生產維持 |
| 停機決議 | 是 | 現階段不全面停機 |
| 下一更新 | 是 | 9/12 15:00；外部版不必揭露內部更新時間亦不構成衝突 |
| 供應商回覆 | 是 | 暫定、待供應商正式確認 |
AI不能自行做的事
- 把「懷疑韌體」寫成「根因是韌體」。
- 把供應商預計回覆時間寫成正式承諾。
- 因主管決定不停機，就寫成「風險已解除」。
- 對外揭露設備識別碼、內網位址或完整未遮罩日誌。
- 替工程師接受 9/12 13:00 的期限。
- 把同一份長訊息直接複製給所有角色。
常見錯誤、隱私與使用注意事項
常見錯誤
- 先寫四個版本，沒有共同底稿： 最容易造成日期與數字漂移。
- 把角色當人格分析： 利害關係人地圖應記錄職責與影響，不是猜誰難合作。
- 把所有人都列為高優先： 等於沒有優先順序，也會造成通知疲勞。
- 主管版只有進度： 沒有影響、選項、建議與決策期限，主管仍不知道要做什麼。
- 執行版只有一句「請處理」： 缺少輸入、條件、完成標準與回報位置。
- 使用者版技術細節過多： 使用者更需要影響、替代方式與支援入口。
- 對外版交代過多內部討論： 只應提供合作方履約所需的資訊。
- 同一群組同時要求三種行動： 責任分散，容易全部沒人接。
- 用副本代替責任指派： 被副本不代表對方已接受任務。
- 將未回覆視為同意： 除非已有明確正式規則，否則不能這樣設定。
- 只檢查語氣，不檢查事實： 文字流暢不能補救錯誤日期或錯誤狀態。
- 忘記更新舊版本： 新決議發布後，舊公告與知識頁仍可能誤導使用者。
資料隱私
送進 AI 前建議移除或遮罩：
- 真實姓名、私人聯絡方式及人事評語
- 客戶名稱、合約編號、報價與未公開財務資料
- 帳號、密碼、API 金鑰、驗證碼與權限資訊
- 設備序號、內網位址、完整日誌及未修補資安弱點
- 病歷、身分證字號、付款資料及其他敏感個資
- 未公開產品、併購、法務爭議或稽核內容
應依公司核准的 AI 工具、資料分類與保留政策處理。若不確定，先用虛構或匿名化資料測試提示詞。
使用注意事項
- AI輸出先視為草稿，不可直接寄送或公告。
- 正式日期、責任、範圍、決議及收件人要人工逐項確認。
- 法律、合約、資安、財務、人資與客戶事故內容需專責審查。
- 溝通計畫不是監控個人的工具，不應作為未經查證的績效評價。
- 角色與影響會隨專案階段改變，應在重大變更後重新檢查。
- 重要決策須保留原始來源與正式紀錄，不能只留 AI 摘要。
- 若訊息已涉及立即安全或重大營運風險，依正式通報流程處理，不要等待 AI 完成整理。
留言