提問的智慧（3.2 版）

如果你因為需要幫助閱讀了本文，然後帶著可以直接從作者那裏取得幫助的印像離開，你就不幸成了那些白癡之一。不要向我們提問，我們不會理睬的。我們在這只是給你說明如何從那些真正懂得你軟硬體問題的人那裏取得幫助的方法，99% 的時間我們不會是那些人。除非你確信此文作者是你遇到問題方面的專家，請不要打擾，這樣大家都更開心一點。

引言

在黑客的世界，你得到的回答很大程度上取決於你提問的方式與解決此問題的難度，本文將教你如何提問才更有可能得到滿意的答覆。

開源程式的使用已經很廣泛，你通常可以從其他更有經驗的用戶得到跟黑客那裏同樣好的回答。這是好事，他們一般對新手常有的毛病更容忍一點。然而，使用我們介紹的方法像對待黑客那樣對待這些有經驗的用戶，通常能最有效地得到問題的解答。

第一件需要明白的事是黑客喜歡難題和激發思考的好問題。假如不是這樣，我們也不會寫本文了。如果你能提出一個有趣的問題讓我們咀嚼玩味，我們會感激你。好的問題是種激勵與禮物，幫助我們發展認知，揭示沒有注意或想過的問題。在黑客中，「好問題！」是非常真摯的贊許。

除此而外，黑客有遇到簡單問題就表現出敵視或傲慢的名聲，有時候我們看起來還對新手和愚蠢的傢伙有條件反射式的無禮，但實情並不是這樣。

我們只是毫無歉意地敵視那些提問前不願思考、不做自己該做之事的人。這種人就像時間無底洞──他們只知道獲取，不願意付出，他們浪費了時間，這些時間本可用於其他更值得回答的人和更有趣的問題。我們將這種人叫做「失敗者 (loser)」（由於歷史原因，我們有時將「loser」拼為「lusers」）。

我們注意到許多人只想用我們寫的軟體，他們對學習技術細節沒有興趣。對大多數人而言，電腦只是種工具，是種達到目的的手段。他們要生活並且有更要緊的事要做，我們承認這點，也從不指望每個人都對這些讓我們著迷的技術問題感興趣。不過，我們回答問題的風格是為了適應那些真正對此有興趣並願意主動解決問題的人，這一點不會變，也不該變。如果這都變了，我們就會在自己能做得最好的事情上不再那麼犀利。

我們（多數）是自願者，從自己繁忙的生活中抽時間來回答問題，有時會力不從心。因此，我們會無情地濾除問題，特別是那些看起來像是失敗者的，以便更有效地把回答問題的時間留給那些「勝利者」。

如果你認為這種態度令人憎惡、以施惠者自居或傲慢自大，請檢查你的假設，我們並未要求你屈服 - 事實上，假如你做了該做的努力使之成為可能，我們中的大多數人非常樂意平等地與你交流並歡迎你接納我們的文化。試圖去幫助那些不願自救的人對我們簡直沒有效率，不懂沒有關係，但愚蠢地行事不行。

所以，你不必在技術上很在行才能吸引我們的注意，但你必須表現出能引導你在行的姿態 - 機敏、思考、善於觀察、樂於主動解決問題。如果你做不到這些使你與眾不同的事情，我們建議你付錢跟別人簽商業服務合同，而不是要求黑客無償幫助。

如果你決定向我們求助，你不會想成為一名失敗者，你也不想被看成一個失敗者。得到快速有效回覆的最好方法是使提問者看起來像個聰明、自信的人，並且暗示只是碰巧在某一特別問題上需要幫助。

（歡迎對本文指正，可以將建議發至 [email protected] 或 [email protected] 。請注意，本文不想成為一般性的網路禮儀指南，我一般會拒絕那些與引出技術論壇中有用的回覆不特別相關的建議。）

提問前

在通過電子郵件、新聞組或網頁論壇提技術問題之前，做以下事情：

嘗試搜索互聯網以找到答案
嘗試閱讀手冊以找到答案
嘗試閱讀 FAQ（常見問題）文檔以找到答案
嘗試自己檢查或試驗以找到答案
嘗試請教懂行的朋友以找到答案
如果你是程式師，嘗試閱讀原始碼以找到答案

提問時，請先表述你已經做了上述事情，這將有助於建立你不是寄生蟲與浪費別人時間的印像。最好再表述你從中 學到的東西，我們喜歡回答那些表現出能從答案中學習的人。

使用某些策略，比如用 Google 搜索你遇到的錯誤提示（既搜索網頁也查查討論組），可能就直接找到了解決問題的文檔或郵件列表線索。即使沒有結果，在電子郵件或新聞組張貼問題時提一句「我在 Google 中查過下列句子但沒有找到甚麼有用的東西」也是件好事。

準備你的問題，徹底地思考。輕率的提問只能得到輕率的回答，或者壓根兒沒有。在提問時，越是表現出做過思考並在努力解決問題，你越有可能得到實際幫助。

注意別提錯問題。如果提問基於錯誤的假設，某黑客多半會一邊想「愚蠢的問題……」，一邊用按照問題字面的無用答案回覆你，並且希望這種只是得到字面回答而不是真正所需的經歷給你一個教訓。

永遠不要假設你 有資格 得到解答。你沒有這種資格，畢竟你沒有為此服務付費。如果你能夠提出有內容、有趣和激勵思考的問題 - 那種毫無疑問能夠向社區貢獻經驗而不僅僅是消極地要求從別人那獲取知識的問題，你將「掙到」答案。

