讓 Codex 在你睡覺時自己寫代碼 (Let Codex write code while you sleep)

原始來源與檔名：2026-05-19T092702+0800-让 Codex 在你睡觉时自己写代码.md

NAPKIN | 餐巾纸

餐巾紙公式

夜間自動化成功率 = 清晰的輸入邊界 + 限定的寫入範圍 + 明確的驗收命令

一句話

不要把 AI 當作能獨立思考產品的資深工程師，而是把它當成一個不知疲倦、但需要你發派精確「夜班工單」的底層執行者。

餐巾紙草圖

[錯誤的許願] "幫我優化專案" -> AI 猜測邊界 -> 隔天充滿 Bug 與衝突 (失敗)
[正確的派工] 定義範圍 + 定義約束 + 指定驗證命令 -> AI 嚴格執行 -> 隔天收穫確定的產出 (成功)

ROUND 1: SKELETON | 骨架掃描

• 核心問題: 為什麼讓 AI 在無人值守的情況下自動寫程式，隔天早上經常得到一堆半成品、版本衝突與權限災難？
• 核心答案: 因為開發者習慣對 AI「許願」而非「派工」。必須提供結構化的夜班工單，限定 AI 的修改範圍並強制執行驗證命令。
• 論證結構: 案例對比 -> 分類歸納 -> 實踐框架

章節骨架

1. 睡前任務的致命傷: 模糊的「幫我優化」會導致 AI 無限發散。
2. 三類最佳夜間任務: 唯讀掃描產出報告、小範圍針對性補測試、文檔與工程衛生維護。
3. 三類絕對禁止的任務: 產品判斷過重、跨前後端的大重構、需要真實生產環境權限的操作。
4. 實踐工具: 標準化的「夜班工單範本」與 AGENTS.md (AI 的員工手冊)。
5. 隔日驗收紀律: 先看 Diff 範圍與測試結果，最後才看 AI 的自我總結。

ROUND 2: DISSECTION | 血肉解剖

• 隱形假設: 開發者對專案的架構邊界有極高的掌控力，知道哪些檔案可以動、哪些不能動，並已經建立好自動化驗證機制 (如 npm run check)。
• 邊界條件: 若專案缺乏良好的單元測試覆蓋率或自動化 Linter 腳本，AI 在夜間就無法進行自我驗證，夜間自動化將失去意義。

ROUND 3: SOUL | 靈魂提取

• 知識連結: 與任務拆解 (Work Breakdown Structure, WBS) 以及微服務架構的隔離原則高度相關。
• 深層洞見: AI 能替你熬夜，但不能替你想清楚什麼事值得熬夜。自動化的本質不是省去 Code Review，而是把 Review 從「大海撈針」變成「檢查已經收斂的 Patch」。
• 行動呼籲: 停止在下班前對 AI 輸入「重構這包程式碼」。改為在倉庫中建立 AGENTS.md，並使用結構化的「工單模板」來指派任務。

讓 Codex 在你睡覺時自己寫代碼 (Architectural Deep Dive)

前言/背景

隨著 AI Agent 的能力提升，許多開發者幻想能實現「睡前丟需求，醒來收 PR」的完全自動化。然而，本文作者基於半年的實戰經驗指出：如果把 Agent 當作能自主決策的工程師來「許願」，只會引發災難。真正的夜間自動化需要極致的邊界管理與工程紀律，將 AI 視為一個需要明確「夜班工單」的執行者。

章節詳細總結

夜間自動化的核心條件 (睡前任务，最怕一句“帮我优化一下”)

在無人值守 (Unattended) 的狀態下，AI 一旦遇到模糊地帶就會開始「幻覺式猜測」。 架構師原則：睡前交接任務必須滿足三個絕對條件：

1. 輸入清楚
2. 寫入範圍清楚 (明確指定可讀與可寫的檔案清單)
3. 驗收命令清楚 (如 npm run check)

三類高 ROI 的夜班任務 (夜间自动化的 3 类好任务)

1. 唯讀掃描 (Read-only Scans)：最安全、成功率最高。例如掃描 TODOs、風險端點、未覆蓋測試的邊界。隔日產出優先級報告供人類決策。
2. 窄範圍補測試 (Small-scope Testing)：禁止下達「提高覆蓋率」這種大而化之的指令，這會讓 AI 產出大量低價值測試。必須指定行為，例如「只針對未付費無法產生公開報告這條路徑補測試」。
3. 文檔與工程衛生 (Documentation)：例如更新 README.md 中的環境變數或啟動指令。這類任務不影響線上邏輯，隔日極易 Review。

絕對禁止無人值守的三大雷區 (3 类任务，不要睡前交给它)

1. 產品決策過重：如「提升轉換率」。AI 無法在夜間自主進行視覺取捨與商業策略評估。
2. 跨前後端的架構大重構：牽一髮動全身的狀態欄位修改，容易導致第二天發生毀滅性的合併衝突 (Merge Conflicts)。
3. 涉及真實生產權限：絕對禁止夜間觸碰生產資料庫或發送真實信件。權限管理應遵循最小權限原則 (Least Privilege)。

實踐框架：夜班工單與 AGENTS.md (员工手册)

• 工單模板 (Work Order Template)：包含「目標、上下文、修改範圍 (允許與排除)、硬規則 (禁加依賴、禁改 UI)、驗證命令、最終輸出要求」。這是一套嚴謹的合約。
• AGENTS.md：這是給 AI 的「員工手冊」。將團隊的硬性架構規定 (如「不允許將確定性引擎替換為 LLM 調用」) 寫在專案根目錄，這比依賴 AI 的短期記憶更為可靠。

隔日驗收的標準作業程序 (第二天早上怎么验收)

人類工程師早上的驗收順序必須是防禦性的：

1. git diff --stat：首先確認修改範圍是否失控。
2. 檢查驗證日誌：確認自動化測試是否真實跑完且通過。
3. 閱讀關鍵 Diff：審查具體的程式碼邏輯。
4. 最後才看 AI 總結：AI 的總結是線索，不是事實 (Summaries are clues, not facts)。若 AI 未執行測試卻宣告完成，該任務視為無效。

總結與結論

• 自動化的前提是可預測性：無邊界的指令只會帶來混亂，極致的邊界約束才能帶來高效率的夜間產出。
• 並行探索，串行修改：對於多 Agent 協作，建議在夜間進行「並行唯讀探索」，而在寫入程式碼時應保持串行 (Sequential)，以避免 Git 衝突。
• 系統化的派工思維：給 AI 一句願望，它還你一堆猜測；給它一張規格嚴謹的工單，它還你一份精準的產出。