Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

代码评审

When to Use

适用场景

When the user asks to review code, a PR, a diff, or says "review this", "check my changes", or "is this ready to merge".
当用户要求评审代码、PR、diff，或者说「评审这个」、「检查我的变更」、「这个可以合并了吗」时使用。

Instructions

使用说明

  1. Read the diff or changed files
  2. Evaluate against this checklist:
    • Correctness: Does the code do what it claims? Are edge cases handled?
    • Clarity: Are names descriptive? Is logic easy to follow?
    • Tests: Are new behaviors tested? Are existing tests still valid?
    • Security: Any hardcoded secrets, SQL injection, or unsafe input handling?
    • Performance: Any unnecessary allocations, N+1 queries, or O(n^2) loops?
    • Style: Consistent with the project's existing conventions?
  3. Categorize findings as:
    • Must fix: Bugs, security issues, broken tests
    • Should fix: Unclear naming, missing tests, code smells
    • Nit: Style preferences, minor suggestions
  4. Provide specific line references and concrete suggestions
  5. Acknowledge what was done well
  1. 阅读diff或变更文件
  2. 对照以下清单进行评估：
    • 正确性： 代码是否实现了声称的功能？是否处理了边缘场景？
    • 清晰性： 命名是否具有描述性？逻辑是否容易理解？
    • 测试： 新增行为是否有对应的测试？现有测试是否仍然有效？
    • 安全性： 是否存在硬编码密钥、SQL注入或不安全的输入处理问题？
    • 性能： 是否存在不必要的内存分配、N+1查询或O(n²)循环？
    • 风格： 是否与项目现有规范保持一致？
  3. 将发现的问题分类为：
    • 必须修复： 漏洞、安全问题、测试失效
    • 应该修复： 命名不清晰、缺少测试、代码坏味道
    • 小优化： 风格偏好、次要建议
  4. 提供具体的行号引用和可落地的改进建议
  5. 肯定代码中做得好的部分

Examples

示例

User: "Review my changes" Agent: Reads the diff, then provides structured feedback:
Must fix: 
parse_input()
on line 42 doesn't handle empty strings — this will panic.
Should fix: The variable 
x
on line 15 could be renamed to 
retry_count
for clarity.
Nit: Consider extracting lines 30-45 into a helper function.
Overall: Good separation of concerns. The error handling pattern is clean.
用户：「评审我的变更」 Agent： 读取diff，然后提供结构化反馈：
必须修复： 第42行的
parse_input()
没有处理空字符串——会导致程序崩溃。
应该修复： 第15行的变量
x
可以重命名为
retry_count
以提升可读性。
小优化： 可以考虑将第30-45行的代码抽离为一个辅助函数。
整体评价：关注点分离做得很好，错误处理模式很简洁。