2026年软件工程师与产品经理的角色重定位

软件工程师与产品经理的角色重定位

这一段时间我一直在spec coding，ai agent的高效输出远超我的认知带宽，而且在具备优秀Harness的前提，ai生成的代码质量已经超过我的水平。我的核心能力已经被ai agent超越，这是一次危机，危险中有机遇。 早上的地铁上，我忽然认识到一点：软件工程师和产品经理的价值链的重心正在发生一次系统性的位移。

先说一个框架

软件工程本质上是一条不断降低抽象层次的转译链：

碎片化语言 → 结构化自然语言 → 领域自然语言 → 代码 → 字节码/机器码 → 执行

这条链上的每一层，都是把上一层的意图「翻译」成下一层的语言。翻译方向是单向的，不可逆——你能从业务意图推导出代码，但无法从机器码里还原出用户的真实诉求。
这条链一直都在，不是什么新发明。新的事情是：AI 正在系统性地接管这条链的中下游，特别是「代码」这一层。而它还没能可靠接管的，是「领域自然语言」这一层。
这个位置的差异，决定了接下来几年里，哪些人的工作会发生根本性变化，哪些人的价值会被重新定价。

什么是「领域自然语言」

这个词不是业界通用术语，是我自己在用的概念，需要解释一下。
日常需求描述往往是这样的：「用户登录后要能看到自己的订单，要快，要安全。」这是碎片化语言——真实，但充满歧义。
产品经理整理后变成：「用户登录后，在订单中心展示近 90 天的订单列表，按创建时间倒序，支持按状态筛选。」这是结构化自然语言——清晰了很多，但对 AI 来说还是太模糊。
领域自然语言是这样的：

GET /api/v1/orders需满足：
① JWT Bearer Token 鉴权，scope=order:read；
② 查询范围限定当前用户，created_at ≥ now()-90d；
③ created_at DESC 排序；
④ cursor-based 分页，page_size ≤ 50；
⑤ P99 响应时间 < 300ms；
⑥ 禁止跨用户查询，越权返回 403 而非空列表。

同样的需求，三种截然不同的精确度。
领域自然语言比需求文档精确，比代码易读，是当前 LLM 可以相对可靠地转译为代码的最高抽象层次。它与业界已有概念的关系是：DDD 的通用语言（Ubiquitous Language）定义了词汇表，领域自然语言是用这套词汇写出的「可执行规格」；OpenAPI Spec 是它的形式化下游；BDD Gherkin 是它的一个子集，专注于行为描述，但领域自然语言覆盖更广，还包括性能约束、安全规范、数据模型设计。
我之所以不用「编译」来描述 AI 的转译过程，是因为编译是确定性的——同样的输入永远给出同样的输出，有明确的语义保证。LLM 是概率性推断，歧义会被以出乎意料的方式填补，没有任何保证。这个区别不是学术上的咬文嚼字，它直接决定了工程实践中你必须为 AI 的输出设计验证机制。

为什么「领域自然语言层」是关键战场

转译链的每一层都在被 AI 侵蚀，但速度差距很大。

代码这一层，AI 的进展是显著的。重复性的 CRUD、样板代码、单元测试生成、文档自动补全——这些任务 AI 今天就能可靠完成，而且还在快速变好。

最上面的几层——理解用户的真实诉求、在多方利益中做业务决策——高度依赖人类的情感感知和组织判断，AI 短期内难以主导。

领域自然语言层夹在中间，是两种压力的交汇点：它是 AI 能力的当前上限，也是人类可以投入产生最大杠杆的位置。

说得更直白一点：谁能精确生产领域自然语言，谁就掌握了驱动 AI Agent 的关键。这不是懂技术或懂业务其中之一的能力，而是两者必须同时具备。

产品经理：变化比你想象的更大

通常的说法是「AI 降低了 PM 的门槛，提升了效率」。我觉得这个说法太温和，甚至有点误导。

更准确的描述是：AI 在系统性地替代 PM 的工具性工作——文档生成、原型制作、竞品整理、数据报表——同时把判断性工作的门槛急剧拉高。结果不是所有 PM 都变轻松了，而是平庸的 PM 会被更快地暴露，优秀的 PM 的上限会大幅提升。

但更根本的变化在于工作界面。PM 的右边，原来是负责实现的工程师，未来会逐步变成 AI Agent。这不只是「换了个工具」——它改变了 PM 的产出物的形态。

写给工程师看的 PRD，可以模糊，靠沟通消歧义，结构服务于可读性，假设读者有背景知识。写给 AI Agent 执行的规范，必须精确，因为任何歧义都会被 AI 以出乎意料的方式填补，而 Agent 不会主动来问你「你的意思是……吗」。

这是一次工作本质的变化，不是效率的提升。

