《提問的智慧》精讀注解版

今天我又讀了一遍《提》，作為一個開源項目的維護者，感慨萬千。下文是我對《提》的 部分 注解，如果你時間有限，可以通過該注解版進行有限的了解。但還是強烈建議你精讀一遍《提問的智慧》，英語好的同學可直接看原文 How To Ask Questions The Smart Way。

• 來源于： https://hacpai.com/article/1536377163156
• Github：詳情
• 官方原文： http://www.catb.org/~esr/faqs/smart-questions.html

下面按照原文章節進行注解，標題即原文章節標題。再次說明，我僅僅是注解了《提》中的部分內容，有時間的話請一定要看原文。

作者：88250
鏈接：https://hacpai.com/article/1536377163156
來源：黑客派
協議：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

簡介

讀懂該小節需要理解什么是“黑客”，我想能看到我寫的文字的人應該都明白黑客是什么。當然，如果這也算一個問題的話可按《提》的方法獲得答案。

黑客們喜愛有挑戰性的問題，或者能激發他們思維的好問題。…… 好問題可以提高我們的理解力，而且通常會暴露我們以前從沒意識到或者思考過的問題。對黑客而言，"好問題！" 是誠摯的大力稱贊。…… 我們不諱言我們對那些不愿思考、或者在發問前不做他們該做的事的人的蔑視。

歸納并提出一個好問題黑客們會賞心悅目；提問前不思考、不動手的人會被蔑視。

我們意識到許多人只是想使用我們寫的軟件，他們對學習技術細節沒有興趣。對大多數人而言，電腦只是種工具，是種達到目的的手段而已。他們有自己的生活并且有更要緊的事要做。我們了解這點，也從不指望每個人都對這些讓我們著迷的技術問題感興趣。盡管如此，我們回答問題的風格是指向那些真正對此有興趣并愿意主動參與解決問題的人，這一點不會變，也不該變。如果連這都變了，我們就是在降低做自己最擅長的事情上的效率。

時間對于黑客和用戶都是非常寶貴的，用戶對技術細節不感興趣很正常，但是對于沒有對軟件真正產生興趣或者不主動參與解決問題的人，他們永遠也別想得到解答。

如果你厭惡我們的態度，高高在上，或過于傲慢，不妨也設身處地想想。我們并沒有要求你向我們屈服 —— 事實上，我們大多數人非常樂意與你平等地交流，只要你付出小小努力來滿足基本要求，我們就會歡迎你加入我們的文化。但讓我們幫助那些不愿意幫助自己的人是沒有效率的。無知沒有關系，但裝白癡就是不行。

黑客和用戶是平等的，黑客們會無視“伸手黨”的一切問題，并且默認提問者就是“伸手黨”。

在提問之前

請注意該章節是“在提問之前”：

1. 嘗試在你準備提問的論壇的舊文章中搜索答案。
2. 嘗試上網搜索以找到答案。
3. 嘗試閱讀手冊以找到答案。
4. 嘗試閱讀常見問題文件（FAQ）以找到答案。
5. 嘗試自己檢查或試驗以找到答案。
6. 向你身邊的強者朋友打聽以找到答案。
7. 如果你是程序開發者，請嘗試閱讀源代碼以找到答案。

當你提出問題的時候，請先表明你已經做了上述的努力；這將有助于樹立你并不是一個不勞而獲且浪費別人的時間的提問者。如果你能一并表達在做了上述努力的過程中所學到的東西會更好，因為我們更樂于回答那些表現出能從答案中學習的人的問題。

如果你“不假思索”地提問，即使有人回答你，那多半也是“臉上笑嘻嘻，心里 MMP”，你基本得不到你想要的答案；即使你這次僥幸得到了正確解答，你肯定還會有更多的問題，而這些問題基本不會有人理你了。

當你提問時

慎選提問的論壇

• 在與主題不合的論壇上貼出你的問題。
• 在探討進階技術問題的論壇張貼非常初級的問題；反之亦然。
• 在太多的不同新聞群組上重復轉貼同樣的問題（cross-post）。
• 向既非熟人也沒有義務解決你問題的人發送私人電郵。

找對的地方提問；不確定問題是否會受歡迎就不要提，因為你的提問對有能力解答你問題的人來說本身就是一些列問題：

1. 要不要回答
2. 要怎么回答你才能避免你“誤入歧途”，因為有的時候一個答案會引發更多的提問
3. 要怎么回答你才能既幫助到你也幫助到潛在的其他用戶

回答者考慮的遠比你想象的要多，所以盡量避免提問，要提就提一個好問題。

