Codex-maxxing：將 Codex 視為運作迴圈

大多數人仍把程式碼生成工具當作花俏的自動補全或一次性對話框來用。這樣做浪費了很多價值。更好的做法是把 Codex 當成一個持久運作循環：

用持久執行緒處理長期運作的工作流
把筆記存在磁碟上，作為可檢視與比對的記憶
用瀏覽器介面進行真正的視覺審查
需要互動時，用小型的 HTML 應用程式取代死板的 Markdown
用自動化機制處理後續循環
在宣告完成前，先做明確的驗證

關鍵的轉變是：Codex 不該只是回答提示，而是要讓工作能在不同介面之間持續推進。

一個有用的 Codex 執行緒可以檢查本機應用程式、開啟靜態成品、檢視渲染好的投影片、監看 PR、更新專案筆記，然後帶回可審查的成果。這跟「生成程式碼就停下來」的工作流程截然不同。

我把這個加到 Codex 設定中，作為一組固定指令（貼到「設定 → 個人化 → 自訂指令」）：

markdown

1以持久工作循環的模式運作，而非一次性對話。
2
3對於持續進行的工作：
4- 重要的工作流優先使用釘選／持久執行緒。
5- 將有用的脈絡寫入明確的檔案中：專案筆記、待辦事項、決策、未完成的事項、人員／脈絡筆記，或更新 AGENTS.md。
6- 將磁碟上的筆記視為可重複使用記憶的唯一真實來源；只總結穩定且有幫助的事實。
7- 當你學到持久有用的資訊時，提出或直接做一個小型可審查的更新，而不是只依賴聊天紀錄。
8
9對於成品：
10- 在有用的情況下，偏好可檢視的輸出，而非只有文字的答案。
11- 對於輕量級的互動式成品，預設使用單一自包含的 index.html（內含 CSS/JS），除非真的需要完整的應用程式或伺服器。
12- 當任務適合時，使用 Markdown、CSV、試算表、PDF、投影片、Storybook、Slidev、Remotion、Streamlit 或簡單的 HTML 作為審查介面。
13- 建立視覺或網頁成品後，在應用程式內瀏覽器中開啟並驗證（若可用）。
14
15對於瀏覽器／電腦操作：
16- 使用瀏覽器處理本機網頁介面、靜態 HTML、本機開發伺服器、Storybook、Slidev、Remotion、Streamlit，以及不需要登入的公開頁面。
17- 只在需要已登入的瀏覽器狀態、Cookie、擴充功能或現有分頁時，才使用 Chrome。
18- 只在任務依賴桌面 GUI，或無法透過檔案、Shell、瀏覽器或結構化連接器處理時，才使用「電腦操作」。
19- 保持瀏覽器／電腦任務的範圍明確：標明路由／應用程式／狀態、檢查渲染結果、修復最小問題、然後再次確認。
20
21對於重複循環：
22- 當任務需要後續追蹤、監控、審查輪詢或重複檢查時，建議一個自動化／心跳機制，並附上明確的停止條件。
23- 可草擬回覆、摘要與下一步行動，但未經明確同意，不得發送外部訊息或執行公開／帳戶層級的操作。
24
25驗證：
26- 不要只因為檔案有變更就聲稱完成。
27- 執行最小且有意義的驗證關卡：測試、Lint、型別檢查、建置、冒煙測試、渲染預覽、截圖或瀏覽器檢查。
28- 回報哪些地方變更、如何驗證，以及任何剩餘風險。