一項功能通常分散在多個位置

命令列只是增加一個標籤統計的參數，程式內卻會經過參數解析、檔案讀取、JSON 轉換、議題排名、標籤計數與輸出格式化。相關測試也可能分散在函式測試、命令列整合測試與範例資料中。

此時只搜尋 label 關鍵字，搜尋結果很可能同時包含實作、測試、README 與套件程式碼，很難直接判斷應該從哪裡開始閱讀。

因此在探索大型程式碼庫時，我們可以先選定一項外部可觀察的功能，再請 Codex 從程式入口一路追到核心邏輯與相關測試。

今天會使用 codex-hands-on 的「四種標籤統計」作為固定目標，找出命令列如何接收輸入、議題資料在哪裡解析、標籤數量在哪裡計算、結果如何輸出，以及哪些測試保護這條功能路徑。

這次操作只讀取檔案，以及執行不會改變專案內容的查詢命令。Codex 不修改程式、不安裝套件，也不建立提交，最後整理出一份「功能脈絡地圖」。地圖中的每項結論都要附上檔案路徑與程式符號，無法從現有內容確認的資訊則標示為「待確認」。

理解程式庫時，可以要求 Codex 說明功能經過的主要流程，並整理相關模組、資料驗證方式與檔案位置。開發者便能沿著這些線索回到原始程式抽查，確認 Codex 對程式結構與功能路徑的理解是否有足夠依據。

從可觀察行為界定探索範圍

開始探索前，應先標示出這項功能的輸入與輸出。codex-hands-on 的輸入是一份議題 JSON 檔案，每筆資料包含標籤。輸出則是在命令列顯示 bug、feature、documentation 與 security 的數量。

標籤統計會和既有議題排名一起輸出，因此探索範圍也要包含兩者如何組合，才能確認統計功能使用哪些資料與處理結果。

我要理解 codex-hands-on 的四種標籤統計功能，這一輪只做唯讀探索。

請先確認下列外部行為在專案中的對應位置：
輸入：命令列接收一份含有 issues 與 labels 的 JSON 檔案。
輸出：命令列顯示 bug、feature、documentation、security 的數量，並保留既有議題排名。

請先說明你準備從哪些入口開始查找，不要修改檔案、安裝套件或建立提交。

這段提問沒有預先指定檔名，因為實際位置仍需由專案內容確認。

它先固定功能邊界，讓 Codex 從命令列入口、輸入格式與輸出文字開始搜尋。若專案中的資料結構與描述不同，Codex 應指出實際欄位與範例來源，避免它自行補出符合提問的結構。

大型專案可能同時存在多個名稱相近的功能。提問中加入四個輸出標籤、JSON 輸入與排名結果，可以縮小搜尋範圍，避免 Codex 追到其他無關的統計模組。

收到第一輪回覆後，要確認它找到的是實際可執行的入口，還是只出現在 README、測試資料或文件中的文字。後續探索才能沿著可執行入口繼續追蹤資料解析、排名、標籤計數與輸出流程。

先找到對外入口與第一個呼叫點

入口是使用者或其他模組開始使用功能的位置。node.js 的命令列專案可以先查看 package.json 的 scripts、bin 設定與實際啟動檔，確認命令如何進入程式。網頁服務則可以從路由、控制器或請求處理函式開始追蹤。

除了執行入口，也要確認專案是否提供程式設計介面（Application Programming Interface, API）。若某個匯出函式可以由其他模組直接呼叫，它也是屬於需要記錄的對外介面。

請找出標籤統計功能的對外入口與第一個呼叫點。

說明 package.json 中哪個 script 或 bin 設定會啟動命令列工具，
啟動後進入哪個檔案與函式，使用者提供的檔案路徑在哪裡被接收。
再確認專案是否匯出可供其他模組使用的函式；若沒有 HTTP API，請直接標示沒有。

每項結論都附上檔案路徑、設定鍵或函式名稱，並區分定義位置與呼叫位置。
保持唯讀，不要修改檔案。

回覆中應該能看到一條從啟動設定連到程式符號的呼叫路徑。例如 package.json 中的某個 script 啟動命令列檔案，再由該檔案呼叫處理輸入的函式。實際檔名與函式名稱仍要以 Codex 找到的專案內容為準。

只列出相關檔案還不足以說明入口。開發者還需要知道哪個設定啟動哪個檔案、哪個函式接收輸入，以及下一個呼叫點在哪裡，才能沿著執行路徑繼續追蹤。

沿著呼叫路徑追蹤資料變化

找到入口後，下一輪要沿著呼叫路徑追蹤資料流。每個節點都應記錄呼叫端、被呼叫函式、傳入資料與回傳結果。從使用者提供的檔案路徑開始，依序確認檔案內容如何轉成議題陣列、議題如何進入排名與標籤統計，以及兩種結果在哪裡組成命令列輸出。

