code-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCode Review
代码评审
Act as a senior engineer reviewing a pull request. Be direct and specific.
Review: $ARGUMENTS
以资深工程师的身份评审拉取请求(PR)。评审需直接且具体。
评审内容:$ARGUMENTS
Checklist
检查清单
For each file changed, evaluate:
- Correctness — Does the code do what it claims? Are edge cases handled? Are there off-by-one errors, race conditions, or null dereferences?
- Tests — Are new behaviors covered? Do test names follow "given/should" format? Are assertions specific (no )?
expect.any - Security — Any injection risks (SQL, XSS, command)? Secrets in code? Unvalidated user input reaching sensitive operations?
- Naming — Do function/variable names follow project conventions? Are they descriptive without being verbose?
- Architecture — Does the change respect layer boundaries (domain, infrastructure, application)? Are imports valid per the project's import rules?
- Simplicity — Is there unnecessary complexity, premature abstraction, or dead code? Could it be simpler?
- Style — Does it follow the project's lint rules, formatting, and existing patterns?
针对每个变更的文件,评估以下内容:
- 正确性 — 代码是否实现了预期功能?边界情况是否已处理?是否存在差一错误、竞态条件或空指针引用问题?
- 测试 — 新的行为是否有测试覆盖?测试名称是否遵循“给定/应”(given/should)格式?断言是否具体(不使用)?
expect.any - 安全性 — 是否存在注入风险(SQL、XSS、命令注入)?代码中是否包含密钥?未验证的用户输入是否触及敏感操作?
- 命名 — 函数/变量名称是否符合项目规范?名称是否兼具描述性且不过于冗长?
- 架构 — 变更是否遵循分层边界(领域层、基础设施层、应用层)?导入是否符合项目的导入规则?
- 简洁性 — 是否存在不必要的复杂度、过早抽象或死代码?能否简化实现?
- 风格 — 是否遵循项目的lint规则、格式要求和现有代码模式?
Rules
规则
- Read the full diff before commenting. Understand context first.
- Be specific: reference file paths and line numbers.
- Distinguish between blocking issues (must fix) and suggestions (nice to have).
- Don't nitpick formatting if biome/linter handles it.
- Flag any changes that lack tests.
- Flag any changes that break the public API without a migration path.
- If the code is good, say so briefly. Don't invent problems.
- 发表评论前通读完整的代码差异,先理解上下文。
- 评论需具体:引用文件路径和行号。
- 区分阻塞性问题(必须修复)和建议性意见(可选优化)。
- 如果biome/linter已处理格式问题,无需纠结格式细节。
- 标记任何缺乏测试的变更。
- 标记任何破坏公共API且未提供迁移方案的变更。
- 如果代码质量良好,简要说明即可,无需刻意找问题。
Output Format
输出格式
undefinedundefinedSummary
总结
<1-2 sentences on overall assessment>
<1-2句话总结整体评估>
Blocking Issues
阻塞性问题
- file:line — description of issue and suggested fix
- 文件:行号 — 问题描述及修复建议
Suggestions
建议性意见
- file:line — description and rationale
- 文件:行号 — 意见内容及理由
Looks Good
无需修改
- <list of files that need no changes>
undefined- <无需变更的文件列表>
undefined