溫馨提醒：點擊正文配圖可放大查看清晰大圖。
在寫英語技術文檔的過程中， 必定會遇到的一個問題就是：標題到底該大寫還是小寫？
為了便于理解，將這個問題拆分一下：
如果是一個比較成熟的產品，那可以選擇沿用現有規范。如果是一個比較新的產品，文檔尚未形成固定規范，那就需要做出一個選擇，制定一個規范，而且一旦制定就要嚴格遵循，確保一致性。
可以說，規范文檔的大小寫是從 style 的一個小方面出發來提高文檔質量。雖說大小寫是一個小方面，但它特別直觀，能快速地給文檔用戶留下第一印象。
在筆者看來，采用哪一種大小寫規范不是最重要的，關鍵是要統一使用一種規范，并嚴格執行下去。
就像一個與你穿衣風格迥然不同的人，如果做到極致的講究和精致，你很可能并不會覺得 TA 是錯的，反而會欣賞，因為那也是一種風格，那就是 TA 的風格。
正文結構：
大小寫規范具體指什么？
技術寫作中的大小寫規范主要包括兩種，即：-style 和 -style 。
從頁面呈現和視覺感知來講，兩種大小寫規范存在明顯差異。
為什么要確定大小寫規范？
1. 保持文檔風格的一致性，提高文檔的整體質量。
對于英語技術文檔來說，統一的大小寫規范可有效提高文檔的整體質量。
一個產品的技術文檔是一個整體，既然是一個整體，就要有這個整體所共同遵循的一些規則，而大小寫就是其中重要的一項。常見的 Style Guide 都有專門的 這一項。
在實際工作中，我發現其實中文技術文檔中也常常存在大小寫問題，只不過不局限于標題。
例如，一些產品名等特殊名詞技術文件英文怎么說，一旦確定了就應在所有文檔中保持絕對一致，而這一點是技術人員容易忽略的。對于文檔用戶，卻留下了潛在的困惑：咦，這前后說的到底是不是一個東西？這就需要在 這一環節格外注意。
2. 提升產品在用戶心目中的形象。
一個好產品可以給用戶留下一個好印象，一個好的文檔可以給用戶留下嚴謹、細致、規范、可靠的印象，進而提升產品印象在用戶心目中的形象。
相反，如果標題大小寫使用混亂技術文件英文怎么說，幾個大寫的交叉著一兩個小寫的，試想用戶會產生什么想法或者困惑呢？
如果是我，我可能會想：那些大寫的標題是否有特殊含義？為什么有的大寫有的小寫？這個產品的文檔質量不怎么樣啊，有點兒亂……雖然我不是處女座，但看起來好難受，簡直不能忍……
一言以蔽之，確定并遵循大小寫規范有利于保證文檔風格的一致性，提高文檔質量，提升產品形象。
知名 Style Guide 中的大小寫規范
現在已經清楚了什么是大小寫規范，以及確定大小寫規范的必要性。
那么，業內熟知的一些 Style Guide 對大小寫規范是如何限定的呢？接下來分享一下 IBM Style Guide 和 Style Guide 中對大小寫規范的描述。
IBM Style Guide
這里所說的 IBM Style Guide 指的是下面這本書：
在 The IBM Style Guide 中，大小寫規范放在了 1 and 下。具體見下圖：
其中，關于 的使用概括如下：
In , use a style in text and use -style for .
具體到 in and 部分：
Use -style for these items:
那 title 就沒有用大寫的時候嗎？有的，往下看：
除了標題外，大小寫在其它場景的使用也有其規范，這些場景已在上面的圖里列出，感興趣的小伙伴可以去看看。
Style Guide
這里所說的 Style Guide 指的是 Style Guide。
鏈接：
與 The IBM Style Guide 類似， Style Guide 也將 放在了 and 目錄下。
其中，關于 in and 部分的規范描述如下：
In and page , use case. That is, only the first word.
: for nouns, , , and other terms that are a way, use the for the term, of where it in the title or .
Even you're using case, don't put a at the end of a .
小結：綜上來看，無論是 IBM Style Guide，還是 Style Guide，都對標題采用的 -style ，即只對標題中的第一個單詞采用首字母大寫。
實際英語技術文檔中的大小寫應用現狀
注：此部分配圖均截圖自產品的官方文檔，截圖日期為 2018 年 1 月 14 日。不排除該日期后會有更新完善，特此說明。
據筆者觀察，即便是國內外大公司，也很難做到標題大小寫風格的完全統一。
如果是一個人寫文檔，保持一種風格相對容易；如果是很多人協作，涉及流程管理，那就難免會有疏漏。
先來看下上面提到的 IBM 和 的文檔，兩者均在 Style Guide 中寫明對標題使用 -style，這也是筆者常見到的技術文檔標題規范。但是，在實際的技術文檔中，反倒是 -style 較為多見。
那么，具體一點，當前實際的產品文檔是如何處理標題大小寫的呢？
別急，馬上就給你舉栗子啦！栗子包括三部分：
IBM DB2 文檔標題的大小寫
以 IBM 的 DB2 為例，其文檔總體采用的 -style。
IBM DB2 文檔鏈接：
但是，也存在大小寫不一致的情況，如下所示：
這里的 "" 不應該使用首字母大寫。
另外，多說一句，還順便發現了其它一些問題，如下所示：
依筆者之見，不論是哪家公司的文檔，只要你帶著一雙敏銳的眼睛去看，總能發現一些問題，而且很容易發現。
Cloud 文檔標題的大小寫
以 的 Cloud 為例，其文檔采用的大小寫規范是：頁面標題（一級標題）采用的是 -style，文內標題采用的則是 -style。
Cloud 文檔鏈接：
第一次看到時的反應是：納尼，還可以玩混搭？
別說，似乎效果還不錯，因為這樣頁面標題和文內標題的區分更明顯了。在總目錄里顯示的是 -style 的大標題，點擊一個標題進去，右側顯示的是 -style 的本文目錄。
地址：
整體來看， Cloud 文檔的大小寫使用還是比較統一的，筆者感覺比 IBM DB2 的更易用，無論是文檔架構還是頁面設計。
雖說瑕不掩瑜，但是呢，也存在一些小瑕疵，比如：
這里一個 "using" 忘記采用首字母大寫了……
如此看來， Cloud 文檔也并沒有做到嚴格遵循 Style Guide。
DB- 排名前十的數據庫文檔
鑒于筆者當前工作是數據庫產品的 ，于是參考 2018 年 1 月份的 DB- 排名，對數據庫產品的文檔進行了一個關于大小寫規范的小調查。
2018 年 1 月排名
那么問題來了，DB- 是個什么鬼？
鏈接：
The DB- ranks to their . The is .
大小寫規范的調查結果如下表所示：
注：上表統計為某個產品文檔總體的大小寫風格，如果在 -style 中夾雜著個別 -style 或者疏漏導致的大小寫不一致，不計入此表。
為了讓大家快速直觀地理解，下面上幾個比較有代表性的圖：
-style
MySQL -style
SQL -style
-style
-style
兩種 style 混用
兩種 style 混用之 -style
兩種 style 混用之 -style
如何為技術文檔選擇大小寫規范？
看到這里，你已經對英語技術文檔中的大小寫規范有了一個較為全面的了解。
當前情況是：在 Style Guide 中的文字規定中，往往是 -style，但在實際的應用中卻是 -style 居多。即便是明確制定規范者，也并沒有完全依照規范執行。
那么，如果你要給一個新產品寫英語技術文檔，該如何選擇大小寫規范呢？這里筆者給初入技術寫作的小伙伴提供一種解決思路：
What：搞清楚技術文檔中的大小寫規范指的是什么。
Why：為什么要確定大小寫規范。
站在前人的肩膀上：了解那些全球知名大公司是如何規定大小寫規范的。
清楚行業現狀：了解產品所屬領域的佼佼者們的文檔大小寫現狀。
發揮主觀能動性：理論規范+實際現狀+主觀決定。
對于英語技術文檔標題的兩種大小寫規范，很難說哪一種是對的，哪一種是錯的，可以說并無對錯之分。
無規矩不成方圓，有規矩不遵循同樣不成方圓。
采用哪一種大小寫規范不是最重要的，審慎地選擇和確定一種大小寫規范，然后嚴格執行和遵守才是最重要的。
如果你好奇筆者當前做的文檔采用的是哪種規范，可以去看看 的英語文檔：
是的，采用的是類似 Cloud 文檔的大小寫規范，即 -style + -style。需要說明的是，這兩種 style 的組合使用并不是“混用”，而是有嚴格區分的：頁面標題（一級標題）采用 -style，文內標題采用 -style。
之所以最終選擇此種大小寫規范，主要考慮以下幾點：
Cloud 的文檔閱讀體驗不錯，清晰無混搭雜亂之感。
兩種 style 組合使用，可以讓頁面標題和文內標題的區分更加明顯，閱讀頁面內容時不易混淆。
結合當前行業書面規范與實際使用現狀，不必拘泥于傳統的廣為人知但實際應用率不高的行業規范。
發揮主觀能動性，做決定！哈哈……
不要忘了，如有任何技術傳播相關的問題或不同見解，歡迎在文末隨意留言哦！
DB- 排名前十的數據庫文檔參考鏈接：
1.
2. MySQL
3. SQL
4.
5.
6. DB2
7.
8.
9. Redis
10.
你可能想讀
技術傳播那些事兒
知乎專欄：
簡書專題：