昨天使用 Codex 建立了 Issue Tracker 的最小開發環境。

現在 repository 裡已經有專案設定、React 元件、測試與 README，終於有實際內容可以閱讀。

今天先不增加任何功能，而是開啟一個全新的 Codex 任務，請它把這份程式當成第一次接觸的陌生專案，替我們建立一張可以查證的 repository 地圖。

為什麼要開一個新的任務？

昨天的對話已經包含技術選擇、建立步驟、執行指令與驗證結果。

如果直接在同一段對話詢問「這個專案怎麼運作」，很難判斷 Codex 的回答究竟來自 repository 裡的檔案，還是延續了前面的對話內容。

所以今天會：

1. 開啟一個新的 Codex 任務
2. 選擇同一個 Issue Tracker repository 作為工作區
3. 只要求 Codex 閱讀與分析，不允許修改檔案

這樣可以模擬新工程師第一次加入既有專案的情境。

閱讀陌生專案時，先找地圖

第一次看到陌生 repository，很容易從第一個檔案開始逐行閱讀。但在不知道整體結構以前，這種方式常常會花很多時間，卻仍然不清楚程式從哪裡開始、各檔案之間如何連接。

我會先回答幾個高層次問題：

• 這是什麼類型的專案？
• 使用了哪些主要技術？
• 程式從哪裡開始執行？
• 重要目錄各自負責什麼？
• 開發、測試與建置指令定義在哪裡？
• 現在已經有哪些功能，哪些功能還不存在？

有了這張地圖，之後才知道要往哪個方向深入。

今天使用的 Prompt

我在新的 Codex 任務中輸入：

目標：
請把目前的 Issue Tracker repository 當成第一次接觸的陌生專案，替新加入的工程師製作一份專案導覽。

請說明：
1. 使用的技術棧，以及判斷依據
2. 應用程式的啟動入口與主要執行流程
3. 主要目錄與重要檔案的責任
4. 開發、測試與建置指令，以及它們定義的位置
5. 現有測試放在哪裡、目前驗證了什麼
6. 是否已經存在任務資料從 UI 到儲存層的流程；若不存在，請直接指出
7. 目前從檔案可以確認的限制、缺口或技術風險

限制：
- 這次只做唯讀分析
- 不要建立、修改、移動或刪除任何檔案
- 不要安裝套件或執行會改變狀態的指令
- 不要只根據常見的 React 專案結構猜測
- 每項結論都附上對應的檔案路徑
- 無法從檔案確認的內容要明確標示，不要自行補完

輸出格式：
先提供一段專案摘要，再依序整理「技術棧」「入口與流程」「目錄地圖」「指令與測試」「目前缺口」。
最後列出三項最值得人工抽查的結論。

這段 prompt 的回覆和執行

今日小結

今天沒有新增功能，而是讓一個全新的 Codex 任務只根據 repository 建立專案理解。