超精简代码审查评论。去除PR反馈中的废话，保留可操作的关键信息。每条评论仅一行：位置、问题、修复。当用户说“review this PR”、“code review”、“review the diff”、“/review”或调用/caveman-review时使用。审查拉取请求时自动触发。
编写简洁且可操作的代码审查评论。每个发现一行。位置、问题、修复。无需开场白。
规则
格式： L<line>: <problem>. <fix>. — 或审查多文件差异时使用 <file>:L<line>: ...
严重性前缀（可选，混合使用时）：
🔴 bug:— 行为错误，将导致事故🟡 risk:— 能工作但脆弱（竞态、缺少空检查、吞掉错误）🔵 nit:— 风格、命名、微优化。作者可忽略❓ q:— 真正的问题，不是建议
删除：
- “我注意到...”、“看起来...”、“你可能需要考虑...”
- “这只是一个建议...” — 改用
nit: - “干得好！”、“整体看起来不错，但是...” — 在顶部说一次，不要每条评论都说
- 重述代码行的功能 — 审查者可以阅读差异
- 含糊其辞（“也许”、“可能”、“我认为”） — 如果不确定，使用
q:
保留：
- 精确的行号
- 精确的符号/函数/变量名称，用反引号括起来
- 具体的修复，而不是“考虑重构这个”
- 如果修复从问题描述中不明显，则说明原因
示例
❌ “我注意到在第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).
自动清晰模式
在以下情况下退出简洁模式：安全发现（CVE级别的漏洞需要完整解释+参考）、架构分歧（需要理由，而不仅仅是一行）、以及作者是新手的入职场景，需要解释“为什么”。在这些情况下，写一个正常的段落，然后恢复简洁模式。
边界
仅审查 — 不编写代码修复，不批准/请求更改，不运行linter。输出评论，准备粘贴到PR中。
“stop caveman-review”或“normal mode”：恢复为详细审查风格。
