在開發 Book Overview App 的過程中，我設計了一套完整的 Hook 系統防護體系，目的是防止開發過程中的逃避行為和確保AI的工作品質。

🔸 Hook 防護體系設計起因

AI會有逃避行為，以完成任務指標為優先而捨棄程式品質或者直接修改測試。

我設計了以下幾種防止停止和強制繼續的 Hook 機制：

🔹 check-todos.py - TodoWrite 完成度檢查

1# 防止未完成工作的會話結束
2if todos_pending or todos_in_progress:
3    output = {"continue": True, "stopReason": "Incomplete todos detected"}

• 🔹 目的: 防止有未完成 TodoWrite 任務時意外停止
• 🔹 機制: 檢查 transcript 中的 TodoWrite 工具狀態
• 🔹 效果: 強制繼續工作直到所有對話任務完成

🔹 check-work-log.sh - 工作日誌完成度檢查

1# 當工作狀態為進行中時，exit 2 阻止停止
2exit 2  # 阻止會話結束，要求繼續工作

• 🔹 目的: 確保當前版本的工作確實完成才允許停止
• 🔹 機制: 分析工作日誌的完成指標和技術債務狀況
• 🔹 效果: 避免「假性完成」，確保工作品質

🔹 check-next-objectives.sh - 版本系列目標檢查

1# 當版本系列仍在進行中時，exit 2 阻止停止
2exit 2  # 防止版本系列中途放棄

• 🔹 目的: 防止版本系列開發中途放棄
• 🔹 機制: 檢查 todolist.md 中的版本系列完成度
• 🔹 效果: 確保版本系列目標達成才允許推進

🔹 check-5w1h-compliance.py - 決策品質檢查

1# 當 5W1H 分析不合規時，阻止 TodoWrite
2{"decision": "block", "reason": "5W1H analysis required"}

• 🔹 目的: 防止逃避性思考和粗糙決策
• 🔹 機制: PreToolUse 階段攔截並檢查 5W1H 完整性
• 🔹 效果: 強制深度思考，杜絕逃避行為

🔸 遇到的邏輯衝突問題

在開發過程中，發現了奇怪的狀況：

原問題:

• check-todos.py 顯示 “All todos completed successfully.”
• 同時系統又顯示 “Stop hook prevented continuation” 訊息
• 我的問題是：已完成所有 todos 為何還阻止停止？這訊息是誰吐出來的？

根本原因:

• 不同 Hook 腳本檢查不同的 todo 來源（會話 vs 專案）
• 會話的任務已結束，但是有其他hook觸發了避免停止的機制

設計思路

防護體系的核心理念：

• 多層防護：從對話層、工作層、版本層、決策層建立完整防護
• 零逃避容忍：任何逃避行為都會被自動檢測和阻止
• 品質強制：不符合品質標準的工作不允許繼續
• 使用者指引：被阻止時提供明確的修正指引和下一步行動

Exit Code 官方定義

根據 Claude Code 官方文件，Hook 腳本的 Exit Code 具有特定含義：

Exit 0 - 成功執行

1exit 0

• 🔸 正常成功執行
• 🔸 允許 Claude Code 繼續操作
• 🔸 不會產生任何阻止行為
• 🔸 用途: 檢查通過、條件滿足、正常完成

Exit 1 - 一般錯誤

1exit 1

• 🔸 非阻塞性錯誤
• 🔸 操作仍可繼續
• 🔸 表示: 有問題但不嚴重
• 🔸 用途: 輕微問題、建議性警告

Exit 2 - 阻止停止 (關鍵!)

1exit 2

• 🔸 阻止 Claude Code 停止會話
• 🔸 顯示 stderr 內容給 Claude
• 🔸 強制要求繼續工作
• 🔸 用途: 工作未完成、需要繼續開發
• 🔸 注意: 這是「阻止停止」而非「阻止繼續」

Exit 3+ - 嚴重錯誤

1exit 3

• 🔸 嚴重錯誤狀態
• 🔸 通常阻止繼續
• 🔸 自定義錯誤類型
• 🔸 用途: 需要立即處理的問題

Exit 2 的真正定義

語意澄清

🔸 錯誤理解:

• “Stop hook prevented continuation” = 阻止繼續工作

🔸 正確理解:

• “Stop hook prevented continuation” = 阻止了「停止會話」這個行為
• 實際效果在我腳本觸發的原因：當前會話還有todo清單未完成，強制繼續工作，不允許停止會話

