鐵人檔案
《Codex 實戰 30 講》從入門操作開始，依序認識 Codex 的使用入口、內建指令、Prompt、AGENTS.md、Context Window、權限、安全邊界與設定方式。後續再進入測試、除錯、重構、程式碼審查、自動化、Skills、MCP 與團隊整合。每篇都搭配固定實作任務，從理解工具逐步進入可控、可驗證、可審查的 AI 輔助開發流程，最後延伸到團隊治理與安全管理。
把重複交代的內容留在專案裡 每次交付任務時，開發者常要重複說明套件管理工具、測試命令、命名方式與不可修改的目錄。這些資訊若只留在單次提示詞（Prompt）中，新...
Codex 看到的內容都有容量限制 開發者把錯誤紀錄、整個專案、需求文件與多輪對話交給 Codex 時，這些資訊都會進入 AI 用來推測的上下文（Context...
修改速度加快後，審查範圍也要跟著收斂 Codex 可以在一次任務中修改程式、測試與文件。當所有變更同時出現在差異（Diff）裡，開發者需要一次確認需求理解、資料...
每個可用狀態都需要一個清楚位置 Codex 可以在短時間內完成多輪修改。第一輪新增格式化函式，第二輪接上命令列參數，第三輪補上文件。 這些內容一旦長時間留在同一...
權限決定 Codex 能把任務做到哪裡 Codex 接到任務後，會先讀取專案，再修改檔案、執行測試及查看差異。這些動作各自需要不同權限。權限界線如果沒有先寫清楚...
沙箱把代理人的活動限制在可控制範圍 Codex 執行任務時，會讀取檔案、寫入程式、啟動測試並呼叫命令。沙箱（Sandbox）會替這些動作設定技術邊界，限制可寫入...
把重複使用的工具設定保存下來 前幾篇已在 AGENTS.md 寫下可修改範圍、禁止操作與沙箱（Sandbox）規則，這些規則會讓 Codex 了解專案要求。開發...
修改完成後需要實際執行驗證 Codex 可以閱讀程式，並推論修改是否合理，但這種判斷會缺少執行證據。 匯入路徑寫錯、型別不符、格式規則違反或測試行為改變，都要透...
測試把修改結果轉成可重複證據 Codex 完成程式修改後，可以立刻執行相關測試、讀取錯誤訊息並調整實作。 這段循環比單純閱讀程式多了一層執行證據。相同命令由另一...
遺留系統的測試策略 遺留系統常見的棘手狀況是程式已經運作多年，測試沒有完整記錄它的行為。需求文件可能缺漏，原作者也未必還在團隊裡。 這時若直接請 Codex 整...
