Back to Details

bug-triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Bug triage

Bug 分类与处理

Goal

目标

Turn an ambiguous bug report into:

a reliable repro (or a clear “cannot reproduce yet” with next info to collect)
a root-cause explanation
a minimal, reviewed fix
verification steps (commands + manual checks)

将模糊的Bug报告转化为：

可靠的复现步骤（或明确的“暂无法复现”及需收集的后续信息）
根本原因说明
经过评审的最小化修复方案
验证步骤（命令+人工检查）

First checks

初步检查

Read any repo-specific guidance (
```
AGENTS.md
```
,
```
CONTRIBUTING.md
```
, README).
Clarify impact: severity, who is affected, and whether it’s a regression.

阅读仓库特定指南（
```
AGENTS.md
```
、
```
CONTRIBUTING.md
```
、README）。
明确影响范围：严重程度、受影响人群以及是否为回归问题。

If info is missing, ask for it

若信息缺失，询问用户

Exact steps to reproduce (starting state + inputs).
Expected vs actual behavior.
Error text / stack trace / logs (full, unedited if possible).
Environment: OS, runtime versions (Node/Bun), browser, commit hash/tag.
Frequency: always / sometimes / only certain data.
“Last known good” version or approximate date when it started.

准确的复现步骤（初始状态+输入）。
预期行为与实际行为对比。
错误文本/堆栈跟踪/日志（尽可能完整、未编辑）。
环境信息：操作系统、运行时版本（Node/Bun）、浏览器、提交哈希/标签。
出现频率：总是/有时/仅特定数据下出现。
“最后正常版本”或问题开始出现的大致日期。

Workflow (checklist)

工作流程（检查清单）

Reproduce locally
- Prefer the simplest, fastest repro.
- If it’s flaky, try to reduce nondeterminism (seed, fixed time, retries).
Localize the failure
- Narrow to a file/function/component/config.
- Use
```
rg
```
  to find relevant code paths and error strings.
Identify root cause
- Form a hypothesis, confirm with logs/breakpoints, then refine.
- If it’s a regression and git history exists, consider
```
git bisect
```
  .
Implement the minimal fix
- Fix the cause, not the symptom.
- Avoid drive-by refactors and formatting churn.
Verify
- Run the project’s standard checks (lint/tests/build).
- Re-run the repro steps and confirm the fix.

本地复现
- 优先选择最简单、最快的复现方式。
- 若问题偶发，尝试减少不确定性（设置随机种子、固定时间、重试）。
定位故障点
- 缩小范围至具体文件/函数/组件/配置。
- 使用
```
rg
```
  查找相关代码路径和错误字符串。
确定根本原因
- 提出假设，通过日志/断点验证，然后细化结论。
- 若为回归问题且存在Git历史，可考虑使用
```
git bisect
```
  。
实施最小化修复
- 修复问题根源，而非仅解决表面症状。
- 避免顺带重构和格式变更。
验证
- 运行项目的标准检查（ lint/测试/构建）。
- 重新执行复现步骤，确认修复有效。

Repo-aware command hints

仓库相关命令提示

Use what the repo actually uses:

If
```
bun.lock
```
exists: prefer
```
bun ...
```
(e.g.
```
bun lint
```
,
```
bun build
```
,
```
bun dev
```
).
Otherwise: use the project’s documented commands (
```
npm
```
,
```
pnpm
```
,
```
yarn
```
, etc.).
If
```
bun.lock
```
exists but
```
bun
```
is not available, tell the user and ask whether to install
```
bun
```
or use the repo’s alternative package manager.

使用仓库实际采用的命令：

若存在
```
bun.lock
```
：优先使用
```
bun ...
```
（例如
```
bun lint
```
、
```
bun build
```
、
```
bun dev
```
）。
否则：使用项目文档中记录的命令（
```
npm
```
、
```
pnpm
```
、
```
yarn
```
等）。
若存在
```
bun.lock
```
但未安装
```
bun
```
，告知用户并询问是否安装
```
bun
```
或使用仓库的替代包管理器。

Deliverable (paste this in the chat / PR / issue)

交付物（粘贴至聊天/PR/Issue）

Use this format:

Summary: ...
Repro: ...
Root cause: ...
Fix: ...
Verification: ...
Risk/notes: ...

If you need a bug-report structure to ask the user for, use

references/bug-report-template.md

.

使用以下格式：

摘要： ...
复现步骤： ...
根本原因： ...
修复方案： ...
验证： ...
风险/注意事项： ...

若需要向用户索要Bug报告的结构化内容，可使用

references/bug-report-template.md

。