编程 Agent 时代工程师角色的重新定位

软件公司的 EPD（工程、产品、设计）存在的意义，就是做出好软件。虽然分属不同角色，但最终目标是一致的：做出能够解决业务问题、真正为用户所用的功能软件。说到底，产出就是代码。必须认清这一点——因为编程 Agent 突然让写代码变得异常简单。那么，EPD 的角色定位将如何变化？

每个人都觉得自己的角色从编程 Agent 中受益最大——而且都没说错

PRD（产品需求文档）曾是 Claude 时代之前软件开发的核心枢纽。EPD 的流程大致如下：

这并非铁律。在初创公司，这些步骤往往混在一起，能力最强的人可以同时做好几件事。但这就是教科书式的标准做法。

之所以需要这套流程，是因为编写软件和制作设计稿都需要投入大量时间与精力。于是，专门的角色分工应运而生。分工越细，跨部门沟通的需求就越大。PRD 是一切的起点，将整个流程串联起来。接力棒传到设计师手中，把文字变成漂亮的 UI 和流畅的交互体验；最后再由工程师将这些变为现实。

编程 Agent 颠覆了这一切。编程 Agent 可以把一个想法直接变成能够运行的软件。当我以及很多人说“PRD 已死”时，真正的意思是：这种从编写 PRD 开始的传统软件开发方式已经终结。

如今，任何人都能写代码，也就意味着任何人都能把东西做出来。但这并不代表做出来的东西架构合理、解决了正确的问题，或者足够好用。工程、产品和设计应该成为这些方面的评审者与把关人。问题在于，Agent 生成的代码并不总是“足够好”。EPD 的工作变成了评审，确保代码“足够好”。这里的“足够好”包含几层含义：

• 从工程系统角度看，架构是否合理：代码是否可扩展、高性能且足够健壮？
• 从产品角度看，思考是否到位：它真的解决了用户的痛点吗？
• 从设计角度看，产品是否好用：界面是否易用、直观？

初版代码的生成成本极低，大量原型随之涌现。这些原型成为大家讨论和评审的中心，产品、工程和设计都围绕它们展开工作。

问题在于——生成代码实在太容易了。过去，编写代码需要很长时间，因此作为评审者，手上需要评审的项目不会太多。但现在任何人都能写代码，在做的项目数量急剧增加。三个职能的瓶颈全都转移到了评审环节——拿到原型后，确保它们足够好。

Claude 之前的软件开发方式，也就是从 PRD 开始的流程，已经成为过去。但描述产品需求的文档依然不可或缺。

假设有人想到一个点子，并迅速做出了原型。接下来该如何上线？这需要 EPD 的其他成员参与评审。在这个过程中，一份文字说明总是有帮助的，而且往往必不可少。其他人在评审时，怎么知道代码中的某个地方是有意为之，还是偶然写成的？他们需要了解背后的意图。总得有一种方式，把意图清楚地传达出来。

我认为，传统的 PRD 流程——PRD → 设计稿 → 代码——已经死了。但描述产品需求的文字本身依然活得很好。在交付评审之前，这份文档应该成为原型的必备搭档。

最标准的形式仍然是一份文档，但也有一些很有意思的想法——例如，把生成功能时使用的 prompt 分享出来，作为一种沟通方式。如果未来的 PRD，就是结构化且带有版本管理的 prompt 呢？

这里所说的通才，是指在产品、工程和设计三个方面都具备良好感觉的人。这些人一直都很有价值、很有影响力——但有了编程 Agent，他们变得更加如鱼得水。为什么？

沟通是所有事情中最困难的部分，它会拖慢一切。如果一个人能够同时搞定产品、设计和工程，那么他会比一个三人团队更快，因为省去了沟通开销。

过去，实现本身是瓶颈，通才也必须与别人沟通，才能把事情做完。现在，他们只需要与 Agent 沟通。这意味着，一个人单打独斗所能产生的影响力，比以往任何时候都更大。

编程 Agent 让实现成本变得极低，使用它们已经成为必选项。能够用好编程 Agent 的人，可以独自完成更多事情：

• 产品经理可以直接制作原型、验证想法，不必先写需求文档，然后干等。
• 设计师可以直接在代码中迭代，而不只是在 Figma 里画图。

使用编程 Agent 是必选项，因为它并不难上手；如果你不用，就会被会用它的人替代。

好的产品思维比以往更有价值——它能让你做出真正有用的东西。差的产品思维也比以往造成更多浪费。如果某个人有一个糟糕的产品想法，他可以直接带着一个原型出现——但这个原型展示的，可能是一个毫无用处或者根本没想清楚的功能。

现在，这些原型需要更多人参与评审——工程、产品和设计都得看。这会吞噬大量时间与资源。而且，推动它们上线的惯性也变得更大了：“东西都已经做出来了！直接合并吧！”产品很可能因此变得更差、更臃肿。

