AI 任務逃避偵測與預防三層防護方法論

Sat, 20 Sep 2025 00:00:00 +0000

背景與演進

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

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

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

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

三層防護機制架構

第一層：AI 內建自檢機制

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

30秒核心檢查清單

三大鐵律檢查
- 測試通過率鐵律：是否包含「測試失敗可接受」的思維？
- 永不放棄鐵律：是否想跳過、暫時處理、或延後任何問題？
- 架構債務零容忍鐵律：是否發現架構問題卻想稍後處理？
逃避詞彙檢查
- 中文禁用詞：「太複雜」「先將就」「暫時性修正」「症狀緩解」等
- 英文禁用詞：workaround, bypass, hack, quick fix 等
- 簡化妥協詞：「更簡單的方法」「簡化處理」「簡化測試」等
品質標準檢查
- 解決方案是完整的，還是妥協的？
- 是否在迴避根本問題？
- 回應是否體現專業工程師標準？

檢查失敗處理

如果任何檢查項目失敗：

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

第二層：Hook 系統驗證

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

觸發時機

UserPromptSubmit: 每次用戶輸入時檢查工作流程合規性
PostToolUse: 檔案編輯後檢查程式異味和品質
PreToolUse: 工具使用前檢查是否有阻止狀態
Stop: 回應完成後分析版本推進狀態

檢查項目

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

第三層：修復模式

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

進入條件

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

修復流程

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

完成標準

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

核心立場

我們接受的：計劃性延後

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

版本規劃的延後

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

TDD 最小實現

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

風險管理的優先級

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

我們拒絕的：逃避行為

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

模糊的拖延

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

核心責任的迴避

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

債務的累積

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

完整違規詞彙對照表

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

品質妥協和逃避責任類

中文違規詞彙	英文違規詞彙	違反原則	正確替代
「太複雜」	“too complex”, “too complicated”	永不放棄鐵律	「需要深度分析，讓我分解問題」
「先將就」	“workaround”, “hack”	永不放棄鐵律	「建立完整解決方案」
「暫時性修正」	“temporary fix”, “quick fix”	架構債務零容忍	「現在就正確實作」
「症狀緩解」	“bypass”	架構債務零容忍	「解決根本問題」
「先這樣處理」	“ignore for now”	永不放棄鐵律	「立即正確處理」
「臨時解決方案」	“will fix later”	架構債務零容忍	「永久性解決方案」

簡化妥協類

中文違規詞彙	英文違規詞彙	違反原則	正確替代
「更簡單的方法」	“simpler approach”, “simpler way”	永不放棄鐵律	「正確且完整的方法」
「採用更簡單的方法」	“take the simpler approach”	永不放棄鐵律	「採用正確的方法」
「簡化處理」	“simplify”	永不放棄鐵律	「完整處理」
「簡單的處理方式」	“simpler method”	永不放棄鐵律	「專業的處理方式」

測試品質妥協類

中文違規詞彙	英文違規詞彙	違反原則	正確替代
「簡化測試」	“simplify test”, “simplified test”	測試通過率鐵律	「建立完整測試」
「降低測試標準」	“lower test standard”	測試通過率鐵律	「維持100%測試標準」
「簡單測試就好」	“basic test only”, “simple test case”	測試通過率鐵律	「全面測試覆蓋」
「基本測試即可」	“minimal test”	測試通過率鐵律	「完整測試套件」

發現問題但不解決類

中文違規詞彙	英文違規詞彙	違反原則	正確替代
「發現問題但不處理」	“ignore the issue”	架構債務零容忍	「發現問題立即解決」
「架構問題先不管」	“architecture debt later”	架構債務零容忍	「架構問題立即修正」
「只加個 TODO」	“just add todo”	架構債務零容忍	「立即實作解決方案」
「問題太多先跳過」	“too many issues skip”	永不放棄鐵律	「逐一解決所有問題」

程式碼修改逃避類

中文違規詞彙	英文違規詞彙	違反原則	正確替代
「註解掉」	“comment out”	架構債務零容忍	「重構或移除」
「停用功能」	“disable”	架構債務零容忍	「修正後啟用」
「暫時關閉」	“temporarily disable”	架構債務零容忍	「立即修正並啟用」

模糊不精確詞彙類

中文違規詞彙	英文違規詞彙	違反原則	正確替代
「智能」	“smart”, “intelligent”	精確性原則	「規則比對」「條件判斷」「算法處理」
「自動」(無具體描述)	“auto” (without details)	精確性原則	「Hook腳本執行」「定時任務觸發」
「優化」(無具體指標)	“optimize” (without metrics)	精確性原則	「減少記憶體使用50%」「提升載入速度2倍」

處理原則

面對複雜問題

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

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

意外狀況的決策

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

立即解決的情況

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

可以延後的情況

效能優化（功能正常）→ 可計劃延後
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 協作始終維持最高執行標準，而非放任品質下滑。

工作準則 on Tarragon