review-changes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review Changes

审查代码变更

Review changed code with explicit severity and confidence.

对变更后的代码进行审查，并明确标注严重程度和置信度。

Process

流程

Follow this sequence to produce a thorough, efficient review:

Understand intent. Read the PR description, commit messages, and any linked issues. Know what the change is trying to do before judging how well it does it.
Scan for scope. Skim the full diff to understand what areas it touches — files, modules, layers. This determines which lenses to load.
Select lenses. Use the table below to pick the relevant reviewer lenses. Load only what applies; skip the rest.
Review each file. Walk the diff file by file. Pull in adjacent unchanged code only when it is necessary to explain impact or verify whether an issue is real.
Synthesize. After the file-by-file pass, look for groupable root causes. Multiple symptoms in different files may share one underlying problem — present those as a grouped finding instead of separate entries.
Write up findings using the format and presentation rules below.
Produce a verdict in the summary section.

遵循以下步骤以生成全面、高效的审查结果：

理解意图：阅读PR描述、提交信息以及所有关联的议题。在评判变更的优劣之前，先明确该变更想要实现的目标。
扫描范围：快速浏览完整的代码差异，了解变更涉及的范围——包括文件、模块、层级。这将决定需要启用哪些审查视角。
选择审查视角：使用下方表格选择相关的审查视角。仅启用适用的视角，跳过无关项。
逐文件审查：逐个文件检查代码差异。仅当需要解释影响或验证问题是否真实存在时，才参考相邻的未变更代码。
归纳总结：完成逐文件审查后，寻找可归类的根本原因。不同文件中的多个症状可能源于同一个潜在问题——将这些问题作为一组发现呈现，而非单独条目。
撰写审查发现：使用下方的格式和展示规则进行撰写。
给出最终结论：在总结部分给出审查结论。

Lens Selection

审查视角选择

Use this table to decide which lenses to load based on what the diff touches. Readability is always worth loading as a baseline.

If the diff touches…	Load these lenses
User input, auth, networking, secrets	Security
Public APIs, module boundaries	Architecture
CLI output, error messages, defaults	UX
Hot paths, loops, queries, large data	Performance
New features, bug fixes, branching logic	Tests
Docs, README, docstrings, examples	Documentation
Existing GitHub review comments	GitHub review threads
Anything else	Readability (always on)

根据代码差异涉及的内容，使用下方表格决定启用哪些审查视角。可读性视角作为基础视角，始终需要启用。

若代码差异涉及…	启用以下审查视角
用户输入、认证、网络、敏感信息	安全
公共API、模块边界	架构
CLI输出、错误信息、默认配置	用户体验
热点路径、循环、查询、大数据	性能
新功能、bug修复、分支逻辑	测试
文档、README、文档字符串、示例	文档
已有的GitHub审查评论	GitHub审查线程
其他任何内容	可读性（始终启用）

Scope

审查范围

Focus on the changed code and behavior introduced by the diff. Pull in adjacent unchanged code only when it is necessary to explain impact or verify whether an issue is real.

聚焦于代码差异带来的变更代码和行为变化。仅当需要解释影响或验证问题是否真实存在时，才参考相邻的未变更代码。

Rating

评级规则

Rate impact separately from certainty.

Severity	Emoji	Meaning
P1	🔴	Critical: security flaws, data loss, crashes, or release blockers
P2	🟠	Important: broken features, serious regressions, or major correctness gaps
P3	🟡	Should fix: smaller bugs, coverage gaps, or usability problems
P4	⚪	Nice to have: low-impact polish or consistency issues

Report findings with confidence ≥ 80. For findings between 60–79, mention them briefly in a "Lower-confidence observations" section at the end, clearly marked as uncertain. Below 60, drop them entirely.

将影响程度与置信度分开评级。

严重程度	表情符号	含义
P1	🔴	关键：安全漏洞、数据丢失、程序崩溃或发布阻塞问题
P2	🟠	重要：功能失效、严重退化或主要正确性缺陷
P3	🟡	建议修复：小型bug、测试覆盖缺口或可用性问题
P4	⚪	优化建议：低影响的细节完善或一致性问题

仅报告置信度≥80%的发现。对于置信度在60-79%之间的发现，在末尾的“低置信度观察”部分简要提及，并明确标注为不确定。置信度低于60%的发现直接忽略。

Finding Format

审查发现格式

Each finding must include:

```
File
```
: location with line numbers
```
Issue
```
: one-sentence problem statement
```
Reasoning
```
: why the behavior is wrong or risky
```
Evidence
```
: concrete code, types, behavior, or reviewer comment
```
Suggestion
```
: a specific fix or next action

