以前我常疑惑，為什麼我看到的 bug 似乎比大多數人多得多。我每週輕易就能觀察到數百到數千個 bug，感覺什麼都不能正常運作，但和我聊過的大多數人卻都沒看到類似的情況。很長一段時間，我以為這跟我的電腦使用方式有關，但久而久之我才明白，其實大家遇到的是同樣的 bug，只是沒注意到而已。

如果你不是程式設計師，那樣看世界或許反而比較好（就像最好不要培養出對食物或酒太過挑剔的味覺一樣），但我認為對程式設計師來說，治好品質盲／Bug 盲是有幫助的。我已經在不少朋友和熟人身上做過這件事（方法就只是把 bug 指給他們看）。過個幾週，那些本來就有意願的人，通常也會開始注意到 bug。

因為我會注意到這類問題，所以在好幾份工作中，主管／副總／高層等等有時會請我去評估某個東西，他們想要的是一個比較有可能發現問題（並在必要時修掉或推動修復）的人的真實意見。有時我什麼問題也找不到（很可能只是問題不在我會注意的類型）。更常見的是，我會找到介於「輕微」到「中度」之間的問題。而有時候，問題會嚴重到甚至可以說那個東西根本就不能用。

我覺得最後這一類有點謎。當我去翻閱這個東西是怎麼變成這種狀態的相關討論時，通常會看到一連串內部留言，表示這東西很棒、運作得很好等等，但當我實際打開來試用時，卻發現它只有在你做了好幾個不直覺的迂迴操作後才會動。更可能的情況是，一般使用者不只根本無法使用，還會有一種又好笑又讓人抓狂的糟糕體驗，糟到會去跟朋友抱怨。

這篇文章的想法在我腦中大概放了十年左右，但我一直猶豫要不要寫出來，因為內心深處我總會懷疑，會不會是我在無意間觸發了大多數使用者不會遇到的奇怪邊界情況。但在看過越來越多產品上線後直接摔得四腳朝天、而使用者遇到的正是跟我看到的一模一樣的問題後，我不再認為一般來說我是因為做了正常使用者不會做的奇怪操作才遇到 bug。如果一個產品在我用起來感覺有嚴重缺陷，那它很可能就是真的有嚴重缺陷。而有了 LLM 的神奇加持，現在我甚至可以讓 LLM 在很多方面扮演一般使用者，來證明這些問題在各種不同情境下都能重現。

幾個例子

我不想舉任何與我工作職責是有關、要評估東西好不好用的具體例子，因為即使內部例子是出於建設性、無責備的本意，轉貼到外部時讀起來未必如此，所以我只舉幾個比較無關緊要、也比較缺乏有力佐證的「隨機」例子。

前陣子，我整理了一些網路搜尋查詢的結果，發現 Google、Bing 和 Kagi 的結果都很差。整體來說，主流搜尋引擎都沒能為這些查詢回傳好的結果，回傳的頁面充滿低品質的 SEO 垃圾內容，甚至有些根本就是詐騙網站。順帶一提，以上面提到的尺度來說，我會把這種情況歸為「中度」而非「嚴重」（嚴重的話會像是搜尋引擎有一半時間回傳 500 錯誤、大多數結果都是詐騙等等；我對「嚴重」的標準是一般使用者根本無法使用，而不只是體驗很差）。幾乎沒有人¹對我描述 Google 和 Bing 搜尋結果的方式有異議，但卻有人說我對 Kagi 的評價是錯的。有些情況下，人們把他們實際的搜尋結果傳給我看。在每個這樣的案例中，我都看不到任何好的結果（例如，對於季節預報的查詢，搜尋結果就沒有回傳最新的季節預報），而且充滿 SEO 垃圾。有一個案例中，有人同時傳給我他的 Kagi 過濾器清單和他得到的搜尋結果，並沒有宣稱結果是好是壞，但一般人還是堅持結果很好，即使那些結果既沒有連到有用的內容，又充滿垃圾——除非使用者做了像是把 GitHub 釘選到結果最上方這類操作，這對那些目的是要下載託管在 GitHub 上的軟體的查詢確實有效，但對文章中其他查詢當然就完全沒用。

