前言：反過來驗證：講清楚之後，還會不會走偏

前面幾天講的都是「沒講清楚導致走偏」的案例，今天反過來看：當目標架構真的被講清楚了，AI 動手前有沒有機會直接抓對方向，而不需要事後靠一句「不對！」來修正。

今日目標

• 對照 Day 11 案例，看同一類任務在講清楚架構後會有什麼不同
• 理解「事先講清楚」具體該包含哪些資訊
• 認識這種對照本身怎麼驗證 Day 13、14 的根因分析是否成立

對照：同一類任務，兩種起手式

Day 11 的案例裡，任務描述只給了「重構這個模組」這樣的方向，AI 憑一般理解動手，結果跟心裡設想的分層架構不一致。如果換一種起手式——在動手前明講「這裡要遵守 Controller/Repository/Middleware 的分層，資料存取邏輯只能出現在 Repository 層」這種具體的架構期待，AI 就有明確的依據可以對照，而不是靠猜測一般做法。

講清楚架構，具體該包含什麼

從 Day 13、14 的根因回推，一個有效的「講清楚」至少該包含：目標架構的具體分層跟各層職責（不是只說「要重構」，是說清楚哪一層該負責什麼）、現有程式碼裡有沒有已經存在的類似實作可以參考（避免重新做出一個已經存在的東西）、如果不確定意圖是提問還是請求，先講明這次是哪一種。這三項分別對應第二部前四天分析出的三個根因缺口。

這個對照怎麼驗證前面的分析

如果第二部前四天的根因分析是對的，那麼補齊這三項資訊之後，同一類任務走偏的機率應該明顯降低——這正是這種「反過來驗證」的價值：不只是分析問題出在哪裡，還要能推導出「補上什麼資訊，問題會不會真的緩解」，這是根因分析有沒有找對地方的重要檢驗方式。

今日思考題

回想你經歷過的一次「事先講清楚反而順利」的協作經驗，那次你講清楚的，剛好對應到今天列的哪一項？

今日重點回顧

• 對照 Day 11 的案例，換一種講清楚架構期待的起手式，AI 有明確依據可以對照，不需要靠猜測
• 講清楚該包含：具體分層職責、現有可參考的實作、意圖是提問還是請求
• 這種反過來驗證的方式，是檢驗根因分析有沒有找對地方的方法

明日預告

明天開始定規則：先讓 AI 複述它理解的方案，再決定要不要動手。