工程師履歷的工作經歷，要寫出你改變了什麼

寫出因為你，什麼改變了

大部分履歷上的工作經歷長這樣，右邊是可以改寫的樣子：

左邊告訴招募人員你的職務內容是什麼，右邊告訴他們你進來之後大概能做出什麼。他們第一次快速掃過你的履歷時，想知道的就是這件事。

XYZ 公式

Google 長期以來給求職者的建議，是把每一項成果寫成：完成了 X，以 Y 衡量，做法是 Z。

• X 是結果
• Y 是證明結果的數字
• Z 是你做了什麼

順序不一定要照這樣。「隔離並修好不穩定的測試，CI 失敗率從 18% 降到 3%」先寫 Z 再寫 X 和 Y，也完全沒問題，重點是三個部分都要有。只有 Z 的句子（「修好不穩定的測試」），讀的人只能自己猜這件事到底重不重要。

STAR 原則和 XYZ 公式有什麼不同

很多履歷教學會提到 STAR 原則：情境（Situation）、任務（Task）、行動（Action）、結果（Result）。STAR 很適合用在面試時講一個完整的故事，但直接照四段寫進履歷，每一條都會太長。

寫進履歷時，可以把 S 和 T 壓縮或省略，只留下 A 和 R，並把結果和數字放在前面，就變成一行 XYZ。例如：

STAR（面試時講）： 上線前一週，CI 一天要失敗好幾次，大家都在重跑測試（S）。我負責找出原因（T）。我把最不穩定的 40 個測試隔離出來，逐一修好（A）。CI 失敗率從大約 18% 降到 3%（R）。

XYZ（寫進履歷）： 隔離並修好 40 個不穩定的測試，CI 失敗率從約 18% 降到 3%。

兩種寫法其實是同一件事，只是一個用來說、一個用來看。

工程師履歷工作經歷範例

參考句子的結構，把系統名稱和數字換成你自己的。

後端

• 零停機完成帳務模組從單體架構拆分成獨立服務，讓年繳方案在三週後順利上線。
• 加上 covering index 並快取排序步驟，搜尋 API 的 p95 延遲從 820 毫秒降到 310 毫秒。

前端

• 讓結帳頁通過 Core Web Vitals 標準，行動版結帳轉換率提升約 4%。

SRE 與基礎架構

• 把 30 個服務搬到新的建置流程，平均部署時間從 25 分鐘縮短到 8 分鐘。
• 找出並清除閒置的 staging 叢集，雲端費用每月減少約 12%（約 9,000 美元）。
• 替三個第一級服務訂定 SLO 和錯誤預算告警，服務慢慢劣化時能在客戶回報前發現。

行動開發

• 修掉圖片快取的記憶體洩漏，並把 crash 分組加入發版檢查，Android 無當機工作階段比例從 98.9% 提升到 99.7%。

資料工程

• 用增量模型重建每晚的營收 pipeline，執行時間從三小時縮短到 25 分鐘，財務部門早上九點就能拿到數字。

帶領與指導

• 帶領四人團隊完成通知系統改寫，從 RFC 到上線，發送失敗率從 4% 降到 0.5% 以下。
• 帶兩位新進工程師上手，兩人都在到職兩週內把程式碼推上正式環境。

如果要投外商、需要英文履歷，可以參考英文版的範例，句型會比直接翻譯自然。

找不到數字的時候，去哪裡找

大部分工程師手上的數字，比自己以為的多，只是當時沒有記下來。可以從這些地方找：

• 監控面板：延遲、錯誤率、可用率、吞吐量、成本
• PR 和設計文件的描述，常常會寫改善前後的數字
• 事故檢討：多久發現、多久修復、影響了多少客戶
• Release note、更新紀錄、上線公告
• 你以前寫的週報或進度報告

如果只能估計，就加上「約」或「大約」。認真估出來的數字放在履歷上沒問題，編出來的數字則不行，而且面試官一定會問你是怎麼量的。

真的沒有數字的時候，就改寫影響範圍：影響了多少使用者、多少團隊或服務，或是這件事完成之後，什麼原本做不到的事變得做得到。