抽象來說，我能理解粉絲往往會對自己喜愛事物的缺點視而不見。舉例來說，我在看過Volvo 在樣本外撞擊測試中的表現後買了一輛 Volvo，有時會在 Volvo 車主論壇上搜尋問題的解答。十多年來，現有的可靠度數據（我認為這也得到修 Volvo 的技師們的經驗談所佐證）都顯示 Volvo 的可靠度是普通到差，但 Volvo 論壇上當然還是充滿堅持 Volvo 是最可靠的車種之一、數據全都錯了的人。

一個可能更切合主題的例子是 Blackboard（課程管理軟體）。在它還是大學課程最廣泛使用的軟體時，這套軟體同時被學生和教授廣泛討厭。我想可以公平地說，它是我社交圈中最被討厭的軟體（有更讓人討厭的軟體，像是 Visual SourceSafe，但那些更討厭的軟體普及度不夠高，不足以成為整體上最被討厭的）。維基百科頁面上寫道

Blackboard 已經成為「教育界最不受喜愛——甚至被憎恨——的公司之一。」

以及

2011 年 12 月，《Fast Company》報導指出，在 Amplicate 顧客意見調查中，有 93% 的受訪者「討厭」這家公司。

在我還年輕得多、也比較口無遮攔的時候，我遇到一位在 Blackboard 工作的人，想都沒想就笨拙地脫口說出類似「在做這麼多人討厭的軟體是什麼感覺？」的話。幸好對方完全沒有被冒犯，反而感到困惑，因為他以為那是廣受喜愛、使用者很喜歡的軟體。他不太相信我說的話是真的，我就隨口說了句大概是我搞錯了，然後話題就轉到別的方向。當時年輕又天真的我，真的很驚訝：在我的社交圈裡大概是最被討厭的軟體，在我遇到的那位員工（想必還有其他員工）眼中，居然是被大家非常喜愛的軟體。

我能理解 Volvo 論壇為什麼會變成那樣，因為現在的車整體來說已經夠可靠，一般人通常不會遇到拋錨，所以很容易會想「數據一定是錯的；畢竟我的車從來沒壞過」。讓我更費解的是，一個人怎麼會看著一整頁充滿垃圾內容的搜尋結果，然後還能迅速寫訊息解釋那些結果有多棒——就算他是某個搜尋引擎的粉絲——或是怎麼會有人認為使用者普遍喜愛一套以被討厭而聞名的軟體，討厭到我談過的每個人都跟我說它有多爛（而且常常是主動抱怨）、有新聞文章在討論大家多討厭這套軟體，甚至連維基百科頁面上都提到人們幾乎一面倒地討厭它。另一個類似 Blackboard 的例子是 Discourse（論壇軟體）的網頁效能，這篇文章的靈感之一就是來自這篇文章所提及、與認為 Discourse 效能很好的 Discourse 員工的對話。我覺得這個例子很有趣，因為 Discourse 實際上在程式碼中加入了會拖慢真實頁面載入速度的邏輯，以便在 LCP 這類網頁效能指標上作弊。這已經遠遠超出單純為基準測試做優化，而是上升到真正作弊的程度，不僅對使用者毫無好處，反而傷害了使用者。在某種程度上，實作這種作弊手法、並指導使用者如何不要意外破壞作弊的程式設計師，一定知道自己 App 的真實效能很差，但人們很容易在這類事情上築起心理防衛。

到了現在，我不會說我感到驚訝，因為這種事我已經看得夠多，多到如果沒發生我反而會覺得驚訝，但我還是會好奇，當這種事發生時，那個人腦中究竟在想什麼。

舉一個非程式領域的例子，我們先前在這篇談論人們對「顯而易見」事實有不同觀點的文章中提到，有一位籃球員主觀上普遍被認為是他那個時代最髒的球員。NBA 並沒有追蹤球員髒度的客觀數據，但他在各種衡量上似乎都遙遙領先。舉例來說，雖然就像 1950 年以前的籃板一樣，攻擊對手下體並不是官方統計項目，但他肯定保持著本世紀以拳打、腳踢、膝撞或其他方式攻擊對手下體次數的紀錄（經時代調整後的紀錄應該也是他的，但由於 80、90 年代整體打法髒得多，他有可能沒有保持歷史總紀錄）。在討論中，他所屬球隊的大多數球迷似乎都沒注意到這點，而「自然的搶籃板動作」和「自然的投籃動作」這些說法，已經因為該隊球迷在為這名球員攻擊他人下體時的扭曲動作辯護時顯得如此無感，而成了反覆出現的笑哏。