別像機關槍似的一次 "掃射" 所有的幫助渠道，這就像大喊大叫一樣會使人不快。要一個一個地來。

論壇發帖、提 issue、群里問、發郵件、發 IM 選其一。如果你沒和維護者面過基，千萬不要把提問通過郵箱或者 IM 發給他，這對他是極大的騷擾和困擾！

對于 B3log 開源的項目而言，我個人更傾向于解決在黑客派上的提問帖，這樣能幫助到更多人的概率更大。除非你是我的付費客戶，否則請不要發郵件或者 IM 向我提問，我會忽略此類信息。

Stack Overflow

搜索，然后 在 Stack Exchange 問。

Stack Exchange 是一個站群，按大分類分了很多子站點，其中 Stack Overflow 是編程相關問答的子站。ESR 之所以推薦它，除了它是世界上目前最有效的問答站外，我覺得很可能還因為它們是非常開放的，所有上面的內容都使用共創協議發布，鼓勵帶原作鏈接進行分享演繹，并且可商用。

除了內容協議非常寬松開放以外，SE 還提供了非常實用的 API，讓開發者可以更好地通過他們的數據來發展應用生態，這和很多類似的問答站點是截然不同的。就國內的問答站而言，基本都是強調保護作者版權、禁止商用轉載，甚至是禁止轉載，這對作者看似是保護，實則是在破壞內容創作的生態，導致惡性循環。

網站和 IRC 論壇

在任何論壇發文以前，先確認一下有沒有搜索功能。如果有，就試著搜索一下問題的幾個關鍵詞，也許這會有幫助。如果在此之前你已做過通用的網頁搜索（你也該這樣做），還是再搜索一下論壇，搜索引擎有可能沒來得及索引此論壇的全部內容。

搜索之后再搜索，實在搜不到答案了再想其他辦法。IRC 我基本沒用過，就不展開了，但如果你有 Linux 方面解決不了的問題，可以一試。

第二步，使用項目郵件列表

當某個項目提供開發者郵件列表時，要向列表而不是其中的個別成員提問，即使你確信他能最好地回答你的問題。

如果一個項目既有 "使用者" 也有 "開發者"（或 "黑客"）郵件列表或論壇，而你又不會動到那些源代碼，那么就向 "使用者" 列表或論壇提問。不要假設自己會在開發者列表中受到歡迎，那些人多半會將你的提問視為干擾他們開發的噪音。

用戶郵件列表和開發者郵件列表是兩個郵件列表，開發者郵件列表是開發者之間溝通用的，不是對外解決問題的地方。ESR 也提到了如果有自信，并且問題在用戶郵件列表中沒得到解決，那也可以在暗中觀察（學習開發者之間的溝通交流方式和文化）后向開發者郵件列表求助。

自從有了 GitHub 后，郵件列表也用得很少了。尤其是 GitHub 提供了 @Team 后，和開發團隊交流就變得更有效率了。ESR 對于郵件列表的建議同樣適用于 GitHub 上艾特團隊，也就是要分清楚開發團隊和支持團隊的區別，或者是分清楚核心團隊和 XX 項目團隊的區別，作為提問者，請不要艾特個人開發者。

使用有意義且描述明確的標題

別用喋喋不休的幫幫忙、跪求、急（更別說救命啊！！！！這樣讓人反感的話，用這種標題會被條件反射式地忽略）來浪費這個機會。不要妄想用你的痛苦程度來打動我們，而應該是在這點空間中使用極簡單扼要的描述方式來提出問題。

再多的跪求、在線等、標點符號、Emoji 或者特殊符號也解決不了你碰到的問題，反而會被黑客們“條件反射式地忽略”，簡明扼要的標題是一個好問題的開始。

一個好標題范例是目標 —— 差異式的描述，許多技術支持組織就是這樣做的。在目標部分指出是哪一個或哪一組東西有問題，在差異部分則描述與期望的行為不一致的地方。

X.org 6.8.1 的鼠標光標，在某牌顯卡 MV1005 芯片組環境下 - 會變形。

另外，這一小節對在回復中提出新問題也給出了建議：無論是郵件列表還是網頁論壇，盡量不要在回復中提出新問題，新問題就新發郵件或者新開帖子。

使問題容易回復

以“請將你的回復發送到……”來結束你的問題多半會使你得不到回答。

在論壇，要求通過電子郵件回復是非常無禮的，除非你認為回復的信息可能比較敏感。

這點很好理解，用什么渠道發布的提問，回答者就回復到該渠道上。除了可能涉及敏感信息外，提問者這樣的請求是無理并且無禮的。

