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

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

單一視角為什麼會出問題

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

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

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

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

三個關鍵詞：

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

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

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

什麼時候值得啟用

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

以下三種情況值得啟用：

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

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

視角的選擇

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

常見視角：

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

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

報告格式

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

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

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

一個完整的例子

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

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

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

衝突怎麼處理

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

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

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

彙整報告要驅動決策

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

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

並行評估方法論是我們在這個需求下發展出來的框架：同時從多個視角審查，而且要快，不能成為開發瓶頸。

從「找出所有問題」到「識別值得行動的問題」

大多數審查流程都以「發現盡量多的問題」為目標，但這個思維本身就有問題。

每個改善建議都有成本：執行要花時間、引入變更風險、佔用注意力。如果改善幅度沒有明確大於這些成本，這個建議帶來的是負價值。

並行評估的核心理念是「最小充分行動」——只做剛好夠用的事。不追求發現所有問題，而是快速識別哪些問題值得行動。

並行掃描解決什麼問題

單視角審查的弱點很明顯：如果你一直在找重複程式碼，你很可能漏掉效能問題。注意力有限，框架有盲點。

並行評估的做法是啟動多個 Agent，每個負責一個獨立視角，同時掃描同一個標的。好處有三：每個 Agent 只聚焦一個問題類型，思考更純粹；多視角互相驗證，同一個問題被兩個 Agent 獨立發現的話可信度大幅提升；所有視角同時跑，整體時間成本低。

執行流程

第一階段：確定掃描標的。 先確定掃描什麼。標的可以是程式碼變更（git diff 的檔案清單）、架構文件、分析報告或功能規格。範圍要夠精確——太大的話先拆分再評估。

第二階段：並行視角掃描。 啟動 2 到 4 個 Agent，每個負責一個視角（Lens），同時掃描。視角設計的要點：焦點獨立不重疊、發現要能轉化為具體行動、數量控制在 4 個以內（超過後噪音大於訊號）。所有 Agent 各自獨立執行，產出發現清單。

第三階段：彙整與行動過濾。 合併清單、去除重複，然後對每個發現套用 Worth-It Filter，只保留值得行動的項目。

Worth-It Filter：讓過濾有標準可循

Worth-It Filter 的邏輯很直觀：

1行動價值 = 改善幅度 / (變更風險 + 實施成本)

改善幅度分三級：高（消除 bug、修安全漏洞、顯著簡化程式碼）、中（提升可讀性、改善維護性）、低（風格偏好）。

決策規則：高改善幅度不管風險都要處理；中改善幅度只在低風險時才立即執行；低改善幅度一律跳過。

很多審查意見其實都是「低改善幅度」的風格偏好，佔用大量討論時間卻沒有實質改善。Worth-It Filter 讓你有標準地跳過這些，不需要每次重新爭論。

如果你需要超過 30 秒解釋「為什麼這個值得改」，大概就不值得。

常駐委員：整體品質把關

每次執行並行評估，除了情境專屬的視角，必須加一個固定的常駐視角。

常駐委員問四個問題：這個設計能更簡單嗎？我們在解決真實問題還是假想問題？有沒有不必要的特例？有沒有破壞現有行為的風險？

評分三級：Good taste（無需改動）、Acceptable（有改善空間）、Garbage（有明顯問題）。直接對應 Worth-It Filter 的改善幅度判斷。

需要常駐委員的原因很簡單：情境特定的視角容易只盯著自己負責的那塊，整體設計層面的問題沒人管。

七種情境，各有對應的視角組合

我們歸納出七種情境：

• A 程式碼審查：Phase 3b 完成後，視角聚焦可重用性、程式碼品質、執行效率
• B 重構評估：Phase 4 開始前，視角聚焦冗餘性、耦合度、複雜度
• C 架構評估：SA 前置審查，視角聚焦一致性、影響範圍、簡潔性
• D 功能評估：Phase 1 完成後
• E 冗餘偵測：版本規劃時
• F 結論審查：incident 分析完成後，門檻最嚴格——任一視角發現問題就必須回到分析階段
• G 系統設計評估：規則、Skill 或方法論變更後，視角聚焦一致性、覆蓋完整性、認知負擔

情境 G 和情境 A 看起來相似，但標的完全不同。A 看程式碼，關注執行效率和重複程式碼；G 看文件和設計規範，關注術語一致性和交叉引用完整性。視角設計也應有所不同。

輸出格式

產出是一份結構化報告，分兩部分：值得行動的發現，和跳過的發現。

「跳過的發現」這部分很重要。它讓所有人知道某個問題我們確實看到了，但經過 Worth-It Filter 評估後決定不處理。這避免了「這個問題之前有沒有看到過？」的重複討論。

後續行動很清楚：值得行動的發現建立 Ticket 排入執行，跳過的發現留在記錄中備查。

實際使用下來，這個框架最大的價值是讓我們有信心地跳過那些不值得處理的問題。當你知道「我們已經用多個視角審查過了，這些確實不值得改」，你可以心安理得地繼續前進，不用帶著「這些問題是不是應該處理？」的疑慮。

做剛好夠用的事，不多也不少。