平均來說，人類很擅長忽略自己喜愛事物中的缺點，包括（而且尤其是）自己的作品或自己公司做的東西。不管是好是壞，我似乎正好相反，腦中立刻想到的都是自己和自己作品的缺陷。好幾次，因為一篇部落格文章，有人傳訊給我說類似「如果有人批評你的作品你會怎麼想？」或「如果有人說你的作品不好你會怎麼想？」之類的話。對於前者，我的想法是，我會費盡心思去找能戳破我論點的人來給我批評，所以如果有人對我的作品提出稍微合理的批評，那其實很棒。對於後者，我本來就覺得自己的作品充滿重大缺陷，所以，呃，對，說它不好似乎挺合理的。我作品中確實有些面向我覺得有趣或不錯，但整體來說，我不確定我會把自己做過的任何東西評為「好」。我不是說我沒有盲點，但我覺得在這個特定的盲點上，我比大多數人稍微不那麼容易中招²。

習慣性的應對方式

如果回想我曾有過的類似盲點，有一個特別鮮明的例子是我小時候，有個朋友來用我的電腦。要讓這個故事說得通，你得知道那還是機械式滑鼠的年代。久而久之，碎屑會卡在滑鼠滾球上，除非你清掉，否則它就會追蹤飄忽不定。

當我朋友試著用我的電腦時，他發現滑鼠根本沒法用，因為游標的移動看起來幾乎是隨機的。當我再次坐下來用滑鼠時，我卻完全沒問題，但仔細看我為了讓游標平順地走直線而做的手部動作，我其實是把手劇烈地到處甩。我才意識到，我一定是在碎屑慢慢累積的過程中逐漸適應了，用某種反向的不規則移動去抵消滑鼠極度飄忽的追蹤³。我覺得很神奇的是，我居然完全沒察覺自己在這麼做，也因此我常常會想，現在的我是不是也在做類似的事。

我有時會想起自己為了繞過 bug 而發展出的一整套應對方法。舉例來說，開新 Google Docs 文件時，我以前會立刻把想要的標題打進去。大概十年前左右的某個時間點，Google Docs 加入了某種延遲，導致你在剛開啟文件後立刻在標題欄輸入的文字會被覆蓋掉，所以我現在養成一個習慣：開完 Google Docs 文件後先做點別的事，之後才去改標題。隨著 Google Docs 功能越來越多，我也發展出一系列習慣來避開各種坑（例如在「錯誤」的時機嘗試搜尋，結果叫出無用的瀏覽器原生搜尋，而不是 Google Docs 的搜尋）。

我的感覺是，所謂的電腦素養和軟體素養，很大一部分就是累積大量這類你在無意識層面執行的習慣。這些習慣往往非常針對特定情境，例如我在微軟工作時養成的一個習慣：在登入前先把筆電的 WiFi 硬體開關切到關閉（我也注意到其他人也在這麼做）。這是因為有個服務常常會讓你的登入失敗，並顯示「There are currently no logon servers available to service the logon request」。但如果那個服務根本完全連不上線，那個檢查就會被跳過，你反而就能直接登入。

品質盲點

光是這類例子就可以寫滿整篇文章，但回到本文的主題，一個常被建議用來克服品質盲點的方法是讓大家吃自己的狗糧——也就是自己用自己做的軟體。平均來說，這比完全不自己用要好得多，但只有在人們沒有發展出（然後忘掉）那些能繞過軟體問題的習慣時才有效。平均而言，程式設計師很擅長繞過軟體的各種怪癖（在 LLM 出現之前，你必須如此才能成為有效率的程式設計師），所以如果沒有特別留意，程式設計師很容易就會忽略這類問題。

反過來說，讓 App 變得好用的很大一部分，似乎就是讓這類奇怪的習慣變得沒有必要。雖然這聽起來應該很容易做到，但從我看過人們試圖針對這類問題給回饋的經驗來看，多數開發者的直覺反應似乎是「咦？要做 X 很簡單啊，只要做[一連串複雜步驟，除非有人特別解釋或看過別人做過，否則沒用過這個 App 很多次的正常人根本想不到]就好了」或是「咦？你沒看到說明書第 43 頁在執行第 261 頁附錄 B 的步驟後，就已經把這個操作的說明寫得很清楚了嗎？」。