Use this header format:

markdown

undefined

每个审查发现必须包含：

```
文件
```
: 位置及行号
```
问题
```
: 一句话概括的问题描述
```
原因
```
: 说明该行为错误或存在风险的理由
```
证据
```
: 具体的代码、类型、行为或审查评论
```
建议
```
: 具体的修复方案或下一步行动

使用以下标题格式：

markdown

undefined

🟠 P2 · 🛡️ SEC-1 · Missing authorization check · 92%

🟠 P2 · 🛡️ SEC-1 · 缺失权限校验 · 92%


Use these prefixes:

- `SEC`: security
- `ARC`: architecture
- `TST`: tests
- `UXD`: user experience
- `RDY`: readability
- `DOC`: documentation
- `PRF`: performance
- `GIT`: GitHub review feedback

Use these category icons when presenting a review summary:

| Prefix | Emoji | Category         |
| ------ | ----- | ---------------- |
| `SEC`  | 🛡️    | security         |
| `ARC`  | 🏗️    | architecture     |
| `TST`  | 🧪    | tests            |
| `UXD`  | 🎨    | user experience  |
| `RDY`  | 👁️    | readability      |
| `DOC`  | 📖    | documentation    |
| `PRF`  | 🚀    | performance      |
| `GIT`  | 💬    | GitHub feedback  |
| `GRP`  | 📦    | grouped findings |


使用以下前缀：

- `SEC`: 安全
- `ARC`: 架构
- `TST`: 测试
- `UXD`: 用户体验
- `RDY`: 可读性
- `DOC`: 文档
- `PRF`: 性能
- `GIT`: GitHub审查反馈

在展示审查总结时使用以下分类图标：

| 前缀 | 表情符号 | 分类         |
| ------ | ----- | ---------------- |
| `SEC`  | 🛡️    | 安全         |
| `ARC`  | 🏗️    | 架构     |
| `TST`  | 🧪    | 测试            |
| `UXD`  | 🎨    | 用户体验  |
| `RDY`  | 👁️    | 可读性      |
| `DOC`  | 📖    | 文档    |
| `PRF`  | 🚀    | 性能      |
| `GIT`  | 💬    | GitHub反馈  |
| `GRP`  | 📦    | 分组发现 |

Review Presentation

审查结果展示

When summarizing findings for a human, present them in an emoji-led format:

text

{severity_emoji} {severity} · {category_emoji} {id} · {title} ({confidence}%) · {file}:{line}

Examples:

text

🔴 P1 · 🛡️ SEC-1 · SQL injection vulnerability (95%) · src/db.ts:45
🟠 P2 · 🏗️ ARC-1 · Circular dependency (88%) · src/modules/a.ts:12
🟡 P3 · 🧪 TST-2 · Missing edge case test (82%) · tests/api.test.ts:78

For GitHub findings, append the author when available:

text

🟠 P2 · 💬 GIT-1 · Consider using constants (90%) · src/config.ts:23 (@reviewer)

If multiple findings collapse into one root cause, you may present a grouped summary:

text

╭──────────────────────────────────────────────────────────────────────────╮
│ 🟠 P2 · 📦 GRP-1 · Inconsistent error handling (3 findings)              │
╰┬─────────────────────────────────────────────────────────────────────────╯
 ├─ 🟠 P2 · 👁️ RDY-1 · Missing error check (85%) · src/api.ts:23
 ├─ 🟡 P3 · 👁️ RDY-2 · Silent failure (82%) · src/api.ts:45
 └─ 🟡 P3 · 👁️ RDY-3 · No error logging (80%) · src/api.ts:67

Sort summaries by severity first, then by confidence. Include a legend when the review is long enough that readers would benefit from one.

向人工展示审查总结时，使用以下表情符号引导的格式：

text

{严重程度表情} {严重程度} · {分类表情} {编号} · {标题} ({置信度}%) · {文件}:{行号}

示例：

text

🔴 P1 · 🛡️ SEC-1 · SQL注入漏洞 (95%) · src/db.ts:45
🟠 P2 · 🏗️ ARC-1 · 循环依赖 (88%) · src/modules/a.ts:12
🟡 P3 · 🧪 TST-2 · 缺失边缘场景测试 (82%) · tests/api.test.ts:78

对于GitHub相关的发现，若有作者信息则补充在末尾：

text

🟠 P2 · 💬 GIT-1 · 建议使用常量 (90%) · src/config.ts:23 (@reviewer)

若多个发现源于同一个根本原因，可以分组展示总结：

text

