前言：AI 一眼就能看出這個人「程度好不好」，但這句話該不該說出口？

「這個 PR 一看就是新手寫的，AI 幫忙先篩一輪，程度太差的直接退回去，維護者只看篩過的就好吧？」

聽起來很有效率，卻是這個系列走到現在最容易踩到的一條線。外部貢獻者投 PR 給一個開源專案，背景差異可能很大——有人是第一次投 PR 的初學者，有人是資深工程師但第一次接觸這個專案的慣例，有人英文不是母語、留言寫得生硬。AI 確實看得出程式碼風格跟這個專案的慣例有落差，但「落差」不等於「能力差」，把兩者混在一起講出來，很容易變成對一個善意貢獻者的公開評判。

今日目標

• 分清楚「補足資訊落差」跟「評判貢獻者能力」是兩件性質不同的事
• 看懂為什麼把「程度判斷」講出來，風險比它省下的時間更高
• 建立一套具體做法：AI 該怎麼描述問題，才不會變成在評價人
• 這篇是第三部（Day 17-23）收尾，順便回顧這幾天講過的授權邊界主題

補足資訊落差：AI 真正該做的事

外部貢獻者跟這個專案維護者之間，最大的落差通常不是技術能力，而是資訊——貢獻者不知道這個專案的 commit 訊息慣例、不知道測試要涵蓋哪些平台組合（Day 21 講過的 Docker/SSH/Sail 這類環境矩陣）、不知道某段看起來可以刪的程式碼其實是為了相容某個特定情境保留的（呼應 Day 12 講過的「沒被引用不等於死碼」）。

這些落差是 AI 可以、也應該幫忙補的：把專案慣例整理成一份 checklist，PR 送出時自動比對差異，用中性、描述性的語言指出「這裡沒有遵循 XX 慣例」，而不是「這裡寫得不好」。

評判能力：AI 不該做、也做不準的事

問題出在另一種說法——「這個人技術背景看起來不夠扎實」「這個貢獻者的程式碼品質普遍偏低，之後的 PR 可以優先度降低」。這句話乍看是在陳述事實，其實藏著兩個問題：第一，AI 判斷的樣本通常只有這一兩個 PR，樣本量小到不足以下這種結論；第二，就算判斷是對的，把它講出來也沒有任何建設性——貢獻者需要的是「這裡該怎麼改」，不是被貼上一個能力標籤。

更現實的風險是：這種評語一旦被記錄下來（例如寫進 PR review 留言、或存進某個內部筆記），會變成一個持續影響這個人後續互動的標籤，而這個標籤的判斷依據可能只是一次沒睡飽寫出來的 PR。

用一組對照來看這個差異：

❌ AI 評判能力：
「這位貢獻者的程式碼風格跟專案慣例落差很大，
 看起來對測試框架不熟，這類 PR 建議降低優先度處理。」
→ 用單一樣本下能力結論，把技術落差講成人的問題，
  對貢獻者沒有建設性，還可能造成不必要的冒犯

✅ AI 描述具體落差：
「這個 PR 的 commit 訊息格式跟專案慣例（Conventional Commits）
 不一致；測試只涵蓋了本機環境，沒有涵蓋 Docker 環境下的行為——
 這兩點需要調整，調整後可以直接合併。」
→ 具體指出哪裡需要改、為什麼，
  留給貢獻者跟維護者足夠的資訊，判斷交給人

AI 的角色是把「這個 PR 跟專案期待之間的落差」講清楚，不是把「這個人的能力值多少」講出來——前者是可以被驗證的事實，後者是一個 AI 沒有資格、也沒有足夠證據下的判斷。

第三部回顧：社群協作與維護者角色的邊界

第三部（Day 17-23）一路講下來，其實是同一個主題句在不同情境下的具體樣貌：Day 17 講 AI 不該代替維護者表達立場，Day 18 講授權/版權判斷不能讓 AI 自己拍板，Day 19、20 講 release 決定要人核准，Day 21、22 講多平台測試矩陣的盲點，今天這篇講的是「評判人」這件事本身就不該是 AI 的角色。這些情境表面上各不相同,但骨子裡都是同一句話：機械性、可驗證的工作可以交給 AI 加速,涉及對人的判斷、專案方向的取捨,終究要人來扛。

今日思考題

回想你上一次收到一份 code review 意見：那份意見是在描述「這段程式碼哪裡需要改」，還是隱約在評價「寫這段程式碼的人程度如何」？如果是後者，那份意見對你實際改進 PR 有幫助嗎，還是只讓你不想再投下一個 PR？

今日重點回顧

• 補足資訊落差（專案慣例、測試矩陣、隱性設計理由）是 AI 該做的事，有具體建設性
• 用單一樣本評判貢獻者的技術能力，不是 AI 該做的事，樣本量不足、也沒有建設性
• 好的做法是把落差講成「這裡跟期待不一致」的具體事實，不是「這個人程度如何」的人身判斷
• 第三部（Day 17-23）反覆講的是同一件事：機械性工作交給 AI，涉及對人的判斷留給人

明日預告

第三部到這裡告一段落，明天進入第四部「實戰案例與總結」：用一個真實 issue，完整追蹤從回報到修復的整個過程，把前面 23 天講過的原則放回真實情境裡檢驗。