我對照 Senior Frontend Engineer 與 Applied AI Engineer 的期望審視了自己的履歷。結果令人鼓舞，但也暴露出一個有用的差距：履歷證明我能建構並交付複雜產品，卻未能一貫展現 senior engineer 所期望的更廣泛影響力、quality systems，以及 operational judgment。
這是對履歷證據的評估，而不是對我能力的完整量度。有些弱點可能是我尚未清楚記錄的經驗；另一些則是我需要刻意培養的能力。
我 2026 年的目標不是收集更多 framework 名稱，而是更擅長做出 technical decisions、降低風險、提升其他工程師的產出，並在 production 中可靠地運營 frontend 與 AI systems。
1. 我現在的位置
我最強的定位，落在 frontend product engineering 與 applied AI systems 的交匯處。
Frontend product engineering
React / Next.js / accessibility / performance / design systems
\
→ Senior Frontend Engineer for AI Products
/ Applied AI Engineer with frontend depth
Applied AI systems
agents / RAG / evals / observability / durable workflows我已交付超過 15 個 React 與 React Native 應用，建構共用 component libraries，在 Figma 設計介面，優化 web 與 mobile performance，開發 typed APIs，並在 AWS 上部署基礎設施。我也建構過 agent workflows、durable streaming、memory、RAG pipelines、retrieval 與 reranking、observability，以及 evaluation suites。
這種組合之所以有價值，是因為 AI product 仍然需要是一個好產品。它需要可理解的介面、accessible 的互動模式、可靠的 state management、有用的 failure states、快速的 rendering，以及能為 agent 產出的答案與行動提供清楚證據。
這次審核得出以下定性基準：
Resume-evidence baseline
Senior frontend engineering 7.4 / 10 ███████░░░
Applied AI engineering 7.6 / 10 ███████░░░
Technical leadership 5.5 / 10 █████░░░░░
Quality and risk management 5.8 / 10 █████░░░░░這些數字不是客觀技能評分。它們用來辨識：履歷中哪些部分對 hiring team 已經有說服力，哪些部分仍依賴假設。
2. 我最強的 Signals
| Signal | Evidence | Why it matters |
|---|---|---|
| Frontend delivery and performance | 15+ React and React Native apps；在 load time、search latency、Core Web Vitals、deployment speed 與 crash-free sessions 上有可量度的提升 | 證明我能交付並改善面向用戶的系統 |
| End-to-end ownership | Design、frontend、typed APIs、data、AWS infrastructure、deployment 與 observability | 幫助我跨越產品與系統邊界做決策 |
| Applied AI systems | Durable agents、RAG、tools、workflows、traces、cost and latency metrics，以及 eval suites | 展現超出 chat-completion demo 的 production AI 工作 |
| Product collaboration | 直接與 client 與 stakeholder 做 scoping、UX iteration 與 delivery | 證明我能把模糊需求轉成技術工作 |
Frontend Delivery and Performance
我可以把 frontend product 從設計帶到 production。經驗涵蓋 React、Next.js、React Native、design systems、animation、data visualization、forms、state 與 server data、CMS integrations、search，以及 deployment。
履歷也包含可量度的 performance 成果：
- 把 page load time 減少 80%
- 把 search latency 減少 90%
- 達到 LCP 低於 0.5 秒 與 CLS 低於 0.1
- 把 build 與 deployment time 減少超過 50%
- 在一個 React Native 應用中維持超過 99.5% crash-free sessions
這些結果比技術清單更有力，因為它們證明我能診斷問題，並改善用戶或工程師能感受到的結果。
End-to-End Ownership
我習慣在 component 邊界之外工作。我在 frontend 應用之外，也建構過 typed APIs、authentication、database access、search、cloud infrastructure、observability，以及 deployment pipelines。
這種廣度幫助我做出更好的 frontend 決策。我能理解資料從哪裡來、API 提供哪些保證、authentication 如何影響 navigation 與 caching、deployment architecture 如何影響 performance，以及 production failures 可能出現在哪裡。
Applied AI Systems
我的 AI 經驗不只是在應用裡加一個 chat completion endpoint。我曾處理：
- 客戶可以斷線並恢復的 durable agent runs
- tools、workflows、memory、scheduling、workspaces 與 retries
- 橫跨 web 與 Discord 的 multi-channel 體驗
- RAG ingestion、chunking、retrieval、reranking 與 graph queries
- agent traces 以及 cost 與 latency metrics
- 使用 golden prompts 與 LLM-as-judge 的 scored evaluation suites
- 可組合的 chat、tool-invocation 與 file-mention 介面
這支撐一個可信的 Applied AI Engineer 或 Senior Frontend Engineer for AI Products 形象。
Product and Stakeholder Collaboration
我曾直接與 clients 與 stakeholders 合作，做 scoping、迭代 UX，並交付 releases。Seniority 要求的不只是正確實作規格，還要找出真正的 constraint、解釋 trade-offs，並幫助團隊決定應該建構什麼。
我已有部分這類證據，但我需要更清楚地記錄決策及其影響。
3. 我需要強化的地方
| Gap | Current signal | Target evidence |
|---|---|---|
| Technical leadership | Project leadership、reviews 與 shared libraries | Mentoring outcomes、被採納的 RFCs、團隊 standards，以及跨團隊影響力 |
| Frontend architecture | 廣泛的 framework 與 delivery 經驗 | 有文件記錄的 state boundaries、rendering decisions、browser constraints 與 trade-offs |
| Testing and reliability | Cypress、Vitest、Testing Library、Sentry 與 observability | Layered test strategy、release gates、SLOs，以及由 incident 驅動的 regression coverage |
| Accessibility | Semantic HTML、keyboard support、Lighthouse 與 axe | WCAG 2.2 AA criteria、手動 keyboard 與 screen-reader audits，以及 CI enforcement |
| AI safety and evaluation | Durable runs、retries、traces 與 LLM-as-judge | Permission boundaries、adversarial cases、deterministic metrics，以及 recovery behavior |
| Production operations | Cloud deployment 與 application monitoring | Real-user monitoring、service objectives、alerting，以及 incident ownership |
Technical Leadership and Team Leverage
我目前 profile 最大的弱點不是實作能力，而是缺少證據證明我的工作提升了團隊產出。
履歷說我帶領過 projects、review 過 frontend code，並建立 shared libraries。它沒有說明：
- 我支援過多少工程師
- 我是否 mentored 其他 developers
- 我引入了哪些 standards 或 architecture decisions
- shared library 被 adopted 的範圍有多廣
- 我的工作是否減少了 review time、defects、duplication 或 onboarding time
- 我如何處理分歧或模糊的技術決策
Senior engineer 是 multiplier。我需要證明自己能創造清晰度、建立有用的約束，並幫助其他工程師交付更好的工作，而不成為瓶頸。
Frontend Architecture and Browser Fundamentals
履歷展示了強大的 frontend toolset，但工具本身不足以證明深度。
我需要更強的證據，說明我如何思考：
- component API design 與 composition
- client、server 與 URL state boundaries
- rendering 與 hydration
- browser scheduling 與 critical rendering path
- network behavior、caching 與 resource loading
- 進階 TypeScript constraints
- design-system governance 與 migration
- 在真實裝置與 network 條件下的 performance measurement
目標不是背誦 browser trivia，而是把 browser 行為連接到架構決策與用戶結果。
Testing and Reliability
履歷列出 Cypress、Vitest、React Testing Library、Lighthouse、axe、Sentry，以及 agent observability。這證明我熟悉有用的工具，但尚未說明我的 quality strategy。
我需要展示如何決定：
- 哪些行為屬於 unit、component、integration 或 E2E test
- 哪些 critical journeys 應擋住 release
- 如何測試 API 與 state boundaries
- 如何偵測 visual regressions
- 如何處理 flaky tests
- production incidents 如何變成 regression tests
- monitoring、SLOs 與 incident reviews 如何回饋到開發
Senior signal 不是我會寫測試，而是我能設計一套 quality system，在不讓交付變慢或脆弱的前提下，抓住重要失敗。
Accessibility Depth
我目前記錄了 semantic HTML、keyboard-accessible 的 navigation 與 forms、可見 focus、有意義的 alt text，以及用 Lighthouse 與 axe 做自動化檢查。
這是有用的基準，但自動化工具只偵測到 accessibility 問題的一部分。我需要更深入練習：
- WCAG 2.2 AA requirements
- 手動 keyboard testing
- VoiceOver 或其他 screen reader
- dialogs、menus 與動態 views 中的 focus management
- accessible names、descriptions、errors 與 status announcements
- contrast、zoom、reflow、motion preferences 與 touch targets
- CI 中的 accessibility checks 與 release acceptance criteria
Accessibility 應是設計與實作的一部分，而不是最後才跑的報告。
AI Safety、Failure Handling 與 Evaluation Rigor
我的 AI 工作已包含 retries、durable runs、traces、cost 與 latency metrics，以及 scored evaluations。下一步是證明這些系統在出錯時仍能安全且可預期地運作。
我需要更強的經驗與證據，圍繞：
- prompt-injection 與 data-exfiltration tests
- 有範圍的 tool permissions 與 authorization
- structured-output validation
- idempotent tool execution
- timeouts、circuit breakers 與 model fallbacks
- 敏感操作前的 human approval
- partial failure 與 recovery
- adversarial 與 regression evaluation sets
- 把 retrieval quality 與 generation quality 分開
- 跨 models 與 retrieval strategies 比較 quality、latency 與 cost
LLM-as-judge 有用，但不應是唯一量度。我還需要 deterministic checks，以及像 tool-call success、retrieval recall、groundedness 與 end-to-end task completion 這類 task-specific metrics。
Applied AI Versus ML Engineering
我目前的證據在 applied AI 與 agent engineering 上最強，而不是以模型為中心的 ML engineering。
如果我鎖定偏重 ML 的職位，就需要在 statistics、experimentation、data preparation、model training、fine-tuning 與 model evaluation 上更深。如果我繼續鎖定 product 與 agent 角色，就應明確說出，並加深讓 AI features 可靠的 system-design 技能。
目前，我打算的定位是：
Senior Frontend Engineer for AI Products 或 Applied AI Engineer with deep frontend expertise。
這比把自己呈現為一般 AI 或 ML engineer 更準確、也更有差異化。
4. Evidence Gaps 與 Capability Gaps
我需要區分：哪些是應更好描述的經驗，哪些是應主動建構的技能。
| Evidence I need to capture | Capabilities I need to strengthen |
|---|---|
| Team size、mentees 與跨團隊影響力 | 正式 mentoring 與 technical-standard ownership |
| Architecture options 與 trade-offs | Browser、rendering 與 state architecture 深度 |
| Users、traffic、agent runs、corpus size 與 p95 latency | Real-user monitoring、SLOs 與 incident response |
| Test strategy 與被阻止的 defects | Integration、contract、visual 與 failure-path testing |
| Design-system adoption 與 migration results | Design-system governance 與 deprecation |
| Production failure stories 與 recovery outcomes | Agent security、permissions 與 adversarial evaluation |
| 已做過的 model 與 retrieval comparisons | Quantitative experiment design 與 ML fundamentals |
這個區分避免兩個錯誤。我不應花數月重學自己已會、只是沒記錄清楚的事；也不應改寫履歷 bullet，暗示自己尚未展現的能力。
5. 首 3 個月：把工作變成 Evidence
我的首要任務是讓工程推理可見，並建立更強的 quality baseline。
0–3 months Turn work into evidence
case studies → quality matrix → accessibility → agent evals
3–6 months Build reliability and team leverage
failure boundaries → SLOs → RFC / mentoring → model comparisons
6–12 months Demonstrate senior scope
cross-team leadership → governance → published case studyWrite Three Architecture Case Studies
我會用同一結構記錄三個 projects：
- 產品與技術 constraint
- Scale 與 reliability requirements
- 考慮過的 options
- 選擇的 approach
- Trade-offs 與被否決的 alternatives
- Rollout 與 failure handling
- 量度到的 outcome
- 我現在會改什麼
至少一份 case study 聚焦 frontend architecture，一份聚焦 durable agent systems，一份聚焦 backend 或 cloud architecture。
Success measure： 三份完成的 case studies，包含具體 constraints、decisions 與 outcomes。
Establish a Frontend Quality Matrix
我會定義每一測試層應涵蓋什麼：
| Layer | Tool or practice | Protects |
|---|---|---|
| Unit | Vitest | Pure logic、parsers、validation 與 state transitions |
| Component | React Testing Library | 用戶可觀察的互動，以及 accessible component contracts |
| Integration | Testing Library with controlled API boundaries | State、data fetching、errors、retries 與 recovery |
| E2E | Cypress | 橫跨 routing、authentication 與真實 browser behavior 的 critical journeys |
| Visual | Targeted visual regression checks | 視覺破壞代價高、或難以用語意表達的 layouts |
| Accessibility | axe in CI plus manual keyboard and screen-reader testing | 自動化規則違規，以及自動化無法偵測的互動問題 |
| Production | RUM、error monitoring 與 SLOs | Pre-production tests 無法重現的 failures 與 performance 條件 |
Success measure： 每個進行中的 project 都有記錄的 critical journeys，並為每個高風險行為指定明確的 test layer。
Deepen Accessibility Testing
我會在合適處把 axe checks 加入 CI，但不會把自動化綠燈報告視為完整的 accessibility coverage。
對重要 flows，我會測試：
- keyboard-only navigation
- 可見且合乎邏輯的 focus
- VoiceOver output
- form errors 與動態 announcements
- zoom 與 reflow
- reduced motion
- WCAG 2.2 AA acceptance criteria
Success measure： 一份可重用的 accessibility checklist、一份有文件的手動 audit，以及在關鍵頁面上的自動化檢查。
Expand Agent Evaluations
我會建立一套 failure-oriented evaluation set，而不是只評估預期成功的 prompts。
這套 suite 將包含：
- tool-selection 與 argument correctness
- retrieval relevance 與 recall
- citation 或 evidence grounding
- end-to-end task success
- permission failures
- malformed tool output
- model timeouts 與不可用的 dependencies
- prompt-injection attempts
- latency 與 cost budgets
Success measure： 一套有版本的 evaluation set，包含 deterministic checks、scored checks、failure categories，以及能偵測 regressions 的 baseline。
6. 第 3–6 個月：建立 Reliability 與 Team Leverage
Engineer Explicit Failure Boundaries
對一個 agent system，我會實作並記錄：
- least-privilege tool access
- tool boundaries 上的 schema validation
- 可重試動作的 idempotency
- timeouts 與有界 retries
- model 與 retrieval fallbacks
- 敏感操作的 human approval
- UI 中清楚的 partial-failure states
- 可追蹤的 decisions 與 tool results
Success measure： 一個 production workflow，具備有文件的 threat cases、recovery behavior，以及 adversarial regression tests。
Add Production Service Objectives
我會把 frontend 與 agent observability 連接到明確的 service objectives。
可能的 indicators 包括：
- 來自真實用戶的 Core Web Vitals
- frontend error 與 recovery rate
- agent task success
- tool-call failure rate
- p95 time to first token 與 total run duration
- retrieval latency
- cost per successful task
我會進行一次 incident exercise，並撰寫一份產生具體後續工作的 blameless postmortem。
Success measure： 至少一份有文件的 SLO、以用戶影響為依據的 alerting，以及一次完成的 incident review。
Create Team-Level Impact
我會擁有一項 engineering standard 或 RFC，並透過一段有意義的工作 mentoring 另一位工程師。
結果應可透過 adoption、減少 duplication、更快 onboarding、更少 regressions，或更短 review cycles 來量度。
Success measure： 一份被採納的 RFC 或 standard、持續的 mentoring evidence，以及可量度的團隊結果。
Compare AI System Choices Quantitatively
我會記錄某個 project 為何使用特定 model、embedding、chunking strategy、reranker、cache 或 routing policy。
比較會考慮：
- task quality
- retrieval quality
- latency
- cost
- failure rate
- operational complexity
Success measure： 一次可重現的比較，改變或驗證了一項 production architecture decision。
7. 第 6–12 個月：展現 Senior Scope
在 12 個月結束時，我希望有反覆證據證明自己能帶領複雜 initiative，而不只是單一孤立例子。
我會致力於：
- 帶領一個 cross-team project，從模糊需求走到 architecture、rollout、monitoring 與 iteration。
- 為 design system 或 AI platform 建立 governance，包括 ownership、versioning、migration 與 deprecation。
- 發表一份脫敏的 technical case study 或 open-source artifact，解釋工程決策與 trade-offs。
- 在能改善 applied AI 決策的地方，持續加深 ML fundamentals。
- Mentoring 工程師，並建立即使我不持續介入仍然有用的 standards。
Success measure： 一份決策與結果的 portfolio，展現產品影響、production reliability，以及提升的團隊產出。
8. 我如何量度進度
到這個計劃結束時，我應能為以下項目提供證據：
| Goal | Evidence |
|---|---|
| 解釋 architectural judgment | 三份 case studies，以及至少一份被採納的 RFC |
| 展現 frontend quality leadership | 與關鍵產品風險綁定的有文件 test strategy |
| 展現 accessibility 深度 | WCAG 2.2 AA checklist、CI checks，以及手動 assistive-technology testing |
| 運營 production systems | RUM 或 agent SLIs、一個 SLO、alerts，以及一次 incident review |
| 建構可靠的 AI products | Versioned evals、adversarial cases、permission boundaries、validation 與 recovery paths |
| 倍增團隊產出 | Mentoring evidence，以及可量度的 standard、library 或 process outcome |
| 傳達 scale | Users、traffic、run volume、corpus size、p95 latency、reliability 與 cost（若可得） |
我會每季覆核這份 scorecard。如果某項活動無法連接到這些結果之一，我就應質疑它是否是發展時間的最高價值用途。
9. 履歷應如何改變
我的履歷已有足夠技術。下一版應包含更多 evidence。
我應該：
- 在 summary 中選擇清楚的 target identity
- 描述重要系統的 scale 與 constraints
- 解釋困難的 decisions，而不只是命名所選 stack
- 量化團隊與用戶 impact
- 展示 failures 如何被偵測與恢復
- 記錄 mentoring、standards 與跨團隊影響力
- 用 quality strategy 與 outcomes 取代只列工具的 testing claims
- 納入 AI safety、permission 與 evaluation evidence
在工作尚未支撐之前，我不應加上主張。履歷應因我的 scope 與 judgment 成長而變強，而不是因為用詞變得更誇張。
Takeaway
我已擅長跨 frontend、backend、cloud 與 applied AI 建構產品。要成為更強的 senior engineer，我需要刻意轉變：
| From | To |
|---|---|
| 交付自己的工作 | 提升 team 的產出 |
| 使用 testing tools | 設計 quality systems |
| 量度 happy paths | 工程化 failure recovery |
| 自動化 accessibility checks | Inclusive design 與手動驗證 |
| 建構 agent features | 證明其 safety、quality 與 reliability |
| 列出 technology choices | 解釋 technical judgment |
我職業的下一階段，不會由我懂多少 frameworks 定義，而會由決策品質、我預防的風險、我能運營的系統，以及因為我在團隊裡而做得更好的工程師來定義。