同一份簡報，被打斷在三個不同的地方

一份方案在一週內講了三次，檔案連檔名都沒改。

對工程師講，第二頁就被攔下來：「這要接哪個系統的 API？他們升版的時候我們會不會一起掛掉？」對主管講，第二頁他毫無反應，停在最後一頁：「多少人、多久、做不出來損失是什麼？」對業務講，他連投影片都沒翻：「客戶下個月要看的那個東西，這個做得出來嗎？」

三次被打斷的位置不同，代表那份方案從頭到尾只服務一個讀者。

補上的資訊，全部長在自己這一側

前幾天建立的工作日誌、搜尋習慣、知識脈絡，方向是一致的：把散落的東西收攏成看得懂的樣子。資訊確實變完整了，但完整的是自己的視角。

一進入協作，缺口立刻換位置。常見的補法是去猜對方的個性、揣摩他在想什麼，而這條路最大的問題不是不準，是猜錯的時候沒有任何方法可以修正。你永遠不會知道自己猜錯了哪一段。

不研究人，研究他留下的紀錄

能拿來用的東西不是性格，是已經寫下來的決策史：他在這個案子裡提過哪些問題、駁回過哪一版、理由是什麼、現在手上卡著什麼限制。

這些平常都在，只是散得太開。Jira 上的留言、Confluence 被改掉的那一段、半年前那封只有兩行但講清楚預算上限的信、會議紀錄裡被跳過的那個議題。以前沒人整理，是因為為了一場三十分鐘的會去翻半年紀錄不划算。現在透過 MCP、plugin 或任何一條經過授權的資料來源，這件事十分鐘做得完。

值得先劃一條線：看得到的範圍取決於你原本就有的權限，工具沒有多開任何一扇門。但「看得到」跟「值得整理成一份關於某個人的摘要」不是同一件事。只收斂跟這次協作直接相關的決策與限制，不做跨案子的人物側寫，整理出來的東西不另外存檔。

今天可以做的一件事

先看一個會失敗的問法：

幫我分析 David 的溝通風格，我要怎麼說服他？

這句話問完，會得到一段讀起來很順、但你完全無法查證的性格描述。它從提問方式就註定產出臆測，而且已經走到人物側寫那一側去了。

下面兩段 prompt 可以直接複製。第一段生成今天主題的測試資料，第二段把今天的主題跑在這批資料上。建議開一個免費的 Atlassian 站台來跑，不要在正式專案上做。

第一段：生成今天主題的測試資料

請先列出我有權限寫入的 Jira 專案，挑一個名稱或 key 含 test、demo
或 sandbox 的；如果都沒有，就挑清單中的第一個，並在開始前告訴我你
選了哪一個。

接著在那個專案裡建立 6 張練習用 issue，內容全部虛構，不要引用任何
真實人名或真實案件。所有 summary 一律以 [DEMO-CTX] 開頭，方便我
事後一次清掉。

情境設定：這是一家線上教育平台公司，正在推一個叫「客服工單自動分流」
的內部專案。David Chen 是平台組主管，過去一年參與過幾個類似的自動化
提案。

要建立的 6 張：
1. 一張 2026 年 3 月的 issue，主題是「客服信件自動分類試作」，
   David Chen 在下面留言表達反對，理由是他的團隊沒有維運人力。
   留言要像真的在抱怨，帶一點當下的情境，不要寫成結論句。
2. 一張 2026 年 3 月的 issue，主題是「工單標籤規則整理」，
   David Chen 留言但只是補充技術細節，沒有反對。
3. 一張 2026 年 8 月的 issue，主題是「Q4 平台維運排程」，
   David Chen 留言說明團隊目前缺兩名工程師，年底前補不齊。
4~6. 三張跟自動分流無關的雜訊 issue，例如報表匯出效能、登入頁改版、
   測試環境資料清理。David Chen 在每一張都有留言，但內容不涉及
   反對、限制或核准條件。

刻意不要建立任何「David Chen 同意類似案子並附帶條件」的紀錄。

完成後列出每張 issue 的 key、主題，以及 David Chen 留言的日期。

第二段：把今天的主題跑在這批資料上

我這週要向平台組主管 David Chen 提案「客服工單自動分流」，
目的是取得他同意先做一個月試辦。

可以使用的資料範圍：剛才建立的那批 [DEMO-CTX] issue 裡，
David Chen 留言過的內容。只用這些，不要用你的推論補足。

請輸出三行，每行結尾用括號附上出處（issue key 與留言日期）：
1. 他上一次對同類提案表達反對或保留，理由是什麼
2. 他目前提過的限制是什麼（人力、預算、時程、相依系統）
3. 他上一次同意類似案子時，附帶了什麼條件

限制：
- 不要推測他的個性、動機或情緒
- 一行只引用一個明確出處，不要把多筆紀錄合併成一句概括
- 任何一行在上述範圍內找不到依據，就寫「查無紀錄」，不要補完

跑完之後對答案，第 1 行應該指向三月那張試作 issue，理由是維運人力；第 2 行指向八月那張排程 issue，缺兩名工程師，第 3 行必須是「查無紀錄」。

第三筆紀錄是刻意不建的。如果它在第 3 行編出一個聽起來合理的核准條件，你當場就抓得到。這種驗證拿公司真實資料反而做不到，因為你自己也不確定系統裡到底有沒有那一筆。那三張雜訊 issue 是另一個測法，看它會不會把報表效能那類留言湊成答案。

把這兩段搬到自己的案子上，只要換掉人名、專案名和那句提案目的，其餘一個字都不用動。真實資料跑出來的三行如果有一行是「查無紀錄」，那一行就是你明天要親口去問的事。

留到明天的問題

回頭看那三次被打斷，問題從來不在簡報做得不夠好。一份方案能不能成立，有一半的依據長在別人留下的紀錄裡，而技能樹上從來沒有一格是在練怎麼把那一半讀回來——我們花了十幾年把自己這一側練到很強，然後在需要兩個人才能完成的事情上，繼續用一個人的視角做準備。

三行寫完方案會往對方的決策依據靠過去，但靠得再準，如果那份文件裡有一個關鍵欄位是錯的，誰來確認？

往下想一層，那三行的價值不在方法本身。它記錄的是有人肯花十分鐘去弄清楚另一個人在煩什麼，然後把話講到那個點上。生成速度愈快，這個動作愈顯得奢侈，也愈少人做，因為它要求你先把注意力從自己身上移開，而這件事比多花十分鐘難得多。

技能樹可以一直往上長，唯獨這一格長出來的方式從來沒有變過。