从 AI 工程到产品技术专家：我的三年职业发展规划

修订记录

当前版本：V2.0｜规划有效期：2026.11.01—2029.11.01｜本次修订：2026.11.01

一句话定位：未来三年，继续深耕工程一线，成长为能判断模型执行方案、实现授权边界，并对产品结果负责的 AI 产品技术专家。

AI Systems & Product Engineering · Agentic Computing · 2026.11.01—2029.11.01

过去几年，我的关注点逐渐从 Web 工程、全栈开发延伸到 AI Agent。最初关心的是如何让模型调用工具、执行 Workflow；后来开始深入 Browser Automation、Agent Runtime、技能沉淀以及 AI 原生软件的实现方式。技术问题越来越复杂，我也越来越确定，自己感兴趣的并非某个框架，而是如何用新的计算能力，构建真正有价值的软件产品。

这种变化让我重新思考未来三年的职业方向。我不想离开工程一线，转成传统意义上的产品经理；也不希望职业身份被“前端”“浏览器”或某项短期热门技术锁定。我希望沿着技术专家序列继续成长：既能够设计复杂 AI 系统，也有能力发现问题、判断产品机会，并将想法交付成真实产品。

这篇文章是一次阶段性自我校准。我会明确区分三个容易混淆的东西：**职业身份是我想成为谁，技术判断是我选择研究什么，实践成果是我用什么证明判断与能力。**三者相关，但不能互相替代。

一、职业身份：AI Systems & Product Engineering

我给自己的职业定位是 AI 产品技术专家，英文能力方向为 AI Systems & Product Engineering；长期对标的国际岗位是 Staff AI Engineer / Staff Software Engineer (AI)。

Staff 是未来希望承担的问题范围，而不是今天已经拥有的头衔。我更倾向于 Individual Contributor（IC）的专家路径：可以影响技术战略、协调复杂工作，却不以正式带团队和人员管理作为身份的必要条件。

技术是根基：AI Systems Engineering

今天构建一个 Agent Demo 并不困难。真正困难的是把它交给真实用户之后：任务运行到一半中断怎么办？登录态失效怎么办？模型反复调用错误工具怎么办？多个 Agent 如何共享资源又不越权？结果如何验证？成本和延迟是否能接受？

这些问题无法单靠更强的 Prompt 解决，它们要求软件架构、分布式系统、执行环境、状态管理、安全隔离、评测与可观测能力共同工作。因此，我希望形成的深度不是“熟悉很多 Agent 框架”，而是能够设计、实现和持续改进生产级 AI 系统。

我仍然会投入编码和系统调试。产品技术专家需要保有足够的一线工程判断力，否则很容易只会描述方向，却无法判断技术代价和实现风险。

产品是方向：AI Product Engineering

同样，一个架构先进的系统也可能毫无产品价值。技术工程师常常习惯先看到某项能力，再寻找适合使用它的场景；但真正的产品思维应当能够反过来，先识别问题，再选择必要的技术。

我希望补强 Product Discovery、用户研究、产品定位、方案取舍、Human-AI Interaction 和端到端交付。能够讨论的不只是 How，还包括 Why 和 What：为什么值得做、什么才是关键需求，以及哪些功能即使能做也应该暂时不做。

这并不意味着要同时扮演所有产品与工程角色，而是希望具备跨越两边的判断力。**技术深度决定能实现什么，产品判断决定什么值得实现。**它们结合起来，才构成我想长期积累的职业壁垒。

二、对照国内与国际岗位，选择可迁移的能力

职业规划不能只根据当前项目制定。我对照过国内大厂的 AI Agent / AI 平台岗位，也研究过硅谷的 Product Engineer、Agent Infrastructure，以及东京国际化企业的 Staff AI Engineer、Applied AI Engineer、Forward Deployed Engineer 等方向。

此前参考的岗位各有侧重：运行时、隔离和评测，客户问题发现与交付，以及系统架构和业务落地。这些是形成规划时的参考维度，不把某家公司的招聘描述当作持续有效的岗位标准；真正申请岗位时再核对当期要求。

我从中归纳出四项相对稳定的能力要求。

**第一，解决复杂系统问题。**不能只完成局部功能，要理解系统边界、故障模式、性能和长期演进。

**第二，交付真实价值。**不仅展示技术可行性，还要通过产品体验、用户反馈或业务指标证明效果。

