| name | code-review |
| description | Token 节约的多维度代码审查。用于审查 diff/分支/PR，或任务提及"代码审查""review my changes""找 bug"。按 diff 大小缩放审查深度，按严重程度分级报告，依据项目威胁模型校准以避免严重度通胀。仅报告问题；除非明确要求，不修改代码。 |
| license | MIT |
| compatibility | kimi-cli |
| metadata | {"audience":"reviewers","workflow":"review"} |
代码审查
结构化、Token 节约的审查方法。一次审查覆盖所有维度，深度按 diff 大小缩放，严重度按项目上下文校准。
步骤 0 — 确定范围
审查前先确定变更集和大小：
- 分支 vs 基准：
git diff --stat main...HEAD
- PR：通过
gh 获取 diff
- 显式文件：仅那些路径
按变更文件数和净变更行数选择路径：
| 规模 | 路径 | 行为 |
|---|
| ≤ 8 文件且 ≤ 500 行 | 简略（默认） | 单次聚焦审查 diff 及其直接调用方。内联报告。 |
| 更大或跨模块 | 完整 | 逐维度审查；将结果写入文件。 |
审查维度
覆盖 diff 实际触及的每个维度，跳过无相关变更的维度：
- 正确性 — 逻辑错误、越界、null/undefined、未处理边界情况、错误路径、对调用方的错误假设。
- 安全性 — 注入、XSS、认证/授权缺陷、密钥泄露、路径遍历、SSRF、不安全反序列化。
- 性能 — N+1 查询、无界循环/分配、热路径上的阻塞调用、缺少分页/超时、内存泄漏。
- 架构 — 不当耦合、泄露的抽象、职责在错误的层、不必要的复杂性。
- 可维护性 — 命名、函数大小、魔数、死代码、重复逻辑、与周围代码库的约定偏差。
- 文档与注释 — AI 样板注释复述代码、注释掉的代码、解释 WHAT 而非 WHY 的注释。
- 兼容性 — 破坏性 API/签名变更、改动的公共契约、改动的默认值、DB/schema 迁移、未更新的调用方。
报告前静默验证：通读每个变更文件，检查未使用的导入、遗留的 TODO、调试打印；确认新增/修改的函数有调用方。
严重度级别
- critical — 数据丢失、安全漏洞、崩溃、核心行为损坏。合并前必须修复。
- major — 真实 bug 或在合理输入下的退化；错误结果。
- minor — 窄影响 bug、弱错误处理、显著异味。
- nit — 风格/命名/注释打磨。仅在累积成可维护性问题时报告，否则省略。
严重度校准（防止通胀）
按上下文判断影响，非按规则模式匹配：
- 读取
AGENTS.md 中的约定、威胁模型和上下文。
- 从
package.json 等文件检测项目阶段（v0.x vs v1+）、部署模型（本地工具？公共服务？库？）。
- v0.x 项目：API 稳定性/兼容性问题 → 最多 minor（semver 预期破坏性变更）。
- 仅本地工具：认证/网络攻击面 → minor（已文档化的约束）。
- 降低不适用于该项目现实的发现。注明校准原因。
- 宁可一个准确的高严重度发现，也不要十个被夸大的。每次误报都会侵蚀对整个审查的信任。
报告前自疑检查
在写下任何发现前，静默做对抗性检查。默认为拒绝：
- 我能反驳这个吗？ 构建反方论证。"这没问题因为……"
- 严重度被夸大了吗？ 在第二位审查者审视下能站住脚吗？
- 这是真实问题还是个人偏好？ "变量名可以更好"不是发现，除非造成真实困惑。
开篇用一行严重度总结：critical: N | major: N | minor: N | nit: N 及采用的路径。
每个发现按严重度排序，格式：
[severity] <标题> (维度)
location: file:line
issue: <问题所在及触发的输入/条件>
impact: <破坏什么，或攻击者/用户获得什么>
fix: <最小具体修复方案>
结尾给出简短总体评估（可合并？有阻断项？）。如果变更确实干净，坦白说明——不人工制造发现。
