前言

「查核結果出來了,不管是什麼問題,直接照查核結果改掉不就好了？」

如果每個查核結果都直接照改，會出現一個問題：有些查核結果是「這句話講的規則有例外情況沒提到」，改的方式牽涉到要不要為了嚴謹加一段但書、犧牲一點文章的流暢度，這種取捨不是查核任務能替你決定的。這篇要講的是,拿到查核結果之後，怎麼分辨哪些可以直接動手改，哪些必須先跟人討論。

今日目標

• 理解「客觀錯誤」跟「判斷空間大」這兩種查核結果的本質差異
• 掌握三個判斷指標，用來快速分辨一條查核結果屬於哪一類
• 看到一組對照範例，示範同樣是查核結果，處理方式怎麼不同
• 建立習慣：修正之前先問「這是事實問題,還是呈現問題」

三個判斷指標

面對一條查核結果，可以用三個指標快速判斷它屬於「直接修」還是「先討論」：

指標一：改了之後,原本的陳述跟修正後的陳述是不是互斥的——如果原本寫的和正確答案是兩個互相排斥的陳述（例如版本號記錯、某個 API 行為描述反了），這是客觀錯誤，直接修正。如果原本的陳述本身沒有講錯，只是省略了一些細節或例外情況，這通常不是「錯」，是「不夠完整」，屬於判斷空間。

指標二：修正方式只有一種寫法,還是有多種可能的呈現方式——客觀錯誤通常修正方式很明確（把錯的版本號換成對的），呈現方式的問題往往有好幾種同樣合理的處理方式（要不要加但書、要不要換一個類比），選哪一種涉及對文章整體風格的判斷，不該由查核任務單方面決定。

指標三：這個修改會不會改變文章原本想表達的重點——如果修正只是換掉一個錯誤的技術細節，不影響論點本身，可以直接改。如果修正牽涉到「這個類比本來想強調的重點是不是還成立」，這種修改會動到論點的取捨，必須先討論。

• ❌ 不分青紅皂白全部直接改：查核結果說某個類比可能不夠精確，直接把類比整段拿掉重寫,沒有跟原作者確認這個類比原本想強調的重點是不是還有其他方式可以保留
• ✅ 先分類再處理：先判斷這是客觀錯誤還是呈現問題，客觀錯誤直接修正並告知修了什麼、依據什麼來源；呈現問題列出來，說明查核發現了什麼疑慮，讓人決定要不要調整以及怎麼調整

今日思考題

如果你收到一份查核報告，列出好幾個問題，你會怎麼決定哪些自己直接改、哪些要先跟利害關係人確認？

今日重點回顧

• 客觀錯誤（互斥陳述、修正方式明確、不影響論點）可以直接修正
• 判斷空間大的（省略但不算錯、呈現方式有多種選擇、牽涉論點取捨）要先列出來討論
• 三個判斷指標：是否互斥、修正方式是否唯一、是否動到原本的論點
• 修正之前先問「這是事實問題，還是呈現問題」，這個問題本身就能過濾掉大部分不該擅自處理的情況

明日預告

Day 13 會用一個具體案例，講一個技術主張查出來本身是對的，但呈現方式需要跟人討論的完整過程。

寫在最後

畫這條界線最容易犯的錯，不是把該直接修的留著沒改，而是把該討論的直接改掉——後者看起來效率更高，但代表擅自替別人做了一個不屬於自己權限範圍的決定。