用清晰、正確、精準并語法正確的語句

正確的拼寫、標點符號和大小寫是很重要的。通常來說，如果你覺得這樣做很麻煩，不想在乎這些，那我們也覺得麻煩，不想在乎你的提問。

別以為別人不在乎拼寫、標點符號和大小寫，黑客們甚至在乎空格的使用！比如中文和英文、數字、符號之間必須要有空格，這個空格被稱作“盤古之白”。

關于大小寫引發的“悲劇”也不少，甚至可能就發生在你身上。比如你簡歷是不是寫過“iphone/ios 開發”，“熟練使用 JAVA”，“熟悉 Mysql”？這樣“不拘小節”的人恐怕不知道大多數編程語言是區分大小寫的吧….

如果在使用非母語的論壇提問，你可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎（沒錯，我們通常能弄清兩者的分別）。同時，除非你知道回復者使用的語言，否則請使用英語書寫。

B3log 開源項目提問無論是在 GitHub 上還是在黑客派上，均可優先使用中文。

使用易于讀取且標準的文件格式發送問題

• 對一些特殊的文件不要設置固定寬度（譬如日志檔案拷貝或會話記錄）。數據應該原樣包含，讓回復者有信心他們看到的是和你看到的一樣的東西。

帖日志要保證是純文本格式，特別是服務器端日志，千萬不要截圖（特別是那種截圖還“勾畫重點”的行為應該立刻停止）；對于瀏覽器端的監控調試輸出可以截圖，但截圖時要考慮信息是否完整，也不要包含無用畫面。

• 勿濫用表情符號和 HTML 功能（當它們提供時）。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向于使人認為你是個無能之輩。過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。這通常不是個好主意，除非你只是對性而不是對答案感興趣。

可能你碰到問題后心情很復雜，需要大量表情符號、紅綠色、超大標題或者 gif 動圖來表達你心中的困惑，但是這樣做除了表現出幼稚、干擾閱讀外沒有任何用。

這一小節中 ESR 還建議了很多條關于發送郵件時的細節，現在郵件在問答時用得比較少了，所以略過。

精確地描述問題并言之有物

• 仔細、清楚地描述你的問題或 Bug 的癥狀。
• 描述問題發生的環境（機器配置、操作系統、應用程序、以及相關的信息），提供經銷商的發行版和版本號（如：Fedora Core 4、Slackware 9.1 等）。
• 描述在提問前你是怎樣去研究和理解這個問題的。
• 描述在提問前為確定問題而采取的診斷步驟。
• 描述最近做過什么可能相關的硬件或軟件變更。
• 盡可能的提供一個可以重現這個問題的可控環境的方法。

項目維護者通常會提供問題報告模板來引導用戶報告問題（比如這里），如果你在報告問題時沒有看到模板，那就按照上述建議進行問題描述。

話不在多而在精

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

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

動手簡化問題是非常重要的，也許你在簡化過程中就可以獲得解決方案。

別動輒聲稱找到 Bug

編寫軟件的人總是非常辛苦地使它盡可能完美。如果你聲稱找到了 Bug，也就是在質疑他們的能力，即使你是對的，也有可能會冒犯到其中某部分人。當你在標題中嚷嚷著有 Bug 時，這尤其嚴重。

不要自以為是的認為你真的發現了 Bug，更不要直接說出來。大家都是為了軟件的將來更好，禮貌明智的表達更能有效促進軟件發展。

提問時，即使你私下非常確信已經發現一個真正的 Bug，最好寫得像是你做錯了什么。如果真的有 Bug，你會在回復中看到這點。這樣做的話，如果真有 Bug，維護者就會向你道歉，這總比你惹惱別人然后欠別人一個道歉要好一點。

即使你真的確定是 Bug 了，也不要直接說出來，維護者會明白你的意思的，并且向你道歉。不要認為維護者是玻璃心，其實是他們只對他們認為有價值的問題上心。

低聲下氣不能代替你的功課

有些人明白他們不該粗魯或傲慢的提問并要求得到答復，但他們選擇另一個極端 —— 低聲下氣：“我知道我只是個可悲的新手，一個擼瑟，但…。”這既使人困擾，也沒有用，尤其是伴隨著與實際問題含糊不清的描述時更令人反感。

時刻記住大家的時間都很寶貴，描述問題是關鍵。

描述問題癥狀而非你的猜測

告訴黑客們你認為問題是怎樣造成的并沒什么幫助。（如果你的推斷如此有效，還用向別人求助嗎？），因此要確信你原原本本告訴了他們問題的癥狀，而不是你的解釋和理論；讓黑客們來推測和診斷。如果你認為陳述自己的猜測很重要，清楚地說明這只是你的猜測，并描述為什么它們不起作用。

