當 Linux 終端

我希望你充當Linux終端。我將鍵入命令，您將回復終端應顯示的內容。我希望你只回復一個唯一代碼塊中的終端輸出，沒有別的。不要寫解釋。除非我指示你這樣做，否則不要鍵入命令。當我需要用英語告訴你一些事情時，我會把文本放在大括號里{像這樣}。我的第一個命令是

pwd

擔任英語翻譯和改進者

我希望你充當英語翻譯，拼寫校正和改進者。我會用任何語言和你說話，你會檢測語言，翻譯它，并用我的文本的更正和改進版本回答，用英語。我希望你用更漂亮、更優雅的高級英語單詞和句子代替我簡化的

A0 級單詞和句子。保持含義相同，但使它們更具文學性。我希望你只回復更正，改進，沒有別的，不要寫解釋。我的第一句話是“伊斯坦布爾 cok

seviyom burada olmak cok guzel”

擔任面試官position

我希望你扮演面試官的角色。我將成為候選人，你會問我這個職位的面試問題。我希望你只以面試官的身份回答。不要一次寫下所有的保護。我希望你只接受我的采訪。問我問題并等待我的回答。不要寫解釋。像面試官一樣一個接一個地問我問題，然后等待我的回答。我的第一句話是“嗨”position

充當 JavaScript 控制臺

我希望你充當JavaScript控制臺。我將鍵入命令，您將回復JavaScript控制臺應顯示的內容。我希望你只回復一個唯一代碼塊中的終端輸出，沒有別的。不要寫解釋。除非我指示你這樣做，否則不要鍵入命令。當我需要用英語告訴你一些事情時，我會通過將文本放在大括號內{像這樣}來做到這一點。我的第一個命令是控制臺.log（“Hello

World”）;

充當 Excel 工作表

我希望你充當基于文本的 excel。您只會回復我基于文本的 10 行 excel 工作表，行號和單元格字母作為列（A 到L）。第一列標題應為空以引用行號。我會告訴你要寫什么到單元格中，你只會將excel表格的結果作為文本回復，沒有別的。不要寫解釋。我會給你寫公式，你會執行公式，你只會回復

excel 表格的結果作為文本。首先，回復我空紙。

家好，我是檸檬哥，專注編程知識分享。

歡迎關注@程序員檸檬橙，編程路上不迷路

私信發送 1024 打包下載10個G編程資源學習資料

私信發送 001 獲取阿里大神LeetCode 刷題筆記

私信發送 002 獲取獲取谷歌公司編程代碼規范

私信發送 003 獲取10個精美簡歷模板PDF和Word版

私信發送 004 獲取100道精選 C++ 面試題和答案word版

私信發送 005 獲取獲取谷歌LeetCode算法筆記

私信發送 006 獲取侯捷C++全套視頻和下載方式

學編程難免遇到問題，遇到問題就需要上網求助。

然而有過不少同學向我訴苦，說在網上提問沒有人回答，有的還收到一些不是很友好的回復。我自己也經常在論壇上目睹過類似的帖子。以至于有人說，程序員社區就是對新人不友好，不愿幫助新人，甚至說這是怕別人學會了來搶飯碗。

對此我想證明一下，程序員們大多很單純，而且這或許是這個星球上最樂于分享的群體。但在這個充滿理性、邏輯至上的群體里，有著自己一套規則。當一個不懂規則的人出現在群體中，往往會被“教做人”。

如果你也曾遭遇這樣的問題，或今后打算在編程社區里成長，請務必看看我接下來要說的東西：

如何正確地和大神提問？

絕大部分得不到滿意回答甚至引來不滿的問題，都是問題本身的原因。提出一個好問題，對于提問者和回答者，都有很大幫助。

提問前準備

當你打算上網求助前，先問自己 2 個問題：

1.我搜索了沒有？

2.我檢查了沒有？

學編程，你不是一個人。幾乎所有你遇到的坑，都有前人踩過，搜索一下就會有答案。各種文檔、教程里的內容也都會包含在網頁結果中。搜索的關鍵是如何描述問題，所以要學會看報錯，能找到報錯中的關鍵信息。

編程界有兩個詞：RTFM、STFW，含義我不解釋，留給你自己去查。當看到有人在你問題下回復類似詞時，想想自己有沒有動手搜索過。

如果網上找不出你的問題，有幾種可能：

1.關鍵詞選得不準確；

2.你確實碰上了特殊情況；

3.你犯了某些低級錯誤。

對新手來說，3 的可能性更大。所以請務必自己檢查下，單詞拼寫對不對、標點是不是英文、縮進空格對不對、括號引號是否成對、文件路徑是否正確……

排除低級錯誤外，你還應當對錯誤做定位，盡量縮小范圍，增加必要的輸出。這在提問時也會極大方便回答者。而且我也經常跟人說，當你自己把必要的值都輸出出來看清楚后，通常問題已經很明顯了。

提問的內容

一個好的問題，應當是準確、具體、簡潔、完整，也就是既要清楚地表達問題涉及的信息，又不要夾雜無關的噪音。

