rockscy Bug from User / 用户反馈转 Bug
When to use
- A user has reported a problem in prose (email, Discord, Twitter DM, support ticket).
- The dev cannot tell from the message:
- what was expected vs. what actually happened
- the steps to reproduce
- whether it's a real bug, user error, or a feature request in disguise
- The dev wants a GitHub issue or internal note they can later sit down and fix.
When NOT to use
- The user has already produced a clean, reproducible report. Don't re-process it.
- The complaint is subjective ("it's slow", "it's ugly") with no measurable claim — that's a UX or perf investigation, not a bug.
- The user is asking for a feature (e.g. "can you add X?") — file as feature request, not bug.
The four-question conversion
For any prose complaint, reduce it to:
- Trigger — what did the user do (action, click, command, input)?
- Expected — what did they expect to happen?
- Actual — what actually happened?
- Surface — where did it happen (URL, screen, version, browser, OS)?
If any of the four is missing, flag it as a follow-up question rather than guessing.
Output format
### Bug: <one-sentence headline, user-perspective>
**Trigger:**
1. <step>
2. <step>
**Expected:** <what they expected>
**Actual:** <what actually happened>
**Surface:** <version / browser / OS / URL>
**Confidence:** <high | medium | low>
- high: report is self-contained, can repro from this alone
- medium: 1–2 reasonable assumptions made
- low: significant guessing — ask user to confirm
**Follow-ups (if any):**
- <question to ask the user>
Worked example
Input (raw user email):
"hey i tried buying the pro plan tonight and the website just kept loading forever, i refreshed a few times then gave up. using safari on my macbook"
Output:
### Bug: Pro plan checkout hangs on Safari (macOS)
**Trigger:**
1. Visit pricing page on Safari (macOS).
2. Click "Pro plan" purchase button.
3. Observe checkout flow.
**Expected:** Stripe checkout opens within a few seconds.
**Actual:** Page stays in loading state indefinitely; refresh does not recover.
**Surface:** Safari on macOS. Version of Safari and macOS unknown. Pricing page URL unknown (likely /pricing).
**Confidence:** medium
- Assumed pricing page URL is /pricing.
- Assumed checkout uses Stripe.
**Follow-ups:**
- Which Safari version + macOS version?
- Does Chrome on the same machine reproduce it?
- Browser console errors (if comfortable opening DevTools)?
Anti-patterns to avoid
- Don't assume severity — "P0 outage" without evidence is alarmist.
- Don't guess root cause in the report — that's the dev's job after reading. The report describes symptoms.
- Don't promise a fix timeline — that goes in the reply email, not the bug report.
中文版
何时使用
- 用户用散文报了一个问题（邮件、Discord、推特 DM、工单）。
- 看不出：
- 期望 vs 实际
- 复现步骤
- 是真 bug、用户操作问题、还是变相的功能请求
何时不使用
- 用户已经写好了清晰可复现的报告——别重新加工。
- 抱怨是主观的（"慢"、"丑"），没有可测指标——那是 UX/性能调研，不是 bug。
- 用户是要功能——按 feature request 处理。
四问转化法
把任何散文压成 4 个问题：
- 触发——用户做了什么动作？
- 期望——他们期望发生什么？
- 实际——实际发生了什么？
- 环境——在哪里发生（URL、屏幕、版本、浏览器、系统）？
任意一项缺失 → 列为待问，不要猜。
输出
### Bug: <一句话标题，用户视角>
**触发：**
1. <步骤>
2. <步骤>
**期望：** <…>
**实际：** <…>
**环境：** <…>
**置信度：** <high | medium | low>
**待问：**
- <…>
反模式
- 不要乱定优先级——没证据就"P0"是恐慌。
- 不要在报告里猜根因——根因是开发读完之后的事，报告只描述现象。
- 不要承诺修复时间——那写在回复邮件里，不写在 bug 单里。