話雖如此，我認為治好人們的品質盲點是做得到的，因為我已經成功過好幾次。我覺得這只有在對方願意接受時才真的有效，畢竟人們對於刻意視而不見的能力是無限的，但在對方願意接受的情況下，只要把他們沒注意到的問題指出來，似乎就有效。甚至多年或十年後，有時還會有人跟我說他們現在到處都看得到 bug。

我覺得這值得去做的原因是，我看過有高度品質盲點的人和團隊，推出因為產品品質問題而成功機率大幅降低、甚至毫無成功機會的東西⁴。為了速度而有意識、刻意地犧牲品質是一回事⁵，但在我看過的這些案例中，總是存在某種品質盲點，讓參與專案的每個人都以為自己正在推出非常高品質的東西，但實際上根本不是。

這件事從來都不是不重要的，但隨著 coding agent 的出現，它變得更加重要，因為雖然現在比以往任何時候都更容易大量產出低品質的軟體，但也比以往任何時候都更容易提升品質，無論是更好的效能、更少的 bug等等。

但要做到這點，你必須真的察覺到這是可能的，品質是可以被提升的。

感謝 Yossi Kreinin、Dennis Snell、Michael Malis、Emu Chu、Gary Bernhardt、Jon Surrell 和 Matt Mullenweg 提供的意見／更正／討論。

很自然地，Gary Bernhardt 在閱讀本文草稿時就遇到了 Google Docs 的 bug。

P.S. 就像我在前四篇文章中提到的，我一直在嘗試更快地寫文章，因為有了 LLM，看資料、釐清問題變得容易得多，但由於我不是用 LLM 來寫作，寫文章所需的時間並沒有本質上的改變，除非我想在品質與速度的取捨上移到不同的位置。先前的結果是，我會跑一些實驗、告訴幾個朋友，然後就再也不會寫出來，因為根據 Amdahl's law，把東西寫出來會實質上耗掉我所有能用來跑實驗的頻寬。事實上，儘管我嘗試這麼做（我的目標是每篇文章只花 30 分鐘撰寫），自從寫完上一篇後，我又有三個我認為完全可以寫成一篇不錯的部落格文章的結果還沒時間寫出來（還不包括為工作做的東西，那又會再多幾項）。在不讓 LLM 幫我寫的情況下，我看不到有什麼合理的方法能把每篇的時間大幅壓到 30 分鐘以下（而且我覺得我常常達不到目標，花超過 30 分鐘），所以不用 LLM 的選項就只剩下：一些比我平常的文章草率得多的文章（一種人類式粗製濫造），或是幾乎沒有文章。

總之，如果你對這些快速（而且肯定更常出錯）的寫作有什麼看法，歡迎告訴我你的想法（X Bsky Mastodon）！

附錄：廣告盲點

Michael Malis（Freshpaint 創辦人兼前執行長）提到（是在訊息中說的，因此呈現訊息般的格式）

舉一個類似但不同的數據點——我在廣告方面也看過類似的盲點。當我向人們解釋 Freshpaint 時，我會說我們幫助醫院做行銷

我常被問到的一個問題是，醫院為什麼要做行銷。奇怪的是，如果你仔細注意，醫院其實做了大量的行銷

在舊金山，到處都是 UCSF／Sutter Health／Stanford 以及各種療程的公車廣告和看板

這跟 Michael 的評論以及本文主題都是不同的題目，但我想說的是，我和不少完全不相信廣告有效的人聊過，不過我在曾任職的一家大公司裡，和一位我信任其資料方法與判斷力的人聊過廣告的 A/B 測試，也在另一家公司親自看過資料，我認為在那些案例中，廣告帶來真實提升（遠超過廣告成本）的因果證據是強而有力的。在我親自看過的那個案例中，他們做了地理區隔的 A/B 測試，在某些地區買廣告、某些地區則不買（這是在全球範圍做的，地區像是美國的州、加拿大的省等等）。會做這種地理區隔，是因為即使有跨裝置追蹤，也無法百分之百確定某人是否真的看過廣告（當然，即使是這種區隔也一樣，我會更偏好更貼近人口聚集區的區隔、不要切在人們相對容易例如通勤往返邊界兩側的地方，但這種污染通常會讓真實的提升高於估計的提升），所以人們有時會做這類地理區隔的 A/B 測試。