每段經歷寫幾條、寫多長

• 最近的工作寫三到五條，越久以前的越少。
• 每條一行，最多兩行。需要三行的，通常可以拆成兩條。
• 用有力的動詞開頭：主導、建立、降低、遷移、設計、上線。「負責」「協助」「參與」會讓你聽起來像是旁觀了自己的工作。
• 每段經歷把最強的那一條放第一個，很多人根本不會讀到第三條。

針對職缺調整履歷

同一份履歷投到每個地方很方便，但針對職缺調整過的履歷，被閱讀的方式會不一樣。每次投遞前：

1. 從職缺描述裡挑出大約五個重複出現、或排在最前面的條件。
2. 每個條件，都找一條可以證明你做過的經歷。找不到的話，想想是不是其實做過，只是從來沒寫下來。
3. 把對得上的那幾條移到每段經歷的最上面，跟這個職缺無關的就刪掉。
4. 在誠實的前提下，用他們的用詞。職缺寫「分散式系統」，你寫的是「微服務」，兩種說法可能都對，但篩選工具和招募人員找的是他們自己的用詞。

不要加上你沒有的技能或成果。調整履歷是挑選和排列真實的內容，編造的東西通常撐不過第一場技術面試。

履歷的原始素材從哪裡來

上面每一條範例，都靠你記得自己做了什麼、改變了什麼。專案結束兩年後，這些細節大多已經忘光了，所以寫履歷常常變成一整個週末的考古。

寫工作日誌可以解決大部分的問題。Perfly 做的是同一件事，但更省力，而且會直接把紀錄變成履歷：

1. 每天隨手記幾行，或讓 GitHub、Jira、Google Calendar、Notion 根據你的活動先擬好紀錄。如果你平常用 Claude Code、Codex 或 Cursor，也可以讓 Agent 幫你送摘要。某條紀錄加上數字會更有力時，Perfly 會趁你還記得的時候追問。
2. Perfly 會用 XYZ 公式，把你確認過的所有紀錄寫成一份主履歷，每一條都連回背後的紀錄。
3. 它會標出比較弱的條目：有記錄數字卻沒用上、完全沒有數字、太長，或背後沒有任何紀錄；英文履歷還會提醒開頭動詞太弱。
4. 貼上職缺描述，就能從你全部的紀錄裡產生一份針對這個職缺的版本，最多可以保留十份。每一份都會列出職缺的主要條件，以及對應的經歷條目，哪裡還有缺口一眼就看得到。
5. 可以複製、匯出成 Markdown 或列印。也可以先跟讀過這份履歷的 AI 面試官演練一次「請介紹一下你的經歷」，針對職缺的版本還會連同職缺描述一起演練。

之前沒有記錄的習慣？連接 GitHub 和 Google Calendar，Perfly 可以把過去 12 個月的活動拉進來、整理成主題，讓你挑出重點當作起點。

常見問題

每一條都要有數字嗎？

大部分要有，但不是全部。描述負責範圍的條目（「從頭到尾負責金流服務，包含值班」）沒有數字也站得住。不過如果整份履歷一個數字都沒有，那就是第一個要改的地方。

可以用 AI 寫履歷嗎？

拿來潤飾文字沒問題。麻煩的是 AI 不知道你的實際成果，它會很有自信地寫出不屬於你的數字。給它真實的成果和數字，放上履歷前每一個數字都要再確認。

履歷要寫到多久以前的經歷？

大概最近十年寫詳細一點。更早的工作可以縮成一兩行，或只列職稱和公司。

工程師履歷一定要一頁嗎？

剛入行的話，一頁對大部分人都夠用。如果相關經驗很多，兩頁也沒問題。與其把字縮小，不如先刪掉比較舊、比較不相關的條目。

中文履歷和英文履歷要分開寫嗎？

要的話最好分開寫，不要直接翻譯。投台灣公司通常用中文履歷，投外商或海外職缺通常用英文。兩種語言的句型習慣不太一樣，直接翻譯常常會讀起來很生硬。

Perfly 多少錢？

前 30 天免費，所有功能都能用。之後每月 $6.99，或每年 $69.99。