前言：確認理解一致，比事後糾正便宜得多

第二部的核心根因是「目標架構只存在授權者腦中，沒有被說出來」，但反過來要求授權者每次都鉅細靡遺地講清楚所有細節，也不現實——有時候授權者自己都還沒把架構想得很完整。今天要講一個更輕量的解法：不要求授權者講到滴水不漏，而是讓執行者先複述一次自己的理解，把落差攔在動手之前。

今日目標

• 認識複述確認機制解決的具體問題
• 看一組「直接動手 vs 先複述再動手」的對照
• 理解這個機制的成本跟效益怎麼權衡

❌ vs ✅：直接動手 vs 先複述再動手

❌ 反例：收到任務描述直接開始做

使用者：重構這個模組，把資料存取邏輯收斂起來
AI：（直接開始動手改程式碼）

✅ 正例：先複述理解的方案，等確認再動手

使用者：重構這個模組，把資料存取邏輯收斂起來
AI：我理解的方案是：把目前分散在各處直接操作資料庫的程式碼，
    抽成一個獨立的 Repository 類別，Controller 只透過這個
    類別存取資料，不直接碰資料庫。這樣的方向對嗎？
使用者：對，但要注意現有的快取邏輯要一起搬過去
AI：（收到補充資訊後才開始動手）

這個機制解決的具體問題

複述不是在浪費時間確認顯而易見的事，它解決的是 Day 13 講的根因：把執行者「一般合理的理解」攤開來給授權者看，讓授權者有機會在動手前就發現落差，而不是等結果出來才發現。這一步的成本，是多花一輪對話確認；換來的效益，是避免掉一次可能需要整段重做的代價——對於複雜、方向不明確的任務，這個交換通常划算。

什麼時候不需要複述

不是所有任務都需要這個機制。任務越簡單、越明確、越可逆，複述的必要性就越低——重複做過很多次的固定流程、或者錯了也很容易修正的小改動，直接動手往往比多一輪確認更有效率。複述確認機制該用在 Day 15 那種「有具體架構期待、方向模糊、重做成本高」的情境。

今日思考題

回想你交代過的任務裡，哪一類最適合先要求複述確認、哪一類直接動手反而更有效率？你的判斷依據是什麼？

今日重點回顧

• 複述確認機制不要求授權者講到滴水不漏，而是讓執行者的理解攤開來，落差在動手前就被發現
• 這個機制的成本是多一輪對話，效益是避免重做的代價，對複雜任務通常划算
• 簡單、明確、可逆的任務不需要這個機制，直接動手效率更高

明日預告

明天講另一條規則：純粹提問的情境，要明講「先別動手」。