名称: 审查评论 描述: 使用常规评论格式生成结构良好的代码审查评论。帮助在拉取请求中提供清晰、可操作的反馈。 参数提示: [描述问题或观察] 允许工具: 读取、询问用户问题
代码审查评论生成器
使用常规评论格式生成建设性的代码审查评论，以提高清晰度和专业性。
说明
基于用户对问题或观察的描述，生成格式良好的代码审查评论。
第一步：理解问题
询问用户：
- 问题或观察是什么？ - 他们在代码中注意到了什么？
- 上下文 - 这涉及哪个文件/函数/行？
- 严重性 - 这是阻塞的（必须修复）还是非阻塞的（可有可无）？
- 建议修复 - 他们有推荐吗？（可选）
如果用户已经提供了此信息，则直接生成评论。
第二步：分类评论
确定适当的标签：
| 标签 | 使用时… |
|---|---|
praise |
突出显示做得好的事情 |
nitpick |
次要的风格或偏好问题 |
suggestion |
改进想法，非必需 |
issue |
需要修复的 bug 或问题 |
question |
需要澄清或理解 |
thought |
分享观点，无需行动 |
确定装饰：
(blocking)- 合并前必须修复(non-blocking)- 可选，作者可以忽略(if-minor)- 仅当是快速修复时
第三步：生成评论
格式：[标签] (装饰): [主题]
## 审查评论
**标签:** [标签]
**装饰:** (阻塞/非阻塞)
**位置:** [文件:行，如果已知]
---
### 评论
**[标签] ([装饰]):** [简短主题行]
[解释为什么这很重要]
[如果适用，建议修复]
---
### 替代措辞
如果您希望不同的语气选项：
**更直接：**
> [直接版本]
**更温和：**
> [更温和版本]
---
### 提示
- [任何关于这可能如何被接收的上下文]
- [如果作者不同意时的替代方法]
示例
示例 1: Bug
用户输入: “他们没有处理用户不存在时的空值”
生成评论:
**issue (blocking):** 当用户未找到时的空指针异常
`getUserById` 在用户不存在时可以返回 `undefined`，但我们直接访问 `.name` 而没有检查。
这将导致应用程序在有人尝试查找已删除用户时崩溃。
**建议修复:**
```javascript
const user = getUserById(id);
if (!user) {
throw new UserNotFoundError(id);
}
return user.name;
```
示例 2: 挑剔
用户输入: “变量名有点模糊”
生成评论:
**nitpick (non-blocking):** 考虑更描述性的变量名
`x` 和 `tmp` 没有传达这些值代表什么。像 `userCount` 和 `pendingRequests` 这样的名称将使这一目了然。
如果您喜欢保持原样，无需行动 - 只是一个可读性的想法。
示例 3: 表扬
用户输入: “非常干净的错误处理”
生成评论:
**praise:** 优秀的错误处理覆盖
喜欢您如何明确处理每个错误案例并提供有意义的错误消息。这将使调试生产问题更容易得多。可重试错误与致命错误的分离尤其好。
语气校准
生成的评论应该：
- 关注代码，而不是人
- 解释非显而易见反馈的“原因”
- 在指出问题时包含建议
- 使用协作语言（“我们”、“让我们”、“考虑”）
相关资源
code-review-communicationskill - 代码审查的完整框架references/conventional-comments.md- 完整的标签分类法