軟體工程師履歷範本：免費模板與寫法指南（2026）
可直接套用的工程師履歷範本（免費、MIT 授權），附成品預覽。逐區塊拆解寫法：基本資訊、經歷 bullet 量化公式、技能取捨、ATS 注意事項、中英文履歷怎麼選。
在找工程師履歷範本的話，先把東西給你，再講怎麼用：
- 範本 repo：gitresume-co/resume-template，免費，MIT 授權
- 建置成品：線上版是範本原樣建置的結果；填好內容後長什麼樣，看下圖的完整範例 PDF
- 不想手寫 YAML：Resume Builder 用引導式表單填完直接產出
範例履歷中的人物、公司與數據皆為虛構，僅用來示範寫法。
套用只要三步：GitHub 上按 Use this template 建立自己的 repo，複製一份 example.gitresume.yaml 命名為 gitresume.yaml（或用 Builder 產生），到 gitresume.co 連上 repo 之後 push。PDF 和網頁版履歷自動建置，之後每次 push 履歷變更都會自動重建。
範本是我們（GitResume）做的，利益先揭露。但下面的寫法建議，不管你用不用這個範本都成立。
基本資訊：讓人找得到你就好
放姓名、Email、電話、所在地，有經營的話加 GitHub 和 LinkedIn。細節比想像中容易出錯：
- 電話帶國碼：
+886 912 345 678，投海外職缺時對方才撥得通 - 地點寫到城市就好：
Taipei, Taiwan，不用完整地址 - LinkedIn 先設定自訂網址，一串亂碼結尾的預設連結放上去很掉漆
- GitHub 放之前先整理：置頂幾個像樣的 repo、補好 README。空蕩蕩的帳號不如不放
- 連結在網頁版履歷上要看得出可以點，範本的成品會自動把連結渲染成藍字
這些對應範本 YAML 裡的 personalInfo 區塊，填進去就會排好。
Summary：兩三行，講你是誰
有一派建議版面不夠就砍掉 summary，我們的看法是：兩三行的 summary 值得留，空泛的才該砍。招募者掃一份履歷的時間以秒計，這段是你唯一能控制第一印象的地方，功能等於書面版的自我介紹開場：用一句話建立「與職位相關、又跟別人不同」的定位。
寫法上直接講領域和量級，例如本文範例履歷的寫法：
Distributed systems, Go, GPU inference. 9+ years building backend platforms at scale.
該砍的是 “fast learner, team player, good communication skills” 這種放誰身上都成立的句子，以及職涯目標宣言（objectives），那些留到面試再說。
經歷：整份履歷的主體
由新到舊排，權重跟著時間遞減：最新的經歷寫最滿（範例給了五個 bullet），越舊的越精簡，最舊的兩個帶過就好。經典的工程師履歷都是這個形狀，現職占最大篇幅，十年前的工作兩行結束。每個 bullet 都用同一個公式：強動詞開頭 + 具體做的事 + 量化影響。
比較這兩行：
✕ Responsible for maintaining the company’s API services
✓ Rebuilt checkout rate-limiter on Redis + Lua; absorbed 75K RPS BFCM peaks with zero incidents
第一行是職缺描述，任何人坐那個位子都能寫。第二行才是履歷：做了什麼、用什麼做的、結果如何，有數字。
量化不一定要有驚天動地的成就，這些都算：
- 規模：服務多少 RPS、管多大的 cluster、資料量多少
- 變化：延遲從多少降到多少、建置時間砍幾成、成本省多少
- 範圍：幾個團隊採用、影響幾個服務、帶幾個人
真的擠不出數字，就寫清楚技術決策和因果，例如 “Migrated nightly cron jobs to an event-driven pipeline, eliminating half-day data delays”。有因果就比純職責強。
還有幾個容易忽略的細節。
開頭動詞的時態：已離職的工作一律過去式；現職進行中的職責用現在式，現職裡已完成的單次成果用過去式。混用不是不一致，是正確做法：
注意換行的尾巴：bullet 超過一行時看一眼第二行，如果只掛著一兩個字，就想辦法改掉：
另外兩個小規則：bullet 省略主詞，直接動詞開頭，不要寫 “I led”；還有一條只講一件事，發現自己用 and 串了兩個成就，就拆成兩條。
新鮮人沒有業界經歷，用專案和實習填這個區塊，同樣的公式照用。
技能：一行一類，放了就要扛得住
按類別分組，每類一行，跟目標職缺相關的優先：
Languages: Go, TypeScript, Python
Infrastructure: Kubernetes, Terraform, AWS
常見的地雷：
- 用進度條或星星自評。 「Go 92%」讀不出任何依據，只會引來面試官挑戰，而且圖形對 ATS 是不存在的（下一段還會再遇到它）。熟練度靠經歷的 bullet 證明，不是用百分比宣告。
- 塞不相關的技術。 版面有限，十年前碰過兩週的框架放上去只是稀釋重點。
- 放不熟的東西。 放了就會被問，每一項都要能在面試裡撐住追問，為了通過關鍵字篩選硬放，最後只是把自己問倒。
學歷：有經歷的人一行帶過
也是由新到舊。工作三年以上，學歷一行寫完就好：學位、學校、年份。新鮮人可以多寫：社團、幹部、相關修課、專題。GPA 超過 3.5 值得放，沒超過就不用特別寫。
ATS 注意事項
多數公司第一關是 ATS（求職者追蹤系統）解析，不是人眼：
- 單欄排版。雙欄、文字框、表格都可能讓解析器讀錯順序，這也是範本做成單欄的原因。
- 關鍵字用職缺的用語。JD 寫 Kubernetes 就寫 Kubernetes，不要只寫 k8s（兩個都寫最保險）。
- 不要把資訊藏在圖片裡。技能雷達圖、進度條對 ATS 是不存在的。
右邊就是 GitResume 實際產出的 PDF：純文字單欄排版，沒有花俏元素，ATS 解析不會出意外。
排版不該占用你的時間
講到版型，順便說用 GitResume 最大的優勢：你不必再為了排版、找模板傷腦筋。網路上翻半天找到的漂亮模板，還不一定是 ATS 友善的，上一段那個雙欄加進度條的例子就是這樣來的。字級、行距、邊界、對齊，這些東西每調一次，就是從打磨履歷內容的時間裡扣一次。身為工程師，你的心力應該放在內容本身，模板把排版定好了，你 push 內容，輸出永遠一致。
真的需要調整（例如內容偏多想收進一頁），專案設定裡有 Layout Density 可以微調：Relaxed、Standard、Compact 三檔預設，或展開 fine-tune 自己控制字級、行高、邊界和各層級間距，旁邊有版面示意即時預覽，改完下次 build 生效。
不過多數人用預設的 Standard 就夠了，而這正是重點：把時間還給內容本身。
中文履歷還是英文履歷？
看職缺：本土企業用中文，外商、新加坡、遠端職缺一律英文。兩份都要的話，分成兩份獨立維護，不要做一份雙語混排的。
像我自己就同時維護中英文兩份履歷：開兩個 repo、各接一個專案、各有獨立網址，中文投本土職缺，英文給外商和獵頭。如果你用免費方案（一個專案），也有辦法：同一個 repo 開兩個分支，兩個分支的履歷改動 push 後都會各自建置出可下載的 PDF，投遞用這個就夠；公開的履歷頁則固定跟著專案設定的分支走。兩份的完整歷史都在 Git 裡，不會弄丟東西。
範本預設是英文。要寫中文履歷也沒問題，欄位值直接填中文，PDF 用 Noto Sans CJK 字型渲染，不會變豆腐字。
這個範本跟 Word 範本最大的差別
它是一個 YAML 檔，活在你自己的 GitHub repo 裡：
- 改壞了
git log找回任何歷史版本，不會再有履歷-final-v3-真的最終版.docx - 投不同公司開不同 branch 客製，改了哪些關鍵字
git diff一目了然 - 請朋友幫看履歷，開 PR 留 comment，比來回傳檔案乾淨
對這套工作流有興趣的話，什麼是 Resume as Code？有完整介紹。已經有一份現成履歷（PDF、Word 都行），丟給 AI agent 幾分鐘就能轉成 YAML。
常見問題
履歷要一頁還是兩頁？
以一頁為原則，資深工程師也一樣。超過一頁的正確反應不是縮字體，是排優先序，把不夠重要的拿掉。刪到痛才是對的長度。
要放照片嗎？
投外商和海外職缺不要放，很多公司為了避免偏見，看到照片直接跳過。本土傳統產業有時候期待有，看職缺要求。預設不放最安全，範本也沒有照片欄位。
這個範本要錢嗎？
範本免費、MIT 授權，隨便用。GitResume 免費方案可以建一個專案，建置 PDF 和網頁、發布、匿名瀏覽統計都包含，PDF 不帶浮水印。Pro 是加專案數、自訂網域這類進階功能。
改了履歷之後要重新匯出嗎？
不用，push 就是更新。每次 build 都會產生一份可下載的 PDF，公開的履歷頁則永遠抓最新一次 build 的內容。
延伸閱讀
- 什麼是 Resume as Code？：用 Git 管履歷的完整概念
- 用 AI Agent 把現有履歷變成 Resume as Code：現成履歷的搬家路線
- 用手機上的 Claude Code 養成更新履歷的習慣：範本套完之後，讓它保持新鮮
- 快速上手指南：連接 repo 的完整步驟