最近在規劃一個規模不小的系統升級時，我發現自己一直重複做同一件事：AI 丟出一堆方案，我卻要從頭問它三個老問題——這會不會幫到核心目標？會不會讓系統真的往前走？會不會把卡住的點解開，而不是製造新摩擦？

問到第三次，我開始想：與其每次都被迫當「審閱者」，不如把這三個問題變成流程的一部分，讓 AI 在提案階段就先替我消化。整理下來，我歸納成一個簡單的 workflow，把人的介入壓到最低，但把方向感緊緊守住。

先把願景寫成「憲法」，而不是每次都重新解釋

最消耗人的，不是評估方案，而是每次都要重講一次「我們到底想怎樣」。所以我會在季度初就花一次力氣，把願景轉成硬限制與加權優先級，當作這個專案的「憲法」餵給 AI。以後任何提案，先對照憲法：違反的就直接擋下或升級給人看；沒違反的，就在約束內自己做權衡。

原本講法 我會編碼成
「幫業務往前走」 前三項 KPI 與門檻，例如「p99 latency 要降 20%，infra 成本增幅不能超過 5%」
「解開摩擦再前進」 一份 friction inventory：現有技術債、團隊瓶頸、客戶痛點，任何提案都必須回應或明確承認
「不要偏離方向」 North Star Architecture：已批准的 pattern、禁用的技術、未來 12 個月視為不可動的介面

我把這份憲法放進 system prompt 或專案文件的長期記憶裡，人只在季度末回頭檢查它是否過時。

分層治理：小事放過，大事才請人看

不是所有決策都值得同樣的注意力。我會把提案分成三層，讓人只碰真正戰略危險的東西。

層級 例子 人的角色
Tactical 重構一個模組、加 feature flag、更新 dependency 零審閱：AI 提案、執行、回報 metrics
Structural 改資料模型、劃分新的服務邊界 非同步檢查點：AI 自動回答那三個問題，並標示與憲法的偏差
Strategic Monolith 拆微服務、雲端遷移、換平台 強制人審，但 AI 必須先預備一份「決策備忘」

用「一頁決策備忘」取代厚厚設計文件

對於重大的系統升級，我不要 AI 直接丟一份 design doc 過來。我會請它壓縮成一份 decision memo，在我開口之前就先回答我的隱憂。

  1. The Bet：用一句話說明這次方向性的改變是什麼，以及為什麼現在要做。
  2. Constraint Check：明確列出這個提案觸碰、違反或強化了哪些憲法限制。
  3. Friction Settlement：它解決了哪個現有卡點？又會引入什麼新摩擦？有什麼緩解措施？
  4. Rollback / Abort Criteria：在哪些可觀察的條件下，我們應該回滾或中止？
  5. Human Question Pre-emption：針對這個提案，預先回答我平常會問的那三個問題。

如果備忘過關，我只需要按一個鍵；如果感覺不對，我只需要丟出一個針對性的反駁，讓 AI 重新提案。

三個問題變成自評量表

我固定會問的三個問題，其實是在檢查三件事。我把它們變成 AI 自己要先打分的 rubric，這樣我不必每次都從頭評估。

問題 真正檢查什麼 過關標準
Would this help [specific outcome]? 目標對齊 提案是否直接推動前三項 KPI，還是只是分心？
Does this move the system forward? 技術債走向 變化是降低複雜度，還是為了 10 倍能力增益而值得增加複雜度？
Does this settle friction to move forward? 組織與操作可行性 它移除的是已知阻塞（部署痛苦、團隊認知負荷），而非製造新阻塞？

我會讓 AI 每項自評 1–5 分。只有任何一項低於 2 分，或理由薄弱，我才介入。

上線前，先跑 Shadow Mode

在人拍板之前，我會請 AI 先把提案跑一遍 shadow mode，把風險濃縮成摘要給我看，而不是把 raw output 丟過來。

  • Code-level：在 branch 上生成升級版本、跑完整 test suite、產出 diff summary。
  • Architecture-level：針對過往 incident post-mortem 做對照，或讓 AI 對自己的提案做一次 pre-mortem，列出最可能失敗的三種方式。
  • Business-level：讓 AI 以 red team 身份對照憲法，列出這個提案最可能偏離原始願景的三個地方。

我只看衝突摘要，而不是原始輸出。

我的角色，從審閱者變成把關者

做到這一步，人就不再是逐行讀文件的審閱者，而是憲法的策展者與例外的裁判。我的工作變成三樣：

  1. 定義憲法（每季度一次，高投入）。
  2. 處理 AI 標出的低分例外（低投入，只在 rubric 出現低分時）。
  3. 根據結果校正量表：上個批准的升級真的解開了卡點嗎？沒有的話，就把過關標準收緊。

實際上，我現在怎麼用它

以這次的大型系統升級為例，我的流程已經變成：

  1. 提案前：確認 AI 已經讀了憲法和 friction inventory。
  2. 提案中：要求它交出 decision memo + 自評 rubric。
  3. 提案後：我那三個問題應該已經在備忘裡被預答。我不是在腦力激盪，而是在驗證它的答案。答案紮實，就一次通過；不紮實，就退回一個針對性的反對意見。

目標是從「人讀完全部再問問題」變成「人讀一頁備忘，驗證預答」。

如果你也在嘗試讓 AI 幫你規劃系統升級，我建議從一件事開始：下一次收到方案，不要先看細節，先請對方用一頁決策備忘回答五個問題——這次賭什麼、觸碰哪些憲法、解開哪個卡點、何時該回滾、你那三個問題預答了沒有。備忘過關，才往下讀。你會發現，來回一次就夠。