[經驗] 美式履歷表，電報寫作風格(telegram style)
這幾年在幫忙訂正、討論美式履歷表寫作時，發現許多人對電報寫作風格(telegram
style)很陌生，現在終於有時間寫篇文來討論這個題目 :)
這個主題雖然是以「英語」為出發點，但其在美式履歷表寫作上的應用，讓我覺得
更適合發在這個版 :)
* 網頁版: http://www.30abysses.com/TWY/2017/01/24/telegram-style.html
========================================================================
# 英語，寫，電報寫作風格(telegram style)，美式履歷表
因為在電報時代發電報是以字計價，所以就沿生出
「電報寫作風格([telegram style][1])」 ；該寫作風格以保持原文文意（不造成
誤會）為前提，儘可能地減少字數，就算最後寫出來的句子不完全符合文法也無所
謂。
例如，[萊特兄弟在 1903-12-17 試飛成功後發的電報][3] ：
> Success four flights thursday morning all against twenty one mile wind
> started from Level with engine power alone average speed through air
> thirty one miles longest 57 seconds inform Press home Christmas .
> Orevelle Wright
雖然文法上不正確，但仍有效傳達了訊息。
這種寫作風格在今日的新聞標題這類空間有限的地方仍十分常見，也稱作
標題文體([headlinese][2]) 。
[1]: https://en.wikipedia.org/wiki/Telegram_style
[2]: https://en.wikipedia.org/wiki/Headlinese
[3]: https://en.wikipedia.org/wiki/Telegram_style#Example
# 美式履歷表
對一般人來說，電報寫作風格最有用的地方，大概就是用來寫美式履歷表；有在網
路上聽過一種 **錯誤** 的觀念，認為寫美式履歷表就是「把動詞換成過去式再拿
掉主詞」，那只說對了一半。正確的說法是使用電報寫作風格。
以下是個 **極簡略** 的例子：
> I managed a team of 3 members.
>
> 我管理過一個三人團隊。
就會寫成
> Managed team of 3.
而讀者可以從上下文(context) 讀出被省去的字；例如， I 被省去了，但因為這
份文件是履歷表，所以主詞自然是 I ； members 被省去了，但因為是談到
"managed ... team", 所以知道 3 應該指的是團隊大小。
在履歷表上使用電報寫作風格的好處，就是節省篇幅，也減輕讀者的工作量。在此
要重申一次，這裡舉的這個簡略例子是單純為了解釋電報寫作風格，實際上在撰寫
履歷表時，切忌這種流水帳式的語氣，而是要以成果(result)、細節(specifics)
、實例(example) 為寫作主軸，這個以後會再談。
# 學習與應用
電報寫作風格在語言學上的正式名稱為 [ellipsis][4] ，可譯作「省略語法」。
[4]: https://en.wikipedia.org/wiki/Ellipsis_(linguistics)
以下幾個網頁有對省略語法更詳盡的說明：
* Ellipsis (linguistics):
[https://en.wikipedia.org/wiki/Ellipsis_(linguistics)][4]
* Headlinese: [https://en.wikipedia.org/wiki/Headlinese][2]
* "HOW TO WRITE TELEGRAMS PROPERLY":
[http://www.telegraph-office.com/pages/telegram.html][5]
[5]: http://www.telegraph-office.com/pages/telegram.html
除了上述的新聞標題、履歷表之外，這種寫作風格適合寫操作手冊、使用方法，尤
其是瓶罐包裝標籤（非常受限的印刷空間）這類說明時使用。
在維基百科關於省略語法([ellipsis][4]) 的頁面上，有更進一步以實例解釋許多
看似不符合文法的句子；這類句子在學術、文學英文中較常出現，例如：
> Friendship often ends in love; but love in friendship -- never.
>
> Charles Caleb Colton
（出處： [https://en.wikiquote.org/wiki/Charles_Caleb_Colton][6] ）
[6]: https://en.wikiquote.org/wiki/Charles_Caleb_Colton
就是省去了後半句話中的 ends ，也就是 [verb phrase ellipsis][7] 的應用；
若還原成完整的句子，就會是：
> Friendship often ends in love; but love never ends in friendship.
[7]: https://en.wikipedia.org/wiki/Verb_phrase_ellipsis
# 結論
電報寫作風格／省略語法對ＥＳＬ人士來說，算是較高階、複雜的英語文法（要先
知道如何寫出正確、完整的句子，才能正確的簡化且不失文字本意）；最直接的應
用大概就是寫美式履歷表。我認為，對省略語法的概念先有基本的認識即可，至少
在遇到省略語法的文體時有個概念，待語感養成之後，再多讀多吸收這類進階文法
的應用範例。
========================================================================
後述
我開了個 github repo:
https://github.com/teach-and-learn/write-resume/issues
有心想練習電報寫作風格/美式履歷表的，可以把這個 repo 當討論區使用 (例如
，挑一句「你想寫在履歷表上但沒信心寫得對不對的話」，開個 issue 提問，我
儘量回答，大家也可以討論切磋)。
要在 PTT 這裡推文討論也是可以 (我這篇文也有發到我的臉書版面，也是可以在
那裡討論) ，但感覺上 GitHub issue 的介面比 PTT 推文/臉書討論串更適合這種
討論，也方便後人蒐尋、觀摩 :)
有意見、建議、問題，請不吝指教 :)
--
個人 雜談、學習、英語、軟體
https://www.facebook.com/tw.yang.30 https://www.facebook.com/30abysses/
https://twitter.com/twy30 http://www.30abysses.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 72.211.194.61
※ 文章網址: https://www.ptt.cc/bbs/Oversea_Job/M.1485260723.A.672.html
※ AmosYang:轉錄至看板 Soft_Job 01/24 20:26
推
01/24 23:30, , 1F
01/24 23:30, 1F
推
01/25 00:57, , 2F
01/25 00:57, 2F
剛再看了一次，覺得你說的對，很可能是
> Friendship often ends in love; but love in friendship never ends.
> Friendship often ends in love; but love never ends in friendship.
讓我再研究一下，感謝指正 orz
※ 編輯: AmosYang (72.211.194.61), 01/25/2017 04:27:35
剛從 archive.org 找到了原文
> Friendship often ends in love; but love, in friendship--never.
wikiquote 上的版本少了原文 "love, in friendship" 中間的逗號，而因為那個
逗號，我認為你是對的；再次感謝指正 orz
我會儘快更正我發出去的文章。
※ 編輯: AmosYang (72.211.194.61), 01/25/2017 04:41:29
# 更正啟事
之前將 Charles Caleb Colton 的
> Friendship often ends in love; but love in friendship -- never.
錯誤地還原成
> Friendship often ends in love; but love in friendship never ends.
>
> 友誼常常最後變成愛情；但友情中的愛從不停息。
正確的還原應該是：
> Friendship often ends in love; but love never ends in friendship.
>
> 友誼常常最後變成愛情；但愛情最後不會變回友情。
## 考證經過
經 [boblu @ ptt.cc 提出疑問][8] ，再查證[原文][9] 後，發現原文與
wikiquote.org 的版本有微妙的出入：
[8]: https://www.ptt.cc/bbs/Oversea_Job/M.1485260723.A.672.html
[9]: https://archive.org/details/laconormanythin11coltgoog
[wikiquote.org 的版本][6] ：
> Friendship often ends in love; but love in friendship -- never.
[原文][9] ：
> Friendship often ends in love; but love, in friendship -- never.
也就是在後半句， love 與 in friendship 之間，原文裡有個逗號；是故，正確
的還原方式應該是
> Friendship often ends in love; but love never ends in friendship.
在此再次感謝 boblu @ ptt.cc 的指教。
※ 編輯: AmosYang (72.211.194.61), 01/25/2017 05:48:02
※ 編輯: AmosYang (72.211.194.61), 01/25/2017 15:15:47
推
01/25 16:21, , 3F
01/25 16:21, 3F
推
01/25 23:56, , 4F
01/25 23:56, 4F
:)
推
01/26 08:21, , 5F
01/26 08:21, 5F
→
01/26 08:22, , 6F
01/26 08:22, 6F
這應該無所謂「老派」與否；就只是「在不造成誤會的前提下儘可能地減少字數」
。一般履歷表寫作，也沒必要考究到省略語法(ellipsis)，拿掉不必要的主詞、名
詞、冠詞，大概就差不多了。
可以參考這裡的例子: https://resumewriternatalie.wordpress.com/2015/08/31/master-the-telegraphic-writing-style/
推
01/26 11:27, , 7F
01/26 11:27, 7F
這麼說吧
(1) 履歷表用字精確
(2) 拿到 job offer
(3) 履歷表被刷掉
* (1) 不見得一定會導致 (2)
但是
* !(1) 導致 (3) 的機會應該不小 XD
以我知道的數據，軟體業職缺數與求職人數相比，大約小 2~3 個數量級；一般人
無法知道 HR 會用什麼方法來處理這麼多求職申請書 :D
多一個 an ，少一個 the ，並不至於被判出局，但無法知道的是另外 99 或 999
份申請書會不會看起來比你的更好看。是故，抱著盡善盡美的心態去準備，但也無
須患得患失。
(軟體業)求職這回事，變數很多，沒有一個精確的準則，的確令人無所適從；然而
，也就是因為沒有一個統一的準則，人人都有機會。
反過來想，如果一個行業的求職變成能標準化的過程，那就代表了替代性高，人人
都可作，誰來作都一樣，那大概就沒什麼金可淘了 :)
※ 編輯: AmosYang (72.211.194.61), 01/26/2017 15:39:24
推
01/26 23:19, , 8F
01/26 23:19, 8F
→
01/26 23:20, , 9F
01/26 23:20, 9F
不知道你所謂的「差距」是指
(1) 確實節省的空間量、比率
(2) 對求職過程的影響
兩者我都沒有數據可回答 :)
就像是「通過門時，用手扶著門好讓下一個人方便通過」，為對方節省的時間是否
值得我被擔誤的時間？是否值得對於建立人際關係的正面效應？
我也是沒有數據可回答 :)
易言之，技術上來說，這的確可以說是一種「迷信」 XD
→
01/26 23:20, , 10F
01/26 23:20, 10F
→
01/26 23:21, , 11F
01/26 23:21, 11F
推
01/26 23:23, , 12F
01/26 23:23, 12F
→
01/26 23:24, , 13F
01/26 23:24, 13F
→
01/26 23:24, , 14F
01/26 23:24, 14F
能理解。
以我的經驗，就科技、軟體業來說，我會這樣排。
* 基本功: **至少要讓看的人願意看超過五秒**，版面乾淨、無贅字、突顯關鍵字
- 所謂版面乾淨就是白紙黑字，沒有「視覺噪音」。
- 無贅字就是沒有 I ... I ... I ... I this ... I that ...
- 突顯關鍵字，就是 job description 上的最重要前三至五項需求，其對應的關
鍵字用粗體標出。
易言之， telegram 風格、字型、排版的階段性任務，就是撐過這前五秒，才有接
下來的二十五秒。
就像是廣告一樣，作得精美的廣告不見得能說服你花錢，但作得不好的廣告可能連
吸引你看三秒都辦不到。
* 語氣、內容
- 切忌流水帳、自傳
- 切忌被動語氣
- 切忌一稿通用
- 專注於成果、實例、細節的三段連續技，把讀者的「注意力」當成對手：
浮空→連擊→追打
易言之，你有 25 秒，強調你的價值，而不是你的「食品成分表」
至於「排版、字型」，我通常文字版用 markdown 寫，直接轉成 HTML/PDF 出稿。
唯一會微調的大概就是四邊的留白，其他的沒去碰過。
格式，我習慣就最基本的條列式；另一位鄉民建議「左右分兩欄」，挑自己喜歡的
就好。
> http://www.30abysses.com/TWY/2016/11/29/game-industry-internship.html
>
> http://allenchou.net/resume/
> 格式：
> 重要的放前面；實戰經驗 ＞ 學歷。
> 工作 ＞ 實習 ＞ 學生團體專案 ～＝ 個人專案。
> 如果空間不夠，可以不放學歷，因為（對遊戲業來說）學歷沒那麼重要。
> 左右分兩欄，經驗與技能。
> 不要用一個通用版去投所有的職缺，要針對每個職缺作調整。
> 用條列式列出重點；不要在履歷表裡寫自傳。
推
01/26 23:33, , 15F
01/26 23:33, 15F
→
01/26 23:33, , 16F
01/26 23:33, 16F
→
01/26 23:34, , 17F
01/26 23:34, 17F
→
01/26 23:34, , 18F
01/26 23:34, 18F
→
01/26 23:35, , 19F
01/26 23:35, 19F
同意，投影片也用得到。
推
01/26 23:52, , 20F
01/26 23:52, 20F
→
01/26 23:53, , 21F
01/26 23:53, 21F
→
01/26 23:54, , 22F
01/26 23:54, 22F
推
01/27 01:50, , 23F
01/27 01:50, 23F
→
01/27 01:51, , 24F
01/27 01:51, 24F
→
01/27 01:51, , 25F
01/27 01:51, 25F
→
01/27 01:52, , 26F
01/27 01:52, 26F
或許可以這麼說：文案寫作並沒有絕對的對錯，多半是以社會文化「約定成俗」為
準繩。
@FRAXIS
在這裡，資訊有限，只能討論就寫作技術本身討論，沒辦法去隔空抓藥、預測未來
「讀到你這份文案的人是不是正好不喜歡/不在乎某種寫作技術」 :)
※ 編輯: AmosYang (72.211.194.61), 01/27/2017 03:59:12