最近有人這樣說
Matt Pocock（TypeScript 圈很有名的教學者）在 2026 年 11 月 4 日發了一則推文，二十萬人看過。講的是：AI 時代，程式碼好不好讀已經不重要了。
理由是這樣的。以前程式是人在讀，人讀東西很慢，所以程式碼要寫得清楚，別人才看得懂。現在程式是 AI agent 在讀。AI 不是用「看」的，它是直接跑看看、跑測試、改一行再跑一次，用做實驗的方式搞懂程式。
所以作者說：對 AI 來說，「好讀」沒意義，「好驗證」才有意義。只要測試齊全，程式再亂、再難懂，AI 都不怕。
他還舉了個例子：有一個很大、很複雜、塞滿效能技巧的模組，但測試覆蓋率 100%。老手工程師要花一兩個小時才敢動它；AI 不用，跑一下測試，立刻就能改。
結論是：以後別管程式好不好讀，只管好不好測。函式太長、邏輯太複雜？沒關係，AI 不在乎。
這段話很吸引人，因為它講到一件真的在發生的事：程式碼的第一個讀者，正在從人變成 AI。 但它的結論跳太快了。這篇文章想做三件事：把它說對的留下來，把說錯的指出來，最後給一個比較站得住的版本。
它說對的兩件事
第一，「好不好測」比「好不好讀」更該被重視，這方向是對的。
這其實是老話：程式要容易測，是設計的第一優先。只是這次是從 AI 的工作方式反推回來的。AI 真的比人更依賴「跑跑看」：跑測試、加 log、改一點再跑。如果一個模組可以單獨拿出來測，代表每次改動都能很快知道對不對、影響範圍有多大。這對人、對 AI 都好，只是 AI 時代把這件事的價值放大了。
第二，「程式碼要用跟需求一樣的詞」這點，比作者自己想的還重要。
作者說可讀性還剩一個用處：程式裡用的詞，要跟人描述需求時用的詞一樣。這就是我們常講的「用同一種語言說話」，也是 Specification by Example 的核心。
在 AI 時代這點反而更關鍵。你跟 AI 說「訂單逾期要通知業務」，它會去程式裡找「訂單」、「逾期」、「通知」、「業務」這些字。如果程式裡叫 rec、flag3、proc()，AI 就對不上。不是它看不懂，是它找不到。命名跟需求脫節，等於把 AI 的索引拿掉了。
這兩點都對。問題出在作者從這兩點推出來的結論。
但它有六個地方講錯了
1. 「測試覆蓋率 100%」不等於「驗證得了」
覆蓋率只告訴你哪些程式碼被跑過，不告訴你測試有沒有真的檢查到重要的行為。一個「塞滿效能技巧」的模組，最難驗證的就是效能本身跟各種邊界情況，而這些通常不在單元測試裡。作者拿一個理想中的 100% 覆蓋率，把驗證的難度整個抹掉了。現實裡常見的是：覆蓋率 100%，但一半的測試只是「跑過去沒當掉」而已。
2. AI 讀程式碼也是要花成本的
AI 讀程式碼還是一個字一個字讀進去，而且它一次能裝進腦袋的量是有上限的。一個又大、分支又多、到處共用變數的模組，對 AI 來說就是：要塞更多東西進去、要想更多種可能、要寫更多測試才蓋得住。
所以「邏輯複雜度對 AI 不重要」這句話很可能是反的。複雜度就是「有幾條路要走」，路越多，驗證成本越高。作者把「AI 不會抱怨程式難讀」誤當成「AI 不會因為程式難讀而出錯」。
3. 他留下來的那一點，本身就是可讀性
「程式碼用跟需求一樣的詞」，這就是可讀性最核心的那一層。把它留下來，然後說「可讀性不重要了」，是自相矛盾。比較誠實的講法是：表面的可讀性（排版、函式長短）變得沒那麼重要；意思上的可讀性（命名、跟需求對得上）變得更重要。 這跟「可讀性不重要」是兩回事。
4. 自己寫程式、自己寫測試、自己說過關
如果程式跟測試都是 AI 寫的，人又看不懂那個模組，那「有測試所以沒問題」就是 AI 自己幫自己打分數。這時候人唯一能插手的地方只剩測試。所以測試（或規格）本身好不好讀，反而變成必要，不是可有可無。作者完全沒提這一點，但這可能是整件事最關鍵的轉折。
5. 「為了效能犧牲可讀性」是舊建議換個包裝
這條跟 AI 一點關係都沒有，只是把「過早最佳化」重新合理化一次。真正該說的是：你要犧牲可讀性可以，但你得先用測試把「這段程式應該做什麼」鎖住。不然下一個來改的人（或 AI）不知道哪些行為是故意的、哪些只是副作用。
6. 出事的時候，還是人要進場
作者自己也承認「人必要時要能跳進去看」，但沒說什麼時候算「必要」。通常是凌晨三點線上出問題、AI 卡住、退版也不對勁的時候。那正是可讀性最有價值、也最等不了的時候。可讀性不是可有可無，它是保險：平常用不到，出事時沒有會很慘。
比較站得住的講法
把那段話修正一下，我會這樣說：
| 原本的說法 | 修正後 |
|---|---|
| 好不好讀不重要，好不好測才重要 | 好不好測是底線，好不好讀是保險；兩個都要，不是二選一 |
| 可讀性只剩「人看得懂」跟「用需求的詞」 | 可讀性的重點從「人讀得順」變成「跟需求的詞對得上」，因為這是 AI 做對事的前提 |
| 有測試就能驗證 | 測試跟規格好不好讀，變得比程式碼本身更重要，因為那是人跟 AI 唯一都看得懂的東西 |
| 邏輯複雜度對 AI 不重要 | 複雜度還是重要，只是衡量方式從「人要讀多久」變成「要跑幾條路才測得完」 |
| 可以為效能犧牲可讀性 | 可以，但要先用測試把「這段該做什麼」鎖住 |
一句話總結：AI 時代沒有讓可讀性消失，它讓可讀性搬家了——從程式碼本身，搬到了規格、測試、命名。
程式不給人讀了，人跟 AI 靠什麼溝通？
把這件事想到底，會得到一個有點意外的結論。
以前我們推 Specification by Example、推 BDD，常常被問：「寫那些 Given/When/Then 幹嘛？工程師直接看程式碼不就好了？」在人寫程式的年代，這個問題不太好回答，因為程式碼確實看得懂。
但現在程式越來越多是 AI 寫的，人也越來越不會一行一行看。這時候，規格跟測試就從「附加文件」變成「唯一的共同語言」：人用它說清楚要什麼，AI 用它確認做對了沒有。兩邊都看得懂的，只剩這一層。
所以那段流傳的話，真正的結論不該是「程式好不好讀不重要了」，而是：
程式碼的可讀性可以退場，但規格跟測試的可讀性一定要補上。 誰沒補，誰就是在讓 AI 自己幫自己打分數。
這也是為什麼我認為 AI 時代的測試，重點不是「多寫幾個自動化測試」，而是「測試有沒有變成人跟 AI 都看得懂、都信得過的規格」。這個話題，下一篇再談。
來源
- Matt Pocock，We need to reconsider our priors on code readability，X，2026-11-04
發佈留言