資深工程師 AI 時代升職戰略：從個人貢獻者到 Staff Engineer 或 Tech Lead 的 90 天行動清單

AI 把資深工程師的「寫程式時間」壓縮了 50% 以上，剩下的時間決定你升不升得上 Staff Engineer 或 Tech Lead。 這篇給你 5 個關鍵能力槓桿、90 天可執行的升職行動清單、以及跟主管啟動「升職對話」的 4 步腳本。

Stack Overflow 2025 開發者調查顯示，76% 的工程師日常工作流程已經整合 AI 工具，（Stack Overflow Developer Survey） 而 GitHub 內部數據顯示 Copilot 使用者完成相同任務的時間比未使用者快 55%。意思是，你過去靠「寫得快、寫得乾淨」累積的技術優勢，今天已經是「人人都有」的基本盤。

AI 時代資深工程師的職涯選擇：Staff Engineer vs Tech Lead vs 帶人主管

台灣中型科技公司過去 5 年的職涯軌跡很單純，資深之後資深之後通常只剩當主管或離職兩條路。但隨著 AI 把個人產出大幅放大、軟體公司的組織結構在重塑，現在有 3 條路徑同時被打開：

AI 時代 Staff Engineer 的 5 個關鍵能力槓桿

以下 5 項是過去 18 個月內，從升職 review 文件、Tech Lead 訪談、矽谷大廠工程文化研究中萃取的共同點。每一項都附「上週你做過幾次」的自測題。

槓桿一：把 AI 變成 10 倍的 leverage，而不是 1.5 倍的 autocomplete

初級工程師用 Copilot 寫 if/else，資深工程師用 AI 做「程式碼考古」、「架構建議」、「跨 repo 重構」、「測試生成」。差別在「你問 AI 的問題層級」。

• 自測：上週你有沒有用 AI 一次重構超過 5 個檔案？

• 自測：你有沒有寫過 AI 評估 prompt，例如「請對比這兩種 schema 設計的 query performance」？

槓桿二：寫文件比寫程式重要 3 倍

Staff Engineer 的影響力來自「讓別人看懂你的決策」。技術設計文件（TDD / RFC）、ADR（Architecture Decision Record）、postmortem，這三種文件你寫得好不好，比 PR 數量還影響升職。（Google Engineering Practices）

• 自測：你的 GitHub repo 有沒有一個 docs/adr 目錄？

• 自測：上一次 production incident，你有沒有主動寫 postmortem 並分享給整個團隊？

槓桿三：跨團隊影響力，不是「跨團隊救火」

升 Staff 看的是「影響範圍」。但影響真正的影響是「我建立了一個 framework、規範或工具，讓其他組不用再踩這個坑」。前者是工作，後者才是 leverage。

• 自測：過去 3 個月，你有沒有一個產出被其他組長期使用？

• 自測：你能不能說出公司內 3 個非自己組的工程師正在解決的技術難題？

槓桿四：從『解問題』升級到『定義問題』

初級工程師等 ticket 來。資深工程師看到問題去搶 ticket。Staff Engineer 主動發現公司沒人注意到的問題，把它變成 ticket。第三層是質變，多數人卡在第二層。一個簡單的訓練：每週問自己「公司現在最該做但沒人做的技術事是什麼？」然後寫成提案文件。

槓桿五：技術品味（taste），讓別人願意聽你的判斷

品味來自三件事：讀別人的程式碼（GitHub trending、公司內部高品質專案）、定期分享技術文章（內部讀書會、Tech Talk）、敢於說「不」並給理由（拒絕一個不該做的功能比加 10 個功能更難）。這項沒有捷徑，但每天投入 30 分鐘讀別人的 code，一年後你會看得出來自己被甩開。

資深工程師的 90 天升職行動清單

把目標拆成 3 個 30 天區段，每段都有明確的「可被 review 的產出」。沒有產出的努力 = 沒做。

Day 0-30：盤點 + 定錨

• 跟主管 1-on-1 一次，明確問「離 Staff/TL 我還缺什麼？」（多數工程師從不問這句）

