給 Codex 一個沒有說明的 Repository，就像請新同事第一天上班立刻修 Bug，卻不告訴他怎麼啟動服務。它也許會靠搜尋猜到入口，但每猜一次，都可能把時間花在錯的路上。今天的工作不是追求花俏的目錄，而是定義一個任何人拿到專案都能重現的起點。

先把「能跑」寫成可執行的步驟

任務追蹤 App 的 Repository 會從最小必要資訊開始：README 說明這是什麼、目前做到哪裡、如何安裝依賴、如何啟動、如何跑測試，以及遇到常見錯誤該去哪裡查。指令必須用實際專案驗證後才能寫成「已可使用」；在那之前只能標示為預定流程。否則一份漂亮但跑不通的 README，比沒有 README 更容易誤導人。

我會把專案結構保持容易搜尋，例如應用程式碼、測試、文件與設定各有固定位置，檔名能反映用途。環境變數則提供不含真實憑證的範例檔，列出名稱、用途和取得方式。真正的 API Key、密碼與 Token 不放進範例、不提交到 Git，也不貼進對話。

README 的第一屏我希望能回答四個問題：這個專案解決什麼問題？需要哪些前置工具？從零到看到畫面要依序執行哪些指令？要怎麼證明修改沒有破壞現有功能？若答案散落在聊天紀錄裡，新加入的人和 AI 都無法穩定取得。文件應該跟著程式一起版本控管，讓同一個 commit 對應同一套操作說明。

給 AI 的不是所有資訊，而是正確入口

對人類和 AI 都有用的入口是：專案目標、目錄地圖、執行指令、驗收標準、已知限制。這些資訊適合放在 README；需要長期遵守的工作規則，例如修改前先讀測試、不要更動生成檔、完成前回報檢查結果，則留給 Day 6 整理成 AGENTS.md。文件過長、過時或互相矛盾，同樣會增加誤判，因此每一條都應能對應到實際工作。

環境變數範例會用說明取代真值，例如 DATABASE_URL 旁註明「開發用資料庫連線字串」，而不把本機密碼直接寫進檔案。若某個變數缺少就無法啟動，應在啟動時明確報錯，而不是等第一個請求進來才失敗。這既是安全問題，也是降低 Debug 成本的設計。

我也會保留一條「乾淨環境測試」：換一個新目錄，依 README 從頭操作，不借用原本電腦上碰巧存在的套件或設定。只有這條路走通，才能說開發環境具備可重現性。日後文章中的指令截圖，也應對應這次實際執行，而不是擺拍一個成功畫面。

今天的檢查清單

在開始任何功能前，我會依序確認：全新下載的工作目錄能否照 README 啟動；環境變數缺少時錯誤是否可理解；測試指令是否存在且能執行；忽略清單是否排除憑證與本機產物；專案是否有一個清楚的 Issue 或任務入口。這五項都需要在真實 Repository 中跑過，不能只用文件文字自我證明。

今天的 Prompt 與可交付成果

交給 Codex 的初始任務會是：「先只讀 Repository。請列出專案入口、啟動指令、測試指令、環境變數範例與你無法確定的地方；不要修改檔案，也不要猜測不存在的指令。每一點標出來源檔案。」這個 Prompt 的目的，是先測試專案能否被正確理解，再決定文件哪裡該補。

目前可交付的是環境整理規格與驗證清單，還不是一份實測過的 Repository 報告。等專案建好後，我會把實際指令、輸出與遇到的失敗補在這裡。

今天學到什麼？

讓 AI「看懂」專案，不靠灌入整個程式碼庫，而靠少量可靠入口和可重現的指令。明天會把 Day 1 的任務追蹤 App 想法，轉成能開工的需求文件。