實際應用場景

專案中的 Exit 2 使用案例：

check-work-log.sh

 1# 當工作狀態為 "IN_PROGRESS" 時
 2if [[ $WORK_STATUS == "IN_PROGRESS" ]]; then
 3    echo "工作進行中，建議完成後再推進"
 4
 5    # 輸出詳細說明到 stderr
 6    cat >&2 <<EOF
 7🔸 版本推進暫停 - 當前工作尚未完成
 8
 9🔸 停止原因：
10• 工作日誌顯示工作仍在進行中
11• 完成度指標不足
12• todolist.md 中有待辦任務
13
14🔸 建議的 TodoWrite 任務：
15請執行以下工作項目...
16EOF
17
18    exit 2  # 阻止停止，要求繼續工作
19fi

check-next-objectives.sh

 1# 當版本系列狀態為 "IN_PROGRESS" 時
 2case "$SERIES_STATUS" in
 3    "IN_PROGRESS")
 4        echo "版本系列仍在進行中"
 5
 6        # 提供具體的待辦任務資訊
 7        cat >&2 <<EOF
 8🔸 版本推進暫停 - 當前版本系列仍在進行中
 9
10🔸 部分待完成任務範例：
11• 修復UI測試中的類型問題
12• 更新ViewModel層錯誤處理適配
13
14🔸 建議的 TodoWrite 任務：
15繼續版本系列開發...
16EOF
17
18        exit 2  # 阻止停止，要求繼續版本開發
19        ;;
20esac

🔸 Hook 系統邏輯衝突解決方案

問題診斷

衝突場景:

• check-todos.py 檢查 TodoWrite 工具（會話級別）
• 其他 Hook 腳本檢查 todolist.md（專案級別）
• 結果：TodoWrite 完成但 todolist.md 仍有待辦事項

解決策略

方案一：Hook 腳本提供 TodoWrite 建議

在返回 exit 2 的 Hook 腳本中：

 1# 檢查 todolist.md 中的未完成任務
 2PENDING_TODOS=$(grep -c "\[ \]" "$PROJECT_ROOT/docs/todolist.md" 2>/dev/null || echo "0")
 3
 4# 在 stderr 中提供 TodoWrite 建議
 5cat >&2 <<EOF
 6🔸 建議的 TodoWrite 任務：
 7請執行以下 TodoWrite 來管理具體工作項目：
 8
 9TodoWrite([
10  {"content": "完成當前版本核心開發工作", "status": "pending", "activeForm": "完成當前版本核心開發工作"},
11  {"content": "執行完整測試確保100%通過率", "status": "pending", "activeForm": "執行完整測試確保100%通過率"}
12])
13EOF

方案二：統一狀態檢查邏輯

確保所有 Hook 腳本檢查相同的狀態來源，或者建立狀態同步機制。

實際演練

Exit Code 選擇原則

• 🔸 Exit 0: 一切正常，可以繼續
• 🔸 Exit 1: 有小問題，但可以繼續
• 🔸 Exit 2: 工作未完成，禁止停止，必須繼續
• 🔸 Exit 3+: 嚴重問題，需要立即處理

Hook 腳本設計模式

 1#!/bin/bash
 2
 3# 🔸 檢查狀態
 4check_work_status() {
 5    # 實作狀態檢查邏輯
 6}
 7
 8# 🔸 根據狀態決定 exit code
 9case "$WORK_STATUS" in
10    "COMPLETED")
11        echo "工作已完成，可推進版本"
12        exit 0
13        ;;
14    "MOSTLY_COMPLETED")
15        echo "基本完成，建議檢查後推進"
16        exit 1
17        ;;
18    "IN_PROGRESS")
19        echo "工作進行中，建議完成後再推進"
20
21        # 🔸 提供詳細的使用者指引
22        cat >&2 <<EOF
23🔸 停止原因說明
24🔸 需要採取的行動
25🔸 建議的 TodoWrite 任務
26EOF
27
28        exit 2  # 阻止停止
29        ;;
30    *)
31        echo "工作未完成，需要繼續開發"
32        exit 3
33        ;;
34esac

使用者體驗優化

• 清楚的錯誤訊息: 使用 stderr 輸出詳細說明
• 具體的行動指引: 告訴使用者需要做什麼
• TodoWrite 整合: 提供可執行的任務建議
• 狀態一致性: 確保不同檢查機制的邏輯一致

🔸 實際測試結果

測試案例 : check-work-log.sh