具體來說，通常應包括這幾種信息：

1.問題的表現；

2.平臺和版本；

3.輸出的報錯信息；

4.相關部分的代碼。

最好還附上你的屏幕截圖（避免你沒意識到的錯誤）以及中間變量的輸出（方便回答者，同時也說明你自己嘗試過）。

特別說一下附上的代碼。對新手來說，最好同時提供截圖和代碼文字，截圖是展示電腦上的真實情況，文字是方便別人復現。如果你的代碼短，就全部發上；如果是很多代碼文件的項目，請自己先做初步的定位，只發關鍵部分的代碼。

如果你是在論壇、問答網站上發帖，取個好標題很重要。把問題在標題里簡要描述清楚遠好過“求助！在線等！挺急的”這種無意義的標題。

提問的形式

提問時，要選擇合適的地方，說合適的話。

比如你在一個進階論壇中問初學者的問題，往往會遭到排斥。反過來也不合適。

而至于什么才是合適的話，這個比較難把握。總的來說，禮貌永遠是好的，沒人愿意搭理傲慢、粗魯的提問。但有時候，效率比禮貌更重要。比如 StackOverflow 就禁止打招呼、感謝，因為這會帶來無效信息。你只需要精確描述問題、采納優秀回答即可。同樣，當你給別人提問時，直接了當地說明問題，絕對不要一句“你好，在嗎”，等到回復再來一句“我可不可以問你一個問題”這樣留言。或許你覺得這是禮貌，但對于別人來說，本來一次就可以回復的事情，硬生生被拖成幾個小時，可能根本就不理你了。

而當你發布在網上的問題最終被解決后，在問題后附上解法說明，按社區規則采納/點贊有用的答案，是值得推薦的做法。對于回答者來說，這比一句口頭贊賞更禮貌。

提問的禁忌

上面說了些建議，如果你還不夠理解，那么請記住，不要像這樣提問：

1.搜一步就可以解決的問題。比如“Python 里怎么讀取一個文件的內容”。

2.X-Y 問題。所謂 X-Y 問題，就是你要解決 X 問題，你認為可以用 Y 方法解決，然后你就問怎么實現 Y，但其實 X 問題根本就有更合適的解法。比如“我怎么取一個字符串的后 3 位”，而實際他想解決的是“怎樣獲取文件的文件類型”。

3.籠統而抽象的問題。比如“我能不能學會 Python”，這個問題被問的頻率很高，但這不該問別人，問你自己。

4.不要亂猜原因，甚至聲稱是別人代碼的 bug。你需要客觀描述和分析問題。比如“我一輸比 10 大的數就不對，是不是 Python 在我電腦上有問題”。

5.不要把多個問題混為一談，分清楚因果。代碼有不止一個錯誤是很正常的，如果別人的方法讓你的報錯發生變化，說明對上一個問題起了作用，這種情況需要進一步分析，而不是立刻回復一句“按照你的方法改了還是不行”。這種屬于真的不禮貌，會讓回答者不想再理你。

6.在開放的論壇、討論組、問答網站，盡量不要通過發私信、加好友的方式來提問。事實上，這種方式大多也無效。

7.不要妄想讓別人替你調試 bug、寫作業、開發。

提問的舉例

一個糟糕問題的例子：
哪位懂 Python 的幫我看下這是什么問題？
（一張幾十行的代碼截圖）

一個好問題的例子：
我的程序里將輸入和變量比較大小，結果報錯，請問是為什么？
我是 Python3
報錯：TypeError: '<' not supported between instances of 'int' and 'str'
（代碼+輸出的截屏、代碼文本）

一個更好問題的例子：
我的程序里將輸入和變量比較大小，結果報錯，請問是為什么？
我是 Windows 下的 Python 3.7
報錯：TypeError: '<' not supported between instances of 'int' and 'str'
提示是第 11 行：if answer < num:
我在前面加了 print，兩個變量都是有值的
（代碼+輸出的截屏、代碼文本）

提問的本質

提問的本質還是思考。如果你能提出一個好問題，必定是對問題思考后的結果。這對你本身也是一種練習。不思考就直接提問，既浪費了鍛煉的機會，也很難得到滿意的答復。

從另一個角度來說，天下沒有免費的午餐（也許有，但肯定有人付了錢），不要把別人回答你當做一件理所當然的事情。所以請尊重別人的勞動，并盡可能讓別人樂于回答你。不要提糟糕的問題就是最基本的要求。

說了這么多，你也不要因此而不想提問題。該問的還是得問，要敢于提問和討論，甚至要上 StackOverflow 等英語網站去問。不然怎么提高自己？不但要問，還要回答，“教”是最好的“學”。當你能向別人解釋清楚一個東西時，才是你真的理解了它。既回饋了社區，又提升了自己，何樂而不為？

最后，有篇很經典的文章，推薦給大家：
【英文版】How To Ask Questions The Smart Wayhttp://www.catb.org/~esr/faqs/smart-questions.html【中文版】提問的智慧https://github.com/FredWe/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md

文章來源于Crossin的編程教室 ，作者Crossin先生