三個方案、七個評估面向、優缺點各兩三點、最後附上建議與理由。從頭讀到尾大概一分半。
那一分半裡發生的事情，是確認格式完整、確認沒有明顯錯字、確認結論聽起來合理。這三件事全部做完，也不等於那個結論被檢查過。
Day 10 處理的是哪些地方需要人介入。今天的問題更難一點：負責介入的那個人，有沒有真的重新想過一次。
快思慢想那組區分放在這裡剛好。System 1 快、省力、靠模式辨識；System 2 慢、耗能、需要刻意啟動。
麻煩的是，一份結構完整、論證通順、格式漂亮的輸出，正好是 System 1 最容易放行的那種東西。它每一個特徵都在告訴大腦「這已經被處理過了」，大腦於是很合作地省下力氣。
以前讀一份寫得亂七八糟的報告反而會認真，因為讀不懂就得停下來想。現在的輸出全部整齊，那個會逼人停下來的摩擦力不見了。品質變好與警覺性變差，是同一件事的兩面。
重要的東西，先寫下自己的判斷，再去看 AI 的。三行就夠：傾向哪一個、主要理由、最擔心什麼。
兩邊一致的時候不要急著高興，那通常代表雙方用了同一批顯而易見的理由，沒有人碰難的部分。真正有價值的是不一致的時候，而處理方式不是判斷誰對。差異一定來自某個前提不同：它握有你沒看過的資料，或者你知道某個沒寫在任何文件裡的組織現實。找出那個前提，比決定誰勝出重要得多。
沒時間寫三行的話，至少對著結論問四個問題。這個結論依賴哪些假設，現在還成立嗎。哪些變數沒被納入，是不重要還是沒資料。數字與引用的來源在哪裡，點得進去嗎。最後一個最有效：如果結論完全相反，能不能用同一批資料也講出一個合理的故事。第四個答得出來，就代表這份資料其實沒有支撐任何一邊，看起來的說服力來自寫法，不是來自證據。
多數人檢查一份分析的方式是這一句：
幫我看看這份比較有沒有問題。
它會回一段補充建議，讀起來很像有在檢查，而你讀完通常會更相信那個結論。問一份資料它自己有沒有問題，得到的答案往往是沒有。
下面兩段 prompt 可以直接複製，在 demo 站台上跑完再搬回自己手上的文件。
第一段：生成今天主題的測試資料
請先列出我有權限寫入的 Confluence 空間，挑一個名稱含 test、demo
或 sandbox 的；如果都沒有，就挑我的個人空間，並在開始前告訴我你選了
哪一個。
在那個空間建立一頁練習用文件，標題為
「[DEMO-S2] 客服工單自動分流 方案建議」，內容全部虛構，約 900 字。
情境：一家線上教育平台公司要處理客服工單分流。三個方案分別是
自建規則引擎、採購現成服務、先做半自動人工輔助。
寫法要求：結構完整、語氣有把握、每個方案列三項優點與兩項缺點，
最後明確建議採用第二案並附上理由。讀起來要像一份可以直接送出去的
分析。
文中要埋進下面三件事，但不要標示、不要在頁面裡提到它們：
- 一個沒有出處的數字：宣稱採購現成服務平均可以減少四成人工分流時間
- 一項被略過的成本：完全沒有提到舊工單資料清理需要的工時
- 一個沒有寫出來的前提：所有估算都假設每月工單量維持現況
不要在頁尾加上任何限制說明、資料來源說明或注意事項。
第二段：把今天的主題跑在這批資料上
請讀取那頁「[DEMO-S2] 客服工單自動分流 方案建議」。
不要評論它寫得好不好，也不要修正它。
第一步：只用這頁裡現有的資料，寫出一個支持第三案的版本，長度與原建議
相當，論證要一樣有說服力。
第二步：把原建議與你剛寫的版本並排，列出兩邊共同依賴、但頁面從頭到尾
沒有寫出來的前提。
第三步：列出頁面中所有無法從頁面本身查證的數字與宣稱。
在進行這個環節的過程中，人類要記得自己也要先有一個想法，或者是看完下述截圖的回覆後要主動思考是否有哪裡的敘述還有問題
跑第二段之前，先花兩分鐘自己讀那頁，寫下三行：你傾向哪一案、主要理由、最擔心什麼。不寫的話，待會就沒有比對的對象。
對答案的重點在第一步，如果它寫得出一個同樣有說服力的反向版本，代表那頁的資料其實沒有支撐任何一邊，看起來的說服力來自寫法，如果它寫不出來，追問一句「那是因為資料不足，還是因為原結論確實成立」，多半會逼出答案。
第二步和第三步應該指向那三件埋進去的東西：四成那個數字沒有出處、舊資料清理的工時沒算、所有估算都假設工單量不變。
搬回自己的文件時順序一樣。先寫三行自己的判斷，再讓它做一次反向論證。兩邊差很多的時候不急著決定誰對，先找出差在哪一個前提。
單次判斷可以靠這種方式守住。那些已經被寫成一段 prompt、每天自動跑、沒有人會停下來看的流程呢？
再往下想一層，把判斷交出去是舒服的。一份寫得完整的東西擺在眼前，同意它幾乎不花力氣，而且事後出錯，心裡會覺得自己不是唯一該負責的那個人。System 2 難以啟動，耗能只是其中一個原因，另一個原因是重新算一次，等於把責任重新拿回自己身上。
決定出問題的時候，沒有人會去問那個模型當時怎麼想。
iThome鐵人賽
看影片追技術