在一个执行成本极低的世界里，系统思维成为了真正的差异化能力。你应该专注于磨练自己的系统思维，为所在领域建立清晰的心智模型：

• 工程：对如何设计服务架构、API 和数据库建立清晰的心智模型。
• 产品：对用户真正需要什么，而不是他们嘴上说想要什么，建立清晰的心智模型。
• 设计：对为什么某个东西用起来、看起来、感觉起来就是对的，建立清晰的心智模型。

系统思维一直都很重要——那么，变化究竟在哪里？

变化在于，实现成本大幅下降了。做出东西比以往更加容易，但这并不意味着做出来的东西就是好的。优秀的系统思维能够让你在动手之前确认方向正确，也能让你在评审他人的工作时更有判断力。这两方面都说明，系统思维的重要性进一步提升了。

编程 Agent 仍然需要有人向它下达指令，告诉它该做什么。如果你让它做了错误的东西——你就是在给别人制造更多有待评审的垃圾。知道应该让 Agent 做什么，也就是具备“产品意识”，已经成为一项基本要求。否则，你会拖累整个组织。这一点对工程、设计以及显然对产品都同样适用。

如今，EPD 有很大一部分工作是在评审原型。具备产品意识，会让评审变得更加容易，即便评审的是设计或工程方面的内容。没有产品意识，就需要一份极其详细的产品文档来配合原型；具备产品意识，只需要一份简要说明，就能理解功能背后的意图，从而加速沟通、评审与交付。

你需要会使用编程 Agent，也需要具备产品意识。所有角色都在融合。

不同角色之间一直存在重叠。设计和产品向来紧密相连——在 Apple 和 Airbnb 这样的公司里，设计师本身就兼任产品经理。“设计工程师”（Design Engineer，即兼具设计与工程能力的角色）在 Vercel 等公司也越来越流行。

但专业化依然有其存在的空间。一位专注于系统架构的资深工程师，仍然非常有价值。一位没有学习凭感觉编程（Vibe Coding），但对客户问题以及应该做什么拥有极其清晰心智模型的 PM，同样很有价值。能够理解并设计用户旅程与交互的设计师也是如此，即使他仍然在 Figma 中工作。

只不过，专业化的门槛已经高得多了。你不仅要在自己的领域出类拔萃，还要拥有极快的评审速度和极强的沟通能力。而且，这类角色在任何公司里都不会太多。

第一类：建设者。这类人拥有不错的产品思维，能够使用编程 Agent，并具备基本的设计直觉。有了护栏——例如测试套件和组件库——他们可以把小功能从想法一路做到上线，也可以为大型功能制作出可用的原型。

第二类：评审者。对于大型、复杂的功能，需要从 EPD 层面进行深度评审。成为评审者的门槛很高——你必须是自己所在领域中顶尖的系统思考者。而且你必须足够快，因为需要评审的东西实在太多了。

如果你现在是一名工程师——要么把系统设计能力磨练到极致，能够从容地评审架构，朝评审者的方向发展；要么提升自己的产品与设计能力，成为建设者。

如果你从事产品或设计——要么建立顶级的产品或设计心智模型，主要承担评审工作；要么投入编程 Agent，提升自己的编程功底。

有意思的是，角色正在坍缩。从上面的图中可以看到，所有 EPD 从业者都分布在这张图的某个位置。不同角色开始融合——工程师拥有了更多时间，可以更多地思考产品与设计；产品和设计人员也能够编写代码了。

每个人都觉得自己的角色从编程 Agent 中受益最大——而且都没说错

Twitter 上有一条很好的帖子，讨论了什么样的人能从编程 Agent 中受益最大：

一个对现有产品有着直觉般理解的人——知道哪里是短板、哪里是亮点，以及如何通过迭代让产品变得更加锋利。

这种人最稀有的形态，站在文化与深度技术的交叉点上。他们是真正的“双语者”：既知道技术上什么是可能的，也能分辨哪些文化潮流是真实的，而不是昙花一现。正是这种组合，决定了一个产品让人感觉是“理应如此”，还是“拼凑而成”。

这条帖子精准地概括了这个新世界，因此引发了广泛传播。它之所以能够传开，部分原因在于，每个读到它的人都觉得帖子描述的正是自己，或者自己所扮演的角色。我看到产品人在转发，设计师在转发，设计工程师在转发，创始人也在转发……每个人都觉得它说的就是自己。

而他们很可能都没有说错！

我认为，这个新世界令人兴奋的一点在于，一个人的出身背景不再那么重要。我真心相信，这样的人可以来自产品、设计或工程中的任何一个方向。但这并不意味着每个人都能成为这样的人——说起来容易，做起来却很难。真正的全才少之又少。