另一方面，表明你能夠也樂意參與解決問題是個很好的開端。「有沒有人能指個方向？」、「我這裏還漏點甚麼？」、「我應該查哪些網站？」通常要比「請給出我可以用的完整步驟」更容易得到回覆，因為你表明了只要有人能指個方向你就很樂意完成剩下的過程。

提問時

仔細挑選論壇

要對在哪兒提問留心，如果你做了下述事情，多半會被一筆勾銷或被看成「失敗者」：

張貼與論壇主題完全無關的問題
在面向高級技術問題的論壇上提非常初淺的問題，或者反之。
在太多不同的新聞組同時交叉張貼
給既非熟人也沒有義務解決你問題的個人張貼你私人的電子郵件

為保護通信的渠道不被無關的東西淹沒，黑客會除掉那些沒有找對地方的問題，你不會想有這種經歷的。

所以第一步是找對論壇，Google 與其他搜索引擎還是你的朋友，可以用它們搜索與你遇到困難的軟硬體問題最相關的專案的網站。那裏通常都有專案的 FAQ 列表、郵件列表及其文檔的鏈結。如果你的努力（包括閱讀 FAQ）都沒有結果，這些郵件列表就是最後能取得幫助的地方。專案的網站也許還有報告臭蟲的流程或鏈結，如果是這樣，去看看。

向陌生的人或論壇發送郵件極有可能是在冒險。譬如，不要假設一個富含資訊的網頁的編寫者想充當你的免費顧問，不要對你的問題是否會受到歡迎做樂觀的估計──如果你不確定，向別處發或者根本別發問。

在選擇網頁論壇、新聞組或郵件列表時，不要太相信名字，先看看 FAQ 或者許可以明確你的問題是否與其主題相關。張貼前先翻翻已有的帖子可以幫助你感受一下那裏行事的方式。事實上，張貼之前在新聞組或郵件列表中搜索與你問題相關的關鍵字是個很好的主意，也許就找到答案了。即使沒有，也能幫助你整理出更好的問題。

別像機關槍似的一次性「掃射」所有的幫助通道，那就像大嚷大叫並使人不快。一個一個地來。

弄清楚你的主題！最典型的錯誤之一是在某種致立於跨 Unix 和 Windows 平台的語言、庫或工具的論壇中提關於作業系統程式介面的問題。如果你不明白為甚麼這是大錯，最好在搞清楚概念前甚麼也別問。

一般來說，在仔細挑選的公共論壇中提問比在私有論壇中提同樣的問題更容易得到有用的回覆。有許多理由支持這一點，一是看潛在的回覆者有多少，二是看論壇的參與者有多少，黑客更願回答能啟發多數人的問題。

可以理解，老練的黑客和一些流行軟體的作者正在收到超出他們承受能力的不當訊息。就像那根多出來就可以壓垮駱駝背的稻草一樣，你的加入也可能會使情況走向極端──已經好幾次了，一些流行軟體的作者退出了對其軟體的支援，因為伴隨而來的湧向其私人郵箱的大量無用消息變得無法忍受。

面向新手的網頁論壇和 IRC 通常響應最快

本地的用戶組織或者你所用的 Linux 發行版也許正在宣傳新手取得幫助的網頁論壇或 IRC（互聯網中繼聊天）(在非英語國家，新手論壇很可能還是郵件列表)，這些地方是開始提問的好去處，尤其是當你覺得遇到的也許只是相對簡單或者一般的問題時。經過宣傳的 IRC 通道是個公開邀請提問的地方，通常可以得到即時的回覆。

事實上，如果出問題的程式來自某發行版（這很常見），在程式的專案論壇或列表提問前最好先在發行版的論壇或列表中問問，否則專案的黑客可能僅僅回覆「用 我們的 原始碼」。

在任何網頁論壇張貼之前，先看看是否有搜索功能。如果有，就試試用問題的幾個關鍵字搜索一下，也許就有幫助。如果在此之前你已做過全面的網頁搜索（你應該這樣做），還是再搜索一下論壇，搜索引擎最近也許還沒有索引此論壇的全部內容。

通過網頁論壇或 IRC 頻道提供專案的用戶支援有增長的趨勢，電子郵件交流則更多地為專案開發保留。先在網頁論壇或 IRC 中尋求與專案相關的幫助。

使用專案郵件列表

當某專案存在開發者郵件列表時，即使你確信誰能最好地回答問題，也要向列表而不是其中的個體提問。檢查專案的文檔和主頁，找到專案的郵件列表並使用它。採用這種策略有幾個好理由：

任何向單個開發者提的足夠好的問題也將對整個專案組有益。相反，如果你認為自己的問題對整個專案組來說太愚蠢，這也不能成為打擾單個開發者的理由。
向列表提問可以平衡開發者的負擔，單個開發者（特別是專案領導）也許太忙以至於無法回答你的問題。
大多數郵件列表有歷史文檔並被搜索引擎索引，其他人可以通過網頁搜索找到你的問題和答案而不用再次在郵件列表中發問。
如果某些問題經常被問到，開發者可以利用此資訊改進文檔或軟體本身以使其更清楚。如果只是私下提問，就沒有人能看到最常見問題的完整場景。

