AI 是怎麼「讀懂」一個 Bug 的？
整理版優先睇
Debugging Skill 將 AI 調 Bug 從「猜」變成「系統」，五步流程可靠提升
呢篇文章係由專注 AI Agent 實踐嘅「努力撞蘑菇AI」寫嘅，佢喺研究 GitHub 倉庫 h4vzz/awesome-ai-agent-skills 時，發現入面有一個 Debugging Skill，將人類工程師十幾年嘅調試經驗寫成可執行指令集。作者想解決嘅問題係：AI 默認用「模式匹配」去估報錯嘅修法，但呢種方法喺 70% 情況下唔 work，因為症狀同根因未必喺同一處。
呢個 Skill 嘅核心係一個五步工作流：復現問題、隔離故障位置、診斷根因、開發並應用修復、驗證修復同防止迴歸。最關鍵嘅設計係顯式分離「症狀」同「根因」，強制 AI 喺診斷時列舉常見根因類型逐一排查，而唔係直接跳到「修報錯行」。另外，隔離階段用二分法快速定位大型代碼庫嘅故障位置，呢個係高級工程師先用嘅技巧。
整體結論係：呢種系統化方法可以將 AI 嘅調試可靠性從「80分靠猜」變成「60分靠系統」，雖然分數低咗，但長期穩定性高好多。Skill 覆蓋唔到嘅係工程判斷（例如呢個 Bug 值唔值得而家修），嗰啲始終要靠人。呢篇文章拆解咗個 Skill 嘅設計哲學，畀咗好多具體例子同原則，對想用好 AI 調 Bug 嘅人好有啟發。
- 【結論】Debugging Skill 通過系統化五步流程（復現→隔離→診斷→修復→驗證）取代 AI 默認嘅「模式匹配」猜測，將調試可靠性從「80分靠猜」提升至「60分靠系統」嘅長期穩定模式。
- 【方法】核心設計係顯式分離「症狀」同「根因」，強制 AI 喺診斷時列舉常見根因類型（例如 null 假設錯誤、併發狀態突變、緩存過期值等）逐一排查，避免直接修報錯行。
- 【差異】隔離階段採用二分法定位大型代碼庫嘅故障位置，而非僅睇報錯行附近代碼，呢個係高級工程師與初級工程師嘅關鍵區別。
- 【啟發】Skill 中嘅 Edge Case 處理（如 Heisenbug）強調使用侵入性最低嘅工具（日誌、race detector）而非斷點，體現咗工具選型對調試結果嘅影響。
- 【可行動點】AI 應遵循「一次只改一件事」、「先復現再修復」、「最近嘅變更優先睇」等原則，並喺無法復現時追問用戶，而非直接畀出可能掩蓋症狀嘅方案。
AI默認係模式匹配，唔係真係識調 Bug
你有冇見過呢個場景：將一段報錯扔畀 AI，佢好自信咁畀個「修復方案」，改完之後跑起嚟仲係掛——只係報錯信息變咗一行。AI 唔係唔會調 Bug，而係默認模式下佢喺度猜：猜報錯信息最常見嘅修法，猜呢個變量名最有機會喺邊度出問題。
AI 默認行為係「模式匹配」，見到 NullPointerException 就直接加 null 檢查，呢個方案得 30% 情況下啱
AI 係喺度猜報錯信息最常見嘅修法，而唔係分析根因
有冇一種方式，可以令 AI 好似一個真正嘅工程師咁調 Bug——先復現，再隔離，再揾根因，最後先修？最近有人喺 GitHub 上開咗個倉庫 h4vzz/awesome-ai-agent-skills，入面有一個 Debugging Skill，將「點樣調 Bug」寫成咗一個可執行嘅指令集。呢篇文章就係拆解呢個 Skill。
五步系統流程：復現、隔離、診斷、修復、驗證
- 1 第一步：復現問題
- 2 第二步：隔離故障位置
- 3 第三步：診斷根因
- 4 第四步：開發並應用修復
- 5 第五步：驗證修復 + 防止迴歸
每一步都有輸入輸出同判斷節點。關鍵在「隔離」嗰步——Skill 寫明：「對於大型代碼庫，用二分法策略——停用一半系統，檢查 Bug 仲會唔會發生，重複直至鎖定。」
二分法定位故障係高級工程師先用嘅技巧
呢個設計決策將 AI 嘅 Debug 能力從「80分靠猜」變成「60分靠系統」，而「60分靠系統」嘅長期可靠性比「80分靠猜」高得多
量化診斷：由症狀倒推根因嘅思維
Skill 入面有一個好紮實嘅例子：Node.js 服務器內存洩漏。故障係服務器內存由 150 MB 慢慢增長到 2 GB，24 小時後 OOM 崩潰。原因係一個中間件入面嘅 requestLog 數組無限增長，每分鐘 1000 次請求，每次儲存完整 headers，一日累計 2.8 GB。
const requestLog = [];
app.use((req, res, next) => {
requestLog.push({
method: req.method,
url: req.url,
headers: { ...req.headers }, // ← 問題喺度
timestamp: new Date(),
});
next();
});修復方案係限制數組大小同停止儲存完整 headers。呢個例子嘅診斷路徑係由症狀倒推：24 小時漲到 2GB，計算每小時增長，反推數據結構規模，再去 code 揾「符合呢個增長規律嘅無界容器」——呢個係典型嘅量化優先調試思路。
量化優先嘅調試思路：由症狀倒推數據規模，再揾對應容器
對於 Heisenbug，必須用侵入性最低嘅工具，例如日誌同 tracing
一次只改一件事、先復現再修復、git bisect 嘅威力
- 「一次只改一件事」：測試假設時淨係改一個變數，否則唔會知邊個改法有效。
- 「先復現，再修復」：冇得復現嘅 Bug 唔好落修復，否則可能只係掩蓋症狀。
- 「最近嘅變更優先睇」：如果 Bug 喺某次部署或 commit 之後出現，用 git bisect 二分法好快揾到源頭。
「無法復現＝無法驗證修復有效＝修復可能係假嘅」——呢句係 Skill 畀 AI 嘅原則
git bisect 嘅二分法複雜度係 O(log n)，喺 1000 個 commit 嘅項目最快 10 次檢查就揾到問題 commit
橫向對比其他 Skill（Data Analysis、SQL Generation），會發現共同模式：將隱式嘅專家直覺顯式化——工作流 + 工具選型 + Best Practices + Edge Cases。但呢啲 Skill 覆蓋唔到「呢個 Bug 唔重要」呢類工程判斷，嗰啲始終要靠人。
Skill 嘅最終定位係技術層面嘅認知標準化，而唔係替代工程判斷
你有冇見過呢個場景：將一段報錯掟俾 AI，佢好有信心咁畀你一個「修復方案」，改完之後行起嚟依然死——只係報錯信息變咗一行。
AI 唔係唔識 Debug，而係默認模式下佢係靠估。估報錯信息入面最常見嘅修法，估呢個變數名最有機會係邊度出問題。
有冇一種方法，可以令 AI 似一個真正嘅工程師咁 Debug——先重現，再隔離，再揾根因，最後先修？
真係有。
最近我喺度研究 h4vzz/awesome-ai-agent-skills 呢個 GitHub 倉庫（截至 2026 年 5 月，該倉庫有 70+ 個 AI Agent Skill 檔案），入面有一個專門俾 AI 用嘅 Debugging Skill。睇完之後，我有啲震撼——唔係因為佢有幾高深，而係因為佢將「點樣 Debug」呢件人類工程師做咗十幾年、從來冇認真總結過嘅事，寫成咗一個可執行嘅指令集。
呢篇文章，我哋就嚟拆解佢。
呢個 Skill 解決乜嘢問題
Debugging Skill 嘅一句話定位：等 AI 按系統性流程嚟 Debug，而唔係靠直覺去估。
佢解決嘅核心矛盾係：AI 嘅知識儲備足以覆蓋絕大多數常見 Bug 嘅修法，但 AI 默認嘅行為模式係「模式匹配」——見到 NullPointerException，直接掟一個加 null 檢查嘅方案。
呢個方案喺 30% 嘅情況下係啱嘅。但另外 70% 嘅情況，NullPointerException 只係症狀，根因藏喺三個函數調用之前嘅一行數據賦值入面。
Debugging Skill 嘅設計目標就係要攞返嗰 70%。
工作流程：五步，缺一不可
呢個 Skill 俾 AI 定義咗一個嚴格嘅五步流程：
第一步：復現問題
↓
第二步：隔離故障位置
↓
第三步：診斷根因
↓
第四步：開發並應用修復
↓
第五步：驗證修復 + 防止迴歸
每一步都有輸入同輸出，都有「乜嘢情況下要停低問用戶」嘅判斷節點。
睇落同人類工程師嘅直覺差唔多？唔係，差好遠。
關鍵係喺「隔離」嗰一步。Skill 入面寫咗一句話，我覺得係成個工作流程最有價值嘅設計決策：
“For large codebases, use binary search strategies — disable half the system, check if the bug still occurs, and repeat.
二分法定位故障。呢個係人類高級工程師會用、但初級工程師唔識用嘅技巧。AI 如果冇呢條指令，面對大型代碼庫就會直接走去睇報錯行附近嘅代碼——嗰度通常只有症狀，冇根因。
最關鍵嘅設計決策：「症狀」同「根因」嘅明確分離
Debugging Skill 入面有一段我反覆睇咗好多次：
“Distinguish the root cause from its symptoms — a NullPointerException is a symptom; the root cause may be a missing validation three function calls earlier.
呢句話喺成個 Skill 入面出現唔係偶然嘅。佢係成個除錯哲學嘅核心。
AI 嘅訓練數據入面有海量嘅 Stack Overflow 帖子，呢啲帖子嘅結構幾乎都係：「我遇到 X 報錯，點修？」然後答案直接指向修掉 X 報錯嘅代碼。
呢種模式訓練出嚟嘅 AI，天然傾向於將症狀當做根因。
Debugging Skill 透過明確指令打斷呢個模式：喺「診斷根因」呢一步，AI 被要求列舉常見根因類型（null 假設錯誤、併發狀態突變、快取過期值、運算符優先級錯誤、async 調用缺少 await、依賴版本唔兼容），並對照當前 Bug 逐個排查，而唔係直接跳到「修報錯行」。
呢一個設計決策，將 AI 嘅 Debug 能力由「80分靠估」變成咗「60分靠系統」——而「60分靠系統」嘅長期可靠性，比「80分靠估」高好多。
最值得記住嘅 Edge Case：Heisenbug
Skill 入面專門有一節叫 Edge Cases，入面有個詞一出嚟，做過併發開發嘅人應該都會會心一笑：Heisenbug。
Heisenbug，直譯「海森堡 Bug」，係指：你喺度觀測佢嘅時候，佢消失咗。
具體表現係：加咗斷點之後 Bug 重現唔到，一取消斷點又出返嚟。
點解會咁？因為斷點改變咗程式執行嘅時序。競態條件（race condition）對時序極度敏感，斷點引入嘅暫停啱好將兩個執行緒嘅執行順序調整到「安全」狀態。
Debugging Skill 對 Heisenbug 嘅處理方案：
“For these, use logging or tracing instead of interactive debuggers, and consider running with the language's race detector if available.
用日誌代替斷點，用語言內置嘅 race detector（例如 Go 嘅 -race 標誌）嚟檢測。
呢個建議嘅背後有一個好重要嘅洞察：唔同嘅除錯工具對 Bug 嘅侵入性唔同，侵入性越高，改變程式行為嘅風險越大。對於 Heisenbug，必須用侵入性最低嘅工具。
案例拆解：一個記憶體洩漏嘅完整診斷
Skill 入面有一個我覺得寫得好紮實嘅例子——Node.js 伺服器記憶體洩漏。
故障描述：伺服器記憶體由 150 MB 緩慢增長到 2 GB，約 24 小時後 OOM 崩潰。
呢種 Bug 最難搞。佢唔報錯，唔拋異常，只係靜靜地食記憶體，直到撐死。
原因出喺一個中介軟體上：
const requestLog = [];
app.use((req, res, next) => {
requestLog.push({
method: req.method,
url: req.url,
headers: { ...req.headers }, // ← 問題在這裏
timestamp: new Date(),
});
next();
});
requestLog 係一個模塊級變數，永遠唔清理。每個請求追加一個物件，物件入面仲包含咗完整嘅請求頭（headers: { ...req.headers }）。
Skill 入面俾咗一個量化嘅計算：每分鐘 1000 次請求，平均 header 大小 2KB，一日累計 2.8 GB。同報告嘅症狀完全吻合。
修復方案：
const MAX_LOG_SIZE = 10000;
const requestLog = [];
app.use((req, res, next) => {
if (requestLog.length >= MAX_LOG_SIZE) {
requestLog.shift(); // 淘汰最舊的一條
}
requestLog.push({
method: req.method,
url: req.url,
timestamp: newDate(),
// headers 不再存儲
});
next();
});
兩處修改：一係限制陣列大小，二係停止儲存完整 headers。
呢個例子令我印象深刻嘅地方係佢嘅診斷路徑——唔係由代碼開始睇，而係由症狀倒推：24 小時漲到 2GB，就計每小時大概增長幾多，再反推可能嘅數據結構規模，再去代碼入面揾「符合呢個增長規律嘅無界容器」。呢個係典型嘅量化優先嘅除錯思路，而唔係憑感覺揾代碼。
三個我覺得「本可以唔寫，但寫咗更好」嘅細節
1. 「一次只改一件事」
Skill 嘅 Best Practices 入面有呢一條：
“When testing a hypothesis, make a single modification and re-run. Changing multiple things simultaneously makes it impossible to determine which change had the effect.
呢個係科學實驗嘅基本原則，但喺 Debug 時經常被違反——尤其係喺壓力下，工程師往往傾向於「將所有睇落有問題嘅地方都改一改」。結果改好咗又唔知邊個改法起作用，下次遇到類似問題都係唔識。
AI 如果冇呢個約束，都會有同樣嘅傾向：將 5 個「可能有關」嘅地方一齊改曬，然後畀你一個「應該好返」嘅方案。
2. 「先重現，再修復」
“Never apply a fix to a bug you cannot reproduce. Without reproduction, you cannot verify the fix works, and you risk introducing a change that masks the symptom without addressing the cause.
呢句話係話俾 AI 聽：如果用戶俾嘅資訊唔夠重現 Bug，就要追問，而唔係直接畀修復方案。
呢個設計決策背後嘅邏輯好清晰：無法重現 = 無法驗證修復有效 = 修復可能係假嘅。能夠「掩蓋症狀但唔解決根因」嘅修復，仲衰過冇修復。
3. 「最近嘅變更優先睇」
“If the bug appeared after a specific deployment or commit,
git bisector reviewing the recent diff is often the fastest path to the root cause.
git bisect 係一個被嚴重低估嘅工具。佢用二分法喺提交歷史入面快速定位「第一個引入 Bug 嘅 commit」，理論複雜度係 O(log n)。一個有 1000 個提交歷史嘅項目，最多 10 次檢查就揾到。
Skill 將呢個工具明確寫入嚟，說明作者想將「時序定位」納入 AI 嘅工具箱——而唔只係「代碼邏輯分析」。
橫向睇：Debugging 同數據分析 Skill 有乜共同模式？
睇完呢個 Skill，我將佢同之前拆解過嘅 Data Analysis、SQL Generation 等幾個 Skill 放埋一齊對比，發現一個有意思嘅共同點：
呢啲 Skill 都係做緊同一件事——將「隱含嘅專家直覺」明確化。
Data Cleaning 嘅 Skill 話「先生成質量報告，再按列策略處理缺失值」——呢個係數據工程師做咗幾年先會有嘅直覺，Skill 將佢寫成可執行步驟。
SQL Generation 嘅 Skill 話「BETWEEN 日期會漏咗最後一日 23:59:59 之後嘅數據，要用 >= 和 < 代替」——呢個係踩過坑先知道嘅邊界行為，Skill 將佢寫成注意事項。
Debugging Skill 話「NullPointerException 係症狀，根因可能喺三個函數調用之前」——呢個係做過大型項目嘅工程師先有嘅除錯哲學，Skill 將佢寫成診斷前嘅強制提示。
呢啲 Skill 嘅共同結構係：工作流程 + 工具選擇 + Best Practices + Edge Cases。工作流程保證 AI 唔跳步，Best Practices 注入專家經驗，Edge Cases 避免常見陷阱。
呢啲 Skill 覆蓋唔到嘅，係乜嘢？
睇呢啲 Skill 嘅時候，我不斷諗一個問題：佢哋覆蓋唔到嘅係乜嘢？
我覺得有一類嘢，係任何 Skill 都寫唔入去嘅：「呢個 Bug 唔重要」。
一個有經驗嘅工程師面對一個 Bug 時，會喺 5 秒內判斷佢值唔值得依家修——用戶量級、觸發頻率、修復成本、潛在風險，呢啲權衡係完全情境化嘅，依賴於對產品、業務、團隊狀態嘅整體感知。
Debugging Skill 可以話俾 AI 聽點樣揾根因，但揾到根因之後要唔要修、即刻修定排期修，呢個判斷 Skill 俾唔到——因為呢個唔係技術問題，而係工程判斷問題。
所以呢啲 Skill 最終嘅定位，其實好清晰：佢哋係喺做技術層面嘅認知標準化，而唔係取代工程判斷。前者可以系統化，後者唔得。
可以被系統化嘅部分，交俾 Skill。唔可以被系統化嘅部分，始終要靠你自己。
你有沒有見過這種場景：把一段報錯扔給 AI，它非常自信地給你一個"修復方案"，改完之後跑起來還是掛——只是報錯信息變了一行。
AI 不是不會調 Bug，而是默認模式下它在猜。猜報錯信息裏最常見的修法，猜這個變量名最有可能是哪裏出了問題。
有沒有一種方式，能讓 AI 像一個真正的工程師一樣調 Bug——先復現，再隔離，再找根因，最後修？
還真有。
最近我在研究 h4vzz/awesome-ai-agent-skills 這個 GitHub 倉庫（截至 2026 年 5 月，該倉庫有 70+ 個 AI Agent Skill 文件），裏面有一個專門給 AI 用的 Debugging Skill。讀完之後，我有點震動——不是因為它有多高深，而是因為它把「怎麼調 Bug」這件人類工程師做了十幾年、從沒認真總結過的事，寫成了一個可執行的指令集。
這篇文章，我們就來拆它。
這個 Skill 解決什麼問題
Debugging Skill 的一句話定位：讓 AI 按系統性流程調 Bug，而不是憑直覺猜。
它解決的核心矛盾是：AI 的知識儲備足以覆蓋絕大多數常見 Bug 的修法，但 AI 默認的行為模式是"模式匹配"——看到 NullPointerException，直接甩一個加 null 檢查的方案。
這個方案在 30% 的情況下是對的。但另外 70% 的情況，NullPointerException 只是症狀，根因藏在三個函數調用之前的一行數據賦值裏。
Debugging Skill 的設計目標就是把那 70% 找回來。
工作流：五步，缺一不可
這個 Skill 給 AI 定義了一個嚴格的五步流程：
第一步：復現問題
↓
第二步：隔離故障位置
↓
第三步：診斷根因
↓
第四步：開發並應用修復
↓
第五步：驗證修復 + 防止迴歸
每一步都有輸入和輸出，都有「什麼情況下停下來問用戶」的判斷節點。
看起來和人類工程師的直覺差不多？不，差很多。
關鍵在「隔離」那步。Skill 裏寫了一句話，我覺得是整個工作流最有價值的設計決策：
“For large codebases, use binary search strategies — disable half the system, check if the bug still occurs, and repeat.
二分法定位故障。這是一個人類高級工程師會用、但初級工程師不會用的技巧。AI 如果沒有這條指令，面對大型代碼庫會直接跑去看報錯行附近的代碼——那裏通常只有症狀，沒有根因。
最關鍵的設計決策：「症狀」和「根因」的顯式分離
Debugging Skill 裏有一段我反覆讀了好幾遍：
“Distinguish the root cause from its symptoms — a NullPointerException is a symptom; the root cause may be a missing validation three function calls earlier.
這句話在整個 Skill 裏出現不是偶然的。它是整個調試哲學的核心。
AI 的訓練數據裏有海量的 Stack Overflow 帖子，這些帖子的結構幾乎都是：「我遇到了 X 報錯，怎麼修？」然後答案直接指向修掉 X 報錯的代碼。
這種模式訓練出來的 AI，天然傾向於把症狀當根因。
Debugging Skill 通過顯式指令打斷這個模式：在「診斷根因」這步，AI 被要求列舉常見根因類型（null 假設錯誤、併發狀態突變、緩存過期值、運算符優先級錯誤、async 調用缺少 await、依賴版本不兼容），並對照當前 Bug 逐一排查，而不是直接跳到「修報錯行」。
這一個設計決策，把 AI 的 Debug 能力從「80分靠猜」變成了「60分靠系統」——而「60分靠系統」的長期可靠性，比「80分靠猜」高得多。
最值得記住的 Edge Case：Heisenbug
Skill 裏專門有一節叫 Edge Cases，裏面有個詞一出來，做過併發開發的人應該都會會心一笑：Heisenbug。
Heisenbug，直譯「海森堡 Bug」，指的是：你在觀測它的時候，它消失了。
具體表現是：加了斷點之後 Bug 復現不了，一去掉斷點又出來了。
為什麼會這樣？因為斷點改變了程序執行的時序。競態條件（race condition）對時序極度敏感，斷點引入的暫停恰好把兩個線程的執行順序調整到了「安全」狀態。
Debugging Skill 對 Heisenbug 的處理方案：
“For these, use logging or tracing instead of interactive debuggers, and consider running with the language's race detector if available.
用日誌代替斷點，用語言內置的 race detector（比如 Go 的 -race 標誌）來檢測。
這個建議的背後有一個很重要的洞察：不同的調試工具對 Bug 的侵入性不同，侵入性越高，改變程序行為的風險越大。對於 Heisenbug，必須用侵入性最低的工具。
案例拆解：一個內存泄漏的完整診斷
Skill 裏有一個我覺得寫得非常紮實的例子——Node.js 服務器內存泄漏。
故障描述：服務器內存從 150 MB 緩慢增長到 2 GB，約 24 小時後 OOM 崩潰。
這種 Bug 最難調。它不報錯，不拋異常，只是悄悄地在吃內存，直到撐死。
原因出在一箇中間件上：
const requestLog = [];
app.use((req, res, next) => {
requestLog.push({
method: req.method,
url: req.url,
headers: { ...req.headers }, // ← 問題在這裏
timestamp: new Date(),
});
next();
});
requestLog 是一個模塊級變量，永不清理。每個請求追加一個對象，對象裏還包含了完整的請求頭（headers: { ...req.headers }）。
Skill 裏給出了一個量化的計算：每分鐘 1000 次請求，平均 header 大小 2KB，一天累計 2.8 GB。和報告的症狀完全吻合。
修復方案：
const MAX_LOG_SIZE = 10000;
const requestLog = [];
app.use((req, res, next) => {
if (requestLog.length >= MAX_LOG_SIZE) {
requestLog.shift(); // 淘汰最舊的一條
}
requestLog.push({
method: req.method,
url: req.url,
timestamp: newDate(),
// headers 不再存儲
});
next();
});
兩處修改：一是限制數組大小，二是停止存儲完整 headers。
這個例子讓我印象深刻的地方是它的診斷路徑——不是從代碼開始讀，而是從症狀倒推：24 小時漲到 2GB，那就計算每小時大概增長多少，再反推可能的數據結構規模，再去代碼裏找「符合這個增長規律的無界容器」。這是一個典型的量化優先的調試思路，而不是憑感覺找代碼。
三個讓我覺得「本可以不寫，但寫了更好」的細節
1. 「一次只改一件事」
Skill 的 Best Practices 裏有這一條：
“When testing a hypothesis, make a single modification and re-run. Changing multiple things simultaneously makes it impossible to determine which change had the effect.
這是科學實驗的基本原則，但在調 Bug 時經常被違反——尤其是在壓力下，工程師往往傾向於「把所有看起來有問題的地方都改一下」。結果改好了也不知道是哪個改法起了作用，下次遇到類似問題還是不會。
AI 如果不受這個約束，會有同樣的傾向：把 5 個「可能有關」的地方一起改掉，給你返回一個「應該好了」的方案。
2. 「先復現，再修復」
“Never apply a fix to a bug you cannot reproduce. Without reproduction, you cannot verify the fix works, and you risk introducing a change that masks the symptom without addressing the cause.
這句話是在告訴 AI：如果用戶給的信息不夠復現 Bug，要先追問，而不是直接給修復方案。
這個設計決策背後的邏輯非常清晰：無法復現 = 無法驗證修復有效 = 修復可能是假的。能「掩蓋症狀而不解決根因」的修復，比沒有修復更危險。
3. 「最近的變更優先看」
“If the bug appeared after a specific deployment or commit,
git bisector reviewing the recent diff is often the fastest path to the root cause.
git bisect 是一個被嚴重低估的工具。它用二分法在提交歷史裏快速定位「第一個引入 Bug 的 commit」，理論複雜度是 O(log n)。一個有 1000 個提交歷史的項目，最多 10 次檢查就能找到。
Skill 把這個工具顯式寫進來，說明作者想把「時序定位」納入 AI 的工具箱——而不只是「代碼邏輯分析」。
橫向看：Debugging 和數據分析 Skill 有什麼共同模式？
讀完這個 Skill，我把它和之前拆解過的 Data Analysis、SQL Generation 等幾個 Skill 放在一起對比，發現一個有意思的共同點：
這些 Skill 都在做同一件事——把「隱式的專家直覺」顯式化。
Data Cleaning 的 Skill 說「先生成質量報告，再按列策略處理缺失值」——這是數據工程師做了幾年才會有的直覺，Skill 把它寫成了可執行步驟。
SQL Generation 的 Skill 說「BETWEEN 日期會把最後一天的 23:59:59 之後的數據漏掉，要用 >= 和 < 替代」——這是踩過坑才知道的邊界行為，Skill 把它寫成了注意事項。
Debugging Skill 說「NullPointerException 是症狀，根因可能在三個函數調用之前」——這是做過大型項目的工程師才有的調試哲學，Skill 把它寫成了診斷前的強制提示。
這些 Skill 的共同結構是：工作流 + 工具選型 + Best Practices + Edge Cases。工作流保證 AI 不跳步，Best Practices 注入專家經驗，Edge Cases 避免常見陷阱。
這些 Skill 覆蓋不到的，是什麼？
讀這些 Skill 的時候，我一直在想一個問題：它們覆蓋不到的是什麼？
我覺得有一類東西，是任何 Skill 都寫不進去的：「這個 Bug 不重要」。
一個有經驗的工程師在面對一個 Bug 時，會在 5 秒內判斷它是否值得現在修——用戶量級、觸發頻率、修復成本、潛在風險，這些權衡是完全情境化的，依賴於對產品、業務、團隊狀態的整體感知。
Debugging Skill 可以告訴 AI 怎麼找根因，但找到根因之後要不要修、現在修還是排期修，這個判斷 Skill 給不了——因為這不是一個技術問題，是一個工程判斷問題。
所以這些 Skill 最終的定位，其實很清晰：它們是在做技術層面的認知標準化，而不是在替代工程判斷。前者可以系統化，後者不行。
能被系統化的部分，交給 Skill。不能被系統化的部分，還是得靠你。