这种设计「给 AI 执行的规范」的能力就是热火朝天的Harness Engineering——一门设计环境、约束条件与反馈循环的工程学科，目标是让 AI Agent 在生产环境中可靠地大规模运行。它和 Prompt Engineering 的区别在于：Prompt Engineering 是单次对话的优化技巧；Harness Engineering 是系统性的工程设计，涵盖上下文注入策略、输出校验机制、失败降级路径，以及将领域规范嵌入 Agent 工作流的方法论。

对未来的 PM 来说，Harness Engineering 不是加分项，是基本功。

开发工程师：左移是方向，但左移有边界

「工程师需要转型成产品经理」——这个说法方向没错，但太笼统，会把人带进坑里。

更精确的说法是：工程师需要向领域自然语言层移动，在那里建立自己的价值定位。但怎么移，取决于每个人的积累和方向。

有人适合往产品侧走，成为技术型 PM——技术背景让他们能直接评估 AI Agent 的实现可行性，同时承担规范生产者和技术约束设计者两个角色。

有人适合深耕垂直领域——金融、医疗、工业、法律。这些领域有大量「业内人都知道但从未被文档化」的隐性规则，AI 最难快速获取的就是这种深度领域知识。领域专家的价值，在于能把这些隐性规则显性化，转化为 AI 可执行的规范。

有人适合走架构方向——在 AI 时代，架构师的工作多了一层：不只是设计系统，还要设计 AI Agent 可以安全操作的系统边界，定义 Agent 能做什么、不能做什么、失败时如何降级。架构设计的复杂性没有降低，只是换了形态。

还有一条新兴路径值得关注：专门做 Harness Engineering 的工程师——设计 AI Agent 的工作流、约束注入机制、输出验证体系、多 Agent 编排系统。这是把软件工程方法论应用于 AI Agent 治理的交叉领域，目前竞争者极少，需求在快速增长。

这四条路有一个共同前提：必须理解领域自然语言层，并能在这一层产出价值。只会写代码而不理解业务约束的工程师，会是第一批被替代的群体。

关于 AI Agent 的能力

网上有很多「AI 代码生成准确率 90%」之类的说法。我不打算重复这些数字，因为它们高度依赖任务类型、上下文质量、领域复杂度，脱离场景的准确率数字是误导性的。

我更想说的是几个 AI 的典型失败模式，因为这些直接影响 Harness Engineering 的设计：

歧义填补是最常见的坑。规范里有歧义时，AI 不会停下来问你，它会做出一个看似合理但实际可能完全错误的假设，然后一路生成下去。你不仔细 review，不会发现。

上下文截断在大型代码库里很明显。早期你告诉 Agent 的约束——某个接口的权限设计、某个字段的业务含义——在长对话后可能已经被遗忘了，Agent 开始用自己的「常识」填补。

过度自信是信任风险。AI 在不确定时不会表达不确定性，它会给出看起来权威的回答。这比直接出错更危险，因为你更难发现。

跨组件盲点在系统集成时频繁出现。对单个组件的理解可以很准确，但组件间的交互约束、数据一致性要求、事件顺序依赖，这些 AI 目前处理得很弱。

这四个失败模式都指向同一个结论：领域自然语言层的规范越精确，这些问题出现的概率越低。这也是为什么我说这一层的人类把控不可省略。

我不能确定的事

我的整个框架建立在一个假设上——领域自然语言层是 AI 当前能力的上限，需要人类显式生产。
如果 LLM 的推理能力继续快速提升，它可能会在未来几年内「跳过」这一层，直接从模糊的需求描述生成可靠的代码。如果这发生了，这篇文章的核心框架需要根本性的修正。
我目前认为这在近期不会发生，因为歧义消解本质上需要的是领域知识和商业判断，而不只是更大的模型。但我承认我可能是错的。另一个不确定性是企业数据安全合规的影响。很多公司的核心业务逻辑不可能喂给外部 LLM，这会显著延长过渡期，也会在不同行业造成完全不同的演进节奏。

最后

软件工程正在经历的，不是替代，而是抽象层次的重心上移。

代码正在成为 AI 的领地。我觉得这本质上是一件好事——它让我们可以把精力集中在 AI 目前无法可靠完成的地方：读懂真实的人类诉求，在不确定中做商业决策，在复杂的组织约束中设计合理的系统边界。

领域自然语言层，是这场迁移里人类价值最集中的地方。

对 PM 来说，核心工作会从「写给人读的文档」变成「写给 AI 执行的规范」，这需要领域建模能力和 Harness Engineering。

对工程师来说，转型不是「变成 PM」，而是找到自己在领域自然语言层的定位——无论是技术型 PM、领域专家、架构师，还是 Harness Engineering 专家。

拥抱这次迁移，意味着主动放弃正在被 AI 接管的工作，把注意力转向 AI 仍然需要人类判断的地方。

这需要判断力，也需要不小的勇气。