「當一個指標變成目標，它就不再是好指標。」
這句話通常被稱為 Goodhart's law，但它其實不是 Goodhart 說的。英國經濟學家 Charles Goodhart 在 1975 年一篇談英國貨幣政策的論文裡，寫的是一句拗口得多的話：任何觀察到的統計規律，一旦被拿來當成控制的手段施壓，就會開始崩解。他當時是英格蘭銀行的顧問，談的是央行盯著貨幣供給量做決策時，這個數字就不再像以前那樣可靠。
大家熟悉的那個簡潔版本，是透過人類學家 Marilyn Strathern 流傳開來的。她在 1997 年一篇討論英國大學評鑑制度的文章裡用了這句話，而她自己還把這個說法歸功給另一位學者。一句被掛在嘴邊的名言，跟原文已經隔了兩手，這件事本身就很適合當這篇的開場。
指標是代理。真正想知道的東西通常很難直接量，例如教學好壞、工程團隊的產出，所以挑一個看得到的數字代替它。平常這個數字跟真正的目標走在一起，數字好，事情通常也好。
一旦數字變成被獎勵或被懲罰的對象，大家就會開始優化數字本身，因為讓數字好看，往往比把事情做好省力得多。一間醫院如果只被考核平均住院天數，就有理由讓病人早一點出院；考核達標了，原本想改善的照護品質卻不一定更好。
導入 AI coding 工具之後，管理者很自然會想知道這筆投資值不值得。最容易拿到的，是一組跟使用和貢獻有關的數字。
Claude Code 給團隊和企業方案的後台，分成兩部分。使用指標包括每天有多少人在用、Claude Code 寫的程式碼被接受了多少行，以及程式碼修改建議的接受率。貢獻指標則要由 GitHub 管理員安裝 Claude 的 GitHub app、再由組織的擁有者開啟，開了零資料保留的組織則用不了，目前還在公開測試階段：它會統計合併的 PR 裡，有多少比例含有 Claude Code 參與寫的程式碼，並依 PR 數或程式碼行數，列出貢獻最多的前十名。
這些數字怎麼算，官方文件寫得很仔細。一個合併的 PR，只要有至少一行能比對到 Claude Code 在那段時間的輸出，就算是有 Claude Code 參與；被人改寫超過兩成的行，則不算在 Claude Code 頭上。官方也說明，這些數字是刻意保守的低估。
這些數字很有用。看得出工具有沒有被用起來、哪些人用得多可以請他分享做法、哪一段時間使用量突然掉下來，也許是遇到了什麼問題。官方文件也建議，要搭配 DORA 這類工程指標一起看。麻煩出在它們被拿來當成目標的那一刻。
程式碼行數是最明顯的例子。Day 15 談過，程式碼是負債，寫得越多不代表越好。把「AI 產出的行數」當成績效，等於獎勵多寫程式。官方文件也寫明，「接受的行數」這項並不追蹤之後被刪掉的部分，今天接受了一大段、明天整段刪掉，照樣算在上面。
接受率也一樣。它高，可能代表建議的品質好，也可能只代表大家越來越懶得細看就按下接受。
排行榜的本意，是找出用得好、能幫助別人上手的人。一旦它跟考核掛鉤，把一個 PR 拆成好幾個，就能讓自己的名次往前移。含 AI 程式碼的 PR 比例被訂成目標時，也會出現類似的事：自己寫比較快的地方，也要繞一圈讓 AI 寫。
沒有人盯著的時候，這些數字大致能反映工具被用得怎麼樣；一旦拿來排名、考核，它們反映的就只剩大家多會配合了。
比較穩當的做法，是把注意力從產量移到結果。DORA 是 Google Cloud 長年進行的軟體交付研究計畫，每年調查大量的工程團隊，整理出五個衡量指標，分成兩類。一類看速度：改動從 commit 到上線要多久、多久部署一次、部署出問題之後多久能恢復；另一類看穩定：部署後需要立刻處理問題的比例，以及因為線上事故而臨時多做的部署，占全部部署的比例。DORA 的研究發現，表現好的團隊兩類指標都好，速度和穩定並不是非得取捨；但只盯著其中一類，就很容易為了那一類而犧牲另一類。
指標也要成對地看。PR 數量上升的時候，review 的負擔有沒有變重、上線後的問題有沒有變多；AI 寫的程式碼比例上升的時候，Day 18 談的「有人真的看懂」還做不做得到。兩個互相牽制的指標，比較難被同時灌水。
落到具體的做法，最簡單的一條是：排行榜和接受率不要放進績效考核。它們拿來了解團隊怎麼用工具、誰可以幫忙帶別人、大家卡在哪裡，價值很高；一旦決定了誰表現好，很快就會被優化成好看的樣子。
Goodhart 在 1975 年談的是央行和貨幣供給量，Strathern 在 1997 年看到的是大學和評鑑分數。
AI coding 的導入報告，是這個現象最新的場景。被盯著的換成了 AI 產出的行數、接受率和排行榜，失真的路徑卻跟五十年前一樣：數字一旦決定了獎懲，大家就會先照顧數字。
延伸閱讀
iThome鐵人賽
看影片追技術