前言：「這個功能該不該做」比「怎麼做」更難

「開發一個新功能，不就是把需求丟給 AI，讓它把程式碼生出來嗎？」

如果需求本身已經定義得清清楚楚，這句話沒錯。但維護一個真實的開源專案時，功能需求很少一開始就清楚——尤其是像測試框架整合這種，上游（這裡是 Pest 測試框架）本身還在持續推出新語法、新特性，維護者要做的第一件事往往不是「怎麼實作」，而是「先搞清楚我們到底漏接了什麼、其中哪些真的值得做」。

這正是今天要講的重點：AI 能加速的是「把已經定義清楚的需求變成程式碼」這一段，但「定義需求範圍」——尤其是「決定哪些事情刻意不做」——這件事，還是要靠維護者的技術判斷。

今日目標

• 看一個真實案例，理解「功能開發」在一個活躍維護的開源專案裡實際長什麼樣
• 認識「系統性盤點缺口」這件事，怎麼幫後續的實作範圍定調
• 理解「刻意不做」跟「還沒做」的差異，以及為什麼前者需要明確記錄下來
• 建立「AI 適合做什麼、維護者該把關什麼」的具體分工方式

案例的起點：一份系統性的功能落差盤點

PHPUnit & Pest Test Explorer 這個專案支援 Pest 測試框架的語法解析。Pest 本身會持續推出新版本（3.0、4.0），每次推出新語法特性，這個擴充套件的解析邏輯就可能出現落差——沒被辨識的語法、被誤判的呼叫鏈、顯示不出來的狀態圖示。

真實的 issue #427「Pest 3/4 feature coverage audit: gaps in Test Explorer support」，就是一份針對這整批潛在落差的系統性盤點——把 Pest 3.0/4.0 的官方發布說明、文件，逐條對照這個擴充套件目前的解析邏輯，列成一張清單，依優先序排列。

這份盤點裡每一條都不是「猜測應該有問題」，而是實際查證後的具體結論。例如針對 Browser Testing 的 visit() 呼叫，盤點裡寫的是：已經用兩套不同的語法分析器（tree-sitter 跟 php-parser）實際驗證過，visit() 是呼叫鏈內部的一個陳述式而不是鏈本身的一部分，所以不會被誤判成測試項目，「沒有解析錯誤、沒有被靜默丟棄」。針對 Mutation Testing 的 --mutate 旗標，結論是「這只是一個純粹的命令列參數，處理指令組裝的模組不會解析它，直接透傳，沒有風險」。

這份盤點的價值，不在於它列出了多少個項目，而在於每一條「沒問題」的結論背後都有實際驗證過的依據，而不是憑印象判斷。

「刻意不做」跟「還沒做」是兩件不同的事

盤點裡最值得注意的一節，是明確列出幾項「調查過後，決定不實作」的項目——例如 Browser Testing 的視覺化狀態圖示，盤點裡寫的理由是：要偵測 visit() 這種藏在測試主體內部（不是呼叫鏈頂層）的呼叫，需要一整套新的「主體遍歷」基礎設施（處理賦值、巢狀呼叫、再把範圍對應回所屬的測試項目），而這只是一個裝飾性的視覺提示，沒有功能性缺口——「投入跟產出不成比例」，所以決定不做。

這跟「還沒排進時程」是完全不同的兩件事。如果只是含糊地說「這個之後再看」，下一次有人（不管是 AI 還是新加入的貢獻者）重新評估這個功能時，得從頭再查一次同樣的問題；但如果明確記錄「調查過，決定不做，理由是 X」，這個判斷就被保存下來，不需要重複評估。

從盤點到實作：一份收斂過的 PR

盤點完成之後，真正動手實作的是 PR #428「feat: Pest todo() assignee/issue and skipOnCi()/skipLocally() detection」——只挑了盤點裡「跟已經上線的 skip/todo/only/group 功能同一個複雜度量級」的兩個項目：todo(assignee:, issue:) 具名參數的顯示、skipOnCi()/skipLocally() 的靜態標注。

這份 PR 的描述裡，開頭就先明講一句話：這是 #427 盤點裡「同一分量級」的後續項目，其餘 5 項各自需要「一種全新的、非 teamcity 的結果格式，或者全新的指令/報表介面」，投入量級完全不同，另外追蹤。換句話說，這份 PR 的範圍不是憑感覺決定的，是直接對照盤點裡的分類結果收斂出來的。

用一組對照來看這個過程：

❌ 沒有先盤點就直接開發：
「Pest 又出新版本了，我們來加幾個功能支援它。」
→ 憑印象挑幾個看起來重要的項目動手，
  沒有系統性確認哪些真的有缺口、哪些其實已經支援、
  哪些調查後會發現投入產出比太差不值得做

✅ 先系統盤點，再收斂範圍動手：
「先把新版本的完整特性列表對照現有解析邏輯逐條驗證，
 標記出真正的缺口跟優先序，把『投入量級不成比例』的
 項目明確記錄成『調查過，決定不做，理由是 X』，
 再從缺口清單裡挑同一個量級的項目收斂成一次 PR。」
→ 每個功能決定背後都有實際查證的依據，
  「做」跟「不做」的理由都留下記錄，可以被下次重新檢視

AI 適合做什麼，維護者該把關什麼

這份盤點跟實作過程裡，AI 能有效加速的部分很具體：逐條核對語法特性跟程式碼的比對工作（例如反覆用不同語法分析器驗證同一個假設）、寫測試案例、實作已經定義清楚的解析邏輯。這些都是「規則已經定義好，照著做」的機械性工作。

但「這個落差重不重要、值不值得投入、要不要現在做」——這個排序判斷本身，需要對這個專案的使用者群體、對上游框架的發展方向有整體理解，這不是讀程式碼能推導出來的，是維護者的技術方向判斷。這正是這個系列的主題句在功能開發場景下的具體樣貌：AI 能加速盤點跟實作這些機械性、可規則化的工作，但『這個功能該不該做、做到什麼程度』這個技術方向的判斷，終究要人來扛。

第二部回顧

到這裡，第二部（Day 8-16）用真實的 CI 重構、bug 定位、依賴升級、功能開發這幾類具體工作，把「AI 處理 issue/PR 的具體工作流」走了一遍。共通的模式是：AI 擅長機械性、規則明確的執行工作，但「範圍該多大、優先序怎麼排、什麼時候該停手」這些判斷，都需要維護者對專案整體方向的理解，不是單看眼前這一個任務就能決定的。

今日思考題

回想你自己維護（或參與）的專案：上一次新增一個功能之前，有沒有先系統性盤點過「還有哪些相關的缺口」？還是想到什麼就做什麼，事後才發現漏了什麼、或者做了一個其實不值得投入的功能？

今日重點回顧

• 系統性盤點（issue #427）讓後續實作範圍不是憑印象決定，每一條結論都有實際驗證依據
• 「刻意不做」要明確記錄理由，跟「還沒排進時程」是不同的兩件事，前者能避免重複評估
• 實作（PR #428）的範圍直接對照盤點的分類結果收斂出來，不是重新用感覺判斷
• AI 適合做機械性的核對、實作、測試工作；技術方向的判斷（該不該做、做到什麼程度）要靠維護者

明日預告

明天用今天這個真實案例（issue #427 到 PR #428）再往下挖一層：一個功能開發從討論到合併的完整歷程裡，還有哪些細節值得拆解。