生产级代码审查

要解决什么问题

合并前的人工审查容易漏掉「只在生产才爆」的问题：生命周期泄漏、线程竞态、未覆盖的错误路径。移动端改动还涉及平台惯例，泛泛的 lint 往往给不出可执行的修复。本技能把审查立场固定为：这条改动会不会在生产出事？ 有事才报，并强制按严重级别归类。

如何工作

• 范围解析：根据你的表述选择 git diff HEAD、暂存区、单次 commit、区间或与 main 的分支对比；含糊时默认未提交改动。
• 平台识别：仓库根目录匹配 Xcode/Gradle 等标记后，加载 references/review-general.md 与 Android 或 iOS 规则；否则走通用工程原则。
• 预检与过滤：先看 git diff --stat；超大 diff 会警告或需你确认。二进制、生成物、锁文件、vendor/、node_modules/ 等只统计、不逐行审。
• 上下文：不只读 diff 行，会读变更周围的完整函数/方法；公开 API 变更会用 git grep 查调用方；签名改了但调用未改会按 P0 处理。
• 输出：每条 finding 含 severity（P0 必改 / P1 应改 / P2 可选）、文件行号、维度、问题说明、原文代码与可编译的 fix_code。默认可直接在对话里 Markdown 输出；只有你要求时才走 HTML 报告流程。

模式：security review / 安全审查 聚焦 OWASP 与注入等，安全项仅 P0/P1；quick review / 快速看看 只报 P0。同一问题在 3+ 文件重复出现会合并为一条。

边界与注意

审查只读，不会改业务代码；也不会做 reset、clean 等破坏性 git 操作。不确定严重级别时倾向更低一级，避免误报 P0。风格与命名争议不算 bug，除非进入安全审查的例外规则。若你通过子 agent 调用，输出可能省略文末 Next Steps。