本文作者：叫我vitamin
本文來源：皮醬叨逼叨（pijiangdbd）
---BEGIN---
1. 前言寫這篇文章的原因是我前前後後看到過好多次標點符號之爭，同時我又是一個較真、愛折騰的人，再加上日常工作中總是會涉及到大量的文檔，寫作內容等，所以我對標點符號的一些理解和看法也會一些自己的心得感受。
剛好今天無意中刷到《少數派》的一篇文章，於是就趁此機會來談談我對產品文檔的一些特殊標點符號的理解和看法。
日常使用特殊的標點符號時遇到了很多疑惑，還有挺多疑惑至今沒有解決，所以此篇有拋磚引玉的作用，希望各位讀者朋友能解答我的一些疑惑。
我對標點符號的用法鑽研的不是很深，所以此篇文章只是我個人經驗分享之談，並非金科玉律、標準方案，請大家辯證性對待。
2. 標點符號的標準規範國家對標點符號的使用是有一套專門的標準規範的，感興趣的可以去看看：
http://www.moe.gov.cn/ewebeditor/uploadfile/2015/01/13/20150113091548267.pdf
其實大多數人都不是專業的編輯或者文字工作者，所以對標點符號的使用基本上不會過於嚴謹，只要能斷句、表達清楚意思即可。尤其是現在網際網路時代，文字表達的場合越來越多，很多行文方式都傾向於口語化，多元化和個性化（表情包和emoji等）。
所以國家標準更多的是適用於正規場合，而日常的工作交流等其實還是沒有那麼強的約束性的。所以如果大家看到了這篇文章中有很多地方使用的標點符號是不標準的，也不用急著跳出來批判我，畢竟這並非是一篇嚴謹的學術研究論文，請大家寬容一些看待。
本文想表達的是一些我在日常寫作時，發現的文檔排版和特殊的標點符號使用的一些困惑，以及我的解決方案。
標準的標點符號使用規範可以看上方的連結，這裡就不再過多的討論了。
3. 日常寫作中，我的幾點困惑1. 直角引號和彎引號「」和「」之爭由來已久，最早的大規模爭論應該是發生在2012年左右的知乎上。直角派和彎角派爭論了很久還是無法統一，但是越來越多的社區開始學習知乎的方式，使用直角引號來替代彎引號了。
我個人其實是更偏向於使用直角引號「」的，一方面是美觀的問題，另外一方面是識別性高（有些字體全形和半角的彎引號很相似）。但是隨之而來的困擾也來了，最大的一個困擾就是：
❝
很多人都不知道如何輸入「」這個符號，Mac可以直接鍵盤使用Shift+【】來輸入，而其他的一些輸入法可能需要使用一些特殊方式才能方便輸入這個符號。
很多文檔是需要協作性工作的，如果我習慣性使用「」，而有一些同事習慣使用「」，那麼這樣協作出來的文檔肯定會不太美觀。
2. 中英文混排的問題中英文混排其實有很多人都不知道中英文混排的規則應該是怎麼樣的，不僅僅是空格的問題，還有一些斷句的符號怎麼選擇也是很多人不知道的。我上次在知乎上無意中看到一個答案，大概的意思是：
如果全文是以中文為基調的，那麼應該以全形標點符號為主體。
在Github上也有相關的指北，具體可以看下方的連結：
https://github.com/mzlogin/chinese-copywriting-guidelines
中英文混排-空格
很多程式設計師、產品經理可能都聽說過中英文混排加空格的規則，但是講實話對於經常要寫文章的人來說，加空格其實比較麻煩，會對寫作的流暢性有所影響。而且這個能遵守這個規範的人還是少數，這樣就會導致在協作的時候，有些人辛辛苦苦加空格；有些人一路寫到底，壓根不加空格。
難以統一行文風格，一直是團隊文檔協作的難題之一。 尤其是本職工作已經很多的情況下，如果還要對標點符號吹毛求疵，很容易被團隊小夥伴「圍毆致死」。
所以我選擇尊重團隊中大多數人的習慣，中英文混排時不加空格，但這也許在另外一個團隊中就是不被認可的了。
3. 操作文檔的一堆名詞怎麼寫其實無論是直角引號還是彎角引號，中英文混排加空格還是不加空格，其實更多的是影響文章閱讀的美觀性而已。但是操作文檔中的一堆名詞寫作，如果沒有使用好「準確」的標點符號，可能就會引起歧義或者讓閱讀者感到吃力。
語雀的官方手冊
語雀使用「」來突出一些操作、按鈕或者關鍵名詞。
蘋果官網的手冊
蘋果使用「」來標記相關的App、頁面、操作、按鈕或者關鍵名詞等。
菜鳥WMS的手冊
菜鳥使用【】來標記相關的操作、按鈕或者關鍵名詞等。
以上是我隨手找的三個操作文檔的案例，總體上來看，似乎代表著「三大流派」。
優點是統一性很強，都凸顯了專有的名詞和信息；
缺點是統一性太強了，導致分不清代表的分別是什麼（是可以接受的缺點）。例如蘋果官網的那張圖「設置」>「蜂窩網絡」>「蜂窩數據選項」，其中「設置」是代表一個App，而「蜂窩網絡」和「蜂窩數據選項」是一個菜單選項。對於一些不熟悉的用戶來說，第一印象可能會不太好區分「設置」到底是指什麼？當然這是我吹毛求疵的看法，我本人還是很認可蘋果的這種做法的。
4. 我總結的特殊標點符號的規範頁面當描述的內容包含某個菜單頁面的時候，建議使用「」或者「」，後面增加名詞修飾。
Tab欄或狀態當描述的內容包含了某個頁面下的Tab信息或狀態的時候，建議使用「」或者「」，後面增加名詞修飾。
欄位或者行內代碼當描述的內容包含某個新增的欄位的時候，建議使用 反引號（`code`）來表示。
按鈕或者功能當描述的內容中需要點擊某個按鈕或者使用某個功能的時候，建議使用【】來表示，不建議使用「」是怕直角引號太多，代表的含義太雜引起閱讀負擔。
組合示例當一段描述中包含上述所有關鍵詞時，甚至還有一些特殊的情況時，可以靈活變動，使用括號()，直角引號「」或彎角引號「」（但是不建議同時出現直角和彎角引號），或者使用加粗，下劃線，文字顏色，背景顏色等。
5. 總結上面總結的一些規範，僅適用於某些很小眾的場景下，大多數情況下只需要遵守標點符號的標準規則即可。若按標準規則來判定，裡面的一些符號用的也不是很標準。但是苦於這一塊的信息太少了，可交流的機會並不多，所以我只能先摸索著前行，後續再看實際情況而迭代更新了。
上述內容都是基於Markdown的編輯形式，如果是使用富文本的方式，那麼有一些樣式或者符號可能不支持。對於產品經理來說，我建議無論是需求文檔還是操作手冊，還是一些日常的經驗沉澱積累，都用Markdown來寫。
至於原因是什麼？自己查一下，體驗一下就會知道了。
如果你有更好的規範或者見解，歡迎與我私聊交流，因為這一塊的疑惑已經困擾我很久了，我也想聽聽各位大佬的意見。
6. 參考資料《少數派寫作排版指南》
《別再用「六個點」當省略號了，這些標點都有更規範的輸入方式》
《設計師與標點符號》