事後才意識到：我們只從一個角度看了問題。

那次之後，我們建立了多視角並行分析的做法：讓不同專業背景的人同時從各自角度切入同一個問題，再由一位彙整者把所有觀點整合成有交叉驗證的報告。

單一視角為什麼會出問題

一個測試失敗，可能同時反映程式碼邏輯的缺陷、測試設計的問題、以及更深的架構缺口。只派一位程式碼專家，他看到邏輯層面的問題，但不一定注意到測試覆蓋的盲區，更不會意識到架構依賴已經出問題。

這不是能力問題，是視角問題。每位分析者都受限於自己的訓練和關注焦點，對其他層面視而不見。

序列分析還有另一個陷阱：讓 A 先分析完，再讓 B 根據 A 的結論往下看，B 的起點已經帶著 A 的偏見，傾向驗證而非獨立重看問題。這是確認偏誤的具體展現。

核心做法：並行、獨立、再彙整

三個關鍵詞：

並行不只省時間，更重要的是確保各視角不互相污染。A 先告訴 B 他的發現，B 就已經不夠獨立了。

獨立意味著每位分析者在看自己的角度前，不知道其他人的結論。分析分歧不是問題，分歧本身就是資訊。架構視角認為問題在模組耦合，程式碼視角認為在邏輯判斷，兩個看法都值得記錄，讓彙整者處理。

彙整是最需要判斷力的環節。好的彙整是找出各視角的共識和衝突，對共識提高信心，對衝突做分析和決策。

什麼時候值得啟用

不是所有問題都需要這套流程，明顯的拼字錯誤或單點問題不值得投入多位分析者。

以下三種情況值得啟用：

• 複雜度高：需要同時追蹤的概念、模組、依賴超過五到七個，單一視角很難把全貌看清楚
• 風險高：影響認證授權、資料完整性，或修錯代價大，多視角交叉驗證是必要保險
• 根因不明：只能看到症狀不知道問題在哪一層，不同視角的分析者可能在不同地方找到線索

反之，問題簡單、根因已知、時間緊迫需要先恢復服務，就先用單一視角快速處理，事後再補完整分析。

視角的選擇

以測試失敗為例，程式碼視角和測試視角幾乎必選，一個看實作一個看設計。架構視角在失敗跨越多個模組時升格為必選。需求視角在懷疑規格對齊問題時加入。

常見視角：

• 程式碼：實作細節、邏輯正確性
• 測試：測試設計、覆蓋率、mock 假設
• 架構：依賴關係、介面合約、整體結構一致性
• 需求：規格對齊、功能完整性

三到五個視角是比較好操作的範圍，太多會讓彙整工作失去焦點。

報告格式

每份視角報告需要有一致結構，彙整才做得起來：

• 發現項：標明嚴重程度，附具體證據（程式碼位置或測試輸出）
• 根因推斷：這個視角對問題來源的推斷，是「推斷」不是「結論」，單一視角的觀察永遠是局部的
• 建議：修復或改善方向，附理由
• 關聯視角：這份報告的發現可能和哪些其他視角有關，對彙整者特別有用

彙整報告的核心是交叉驗證：找出所有視角都同意的共識（可信度最高，優先處理）、找出只有特定視角看到的獨特發現（不能丟棄）、正面處理衝突（分析衝突原因，給決策建議，不是選一個忽略另一個）。

一個完整的例子

那次跨三個模組的複雜失敗，我們啟動了四個視角並行分析：

• 程式碼：型別轉換在邊界條件下產生空值
• 測試：mock 設定假設了一個不再成立的前提條件
• 架構：三個模組間的依賴關係最近有過調整，但某個介面合約沒有同步更新
• 需求：最近一次規格變更重新定義了邊界行為，但實作沒有對應修改

彙整之後，四個視角都指向「介面合約不一致」，只是各自看到不同表現。這個共識讓修復方向非常清楚，信心度比單一視角高出很多。

衝突怎麼處理

衝突不應迴避，應正面處理。幾個簡單原則：

• 根因推斷不一致：把所有可能根因列出來，建議逐一排查，不要憑直覺選一個
• 修復建議方向衝突：評估各方案風險和成本，選最穩健的
• 優先級不同：取最高優先級，不遺漏緊急問題
• 修復範圍不同：取範圍聯集，寧可多修一點

邏輯一致：在不確定性面前，傾向保守和全面，而不是快速和片面。

彙整報告要驅動決策

報告最後要明確給出根因結論、修復方案和派發建議，讓決策者不需要自己從原始報告拼湊答案。讀完之後應該知道：問題是什麼、各視角是否有共識、接下來修什麼、誰去修、有哪些風險需要持續關注。讀完還不清楚下一步，彙整就做得不夠。

回到最開始那次事件：如果當時啟動多視角分析，架構視角大概第一時間就會看到介面合約的問題，而不是修了兩次還在找根因。問題複雜度到一定程度，快速就等於緩慢，全面才是真正的效率。

這個「先做簡單的」念頭，幾乎讓我們陷入一個耗費兩倍時間的窘境。

仔細看才發現，那個「簡單的參數問題」和另外兩個缺失事件，根本出自同一個根因：事件系統在早期規劃時就設計好了，但後來的實作只完成了一部分。如果我們先去修參數，等到補完缺失事件之後，那個測試可能還要再動一次。

更糟的情況是：如果我們在過程中發現了架構問題，才意識到不能這樣修，那前面所有的工作都白費了。

從那次之後，我們開始認真思考一件事：發現問題的當下，應該先做什麼？

分批思維的陷阱

