為什麼大家的自評都長得差不多
隨便翻幾份自評，會看到一樣的句子：「工作認真負責，品質穩定」「具備良好的團隊合作精神」「如期完成主管交辦的任務」。
這些話都沒錯，只是沒什麼用。你的主管要拿著你的自評去開校準會議，跟其他十幾位工程師的考績放在一起比，一句他拿不出具體例子撐腰的話，在那個會議室裡幫不了你多少。
真正有用的是細節：你做了什麼、因為你做了這件事而改變了什麼，最好還有一個數字。
好的回答背後都有同一個結構
寫得好的回答，幾乎都包含三個部分：你做了什麼、帶來什麼結果、為什麼這對團隊或公司重要。數字通常放在中間那段。
| 比較弱的寫法 | 比較有力的寫法 |
|---|---|
| 負責優化結帳效能 | 把結帳的價格計算改成快取，p95 延遲從 1.4 秒降到 600 毫秒，隔月行動版轉換率提升約 3% |
| 協助新人到職 | 帶兩位新進工程師上手，並寫了本機開發環境的設定文件，新人第一個 PR 合併的時間從大約兩週縮短到四天 |
| 負責 on-call 值班 | 主導六月金流事故的檢討，三項後續改善全部完成上線，之後沒有再發生同類事故 |
沒有精確數字也沒關係，寫個大概的數字，並註明是估計就好。「頁面告警少了大約三成」還是比「告警明顯減少」有說服力。
常見自評題目和範例回答
每家公司的考核表都不太一樣，但題目幾乎都是下面這幾種的變形。範例回答是以一位中階後端工程師的角度寫的。參考結構就好，不要整段照抄，主管看得出來三個人貼了同一份範本。
「本期主要的工作成果是什麼？」
這半年最主要的專案是把帳務模組從單體架構拆成獨立服務。我寫了設計文件、把工作拆成四個里程碑，五月零停機完成切換。這讓定價團隊在切換後三週就推出了年繳方案。
另外我接手了 CI 裡不穩定的測試。把最糟的 40 個測試隔離並修好之後，主要 pipeline 的失敗率從大約 18% 降到 3%，大家每天都少重跑好幾次。
挑兩三件事就好，最重要的放第一個。有些主管看完第一段就不會往下看了。
「本期最有成就感的事是什麼？」
這題可以寫比較小、比較個人的事，不一定要是你最大的專案。
是 on-call 處理手冊，雖然沒有人要求我寫。某次值班被告警吵了一整晚之後，我花了幾個下午，把最常見的五種告警要怎麼排查寫下來。兩位比較新的同事跟我說，被叫起來的時候第一個打開的就是這份手冊，我們處理事故的時間中位數也從大約 50 分鐘降到 20 分鐘。
「有哪些地方做得不夠好，或可以改進？」
大家最怕這題，但這題寫得好，反而最能讓主管信任你。寫一件真實的事，說你學到什麼，再說你已經在怎麼改。
第二季的搜尋重建索引專案，我低估了工作量。原本估兩週，實際花了五週，而且我太晚才回報進度落後。之後只要碰到我沒接觸過的系統，我都會先花一點時間做技術驗證再估時程；比較長的專案，我每週五都會在頻道裡更新進度，就算沒什麼新進展也會講。
不要寫「我太認真」「我太要求完美」這種假缺點。主管一眼就看得出來，還會讓整份自評看起來比較不老實。
「對團隊的貢獻，或跟其他人的合作？」
這半年我 review 了大約 120 個 PR，並把自己一直重複留的意見寫成 lint 規則，大家就不用在 review 裡反覆爭論同樣的事。我也跟行動團隊一起工作了兩週，讓他們的離線同步可以接上我們的新 API，他們因此提早發布了一個版本。另外我負責後端職缺的面試流程，最後成功招募到兩位。
「專業能力有什麼成長？」
這半年之前，我從來沒有在正式環境維運過 Kafka。我接手了事件 pipeline 的 consumer，學會看延遲監控，也自己處理過兩次相關事故。接下來我想加強容量規劃，這部分我目前還很依賴別人。
「下一期的目標是什麼？」
好的目標要具體到半年後回頭看，可以明確說出有沒有達成。
- 主導通知系統改寫的設計，從 RFC 一路帶到第一次正式上線。
- 帶一位比較新的工程師完成他的第一輪 on-call。
- 把核心 API 的 p99 延遲壓到 300 毫秒以下，目前是 450 毫秒。
「請給自己打分數」
如果考核表要你自評分數，就誠實地選，再用一兩句具體的事實撐住它。常見的五分制大概是這樣，有些公司用甲乙丙或 A、B、C，意思也差不多：
| 分數 | 通常代表 |
|---|---|
| 1 | 遠低於預期，或沒達成目標 |
| 2 | 部分達成 |
| 3 | 達成預期 |
| 4 | 超出預期 |
| 5 | 遠超出預期 |
我給自己 4 分。我最主要的目標，帳務服務拆分，如期上線了，CI 的改善也超出原本的規劃。沒有給 5 分，是因為搜尋重建索引的專案延誤了三週。
比自己心中的分數低一點點，看起來是有判斷力；低太多，只會讓主管少了幫你爭取的空間。
不同資歷的範例
資歷越深，題目還是那幾題，但一個好答案涵蓋的範圍會跟著變大。
初階工程師
剛入行的前一兩年，主管想看到的是你能穩定交付、學得快，而且每一季需要別人幫忙的地方都少一點。小事也算數，只要有做完。
工作成果： 這半年我完成了 14 張票，包括客服從去年就一直在要的後台 CSV 匯出，現在每週大約被用 200 次。我也追了排程信件的時區 bug，一路查過三個服務才修好，這是我第一次自己從頭到尾 debug 完一個問題。
成長： 剛進來的時候，大部分的票我都需要有人陪著做。到了下半段，中等大小的票我已經可以自己處理，只在設計階段請人給意見。接下來我想自己負責一個小功能，從規格一路做到上線。
資深工程師
到了資深，主管看的是專案是不是因為你才順利落地，以及你身邊的人有沒有變得更好。
工作成果： 我帶著另外兩位工程師，從 RFC 一路完成通知系統的改寫上線。發送失敗率從 4% 降到 0.5% 以下，也停用了一個每月大約花掉 3,000 美元的外部服務。我也建立了團隊的設計審查流程，之後有五份 RFC 走過這個流程，其中兩份因為審查時提出的意見而調整了方向。
帶人： 這半年兩位新同事到職，我都是他們的 onboarding buddy。兩個人都在到職兩週內就把程式碼推上正式環境，其中一位現在負責維護我們的 on-call 手冊。
Staff 工程師或 Tech Lead
到這個層級，問題會從「你做了什麼」變成「因為有你，組織有什麼不一樣」。
工作成果： 我提出把三套工作佇列整併成一個平台的提案，並讓四個團隊對遷移計畫達成共識。目前已經有兩個團隊完成遷移，這兩個團隊因為佇列問題被叫起來的次數少了大約六成。我也訂出了第一級服務的可靠性標準，現在已經放進每次上線前的檢查清單。
待改進： 佇列遷移那段時間，我陷在細節裡太久，也太晚把第二個團隊的切換交出去。下半年我想把重心放在設計和排除障礙上，讓各團隊的 lead 自己負責執行。
不同職務的範例
不管哪個領域，寫法的結構都一樣，差別在於主管會看的數字不同。
前端
我主導了結帳頁的效能改善，主要是拆分 bundle、讓付款元件延遲載入，行動版的 LCP 從 3.8 秒降到 1.9 秒。現在這一頁通過了 Core Web Vitals，隔月行動版結帳的放棄率也降了大約 4%。
SRE、平台或 DevOps
我把服務搬到新的部署流程上，平均部署時間從 25 分鐘縮短到 8 分鐘，週五部署又變回一件無聊的小事。我也替三個第一級服務訂了 SLO，並加上錯誤預算告警，現在服務慢慢變差的時候，我們會比客戶先發現。清掉閒置的 staging 叢集之後，雲端費用也少了大約 12%。
行動開發
我修掉了圖片快取的記憶體洩漏，並把 crash 分組加進發版檢查清單，Android 的無當機工作階段比例從 98.9% 提升到 99.7%。我也把發版頻率從每月一次改成每兩週一次，兩季下來 App Store 評分從 4.2 升到 4.5。
資料工程
我用增量模型重建了每晚跑的營收 pipeline，執行時間從三小時縮短到 25 分鐘，財務部門早上九點就能拿到數字，不用等到中午。我也替主管儀表板背後的五張資料表加上資料品質檢查，已經在有人看到錯誤數字之前，攔下兩次上游的錯誤資料。
可以直接套用的短句
有時候考核表只要你寫一兩行。下面這些可以當作起點，把括號換成你自己的實際內容。
寫成果：
- 「完成【專案】，帶來【結果，最好有數字】。」
- 「把【指標】從【原本】改善到【之後】，做法是【你改了什麼】。」
- 「解決了【團隊或專案】卡住的地方，做法是【你做了什麼】。」
寫負責任的態度：
- 「從頭到尾負責【系統或領域】，包括值班和規劃。」
- 「在別人還沒發現之前就注意到【問題】，並且【你怎麼處理】。」
寫協作和帶人：
- 「跟【團隊】一起完成【專案】，結果【成果】。」
- 「帶【某人或某個職位】完成【里程碑】。」
寫成長：
- 「學會【技術或能力】，並用它【具體成果】。」
寫待改進：
- 「我想加強【能力】。這半年因為這點，【具體發生的事】。下半年我會【具體的做法】。」
真正難的是想起自己做過什麼
上面每一段範例回答裡都有數字或日期，而這正是大多數人打開考核表時手上沒有的東西。你記得那次大上線，但不記得 CI 的改善是三月做的，也不記得失敗率從 18% 降到了 3%。
解法是事情發生的時候就記下來。每天下班前一行就夠了，到了考核的時候，你只是從清單裡挑重點，而不是拼湊半年前的記憶。
Perfly 就是圍繞這個習慣做的，而且盡量幫你把事情做掉：
- 你每天隨手記幾行，或是連接 GitHub、Jira、Google Calendar、Notion，讓 Perfly 根據你的活動先擬好。如果你平常用 Claude Code、Codex 或 Cursor，也可以讓 Agent 幫你把摘要送過來。不管哪種方式，要留哪些都由你確認。
- 到了考核的時候，選好期間（一季、半年或一整年），Perfly 就會用這些確認過的項目擬出你的自評。草稿會分成主管通常最在意的六個面向：影響力與範圍、技術深度、方向性、協作與影響他人、執行力與責任感、學習與成長。如果你有設定年度目標，每個目標都會有自己的區塊，列出支撐它的工作。
- 每一句話都會連回它的來源項目，所以主管問「那是什麼時候的事？」，你答得出來。
- 它可以建議 1 到 5 分的自評分數，附上簡短的理由，整體和每個目標都有。要不要採用由你決定。
- 最後複製到公司的考核系統，或匯出成 Markdown、列印出來。想的話，還可以跟讀過你自評的 AI 面試官先演練一次考核面談。
這次考核才開始記也來得及。連接 GitHub 和 Google Calendar，Perfly 可以把過去 12 個月的活動拉進來、整理成幾個主題，讓你挑出重點。它不會知道你做過的每一件事，但總比對著空白欄位發呆好。
同一批項目也會用在你的週報和履歷上，這個習慣不只幫你寫一份考核表。
常見問題
自評要寫多長？
比你想的短。大部分題目寫一兩段短短的文字，或三到五個條列就夠了。主管要看一整疊，所以最有力的那一點放第一個。
可以用 ChatGPT 寫自評嗎？
拿來潤稿沒問題。麻煩的是 ChatGPT 不知道你做了什麼，叫它從零開始寫，你只會得到這篇一開頭那種千篇一律的句子。如果你先給它一份附上數字的實際成果清單，它會寫得好很多，但大多數人手上就是沒有這份清單。
要提到自己犯的錯嗎？
要，簡短提就好，並且每一件都配上你之後改了什麼。完全沒有缺點的自評，反而比有一個真實缺點的更難讓人相信。
公司看得到我在 Perfly 寫的東西嗎？
看不到。Perfly 是個人工具，沒有團隊後台，也沒有管理員視角。要放什麼進公司的考核系統，由你自己決定。
Perfly 多少錢？
前 30 天免費，所有功能都能用。之後每月 $6.99，或每年 $69.99。