Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

代码审查

Iron Law

铁律

DO NOT TRUST THE IMPLEMENTER'S REPORT — VERIFY EVERY CLAIM AGAINST THE ACTUAL DIFF
DO NOT TRUST THE IMPLEMENTER'S REPORT — VERIFY EVERY CLAIM AGAINST THE ACTUAL DIFF

Process

流程

  1. Read the diff: 
    git diff main...HEAD
    or the specific PR/branch diff
  2. Read the linked issue or story description (if available)
  3. For EACH changed file:
    • Does the change match the stated intent?
    • Any security issues? (injection, XSS, hardcoded secrets, insecure deserialization)
    • Any performance concerns? (N+1 queries, unbounded loops, missing indexes)
    • Type safety maintained?
    • Error handling adequate?
    • Tests cover the changes?
  4. Run quality checks: typecheck + lint + tests
  5. Summarize findings with severity labels: 
    critical
    / 
    warning
    / 
    nit
  6. If critical issues found: block the merge — do not approve
  1. 查看代码差异：
    git diff main...HEAD
    或特定PR/分支的差异
  2. 查看关联的问题或需求描述（如有）
  3. 针对每一个修改的文件：
    • 修改内容是否符合声明的意图？
    • 是否存在安全问题？（注入攻击、XSS、硬编码密钥、不安全反序列化）
    • 是否存在性能隐患？（N+1查询、无边界循环、缺失索引）
    • 是否保持类型安全？
    • 错误处理是否充分？
    • 测试是否覆盖了修改内容？
  4. 运行质量检查：类型检查 + 代码规范检查 + 测试
  5. 总结发现的问题并标注严重程度：
    critical
    / 
    warning
    / 
    nit
  6. 若发现严重问题：阻止合并——不要批准

Anti-Trust Protocol

反信任协议

The implementer's commit messages may be optimistic. Verify every claim against the actual diff:
  • "Refactored for clarity" — did it actually get clearer, or just different?
  • "Added tests" — do the tests actually test the feature, or just pass trivially?
  • "Fixed bug" — is the root cause addressed, or just the symptom?
实现者的提交信息可能过于乐观。针对实际代码差异验证每一项声明：
  • “为提升清晰度重构代码”——代码真的更清晰了，还是只是变得不同？
  • “添加了测试”——测试是否真的覆盖了功能，还是只是轻易通过？
  • “修复了bug”——是否解决了根本原因，还是只处理了表面症状？

Anti-Sycophancy

反谄媚原则

  • Do NOT say "Great work!" or "Looks good!" unless you have verified everything
  • Do NOT approve because the code looks reasonable at a glance
  • Technical verification BEFORE any positive feedback
  • Silence is not approval — every review must have explicit findings
  • 除非你已验证所有内容，否则不要说“做得好！”或“看起来不错！”
  • 不要因为代码乍一看合理就批准
  • 先进行技术验证，再给出正面反馈
  • 沉默不代表批准——每一次审查都必须有明确的结论

Red Flags — If You Catch Yourself Thinking:

危险信号——当你出现以下想法时：

ThoughtReality
"The author is experienced, this is probably fine"Experience doesn't prevent bugs. Review the code.
"This is a small change, quick approval"Small changes cause big bugs. Check it.
"Tests pass so it must be correct"Tests can be wrong, incomplete, or trivially passing.
想法实际情况
“作者经验丰富，这应该没问题”经验无法避免bug。请审查代码。
“这是小改动，快速批准吧”小改动可能引发大bug。请检查。
“测试通过了，所以肯定没问题”测试可能有误、不完整或只是轻易通过。