**第三，承担模糊问题。**高级专家不能总是等待别人给出完整 PRD，而应该能澄清问题、提出取舍并推动可执行的方案。

**第四，放大个人影响。**让架构、工具、方法或工程标准能够被其他人复用，而不只是自己写更多代码。

因此我不准备为了某个招聘标题，单独把自己训练成“Browser Agent Engineer”“OS Kernel Engineer”或纯粹的“AI PM”。具体技术专长必须深入，但最终应当能够迁移到不同产品形态、不同组织和不同工程问题中。

三、技术研究方向：Agentic Computing 与受控执行

职业身份回答“我需要什么能力”，技术研究回答“我愿意把深度投入哪里”。这部分我已经有一个相对明确的判断：Agentic Computing。

我的假设是，AI 的发展不仅会给现有软件增加智能功能，还可能改变计算机的使用方式。过去，软件主要围绕人通过键盘、鼠标、页面和菜单逐步操作来设计；现在，Agent 已经能够接收目标、规划步骤、调用工具和操作软件。未来的计算环境，可能需要同时支持人和 Agent，而不是仅仅为人类操作提供界面。

这不是已经被证实的行业结论，而是值得持续验证的 Technology Thesis（技术战略判断）。我希望研究的是：当 Agent 成为计算资源的实际使用者，软件架构、执行环境和人机协作需要如何变化？

本次修订的判断：让模型选择执行策略，让系统守住授权边界

接下来三年的一个重要假设是：随着模型能力增强，更多任务分解、工具选择和协作方式可以由模型按任务生成。Planner、Executor 或多 Agent 图是可以比较的实现选项，不应成为职业规划必须维护的固定形态。对于规则明确、重复性高或需要严格保证顺序的任务，确定性 Workflow 仍然有价值；选择依据应当是成功率、风险、延迟和成本的对照结果。

这意味着，我需要提高审核执行方案的能力，同时设计能够自动审核常规方案的系统。模型提出目标、依赖步骤、工具与数据范围、预算、验收方式及升级条件；系统做结构化校验，并在执行时继续检查实际动作。审核通过的是限定范围内的行为，不是一张可以任意调用工具的通行证。 任务发生变化、参数越界或权限过期时，应暂停、重规划或重新申请授权。

我准备明确区分两类职责：执行策略可以由模型调整；权限、预算、审批和审计由独立于模型决策的治理机制约束。“独立”首先是信任与职责边界，可以先在现有运行时里实现，不意味着新建一套控制平台。模型不能修改自己的权限，也不能在调用被拒后换工具、拆金额或委派给另一个 Agent 绕过同一限制。

工程师负责把授权规则实现为可检查的系统约束，业务、数据或系统责任人保有相应的最终授权权。人还要决定任务目标、可接受的代价和产品价值，不能把全部责任缩成批准一次工具调用。

审批按风险与授权范围触发

审批不应机械地插入每一步。已有权限范围内、非敏感的只读分析可以自动进行；写生产、动钱、对外发送和访问敏感数据，应根据影响范围、可逆性、数据等级与既有授权判断是否升级。只读查询也可能导出敏感信息，不能直接等同于低风险。

例如，在“超过 500 元的退款必须人工审批”的既有规则下，模型提出给某位老客户自动退 800 元，只能形成规则变更建议，当前执行仍须遵守 500 元边界。后续由有权责任人评审建议，经过测试、灰度和版本化发布后，才能改变授权规则。这是说明边界的假设示例，不是本人已经实施的业务机制。

职业成长因此包括两种审核：对例外执行方案做风险判断，对一类行为的规则做制度设计。日常低风险提案应尽量由规则和评测自动筛选，不能让工程师成为每项任务都要经过的人工关卡。

跨环境执行的研究位置

研究仍以 Agentic Computing 为主线。当前从浏览器执行环境切入，关注 Chromium、CDP、DOM/Accessibility/视觉混合感知，以及任务恢复与安全操作；同时把 Browser、Android、iPhone、Computer 作为四类独立环境，分别理解它们的身份、权限、设备与生命周期约束。

浏览器或某一移动端可以先落地，但不能把单端成功等同于跨环境完成。桌面与系统接口的研究，也不等于要从内核、驱动开始自建操作系统。基础能力优先沿用已有执行器、设备管理和隔离机制，只有现有链路不能解决的实际问题才增加新边界。