如果一個專案既有「用戶」也有「開發者」（或「黑客」）郵件列表或網頁論壇，而你又不擺弄那些原始碼，向「用戶」列表或論壇提問。不要假設自己在開發者列表中會受歡迎，那些人多半會遭受你的噪音干擾。

然而，如果你確信你的問題不一般，而且在「用戶」列表或論壇中幾天都沒有回覆，可以試試「開發者」列表或論壇。建議你在張貼前最好先暗暗地觀察幾天以瞭解那裏的行事方式（事實上這是參與任何私有或半私有列表的好主意）。

如果你找不到一個專案的郵件列表，而只能查到專案維護者的位址，只管向其發信。即便在這種情況下，也別假設專案郵件列表不存在。在你的電子郵件中陳述你已經試過但沒有找到合適的郵件列表，也提及你不反對將自己的郵件轉發給他人（許多人認為，即使沒甚麼秘密，私人電子郵件也不應該被公開。通過允許將你的電子郵件轉發他人給了相應人員處置你郵件的選擇）。

使用明確而有意義的主題

在郵件列表、新聞組或網頁論壇中，主題是你在五十個或更少的字符以內吸引有資格的專家注意的黃金機會，不要用諸「請幫我」（更別提大寫的「請幫我！！！！」，這種主題的消息會被條件反射式地刪掉）之類的嘮叨浪費機會。不要用你痛苦的深度來打動我們，相反，要在這點空間中使用超級簡明扼要的問題描述。

使用主題的好慣例是「物件──偏差」式的描述，許多技術支援組織就是這樣做的。在「物件」部分指明是哪一個或哪一組東西有問題，在「偏差」部分則描述與期望行為不一致的地方。

愚蠢：

救命啊！我的筆記本視頻工作不正常！

明智：

X.org 4.1扭曲滑鼠游標，某顯卡 MV1005 型號的晶片組

更明智：

使用某顯卡 MV1005 型號晶片組的 x.org 4.1 的滑鼠游標被扭曲

編寫「物件──偏差」式描述的過程有助你更具體地組織問題。是甚麼被影響了？僅僅是滑鼠游標或者還有其他圖形？只在 X.org 中出現？或只是在其 4.1 版中？是針對某顯卡？或者只是其 MV1005 型號的晶片組？一個黑客只需描一眼就能夠立即明白甚麼是你遇到的問題，甚麼是你自己的問題。

更一般地，想像一下在只顯示主題的文檔索引中查找。讓你的主題更好地反映問題，可以使下一個搜索類似問題的人能夠在文檔中直接找到答案的線索而不用再次張貼提問。

如果你想在回覆中提問，確保改變主題以表明你是在問一個問題，一個主題像「re: 測試」或「re: 新臭蟲」的消息不太可能引起足夠的注意。同時，將回覆中與新主題不甚相關的引用內容儘量刪除。

對於郵件列表訊息，不要直接點擊回覆按鈕來開始一個新的主題，這將限制你的觀眾。有些郵件閱讀程式，比如 mutt，允許用戶按線索排序並通過折疊主題來隱藏消息，這樣做的人永遠看不到你發的訊息。

僅僅改變主題還不夠。mutt 和其他郵件閱讀程式還要檢查主題以外的其他郵件頭資訊，以便為其指定主題，所以寧可發一個全新的郵件。

在網頁論壇，因為消息與特定的主題緊密結合並且通常在主題之外不可見，好的提問方式略有不同，通過回覆提問並不要緊（一些論壇甚至不允許在回覆中出現分離的主題，而且這樣做了基本上沒有人會去看）。不過通過回覆提問本身就是令人懷疑的做法，因為它們只會被正在查看該主題的人讀到。所以，除非你只想在該主題當前活躍的人群中提問，還是另起爐灶比較好。

使之更易回覆

以「請向……回覆」來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件用戶端設置一下回覆位址都麻煩，我們也覺得花幾秒鐘考慮你的問題更麻煩。如果你的郵件用戶端程式不支援這樣做，換個好點的。如果是作業系統不支援所有這種郵件用戶端程式，也換個好點的。

在網頁論壇，要求通過電子郵件回覆是完全無禮的，除非你確信回覆的資訊也許是機密的（而且有人會為了某種未知的原因只讓你而不是整個論壇知道答案）。如果你只是想在有人回覆主題時得到電子郵件提醒，可以要求論壇發送。幾乎所有論壇都提供諸如「留意本主題」、「有回覆發送郵件」的功能。

使用清晰的語法與拼寫正確的語句

經驗告訴我們，粗心與草率的作者通常也粗心與草率地思考和編程（我敢打賭）。為這些粗心與草率的思考者回答問題沒有甚麼好處，我們寧可將時間花在其他地方。

清楚、完整地表達你的問題非常重要。如果你覺得這樣做麻煩，我們也覺得注意你的問題麻煩。花點額外的精力斟酌一下字句，用不著太僵硬與正式──事實上，黑客文化很看重能準確地使用非正式、俚語和幽默的語句。但它必須很準確，而且有跡像表明你是在思考和關注問題。

正確地拼寫、使用標點和大小寫，不要將 “its” 混淆為 “it’s”，“loose” 搞成 “lose” 或者將 “discrete” 弄成 “discreet”。不要全部用大寫，這會被看成無禮的大聲嚷嚷（全部小寫也好不到哪去，因為不易閱讀。Alan Cox [注：著名黑客，Linux 內核的重要參與者] 也許可以這樣做，但你不行）。

