目标
探讨随着 AI 改变软件开发成本结构，为什么产品工程可能成为传统 SDE 在 AI 时代的一个职业方向。
- AI 如何影响传统 SDLC
- SDE 在 AI 时代的能力迁移方向
- 产品工程能力应该如何建立
English version: Product Engineering: An SDE Career Path in the AI Era
是什么
Product Engineer 是同时具备产品判断和端到端交付能力的工程师。
- 能理解用户问题和产品目标
- 能基于产品取舍做技术决策
- 能完成从方案到上线的交付
- 能根据反馈评估效果并持续迭代
为什么
传统产品生命周期
先看一个常见产品生命周期。这里最重要的是问题和价值的配对：每个阶段解决什么问题，对应创造什么价值。
| 层级 | 阶段 | 关键问题 | 价值 |
|---|---|---|---|
| 业务 | 用户需求 | 哪个用户问题值得解决？ | - 发现真实问题 - 明确需求和痛点 |
| 业务 | 商业收入 | 这个产品为什么值得投入？ | - 判断收入潜力 - 评估利润、增长或战略意义 |
| 产品 | 方案定义和设计 | 用什么方案解决这个问题？ | - 定义产品方案 - 设计用户体验 - 对齐关键取舍 |
| 技术 | 技术规划 | 方案如何可靠落地？ | - 澄清需求 - 设计架构 - 制定实施计划 |
| 技术 | 实现 | 如何完成构建并交付给用户？ | - 把计划实现为软件 - 通过测试保障质量 |
| 决策 | 衡量和迭代 | 结果是否符合预期？ | - 验证真实效果 - 降低后续决策的不确定性 - 判断下一步产品或业务动作 |
再看这些阶段在组织中通常由哪些角色承担。
| 层级 | 解决的问题 | 价值 | 典型角色 |
|---|---|---|---|
| 战略方向 | 解决什么问题，为什么现在解决？ | 定方向、定成功标准、分配资源、做取舍 | 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 放大交付效率，也能把产品决策、技术交付和业务结果连起来。
招聘市场证据：
- 技能需求正在转向 AI 加人类判断。WEF’s Future of Jobs Report 2025 将 AI 和 big data 列为快速增长技能，同时强调 analytical thinking、creative thinking、leadership 和 collaboration。
- SWE 市场的技能结构正在变化。LinkedIn’s 2026 U.S. Software Engineer Talent Landscape 提到，新的 SWE 招聘更看重云平台和快速增长的 AI 相关工具。
- AI 需求不只属于 AI developer。PwC’s 2026 AI Jobs Barometer 显示 AI 相关角色和 AI user roles 的需求都在增长。
SDE 的新价值区和职业方向
新方向从哪里来
从产品生命周期看，SDE 值得投入的新方向，最好满足三个条件：
- 短期内 AI 做不好。
- 在产品生命周期里有明确位置。
- SDE 能用软件工程能力参与进去。
| 层级 | AI 短期难度 | 产品生命周期中的位置 | SDE 如何参与 |
|---|---|---|---|
| 战略方向 | 高：目标、业务上下文和责任边界不清晰 | 决定为什么做，以及什么结果最重要 | 支持调研、定义问题、评估价值 |
| 战术规划 | 中：结构化任务和复杂取舍混合 | 把方向拆成产品、技术和执行计划 | 拆解问题、明确约束、设计方案路径 |
| 执行 | 低：输入、输出和评价标准更清晰 | 把计划实现为软件，并拿到反馈 | 用 AI 加速编码、测试和迭代 |
新价值链是什么
这里有两条路径：
- 单层深度：继续在某一层加深，例如战略、规划、架构或执行。
- 跨层连接：把战略、规划和执行串起来，形成结果闭环。
我更推荐跨层连接。
单层深度仍然有价值，但每一层都会被 AI 改变。更值得关注的机会，是连接这些层级，把不清晰的目标拆成可执行、可验证、能借助 AI 提效的工作。
在常见互联网业务团队里，Product Engineering 是跨层连接的一条具体路径。
| 维度 | 业务团队 | 基础设施团队 |
|---|---|---|
| 领域 | 面向用户的产品和业务结果 | 内部平台、工具和工程系统 |
| 角色方向 | Product Engineer | Platform 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 把验证过的方向落成可运行的软件，并拿到可衡量的结果。
| 步骤 | 关键问题 | 方法 | 输出 |
|---|---|---|---|
| 架构 | 验证过的方向如何落到技术结构上？ | 架构设计、取舍评审 | 架构决策 |
| 构建 | 方案如何实现？ | 编码、代码评审、测试、持续交付 | 可运行的软件 |
| 衡量 | 方案是否达到预期？ | 指标追踪、用户行为观察 | 结果信号 |
| 迭代 | 下一步应该改变什么？ | 数据评审、反馈评审、小步迭代 | 下一个版本 |