一個反直覺的工程決策

服務的金流串接——收單服務商介接、訂單建立、付款回調、開通訂閱、對帳——全部做完了，然後用一個旗標整個關起來，一天都沒有開過。

聽起來像做白工？這可能是我做過最正確的工程決策之一。

為什麼「能收錢」跟「要收錢」是兩件事

工程上「能收錢」很快，但商業上「要收錢」牽涉一堆工程以外的前置條件：收單服務商的特約審核（要等對方）、公司登記與稅務安排（要等行政流程）、法規面的確認（要等專業意見）。這些流程的共同點：時程不由我控制，而且不會因為程式碼寫得快就變快。

天真的排程是「等前置條件都齊了再開始寫金流」——那樣的話，條件成熟的那一天，才是工程開工的第一天，上線又要再等幾週。我的做法反過來：把工程做到「開關一撥就能收錢」的完成度，然後讓它待命。 等待期間燒的是行政流程的時間，不是工程時間——兩條線並行，總時程取決於較慢的那條，而不是兩條相加。

旗標怎麼設計

PAYMENT_ENABLED = env_flag("PAYMENT_ENABLED", default=False)

@router.post("/subscribe")
def create_subscription(...):
    if not PAYMENT_ENABLED:
        raise HTTPException(403, detail="付費功能尚未開放")
    ...

幾個實作上的講究：

• 預設值必須是關。 新環境、忘了設環境變數、CI——任何「沒有明確說開」的情境都是關。付費入口誤開的風險遠大於誤關。
• 關的是入口，不是程式碼路徑。 旗標之後的完整流程（建單、回調、開通）平常就被完整測試覆蓋著，用測試模式的假付款跑全流程。開燈那天不是「啟用一段沒人跑過的程式碼」，是「把每天都在測的路徑對外開放」。
• 兩種狀態都有測試釘住。 一支測試驗證旗標關閉時回 403，一支驗證開啟時流程正常——防的是有人（包括 agent）改程式碼時不小心讓旗標失效。
• 這個旗標被明文列為 agent 不可觸碰。 CLAUDE.md 裡寫死：付費開關的開啟是只有我本人能做的決定。原因跟 Day 14 的定價一樣——當 AI 有能力自主改碼部署，「哪些開關它絕對不能碰」必須是白名單之外的明確禁令。

這個模式的通用性

「地基先蓋好、開關後開燈」適用於所有「工程可控、開放時機不可控」的功能：等審核的、等法規的、等合作方的。它把「等待」從工程排程裡拆出去，也把「開放」變成一個零風險動作——那天要做的事只有撥一個環境變數，而不是趕工合併一條塵封的分支。

工程師的本能是「做完就上線」。商業服務教我的是：完成度和開放時機是兩個獨立變數，解耦它們，你才能在自己控制得了的維度上全速前進。