1$ ./.claude/scripts/check-work-log.sh
2# 返回 exit 3，stderr 顯示：
3🔸 版本推進暫停 - 工作未開始或缺乏完成指標
4🔸 停止原因：
5• 工作日誌缺乏完成指標 (0 = 0)
6• todolist.md 中有 240 個待辦任務
7
8🔸 建議的 TodoWrite 任務：
9請執行以下 TodoWrite 開始系統化工作...

測試案例 🔸: check-next-objectives.sh

1$ ./.claude/scripts/check-next-objectives.sh
2# 返回 exit 2，stderr 顯示：
3🔸 版本推進暫停 - 當前版本系列仍在進行中
4🔸 部分待完成任務範例：
5• 修復UI測試中的類型問題
6• 更新ViewModel層錯誤處理適配
7
8🔸 建議的 TodoWrite 任務：
9請執行以下 TodoWrite 繼續版本系列開發...

🔸 效果評估

問題解決成果

• 🔸 邏輯一致性: Hook 系統不再產生矛盾訊息
• 🔸 使用者體驗: 清楚知道為什麼被阻止和需要做什麼
• 🔸 工作流程: TodoWrite 與 todolist.md 狀態同步

關鍵學習

🔸 Exit 2 的真實含義: 阻止停止，要求繼續工作 🔸 stderr 的重要性: Claude Code 會顯示 stderr 給使用者 🔸 狀態檢查一致性: 不同檢查機制需要協調 🔸 使用者指引: 提供可執行的具體建議比抽象說明更有效

後續改善方向

• Hook 腳本標準化: 建立統一的錯誤處理和訊息格式
• 狀態同步機制: 建立 TodoWrite 與 todolist.md 的雙向同步
• 使用者體驗測試: 收集真實使用場景的反饋
• 文件完善: 將這些經驗整理成團隊開發規範

🔸 參考資源

• Claude Code Hooks Guide
• Claude Code Hook Events
• reddit網友分享 在有todo未完成的情況下用hook偵測會話轉階段，強迫AI繼續工作不要停下來

在與 LLM AI 協作過程中，我們發現了一個關鍵問題：AI 面對複雜問題會產生逃避行為，包括簡化問題、延後處理、或使用臨時解決方案。

為了徹底解決這個問題，我們發展了三層防護機制：

1. 第一層：AI 內建自檢 - 在每次回應前強制執行檢查，從源頭預防逃避行為
2. 第二層：Hook 系統驗證 - 透過自動化腳本進行事後驗證和持續監控
3. 第三層：修復模式 - 發現問題時提供補救措施和修正指引

這套方法論不只確保 AI 協作品質，也成為我們所有開發決策的指導原則。

三層防護機制架構

第一層：AI 內建自檢機制

這是最重要的防線，AI 在生成任何回應前都必須執行以下強制檢查：

30秒核心檢查清單

1. 三大鐵律檢查

   • 測試通過率鐵律：是否包含「測試失敗可接受」的思維？
   • 永不放棄鐵律：是否想跳過、暫時處理、或延後任何問題？
   • 架構債務零容忍鐵律：是否發現架構問題卻想稍後處理？

2. 逃避詞彙檢查

   • 中文禁用詞：「太複雜」「先將就」「暫時性修正」「症狀緩解」等
   • 英文禁用詞：workaround, bypass, hack, quick fix 等
   • 簡化妥協詞：「更簡單的方法」「簡化處理」「簡化測試」等

3. 品質標準檢查

   • 解決方案是完整的，還是妥協的？
   • 是否在迴避根本問題？
   • 回應是否體現專業工程師標準？

檢查失敗處理

如果任何檢查項目失敗：

1. 立即停止當前回應生成
2. 重新分析問題和解決方案
3. 重新構思符合三大鐵律的回應
4. 再次檢查直到通過所有項目

第二層：Hook 系統驗證

自動化腳本在關鍵時刻執行檢查：

觸發時機

• UserPromptSubmit: 每次用戶輸入時檢查工作流程合規性

• PostToolUse: 檔案編輯後檢查程式異味和品質

• PreToolUse: 工具使用前檢查是否有阻止狀態

• Stop: 回應完成後分析版本推進狀態

檢查項目

• ESLint 錯誤偵測和追蹤
• 技術債務累積監控
• 任務逃避行為偵測
• 程式異味自動分析
• 效能指標監控

第三層：修復模式

當前兩層發現問題時的補救機制：