請從剛才確認的命令列入口開始，追蹤四種標籤統計的完整呼叫路徑。

每一步請寫出：呼叫端的檔案與函式、被呼叫的函式、傳入資料、回傳資料，以及這一步對標籤統計的責任。

資料流至少要涵蓋輸入路徑、檔案內容、JSON 解析後的 issues、排名結果、四種標籤計數，以及最後的命令列文字。
請標出 rankIssues、priorityScore 與標籤統計之間的實際關係。

只引用程式中能確認的關係。找不到的節點標示待確認，不要修改檔案。

這一輪也要記錄資料形狀的變化。檔案內容在哪裡從字串轉成物件、issues 在哪裡被取出、標籤名稱是否經過正規化、計數結果使用什麼資料結構保存，以及格式化階段讀取哪些欄位，都會影響後續修改位置。若只記錄「讀取資料後進行統計」，會漏掉中間影響行為的處理步驟。

呼叫路徑也能看出各段程式負責的工作。若排名與標籤統計由不同函式處理，再由命令列層組合結果，調整標籤計數規則時，就可以先把修改範圍集中在統計相關程式。若計數邏輯直接寫在輸出流程中，相關測試位置與修改範圍也會不同。

功能脈絡地圖應記錄目前程式實際存在的結構。Codex 需要沿著呼叫與資料流整理證據，再由開發者依這些資訊判斷後續修改位置。

把測試連回它保護的程式

測試位置不能只整理成一個目錄名稱。開發者還需要知道每個測試檔案呼叫哪個入口、使用哪些資料，以及驗證哪一段行為。

這樣才能分辨直接驗證標籤統計函式的單元測試，以及從命令列入口執行完整流程的整合測試。

請找出保護四種標籤統計流程的測試。

對每個相關測試檔案，說明測試名稱、呼叫的函式或命令列入口、使用的 fixture 或內嵌資料、驗證的輸出，以及它對應呼叫路徑中的哪個節點。

請確認目前是否涵蓋四種標籤、缺少標籤時顯示 0、單一 issue 有多個標籤、重複標籤與大小寫差異。沒有覆蓋的情境標示為測試缺口。

列出 package.json 中可執行這些測試的實際命令。不要執行安裝或修改檔案。

測試缺口只描述目前專案的覆蓋情況，這一輪先記錄，不進行補測試。

Codex 應指出哪些案例已有測試、哪些案例找不到，以及判斷依據。若回覆只根據檔名或測試描述推測內容，還要補查測試名稱、呼叫位置與斷言，確認該測試是否真的經過標籤統計流程。

測試也要對應回前一輪整理出的呼叫路徑。直接呼叫標籤統計函式的測試，可以保護計數規則。從命令列入口執行的測試，則能涵蓋輸入解析、排名、標籤統計與輸出格式。這些資訊能協助開發者判斷後續修改會影響哪些測試。

測試命令應從 package.json 或專案文件取得。完整測試、指定測試檔案與單一測試案例可能使用不同執行方式，功能脈絡地圖只記錄專案中能確認的命令。無法確認的參數或選項則標示為「待確認」，確保 Codex 並無自行產生專案中沒有出現過的指令。

補上設定、資料與錯誤邊界

主要呼叫路徑完成後，還要補查周圍的設定、資料形狀與錯誤處理。

四種標籤是直接寫在函式裡、由常數匯入，或從設定讀取，會影響後續修改需要觸及的範圍。議題缺少 labels、標籤不是字串，或 JSON 無法解析時，程式目前採取的處理方式也要記錄。

請補查標籤統計周圍的設定、資料與錯誤邊界。

找出四種目標標籤的定義位置、issues 與 labels 的資料形狀、fixture 或範例資料來源，以及缺少 labels、非字串標籤、JSON 解析失敗時的處理方式。

說明 README 或其他文件如何描述這項功能，並確認文件範例是否與目前程式行為一致。

每項結論附上檔案路徑與程式符號。
專案中無法確認的規則標示為「待確認」。
不要執行安裝或修改檔案。

這一輪可以補出主要流程沒有顯示的限制。例如程式可能允許 labels 可以省略並產生空值，也可能直接假設標籤一定是字串。若輸入資料型別只透過 fixture 或範例表達，程式內沒有驗證邏輯，也要在地圖中記錄，因為這些條件會影響修改時需要保護的既有行為。

設定來源也需要追到實際定義位置。若四種標籤集中在常數中，後續調整可能只涉及該定義與相關測試。若名稱分散在計數與格式化程式中，修改範圍就會涵蓋多個節點。這一輪只記錄目前結構與依賴關係。