總之，在這些 A/B 測試中，光是直接的營收增長，廣告投資報酬率就相當不錯，而且使用者數量也有成長，這似乎很可能在未來帶來更多營收（後續的營收沒有被分析）。我不知道廣告整體上的效果如何，也不清楚你的特定廣告是否有效，但那種常見的說法認為廣告整體上沒用，在我看來是錯的。

回到 Michael 評論的主題，我認為程式設計師很容易沒注意到廣告。我認識的幾乎所有程式設計師都使用廣告阻擋器，而且在現實生活中，他們的眼睛似乎就是會掠過廣告而不會注意到。我能理解這怎麼會助長「廣告沒用」的想法。到底誰會去看這些東西？但根據我與「一般人」互動的經驗，以及我在 Google 任職期間熟悉的資料，許多、甚至大多數人根本沒意識到很多廣告就是廣告。當他們做 Google 搜尋並點選最上面的結果時，他們常常完全不知道自己看的不是 Google「認為」最好的連結，而是出價最高、買下那個廣告版位的人的連結。

附錄：其他人的留言

Em Chu，談一個習慣性的 bug 迴避方式：

我確定你可以在這個段落收集無限多個例子，但我就是想抱怨一下：當我喚醒並解鎖筆電（Mac）時，很容易讓它進入一種「醒著」卻無法使用的狀態（黑畫面加游標之類的），只能靠實際把上蓋闔上再打開來修復。為了繞過這個問題，我想我通常會在螢幕亮起後等一秒，摸一下觸控板，然後才解鎖，不過老實說這大多是下意識發生的，而且顯然我還需要多練習，因為我每個月還是會遇到這個 bug 好幾次。

讀到這段後，我檢視了自己打開筆電的方式，才意識到自己為了繞過其他筆電 bug 也養成一些好笑的習慣。這裡提到的特定 bug 在我的筆電上無法重現，看來我可以停止為某台舊筆電而設下的那個習慣性迴避動作了。

Gary Bernhardt，談他閱讀本文草稿的經驗

在閱讀它的過程中，Google Docs 的介面似乎壞掉了，導致無法向上捲動去看某些留言（見截圖[本文未顯示]）。

看了截圖後，我發現我也遇過完全一樣的 bug，而且我對它有一些應對方法（依情境不同而有所不同）。就軟體品質而言，我個人會把 Google Docs 評為遠高於平均：我覺得它比主要替代方案（Microsoft Word、OpenOffice、各種早已消失的舊編輯器如 StarOffice、Lotus 等）要少 bug、少卡頓得多。即便如此，我還是可以輕易坐下來寫一篇一萬字的文章，專門講 Google Docs 的 bug 和我對它們的各種 workaround。

有時我曾試著看看能不能找到一份整天只修品質問題的工作。這從來沒有成功過，原因是一方面這不是什麼高度優先的事，另一方面公司通常也沒有這種常規職位。我有時會幻想以實習生的身分加入公司，花幾個月只修品質問題然後就離開。實際上，我想如果我真的得到這樣的工作，很多修正都會被擋下來，而且以實習生的身分要在三個月內真正推動改變會非常困難，所以那得是個幾乎被棄置、沒人在乎我在做什麼的專案（而且公司的優先事項不會那麼專注於推出新功能，以至於修好的東西馬上又被改壞）。

@IncidentNoodle

有點歪打正著地切題：<abbr> 標籤在行動裝置上大約上週還能用，但現在在所有 iOS 瀏覽器（Safari／Chrome／Firefox）上都失效了，而且我在 macOS 瀏覽器（三種都是）上很難發現要靠 hover 才會顯示，因為延遲很長

@[email protected]：

德語有個詞專門形容這個——Betriebsblindheit

@oulipien.bsky.social：

這裡有個來自 @danluu.com 的瘋狂軼事，我真希望他當時能更直接一點，問那個人到底是從哪裡得出 Blackboard 被任何人喜歡這種信念的。使用者調查？委託人（指 principal，而非 agent）的調查？內心的確信？？？[Blackboard 軼事截圖]