進入條件

• AI 自檢發現違規詞彙或思維
• Hook 系統偵測到逃避行為
• 品質指標超過容忍閾值

修復流程

1. 停止所有開發活動
2. 分析問題根因和影響範圍
3. 制定具體的修正計劃
4. 執行修正並驗證結果
5. 記錄學習並更新防護機制

完成標準

• 所有違規行為已修正
• 品質指標回到可接受範圍
• 問題根因已徹底解決
• 預防措施已建立

核心立場

我們接受的：計劃性延後

計劃性延後是正當的開發策略。我們接受並鼓勵以下形式的延後：

版本規劃的延後

• v0.1 做基礎功能，v0.2 加進階功能 → 正確
• 明確標註「此功能於 v0.3 實作」→ 正確
• 每個版本有完整可用的交付物 → 必要

TDD 最小實現

• 先通過測試，再優化效能 → 正確
• 實作最小功能，重構階段再改善 → 正確
• 為擴展預留介面，但不過度設計 → 正確

風險管理的優先級

• 核心流程優先，邊緣案例延後 → 合理
• 安全問題優先，美觀問題延後 → 必要
• 已知範圍的問題，計劃性處理 → 專業

我們拒絕的：逃避行為

以下行為是逃避，必須立即糾正：

模糊的拖延

• 「太複雜，之後再說」→ 錯誤
• 「暫時跳過」但無具體計劃 → 錯誤
• 「先將就用」沒有改善時程 → 錯誤

核心責任的迴避

• 發現架構問題但繞過 → 不可接受
• 省略錯誤處理 → 不可接受
• 降低測試標準來通過 → 不可接受

債務的累積

• TODO 沒有追蹤和時程 → 失職
• 臨時方案變永久 → 技術腐敗
• 問題擴散不處理 → 專案危機

完整違規詞彙對照表

為了確保一致性執行，以下是完整的違規詞彙清單：

品質妥協和逃避責任類

簡化妥協類

測試品質妥協類

發現問題但不解決類

程式碼修改逃避類

模糊不精確詞彙類

處理原則

面對複雜問題

複雜不是逃避的理由。我們的處理方式：

1. 分解：任何複雜問題都能分解為可管理的部分
2. 排序：依影響和依賴關係決定處理順序
3. 執行：逐步解決，每步都有可驗證的成果

意外狀況的決策

遇到預期外的技術挑戰時：

立即解決的情況

• 阻塞其他開發 → 立即處理
• 影響資料完整性 → 立即處理
• 安全漏洞 → 立即處理

可以延後的情況

• 效能優化（功能正常）→ 可計劃延後
• UI 美化（體驗可用）→ 可計劃延後
• 邊緣案例（主流程正常）→ 可計劃延後

需要重新評估的情況

• 暴露設計缺陷 → 停下來重新設計
• 依賴關係錯誤 → 調整架構
• 需求理解偏差 → 重新確認需求

AI 回應前自檢機制詳解

30秒強制檢查流程

AI 在生成任何回應前都必須完整執行以下檢查：

第一階段：三大鐵律檢查

 11. 測試通過率鐵律檢查
 2   問：我的回應是否包含「測試失敗可接受」的思維？
 3   問：是否想要跳過測試或降低測試標準？
 4   要求：必須堅持 100% 測試通過率
 5
 62. 永不放棄鐵律檢查
 7   問：我是否想跳過、暫時處理、或延後任何問題？
 8   問：是否在尋找「更簡單」的方法來迴避複雜性？
 9   要求：必須面對並解決所有問題
10
113. 架構債務零容忍鐵律檢查
12   問：我是否發現架構問題卻想稍後處理？
13   問：是否想要使用臨時方案或權宜措施？
14   要求：必須立即修正架構問題

第二階段：逃避詞彙檢查

 1中文禁用詞彙掃描：
 2□ 「太複雜」「先將就」「暫時性修正」「症狀緩解」
 3□ 「先這樣處理」「臨時解決方案」「回避」「不想處理」
 4□ 「更簡單的方法」「簡化處理」「簡化測試」
 5□ 「發現問題但不處理」「架構問題先不管」「只加個 TODO」
 6□ 「智能」「自動」(無具體描述)「優化」(無具體指標)
 7
 8英文禁用詞彙掃描：
 9□ "workaround", "bypass", "hack", "quick fix"
