2026 个人发展计划

我对照 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 study

Write 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 定义，而会由决策质量、我预防的风险、我能运营的系统，以及因为我在团队里而做得更好的工程师来定义。

阅读下一篇笔记

用 Hono、Better Auth、Drizzle 与 Postgres RLS 打造 Multi-Tenant 后端