我之前做了很多規範去強迫或者限制AI執行的時候需要記住所有的判斷原則，但是實際執行狀況並不理想，生成式AI的問題就是每次生成的內容都是不穩定的，那後來我改變了想法，先使用 hook 禁止 主線程(我跟AI的對話視窗)編輯工作日誌以外的資料夾 ，然後要求主線程必須依照我設計的決策樹去分派任務，但是就算把規則這樣寫了，也不能保證AI真的都會依照決策樹執行，所以進一步再加入一個 hook ，我要求分派任務的時候一定要有 ticket ，否則代理人會拒絕執行，而 建立 ticket 的方式，是必須依照 ticket 範本去建立 ticket ，範本中有一個欄位強制需要填入決策樹的思考過程，所以能夠保證在生成 ticket 的時候，會做一輪決策樹的思考。

所以這個文件就是完整的決策樹設計內容，文件末端有附上 完整流程圖

決策流程總覽（二元樹結構）

 1接收訊息
 2    |
 3    v
 4[第零層] 明確性檢查
 5    |
 6    +-- 包含明確錯誤關鍵字? ─是→ [第六層] 事件回應流程
 7    |
 8    +─── 否 → 包含不確定性詞彙? ─是→ [確認機制]
 9    |                            |
10    |                            └─否→ 複雜需求? ─是→ [確認機制]
11    |                                      |
12    |                                      └─否→ [第一層]

第零層後的流程：

• 錯誤優先：直接進入第六層（事件回應流程）
• 不確定性詞彙：確認後進入第一層
• 複雜需求：確認後進入第一層
• 明確內容：進入第一層

第零層：明確性檢查

核心原則：當定義不明確時，應該往上詢問確認，而非強行做出判斷。

觸發確認機制的情境

不確定性詞彙清單

確認流程

 1接收訊息
 2    |
 3    v
 4[第零層] 明確性檢查
 5    |
 6    +-- 包含明確錯誤關鍵字（test failed, crash, error）?
 7    |   +-- 是 --> 直接進入錯誤流程（不需確認）
 8    |
 9    +-- 包含不確定性詞彙?
10    |   +-- 是 --> [確認機制] 向用戶確認問題性質
11    |
12    +-- 複雜需求（觸發 3+ 代理人）?
13    |   +-- 是 --> [確認機制] 向用戶確認 use case
14    |
15    +-- 明確 --> 繼續第一層判斷

確認問題模板

不確定性詞彙確認：

1您提到「{問題描述}」，請確認：
21. 這是一個需要修復的錯誤嗎？
32. 還是您想諮詢/了解如何處理？

複雜需求確認：

1這個需求涉及多個面向（{面向列表}），請確認：
21. 主要目標是什麼？
32. 有沒有優先級順序？
43. 是否有相關的 use case 或規格文件？

第一層：訊息類型判斷

1[第零層完成]
2    |
3    v
4是問題? ─是→ [第二層] 問題處理流程
5       |
6       └─否→ [第三層] 命令處理流程

訊息類型判斷規則

第二層：問題處理流程

1是問題
2    |
3    v
4是查詢類問題? ─是→ 執行查詢命令
5             |
6             └─否→ 派發對應諮詢代理人

查詢類問題判斷

諮詢類問題派發

第三層：命令處理流程

1是命令
2    |
3    v
4是開發/修改命令? ─是→ [Level 2] Hook 系統驗證 Ticket
5               |
6               └─否→ 是除錯命令? ─是→ [強制] 派發 incident-responder
7                                |
8                                └─否→ 其他命令類型 (ignore)

Level 2 驗證：Ticket 存在檢查

何時驗證：接收開發/修改命令後立即執行 誰負責：Hook 系統（command-entrance-gate-hook.py）

1是開發/修改命令
2    |
3    v
4有對應 Ticket? ─是→ Ticket 已認領? ─是→ 涉及安全相關? ...
5             |                    |
6             |                    └─否→ [Ticket 執行流程]
7             |
8             └─否→ [警告] 建議執行 /ticket-create
9                 (用戶決策：繼續或修正)

開發/修改命令

 1開發/修改命令（已通過 Level 2 驗證）
 2    |
 3    +-- 涉及安全相關?（認證/授權/API/敏感資料）
 4    |   +-- 是 --> [強制] 派發 security-reviewer
 5    |
 6    +-- 有對應 Ticket?
 7    |   +-- 是 --> /ticket-track query {id}
 8    |   |         --> 進入 [Ticket 執行流程]
 9    |   |