[某種變體：人們被老闆逼著說他們沒看到 bug]

我不認為這跟文章中任何一個主要例子相符，更別說全部了。想想上面提到的 Blackboard 例子。我和其他跟這位 Blackboard 員工談過的人不太可能是去考核員工的「神秘客」，而且這位員工的反應對任何不是這種假設性（實際上也不存在）的神秘客來說，顯然是荒謬的，所以這樣反應只會讓他在遇到的大多數人眼中顯得有點傻，而且毫無好處（例如，見上一則引言，那似乎是典型的內部反應）。也許少數非常多疑的員工會為了以防萬一遇到老闆認識、知道他們在這家公司工作的朋友或親戚、並會把故事轉述回去、而老闆又會在乎這種事的極小機率，而維持這種表面說法，但要說（例如）每一位來跟我解釋 Discourse 效能真的很好的 Discourse 員工都是這種情況，就實在不太可信。

如果看籃球的例子，這就更荒謬了。你或許可以編出某種理由，像是如果你不相信或假裝相信最荒謬的辯解，其他球迷就會排擠你，但以一個花了很多時間跟運動迷相處的人來說，我大致上沒發現有這種情況。而且，就算在某種程度上算是有一點，那也比較像是自我篩選的問題——熱衷於最極端辯解的球迷會花更多時間跟同樣熱衷於最極端辯解的球迷在一起，而比較不熱衷於這些極端辯解的球迷則傾向跟同樣不那麼熱衷的人相處。

另外，單就那些不接受這些說法並動手修正的人的職涯來看，察覺這些問題並加以修正，對他們來說發展得很好。假裝這些問題不存在（無論是有意識還是不自覺）似乎也發展得不錯，所以我不確定修正這些問題是否真的是更好的職涯路徑，但它肯定也沒糟到整體上會讓人有實質的職涯壓力去假裝這些東西不存在，即使在某些個別職位上確實存在要假裝這些問題不是真的的直接壓力。

Daniel Gibson：

還有誰會用 Shift 鍵來結束螢幕保護程式，因為萬一這個按鍵事件真的傳到某個程式，它最不可能造成非預期的影響？

這讓我想起，當我想立刻把一則排隊中的訊息傳給 codex 並中斷目前的工具呼叫時，我會把手指放在按鍵上並盡可能快速地按下，以縮短工具呼叫剛好結束、而按 Escape 鍵會變成完全停止 codex 而不是讓訊息送出的時間窗口。我大概應該直接跑一個已針對這個問題以及我遇過的其他幾個問題修補過的 codex 版本，但我已經在做像是試用某個針對特定工作負載優化的奇怪 ripgrep 版本這類事，那個版本還額外加入了一個原生碼編譯器，會在搜尋開始的同時於另一個執行緒中編譯匹配表達式，並在編譯完成後切換過去，所以我並不是反對為了改善工作流程而製作奇怪的 patch，比較像是整體頻寬的問題（毫無疑問，寫下這段後，一定會有人告訴我其實只要按另一個鍵就好，而且我花寫這段評論的時間去問 codex 就能知道了）。就像 Google Docs 一樣，我認為以這個領域來說，codex 的軟體品質算是高於平均，但即使我使用它還不到一年，我也可以輕易寫出一篇一萬字的文章，講我已經實作的各種 workaround（有些是靠習慣，有些則是真的寫了會監控異常行為並自動修正的腳本）。

John Regehr：

直到我寫完並發表這篇文章後，有人貼出 John 的文章，我才想起來，原來 John Regehr 在我開始寫部落格之前就寫過「Operant Conditioning by Software Bugs」！也許我應該用 LLM 來搜尋前人的作品，但如果我那樣做，我大概永遠都不會寫任何東西，因為真正全新的想法其實沒那麼多，幾乎所有東西都會跟別人說過的類似。不管是好是壞，我比 John 囉唆得多，所以這篇文章用了多得多的字數，還塞了更多隨機的故事。如果你覺得我的部落格文章太長，卻還是莫名其妙一路看到文章底部，那你可能會比喜歡我的文章更喜歡 John 的文章 :-)。