ClearForge
重點：我寫了一個 AI 架構教練，自己的狀態管理卻沒邊界——「AI 起草、人挑戰」最大的盲點，是教設計的工具沒被自己挑戰過。
我被自己寫的 AI 架構教練卡住了。
單人開發 DDD 的最大瓶頸
最近在開發一個合作的產品，因為屬於領域複雜型的產品，我決定採用 DDD，並把 DDD 融入原本的 AI 開發流程。
但只有一個人開發，DDD 最大的瓶頸就擺在眼前——
你做了一個架構決策，旁邊沒有夠資深的人陪你 review。
你只能自己跟自己對話，久了分不清自己是想清楚了，還是只是說服了自己。
沒人 review 這件事比想像中昂貴。等你發現漏想了什麼，code 已經長在錯的骨架上，重做的代價不是工時，是市場不會等你重來。
DDD Architecture Coach：AI 起草，人挑戰
所以我做了一個 Claude Code skill，叫 DDD Architecture Coach。
操作原則只有一句話：AI 起草，人挑戰。
一般人用 AI 是「我問、AI 答」，我把它倒過來。
AI 依照業務旅程，直接產出：
- Context Map 草稿
- Aggregate 定義
- 決策記錄
整份架構文件的初版由它寫。我的工作變成專注在挑戰：
「這個邊界不對，這條 invariant 跨了兩個 Bounded Context」
「這個 AI 介入點沒有 fallback，該被否決」
「這個用詞業務根本不會這樣說」
產出規格文件的負擔交給 AI，判斷跟挑戰的責任留給自己。 前者是低槓桿勞動，後者才是真正的架構工作。
然後這禮拜，這個 skill 打了我的臉
DDD 有一個核心原則：不同 Bounded Context 互不耦合，理論上可以平行推進。
我想加速，同時開不同的 Session 跑好幾個 BC 的架構設計與開發。
結果發現——我的 skill 沒在守它自己教的規則。
每個 phase 的指令都改寫同一份 arch-state.md，幾個 BC 一起推就互相覆蓋。
一個教你做邊界設計的工具，自己的狀態管理沒有邊界。
改法不複雜，但提醒的事很關鍵
改法本身不複雜：把 arch-state.md 變成 gitignored 的個人進度指標，per-BC 指令改成傳入 BC 名稱，共享狀態的問題就解了。
但這件事提醒我的不是技術細節。是——
我用了一段時間覺得順手之後，開始信任工具本身，減少了對它的挑戰。
而「AI 起草、人挑戰」這個模式能運作的前提，就是人不能停止挑戰——包括挑戰工具本身的設計。
容易忽略的盲點：從「挑戰者」變成「批准者」
至少現階段我的經驗是，把 AI 放在「起草者」而不是「回答者」的位置，對單人開發的架構品質幫助很大。
但這個模式有一個容易忽略的盲點：
當工具跑順了，你會不自覺從「挑戰者」變成「批准者」，只看產出順不順眼，不再去想它漏了什麼。
我這次是踩到具體的 bug 才發現。不知道還有多少是我還沒踩到的。
一個問題留給你
如果你也在嘗試用 AI 輔助架構決策，不只是寫 code——
你要怎麼確保自己還在真的挑戰，而不是不知不覺變成蓋章的人？