每次修改後全面審查，節奏會拖慢；不審查，問題又會累積。更麻煩的是，自己審查自己的程式碼，容易用同一個框架看事情，系統性地漏掉某類問題。

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

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

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

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

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

並行掃描解決什麼問題

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

並行評估的做法是啟動多個 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 排入執行，跳過的發現留在記錄中備查。

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

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