10    |   +-- 否 --> 是新功能需求?
11    |              +-- 是 --> /ticket-create → SA 前置審查
12    |              +-- 否（小型修改）--> /ticket-create → TDD 流程

說明：

• Level 2 驗證是非阻塞式的警告機制（不會強制停止執行）
• 用戶可選擇忽略警告繼續執行，但應遵循建議操作
• 驗證檢查點詳見：command-entrance-gate-hook.py

安全相關命令（強制規則）

除錯命令（強制規則）

強制動作：除錯命令 → [強制] 派發 incident-responder

禁止行為（與 Level 2 驗證關係）

禁止違反 Level 2 驗證結果：

警告類型（由 Hook 輸出）：

• 「未找到待處理 Ticket」：建議執行 /ticket-create
• 「Ticket 尚未認領」：建議執行 /ticket-track claim {id}

第四層：Ticket 執行流程

 1[Ticket 驗證通過]
 2    |
 3    v
 4Ticket 是 pending? ─是→ 執行 /ticket-track claim {id}
 5               |      └→ [階段判斷]
 6               |
 7               └─否→ Ticket 是 in_progress? ─是→ 繼續執行 [階段判斷]
 8                                          |
 9                                          └─否→ Ticket 是 completed? ─是→ 詢問後續任務
10                                                                    |
11                                                                    └─否→ (blocked) 升級 PM

Ticket 狀態對應動作

第四層半：並行派發判斷

詳細規則：parallel-dispatch

並行派發觸發條件

並行安全檢查清單

1- [ ] 檔案無重疊：各任務修改的檔案集合無交集
2- [ ] 測試無衝突：各任務的測試可獨立執行
3- [ ] 依賴無循環：任務之間無先後依賴關係
4- [ ] 資源無競爭：不會同時存取相同外部資源

第五層：TDD 階段判斷

1[Ticket 認領並執行]
2    |
3    v
4需要 SA 前置審查? ─是→ [派發] system-analyst
5               |     └→ (SA 審查通過) [進入 Phase 1]
6               |
7               └─否→ [TDD 階段派發]

TDD 階段派發

第六層：事件回應流程（錯誤分類決策樹）

詳細流程：incident-response

二元化錯誤分類樹

 1[錯誤發生] --> /pre-fix-eval --> 派發 incident-responder
 2                |
 3                v
 4           是編譯錯誤? ─是→ 依賴問題? ─是→ [Ticket] --> system-engineer
 5                     |              |
 6                     |              └─否→ [Ticket] --> parsley-flutter-developer
 7                     |
 8                     └─否→ 是測試失敗? ─是→ 測試本身問題? ─是→ [Ticket] --> sage-test-architect
 9                                   |                    |
10                                   |                    └─否→ 設計邏輯錯誤? ─是→ [Ticket] --> system-analyst
11                                   |                                       |
12                                   |                                       └─否→ [Ticket] --> parsley-flutter-developer
13                                   |
14                                   └─否→ 是執行時錯誤? ─是→ 環境問題? ─是→ [Ticket] --> system-engineer
15                                                      |              |
16                                                      |              └─否→ 資料問題? ─是→ [Ticket] --> data-administrator
17                                                      |                               |
18                                                      |                               └─否→ [Ticket] --> parsley-flutter-developer
19                                                      |
20                                                      └─否→ 是效能問題? ─是→ [Ticket] --> ginger-performance-tuner
21                                                                       |
22                                                                       └─否→ [Ticket] --> security-reviewer

錯誤類型派發表

第七層：完成判斷流程

 1[階段/Ticket 完成]
 2    |
 3    v
 4有技術債務記錄? ─是→ 執行 /tech-debt-capture
 5             |     └→ 建立技術債務 Ticket
 6             |
 7             └─否→ 涉及規則變更? ─是→ 檢查 SKILL/方法論同步
 8                              |     └→ 更新相關引用和內容
 9                              |
10                              └─否→ 需記錄學習經驗? ─是→ [派發] memory-network-builder
11                                                  |
12                                                  └─否→ 有後續階段? ─是→ 更新 worklog 進入下一個 Ticket
13                                                               |
14                                                               └─否→ 版本所有 Ticket 完成? ─是→ /version-release check
15                                                                                       |
16                                                                                       └─否→ 等待其他 Ticket 完成

完成判斷規則

規則變更同步檢查

當修改了 .claude/rules/ 下的規則檔案時，必須檢查以下相關文件是否需要同步更新：

同步檢查命令：

1# 搜尋引用了特定規則檔案的文件
2grep -r "rules/{changed-file}" .claude/

代理人觸發優先級

詳細定義：agents/overview

優先級順序

