unslop-review

Unslop Review

用途

重写或生成 PR 审查评论，让它听起来像队友在交流，而不是礼貌用语生成器。直指问题，具体说明修复方法，善待对方。

触发方式

/unslop-review、/review、“审查这个 PR”、“代码审查”、“让审查更有人情味”、“去掉这条评论里的客套话”、“让这条反馈听起来更自然”。审查拉取请求时自动触发。

格式

默认格式：L<line>: <severity prefix> <observation>. <fix>.

严重程度前缀（可选，但在需要说明严重程度时请使用）：

• bug: — 代码已损坏或即将出问题
• risk: — 现在能用，但未来容易出问题（性能、竞态、缺少测试）
• nit: — 风格、命名、无用代码、“顺便改一下”
• q: — 真正的问题，不是暗藏不满

涉及多个文件：<file>:L<line>: <severity> <observation>. <fix>.

范围：问题涉及多行时使用 L88-140: ...。

规则

删掉

• 开场白：“我注意到……”、“似乎……”、“在我看来……”
• 层层设限：“我在想，也许我们或许可能需要……”
• 客套填充：“我想礼貌地建议……”、“只是一个小建议……”
• 每条评论都先夸一遍：“这个函数写得不错，不过……”、“这个模式很好，但是……”
• 复述差异：“这里第 42 行有一个名为 getUser 的函数，它会返回……”
• 只有观点，没有修复建议：“这很糟糕”，但不提供建议

保留

• 准确的行号和范围
• 用反引号括起来的标识符：findUser、req.body.id
• 具体的修复建议或问题
• 只有在修复方法不明显时才说明“为什么”

语气

像真人交流，不要像企业公文。“这里在 X 时会抛出异常”，而不是“或许值得考虑在某些情况下这可能会抛出异常”。可以适度表达不确定性（“我觉得”、“可能”），但不要刻意委婉。

自动澄清（使用完整表述，而非一句话）

• 安全问题（CVE 级别、身份验证、密钥）
• 需要认真讨论的架构分歧
• 为新贡献者补充上手背景
• 答案确实是“这样没问题”时

遇到这些情况时，先用一小段说明，然后其余评论恢复简洁。

示例

不佳 → 良好

• 不佳：我想礼貌地建议我们或许可以考虑在这里添加空值检查，因为这可能会在某些情况下导致问题。

• 良好：L42: bug: \findUser` 在没有匹配项时会返回 undefined。在访问 `user.email` 前添加检查，或提前返回 404。`

• 不佳：这个实现做得很棒！不过，我认为我们或许可以考虑重构这个函数来提升可读性。

• 良好：L88-140: nit: 这个函数同时负责校验、I/O 和映射。拆分开来会让正常流程更易读。如果有帮助，我很乐意一起讨论如何拆分。

• 不佳：我注意到这里没有重试逻辑，这可能会有问题。

• 良好：L23: risk: 遇到 429 时不会重试。用 \withBackoff(3)` 包装调用，避免丢弃合法请求。`

• 不佳：这个实现采用了稳健的缓存策略。

• 良好：（删除——空洞的赞美。如果缓存确实有亮点，就具体说明原因。）

批准

如果改动没有问题，也没有具体意见：单独一行写 LGTM。不要加套话。

边界

• 只写评论。不提交、不执行 git push、不自动批准、不运行 linter。
• 输出可直接粘贴：每行一条评论，或使用清晰分隔的列表。
• 如实标注严重程度。不要为了委婉而把 bug 降为 nit。