程序員如何訓練自己的書面表達能力？

01-12

比如如何寫好技術文檔？
如何把複雜的原理講清楚？

這其實是個非常好的問題，能發現這個問題，能發現這是一種可以提高的技能，就很有提升的可能了。

文字表達能力，每個人在小學時候，就開始積累和影響你的一生了。如果你有幸遇到一個語文班主任，又在小學時期里，不斷堅持給你認真上閱讀理解課，或者優秀文章賞析。竭盡全力希望提高全班的作文水平，那你就有福了。

文字只是工具，表達能力其實是邏輯思維能力的體現，一件事情如果對其了如指掌，自然就更容易寫出思路清晰，深入淺出的好東西來。這話題有些大，我只能說我總結出來的幾點，絕對不敢、也談不上全面解釋這個問題。

重點技能1，換位思考能力，作為程序員，你應該知道那種感覺，當你設計一個界面的樣式結構的時候，或者寫一個按鈕的邏輯操作時候。大腦會浮現出，最終用戶，在一個什麼情況下，點擊這個按鈕，然後後面一系列的變數、數據、循環的過程，有時候會很形象的出現一些畫面和感受吧。。這就是最基本的換位思考能力。要寫出好東西，沒有換位思考的能力，寫不出好東西的。因為你無法模擬讀者的想法，理解不了讀者，就別提什麼文字技法了。。因為你根本不知道，這麼寫了聽眾或觀眾是個什麼感受，也就無從不斷改進自己的作品，也就無法提升自己的文檔水平。

試想一個情景，一個普通電腦水平的客戶，突然闖進公司，與你溝通起一個電子支付的流程問題。這時候你如果跟他說：「這個系統要第三方網銀API介面支持才能實現！」，這句話對另外一個程序員來說，應該沒問題的，大家都懂的。但如果是普通用戶，他是否懂什麼叫API呢？也許聽過這個詞和模糊的意思，但他在模糊的狀態下，對後續的溝通就會產生越來越大的疑惑。

我不糾結用戶對API這個詞的理解程度問題，但我希望你看到用API這個詞，體現了程序員的行業習慣，是我們的行話，沒有站在聽眾的立場上，優化這句話的表達方式。另外請注意，如果平時你不跟聽眾溝通，不從他們的溝通中，研究他們對每個詞、每件事的看法和理解程度，就一直寫不出適合給他們看的東西。同樣道理，如果你是給上司彙報，那就得揣摩上司的知識結構、用詞習慣、思維焦點等等

重點技能2，永遠緊抓主題，每寫2頁PPT，都要強制自己想一下，前面幾頁，是否都是與主題非常相關的內容。如果回答是相關的，那還要問自己能不能更直接、更緊密、更簡練的體現出與主題的相關性。我見過不少人寫的東西，圖文華麗，但不夠與主題相關。配合上他的解說，讓我覺得廢話太多，聽著真沒勁，容易走神。究其所有，最終指向都是與主題扣的不夠導致的。小時候，老師一定也不斷重複要求你，作文一定要緊密與主題相關，跑題就最多只能拿一半分數。我認為訓練這件事情，真的非常之重要，我只恨當年訓練的還不夠。

緊扣主題這件事情，你要充分的在工作中不斷訓練自己才行，永遠要珍惜別人看你東西所花費的每一秒鐘。在正確理解你想表達的核心主題的基礎上，佔用聽眾觀眾的時間越短越好。喬布斯的演講，不誇張的說是可以精確到每個詞，每一秒的。（喬布斯自傳里有說明這一點）

緊扣主題，還體現在你再精簡內容上的文字功力。舉例來說，我給這篇文章想一個一句話主題：

平述版：「深入了解用戶對信息的接受能力和習慣，保證你說的每一句話，都能被他們正確理解，並且能緊扣主題，不要浪費他們的時間！」

華麗版：「優秀的作家，可以預言你下一秒應該想到情景，文字只是他們操縱你心靈的工具！」

懸念版：「他們先把一堵牆粉刷的亂七八糟，唯獨留下那一抹空白，供你逃避這一切！」

口號版：「讓外行覺得通俗易懂，讓內行覺得大有收穫！」

等等！等等！圍繞一個主題造句，我可以寫出很多種變化。這是文字功底么？我認為不是，內行一看，上面的東西不講究，甚至不通順。但我不在意，因為上面的文字，可以在各種場合，配合各種各樣的聽眾。先是邏輯主題理解的清晰，再是換位思考能力要鍛煉，平日里對各種高手寫的廣告、新聞、微博都能敏銳的撲捉到，這是一段非常優秀的文字。（心中會有感嘆，哇噢~！太牛叉了，這什麼樣的人想出來這樣的表達方式，我真想認識一下這位作者。。一定是個妙人。。等等！）

沒有羨慕，就不會有學習的念頭，沒有把學習融入到生活的每一刻當中，是學不好這門功課的。所以我說，這是個好問題，因為我已經感受到您那種羨慕的心情了。呵呵。。

P.s. 前文不改了，按說是應該精鍊一番，另外我覺得也不是直接命中問題，廢話太多。但我猜想這種即興的手法，可能更適合這個場景，更適合您的口味！呵呵。。

基本的寫作素養是很重要的，可以通過平時寫郵件，寫報告中有意識的訓練。

技術寫作的好處是你可以大大方方地追求精簡，這和大多數人接受的寫作教育正好相反，中國學生出學校一身的「鋪陳」本事，技術寫作根本不需要。有本書叫How to Write Short，可以給你一個正確的技術寫作觀。

前面 @郝欣誠的答案里說的永遠抓緊主題，有時候意味著削掉（很多）不重要的細枝末節，一個文檔說清楚一個層次上的問題，而不需要說清所有層次上的問題。應該避免在一個文檔里囊括所有細節，儘管這樣寫下來表面雖詳實，可讀性就剩沒多少了，沒有人真有這個耐心去讀一個事無巨細的技術文檔。

結構和內容一樣重要，因為看技術文檔很少像讀小說順次讀下來，基本都是要提綱挈領地根據要尋找的內容從組織結構里找到入口，然後切入進去讀一部分。合理安排好結構是幫助用戶快速找到內容的關鍵。

比如https://support.apple.com/manuals/，條理清晰，易於尋找，文檔主體又十分精簡，是好文檔的典範。Google 「best API documentation」可以知道很多其他例子，如

Ask HN: What"s the best API documentation you"ve ever seen?

Stripe API Reference

不要說你上不了Google
https://www.linkev.com/?a_aid=itlr

多看、多寫、多改。

如果有強勢領導壓著你天天加班寫材料，基本上不是傻子都能練出來。

1.軟體工程。好好讀幾遍，特別是需求和需求規約，結構化分析，結構化設計這三個部分。仔細體會自頂向下逐步求精，模塊化結構。

2.用（主）＋謂＋賓結構。

3.找幾篇碩士論文，按上述原則進行修改。直至結構清晰，層次分明，觀點明確，重點突出為止。