「分階段處理」聽起來很有道理。把大問題切小，每個階段有進展，感覺有效率。但有一種分批方式是有害的——那就是在沒有做完整分析之前，就開始決定「先做哪個、後做哪個」。

這種模式的問題在於決策的依據是「哪個快」而非「哪個對」。

我們把這種思維方式稱為分批思維，它的表現形式通常是：

• 先修復簡單的，再處理複雜的
• 立即解決眼前問題，其他的之後再說
• 邊做邊看，問題浮現了再應對

這是一種短視的合理化。在壓力下，任何能「讓情況立刻改善一點」的選項都很誘人。但它的代價是：你可能一次又一次回到同一個地方修修改改，最終花了更多時間，卻在系統裡留下更多裂縫。

全局分析優先

我們現在的做法是：發現問題，先停下來分析，再決定怎麼做。

重點是在選擇修復路徑之前，先弄清楚幾件事：

這個問題影響了哪些檔案和模組？根本原因是什麼——設計就有缺陷，還是實作沒有完成？有沒有連鎖問題藏在後面現在看不到、之後才會浮現？

影響範圍不明、根因不清楚、發現多個相關問題——只要符合任何一條，就必須做完全局分析再動。影響範圍明確且確定是局部問題，才可以直接修。

策略規劃先行

全局分析之後，下一步是先把策略規劃完。

策略規劃的核心是：把全局分析中識別出的所有問題，都設計進解決方案裡，拆成可追蹤的任務，標清楚依賴關係，排好執行順序。

這裡有一個關鍵區分：

• 正確的分批執行：有完整策略，所有任務都設計好了，按優先順序一個個做。
• 錯誤的分批思維：沒有完整策略，邊做邊規劃，哪個容易先做哪個。

前者是系統性執行，後者是隨機應對。看起來相似，結果差很多。

策略規劃的品質可以用幾個問題來檢驗：這份策略涵蓋了全局分析識別出的所有問題嗎？每個任務的目標和範圍是明確的嗎？任務之間的依賴關係是清晰的嗎？有沒有哪個任務完成了，反而會讓另一個任務需要重做？

如果這些問題都能肯定地回答，策略才算完整。

設計問題和實作問題要分清楚

在判斷如何處理問題之前，有一個分類特別重要：這個問題是設計問題，還是實作問題？

設計問題指的是架構層面的缺陷，例如違反了分層原則、依賴方向錯誤、模組職責不清。這類問題的共同特徵是：就算把當下的錯誤「修掉」，根本的架構隱患還在，之後還是會以另一種形式冒出來。

實作問題指的是設計本身是對的，但程式碼還沒寫完，或者寫錯了某些地方，例如功能規劃完整但程式碼缺失、測試引用的事件類別還沒被建立、某個參數傳錯了。

這兩種問題的處理方式截然不同：

遇到設計問題，必須立刻停止功能開發，修正架構，然後再繼續。繞過去的代價是系統性的架構債務。

遇到實作問題，不需要停止，按照全局分析的結果規劃任務，依序補完就好。

混淆這兩類問題是一種常見的失誤。把設計問題當成實作問題來修，是最危險的一種——表面上解決了，實際上問題變得更隱蔽。

判斷的方法很直接：這個問題是違反了架構原則？影響了多個層級？如果是，優先考慮設計問題。如果問題是「功能設計完整但程式碼不在」，那是實作問題，按計劃處理即可。

用一個真實案例來看

回到我們開頭那個例子。三個整合測試出錯，表面看是測試引用問題，但全局分析之後的結論是：根因是事件系統在早期規劃了完整的事件，但後來只實作了其中一部分。這是實作問題，不是設計問題。

所以我們沒有立刻去修那個「簡單的」測試，而是先規劃完整策略：

第一階段，補全所有缺失的事件類別。這是架構基礎，必須先做，而且這些任務彼此獨立，可以並行處理。

第二階段，等事件類別都建好之後，統一修復三個測試檔案。這時候每個測試的修改都有完整的依賴可以對齊。

第三階段，執行所有整合測試，確認百分百通過，更新文件。

這個順序保證了每一步的修改只需要做一次，不會因為後來又發現新問題而需要回頭重改。

相比之下，如果我們走了「先修簡單的」路線，第一個測試會改兩次——一次修參數，一次等其他事件建好之後再調整引用。效率反而更低。

另一個例子是架構問題的處理。如果我們發現一個 UseCase 直接引用了 Widget，這是明確的設計問題——違反了 Clean Architecture 的分層原則。遇到這種情況，我們的做法是立刻停止其他功能的開發，重新設計 UseCase 的輸入輸出，用 DTO 來替代直接引用，修正依賴方向，然後才繼續之前的工作。

不處理，問題不會消失，只會越埋越深。

在實踐中保持這個習慣

這套方法論的難處在於在壓力下堅持。當測試出錯、當時間緊，「先修了再說」的衝動非常強。

我們找到的一個有效做法是：在決定怎麼修之前，強迫自己回答這幾個問題——影響範圍確定了嗎？根因清楚嗎？這是設計問題還是實作問題？策略有沒有涵蓋所有識別出的問題？

全部能回答，才開始動。有任何一個無法確定，繼續分析。

這個過程一開始會感覺很慢，但隨著熟練度提升，全局分析本身的時間會縮短，而且避免的重複修改和架構返工，帶來的時間節省遠超過分析的成本。

結語

這套習慣的核心只有一句話：速度不是決策依據，正確才是。

發現問題先全局分析，分析完先做策略規劃，遇到設計問題立刻停下修正，然後才開始執行。慢下來，才能真的快。