hui-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<行号>: <问题>. <修复方案>.

— 审查多文件差异时使用

<文件名>:L<行号>: ...

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

```
🔴 bug:
```
— 行为异常，会引发故障
```
🟡 risk:
```
— 功能可用但存在隐患（竞态条件、缺失空值检查、错误被吞）
```
🔵 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...” — 在开头说一次即可，不要每条评论都加
重复代码行的功能描述——审核者可以直接查看差异
模糊表述（“perhaps”、“maybe”、“I think”）——若不确定请使用
```
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对象是否为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).

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级别的漏洞需要完整解释+参考资料）、架构分歧（需要说明理由，而非仅用一行表述）、以及作者是新人需要了解“原因”的入职场景。这些情况下请撰写正常段落，其余内容恢复精简模式。

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 hui-review" or "normal mode": revert to verbose review style.

仅负责审查——不编写代码修复方案，不进行批准/请求修改操作，不运行代码检查工具。输出的评论可直接粘贴到PR中。输入“stop hui-review”或“normal mode”可恢复 verbose 审查风格。