开源一个 Android/Rockchip 代码审查 Skill：android-rockchip-reviewer-skill

摘要

最近整理并开源了一个面向 Android/Rockchip 源码改动审查的 Claude Skill：`android-rockchip-reviewer-skill`。它不是一个通用的代码风格检查工具，而是专门用于 Android 11/12/13、Rockchip RK3566/RK3568/RK3562 等源码项目中的 Delta Review。重点关注 Kernel driver、DTS/DTSI、HAL、Framework、init、sepolicy、PRODUCT_PACKAGES、Android.bp/Android.mk 等底层系统改动。

项目地址：https://github.com/youngersweet/android-rockchip-reviewer-skill

问题：当前codex/claude等agent中review通常都是针对于你所改动的diff内容本身进行审查，是否完成既定目标，编写是否存在编译，语法，约定等BUG；但是却没有针对改动内容进行联动性，相关性的审查，很可能导致修复了A，但出现了B，完成了A功能，但引发B BUG；

解决：当前项目主要目标：让 AI Review 从“泛泛建议”变成“有证据、有范围、有风险等级、有验证方式”的工程化审查流程；30%修改内容本身审查，70%修改内容及其代码语义影响分析。

项目目标

`android-rockchip-reviewer-skill` 是一个 Claude/Codex Skill，用于主动调用 `/reviewer` 时，对当前代码改动执行证据驱动的 Delta Review。

1- 普通 review 只看“这几行代码有没有明显 bug”。该 skill 要看“这几行改动在 Android/Rockchip 系统链路里会影响谁、被谁触发、依赖什么环境、破坏什么隐含契约”。
2- 对 Android/Rockchip 代码改动执行证据驱动的 Delta Review，并强制纳入变更所在的系统语义环境、调用/触发链、影响面、配置联动和运行时验证边界，避免只审查局部代码本体。
3- 对代码 diff 做结构化 review，而不是泛泛给建议。
4- 默认使用 deep 模式，覆盖变更本体、调用链、影响面和风险兜底。
5- 强制证据驱动：没有证据不得报告 P0/P1 高危问题。
6- 控制搜索范围：默认 L0/L1，发现问题或证据不足时再进入 L2 定向搜索。
7- 区分已确认问题和需要验证的风险，降低误报。
8- 符合 Android/Rockchip 项目习惯：默认只读分析，不主动编译。

核心定位

这里的重点不是“多找几个 caller”，而是审查这些面：
1- 本体面：这次 diff 自己改了什么。
2- 调用/触发面：谁会调用它、触发它、加载它、注册它。
3- 影响面：它会改变哪些状态、时序、资源、权限、配置、错误路径。
4- 环境语义：它所在的是 DTS、driver、HAL、init、sepolicy、SystemServer、PRODUCT 包装链还是 framework 服务链。
5- 联动面：manifest、rc、mk、bp、sepolicy、feature XML、DTS compatible、service name、property 是否同步。
6- 风险面：是否破坏启动链、权限模型、硬件识别、服务注册、binder 暴露、watchdog、suspend/resume 等关键路径。

支持的 Review 范围

三档 Review 模式

Skill 中定义了三档模式：`quick`、`normal`、`deep`。

/reviewer --mode quick

/reviewer --mode normal

/reviewer --mode deep

也兼容旧式深度参数：

/reviewer --depth 1 # quick

/reviewer --depth 2 # normal

/reviewer --depth 3 # deep

quick：

适合小改动快速扫雷。

- 主要看单文件和直接依赖；

- 默认只做 L0，必要时 L1；

- 只报告阻塞项或明确风险。

normal：

适合普通功能改动。

- 看变更文件和同模块依赖；

- 默认 L0/L1，必要时 L2；

- 输出风险、观察项和验证建议。

deep：

默认模式。

- 适合核心模块、跨模块变更、底层系统改动；

- 检查变更链路、影响面、风险兜底；

- 默认 L0/L1，发现问题或证据不足时进入 L2；

- 输出完整报告。

搜索范围控制：L0 / L1 / L2

为了避免 AI 一上来全项目乱搜，Skill 对搜索范围做了分层。

L0：单文件

只看目标文件和对应 diff，重点分析变更附近。

适合：

- 小范围逻辑改动；

- 注释、日志、局部判断条件；

- 明确不涉及外部接口的修改。

L1：同目录 / 同模块

读取强关联文件，例如：

- `.c` ↔ `.h`；

- `Android.bp` ↔ `Android.mk`；

- `.te` ↔ `file_contexts` / `property_contexts`；

- HAL ↔ manifest / device.mk。

L2：项目级定向搜索

L2 不是禁止，而是必须有理由。

出现以下情况时允许或必须进入 L2：

- 疑似 P0/P1 高风险，但 L0/L1 证据不足；

- 变更涉及公共接口、核心服务、DTS compatible、property、SELinux domain/type、HAL service、PRODUCT_PACKAGES；

- L1 发现调用方或被调用方不在同模块；

- 需要证明“没有同步修改”或“存在隐式依赖”。

L2 必须说明：

- 为什么进入 L2；

- 搜索关键词是什么；

- 搜索结果是否截断；

- 哪些结果被纳入结论。

Android/Rockchip 专项优先级

Skill 会优先关注以下高风险区域：

1. 核心启动链：init、zygote、SystemServer、servicemanager、surfaceflinger；

2. 权限与安全：SELinux、uid/gid、capability、property_contexts、file_contexts；

3. DTS/驱动硬件链路：regulator、GPIO、interrupt、clock、pinctrl、bus、wakeup-source；

4. HAL/VINTF/service 注册：manifest、service rc、库依赖、接口版本；

5. PRODUCT_PACKAGES/feature/权限 XML：包是否安装、feature 是否与服务一致；

6. Framework 核心服务：AMS、PMS、WMS、PowerManager、Input、Camera、Audio；

7. 性能与稳定性：启动时序、阻塞调用、资源泄漏、watchdog、重试/超时。

这些区域出问题时，影响往往不是“某个函数不对”，而是启动、权限、服务注册、硬件识别、稳定性等系统级问题。