絕大多數 AI 編碼工作流有一個共同的失敗模式：每次對話都在重新建構整個任務。

你解釋了一遍架構，下次還要解釋。你做了一個決策，沒有記錄，下次 AI 不知道。你要求了一個特定的程式碼風格，每個新會話都要重申一次。

這不是 AI 能力的問題，而是連續性基礎設施的問題。

每次對話都是一個新工人

想像一個人類工程師的工作方式：他有設計文件、需求紀錄、程式碼審查歷史、部署日誌。這些文件讓他不需要在每次開工時都從頭回憶上次做了什麼。

AI 編碼工具在這方面像一個沒有任何記憶的承包商：每次雇用，你都要重新交接所有東西。

Codex Factory Kit 的設計信念是：把「記憶」具體化為 repo 內部的持久化制品。

八個階段，八個制品

Codex Factory Kit 把一個完整的任務分解成八個階段：

1. Bootstrap — 建立 PRODUCT.md，描述目標和限制
2. Office Hours — 和 AI 對話釐清需求，更新 PRODUCT.md
3. Sprint Conductor — 生成 PLAN.md 和 TESTPLAN.md
4. Implementation — 執行計畫，AI 作為子 Agent
5. Review Gate — 生成 REVIEW.jsonl，結構化審查紀錄
6. QA Runtime — 驗證，更新 TESTPLAN.md
7. Document Release — 更新 RELEASE.md
8. Retro — 生成 RETRO.md，記錄學到的東西

每個階段的輸出都是下一個階段的輸入。這個循環不依賴 AI 的記憶，而是依賴寫在磁碟上的事實。

輕量模式存在的原因

不是每個任務都需要走完八個階段。小的一次性修改跑完整流程反而增加開銷。

Codex Factory Kit 有輕量模式，讓簡單任務保持簡單。設計原則是：大任務得到更可靠的結果，小任務保持快速，不需要在兩者之間做妥協。

工廠比喻的意義

「工廠」不是隨機的比喻。工廠的核心特性是：標準化流程讓每次生產的結果可預測。

工廠不依賴某個特定工人的個人能力，而是依賴流程本身。Codex Factory Kit 試圖把這個邏輯引入 AI 編碼：用標準化的制品和流程，讓 AI 對話的結果更可預測，讓跨會話的工作能夠真正累積，而不是每次都重新開始。

誰適合用這個

這個工具不適合每個任務都是小型單次修改的使用者。它適合：

• 在真實 repo 上用 Codex 做嚴肅工程工作的開發者
• 需要跨多個會話完成較大任務的場景
• 想讓規劃、審查、QA 有明確紀錄可查的團隊

如果你的工作流是「問一個問題、得到一個答案、繼續下一件事」，Codex Factory Kit 可能是過度設計。如果你的工作流是「用 AI 推進一個有多個移動部件的複雜專案」，它可能是你一直缺少的那一層。