Appearance
L03-15 案例二：代码审查 Agent
全局中心内容：Code Review Agent 的生死线是「误报率」——宁可少报，不可乱报。 全局讲解主线：为什么难 → 定位精度问题 → 规则与模型分工 → 行号对齐 → 置信度 → CI 集成 → 度量。
P1 · 产出页
中心内容：一个能给出准确行号、带置信度、可接入 CI 的审查 Agent。
- 讲解技巧
- 开场真相：大部分团队做过 Code Review Agent，大部分最后关掉了。
- 追问原因——几乎都是同一个：误报太多，没人看了。
- 时长：30s
P2 · 为什么难
中心内容：代码语义复杂、上下文大、错误标准主观。
- 讲解技巧
- 强调最大的坑：模型会「幻觉出」代码里不存在的问题。
- 结论：这不是模型能力问题，是输入组织方式的问题。
- 时长：4min
P3 · 规则与模型分工
中心内容：确定性规则交给静态分析，模型只做规则覆盖不到的部分。
页面内容：分工表（格式/规范 → 规则；逻辑/设计/安全 → 模型）
讲解技巧
- 这是本节最重要的方法论：模型不适合做确定性检查，做了既贵又不准。
- 提醒：先跑静态分析，把结果一起给模型，让它判断哪些真的重要。
时长：6min
P4 · 行号对齐
中心内容：模型给的行号经常对不上，必须程序校正。
页面内容：DiffParser 与行号映射
讲解技巧
- 这是本案例的核心工程难点：只给 diff 不给上下文行号，模型必然猜错。
- 给出解法：把 diff 解析成「新文件行号 → 内容」的映射，再交给模型。
时长：6min
P5 · 准确率优先
中心内容：宁可漏报，不可误报。
页面内容：置信度分级与展示策略
讲解技巧
- 给出产品策略：高置信度直接评论，中置信度折叠，低置信度不展示。
- 强调理由：一次误报会让开发者对整个工具失去信任，代价远高于漏报。
时长：5min
P6 · 输出规范
中心内容：每条意见要有 文件/行号/问题/建议/依据。
- 讲解技巧
- 用结构化输出（回顾 01-08），并要求引用具体代码行作为依据。
- 提醒：没有依据的意见要直接丢弃。
- 时长：5min
P7 · CI 集成
中心内容：只审查变更部分，控制在 2 分钟内。
- 讲解技巧
- 强调只审 diff：全文件审查又慢又容易报出与本次变更无关的问题。
- 提醒超时要有降级：超时就不评论，别阻塞流水线。
- 时长：5min
P8 · 度量与迭代
中心内容：统计采纳率，用它来调 Prompt 和阈值。
页面内容：采纳率 / 误报率 / 修复率 三个指标
讲解技巧
- 强调采纳率是最好的优化信号：低于 30% 说明噪音太大，必须收紧。
时长：4min
P9 · 避坑与小结
中心内容：不要一上来全量开启，先在少数仓库试点。
- 讲解技巧
- 引出下一节：工单处理 Agent——03-16。
- 时长：3min
讲师备忘
| 项 | 内容 |
|---|---|
| 课前必做 | 准备一个真实 diff 与解析结果；准备误报样例 |
| 最容易超时处 | P4 行号对齐，代码较长 |
| 学员最常问 | 「要不要审全文件？」答：不要，只审 diff |
| 现场备用 | 无 CI → 本地脚本演示审查输出 |