一般而言，如果你寫得像個半文盲似的傻子，多半得不到理睬。如果像個小孩似地亂寫亂畫那絕對是在找死，可以肯定沒人會理你（或者最多是給你一大堆指責與挖苦）。

如果在非母語論壇中提問，你的拼寫與語法錯誤會得到有限的寬容，但懶惰完全不會被容忍（是的，我們通常看得出其中的差別）。同時，除非你知道回覆者使用的語言，請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的訊息。在互聯網上英語是工作語言，用英語書寫可以將你的問題不被閱讀就被直接刪除的可能降到最低。

使用易懂的格式發送問題

如果你人為地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，所以：

使用文本而不是 HTML（超文本標注語言)（關閉HTML 並不難）
使用 MIME（多用途互聯網郵件擴展）附件通常沒有問題，前提是真正有內容（譬如附帶的原始檔案或補丁），而不僅僅是郵件用戶端程式生成的範本（譬如只是訊息內容的拷貝）。
不要發送整段只是單行句子但多次折回的郵件（這使得回覆部分內容非常困難）。設想你的讀者是在 80 個字符寬的文本終端閱讀郵件，設置你的行折回點小於 80 列。
但是，也不要用任何固定列折回資料（譬如直接傳送的日誌檔或會話記錄）。資料應該原樣包含，使回覆者確信他們看到的與你看到的東西一樣。
在英語論壇中，不要使用 “Quoted-Printable” MIME 編碼發送消息。這種編碼對於張貼非 ASCII 語言可能是必須的，但很多郵件代理程式並不支援。當它們分斷時，那些文本中四處散佈的「=20」符號既難看也分散注意力。
永遠不要 指望黑客們閱讀使用封閉的專用格式編寫的文檔，諸如微軟公司的 Word 或 Excel 文件等，大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你門口時你的反應一樣。即使他們能夠處理，他們也很厭惡這麼做。
如果你從使用視窗的電腦發送電子郵件，關閉微軟愚蠢的「聰明引用」功能，以免在你的郵件中到處散佈垃圾字符。
在網頁論壇，勿濫用「表情符號」和「html」功能（當它們提供時）。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向於使人認為你是個無能之輩。過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。這通常不是個好主意，除非你只是對性而不是有用的回覆更有興趣。

如果你使用圖形用戶介面的郵件用戶端程式（如網景公司的 Messenger、微軟公司的 Outlook 或者其他類似的），注意它們的預設配置不一定滿足這些要求。大多數這類程式有基於功能表的「查看原始碼」命令，用它來檢查發送檔夾中的訊息，以確保發送的是沒有多餘雜質的純文字檔案。

描述問題應準確且有內容

仔細、清楚地描述問題的徵狀
描述問題發生的環境（主機，作業系統，應用程式，任何相關的），提供銷售商的發行版和版本號（如：「Fedora Core 2」、「Slackware 9.1」等）
描述提問前做過的研究及其理解。
描述提問前為確定問題而採取的診斷步驟。
描述最近對電腦或軟體配置的任何相關改變。

盡最大努力預測黑客會提到的問題，並提前備好答案。

Simon Tatham 寫過一篇叫如何有效地報告臭蟲的文章，我強烈推薦各位閱讀。

多不等於準確

你應該寫得準確且有內容，簡單地將一大堆原始碼或資料「傾倒」在求助訊息中達不到目的。如果你有一個很大且複雜的測試樣例讓程式崩潰，嘗試將其裁剪得越小越好。

至少有三個理由支持這點。第一，讓別人看到你在努力簡化問題使你更有可能得到回覆。第二，簡化問題使你更有可能得到 有用的 回覆。第三，在提純臭蟲報告的過程中，你可能自己就找到了解決問題的方法或權宜之計。

別動輒聲稱找到臭蟲

當你在一個軟體中遇到問題，除非你 非常、非常 的有根據，不要動輒聲稱找到了臭蟲。提示：除非你能提供解決問題的原始碼補丁，或者對前一版本的回歸測試表現出不正確的行為，否則你都多半不夠完全確信。對於網頁和文檔也如此，如果你聲稱發現了文檔的「臭蟲」，你應該能提供相應位置的替代文本。

記住，還有許多其他用戶未經歷你遇到的問題，否則你在閱讀文檔或網頁搜索時就應該發現了（你在埋怨前已經做了這些，是吧？)。這也意味著很有可能是你弄錯了而不是軟體本身有問題。

編寫軟體的人通常非常辛苦地使它盡可能完美。如果你聲稱找到了臭蟲，也就暗示他們做錯了甚麼，而這幾乎總會使人不快──即使你是對的，在主題中嚷嚷「臭蟲」也是特別不老練的。

提問時，即使你私下非常確信已經發現一個真正的臭蟲，最好寫得像是你做錯了甚麼。如果真的有臭蟲，你會在回覆中看到這點。這麼做的話，如果真有蟲子，維護者就會向你道歉，這總比你弄砸了然後欠別人一個道歉要強。

低聲下氣不能代替自己應做之事

有些人明白他們不應該粗魯或傲慢地行事並要求得到答覆，但他們退到相反的低聲下氣的極端，「我知道我只是個甚麼也不是、甚麼也不懂的失敗者，但…」。這既使人困擾也沒有幫助，當伴隨著對實際問題含糊的描述時還特別令人反感。

