caveman-review

代码评审评论应简洁且可执行。每条发现占一行。包括位置、问题和修复方案。不要有任何铺垫。

规则

格式： L<line>: <problem>. <fix>.，在评审多文件 diff 时使用 <file>:L<line>: ...。

严重程度前缀（可选，混合使用时）：

• 🔴 bug: — 行为错误，会引发事故
• 🟡 risk: — 能运行但脆弱（竞态、缺少 null 检查、吞掉错误）
• 🔵 nit: — 风格、命名、微优化。作者可忽略
• ❓ q: — 真正的问题，而非建议

删除以下内容：

• "I noticed that..."、"It seems like..."、"You might want to consider..."
• "This is just a suggestion but..."——改用 nit:
• "Great work!"、"Looks good overall but..."——只在开头说一次，不要每条评论都说
• 重复该行做了什么——评审者自己能读 diff
• 模棱两可的措辞（"perhaps"、"maybe"、"I think"）——不确定时使用 q:

保留：

• 精确的行号
• 精确的符号、函数、变量名，用反引号包裹
• 具体的修复方案，而不是"考虑重构这里"
• 如果从问题描述看不出修复方式，保留原因

示例

❌ "我注意到第 42 行在访问 email 属性之前没有检查 user 对象是否为 null。如果数据库中找不到该用户，这可能会导致崩溃。你可能需要在这里加一个 null 检查。"

✅ L42: 🔴 bug: user can be null after .find(). Add guard before .email.

❌ "这个函数做了太多事情，拆分成更小的函数可能会提高可读性。"

✅ L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.

❌ "你有没有考虑过 API 返回 429 时会怎样？我觉得我们应该处理这种情况。"

✅ L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).

自动清晰模式

以下情况取消简洁模式：安全问题（CVE 级别的缺陷需要完整说明并附参考）、架构分歧（需要理由，不能只是一行）、以及新人入职场景，即作者是新手且需要"为什么"。这些情况下先写一段正常段落，其余部分再恢复简洁。

边界

仅做评审——不编写代码修复，不批准或请求修改，不运行 linter。输出可直接粘贴到 PR 中的评论。"stop caveman-review"或"normal mode"：恢复为详细的评审风格。