ExplainThis 全端開發雙週報 #80 如何把「善用 AI」寫到履歷中?
如何把「善用 AI」寫到履歷中?
嗨～歡迎閱讀第 80 期 ExplainThis 全端開發雙週報！
因為近期使用 AI 這項能力逐漸成為軟體工程師的標配，許多公司在找新員工時，也會評估對 AI 工具使用的精熟程度。在 ExplainThis 經營的 E+ 社群當中(連結)，也有許多讀者陸續在履歷上面寫跟使用 AI 相關的列點。
Cursor 的工程副總 Lee Robinson 針對工程師求職申請的分享 (連結)，他從自己近期看過數百份履歷的的角度出發，整理出幾個讓履歷更容易被看見的建議。
在他的分享中，Robinson 說自己很意外地看到，很多工程師的履歷完全沒有提到 AI 或代理工具。他認為現在合理的預期是，一位工程師在工作中會需要理解如何搭配 AI 寫程式、除錯、規劃或加速開發流程。
對此，希望透過這期雙週報的主題文章分享「如何把善用 AI 寫到履歷中」的一些範例供讀者們參考。
如何把「善用 AI」寫到履歷中?
就寫列點來說，與《軟體工程師求職全攻略》提到的履歷撰寫原則一樣，核心關鍵是要寫出相關的關鍵字 (所以 ATS 能抓到)，以及要寫出成果影響力 (所以用人主管會想找來面試)。
公司在評估工程師時，不只會問有沒有用過 AI 工具 (現在幾乎多數公司都預設工程師有在用)，而是會進一步評估「怎麼用? 多有效?」。換句話說，有沒有將 AI 運用到多個環節、用了後產生多大的影響力，這些都會是評估的方向。因此，不能只是寫一句「熟悉 AI 工具」而已，而是讓人看見你怎麼把 AI 變成工作流程的一部分，並且有實際的成果。
如果要進一步區分初階與資深工程師使用 AI 的方式，那麼只停留在用 AI 寫程式、寫測試，這種最基本的列點，會比較難與初階工程師拉開區別。能否在用 AI 時對接到適當的外部工具、能否透過代理技能 (agent skills) 來提升整個團隊的品質與一致性、能否透過子代理來加速、能否在用 AI 的同時最小化 tokens 消耗成本，都會是評估的面向。
即使這些平常都有做到，如果在呈現上沒有修飾，也可能會看起來沒區別度。以下我們會透過三個實際列點，來談可以如何寫更好。
範例一「會用 AI 做 Code Review」
首先，如果履歷上寫「使用 AI 協助 Code Review，提升程式碼品質」，這會讓人知道你懂得用 AI 來把關程式碼品質，但這幾乎是人人都能寫出的點。
更理想的寫法會是 「設計複利工程工作流程，讓 AI 代理自動萃取每次互動的模式並融入技能庫，使 Code Review 重複性意見減少 XX%，審核來回次數從 XX 次降至 YY 次」。
英文版本則是 Designed a compound engineering workflow that automatically extracts patterns from AI agent conversations into a reusable skill library, reducing repetitive code review comments by XX% and cutting average review round-trips from XX to YY.
這個版本的差異在於，呈現出不只是會用 AI，還能夠把過去的經驗變成下一次產出的預設品質。這會讓看履歷的人看見，你不只是會用工具，而是有系統化改善工程流程的能力。
範例二「會用 AI 寫測試」
再看到第二個範例，如果履歷上寫「使用 AI 產生測試案例並修正錯誤」，也會因為現在很多工程師都會請 AI 幫忙產生測試，讓這個列點不太能形成差異。
更理想的寫法會是「建立「生成→測試→修正」的完整驗證回圈，讓 AI 代理在寫完程式碼後立即執行測試，未通過則自動回頭修正，將 AI 生成程式碼需要人工介入修改的比例降低 XX%，通過 QA 審核的一次通過率從 XX% 提升至 YY%」。
英文版本則是 Implemented a generate → test → fix verification loop where AI agents automatically re-attempt until all tests pass, reducing manual intervention rate on AI-generated code by XX% and improving first-pass QA approval rate from XX% to YY%.
這個寫法的差別，在於從整體流程角度切入，而且著重在影響力的呈現。很多人在寫履歷時，只會寫做了什麼，而沒寫出做這件事情有多大的影響力。軟體測試的核心目的之一，是讓軟體更加可靠，所以當把通過 QA 審核的品質門檻寫出來，就能突顯你不只是用 AI，還會確保 AI 真的有帶來幫助。
範例三「優化 Lint 與格式化速度」
最後一個範例，如果在履歷寫「優化專案的 Lint 與格式化工具，提升開發效率」，這也是個在呈現上相對可惜的寫法，讀履歷的人無法從中看出實際提升了多少。
更理想的寫法會是「遷移程式碼檢查與格式化工具鏈至更高效的方案，將 Lint 時間從 XX 秒縮短至 YY 秒以內、格式化時間從 XX 秒縮短至 YY 秒以內，加快 AI 代理的驗證回圈速度，隨程式碼庫規模增長效益更為顯著」。
英文版本則是 Migrated linting and formatting toolchain to higher-performance tooling, reducing lint time from XXs to under YYs and formatting time from XXs to under YYs, directly accelerating AI agent feedback loops at scale.
這個寫法不只是寫出影響力，更讓讀履歷的人知道「這位候選人有在考量 AI 代理的效率」。因此傳達的就不會只是「我把工具換快了」，而是理解開發工具鏈在 AI 時代的新角色。
以上，希望透過這篇文章，有讓讀者更了解如何把「善用 AI」轉換成讓人看得出差異的列點。當然，在實際要推動團隊改善前，務必先設定好指標 (上面提到的 XX 與 YY 是範例指標，每個團隊用的不必然相同)，這樣才能衡量與比較改善前後的差異，寫在履歷上會比較能突顯影響力～
最後補充一點，如果想要有效寫出上面這些列點，除了遵循律例撰寫推薦的原則外，在 E+ 最新的《AI Coding 201 — 從實戰到最佳實踐》課程已經有上架的單元中談到的要點，如果有照著做來改善團隊，就可能寫出以下的列點。
感興趣的讀者，歡迎加入 E+ 觀看 (連結)
本期推薦
這週在社群中有篇來自 Google 傑出工程師 (L9) Vlad Feinberg 分享的《How to Land a Frontier Lab Job》 (連結)。在他的這篇文章中，有許多有洞見的觀點，以及務實的具體建議。文章中談的概念適用於所有軟體工程師，我們也寫了心得 (連結)
來自法國的圖靈獎得主，也是前 Meta 首席 AI 科學家 Yann LeCun，回應有人問「法國擁有的費爾茲獎得主，比歐洲任何其他國家都多，但在國際數學奧林匹亞競賽（IMO）的表現卻非常差。像匈牙利、羅馬尼亞、保加利亞這些國家，在 IMO 上表現非常好，卻連一位費爾茲獎得主都沒有。為什麼會這樣?」，觀點值得思考 (連結)
Raycast 團隊最近分享了《A Technical Deep Dive Into the New Raycast》一文 (連結) 談新版 Raycast 技術細節，從技術棧選擇到技術取捨討論，非常精彩
《The production bug that made me care about undefined behavior》一文 (連結)透過實際的經歷，分享沒有注意到
undefined行為導致的 bugs，是很寶貴的提醒《If You Can’t See the Boundary, You Can’t Reason About the System》一文 (連結) 從 React 的 RSC 出發，來談系統邊界的問題
上週在 X 上討論度最高的文章，莫過於 Deedy 寫的這篇對舊金山 (或台灣人可能比較常用的「矽谷」) 的職涯觀察，談到在高速進展的 AI 時代中，人們所經歷的躁動與焦慮 (連結)。我們也寫了讀後感 (連結)
這週 Meta 再次進行全球規模的大裁員，由於這次是官方事前預告，讓還在職的員工人心惶惶，《A Meta employee gets real about the horror of working there right now》一文 (連結) 專訪了 Meta 員工，談到面對裁員的恐懼與焦慮。同時，前 Meta 的首席工程師 Kun Chen 分享了裁員背後的實際考量 (連結)，以及軟體業界正在經歷的變動