peer-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Peer Review

同行评审

Step 1: Gather context

步骤1：收集背景信息

Read everything relevant before analyzing:

Requirements: the spec, ticket, or PR description defining what must be built
Plan: the implementation plan, design doc, or proposed changes
Code: the actual implementation, diff, or relevant source
Contracts: OpenAPI/protobuf/API docs;
```
package.json
```
/
```
requirements.txt
```
/
```
Cargo.toml
```
for related libs
History: related bugs, incidents, or post-mortems
Tests: existing test files for current coverage

在分析前阅读所有相关资料：

需求：定义需构建内容的规格说明、工单或PR描述
计划：实施计划、设计文档或拟议变更
代码：实际实现、差异文件或相关源代码
契约：OpenAPI/protobuf/API文档；相关库的
```
package.json
```
/
```
requirements.txt
```
/
```
Cargo.toml
```
历史记录：相关漏洞、事件或事后分析报告
测试：现有测试文件及当前测试覆盖率

Step 2: Analyze against requirements

步骤2：对照需求分析

Compare the plan to the requirements. Check completeness, edge cases (boundaries, empty inputs, max values, races), error states and rollback, failure modes (a downstream service down/slow/returning garbage), hidden ordering or version conflicts, performance (N+1, unbounded loops, leaks), security (input validation, auth, secrets, data integrity), and test adequacy.

Focus on what is most likely to cause failure, not every theoretical issue.

将计划与需求进行对比。检查完整性、边缘情况（边界值、空输入、最大值、竞态条件）、错误状态与回滚机制、故障模式（下游服务宕机/缓慢/返回无效数据）、隐藏的顺序或版本冲突、性能问题（N+1查询、无限循环、内存泄漏）、安全性（输入验证、身份认证、密钥管理、数据完整性）以及测试充分性。

重点关注最可能导致失败的因素，而非所有理论上的问题。

Step 3: Write the review

步骤3：撰写评审报告

Exactly four sections. Maximum clarity, minimum words.

严格包含四个部分。力求清晰简洁，用词精炼。

Critical Risk

关键风险

One paragraph naming the single thing most likely to cause failure, why it is dangerous and under what conditions it breaks. Pick the highest-impact, most probable one; do not list several.

用一段文字说明最可能导致失败的单一因素，阐述其危险性及触发故障的条件。选择影响最大、概率最高的风险，不得罗列多个。

Other Gaps

其他不足

Bulleted secondary issues, one line each, formatted

- <issue> → <impact>

. Only real, material issues, no nitpicks or theoretical concerns.

用项目符号列出次要问题，每项一行，格式为

- <问题> → <影响>

。仅包含真实的实质性问题，不涉及细微瑕疵或理论性担忧。

Fix

修复方案

Numbered, concrete, actionable steps that address the critical risk only.

列出针对仅关键风险的具体、可执行的编号步骤。

Verdict

结论

One sentence, exactly one of: "Ship it." / "Fix the critical risk first, then ship." / "Needs rework." No explanation.

一句话，必须是以下三者之一："可发布。" / "先修复关键风险，再发布。" / "需要重新修改。"无需解释。

Step 4: Update the plan

步骤4：更新计划

Apply the Fix steps to the plan files directly, the smallest change that mitigates the critical risk. Report which files changed and the fix applied.

直接将修复步骤应用到计划文件中，以最小的变更缓解关键风险。报告修改的文件及应用的修复内容。

Style

风格要求

Concrete language only. No vague warnings ("be careful with X").
Back every claim with evidence from what you read.

仅使用具体表述。禁止模糊警告（如"注意X事项"）。
所有观点均需基于阅读到的资料提供证据。