更值得长期投入的是不同环境共同面对的问题：谁提出任务、谁批准权限、如何约束实际副作用、失败后怎样恢复、结果怎样独立验证。产品侧通过真实任务检查委托、审批和接管体验，决定哪些能力值得继续。环境可以更换，这组问题及其证据标准应当可以迁移。

四、能力模型：一条技术深度，两条扩展方向

为了避免规划变成无限增长的学习清单，我将自己的能力建设分成六个方面，但不会平均投入。

软件与系统工程

保持 TypeScript、Node.js 和 Web 工程优势，进一步强化 Python、后端系统设计、分布式任务、数据库、队列、云原生、并发与容错。补齐操作系统进程、IPC、文件和权限等基础。Rust 或 C++ 是解决特定系统问题的工具，不是必须同时精通的语言收集目标。

Agent 与 AI 系统

深入模型能力边界、Context Engineering、Tool Use、Agent Harness、规划与执行、状态和记忆。尤其要理解什么时候应当交给模型推理，什么时候应当使用确定性程序；如何避免上下文漂移、重复动作和错误的副作用。

评测、可靠性与安全

把 E2E Eval、Trace、Replay、故障恢复和权限治理作为工程基础设施，而不是上线前的附加检查。一个任务即使完成了，如果过程中执行了未经授权的敏感操作，也不应被评价为成功。评测体系必须同时衡量任务结果和系统行为。

执行提案审核与治理工程

在规划与执行之外，补强四项可交付能力：定义可校验的任务契约；实现动作级权限、预算和审批约束；设计风险分级与授权交互；建设执行回放、回归评测和规则变更流程。静态方案审核与运行时检查缺一不可，提案通过后仍要检查实际参数和副作用。

学习重点包括最小权限、身份与凭证隔离、授权的范围和有效期、撤销、幂等及补偿、审计和敏感数据留存。优先复用现有系统中的机制；只有重复问题得到验证后，再抽取公共治理模块。学习成效用越权能否被阻断、失败能否被解释、用户是否减少无谓确认来衡量。

产品发现与 Human-AI Interaction

学习用户访谈、需求判断、产品优先级、任务体验和关键指标。尤其关注 Agent 产品的交互：用户如何委托任务、理解不确定性、确认敏感操作、接管异常和审查结果。

端到端产品工程

能从一个问题出发，经过验证、原型、开发、发布、数据观察与迭代形成闭环。复杂系统经验可以通过工作积累；真正独立的产品判断，则需要有明确的决策空间和对结果负责的机会。

技术影响力与表达

练习架构文档、ADR、技术复盘、开源贡献和跨团队协作。提升英语技术沟通能力，做到能完整解释设计依据、技术权衡、失败原因和改进结果。高级专家的影响力不取决于标题是否响亮，而取决于判断是否被采纳，成果是否被复用。

五、2026.11.01—2029.11.01：三个阶段与验收证据

对外，我希望逐步形成三类可公开核验的材料：使用合成数据复现的运行时与权限实验、说明用户问题和关键取舍的产品案例、能够由他人独立使用的评测或工程工具。工作中的经验可以帮助形成判断，但内部代码、运行数据和客户案例不能自动变成公开作品；无法获得公开授权的部分，用独立实现与合成场景表达，并注明验证范围。

英语技术表达贯穿三个阶段：先能讲清一次失败和修复，再能解释产品取舍，最后能用技术提案和设计评审推动协作。国际岗位是能力参照，不把地区、公司或职位名称设为必须完成的职业结果。

规划自 2026 年 11 月 1 日开始，至 2029 年 11 月 1 日复盘收口。三个年度阶段按周年划分，不再使用自然年的“2027、2028、2029”代替执行周期。系统工程、产品实践与经验复用始终并行，阶段只是投入重点；以下均为计划交付，不是已经取得的成果。

第一阶段：把可治理执行做成一个最小完整实验

从一类有代表性的任务开始，沿用现有工具、运行时和存储，补齐四项能力：结构化执行提案、动作发生前的授权检查、预算与终止条件、可供回放和评估的执行轨迹。先证明这些约束能起作用，再判断是否需要抽取公共模块。

先测量固定流程的任务结果、P50/P95 耗时、单次成功任务成本和人工介入，再与模型生成策略作对照。能力覆盖 Browser、Android、iPhone、Computer 四类环境的边界设计，实测从当前有设备与授权的一端开始；一个端通过不代表跨端能力完成。

