code-review

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 实际触及的每个维度，跳过无相关变更的维度：

1. 正确性 — 逻辑错误、越界、null/undefined、未处理边界情况、错误路径、对调用方的错误假设。
2. 安全性 — 注入、XSS、认证/授权缺陷、密钥泄露、路径遍历、SSRF、不安全反序列化。
3. 性能 — N+1 查询、无界循环/分配、热路径上的阻塞调用、缺少分页/超时、内存泄漏。
4. 架构 — 不当耦合、泄露的抽象、职责在错误的层、不必要的复杂性。
5. 可维护性 — 命名、函数大小、魔数、死代码、重复逻辑、与周围代码库的约定偏差。
6. 文档与注释 — AI 样板注释复述代码、注释掉的代码、解释 WHAT 而非 WHY 的注释。
7. 兼容性 — 破坏性 API/签名变更、改动的公共契约、改动的默认值、DB/schema 迁移、未更新的调用方。

报告前静默验证：通读每个变更文件，检查未使用的导入、遗留的 TODO、调试打印；确认新增/修改的函数有调用方。

严重度级别

• critical — 数据丢失、安全漏洞、崩溃、核心行为损坏。合并前必须修复。
• major — 真实 bug 或在合理输入下的退化；错误结果。
• minor — 窄影响 bug、弱错误处理、显著异味。
• nit — 风格/命名/注释打磨。仅在累积成可维护性问题时报告，否则省略。

严重度校准（防止通胀）

按上下文判断影响，非按规则模式匹配：

• 读取 AGENTS.md 中的约定、威胁模型和上下文。
• 从 package.json 等文件检测项目阶段（v0.x vs v1+）、部署模型（本地工具？公共服务？库？）。
• v0.x 项目：API 稳定性/兼容性问题 → 最多 minor（semver 预期破坏性变更）。
• 仅本地工具：认证/网络攻击面 → minor（已文档化的约束）。
• 降低不适用于该项目现实的发现。注明校准原因。
• 宁可一个准确的高严重度发现，也不要十个被夸大的。每次误报都会侵蚀对整个审查的信任。

报告前自疑检查

在写下任何发现前，静默做对抗性检查。默认为拒绝：

1. 我能反驳这个吗？ 构建反方论证。"这没问题因为……"
2. 严重度被夸大了吗？ 在第二位审查者审视下能站住脚吗？
3. 这是真实问题还是个人偏好？ "变量名可以更好"不是发现，除非造成真实困惑。

开篇用一行严重度总结：critical: N | major: N | minor: N | nit: N 及采用的路径。

每个发现按严重度排序，格式：

[severity] <标题>  (维度)
location: file:line
issue:  <问题所在及触发的输入/条件>
impact: <破坏什么，或攻击者/用户获得什么>
fix:    <最小具体修复方案>

结尾给出简短总体评估（可合并？有阻断项？）。如果变更确实干净，坦白说明——不人工制造发现。