注意：以下優先級適用於代理人派發決策。此外還有 Level 2 驗證 在命令入口執行。

 1Level 2: Hook 系統驗證 - 命令入口檢查點
 2    |
 3    +-- Ticket 存在？
 4    +-- Ticket 已認領？
 5
 6Level 1: incident-responder（錯誤/失敗最高優先）
 7Level 2 (代理人): system-analyst（架構審查）
 8Level 3: security-reviewer（安全審查）
 9Level 4: 其他專業代理人（DBA, SE, SD, ginger 等）
10Level 5: TDD 階段代理人（lavender, sage, pepper, parsley, cinnamon）

Level 2 驗證特性：

• 觸發時機：接收開發命令後立即執行（比任何代理人派發都早）
• 驗證責任：Hook 系統完全自動化
• 特性：非阻塞式警告（不會強制停止）

多條件觸發處理規則

任務拆分認知負擔檢查

詳細指南：task-splitting

拆分觸發條件

任一條件符合即需拆分：

複雜度快速評估

派發記錄要求

Ticket 決策樹欄位（必填）

所有 Ticket 必須包含 decision_tree_path 欄位，記錄從進入決策樹到最終決策的完整路徑。

欄位格式：

1decision_tree_path:
2  entry_point: "{進入層級}"           # 第零層~第七層
3  decision_nodes:                      # 經過的決策節點
4    - layer: "{層級}"
5      question: "{決策問題}"
6      answer: "{答案}"
7      next_action: "{下一步}"
8  final_decision: "{最終決策}"         # 派發的代理人或執行的動作
9  rationale: "{決策理由}"              # 簡述決策原因

驗證機制

• 建立時：Ticket 建立工具自動要求填寫
• 派發時：Hook 系統驗證決策樹欄位存在
• 無效 Ticket：缺少決策樹欄位的 Ticket 無法用於派發

為何需要決策樹欄位？

命令快速參考

Ticket 管理命令

決策和評估命令

版本管理命令

其他常用命令

強制執行命令

以下命令在特定情境下必須執行，不可跳過：

違規處理

主線程違規行為

相關文件

代理人定義

• agents/overview - 代理人總覽

執行流程

• flows/tdd-flow - TDD 流程
• flows/incident-response - 事件回應流程
• flows/ticket-lifecycle - Ticket 生命週期

操作指南

• guides/task-splitting - 任務拆分指南
• guides/parallel-dispatch - 並行派發指南

Hook 系統

• Hook 實作：.claude/hooks/command-entrance-gate-hook.py - Level 2 驗證檢查點實作
• Hook 日誌：.claude/hook-logs/command-entrance-gate/ - 驗證檢查日誌

禁止行為

• forbidden/skip-gate - Skip-gate 防護

Last Updated: 2026-01-28 Version: 3.1.0

Change Log:

• v3.1.0 (2026-01-28): 新增規則變更同步檢查
  • 第七層新增「規則變更同步」判斷節點
  • 當修改 .claude/rules/ 時，強制檢查 SKILL 和方法論是否需要同步
  • 更新 Mermaid 圖表反映新判斷節點
• v3.0.0 (2026-01-28): 完整二元化決策樹結構
  • 將所有決策節點改為嚴格的二元樹結構（只有是/否兩個分支）
  • 重構第零層：3 個連續是/否判斷（錯誤關鍵字→不確定性詞彙→複雜需求）
  • 重構第一層：單一判斷（是問題 vs 是命令）
  • 重構第二層：單一判斷（查詢類 vs 諮詢類）
  • 重構第三層：連續 2 個判斷（開發命令→除錯命令）
  • 重構第四層：連續 3 個判斷（pending→in_progress→completed）
  • 新增第五層：TDD 階段判斷（SA 前置審查 vs 直接進入 TDD）
  • 重構第六層：完整二元化錯誤分類樹（編譯→測試→執行時→效能→安全）
  • 重構第七層：連續 4 個判斷（技術債務→學習經驗→後續階段→版本完成）
  • 移除所有多分支節點，實現純二元樹結構
• v2.2.0 (2026-01-27): 新增派發記錄要求章節，引入決策樹欄位強制紀錄
• v2.1.0 (2026-01-23): 新增 Level 2 驗證檢查點明確化，填補缺口 3
• v2.0.0 (2026-01-23): 重構為核心決策樹，合併 command-mapping

附錄：二元決策樹圖表

主流程圖（第零層至第七層）

