別再叫 AI「總結」這次對話了 : 用起承轉合做對話回顧，價值差十倍

為什麼條列式摘要會丟掉最值錢的東西

我做了一個小實驗。

同一段對話 : 大概 40 分鐘的系統設計討論，中間我推翻過兩次方向，最後落在一個跟一開始完全不同的方案 : 我用兩個 prompt 分別請 AI 收尾。

Prompt A：「請總結這次對話。」

得到的東西大概是這樣：

重點摘要

• 討論了系統 X 的設計
• 評估了三個方案（A、B、C）
• 最終決定採用方案 C
• 後續行動：建立資料模型、設計介面、規劃 12 週開發

關鍵決策

• 採用方案 C 因為符合需求
• 確認資料模型有 7 張表
• 確認三個核心介面

工整、清楚、可貼進 Notion。讀完三個月後，我完全不記得當初為什麼選 C。

Prompt B：「用起承轉合分析這次對話，特別把推翻自己的時刻列出來。」

得到的東西大概是這樣：

起：從 80 項 todo 開始

使用者一開始丟了一份 80 項的混亂清單，我沒有立刻挑一項解決，而是先把它分成 10 個主題。這個動作本身揭露了一件事：使用者真正在意的是「整合既有工具」，不是「打造新東西」。

承：四層現實逐步加入

從抽象架構出發，加入現況（既有的 setting.yml、k8s repo、Excel 安裝檢查清單），再加入交付場景（air-gap on-prem），最後加入角色矩陣。每加一層，設計變得更具體、不更通用 : 這跟一般「越設計越想做通用」的習慣相反。

轉：六次自我推翻

1. 第一次：以為要打造新系統，後來發現是「既有工具的中央索引」
2. 第二次：以為要做資料管理，後來發現要做「協助交付團隊上戰場」
3. 第三次：設計了 PSP × Distr 整合方案後，使用者問「真的還需要 Distr 嗎？」 : 把自己一千行的設計推翻了。原來那個方案恰好證明了 Distr 只剩次要功能
4. 第四次：再次確認市場真的沒有 air-gap PSP，才敢繼續自建
5. 第五次：使用者反問「自建這麼小的東西，憑什麼？」 : 從成本論證升級到價值論證
6. 第六次：「MVP 是戰術，自建 vs 買是戰略」 : 兩件事不衝突

合：12 週 MVP 計畫

7 張資料表、3 個核心介面、12 週工作分解、5 個 day-1 架構決策。但同樣重要的是「不做清單」：tickets/KB、telemetry、AI agent、自助入口。

讀完三個月後，我完整記得當初為什麼選 C。更重要的是 : 我能跟沒參與的同事完整解釋，他們也能看出推理路徑。

兩個 prompt 看起來只差幾個字，輸出的價值差了十倍。

後面這個 prompt 對應的方法，我稱為 起合回顧法（Frame Retrospective） : 用敘事結構保留對話的思考脈絡，而不只是條列結論。

為什麼敘事結構贏

這不是文學偏好，是認知科學。

人腦記憶敘事比記憶列表強得多。一段「我從 A 開始、遇到 B、推翻成 C、最後落在 D」的故事，比「結論：D；理由：B 不適用、C 也不適用」的條列要好記、好分享、好傳承。

更深一層的差別在於：

條列摘要的盲點在於：它假設只有結論值得記。但真正讓你能解釋、能複製、能傳承的，是「為什麼不是別的選項」 : 而那些都活在被推翻的中間版本裡。

第三幕「轉」是靈魂

起承轉合裡，「轉」是這個結構的核心。

「起」是設定脈絡、揭露混亂。
「承」是建構想法、加入現實層次。
「合」是產出可執行的東西。

這三幕做好就是一份不錯的工作日誌。

但「轉」是別的東西 : 它是質疑與推翻的時刻。沒有「轉」，回顧就只是流水帳。

回頭看那六次推翻：

「照你剛剛的設計，真的還需要 Distr 嗎？」

這句話只有十幾個字。但這句話讓接下來的決策完全不同。如果用「請總結」收尾，這個瞬間會被丟掉 : 因為它不是結論，只是「過程中的一個轉折」。

而對話真正的價值，就在這些轉折裡。

這也是為什麼我會堅持要 AI 把推翻時刻明確列出來、編號、不要美化。每一次推翻都是一個被驗證過的決策邏輯，可以變成下次遇到類似情境的起點。

完整 prompt 模板

完整版（中文）