別用低級靈長類動物的策略浪費大家的時間，相反，儘量清楚地表述背景事實和你的問題，這比低聲下氣更好地擺正你的位置。

有時，網頁論壇設有單獨的初學者提問區域，如果你真的認為遇到了初淺的問題，到那去就是了，但一樣別低聲下氣。

描述問題症狀而不是猜測

告訴黑客你認為是甚麼導致了問題是沒有用的（如果你的診斷理論是了不起的東西，你還會向他人諮詢求助嗎？）。所以，確保只是告訴他們問題的原始症狀，而不是你的解釋和理論，讓他們來解釋和診斷。如果你認為陳述你的猜測很重要，清楚地說明這只是你的猜測並描述為甚麼它們不起作用。

愚蠢：

我在編譯內核時接連遇到 SIG11 錯誤，懷疑主板上的某根電路絲斷了，找到它們的最好辦法是甚麼？

明智：

我組裝的電腦（ K6/233 CPU、FIC-PA2007 主板（威盛 Apollo VP2 晶片組）、Corsair PC133 SDRAM 256MB 內存）最近在開機 20 分鐘左右、做內核編譯時頻繁地報 SIG11 錯，但在頭 20 分鐘內從不出問題。重啟動不會重定時鐘，但整夜關機會。更換所有記憶體未解決問題，相關的典型編譯會話日誌附後。

按時間先後羅列症狀

剛出問題之前發生的事情通常包含有解決問題最有效的線索。所以，記錄中應準確地描述你及電腦在崩潰之前都做了些甚麼。在命令行處理的情況下，有會話日誌（如運行腳本工具生成的）並引用相關的若干（如 20）行記錄會非常有幫助。

如果崩潰的程式有診斷選項（如 -v 詳述選項），仔細考慮選擇這些能在記錄中增加排錯資訊的選項。

如果你的記錄很長（如超過四段），也許在開頭簡述問題隨後按時間先後羅列詳細過程更有用。這樣做，黑客在讀你的記錄時就知道該查哪些內容了。

描述目的而不是步驟

如果你想弄清楚如何做某事（而不是報告一個臭蟲），在開頭就描述你的目標，此後才描述為此採取的措施所遇到的問題。

經常有這種情況，尋求技術幫助的人在腦袋裏有個更高層面的目標，他們在自以為能達到目標的特定道路上被卡住了，然後跑來問該怎麼走，但沒有意識到這條路本身有問題，結果要費很大的勁才能通過。

愚蠢：

我怎樣才能讓某圖形程式的顏色拾取器取得十六進位的 RGB 值？

明智：

我正試圖用自己選定數值的顏色替換一幅圖片的顏色表，我現在唯一知道的方法是編輯每個表槽，但卻無法讓某圖形程式的顏色拾取器取得十六進制的 RGB 值。

第二種提法是明智的，它使得建議採用更合適的工具完成任務的回覆成為可能。

別要求私下回覆

黑客們認為問題的解決過程應該公開、透明，此過程中如果更有才能的人注意到不完整或者不當之處，最初的回覆才能夠、也應該被更正。同時，作為回覆者也因為能力和學識被其他同行看到而得到某種回報。

當你要求私下回覆時，此過程和回報都被中止。別這樣做，讓 回覆者 來決定是否私下回答──如果他真這麼做了，通常是因為他認為問題編寫太差或者太膚淺以至於對其他人無意義。

對這條規則存在一條有限的例外，如果你確信提問可能會導致大量雷同的回覆時，那麼「給我發電子郵件，我將為小組歸納這些回覆」將是神奇的句子。試圖將郵件列表或新聞組從洪水般雷同的回覆中解救出來是非常有禮貌的──但你應信守諾言。

問題應明晰

漫無邊際的問題通常也被視為沒有明確限制的時間無底洞。最有可能給你有用答案的人通常也是最忙的人（假如只是因為他們承擔了大多數工作的話），這些人對於沒有限制的時間無底洞極其反感，所以他們也傾向於討厭那些漫無邊際的問題。

如果你明確了想讓回覆者做的事（如指點方向、發送代碼、檢查補丁或其他），你更有可能得到有用的回覆。這可以使他們集中精力並間接地設定了他們為幫助你需要花費的時間和精力上限，這很好。

要想理解專家生活的世界，可以這樣設想：那裏有豐富的專長資源但稀缺的回應時間。你暗中要求他們奉獻的時間越少，你越有可能從這些真正懂行也真正很忙的專家那裏得到回答。

所以限定你的問題以使專家回答時需要付出的時間最少──這通常還與簡化問題不一樣。舉個例，「請問可否指點一下哪有好一點的 X 解釋？」通常要比「請解釋一下 X」明智。如果你有甚麼代碼不運行了，通常請別人看看哪有問題比叫他們幫你改正更明智。

別張貼學校功課

黑客們善於發現「學校功課」式的問題。我們大多數人已經做了自己的學校功課，那是該你做的，以便從其經歷中學習。問一下提示沒有關係，但不是要求完整的解決方案。

如果你懷疑自己碰到了一個學校功課式的問題，但仍然無法解決，嘗試在用戶組論壇或（作為最後一招）在專案的「用戶」郵件列表或論壇中提問。儘管黑客們會看出來，一些高級用戶也許仍會給你提示。

刪除無意義的問題

