目标

探讨随着 AI 改变软件开发成本结构,为什么产品工程可能成为传统 SDE 在 AI 时代的一个职业方向。

  • AI 如何影响传统 SDLC
  • SDE 在 AI 时代的能力迁移方向
  • 产品工程能力应该如何建立

是什么

Product Engineer 是同时具备产品判断和端到端交付能力的工程师。

  • 能理解用户问题和产品目标
  • 能基于产品取舍做技术决策
  • 能完成从方案到上线的交付
  • 能根据反馈评估效果并持续迭代

Product Engineer capability map

为什么

传统产品生命周期

先看一个常见产品生命周期。这里最重要的是问题和价值的配对:每个阶段解决什么问题,对应创造什么价值。

层级阶段关键问题价值
业务用户需求哪个用户问题值得解决?- 发现真实问题
- 明确需求和痛点
业务商业收入这个产品为什么值得投入?- 判断收入潜力
- 评估利润、增长或战略意义
产品方案定义和设计用什么方案解决这个问题?- 定义产品方案
- 设计用户体验
- 对齐关键取舍
技术技术规划方案如何可靠落地?- 澄清需求
- 设计架构
- 制定实施计划
技术实现如何完成构建并交付给用户?- 把计划实现为软件
- 通过测试保障质量
决策衡量和迭代结果是否符合预期?- 验证真实效果
- 降低后续决策的不确定性
- 判断下一步产品或业务动作

再看这些阶段在组织中通常由哪些角色承担。

层级解决的问题价值典型角色
战略方向解决什么问题,为什么现在解决?定方向、定成功标准、分配资源、做取舍Founder、Executive、Product Leader、Business Owner
战术规划构建什么,如何组织工作?把方向拆成计划、需求、设计、优先级和协作机制PM、Designer、Tech Lead、Data Analyst
执行如何构建、发布、运行和改进?交付系统,稳定发布,观察反馈并持续改进SDE、QA、SRE、Support、Sales、Marketing

AI 对 SDLC 流程的影响

AI 擅长什么,不擅长什么

AI 对工作的影响,主要取决于任务边界是否清晰。

  • 擅长:输入、输出、规则和评价标准清晰的任务。
    • 例子:编码、测试、文档和常规技术调研。
  • 不擅长:输入、输出、约束和成功标准都不清楚的复杂工作。
    • 例子:问题定义、用户上下文、业务取舍、产品判断和最终决策。

相关探索:AI exploration notes

对不同角色层级的影响

按上面的角色分层看,AI 对不同层级的影响并不相同。

下面的百分比来自我自己的经验体感,不是统计结论。它表示在当前 AI 能力下,各层级大概会被影响到什么程度。

层级AI 影响原因
战略方向30%战略依赖上下文、业务判断、资源分配和责任承担
战术规划50%规划既有结构化工作,也有产品、设计、数据和技术之间的复杂取舍
执行70%执行环节通常有更清晰的输入、输出、规则和评价标准

对公司组织和市场需求的影响

因此在组织调整时,纯执行型角色和一部分中间协调型角色更容易受到冲击。裁员和岗位减少不只和 AI 有关,也和招聘周期、资金成本、前几年扩张过快、公司降本增效有关。

组织收缩、效率要求提高之后,更稀缺的是这类人:能处理不清晰的问题,能做跨职能取舍,能用 AI 放大交付效率,也能把产品决策、技术交付和业务结果连起来。

招聘市场证据:

SDE 的新价值区和职业方向

新方向从哪里来

从产品生命周期看,SDE 值得投入的新方向,最好满足三个条件:

  • 短期内 AI 做不好。
  • 在产品生命周期里有明确位置。
  • SDE 能用软件工程能力参与进去。
层级AI 短期难度产品生命周期中的位置SDE 如何参与
战略方向高:目标、业务上下文和责任边界不清晰决定为什么做,以及什么结果最重要支持调研、定义问题、评估价值
战术规划中:结构化任务和复杂取舍混合把方向拆成产品、技术和执行计划拆解问题、明确约束、设计方案路径
执行低:输入、输出和评价标准更清晰把计划实现为软件,并拿到反馈用 AI 加速编码、测试和迭代

新价值链是什么

这里有两条路径:

  • 单层深度:继续在某一层加深,例如战略、规划、架构或执行。
  • 跨层连接:把战略、规划和执行串起来,形成结果闭环。

我更推荐跨层连接。

单层深度仍然有价值,但每一层都会被 AI 改变。更值得关注的机会,是连接这些层级,把不清晰的目标拆成可执行、可验证、能借助 AI 提效的工作。

在常见互联网业务团队里,Product Engineering 是跨层连接的一条具体路径。

维度业务团队基础设施团队
领域面向用户的产品和业务结果内部平台、工具和工程系统
角色方向Product EngineerPlatform Engineer / Infrastructure Architect
价值链用户问题发现
业务价值判断
产品方案拆解
AI 辅助交付
内部需求发现
平台价值判断
技术方案拆解
AI 辅助交付
能力深度更看重业务价值判断和产品取舍更看重架构、系统、性能、可靠性和代码质量

本文后续会聚焦 Product Engineer,而不是 Infrastructure Architect。

  • 我过去更多在应用、框架和系统架构方向积累深度。
  • 我现在对 Product Engineer 方向更感兴趣。

怎么做

本节只保留高层实践框架。

基本顺序是:先判断方向是否值得做,再验证方案是否成立,最后高质量交付。

Product Engineer 和纯 PM 或 Tech Lead 的差异,在于能把 discovery 接到工程闭环里:产品假设、原型、技术取舍、埋点、交付和迭代。

产品风险

在投入大量交付成本之前,先判断主要产品风险是否可控。

风险关键问题方法输出
用户价值用户是否真的需要?客户访谈、使用意愿、付费意愿用户需求证据
可用性用户能顺利使用吗?低保真原型、任务 walkthrough可用性风险评估
可行性团队能做出来吗?技术 spike技术可行性证明
商业可行性公司是否应该投入?stakeholder review商业可行性评估

Discovery

在正式投入方案前,用 discovery 降低不确定性。

步骤关键问题方法输出
问题定义用户是谁,场景是什么,痛点是什么?客户访谈、反馈分析问题陈述
假设预期带来什么变化?假设建模可测试假设
验证如何测试假设是否成立?原型、用户测试、A/B 实验验证结果
指标如何判断是否有效?业务指标、行为指标成功标准
决策应该继续、迭代还是停止?Go / iterate / kill review决策

Delivery

用 delivery 把验证过的方向落成可运行的软件,并拿到可衡量的结果。

步骤关键问题方法输出
架构验证过的方向如何落到技术结构上?架构设计、取舍评审架构决策
构建方案如何实现?编码、代码评审、测试、持续交付可运行的软件
衡量方案是否达到预期?指标追踪、用户行为观察结果信号
迭代下一步应该改变什么?数据评审、反馈评审、小步迭代下一个版本