10□ "too complex", "temporary fix", "ignore for now"
11□ "simpler approach", "simpler way", "easier approach"
12□ "simplify test", "basic test only", "minimal test"
13□ "comment out", "disable", "just add todo"

第三階段：品質標準檢查

1要求：解決方案完整性檢查
2   我的解決方案是完整的，還是妥協的？
3
4要求：根本問題檢查
5   我是否在迴避根本問題？
6
7要求：專業標準檢查
8   我的回應體現專業工程師標準嗎？
9   6個月後我會為這個回應感到驕傲嗎？

檢查失敗立即修正流程

如果任何檢查項目失敗：

 11. 立即停止
 2   停止當前回應生成，不發送任何內容
 3
 42. 重新分析
 5   深入分析問題和解決方案
 6   識別導致違規的根本原因
 7
 83. 重新構思
 9   構思完全符合三大鐵律的回應
10   確保解決方案完整且專業
11
124. 再次檢查
13   重新執行完整的 30 秒檢查流程
14   直到通過所有檢查項目才能回應

關鍵情境標準處理

測試失敗情境

觸發條件：任何測試失敗、通過率 < 100%

 1強制執行流程：
 21. 立即停止所有其他工作
 32. 啟動深度分析 agent (lavender-interface-designer)
 43. 制定並執行完整解決方案
 54. 驗證達到 100% 通過率
 65. 記錄解決過程到工作日誌
 7
 8嚴格禁止：
 9禁止：跳過失敗的測試
10禁止：認為 92% 通過率「已經很好」
11禁止：先處理其他「更重要」的工作
12禁止：採用臨時修補方案

複雜問題情境

觸發條件：問題看起來複雜、不知道解法

 1強制執行流程：
 21. 承認複雜性，但拒絕放棄
 32. 將複雜問題分解為可管理的子問題
 43. 啟動相應的專業 agent
 54. 按優先級逐一解決子問題
 65. 記錄完整過程供未來參考
 7
 8嚴格禁止：
 9禁止：認為問題「太複雜」而放棄
10禁止：尋求「權宜方案」
11禁止：跳過問題處理其他工作
12禁止：採用「暫時性」解決方案

架構問題情境

觸發條件：發現設計缺陷、技術債務、架構不一致

 1強制執行流程：
 21. 立即停止功能開發
 32. 評估影響範圍
 43. 啟動重構專家 (cinnamon-refactor-owl)
 54. 制定詳細修復計劃
 65. 徹底修正後再繼續功能開發
 7
 8嚴格禁止：
 9禁止：認為架構問題「影響不大」
10禁止：想要「之後再處理」
11禁止：繼續在有問題的架構上開發
12禁止：採用簡單修補而非根本性解決

執行標準

延後必須有記錄

每個延後決定都要：

• 記錄在工作日誌
• 標註預計處理時間
• 說明延後的理由

定期檢視累積

• Sprint 結束檢查延後項目
• 版本發布前清理技術債務
• 超過兩個版本的延後必須處理

品質底線不妥協

無論如何都不能延後的：

• 安全性：任何安全問題
• 資料完整性：可能造成資料遺失或錯誤
• 核心體驗：用戶主要使用路徑

判別範例

正例：正確的延後

1// TODO: v0.2 版本加入批次處理
2// 目前 v0.1 實作單筆處理
3function processItem(item) {
4  return processSingle(item); // 完整功能，可延後優化
5}

理由：功能完整、有明確版本規劃、不影響使用。

反例：錯誤的逃避

1// TODO: 錯誤處理太麻煩，先不做
2function riskyOperation() {
3  return doOperation(); // 缺少錯誤處理，不可接受
4}

理由：核心責任缺失、沒有時程、影響穩定性。

正例：正確的最小實現

 1class DataProcessor {
 2  process(data) {
 3    // v0.1: 同步處理
 4    return this.syncProcess(data);
 5  }
 6
 7  // 預留介面給 v0.2 非同步處理
 8  async processAsync(data) {
 9    throw new Error('v0.2 功能');
10  }
11}

理由：當前版本完整可用、為未來預留空間、有清楚邊界。

反例：錯誤的妥協

1// 測試太嚴格，先降低標準
2test.skip('應該要處理邊界情況', () => {
3  // 跳過困難的測試
4});

理由：降低品質標準、逃避問題、累積風險。

文化與態度

我們的信念

• 沒有解決不了的問題，只有還沒找到的方法
• 延後是策略，逃避是失職
• 技術債務必須管理，不是忽視

我們的承諾