flowchart TD
    START[接收訊息] --> L0_ERR{包含錯誤關鍵字?}

    %% 第零層
    L0_ERR -->|是| L6[第六層:事件回應]
    L0_ERR -->|否| L0_UNC{包含不確定性詞彙?}
    L0_UNC -->|是| CONFIRM[確認機制]
    L0_UNC -->|否| L0_CMP{複雜需求?}
    L0_CMP -->|是| CONFIRM
    L0_CMP -->|否| L1
    CONFIRM --> L1

    %% 第一層
    L1{是問題?}
    L1 -->|是| L2[第二層:問題處理]
    L1 -->|否| L3[第三層:命令處理]

    %% 第二層
    L2 --> L2_Q{是查詢類?}
    L2_Q -->|是| QUERY[執行查詢命令]
    L2_Q -->|否| CONSULT[派發諮詢代理人]

    %% 第三層
    L3 --> L3_DEV{是開發命令?}
    L3_DEV -->|是| L3_TKT{有對應 Ticket?}
    L3_DEV -->|否| L3_DBG{是除錯命令?}
    L3_DBG -->|是| INCIDENT[派發 incident-responder]
    L3_DBG -->|否| OTHER[其他命令]

    L3_TKT -->|是| L3_CLAIM{已認領?}
    L3_TKT -->|否| WARN1["警告: ticket-create"]
    L3_CLAIM -->|是| L4[第四層:Ticket執行]
    L3_CLAIM -->|否| WARN2["警告: ticket-track claim"]

    %% 第四層
    L4 --> L4_P{pending?}
    L4_P -->|是| CLAIM[claim 後執行]
    L4_P -->|否| L4_IP{in_progress?}
    L4_IP -->|是| L5[第五層:TDD階段]
    L4_IP -->|否| L4_C{completed?}
    L4_C -->|是| ASK[詢問後續]
    L4_C -->|否| ESCALATE[blocked→升級PM]
    CLAIM --> L5

    %% 第五層
    L5 --> L5_SA{需SA審查?}
    L5_SA -->|是| SA[system-analyst]
    L5_SA -->|否| TDD[TDD階段派發]
    SA --> TDD

    %% 第七層（完成判斷）
    TDD --> L7[第七層:完成判斷]
    L7 --> L7_TD{技術債務?}
    L7_TD -->|是| TECHDEBT["tech-debt-capture"]
    L7_TD -->|否| L7_RULE{規則變更?}
    L7_RULE -->|是| SYNC[檢查SKILL/方法論同步]
    L7_RULE -->|否| L7_LEARN{學習經驗?}
    SYNC --> L7_LEARN
    L7_LEARN -->|是| MNB[memory-network-builder]
    L7_LEARN -->|否| L7_NEXT{後續階段?}
    L7_NEXT -->|是| NEXT[下一個Ticket]
    L7_NEXT -->|否| L7_VER{版本完成?}
    L7_VER -->|是| RELEASE["version-release"]
    L7_VER -->|否| WAIT[等待其他Ticket]

第六層：錯誤分類決策樹

flowchart TD
    L6[錯誤發生] --> PREFIX["pre-fix-eval"]
    PREFIX --> IR[incident-responder分析]

    IR --> E1{編譯錯誤?}
    E1 -->|是| E1A{依賴問題?}
    E1A -->|是| SE1[system-engineer]
    E1A -->|否| PARSLEY1[parsley-flutter-developer]

    E1 -->|否| E2{測試失敗?}
    E2 -->|是| E2A{測試本身問題?}
    E2A -->|是| SAGE[sage-test-architect]
    E2A -->|否| E2B{設計邏輯錯誤?}
    E2B -->|是| SA[system-analyst]
    E2B -->|否| PARSLEY2[parsley-flutter-developer]

    E2 -->|否| E3{執行時錯誤?}
    E3 -->|是| E3A{環境問題?}
    E3A -->|是| SE2[system-engineer]
    E3A -->|否| E3B{資料問題?}
    E3B -->|是| DBA[data-administrator]
    E3B -->|否| PARSLEY3[parsley-flutter-developer]

    E3 -->|否| E4{效能問題?}
    E4 -->|是| GINGER[ginger-performance-tuner]
    E4 -->|否| SECURITY[security-reviewer]

TDD 階段流程

flowchart LR
    SA[SA審查] --> P1[Phase 1<br/>lavender]
    P1 --> P2[Phase 2<br/>sage]
    P2 --> P3A[Phase 3a<br/>pepper]
    P3A --> P3B[Phase 3b<br/>parsley]
    P3B --> P4[Phase 4<br/>cinnamon]
    P4 --> DONE[完成判斷]

在與 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 協作始終維持最高執行標準，而非放任品質下滑。