我的 AI 對自己的問題下了一個很合理的診斷，而它是錯的

文章頁的版面在載入時會跳動。Lighthouse 給的 CLS 是 0.303，而 0.1 以上就算差。

我的自動營運系統把原因寫進了紀錄檔：

文章頁 CLS 0.303，來源是 .prose img 缺 width/height。要修得逐張取原始尺寸(125 張)，是獨立工作。

這個診斷看起來完全正確。圖片沒有宣告尺寸，瀏覽器不知道要留多少空間, 圖載進來就把後面的內容擠下去 —— 這是版面位移最經典的成因，任何一篇談 CLS 的文章都會先講它。

隔天真的動手時，我先做了一件事:數一數到底有幾張沒寫尺寸。

答案是 4 張。另外 155 張早就寫了。

那個診斷錯在哪

錯不在「圖片尺寸會影響 CLS」——那是對的。錯在它把一個熟悉的原因套上去，而沒有去看現場。

真正的原因是：那 155 張圖寫了尺寸，但寫的是錯的。

這些文章是 2017 年寫的，當年的 HTML 長這樣：

<img src="https://i.imgur.com/KXKbv0d.jpg" width="500" height="500">

作者寫 500x500 的意思是「我想讓它顯示成 500×500」,不是「這張圖本來就是 500×500」。

而那張圖的真實尺寸是 1361×738。

於是發生的事情是：

瀏覽器讀到 width="500" height="500"，依 1:1 的比例先留一塊正方形空間
圖片下載完成，真實比例是 1.84:1
瀏覽器改用真實比例重算高度 → 整塊區域的高度變了 → 後面所有內容位移

寫錯尺寸比不寫尺寸更糟。 不寫的話瀏覽器至少知道自己不知道;寫錯的話它會很有信心地保留一塊錯的空間。

我逐張抓了 119 個不重複網址的真實尺寸來比對:159 張裡有 145 張是錯的,91%。

為什麼這種錯誤特別危險

如果那個診斷是「不知道原因」，我會去查。

但它給的是一個合理、具體、而且可以直接開工的答案。照著做的話，我會花時間去補那 4 張缺的尺寸, 然後發現 CLS 幾乎沒動，然後開始懷疑是別的地方 —— 在一個已經被誤導的方向上繼續找。

錯誤的診斷比沒有診斷更貴，因為它會消耗掉你原本會用來懷疑的注意力。

而且這個錯誤的形狀很值得注意：它是把常見原因當成本案原因。 CLS 的常見成因就是缺尺寸，所以「缺尺寸」是機率上最好的猜測。猜測本身沒錯，錯在沒有在動手前用一行指令去驗證那個猜測。

那一行指令是這樣的，花不到十秒：

# 有幾張圖沒寫 width/height?
grep -o '<img[^>]*>' *.md | grep -vc 'width='

這不是「AI 不可靠」的故事

我想把這點講清楚，因為很容易被讀成那個結論。

那份紀錄是同一套系統寫的，而它也同時做對了很多事：它記下了 CLS 的確切數字、記下了受影響的選擇器、把這件事開成獨立任務、還在 STATUS 裡留了一句「新文章一律自己帶 width/height，不要再累積這個問題」。

那句預防性的備註是對的，而診斷是錯的。 兩者出自同一次思考。

人也會這樣。看到熟悉的症狀，腦子會直接跳到最常見的原因，然後把後續的觀察都往那個方向解釋。差別只在於:系統會把它的猜測寫成看起來很確定的一行字，存進檔案裡, 然後隔天的你會把那行字當成已經查證過的事實。

我改了什麼

一、動手修之前，先量。 不是量「問題有多嚴重」——那我已經有了(CLS 0.303)。是量**「我以為的原因，在現場成立嗎」**。這一步通常只要一行指令。這次如果先數一下，十秒就知道方向錯了。

二、紀錄裡把「量到的」跟「推測的」分開寫。 CLS 0.303、來源選擇器 .prose img 是量到的。 因為缺 width/height 是推測。它們寫在同一行，隔天讀起來就一樣可信。現在我要求推測要標明是推測。

三、修完之後，回頭改掉原本的診斷。 我在紀錄檔裡明確寫了「原診斷錯誤」，而不是默默把結論換掉。 因為下一次我需要知道的不只是正確答案，還有「我上次是怎麼想錯的」。

順帶一提，這件事還有一個尾巴。

尺寸全部改成真實值之後，有一頁的 CLS 從 0.303 降到 0.212,沒有歸零。我又查了一輪，發現那 0.212 是本機環境造出來的假象 —— 圖片放在 imgur, 而 imgur 的防盜連會擋 localhost 的 referer，圖載不進來就改渲染替代文字，尺寸不一樣，又是位移。

線上量，是 0。

所以同一個數字，先是被錯誤的診斷解釋過一次，又被錯誤的環境製造過一次。兩次我都差點照著它動手。