抵制在求助消息末尾加上諸如「有人能幫我嗎？」或「有沒有答案？」之類在語義上無任何意義東西的誘惑。第一，如果問題描述還不完整，這些附加的東西最多也只能是多餘的。第二，因為它們是多餘的，黑客們會認為這些東西煩人──就很有可能用邏輯上無誤但打發人的回覆，諸如「是的，你可以得到幫助」和「不，沒有給你的幫助」。

一般來說，避免提「是或否」類型的問題，除非你想得到「是或否」類型的回答。

不要刻意標明問題緊急

這是你自己的問題，不要我們的。宣稱「緊急」極有可能事與願違：大多數黑客會直接刪除這種消息，他們認為這是無禮和自私地企圖得到即時與特殊的關照。

有一點點局部的例外，如果你是在一些知名度很高、會使黑客們激動的地方使用程式，也許值得這樣去做。在這種情況下，如果你有期限壓力，也很有禮貌地提到這點，人們也許會有足夠的興趣快一點回答。

當然，這是非常冒險的，因為黑客們對甚麼是令人激動的標準多半與你的不同。譬如從國際太空站這樣張貼沒有問題，但以代表感覺良好的慈善或政治原因而這樣做幾乎肯定不行。事實上，張貼諸如「緊急：幫我救救這個毛絨絨的小海豹！」肯定會被黑客迴避或令他們光火，即使他們認為毛絨絨的小海豹很重要。

如果你覺得這不可思議，再把剩下的內容多讀幾遍，直到弄清楚了再發貼。

禮多人不怪

禮貌一點，使用「請」和「謝謝你的關注」或者「謝謝你的意見」，讓別人明白你感謝他們無償花時間幫助你。

坦率地說，這一點沒有語法正確、文字清晰、準確、有內容和避免使用專用格式重要（同時也不能替代它們）。黑客們一般寧可讀有點唐突但技術鮮明的臭蟲報告，而不是那種禮貌但含糊的報告。（如果這點讓你不解，記住我們是按問題能教我們些甚麼來評價一個問題的。）

然而，如果你已經談清楚了技術問題，客氣一點肯定會增加你得到有用回覆的機會。

（我們必須指出，本文唯一受到一些老黑客認真反對的地方是以前曾經推薦過的「提前謝了」，一些黑客認為這隱含著事後不用再感謝任何人的暗示。我們的建議是先說「提前謝了」，事後再對回覆者表示感謝。或者換種方式表達，譬如用「謝謝你的關注」或「謝謝你的意見」。）

問題解決後追加一條簡要說明

問題解決後向所有幫助過的人追加一條訊息，讓他們知道問題是如何解決的並再次感謝。如果問題在郵件列表或新聞組中受到廣泛關注，在那裏追加此消息比較恰當。

最理想的方式是向最初提問的線此消息並在主題包含「已解決」、「已搞定」或其他同樣意思的明顯標記。在人來人往的郵件列表裏，一個看見線索「問題 X」和「問題 X – 已解決」的潛在回覆者就明白不用再浪費時間了（除非他個人覺得「問題」有趣），因此可以用此時間去解決其他問題。

你追加的訊息用不著太長太複雜，一條簡單的「你好 - 是網線壞了！謝謝大家 - 比爾」就比甚麼都沒有要強。事實上，除非解決問題的技術真正高深，一條簡短而親切的總結比長篇大論要好。說明是甚麼行動解決了問題，用不著重演整個排錯的故事。

對於有深度的問題，張貼排錯歷史的摘要是適當的。描述問題的最終狀態，說明是甚麼解決了問題，在此**之後**才指明可以避免的彎路。應避免的彎路部分應放在正確的解決方案和其他總結材料之後，而不要將此消息搞成偵探推理小說。列出那些幫助過你的名字，那樣你會交到朋友的。

除了有禮貌、有內容以外，這種類型的追帖將幫助其他人在郵件列表、新聞組或論壇文檔中搜索到真正解決你問題的方案，從而也讓他們受益。

除上述而外，此類追帖還讓每位參與協助的人因問題的解決而產生一種滿足感。如果你自己不是技術專家或黑客，相信我們，這種感覺對於你尋求幫助的老手和專家非常重要。問題敍述到最後不知所終總是令人沮喪的，黑客們癢癢地渴望看到它們被解決。「撓癢癢」為你掙到的好報將對你下次再次張貼提問非常非常的有幫助。

考慮一下怎樣才能避免其他人將來也遇到類似的問題，問問自己編一份文檔或 FAQ 補丁有沒有幫助，如果有的話就將補丁發給維護者。

在黑客中，這種行為實際上比傳統的禮貌更重要，也是你善待他人而贏得聲譽的方式，這是非常有價值的財富。

如何解讀回答

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

有一個古老而神聖的傳統：如果你收到了「RTFM」的回覆，發信人認為你應該去「讀讀該死的手冊」，他多半是對的，去讀一下吧。

