定義成功標準。反覆驗證直到達成。
將任務轉化為可驗證的目標：
對於多步驟任務，列出簡短計畫：
1. [步驟] → 驗證: [檢查項目]
2. [步驟] → 驗證: [檢查項目]
3. [步驟] → 驗證: [檢查項目]
強而有力的成功標準能讓 Agent 獨立反覆運算。薄弱的標準（「讓它動起來」）則需要不斷澄清。
LLM 非常擅長反覆執行直到達成特定目標——但前提是目標必須明確。當你說「修復驗證」，模型不知道什麼叫「修復」，它會開始改程式碼，然後根據你的反應猜測下一步。
但當你說「為空郵件寫測試 → 讓它通過 → 確認既有測試仍然通過」，模型就有了明確的驗證標準。它知道什麼時候算「完成」，不需要不斷問你。
關鍵心態：把「成功標準」當作合約。好的合約讓雙方都知道什麼時候算完成，不需要不斷來回確認。
我會這樣修復驗證系統： 1. 檢視程式碼 2. 找出問題 3. 進行改進 4. 測試變更 [在沒有明確成功標準的情況下開始修改]
要「修復驗證」，我需要定義成功標準。 如果是「使用者變更密碼後仍然保持登入狀態」： 計畫： 1. 撰寫測試：變更密碼 → 驗證舊 session 已失效 驗證：測試失敗（重現了錯誤） 2. 實作：在密碼變更時使 session 失效 驗證：測試通過 3. 檢查邊界情況：多個活躍 session、同時變更 驗證：額外測試通過 4. 驗證無回歸：既有的驗證測試仍然通過 驗證：完整測試套件全綠
到互動範例頁看這個原則的 ❌/✅ 對照：
計畫：
1. 閱讀 controllers/orders.py（2000 行）
2. 設計 service 層介面
3. 把邏輯搬過去
4. 讓所有測試通過
—— 前三步沒有任何驗證點。
搬錯一個 side-effect 的順序，測試全綠也抓不到
（例如：原本先扣庫存再記 log，搬成先記 log 再扣庫存）。
測試通過 ≠ 行為不變。
1. 編碼前思考（原則 1）：
→ 「拆 service 層」的邊界？先確認 controller 只負責 HTTP 處理，
業務邏輯（庫存、訂單狀態、log）全數下沉。提出方案讓使用者確認。
2. 目標驅動（原則 4）——重構的核心成功標準：
→ 行為不變 = 同樣輸入、同樣順序、同樣 side-effect。
→ 這必須是可執行的檢查，不是形容詞。
3. 分步計畫（每一步可獨立驗證）：
1. 先「鎖定」行為：為現有 controller 補上端點測試
驗證：既有 + 新增測試全綠（這是你重構前的「基準線」）
2. 搬移純計算邏輯（無 side-effect 的部分）到 service
驗證：全部測試仍然全綠，無一行行為改變
3. 搬移有 side-effect 的邏輯（扣庫存、記 log、發事件）
驗證：測試全綠 ＋ 針對「side-effect 順序」加 3 個斷言測試
4. controller 瘦身到只留 HTTP 處理
驗證：端點測試全綠、完整套件無回歸、diff 內無多餘改動
4. 精準修改（原則 3）：
→ 搬移時「複製貼上」而非「順手重構」——先搬，改動留到確認行為不變之後。
next-token prediction 優化的是「接下去最自然」，不是「可執行」。「我會檢視程式碼、找出問題、進行改進」這句話在語言上無懈可擊——它讀起來像個專業的計畫，但沒有任何一個字可以被檢查。這是形式完整而內容空洞：模型的流暢度讓模糊的計畫聽起來具體。
成功標準的作用：給定一個明確目標（「100 個請求 → 前 10 個成功、其餘 429」），模型的搜尋空間急劇縮小——它知道「完成」長什麼樣，可以獨立反覆運算直到命中。反之，模糊目標讓模型處於「猜測式完成」模式：每做完一步就停下來等你糾正，因為它永遠不知道自己是否完成了。強目標省掉的不是模型的工作，而是來回澄清的回合數。
Sycophancy（討好偏誤）：RLHF 讓模型傾向說出「能讓使用者開心」的話——「我會把它修好的！」比「我不確定問題是什麼」更能讓使用者滿意。原則 4 就是要剝掉這層討好：讓「承諾」退位，讓「可檢查的條件」進場。當模型說「我會修好」，你該回：「好的，那請先寫出能重現它的測試。」
Agent 學會了原則 4 的「格式」：每個步驟後面都加了「驗證：」。但打開一看——「驗證：功能正常」「驗證：程式碼優雅」「驗證：使用者滿意」。有驗證欄位，但驗證條件不可操作。這是形式主義的勝利：計畫的形狀對了，本質卻沒變。原則 4 的成功標準必須是「人 or 機器可以執行的檢查」：跑一個指令、看一個數字、做一個斷言。任何需要主觀判斷的「驗證：」都是沒寫。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 計畫是「檢視 → 改進 → 測試」 | 沒有可驗證標準，模型在表演流程 | 要求每步改成「為 X 寫測試 → 讓它通過」的句式 |
| 一次交出 300 行完整實作 | 一次到位——沒有中間驗證點 | 要求拆成可獨立驗證的步驟，每步一個 commit |
| 「驗證：功能正常／使用者滿意」 | 驗證條件不可操作，形式主義 | 要求驗證必須是可執行的檢查（指令、數字、斷言） |
| 沒先重現 bug 就直接改碼 | 跳過重現——把「改」當成「修」 | 要求先寫失敗測試證明你能重現，再動手 |
| 修好 bug 但既有測試變紅 | 忽略回歸——只驗證了目標，沒驗證環境 | 「完整測試套件全綠」必須列入完成標準的一部分 |
收到需求後的假設盤點： 1. 通知類型：系統通知？行銷通知？兩者分開管理嗎？ 2. 即時性：需要 WebSocket 推送？還是定期刷新就好？ 3. 偏好設定：每個通知類型獨立開關？還是全開/全關？ 4. 資料量：使用者通常有幾百條還是幾萬條通知？ 5. 保留策略：通知保留多久？會自動清除嗎？ → 確認：系統通知（非行銷）、定期刷新、每個類型獨立開關、 預設數百條、保留 90 天。
# V1 只做：列表（API） + 標記已讀 + 每類型開關 # 先不做：WebSocket、通知分組、批量操作、匯出 # 三個核心 API endpoint ≈ 60 行 GET /notifications → 分頁通知列表 POST /notifications/:id/read → 標記已讀 GET /notifications/preferences → 偏好設定 PUT /notifications/preferences → 更新偏好
新增：notifications.py, templates/notifications.html 修改：app.py（加 4 個 route） 刻意沒動的： - templates/layout.html 的 CSS 變數命名 - app.py 裡既有 route 的格式不一致 - tests/ 裡「看起來覆蓋不夠」的舊測試
計畫與驗證： 1. 實作資料模型 驗證：DB migration 成功 + 單元測試全綠 2. GET /notifications — 分頁列表 驗證：curl 返回正確格式 + 分頁參數生效 3. POST /notifications/:id/read — 標記已讀 驗證：呼叫後 GET 列表中該通知 is_read=true 4. 偏好 API 驗證：設定某類型關閉 → 該類型通知不出現在列表中 5. 既有測試 驗證：完整套件全綠，無回歸 每步一個 commit，每步都可獨立回滾。
效能：沒有明確的效能目標，優化就是盲人摸象。「讓它更快」不是目標——「P99 回應時間從 500ms 降到 200ms 以下」才是。目標驅動要求你在動手之前就定義「多少算夠」，然後每一步的驗證都跑出數字。例如：加了資料庫索引後，EXPLAIN ANALYZE 的結果從「Seq Scan」變成「Index Scan」、執行時間從 300ms 降到 5ms——這才是「驗證通過」，不是「我覺得變快了」。
品質：模糊的完成標準是品質的頭號殺手。「確保它能運作」沒有任何可操作的含義——什麼叫「運作」？通過哪些測試？覆蓋哪些邊界？目標驅動要求你把「品質」拆成可執行的檢核：單元測試通過、整合測試通過、端到端手動測試通過、code review 完成。每一個都是一個可檢查的條件，而不是一個主觀判斷。
安全：安全修復如果没有明確的完成標準，就等於沒修。「修好了」不是安全驗證——「重複漏洞的攻擊向量已被阻斷，既有安全測試仍然全綠，且未引入新的 CVE」才是。目標驅動在安全場景的關鍵是：把「我相信它安全了」變成「我用可執行的測試證明它安全了」。
Agent 寫了一個測試 def test_rate_limit(): assert limiter.allow() == True——測試永遠通過，但什麼都沒測到（沒有模擬滿額情境）。這是原則 4 的形式主義勝利：有「驗證」欄位，但驗證條件不可操作。真正的驗證必須能「失敗」：先證明它在錯誤條件下會失敗，然後修復它讓它通過。
| 面向 | 原則 4 · 目標驅動執行 | 相關原則 | 差異說明 |
|---|---|---|---|
| 核心動作 | 定義可驗證的成功標準，反覆驗證直到達成 | 原則 1（編碼前思考） | 兩者都管「方向」：原則 1 在動手前問「做什麼對的事」，原則 4 在動手後問「怎麼知道做對了」。前者管釐清，後者管驗收。 |
| 時機 | 整個開發過程中（每步都驗證） | 原則 2（簡潔優先） | 原則 4 管「驗證」，原則 2 管「範圍」。兩者搭配：用最少的程式碼（2），每一步都可驗證（4）。缺一不可。 |
| 對抗的偏誤 | Sycophancy（討好偏誤）——「我會修好的！」的空頭承諾 | 原則 3（精準修改） | 原則 4 管「做了對不對」，原則 3 管「改了多少」。兩者搭配：改得精準（3），且每步可驗證（4）。 |
| 最大價值 | 把來回澄清的回合數降到最低 | 原則 1（編碼前思考） | 原則 1 減少「方向錯誤」的回合；原則 4 減少「完成標準不清」的回合。兩者共同降低人機協作的溝通成本。 |