真实 PR 上跑了一次 AI 评审：20 个文件审出 1 MINOR + 3 INFO，还把「机器判不了的 7 件事」逐条列给评审人

场景：PR #1（lc_power_shield → main，STM32F030 多通道 ADC 采样 / 功耗测量）开好后，zephyr_rtos_ci 发起 REQUEST_REVIEW，评审机器人 ai-review-bot 在 25 分钟内把报告直接贴回 PR 讨论区（COMMENT，5775 字）。结论是可合入，但没有一句「看起来不错」：1 条 MINOR 落到 Kconfig:4、3 条 INFO 落到具体行号，另外把 7 个非 C 文件与 7 条机器给不了结论的问题单独列出来交给评审人——这比「AI 说没问题」有用得多。

提交者开 PR #1（20 个文件）        https://zephyrrtos.cn:3000/zephyrrtos_china/zephyr/pulls/1
  │  zephyr_rtos_ci 发起 REQUEST_REVIEW
  ▼
ai-review-bot（zephyrrtos.cn 评审引擎 · 规则 40 条 + tree-sitter 结构/复杂度）
  │  取 refs/pull/1/head，与 origin/main 做 diff；基于完整文件，存量问题也报
  ▼
在 PR 上以 COMMENT 形式发布报告（5775 字 · 固定六段）
  ├─① 结论：可合入 · MAJOR 0 / MINOR 1 / INFO 3
  ├─② 问题清单：文件:行 + 规则 ID + 置信度 + 判据 + 建议
  ├─③ 结构分析：main() CC=14 · SLOC=66 · 嵌套 4 · 调用 23
  ├─④ 机器检查：本次未跑上游 checkpatch（显式写明，不假装跑过）
  ├─⑤ 未验证 / 需人工确认：7 个 .overlay/.yaml + 7 条机器判不了的问题
  └─⑥ 规则覆盖：命中 3 条 / 已执行未命中 37 条
  ▼
人：按清单改 → 复跑 → 合入或拒绝（BLOCK 只能评审人给）

• MINOR · R-KCF-002 Kconfig:4 config SEQUENCE_SAMPLES 缺 help 说明（同类共 4 处：4/17/21/24）——判据是上游要求新符号必须有 help，缺了不能合入，用户也看不出开关干什么
• INFO · R-KCF-003 Kconfig:21 SEQUENCE_32BITS_REGISTERS 与 Kconfig:24 SHELL_ADC_PS 既无 depends on 也无 default/select：没有可见性/默认值的符号会出现在所有配置里，容易被误开
• INFO · R-KRN-003 src/main.c:31 可写 static vrefs_mv 被 3 个函数（defined / cmd_adc_status / main）使用，全文件没有 k_mutex/k_spinlock/atomic/irq_lock——volatile 只防优化，不防撕裂
• 结构分析给数字不给形容词：main.c 238 行 / 3 个函数；复杂度热点 main() CC=14、SLOC=66、嵌套 4、调用 23；并如实标注「语法树 2 个 ERROR 节点，函数数是下界」
• 诚实清单：6 个 .overlay + 1 个 sample.yaml 只做通用检查（未做规则扫描）；另列 7 条机器判不了的项目——设计意图、栈与实时性、优先级反转、性能预算、API 语义、版本兼容、测试证据，要求评审人逐项给结论

边界与用法：这是机器 + 启发式的评审，等级契约写在引擎里——机器规则最高 MAJOR、启发式一律降级 INFO「待人工确认」、BLOCK 只能评审人给；报告第 5 段固定列「未验证 / 需人工确认」，没有这段就说明报告没按契约出。想自己复现或对别的 commit/PR 跑一遍：把 Gitea 链接的 host 换成 /agent/api/r/ 即可（PR → /agent/api/r/zephyrrtos_china/zephyr/pull/1，?raw=1 取 Markdown）。目前 PR 评审只覆盖 zephyrrtos_china/zephyr；合入与否仍由人决定。