• 列出公司過去 6 個月的技術痛點清單（從 incident report、retro、Slack 抱怨記錄抓）

• 挑 1-2 個你能解決的、影響 2 個組以上的問題

• 用 AI 把這個問題寫成 1 頁的提案文件

Day 30-60：產出 + 對齊

• 做出 MVP（最小可運作版本），不要追求完美，要追求「能讓其他組試用」

• 找 2-3 個跨組工程師當 alpha tester，收集真實反饋

• 公開分享一次（內部 Tech Talk、寫篇內部 Notion 文章、PR 留下完整 ADR）

• 更新主管：把 Day 0 的提案 → 現在的 MVP → 收到的反饋串成一個故事

Day 60-90：放大 + 取得 sponsor

• 把 MVP 推到 production，做出可量化的數據（縮短了多少時間、減少了多少 bug、提升了多少 throughput）

• 讓至少 1 位主管以上的人（你的主管的主管）知道這件事是你做的

• 產出一份 1 頁的「升職案例」文件：問題→解法→結果→量化指標，交給主管

• 正式啟動升職對話

跟主管啟動升職對話的 4 步腳本

不要等 review 才談升職。多數公司的升職是「半年前就被內定」的，等到 review 才提通常已經來不及。提早 6-9 個月把這 4 步走完：

Step 1：先問現狀，不要先要承諾

開場句：「我想跟你聊聊我的成長路徑。我目標是 Staff Engineer（或 Tech Lead）。從你的角度看，我現在距離這個位置最缺什麼？」

這句話的關鍵是「不要先說我想升職」，先問狀態。多數主管會誠實告訴你 2-3 個缺口。

Step 2：把缺口轉換成可執行的 commitment

如果主管說「你還需要更多跨團隊影響力」，下一句問：「具體來說，要做到什麼程度算夠？例如『主導一個跨 3 個組的專案』算嗎？」。把「跨團隊影響力」這種抽象詞具體化。

Step 3：定期 update，每月一次 20 分鐘

不要等下次 1-on-1 才報告。每個月主動寄一封 email 給主管：「過去一個月我針對 XXX 做了 ABC，下個月計畫 DEF，預計在 N 月達到 XX 標準」。主管會把這封信收進「升職證據資料夾」。

Step 4：在 review 前 30 天交出升職案例文件

Promotion packet：1 頁的問題定義、3 頁的工作內容、1 頁的量化結果、3 個 peer 的 testimonial（不一定要正式 reference，3 句話的肯定也可以）。讓主管要為你升職時手上有材料，不是空口無憑去爭取。

3 個常見的卡關訊號與解法

訊號一：每年績效都是 A，但升職永遠輪不到

代表你做的事「好但不夠 visible」。解法：每月寫一篇內部分享、PR description 寫得像文章、incident response 主動領導 postmortem。Visibility 重點在讓貢獻被看見，而非炫耀。

訊號二：每次升職 calibration 都被主管說『再給一年』

代表你還在等公司給機會，沒主動創造機會。解法：自己提案、自己挑問題、不要等被分配。換工作有時候反而是最快的方式（用市場行情逼公司 match 升職）。

訊號三：你已經做 Staff 的工作但職稱還是 Senior

這是最危險的訊號。意思是公司願意拿你的產出，但不打算給對應的位置。明確的對話：「我做的事已經到 X level，如果今年無法升職，我會考慮其他選擇。」如果公司還是不動，去外面看市場，通常你會發現自己被低估 30-50%。

最後一個提醒：不要把升職當成單一目標

我認識的最強工程師，沒有一個是「為了升職」做事的。他們做事是因為「這件事該做、好玩、能讓公司更好」，升職是順帶的結果。當你的能量花在「升職政治」上時，你就不在做 Staff Engineer 該做的事了。

反過來看：當你已經在解決公司最痛的問題、寫出讓人想抄的程式碼、訓練出能獨當一面的 junior，升職就只是時間問題。如果你的公司在這種狀態下還不升你，市場會。

延伸閱讀：35-45 歲職涯升級完整戰略、AI 寫程式時代你還需要工程師嗎？、專案經理 AI 工作流。