這個測驗不是要考你「四個原則是什麼」——而是測你在真實場景中會怎麼反應。每題都是一個真實的開發場景，你會看到使用者需求和 AI 的回應，然後判斷這是不是好的做法。
答錯沒關係。每題的回饋會帶你回到對應的課程頁，讓你深入了解為什麼那個做法是錯的。學習的重點不是記住規則，而是在看到反模式時能立刻察覺。
選項 A：class PreferenceManager（含 cache、validator、merge、notify） 選項 B：def save_preferences(db, user_id, preferences)（6 行） —— 這題的陷阱在於：A 看起來比 B「專業」一百倍。
步驟 1：找「需求的最小核心」 需求是「儲存」——一個 UPDATE 就完成。 步驟 2：把 A 的每個元件跟需求對齊 - cache → 需求沒提效能問題 → 猜測性功能 - validator → 需求沒提錯誤資料 → 猜測性功能 - merge → 需求沒提合併語意 → 猜測性功能 - notify → 需求沒提通知 → 猜測性功能 步驟 3：確認「沒有反模式」的選項是否真的沒問題 B 只有 6 行，但行為清楚、可測試、可追溯——完全合格。 步驟 4：留意「題目本身」的引導 題目如果描述「使用者抱怨設定常常被覆蓋」→ merge 就是需求； 題目如果只是「儲存」→ merge 就是反模式。 → 場景題的答案，永遠藏在題目的情境細節裡。
測驗陷阱之所以有效，是因為它利用的是人類的認知偏誤，不只是模型的：
學員答題時選了 B（正確答案），但理由寫的是「因為 B 比較短」。這看似對了、其實沒懂：如果需求是「需要防止設定被併發覆蓋」，B 根本不夠，正確答案會是帶 lock 或版本欄位的方案。用「短」當判斷標準，等於把「簡潔優先」誤讀成「越短越好」——下次遇到需要一點複雜度的需求，就會答錯。判斷的座標必須是需求，不是長度。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 選了「看起來專業」但需求不符的選項 | 表面特徵捷徑壓過需求分析 | 先寫下需求的最小核心，再逐項核對選項 |
| 因為「比較短」而選了正確答案 | 把「簡潔」誤讀成「越短越好」 | 用「哪個選項最貼合需求」取代「哪個選項最短」當標準 |
| 沒看出選項裡「多出來的元件」 | 負面空間盲點——只看到有，沒看到「需求不需要」 | 強迫自己為每個元件問一句「哪個需求需要它？」 |
| 被題目的情境引導偏離 | 漏讀情境細節，把「需求」想成「一般情況」 | 圈出題目中描述問題的字句，把它們變成檢查清單 |
| 對不確定的題目用「猜」 | 沒有可操作的判斷框架 | 使用速查表六步流程＋「每行可追溯」作為固定框架 |
def save_preferences(db, user_id, preferences):
db.execute("UPDATE users SET preferences=? WHERE id=?",
(json.dumps(preferences), user_id))