代码审查与风险检查

---
name: code-review-and-risk-check
description: 以"审查者"视角检查代码 diff，重点抓正确性、边界、安全、兼容性与可维护性，而不是风格挑刺。用于 PR 评审与合入前把关。
---

# 代码审查与风险检查

## 何时使用

- 有 PR / diff 待合入。
- 自己写完代码想让 AI 先过一遍（自审）。
- 发布前的最后一道人工关口。

## 前置

- 必读 `.agents/rules/代码规范.md`、`架构边界.md`、`API与兼容性规则.md`、`安全与隐私规则.md`、`测试规则.md`。
- 拿到**完整 diff**（不是摘要）。

## 输入

- 代码 diff / PR 描述
- `变更/<id>/实现计划.md` 与 `验证记录.md`（判断是否达成目标）
- 相关 `.agents/context/` 条目

## 步骤

按下面的**审查顺序**逐层看（从"会不会出事"到"好不好维护"）：

1. **正确性**：逻辑是否实现需求？有无边界遗漏（空、0、负、超大、并发）？错误路径是否处理？
2. **契约与兼容**：API / 事件 / Schema 变更是否与 `模块与契约/` 一致？是否破坏既有调用方？
3. **安全**：越权、注入、XSS、SSRF、敏感信息硬编码 / 日志泄露、依赖风险。（对照 `安全与隐私规则.md`）
4. **数据**：事务边界、幂等、并发写、迁移可回滚、软删语义。
5. **性能**：N+1 查询、无索引查询、大对象拷贝、循环内 IO、无界内存增长。
6. **可观测性**：关键路径是否有日志 / 指标 / trace？错误是否可定位？（对照 `可观测性规则.md`）
7. **测试**：是否有对应测试？测试是否测了行为而非实现细节？
8. **可维护性**：命名、职责单一、重复代码、过度抽象、注释与文档同步。
9. **规范**：仅此阶段才看风格 / lint（由工具跑，人不必纠结）。

对每个问题标注：**阻塞（必须改） / 建议（可改可不改） / 提问（需要作者说明）**。

## 输出

- PR 上的分级评论（阻塞 / 建议 / 提问）。
- 若发现架构级问题 → 建议写 ADR 或转 `架构决策/技术债务.md`。
- 若影响面比计划大 → 回退到 `代码库理解与影响分析`。

结论必须明确二选一：**可合入** / **需修改后再看**。

## 检查清单

- [ ] 所有"阻塞"项都给了具体的修改方向，而不是"这样不好"。
- [ ] 逐条核对了契约变更与兼容性。
- [ ] 检查了安全与隐私高风险点。
- [ ] 确认测试覆盖了本次改动的核心路径。
- [ ] 给出了明确的合入结论。
- [ ] 已区分"本次必须改"与"记入技术债下次改"。

## 边界与禁止

- **禁止**把审查变成风格仲裁（格式化交给工具）。
- **禁止**只给"LGTM"而不写任何检查依据——要么逐项过，要么说明为何轻量。
- **禁止**在未看完整 diff 的情况下下结论。
- 发现安全 / 数据高危问题时，**立即**标为阻塞并提示用户，不得默默放过。