README 與其他文件可以提供使用方式、輸入範例與執行命令，程式和測試則能確認目前可執行的行為。三者出現差異時，功能脈絡地圖應分別記錄內容與來源，並把差異保留下來。

探索階段先建立可查證的現況，後續再依產品規則與歷史紀錄確認應採用哪一項定義。

要求證據並保留未知資訊

Codex 的說明讀起來完整，仍要確認每一段關係是否有程式證據。探索提問應要求提供檔案路徑、設定鍵、匯出名稱、函式名稱與測試名稱。這些定位資訊能讓開發者直接開啟原始檔案，確認函式確實存在、呼叫方向是否正確，也能檢查 Codex 是否省略條件分支或中間處理。

註解、README 與程式行為出現差異時，可以要求 Codex 分別標示「文件宣告」與「實作行為」。遇到名稱相同的函式，也要列出完整路徑與呼叫端。大型儲存庫可能同時保留舊版本、產生檔案、測試替身或名稱相近的模組，只靠名稱搜尋容易把不同用途的程式混在一起。

無法確認的資訊也應保留在功能脈絡地圖中。例如找不到輸入資料的正式結構、沒有針對非字串標籤的測試，或測試腳本依賴外部環境，都可以標示為「待確認」，並附上已查找的檔案與位置。這些項目可以直接整理成後續需要向團隊確認的清單，也能避免推測混入已證實的流程。

若 Codex 的結論缺少依據，可以改用聚焦的後續提問：

請證明命令列入口會呼叫這個統計函式，列出中間每個呼叫端、被呼叫函式與程式符號。

每次只補查一段呼叫鏈結，可以讓原本概略的說明逐步收斂成可追蹤、可抽查的程式路徑。

產出一份功能脈絡地圖

入口、呼叫路徑、資料流、測試與邊界都確認後，可以請 Codex 合併前面的探索結果。

這份地圖要讓另一位開發者能依序閱讀，因此先交代外部行為，再整理程式路徑與各節點的責任，最後連到測試、執行命令與待確認項目。

請根據前面已確認的證據，整理「四種標籤統計功能脈絡地圖」。

內容依序包含：
1. 功能的輸入、輸出與使用者可觀察行為。
2. 從 package.json 到命令列入口的啟動方式。
3. 完整呼叫路徑，每個節點列出檔案、函式與責任。
4. 資料從輸入路徑到最終輸出的形狀變化。
5. 對外匯出函式或 API；沒有 HTTP API 時明確標示。
6. 測試檔案、測試名稱、資料與對應行為。
7. 相關設定、文件、錯誤邊界、測試缺口與待確認項目。
8. 專案已定義的啟動、指定測試與完整測試命令。

所有結論附上檔案路徑與程式符號，不要加入沒有程式證據的推測。
保持唯讀，不要修改檔案、安裝套件、執行會寫入資料的命令或建立提交。

完整輸出可以搭配文字流程與簡單圖示，檔案路徑與程式符號仍要保留在正文中。圖示用來呈現上下游關係，文字則補充資料形狀、條件分支、函式責任與測試證據。

內容較長時，可以把主要呼叫路徑放在前面，再將例外處理、測試缺口與待確認項目集中整理在後面。

在程式庫探索相關說明中，應要求 Codex 說明模組責任、資料驗證位置與修改時需要注意的限制，並透過流程或檔案清單協助核對。

功能脈絡地圖進一步把入口、程式符號、資料流與測試證據串在同一份紀錄中，後續修改功能時，就可以直接沿著既有路徑確認影響範圍與驗證方式。

抽查地圖後保存可重用資訊

收到功能脈絡地圖後，先抽查兩到三段關鍵連結。從 package.json 驗證啟動設定，再從命令列入口追到統計函式，最後打開一個測試確認它確實驗證標籤輸出。

任何一段對不上，都應回到 Codex 對話要求修正地圖與引用位置。

接著執行 git status --short，確認探索期間沒有檔案變更。若 Codex 執行的工具產生快取或報告檔，要先確認來源與內容，再依專案規則處理。本次的成果只有功能脈絡地圖，程式與設定應保持原狀。

地圖中穩定且經過抽查的資訊可以保存到專案文件，例如啟動命令、測試命令、主要目錄責任與禁止修改區域。只適用於標籤統計的呼叫細節則留在功能文件或任務紀錄中，讓下一次修改可以快速找到入口，也避免專案規則塞入過多局部內容。

完成這次練習後，開發者應能從一項外部行為出發，請 Codex 找入口、追呼叫、整理資料變化、連到測試，再用路徑與符號抽查結果。這種探索方式能先建立可核對的理解，後續修改才有清楚的影響範圍與驗證位置。