• 誠實面對技術挑戰
• 為決定負責並追蹤
• 維持專案的長期健康

我們的標準

• 每個延後都有明確計劃
• 每個問題都有解決方案
• 每個決定都能說明理由

執行保障：三層防護機制完整架構

完整防護體系

為了確保這些原則被確實執行，我們建立了三層互補的防護機制：

第一層：AI 內建自檢（主要防線）

• 執行時機：每次回應前自動執行
• 檢查範圍：三大鐵律、逃避詞彙、品質標準
• 處理方式：檢查失敗立即停止回應生成，重新構思
• 特色：源頭預防，即時阻止

第二層：Hook 系統驗證（輔助驗證）

• 執行時機：用戶輸入、檔案編輯、工具使用前後
• 檢查範圍：ESLint 錯誤、技術債務、程式異味
• 處理方式：自動記錄問題、啟動 agents 處理
• 特色：持續監控，事後驗證

第三層：修復模式（最後防線）

• 觸發條件：前兩層發現違規行為或品質問題
• 處理方式：進入修復模式，完成修正後才能繼續
• 特色：強制修正，確保問題得到解決

三層協作機制

正常工作流程

1用戶輸入 → AI自檢 → 通過 → 生成回應 → Hook驗證 → 正常繼續

發現問題時

1AI自檢失敗 → 重新構思 → 再次檢查 → 通過後回應
2Hook檢測問題 → 記錄追蹤 → 必要時啟動修復模式
3修復模式 → 停止開發 → 修正問題 → 驗證完成 → 繼續開發

關鍵優勢

多重保障

• AI 自檢確保源頭品質
• Hook 系統提供持續監控
• 修復模式確保問題解決

精確判斷

• 區分計劃性延後和逃避行為
• 識別技術文檔中的範例程式碼
• 理解上下文和開發階段

自動化執行

• 無需人工干預
• 一致性執行標準
• 即時問題發現和處理

防護機制效果

這套三層防護機制確保：

• 原則被一致執行：沒有例外情況
• 問題被及時發現：多個時間點檢查
• 品質不因壓力妥協：自動化強制執行
• 逃避行為被根本預防：從思維層面攔截

結論：從根本預防逃避行為的完整方法論

這套方法論代表了我們在 AI 協作品質控制上的重大突破。我們從最初的 Hook 系統發展到現在的三層防護機制，實現了從事後修正到源頭預防的根本性轉變。

核心成就

從反應式到預防式

• 過去：Hook 系統發現問題後修正
• 現在：AI 自檢在問題產生前攔截
• 效果：逃避行為從源頭被消除

從單一防護到多層保障

• 第一層：AI 內建自檢（30秒強制檢查）
• 第二層：Hook 系統驗證（持續監控）
• 第三層：修復模式（強制修正）
• 效果：任何逃避行為都無法逃脫檢測

從人工監督到自動化執行

• 自檢機制：每次回應前自動執行
• 檢查標準：三大鐵律 + 違規詞彙 + 品質標準
• 處理流程：檢查失敗立即重新構思
• 效果：零人工干預的品質保證

方法論價值

這不只是技術工具，更是工作哲學的具體實現：

永不妥協的品質標準

• 計劃性延後是正當策略
• 逃避性拖延絕不容忍
• 100% 測試通過率是最低標準
• 架構問題必須立即修正

思維模式

• 面對複雜問題不逃避，而是分解解決
• 發現問題立即處理，不推遲到未來
• 追求根本性解決，拒絕症狀緩解
• 維持長期視角，拒絕短期妥協

可持續的開發實踐

• 技術債務得到控制
• 程式碼品質持續提升
• 團隊標準保持一致
• 專案健康度不斷改善

執行承諾

這是要求，不是建議。這是標準，不是理想

• 任何違反這些原則的行為，無論來自人類還是 AI，都會被三層防護機制檢測並要求修正
• AI 每次回應前都必須通過 30 秒自檢
• Hook 系統持續監控所有開發活動，確保品質標準
• 修復模式在發現問題時強制執行，直到問題徹底解決

這套三層防護機制目標是：

• 可信賴的 AI 協作關係
• 可持續的品質保證體系
• 可擴展的開發方法論
• 可複製的成功模式

我們將持續改進這套機制，讓它成為所有 AI 協作專案的標準基礎設施，確保每個專案都能維持最高的品質標準。

這是品質保證系統，確保 AI 協作始終維持最高執行標準，而非放任品質下滑。