鐵人檔案
當 Codex 不再只是補 Code，而是開始跨多個 Session、Worktree、Repo 持續執行任務，真正的難題會從「怎麼下 Prompt」變成「怎麼治理 Agent」。這 30 天將以我的實際開發流程為案例，整理 AGENTS.md、Skills、Plan freeze、FULL／FAST Preflight、Worktree 隔離、Verification、Handoff、Migration Guardrail 與跨 Repo 共用治理等做法，並記錄 AI 在真實專案中反覆探索、誤改、Context 膨脹與部署風險如何被逐步收斂。目標不是教 Codex 指令，而是建立一套可驗證、
一開始，我對 AI Coding 的期待很單純。 把需求告訴 AI。 讓它幫我寫 Code。 有錯誤，再把錯誤訊息貼回去。 如果結果不對，就把 Prompt...
昨天提到，當 Codex 開始自己工作後，我開始在意的，不再只是 Prompt。 而是三件事： Context：它現在知道什麼？ Authority：它現在...
前兩天談到，我原本以為只要把需求講清楚、讓 Codex 繼續做下去，就能把開發速度一路往上拉。 但專案做久之後，我開始遇到另一個問題。 不是 Codex 不會...
Day 3 的焦點放在 AGENTS.md。 它解決的是一個很實際的問題： 不要讓每個新 Session，都重新教 Codex 一次這個 Repositor...
Day 4 留下了一個問題。 PROJECT_STATE.md 可以告訴新的 Agent： 這個專案現在在哪裡。 例如： 目前採用方案 B backend...
前幾天開始把不同種類的 Context 拆開。 AGENTS.md → 怎麼工作 PROJECT_STATE.md → 現在在哪 DECISIONS.md...
Day 6 談 Handoff 時，留下了一個問題： 如果下一個 Session 完全看不到上一輪聊天，只拿到 Repository 和一份最小 Handof...
Day 7 談到一件事： Conversation 可以消失，但重要狀態必須能從 Repository 重新取得。 這解決的是「Agent 要去哪裡找回正...
Day 8 把一部分重複 Prompt 抽成 Skill 之後，問題沒有結束。 反而多了一個以前不存在的狀態： 同一個 Skill 中央版本已更新 Repo...