验收材料至少包括：一组可复现任务与故障用例；工具不存在、参数越权、预算耗尽、授权撤销和绕过尝试的拒绝记录；失败后的恢复说明；一次真实用户反馈。验收器和工具授权由受控代码执行，模型自述“已经完成”只能是待核验证据。

2026.11.01—2027.01.31 的起步动作： 前 30 天选定场景、权限责任人、基线与数据口径；第 31—60 天跑通最小提案与拦截链路；第 61—90 天完成固定流程与动态策略对照、失败回放和首次评审。没有基线时不预先承诺百分比收益。

第二阶段：让风险分级真正改善产品体验

把实验放入一个目标用户会反复使用的产品，参与问题定义、授权交互、发布与复盘。让用户能看懂“要做什么、会影响什么、批准到哪里、怎样撤销”，并在异常时接管。已有低风险授权内自动执行，超出范围再请求审批。

以任务完成率、重复使用、审批等待、无必要打断和风险漏拦评估体验。至少完成两轮由反馈推动的迭代，保留改变优先级的依据。权限规则与模型、Prompt、工具版本关联，规则变更经过评审、回归和灰度；出现风险信号时能撤销授权并回退版本。

阶段验收： 一份包含样本和基线的产品案例；至少一次规则变更的测试、批准、灰度与回退记录；一套能解释误拦与漏拦的评估材料。若拿不到真实生产授权，就用隔离试点验证，并明确它不能证明生产验收。

第三阶段：以复用和决策质量证明专家能力

选择已经在真实使用中有效的能力，扩展到第二个任务场景或由另一位工程师独立使用，检验它究竟是通用方法还是第一场景的偶然适配。复用内容可以是权限适配、任务契约、评测集或运行时模块，不以新造完整框架为目标。

模型可以依据历史轨迹提出并行化、工具替换或预算调整建议；是否推广，由离线评测、回归、灰度和有权责任人决定。回放默认采用记录、模拟或隔离环境，不重新触发真实退款、生产写入或外部发送。

阶段验收： 一个由他人采用的成果、一份跨场景对照、一份包含失败与代价的架构决策记录，以及可分享的技术作品集。对外材料必须独立脱敏，不携带内部代码、数据、账户和客户信息。能否承担专家级问题由这些证据检验，不用职业头衔或预置 Agent 数量替代。

六、怎样复盘，何时调整计划

每季度做一次执行复盘，每半年做一次方向评审。第一次季度复盘为 2027.02.01；半年评审为 2027.05.01、2027.11.01、2028.05.01、2028.11.01、2029.05.01，最后在 2029.11.01 完成周期评审。复盘结论追加到文首修订记录，保留当时的选择与依据。

固定流程、模型动态规划和混合方案使用同一任务与口径比较。没有统计基线之前，不承诺“耗时从 90 秒降到 40 秒”之类的结果；有数据后才设阶段目标，并同时注明样本、环境和风险指标。评测中的越权用例必须阻断；有限测试零漏拦不等于实际环境绝对安全。

如果动态规划没有带来收益，就保留固定流程；如果新增治理机制只增加确认次数而没有改善控制效果，就缩小范围、修正规则。模型能力变强也不能成为取消授权边界的理由。技术假设允许被推翻，职业方向保留系统判断、产品责任和可验证交付这些可迁移能力。

七、写在最后

过去，我常用学到了什么框架、完成了什么需求来评价成长。未来三年，我希望换一种衡量方法：能否独立判断什么值得做，能否设计可靠的系统，能否用真实数据证明产品与工程价值，能否让技术成果超出个人工作范围继续产生影响。

职业身份上，继续沿 AI Systems & Product Engineering 的 IC 专家路径成长，朝 Staff AI Engineer 的问题范围努力；研究上，以 Agentic Computing 检验自主执行与受控授权的边界。 Staff 仍是能力目标，不是当前头衔，也不承诺在周期终点获得某个职级。

2026.11.01—2029.11.01，按工程基础、产品责任和可复用影响逐步推进，三条能力线始终并行。每次阶段评审都要能回答：模型获得了多少有效自主性，系统守住了哪些边界，用户得到了什么可以核验的结果。

我希望成为的，不是只会追逐最新 AI 工具的人，也不是脱离工程细节谈产品愿景的人，而是能够理解技术演进、识别值得解决的问题、构建复杂系统，并把技术创新转化为实际价值的产品技术专家。

Deep Technical Expertise · Strong Product Judgment · Real-World Impact

技术深度是根基，产品判断是方向，真实价值是最终标准。