把本次聊天範圍內的討論做分析，整理起承轉合的每個有價值的產出，
思考的脈絡。

要求：
1. 每幕（起、承、轉、合）下面說明：使用者帶來什麼、產生了什麼、
   轉場訊號是什麼
2. 第三幕「轉」要明確列出每個推翻時刻（編號 1, 2, 3...），不要美化
3. 萃取 meta-lessons：哪些思考動作讓這次對話有效
4. 最後一句濃縮整個決策軌跡
5. 給 2-3 個可執行的 next steps

完整版（英文）

Analyze our discussion in this chat and organize the valuable outputs 
and thinking flow as a four-act narrative 
(Setup → Develop → Reframe → Converge).

Requirements:
1. For each act, describe: what the user brought, what was produced, 
   the transition signal
2. In Act 3 "Reframe", explicitly list each turning point with numbers 
   (1, 2, 3...). Don't smooth them over.
3. Extract meta-lessons: what thinking moves made this conversation work
4. Distill the entire decision trajectory in one sentence
5. Provide 2-3 concrete next actions

極簡版（記不住時用這個）

用起承轉合分析這次對話，特別把推翻自己的時刻列出來。

三個版本可以依場合切換。重要對話用完整版，日常用極簡版。

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

不是每段對話都該做回顧。誤用比不用更糟。

該用：

• 對話跨越 30 分鐘以上、產出多個重要決策
• 要分享給沒參與的人（主管、團隊、新人）
• 需要在未來重新拿出來看的決策
• 內容會影響長期方向（產品策略、架構選擇）
• 想內化思考方法，不只是結論

別用：

• 簡單問答（「Spring Boot 的 JWT lib 哪個」）
• 純執行性任務（「幫我改這段 code」）
• 短對話（5 分鐘內）
• 純資訊查詢（「莫札特的死因」）
• 沒有決策成分的對話

判斷規則：對話結束時問自己「未來會想再看這段對話嗎？」如果是，做回顧。如果不是，直接關掉。

三個常見反模式

反模式 1：套框架而不看內容

症狀：硬把對話塞進起承轉合，即使根本沒有真正的「轉」。

對策：誠實標記「這次轉的份量很輕」，不要捏造推翻時刻來填充框架。如果這次對話沒有推翻，那是訊息 : 可能代表沒有充分挑戰假設，下次該更刻意質疑。

反模式 2：把回顧寫成績效報告

症狀：強調「做對了什麼」、避開「推翻了什麼」。

對策：強迫自己列出至少一個推翻時刻。被推翻的版本不是失敗，是抵達當前結論的必要路徑。一份美化過的回顧，跟條列摘要一樣沒用。

反模式 3：寫太長沒人讀

症狀：產出 5000 字精美 markdown，自己讀過一次就再也沒打開。

對策：開頭先寫 200 字 TL;DR，把整段旅程濃縮成一句話。這句話本身就是回顧的最大價值 : 其他都是支撐這句話的證據。

進階：對回顧本身做回顧

起合回顧法有個常被忽略的特性 : 它可以遞迴用在自己身上。

當你已經做過幾次對話回顧，可以再貼這個 prompt：

用起承轉合分析我「上次做的那次回顧」本身 : 
當時的結構合理嗎？哪些「轉」被我略過？
回顧本身有什麼盲點？

這層 meta 回顧會揭露：

• 你的回顧結構有沒有變得程式化（每次都套同樣標籤但內容貧乏）
• 哪些重要轉折被當時的你忽略了（因為對話進行時沒意識到）
• 你對「什麼算推翻」的判斷標準有沒有偏誤

當你開始對方法本身做回顧，方法就從「工具」升級成「持續演化的習慣」。 第 6 篇會把這個遞迴特性展開到五層。

試一次

下次結束一段重要對話時，先別關。貼那個極簡版 prompt：

用起承轉合分析這次對話，特別把推翻自己的時刻列出來。

如果出來的東西讓你覺得「啊，原來經歷了這些」 : 那就是這個習慣的價值。

如果出來的東西讓你覺得「好像沒什麼可推翻的」 : 那也是訊息。可能下次該更刻意質疑自己的中間版本。

兩種結果都比「請總結」有用。

可帶走的句子

結論的價值有限，怎麼到結論的才是資產。

下一篇：《在 AI 給你建議之後，你應該做的一件事：派它出去查、回來對照》

歡迎來找我討論 : https://tw.linkedin.com/in/enjtorian