話再多而不在精

你需要提供精確有內容的信息。這並不是要求你簡單的把成堆的出錯代碼或者資料完全轉錄到你的提問中。如果你有龐大而複雜的測試樣例能重現程序掛掉的情境，儘量將它剪裁得越小越好。

信息要足夠，但不要堆砌

“詳細”不等於“把所有東西都貼上來”。日誌、配置、代碼、截圖和錯誤信息都應該經過篩選。你需要保留能支持診斷的事實，刪掉和問題無關的噪聲。

如果問題可以用 20 行代碼復現，就不要貼整個項目。如果錯誤只出現在最後 30 行日誌裡，就不要把幾萬行日誌直接塞進正文。

最小化問題的三個價值

這樣做的用處至少有三點。 第一，表現出你為簡化問題付出了努力，這可以使你得到回答的機會增加； 第二，簡化問題使你更有可能得到有用的答案； 第三，在精煉你的 bug 報告的過程中，你很可能就自己找到了解決方法或權宜之計。

一個實用標準

在發問前問自己：回答者是否能用你給出的材料復現或理解問題，同時又不必在大量無關內容裡搜尋線索？如果不能，就繼續裁剪、整理和標註重點。