RTFM 有個年輕的親戚，如果你收到「STFW」的回覆，發信人認為你應該「搜搜該死的網路」，他多半也是對的，去搜一下吧。(更溫和一點的說法是「Google 是你的朋友！」）

在網頁論壇，你也可能被要求去搜索論壇的文檔。事實上，有人甚至可能熱心地為你提供以前解決此問題的線索。但不要依賴這種好心，提問前應先搜索一下文檔。

通常，叫你搜索的人已經打開了能解決你問題的手冊或網頁，正在一邊看一邊敲鍵盤。這些回覆意味著他認為：第一，你要的資訊很容易找到。第二，自已找要比別人餵到嘴裏能學得更多。

你不應該覺得這樣就被冒犯了，按黑客的標準，他沒有不理你就是在向你表示某種尊敬，你反而應該感謝他熱切地想幫助你。

如果還不明白

如果你看不懂回覆，不要馬上回發一個要求說明的消息，先試試那些最初提問時用過的同樣工具（手冊、FAQ，網頁、懂行的朋友）試著搞懂回覆。如果還是需要說明，展現你已經明白的部分。

譬如，假如我告訴你：「聽起來像是某輸入項有問題，你需要清除它」，接著是個不好的回帖：「甚麼是某輸入項？」。而這是一個好的跟帖：「是的，我讀了手冊，某輸入項只在 -z 和 -p 開關中被提到，但都沒有提及清除某選項，你指的是哪一個還是我弄錯了甚麼？」

對待無禮

很多黑客圈子中看似無禮的行為並不是存心冒犯。相反，它是直接了當、一刀見血式的交流風格，這種風格對於更關注解決問題而不是使別人感覺舒服而混亂的人是很自然的。

你如果覺得被冒犯，努力平靜地反應。如果有人真的做了過格的事，郵件列表或新聞組或論壇中的前輩多半會招呼他。如果這沒有發生而你卻發火了，那麼你發火對像的言詞可能在黑客社區中看起來是正常的，而你將被視為有錯的一方，這將傷害到你獲取資訊或幫助的機會。

另一方面，你會偶而真的碰到無禮和無聊的言行。與上述相反，對真正的冒犯者狠狠地打擊、用犀利的語言將其駁得體無完膚都是可以接受的。然而，在行事之前一定要非常非常的有根據。糾正無禮的言論與開始一場毫無意義的口水戰僅一線之隔，黑客們自己莽撞地越線情況並不鮮見。如果你是新手或外來者，避開這種莽撞的機會不高。如果你想得到的是資訊而不是消磨時光，這時最好不要把手放在鍵盤上以免冒險。

（有些人斷言很多黑客都有輕度的自閉症或阿斯伯格綜合症，一定缺少平滑人類社會「正常」交往所需的腦電路。這既可能是真也可能是假。如果你自己不是黑客，興許你認為我們腦袋有問題還能幫助你應付我們的古怪行為。只管這麼幹好了，我們不在乎。我們喜歡我們現在這個樣子，並且一般都對臨床診斷有相當的懷疑。）

在下一節，我們會談到另一個問題，當你行為不當時會受到的「冒犯」。

別像個失敗者那樣反應

在黑客社區的論壇中有那麼幾次你會搞砸──以本文詳述或類似的方式。你會被示眾是如何搞砸的，也許言語中還會帶點顏色。

這種事發生以後，你能做的最糟的事莫過於哀嚎你的遭遇、宣稱被口頭攻擊、要求道歉、高聲尖叫、憋悶氣、威脅訴諸法律、向其雇主報怨、忘了關馬桶蓋等等。相反，你該這樣去做：

熬過去，這很正常。事實上，它是有益健康與恰當的。

社區的標準不會自己維持，它們是通過參與者積極而_公開_地執行來維持的。不要哭嚎所有的批評都應該通過私下的郵件傳送，這不是事情運作的方式。當有人批評你的一些主張或者其看法不同時，堅持聲稱個人被侮辱也毫無用處，這些都是失敗者的態度。

也有其他的黑客論壇，受太高禮節要求的誤導，禁止參與者張貼任何對別人帖子挑毛病的訊息，並被告知「如果你不想幫助用戶就閉嘴」。有思路的參與者紛紛離開的結果只會使它們變成了毫無意義的嘮叨與無用的技術論壇。

是誇張的「友善」（以上述方式）還是有用？挑一個。

記住：當黑客說你搞砸了，並且（無論多麼刺耳地）告訴你別再這樣做時，他正在為關心你和他的社區而行動。對他而言，不理你並將你從他的生活中濾除要容易得多。如果你無法做到感謝，至少要有點尊嚴，別大聲哀嚎，也別因為自己是個有戲劇性超級敏感的靈魂和自以為有資格的新來者，就指望別人像對待脆弱的洋娃娃那樣對你。

有時候，即使你沒有搞砸（或者只是別人想像你搞砸了），有些人會無緣無故地攻擊你本人。在這種情況下，報怨倒是真的會把問題搞砸。

這些找茬者要麼是甚麼也不懂但自以為是專家的不中用傢伙，要麼就是測試你是否真會搞砸的心理學家。其他讀者要麼不理睬，要麼用自己的方式對付他們。這些找茬者在給自己找麻煩，這點你不用操心。

也別讓自己捲入口水戰，大多數口水戰最好不要理睬──當然是在你核實它們只是口水戰、沒有指出你搞砸的地方，而且沒有巧妙地將問題真正的答案藏於其中（這也是可能的）之後。

提問禁忌

下面是些典型的愚蠢問題和黑客不回答它們時的想法。

好問題與壞問題

最後，我將通過舉例來演示提問的智慧。同樣的問題兩種問法，一種愚蠢，另一種明智。

愚蠢：我在哪能找到關於 Foonly Flurbamatic 設備的東西？

這個問題在乞求得到 STFW 式的回覆。

明智：我用 Google 搜索過「Foonly Flurbamatic 2600」，但沒有找到甚麼有用的，有誰知道在哪能找到這種設備的編程資訊？

這個人已經搜索過網路了，而且聽起來他可能真的遇到了問題。

愚蠢：我不能編譯某專案的原始碼，它為甚麼這麼破？

他假設是別人搞砸了，太自大了。

明智：某專案的原始碼不能在某 Linux 6.2 版下編譯。我讀了常見問題文檔，但其中沒有與某 Linux 相關的問題。這是編譯時的記錄，我做錯了甚麼嗎？

他指明了運行環境，讀了FAQ，列出了錯誤，也沒有假設問題是別人的過錯，這傢伙值得注意。

愚蠢：我的主板有問題，誰能幫我？

某黑客對此的反應可能是：「是的，還需要幫你拍背和換尿布嗎？」，然後是敲下刪除鍵。

明智：我在 S2464 主板上試過 X、Y 和 Z，當它們都失敗後，又試了 A、B 和 C。注意我試 C 時的奇怪症狀，顯然某某東西正在做某某事情，這不是期望的。通常在 Athlon MP 主板上導致某某事情的原因是甚麼？有誰知道我還能再試點甚麼以確定問題？

相反地，這個人看來值得回答。他展現了解決問題的能力而不是坐等天上掉餡餅。

在最後那個問題中，注意「給我一個回覆」與「請幫我看看我還能再做點甚麼測試以得到啟發」之間細微但重要的差別。

事實上，最後那個問題基本上源於 2001 年 8 月 Linux 內核郵件列表（lkml）上的真實事件，是我（Eric）當時提了那個問題，我發現 Tyan S2462 主板有神秘的死機現像，郵件列表成員給我提供了解決此問題的關鍵資訊。

通過這種提問方式，我給了別人可以咀嚼玩味的東西。我設法使之對參與者既輕鬆又有吸引力，也表明了對同行能力的尊敬並邀請他們與我一起協商。通過告訴他們我已經走過的彎路，我還表明了對他們寶貴時間的尊重。

事後，當我感謝大家並評論這次良好的經歷時，一個 Linux 內核郵件列表的成員談到，他認為並不是因為我的名字在列表上，而是因為我正確的提問方式才得到了答案。

黑客們在某種方面是非常不留情面的精英分子。我想他是對的，如果我表現得像個不勞而獲的寄生蟲，不管我是誰都會被忽略或斥責。他建議將整個事件作為對其他人提問的指導直接導致了本文的編寫。

如果沒有回覆

如果得不到回答，請不要認為我們不想幫你，有時候只是因為小組成員的確不知道答案。沒有回覆不等於被忽略，當然必須承認從外面很難看出兩者的差別。

一般來說，直接將問題再張貼一次不好，這會被視為毫無意義的騷擾。

還有其他資源可以尋求幫助，通常是在一些面向新手的資源中。

有許多線上與本地用戶組織，雖然它們自己不編寫任何軟體，但是對軟體很熱心。這些用戶組通常因互助和幫助新手而形成。

還有眾多大小商業公司提供簽約支援服務（紅帽與 Linuxcare 是兩家最出名的，還有許多其他的）。別因為要付點錢才有支持就感到沮喪！畢竟，如果你車子的汽缸墊燒了，你多半還得花錢找個修理店把它弄好。即使軟體沒花你一分錢，你總不能指望服務支援都是免費的。

像 Linux 這樣流行的軟體，每個開發者至少有一萬個以上的用戶，一個人不可能應付這麼多用戶的服務要求。記住，即使你必須付費才能得到支持，也比你還得額外花錢買軟體要少得多（而且對封閉原始碼軟體的服務支援與開源軟體相比通常還要貴一點，也要差一點）

如何更好地回答問題

**態度和善一點。**問題帶來的壓力常使人顯得無禮或愚蠢，其實他們並不是這樣。

**對初犯者私下回覆。**對那些坦誠犯錯之人沒有必要當眾羞辱，一個真正的新手也許連怎麼搜索或在哪找 FAQ 都不知道。

**如果你不確定，一定要說出來！**一個聽起來權威的錯誤回覆比沒有還要糟，別因為聽起來像個專家好玩就給別人亂指路。要謙虛和誠實，給提問者與同行都樹個好榜樣。

**如果幫不了忙，別妨礙。**不要在具體步驟上開玩笑，那樣也許會毀了用戶的安裝──有些可憐的呆瓜會把它當成真的指令。

探索性的反問以引出更多的細節。如果你做得好，提問者可以學到點東西──你也可以。試試將很差的問題轉變成好問題，別忘了我們都曾是新手。

儘管對那些懶蟲報怨一聲 RTFM 是正當的，指出文檔的位置（即使只是建議做個 Google 關鍵字搜索）會更好。

**如果你決意回答，給出好的答案。**當別人正使用錯誤的工具或不當的方法時別建議笨拙的權宜之計，應推薦更好的工具，重新組織問題。

**幫助你的社區從問題中學習。**當回覆一個好問題時，問問自己「如何修改相關文件或 FAQ 文檔以免再次解答同樣的問題？」，接著再向文檔維護者發一份補丁。

如果你的確是在研究一番後才做出的回答，_展現你的技巧而不是直接端出結果。_畢竟「授人以魚，不如授人以漁」。

鳴謝

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

提問

作者

修訂歷史

原文：How To Ask Questions The Smart Way

目錄

譯文

棄權申明

引言

提問前

提問時