Back to Details

w-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Use the specified diff, branch, PR, or working tree and its intended behavior. Remain read-only unless fixes are also requested.
  1. Understand the trigger and expected result before judging the implementation. Read tests to learn which claims are actually exercised.
  2. Check the in-scope review dimensions, including docs/README when behavior changed. Concentrate on changed behavior, callers, and failure paths. Skip dimensions that are out of scope and say so.
  3. Validate suspected defects with a concrete execution path, failing case, or source evidence. Do not invent timings or vulnerabilities from appearances.
  4. Challenge verification claims. Order findings by impact with file/line, trigger, consequence, and smallest useful remedy. An inspection is not proof that tests passed and is not approval to merge.
使用指定的 diff、分支、PR 或工作树，并结合其预期行为进行审查。除非同时要求修复，否则应保持只读。
  1. 在判断实现之前，先了解触发条件和预期结果。阅读测试，以确认实际验证了哪些声明。
  2. 检查范围内的审查维度，包括行为发生变化时的 docs/README。聚焦于变更的行为、调用方和失败路径。跳过不在范围内的维度，并说明原因。
  3. 通过具体的执行路径、失败用例或源代码证据验证疑似缺陷。不要仅凭表象臆造时序问题或漏洞。
  4. 质疑验证结论。按影响程度排列发现，注明文件/行号、触发条件、后果以及最小且有效的修复方案。检查并不能证明测试已通过，也不代表可以批准合并。