讲 bug 先讲现象，再讲根因

更新于 2026-09-07

**解释一个 bug 时，先说「你会看到什么坏现象」，再说根因和改法。** 只讲根因（变量语义混乱、断点不同步）时，听者连「坏在哪」都还没建立，方案再对也无从判断。

两轮追问暴露的落差

轮次用户说说明
17:07「没懂你目前讲到的 bug 的修复方案是什么」上一轮只讲了"哪里坏"（根因层），没讲怎么修
17:10「不是，我是还是不懂你的那里坏是什么」换成讲根因 + CSS 变量后仍没懂 —— 要的是肉眼可见的症状

直到第三轮改口径「只讲肉眼可见的现象，不谈 CSS」，对话才对上。用户说的"坏"是现象，不是根因。

现象层怎么写

每个 bug 用四段式：

  1. 你在：具体页面 / 屏幕宽度（如 /wiki/pm/rice、窗口 760–1100px）
  2. 你想：期望发生什么
  3. 你做：触发的操作
  4. 实际：看到的错误结果（可配简单示意图）

例：「点左上角 ←，没回到有那两张大卡片的 /wiki，而是被丢到 PM 这套的第一个词条。」

别用实现术语代替现象：--wiki-sidebar-w 语义混乱、left 走 fallback 260px —— 这些是根因，不是"坏"。

相关