读到一篇超赞的技术文章，兴冲冲地觉得这套也要用，然后三天后完全忘了，或者照搬了一堆东西进系统、过了一个月才发现根本用不到，这个剧情很多人都演过。
问题出在哪
读文章的时候，很容易被几件事带着走：
- 名气：大神写的就一定对吗？
- 新鲜感：新的方法听起来总是比较厉害
- 行动冲动：读完总觉得「应该做点什么」
问题的根本在读者跳过了分析（文章本身写得好不好其实是次要的）。从「读完」到「执行」之间，少了一步：好好想过。
但「好好想」需要时间和精力，人类通常没有足够的耐心把每个论点都摊开来查看。
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