往往簡單的問題早都被解決了，你碰到的通常都是復雜的問題。復雜的問題可能有 100 種產生的可能性，你說的只是一種可能性，而且很可能是錯誤的，即使你提供了理論解釋。

按發生時間先后列出問題癥狀

問題發生前的一系列操作，往往就是對找出問題最有幫助的線索。因此，你的說明里應該包含你的操作步驟，以及機器和軟件的反應，直到問題發生。

描述問題發生的步驟至關重要，如果你按照你給的步驟不能重現問題，那就不要提問。另外，可自己嘗試手動調整日志級別來觀察輸出情況。

記住，多不等于好。試著選取適當的調試級別以便提供有用的信息而不是讓讀者淹沒在垃圾中。

描述目標而不是過程

如果你想弄清楚如何做某事（而不是報告一個 Bug），在開頭就描述你的目標，然后才陳述重現你所卡住的特定步驟。

你別笑，我真遇到過這樣報告問題的：“我發現了個 bug，你的軟件不能做 XXX。”我回復：“這不是 bug，是個 feature。”并關閉。

軟件所有的功能通常都在界面或者參數上提供出來，文檔上也會有相應描述。如果某個功能你找不到入口，只有兩種情況：

1. 這個功能是個彩蛋
2. 沒這功能

別要求使用私人電郵回復

黑客們認為問題的解決過程應該公開、透明，此過程中如果更有經驗的人注意到不完整或者不當之處，最初的回復才能夠、也應該被糾正。同時，作為提供幫助者可以得到一些獎勵，獎勵就是他的能力和學識被其他同行看到。

秉承開源的理念：開放、共享、協作來進行提問和解決問題很有效也很有價值。

對于 B3log 開源項目而言，優先到論壇發帖提問，請勿私信我，私信我的話我只會回你：“請到論壇發問答帖。”或者直接忽略你的提問。

清楚明確的表達你的問題以及需求

漫無邊際的提問是近乎無休無止的時間黑洞。最有可能給你有用答案的人通常也正是最忙的人（他們忙是因為要親自完成大部分工作）。…… 因此，問“我想更好的理解 X，可否指點一下哪有好一點說明？”通常比問“你能解釋一下 X 嗎？”更好。

如果你對可能的答案的邊界不清楚，最好不要問。

詢問有關代碼的問題時

這一節 ESR 建議在反饋代碼問題時可以通過最小化測試用例（前面“話不在多而在精”一節有提到過）進行描述。

一般而言，要得到一段相當精簡的測試用例并不太容易，但永遠先嘗試這樣做的是種好習慣。這種方式可以幫助你了解如何自行解決這個問題 —— 而且即使你的嘗試不成功，黑客們也會看到你在嘗試取得答案的過程中付出了努力，這可以讓他們更愿意與你合作。

如果是 code review：

一定要提到你認為哪一部分特別需要關注以及為什么。

別把自己家庭作業的問題貼上來

黑客們很擅長分辨哪些問題是家庭作業式的問題；因為我們中的大多數都曾自己解決這類問題。同樣，這些問題得由你來搞定，你會從中學到東西。你可以要求給點提示，但別要求得到完整的解決方案。

這里“家庭作業式的問題”主要就是指那種 顯然 是要通過自己學習來解決的問題，并且通過學習肯定能解決的問題，總之，你學了就知道了。

去掉無意義的提問句

避免用無意義的話結束提問，例如“有人能幫我嗎？”或者“這有答案嗎？”。

這和問你“在嗎？”一樣，大部分時候我都很想回復“不在。”你要知道，在一些代碼實現中，我們都是盡自己的最大努力來做簡化，看到你這樣問，我們會條件反射地把它優化掉。

即使你很急也不要在標題寫緊急

這是你的問題，不是我們的。…… 有半個例外的情況是，如果你是在一些很高調，會使黑客們興奮的地方，也許值得這樣去做。在這種情況下，如果你有時間壓力，也很有禮貌地提到這點，人們也許會有興趣回答快一點。

過分強調往往適得其反。

禮多人不怪，而且有時還很有幫助

彬彬有禮，多用請和謝謝您的關注，或謝謝你的關照。讓大家都知道你對他們花時間免費提供幫助心存感激。…… 坦白說，這一點并沒有比清晰、正確、精準并合法語法和避免使用專用格式重要（也不能取而代之）。

禮多人不怪，但別顛倒主次，精準描述問題永遠是第一位。

