每次修改後全面審查會拖慢節奏，不審查則讓問題累積。第三個限制比前兩個更難處理：自己審查自己的產出時用的是同一個框架，漏掉的類型會系統性地重複漏掉。

並行評估同時處理這三件事：多個視角獨立審查、全部並行執行、產出經過一次「值不值得動手」的過濾。

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

以「發現盡量多的問題」為目標的審查流程，產出的是一份沒有排序的清單，而清單的每一項都要花成本：執行時間、變更風險、注意力。改善幅度沒有明確大於這些成本的項目，執行它是淨損失。

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

並行掃描解決什麼問題

單視角審查的弱點來自注意力的排他性：正在找重複程式碼的時候，效能問題不在搜尋範圍內。

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

執行流程

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

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

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

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

Worth-It Filter 的邏輯很直觀：

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

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

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

相當一部分審查意見屬於低改善幅度的風格偏好：討論成本高、實質改善小。有了固定的過濾標準之後，跳過它們不需要每次重新論證一遍。

一個可以當場執行的判準：解釋「為什麼這個值得改」需要超過 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 看文件和設計規範，關注術語一致性和交叉引用完整性。視角設計也應有所不同。

輸出格式

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

「跳過的發現」這一部分承擔的是記錄責任：那個問題被看到了，而且被評估過並決定不處理。少了這一段，同一個問題會在下一輪重新被發現、重新被討論。

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

這套彙整裁量對品質改善類發現是對的設計；發現屬於安全或阻斷性質時，彙整裁量本身會成為風險——否決該直接落在 gate、而非回到彙整層裁量，判讀條件見 發射管制隊視角的安全分線 lens。

這個框架的產出除了值得行動的清單，還有一個附帶結果：跳過的項目有了明確依據——多個獨立視角看過、經過同一套過濾標準判定。這讓「還有沒有該處理的問題」這個疑問有地方查證。

同一個問題該由幾個視角分析、分歧怎麼收斂，走 多視角並行分析。