讀到一篇超讚的技術文章，興沖沖地覺得這套也要用，然後三天後完全忘了，或者照搬了一堆東西進系統、過了一個月才發現根本用不到，這個劇情很多人都演過。
問題出在哪
讀文章的時候，很容易被幾件事帶著走：
- 名氣：大神寫的就一定對嗎？
- 新鮮感：新的方法聽起來總是比較厲害
- 行動衝動：讀完總覺得「應該做點什麼」
問題的根本在讀者跳過了分析（文章本身寫得好不好其實是次要的）。從「讀完」到「執行」之間，少了一步：好好想過。
但「好好想」需要時間和精力，人類通常沒有足夠的耐心把每個論點都攤開來檢視。
AI 有。
Deep Review 是什麼
Deep Review 是一套給 AI Agent 的研究方法論。一份結構化的 prompt，專門解決「該不該採用這篇文章的建議」這個問題。
它的核心是幫忙分析（摘要文章那種事隨便一個 AI 都能做）：
- 這篇文章解決的問題，自己真的有嗎？
- 它的建議有證據支撐嗎？還是只是觀點？
- 跟現在的系統比，差在哪？
- 採用的成本和風險是什麼？
- 改了之後發現不行，退得回來嗎？
跑完之後，每條建議都會拿到一個明確的判定：採用、實驗、拒絕、或需要討論。
不靠直覺，靠流程。
六個階段
Phase 0：過濾
最重要的第一步：這個問題在自己的系統裡存在嗎？
多數文章解決的問題其實不存在於使用者自己的系統。如果第一題的答案是「沒有」，整個分析直接結束。不浪費時間，不浪費 token。
「什麼都不改」是完全合理的結果。
Phase 1：提取
把文章拆成一條一條獨立的主張（claims），然後標記每一條的證據類型：
| 類型 | 例子 |
|---|---|
| 實驗數據 | 「測了 500 次，延遲降低 40%」 |
| 案例研究 | 「團隊用了之後生產力提高」 |
| 邏輯推理 | 「因為 A，所以 B 應該成立」 |
| 純粹觀點 | 「這樣比較好」 |
這一步純提取，不做判斷。先忠實呈現作者說了什麼。
還會問一個微妙的問題：如果這篇文章是匿名發表的，你還會覺得一樣有說服力嗎？ 用來對抗權威偏誤。有時候被說服跟論點本身無關，純粹因為作者有名。
Phase 2：比對
把每條主張和系統現狀對照，而且必須引用具體的檔案和行數。
「系統裡好像有類似的東西」這種含糊的說法不被接受。要嘛指出 config.yaml:42，要嘛承認還沒查到。
Phase 3：論辯
針對每條主張，列出正反兩面：
- 支持：文章的證據 + 對自身的具體好處
- 反對：實施成本、和現有系統的衝突、作者沒考慮到的情境
- 缺失：做決定之前還缺什麼資訊
另外會從可靠性、可維護性、操作性、複雜度四個面向評估影響，以及一個常被忽略的問題：採用之後後悔了，退回來的成本高嗎？
Phase 4：決策
每條主張一張決策卡，格式統一：
- Claim：這條主張是什麼
- Decision：採用 / 實驗 / 拒絕 / 需要討論
- Reasons：前 2-3 條理由
- Concrete change：如果要改，改哪個檔案的哪個部分
- Expected consequences：預期的正面和負面影響
答案不只「好」跟「不好」兩種。有時候是「先小規模試試」，有時候是「東西不錯但用不到」。
Phase 5：審計
最後一步，也是最關鍵的設計：審計必須由獨立的 subagent 執行。
為什麼？AI 在同一次對話中檢查自己的輸出，幾乎一定會說「看起來沒問題」。研究顯示這種自查的辨別力趨近於零。
獨立 subagent 會檢查幾個常見的失敗模式：
- 所有主張都被採用，或全部被拒絕（沒有分辨能力）
- 比對表裡沒有具體的檔案路徑（含糊帶過）
- 反對意見全都是「需要更多資料」（迴避判斷）
- 支持論點只是重述文章（沒有結合自身情境）
還會問一個狠問題：跳過整個分析、30 秒靠直覺做決定，結論會一樣嗎？ 如果答案是「會」，代表這個分析沒有產生額外價值。
重點在學習，不在審查來源
有人可能會問：這算是在「審核」文章嗎？
不算。Deep Review 的核心態度是學習：目的不在複製，也不做批判。
它要回答的問題是：「這篇文章裡有什麼東西，對使用者的系統有用？」判定文章「對」或「錯」從來不是重點。
Phase 5 的審計，審的是分析過程的品質（文章本身不在審查範圍）。帶著學習的心態去評估資源，輕量的紅旗檢查就夠了。
怎麼開始用
最簡單的方式：
- 把
deep-review.md放到專案目錄或~/.claude/裡 - 在 Claude Code 裡輸入
deep-review，貼上文章 - 等它跑完六個階段，拿到結論
就這樣，一個檔案，不用裝任何東西。
不是用 Claude Code 也沒關係。deep-review.md 就是一份結構化 prompt，可以拿去 Cursor、Windsurf 或任何能讀 markdown 的 AI 工具裡用。
為什麼做這個
長期搭 AI Agent 系統的人，每天都會讀到大量技術文章和別人的做法。有些真的很好，有些聽起來很好但其實不適合自己。
問題是：沒有時間和精力把每篇都仔細分析。直覺判斷又常常出錯：要嘛過度樂觀，要嘛完全忽略。
於是有了 Deep Review：把「直覺」變成「流程」。
不是所有文章都需要跑這套分析。簡單的小技巧看看就好。但遇到那些可能改變系統架構或工作流程的文章時，花幾分鐘跑一下 Deep Review，可以省下之後幾小時的踩坑時間。
背後的研究
設計有據可查：
- CheckEval：為什麼 checklist 比開放式評分更好
- LLM-as-Judge 研究：AI 當評審時的已知偏見
- 多 Agent 辯論研究：為什麼 AI「角色扮演辯論」常常適得其反
- Heilmeier Catechism：DARPA 的提案評估方法
- Architecture Decision Records：工程團隊記錄決策的標準格式
延伸閱讀
Deep Review 是開源的，MIT 授權。
GitHub：p3nchan/deep-review
小企鵝的經驗
這套 skill 是小企鵝自己寫的，每天都在用。最常用的場景就是讀到一篇技術文章覺得好像很厲害的時候，先丟進 Deep Review 跑一輪，再決定要不要動手改系統。八成的文章跑到 Phase 0 就直接結束（自己的系統根本沒這個問題）。剩下兩成裡，又有一半在 Phase 4 拿到「需要討論」或「拒絕」。真的進到「採用」的比例比想像低很多，這正是它的價值：把興奮的衝動轉成有依據的決定。
常見問題
Q: Deep Review 是什麼？
一套給 AI Agent 的結構化分析方法。讀完技術文章後，用六個階段（過濾→提取→比對→論辯→決策→審計）判斷哪些建議值得採用，哪些應該跳過。
Q: 需要特定的 AI 工具才能用嗎？
主要為 Claude Code 設計，但 deep-review.md 就是一份結構化 prompt，可以用在 Cursor、Windsurf 或任何能讀 markdown 的 AI 助手上。
Q: 和直接問 AI「這篇文章好不好」有什麼差別？
直接問 AI 通常會得到一面倒的正面回覆。Deep Review 強制 AI 走完完整的分析流程，包括比對現有系統、列出反對理由、並用獨立的 agent 做審計，避免自我肯定偏誤。
Q: 「什麼都不改」也是合理的結果嗎？
完全合理。Deep Review 的 Phase 0 就是先問「我們有這個問題嗎？」，如果沒有就直接結束。不是每篇文章都需要行動。
整理：Penna｜小企鵝 Penchan