履歷不是寫給自己看的——為什麼你寫對了自己、寫錯了讀者
多數新鮮人寫履歷、心裡的讀者是自己。 讀履歷的 HR、心裡的目標是 6 秒內篩掉 180 份。 兩個 mental model 完全相反——所以你寫得很努力、卻常常卡在第一關。
大多數新鮮人寫履歷時、心裡的讀者是自己——寫完讀一遍、覺得「對、我做過這些事」、就送出。問題是、那一頁紙真正會被閱讀的場合、是 HR 桌上一疊 200 份履歷裡其中一份。那位 HR 不知道你做過什麼、也沒義務按你的順序讀完。
編輯部的觀察是——這份「寫給自己看」的習慣、是新鮮人履歷最大的盲區。不是文筆問題、不是經歷不夠的問題、是作者跟讀者根本不在同一個 mental model 裡。這篇拆給你看那個 mismatch 在哪、以及怎麼從「作者視角」翻譯成「讀者視角」。
HR 第一眼讀履歷、不是從上往下讀
編輯部讀過大量招募流程觀察、第一眼讀履歷的人——多數情況下是 HR——掃完一頁紙的時間、業界常引用的 anchor 是 6 到 10 秒。實際時間會因投遞量、是否已過 ATS 預篩、職缺資深度浮動、但「快」這個事實是穩定的——慢的話、HR 那一天看不完。
這 6 到 10 秒做的事情、不是按你寫的順序從上讀到下、是眼睛跳著找跟 JD 對應的 signal。
想像 HR 桌上有 200 份應徵這個職位的履歷、JD 寫的核心需求是「Python、SQL、有 dashboard 經驗」。HR 的腦袋在那 6 秒內跑的查詢、不是「這個人從幼稚園到現在做了什麼」、是「Python ✓ / SQL ✓ / dashboard ?」。看到 ✓ 就 stay 一下、看到 ? 就放下、看下一份。
你寫履歷時、想的是「我要怎麼完整呈現我自己」。讀履歷時、HR 想的是「我要怎麼用 6 秒篩掉 180 份」。兩個 mental model 完全相反——這是新鮮人寫得很努力、卻常卡在第一關的根因。
問題不是要不要一頁滿、是那一頁怎麼分配
新鮮人最常問的一句話是「我履歷只能寫半頁、會不會太空?」。這句話背後的假設是——履歷是填空題、空白等於沒料、把一頁填滿才安全。
編輯部要在這裡校正一個誤區——「填滿」的動機確實有問題、但「半頁可以」的結論是錯的。
為什麼半頁不行——資深 HR 顧問的觀察是、半頁履歷在多數招募現場會被解讀為「沒熱情、極度被動、職涯空白到擠不出基本內容」。同時、現代 ATS(Workday、Greenhouse 這類系統)在計算 Resume Completeness 時、字數過少會被自動降權。半頁從訊號層跟技術層都吃虧。
那「填滿」的真正問題在哪?在平均分配。
新鮮人為了填滿、會把所有沾過邊的經驗都寫進去——選修課、社團幹部、短期打工、研究助理、志工服務、學校競賽。每段平均分配 2-3 行空間。讀起來「平的」——每件事看起來都一樣重要、也都一樣不重要。HR 那 6 秒掃過、找不到 signal、放下。
正確的問法不是「怎麼填滿一頁」、也不是「容許半頁」、是——
「那一頁紙、reader 6 秒能 spot 的 3 個 signal 是哪 3 個?我要把 80% 的空間給這 3 個、剩下的擠到角落或刪掉」。
平庸的經驗不該佔同樣的空間。把那些 2-3 行的雜項濃縮成單行 reference、騰出空間給 signal-strong 的專案做深度展開——這是「一頁滿、但每寸都是 signal」的版本。半頁是 surrender、不是 strategy。
想看編輯部會怎麼從你現在這份履歷裡、挑出 reader 會看見的 3 個 signal?
30 秒生成你的拆解 →同一件事、兩種詞彙、HR 看見的不一樣
編輯部讀過大量新鮮人履歷、有一個共通問題——寫的是學校語言、不是業界語言。
同樣一件事、學校語言會寫「跟 5 個系的學長姐一起跑研討會」、業界語言會寫成「跨部門協調、執行 X 規模的 event」。前者讀起來像「我們組員開會了」、後者讀起來像「這個人做過真正的協作」。HR 看了會自動往加分欄移動——「啊、有 stakeholder management 經驗」。
這個落差不是「潤飾」、也不是「灌水」、是讀者語言轉換。同一件事、你用學校的詞彙描述、reader 看不到對應的職場 skill。換成業界的詞彙——你做的事情本身一個字沒改——reader 才認得出來。
這條規則對新鮮人特別重要、因為你有的大部分 evidence 都是「學校場景」(社團、課程專案、實習、TA)、用學校語言寫沒人聽得懂。
Before(學校語言)
擔任攝影社副社長 (113-1 至 113-2 學期)、負責社員聯絡與活動規劃。協助舉辦學期攝影展、參與人數約 50 人。
After(業界語言、加 evidence)
攝影社副社長 (2024-2025)。把社員從 8 人成長到 24 人——重新設計新生入社流程、改月聚 cadence。籌辦校園聯合攝影展、跟資工系、中文系合作租借展覽空間、final attendance 80 人(前一年同類活動 30 人)。社團 Instagram 從 0 經營到 600 粉絲。
編輯部的判讀是——Before 列「我做了什麼職位」、After 寫「我做出什麼可量化差別」。Reader 6 秒掃過 Before 看到的是「有過社團幹部頭銜」、掃過 After 看到的是「組織擴張 3 倍、跨系合作、數字會說話」。同一段經驗、reader 的判斷完全不同。
不過「業界語言」有一個容易踩過頭的地雷——
當一個應徵 junior 職缺的新鮮人、在履歷裡頻繁出現「主導跨部門戰略協作」、「優化組織營運 cadence」、「驅動漏斗轉化」這種高階主管才會用的策略大字眼、經驗豐富的 HR 一眼看穿——這只是「攝影社跟資工系借教室辦活動」的過度包裝。第一印象變成「油條、不真誠」、比學校語言版更糟。
翻譯的底線是「名副其實」。多用動詞與客觀數據(招募了 16 人、attendance 80 人、Stripe sandbox 串接、67% coverage)、少用策略大字眼(戰略、cadence、漏斗、賦能)。Reader 要的是「這個人做了什麼可驗證的事」、不是「這個人會用什麼漂亮的詞」。
重看上面 Specimen 01 的 After——用的是「把社員從 8 人成長到 24 人」、「籌辦校園聯合攝影展、跟資工系、中文系合作」、「Instagram 從 0 經營到 600 粉絲」——全部是動詞 + 客觀數據、沒有一個策略大字眼。這就是「名副其實」的翻譯。
不能打破、但可以加一層
多數履歷模板教你「按時間順序排」——通常是反序、最新的在上、最舊的在下。不管哪種、履歷被組織的軸線是時間。
問題是——HR 6 秒掃描時、用的不是時間軸、是 relevance 軸。最後一年的實習可能跟 JD 高度對齊、大一通識專題可能跟 JD 完全無關——但時間排序會把它們放得一樣顯眼。
Reader 路徑跟時間順序錯位。新鮮人特別吃虧——你「最新」的東西多半就是 JD 最在意的(實習、final year project)、但反序時間線只給它跟「大一社團」同等的視覺權重。
第一直覺是——那就放棄時間線、改成 JD relevance 排序。但這條路不能走、有兩個工程現實擋住:
- ATS parsing 的時間線依賴。 現代 ATS(Workday、Greenhouse、各家 AI 解析器)的核心邏輯是「基於時間線的實體識別」——chronological entity parsing。你把時間線打亂、系統會把你的期末專案誤認為「最新工作經歷」、把實習日期 parse 錯到別的 entity、整份履歷被解析成一團 garbage 進到 HR 後台。
- HR 的成長軌跡判讀。 HR 高度依賴時間線判讀「這個人的成長 trajectory」——你最近一年做什麼、跟三年前做什麼、是評估你進步速度的關鍵訊號。打亂時間線等於把你的成長故事砍碎、reader 反而看不出你變強的軌跡。
編輯部的解法是雙層架構——
時間線本身留著(reverse chronological、最新在上)、但在履歷頂端、150 字自介下方、進入時間線之前、開一個獨立的「Selected Projects / 精選核心專案」區塊、放 2-3 個跟這份 JD 最對齊的 evidence、做深度展開。
這樣 reader 6 秒掃過頂端 Selected Projects、第一眼看到的就是 JD-aligned signal;想繼續往下細讀、完整時間線在後面。ATS 解析時間線那段、entity 結構清楚、不會出錯。
順著系統的毛摸、但把最強的 evidence 放在 reader 第一眼會掃到的地方——這是合規又有效的版本。
Selected Projects 區塊裡的每一條怎麼寫?看下面這個 specimen——
Before(時間線 + 工具列舉)
修習軟體工程實務 (CSIE3320)、與 3 名組員協作完成電商網站專案。技術:React、Node.js、MySQL。
After(relevance + scope + result)
軟體工程實務期末專案 (3 人組、12 週):負責 checkout flow 與第三方支付串接 (Stripe sandbox)。整合測試從 0 拉到 67% coverage、live demo 取得課程最高分。每週 2 hr code review cadence 是我提案並 facilitate。
Before 寫「我修了一門課、用了什麼工具」——資訊全在、但 reader 看不到 signal。After 寫「我交付了什麼 + 我做了哪些 scoping 選擇 + 量化結果 + 領導痕跡」——同一段 12 週的課程專案、reader 第一次看見「這個人能交付、會自己提流程」。
這條 After 寫法、就是 Selected Projects 區塊每一條該長的樣子——4-6 行、含 scope(3 人組、12 週)、技術選擇(Stripe sandbox)、可驗證的量化(67% coverage、最高分)、跟你做的 leadership 細節(提案 code review cadence)。然後在底下反序時間線的「課程」段、課程名稱只列一行 reference 就好——雙層架構自然成形。
挑掉跟 JD 無關的、是尊重 reader、不是隱瞞自己
編輯部觀察到、新鮮人最常見的一個心理障礙是——「我經歷不多、能寫的我都寫了、再不寫就空了」。
這句話有一半對、一半錯。對的那一半:經歷不多是事實。錯的那一半:「能寫的我都寫了」假設「完整呈現」是履歷的義務。
編輯部的視角是——履歷不是 CV。CV 是「我所有經歷的完整檔案」、寫給學界 / 政府機構 / Background check。履歷是「我針對這個 JD、最有說服力的 evidence」、寫給 hiring decision。後者本質就是 curation——你挑跟 JD 對齊的、捨棄不對齊的。
Curation 不是不誠實、是專業。
出版業每一本書都會被 edit、reporter 寫的每篇報導都會被剪。沒有人會說「你把我訪談裡這 5 句話拿掉、所以你在撒謊」。剪掉跟主題無關的、是尊重讀者時間、也是讓主題突出。
履歷是出版品。挑掉跟 JD 無關的、不是隱瞞、是讓 reader 6 秒內看見你最強的那部分。你跟同一家公司投不同職位、寫的應該是兩份不同的履歷——同樣的經歷、不同的 curation。
寫完一條 bullet、自問 reader 看到會問什麼
寫完一條 bullet、做這個測試——
「reader 看到這條會問什麼?」
如果答得出來——例如「在電商社負責 IG 經營、6 個月從 0 到 600 粉絲」、reader 會想「怎麼做到的?」「ROI 怎麼算?」「下一段是不是有解釋?」——那條 bullet 有功能。它在 reader 腦袋裡種了一個問號、會引導他繼續讀下去、或在面試時主動問。
如果答不出來——例如「擔任攝影社副社長、負責社員聯絡」——reader 看到不會產生任何問題。沒有問號 = 沒有 follow-up 可能 = 那條 bullet 對 reader 是 noise、不是 signal。
兩個處理方式:改寫到能引發問題、或刪掉。
這個測試只有自己能做——因為 reader 不會告訴你哪條是 noise。他只會默默放下你的履歷、看下一份。
履歷不是寫給自己看的。
寫的時候你是作者、要 advocate 為自己;
讀的時候 HR 是讀者、要在 6 秒內篩掉 180 份。
兩個 model 之間的橋、是 curation 與 reader-awareness。
但 reader-awareness 有個工程現實——
你不能完全照感覺重排履歷、
因為 reader 之前還有 ATS、ATS 有它的解析習慣。
正確的姿勢是——順著系統的毛摸、但在細節處給直擊痛點的解藥。
結構符合機器與 HR 的傳統習慣(一頁紙、反序時間線)、
內容的密度與詞彙完全對齊 JD(Selected Projects、名副其實的翻譯、可驗證的數據)。
編輯部不替你寫履歷。
我們做的是——在 HR 拿到你的履歷之前、
替你先讀一遍、把 reader 6 秒會卡住的地方標記出來。
然後你拿筆、自己改。
結構是骨架。
聲音是你的。
— 主編,The Match
把你的履歷對到一份真的 JD 上
30 秒生成六維度分析、能力缺口、與可動手改寫的具體建議——讓編輯部替你先讀一遍、把 reader 6 秒會卡住的地方標記出來。
註冊送 1 次完整深度分析、看品質再決定要不要付費。