用途
Adversarial Code Review 用于通过敌对视角审查代码，找出作者可能遗漏的 bug、安全问题与意外后果。它适合在评审 PR、审计代码库等场景使用，目标不是尽可能多地挑毛病，而是在问题到达用户之前找出真正重要的问题。
核心原则
以“试图破坏代码”的心态进行评审，故意采用不同的敌对视角，每个视角都能揭示其他视角遗漏的问题。这不是为了找茬，而是为了在用户之前发现问题。
评审模式
技能提供两种模式。差异聚焦模式为默认模式，在没有明确指令或进行 PR 评审时使用，关注“改了什么？什么可能被破坏？”。审计模式在明确要求“audit”“holistic”“codebase review”时触发，范围更广、覆盖更系统。若有疑问，使用差异聚焦模式；审计模式需要明确请求。
六个对抗性视角
技能要求逐一应用每个视角，不要混合，因为切换视角会迫使更深入的分析。
- 恶意用户：核心问题是“我会如何利用它？”，可揭示输入校验缺口、注入向量、权限提升。
- 粗心同事：核心问题是“用错了会怎样？”，可揭示 API 误用、契约不清晰、错误处理缺口。
- 未来维护者：核心问题是“6 个月后什么会让我困惑？”，可揭示隐式假设、缺少上下文、时间耦合。
- 运维/值班：核心问题是“凌晨 3 点它会如何失败？”，可揭示可观测性缺口、恢复路径、失败模式。
- 数据完整性：核心问题是“状态会怎样？”，可揭示竞态条件、部分失败、一致性违反。
- 交互影响：核心问题是“这还会改变什么？”，可揭示意外副作用、行为变化、契约破坏。
每个视角都有更细的问题清单。例如恶意用户视角会问：哪些输入被错误信任？能否提升权限或访问未授权数据？发送畸形/超大/意外输入会怎样？是否存在注入点？深度安全评审可参考 references/security-lens-detail.md。
视角优先级
并非所有视角对所有代码都同等重要。技能给出优先级表：用户输入处理优先恶意用户与数据完整性；API/公共接口优先粗心同事与交互影响；后台任务优先运维/值班与数据完整性；业务逻辑优先未来维护者与交互影响；数据库操作优先数据完整性与运维/值班。
评审工作流
开始评审时可复制检查清单：步骤 1 确定模式；步骤 2 理解改动/代码目的；步骤 3 按风险应用视角，每个约 5 分钟，依次为恶意用户、粗心同事、未来维护者、运维/值班工程师、数据完整性、交互影响；步骤 4 用影响过滤器筛选发现；步骤 5 按严重程度分类；步骤 6 将 Consider 条目限制为最多 2 条；步骤 7 至少指出一项优点；步骤 8 格式化报告。
五条铁律
- 严重程度匹配实际风险，而非理论最坏情况。
- 每个 Must Fix 都需要演示或清晰推理。
- 替代建议是可选的，不是强制的。
- 至少认可一项做得好的地方。
- 对抗不等于敌对，认可能建立信任。
影响过滤器
每个潜在发现都必须通过过滤器，得分 2 分以上才报告：可能发生（概率）、发生后有影响（严重度）、对作者非显而易见（附加价值）。若得 0-1 分则不报告，否则只是增加噪音。
严重程度分级
Must Fix 表示破坏正确性、安全性或数据完整性，应阻止合并，例如 SQL 注入、导致数据丢失的竞态条件、认证绕过。Should Fix 表示可能有问题但未立即损坏，应在合并前或合并后不久修复，例如缺少错误处理、命名不清、边界情况无测试。Consider 表示风格、优化、理论担忧，每次评审最多 2 条。技能特别提醒“Consider 陷阱”：超过 2 条会稀释重要反馈、显得吹毛求疵、降低评审可信度。
不应标记的内容
包括 linter/formatter 覆盖的风格偏好、同等合理的替代实现、假设性未来、纯个人偏好但并非错误。判断标准是：“一位合理的资深工程师会在这里不同意我吗？”如果会，可能就不值得评论。
报告格式
报告结构包含 Summary、What's Done Well、Must Fix、Should Fix、Consider。Must Fix 和 Should Fix 条目需包含 Location、Lens、Issue、Impact、Suggestion（可选）。Consider 仅需简要要点，最多 2 条。
何时升级
遇到安全关键代码（认证、加密、支付）时，参考 references/security-lens-detail.md，考虑外部评审。发现 3 个以上 Must Fix 时，停止评审并升级进行根本性重新设计讨论。不懂代码时不要猜，应先请求讲解。架构问题应标记为设计讨论，不要在评审中试图“修复”。
审计模式
明确要求审计时，需先定义范围：关注哪些区域/模块？主要关注点是什么（安全、性能、可维护性）？时间预算多少？抽样策略包括优先高风险区域（认证、支付、用户输入处理）、最近变更的代码（如 git log --since="3 months ago" --name-only）、复杂代码（高圈复杂度、多依赖）、无测试代码。审计附加步骤包括与请求者定义范围和主要关注点、识别高风险区域、战略抽样、跟踪覆盖、记录跨文件系统性模式。边缘情况可参考 references/edge-case-domains.md。
常见错误
包括未理解就评审、混合视角、严重程度膨胀、见木不见林。技能建议逐一应用视角并记录发现，而不是“让我看看这段代码找出所有问题”；同时提醒不是所有问题都严重，若一切都紧急则没有紧急之事；应用完所有视角后要退后一步，看是否存在系统性模式或更深层设计问题，是否应转为重新设计讨论而非继续评审。
关键原则
目标不是找出尽可能多的问题，而是在问题到达用户之前找出重要的问题。质量重于数量，影响重于体量，信任重于彻底。