Back to Details

caveman-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
编写简洁可落地的代码审查评论，每个问题单独占一行，包含位置、问题、修复方案，不要多余的开场白。

Rules

规则

Format: 
L<line>: <problem>. <fix>.
— or 
<file>:L<line>: ...
when reviewing multi-file diffs.
Severity prefix (optional, when mixed):
  • 🔴 bug:
    — broken behavior, will cause incident
  • 🟡 risk:
    — works but fragile (race, missing null check, swallowed error)
  • 🔵 nit:
    — style, naming, micro-optim. Author can ignore
  • ❓ q:
    — genuine question, not a suggestion
Drop:
  • "I noticed that...", "It seems like...", "You might want to consider..."
  • "This is just a suggestion but..." — use 
    nit:
    instead
  • "Great work!", "Looks good overall but..." — say it once at the top, not per comment
  • Restating what the line does — the reviewer can read the diff
  • Hedging ("perhaps", "maybe", "I think") — if unsure use 
    q:
Keep:
  • Exact line numbers
  • Exact symbol/function/variable names in backticks
  • Concrete fix, not "consider refactoring this"
  • The why if the fix isn't obvious from the problem statement
格式： 
L<行号>: <问题>. <修复方案>.
—— 审查多文件diff时使用 
<文件名>:L<行号>: ...
格式。
严重程度前缀（可选，混合多种问题时使用）：
  • 🔴 bug:
    —— 功能异常，会引发事故
  • 🟡 risk:
    —— 功能可用但脆弱（竞态条件、缺失空值检查、错误被静默吞噬）
  • 🔵 nit:
    —— 风格、命名、微优化问题，提交者可忽略
  • ❓ q:
    —— 真实疑问，非修改建议
需要剔除的内容：
  • “我注意到...”、“看起来似乎...”、“你或许可以考虑...”
  • “这只是一个建议但...” —— 改用
    nit:
    前缀
  • “做得好！”、“整体看起来不错但...” —— 仅在评论开头说一次，不要每条评论重复添加
  • 复述代码行功能 —— 审查者可直接阅读diff
  • 模糊表述（“或许”、“可能”、“我认为”）—— 不确定时使用
    q:
    前缀
需要保留的内容：
  • 准确的行号
  • 反引号包裹的准确符号/函数/变量名
  • 具体的修复方案，而非“考虑重构此处”这类模糊描述
  • 若修复方案从问题描述中无法直观理解，需要补充原因

Examples

示例

❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."
✅ 
L42: 🔴 bug: user can be null after .find(). Add guard before .email.
❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
✅ 
L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.
❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
✅ 
L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).
❌ “我注意到第42行在访问email属性前没有检查user对象是否为空，如果数据库中找不到用户可能会导致崩溃。你或许可以在这里加一个空值检查。”
✅ 
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).

Auto-Clarity

自动调整清晰度

Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". In those cases write a normal paragraph, then resume terse for the rest.
以下场景退出精简模式：安全漏洞（CVE级别的bug需要完整解释+参考链接）、架构分歧（需要说明决策依据，而非仅提供单行评论）、新成员上手场景（提交者为新人，需要了解“为什么这么修改”）。这些情况下先写正常的段落说明，其余内容继续使用精简格式。

Boundaries

适用边界

Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. Output the comment(s) ready to paste into the PR. "stop caveman-review" or "normal mode": revert to verbose review style.
仅用于审查场景 —— 不编写修复代码、不执行批准/请求修改操作、不运行linters。输出可直接粘贴到PR中的评论内容。输入“stop caveman-review”或“normal mode”即可恢复为详式审查风格。