問題解決后，加個簡短的補充說明

問題解決后，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，并再一次向他們表示感謝。…… 在黑客中，這種良好的后繼行動實際上比傳統的禮節更為重要，也是你如何透過善待他人而贏得聲譽的方式，這是非常有價值的資產。

問題即使是自己解決的，也請在解決后補充下簡短的說明，這對于積攢聲譽很有幫助。其他遇到同樣問題的人會感激你的，黑客們也會對你有始有終的行動表示贊賞，即使這個問題對他們來說不是個好問題。

如何解讀答案

RTFM 和 STFW：如何知道你已完全搞砸了

如果你收到 RTFM （Read The Fucking Manual）的回應，回答者認為你應該去讀他媽的手冊。當然，基本上他是對的，你應該去讀一讀。…… 如果你收到 STFW（Search The Fucking Web）的回應，回答者認為你應該到他媽的網上搜索。那人多半也是對的，去搜索一下吧。…… 你不應該因此不爽；依照黑客的標準，他已經表示了對你一定程度的關注，而沒有對你的要求視而不見。

鳥哥語錄.jpg。

如果還是搞不懂

如果你看不懂回應，別立刻要求對方解釋。像你以前試著自己解決問題時那樣（利用手冊，FAQ，網絡，身邊的高手），先試著去搞懂他的回應。如果你真的需要對方解釋，記得表現出你已經從中學到了點什么。

只要你有搞不懂的東西，永遠優先嘗試自己解決。

處理無禮的回應

很多黑客圈子中看似無禮的行為并不是存心冒犯。相反，它是直接了當，一針見血式的交流風格，這種風格更注重解決問題，而不是使人感覺舒服而卻模模糊糊。…… 另一方面，你偶爾真的會碰到無禮和無聊的言行。與上述相反，對真正的冒犯者狠狠地打擊，用犀利的語言將其駁得體無完膚都是可以接受的。然而，在行事之前一定要非常非常的有根據。

這一點讓我想起了曾仕強的“只講妥當話、不講實在話”。至少在黑客的圈子里，這樣說“妥當話”完全就是在浪費大家時間。

如果你想得到的是信息而不是消磨時光，這時最好不要把手放在鍵盤上以免冒險。

做個鍵盤俠實在是太容易了。

如何避免扮演失敗者

如果你搞砸了，并且被人在公開場合告知你的愚蠢行為時：

熬過去，這很正常。…… 當有人評論你的一個說法有誤或者提出不同看法時，堅持聲稱受到個人攻擊也毫無益處，這些都是失敗者的態度。…… 夸張的講法是：你要的是友善（以上述方式）還是有用？兩個里面挑一個。

這一節 ESR 建議大家不要卷入毫無意義的口水戰。有些“自以為是專家的不中用家伙”他們其實是“測試你是否真會搞砸的心理專家”，這些人就靠引戰和表演來滿足他們的內心。

其它讀者要么不理睬，要么用自己的方式對付他們。這些來找麻煩的人在給他們自己找麻煩，這點你不用操心。

不該問的問題

這一節是一些常見的不該發問的示例，建議看原文。

好問題與蠢問題

這一節是一些常見的好問題和蠢問題示例，建議看原文。

黑客從某種角度來說是擁有豐富知識但缺乏人情味的家伙；我相信他是對的，如果我像個乞討者那樣提問，不論我是誰，一定會惹惱某些人或者被他們忽視。

如果得不到回答

總的來說，簡單的重復張貼問題是個很糟的點子。這將被視為無意義的喧鬧。…… 另外，你可以向很多商業公司尋求幫助，不論公司大還是小。別為要付費才能獲得幫助而感到沮喪！…… 就算軟件沒花費你一分錢，你也不能強求技術支持總是免費的。

總之，正確的提問但沒有得到回答時不要沮喪，因為這兩者之間沒有必然的因果關系。付費咨詢也是解決問題的一條路徑，就像你選擇使用免費軟件一樣。

如何更好地回答問題

這一節是對回答者的建議，保持友善、歸納問答、提高效率，授人以魚不如授人以漁。

相關資源

如果你需要個人電腦、Unix 系統和網絡如何運作的基礎知識，參閱 Unix 系統和網絡基本原理。

當你發布軟件或補丁時，試著按軟件發布實踐操作。

鳴謝

Evelyn Mitchel 貢獻了一些愚蠢問題例子并啟發了編寫如何更好地回答問題這一節， Mikhail Ramendik 貢獻了一些特別有價值的建議和改進。

作者：88250

鏈接：https://hacpai.com/article/1536377163156

來源：黑客派

協議：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/