╭──────────────────────────────────────────────────────────────────────────╮
│ 🟠 P2 · 📦 GRP-1 · 错误处理不一致（3项发现）              │
╰┬─────────────────────────────────────────────────────────────────────────╯
 ├─ 🟠 P2 · 👁️ RDY-1 · 缺失错误检查 (85%) · src/api.ts:23
 ├─ 🟡 P3 · 👁️ RDY-2 · 静默失败 (82%) · src/api.ts:45
 └─ 🟡 P3 · 👁️ RDY-3 · 无错误日志 (80%) · src/api.ts:67

首先按严重程度排序，再按置信度排序。若审查内容较长，可添加图例以方便读者理解。

Actionability

可执行性要求

Prefer findings that are specific, reproducible, and cheap enough to act on in the current change. Cap output at roughly 8 findings for a normal-sized diff — prioritize ruthlessly rather than dumping everything.

Avoid:

Speculative concerns without concrete evidence in the diff.
Style preferences that linters or formatters already enforce.
Suggesting rewrites of working code unless there's a clear maintainability or correctness risk.
Flagging pre-existing TODO/FIXME comments that aren't part of this change.
Issues outside the review scope (e.g., unrelated files, hypothetical future requirements).

优先选择具体、可复现且在当前变更中易于处理的发现。对于普通规模的代码差异，审查发现的数量控制在约8个以内——要严格筛选优先级，而非罗列所有问题。

避免：

无具体证据的推测性担忧。
代码检查工具或格式化工具已能处理的风格偏好问题。
建议重写可正常运行的代码，除非存在明确的可维护性或正确性风险。
标记不属于本次变更的已有TODO/FIXME注释。
超出审查范围的问题（例如无关文件、假设的未来需求）。

Summary

审查总结

End every review with:

A bordered summary that includes only the severity counts.
A verdict label.
One to three short, action-oriented bullets that explain the TL;DR.

Use this format:

markdown

╭───────────────────────────────────────────╮
│ 🔴 P1: 0   🟠 P2: 1   🟡 P3: 2   ⚪ P4: 1 │
╰───────────────────────────────────────────╯
**Needs changes**:
- Fix the inconsistent error handling in `src/api.ts`, `src/jobs.ts`, and `src/worker.ts`.
- Add a retry-path test so this regression does not recur.
- Merge after the P2 issue is resolved.

The verdict label should be one of:

Ship it: no findings, or only P4 nits.
Ship with fixes: P3 or below; nothing blocking.
Needs changes: at least one P2 that should be resolved before merge.
Blocked: at least one P1; do not merge.

Write the bullets as a call to action. Prefer concrete next steps over vague summaries.

Good:

Add the missing authorization check in the admin route.

Update the docs to mention the new default timeout.

Merge after the flaky retry test is fixed.

Avoid:

```
Authorization issue.
```
```
Docs need work.
```
```
Some tests are missing.
```

If cross-cutting themes emerged (for example, "error handling is inconsistent across three files"), use one bullet to name the theme and the remaining bullets to say what should happen next.

每份审查必须以以下内容结尾：

一个包含严重程度统计的带边框总结。
一个结论标签。
1-3条简短、面向行动的要点，说明核心结论。

使用以下格式：

markdown

╭───────────────────────────────────────────╮
│ 🔴 P1: 0   🟠 P2: 1   🟡 P3: 2   ⚪ P4: 1 │
╰───────────────────────────────────────────╯
**需要修改**:
- 修复`src/api.ts`、`src/jobs.ts`和`src/worker.ts`中的错误处理不一致问题。
- 添加重试路径测试，避免此类退化问题再次发生。
- 解决P2问题后方可合并。

结论标签必须为以下之一：

直接合并：无审查发现，或仅存在P4级别的小问题。
修复后合并：仅存在P3及以下级别问题；无阻塞性问题。
需要修改：存在至少一个P2级别问题，需在合并前解决。
禁止合并：存在至少一个P1级别问题；不可合并。

要点需以行动指令的形式撰写。优先使用具体的下一步行动，而非模糊的总结。

正面示例：

在管理员路由中添加缺失的权限校验。

更新文档，提及新增的默认超时时间。

修复不稳定的重试测试后再合并。

反面示例：

```
权限问题。
```
```
文档需要完善。
```
```
部分测试缺失。
```

若出现跨文件的共性问题（例如“三个文件中的错误处理不一致”），可使用一个要点点明该共性问题，其余要点说明具体的下一步行动。

Reviewer Lenses

审查视角详情

Load only the lenses that matter for the current diff:

architecture
documentation
GitHub review threads
performance
readability
security
tests
user experience

仅启用与当前代码差异相关的审查视角：

架构
文档
GitHub审查线程
性能
可读性
安全
测试
用户体验