在软件公司里，EPD（工程、产品和设计）是关于创造优秀的软件。虽然角色是分开的，但最终目标是做出能够解决业务问题、用户可以使用的功能性软件。归根结底，这其实只是代码。必须认识到，EPD 这个职能产出的本质就是代码，因为……编码代理突然让写代码变得非常容易。那么，这会如何改变 EPD 的角色？

变化中的流程：

PRD 已死

瓶颈从实现转向评审

PRD 万岁

对角色的影响：

通才比以往任何时候都更有价值

编码代理成为必需品

好的 PM 很出色，差的 PM 很糟糕

每个人都需要产品感

专业化的门槛更高了

你要么是构建者，要么是评审者

每个人都觉得自己的角色最能从编码代理中受益——而他们说得没错

PRD 已死

在 Claude 出现之前的时代，PRD（产品需求文档，Product Requirement Documents）是软件开发的核心。EPD 流程大致是：

某个人（通常是产品）有了一个想法

产品写一份 PRD

设计根据 PRD 做出一个原型稿

工程把原型变成代码

这并不是一成不变的规则（在初创公司里这些步骤往往会混在一起，最优秀的构建者往往能同时做其中好几件事），但这是教科书式的构建方式。

之所以需要这样做，是因为构建软件（以及制作原型）需要投入大量时间和精力。因此人们建立了不同的职能来专门负责这些工作。随着人越来越专业化，也就需要在这些职能之间进行沟通。PRD 就是这种沟通的基础，并由此启动整个流程。然后流程会像瀑布一样流向设计，设计把漂亮的文字变成漂亮的 UI 和流畅的 UX。接着工程再把它真正实现出来。

编码代理改变了这一切。编码代理可以把一个想法直接变成功能性的软件。当我（以及其他人）说“PRD 已死”时，我们真正的意思是：这种从撰写 PRD 开始的传统软件开发方式已经过时了。

瓶颈从实现转移到了评审

现在任何人都可以写代码，这意味着任何人都可以构建东西。但这并不意味着做出来的东西架构良好、解决的是正确的问题、或者足够易用。工程、产品和设计应该成为这些方面的评审者和裁决者。问题在于，生成出来的代码并不总是“很棒”。EPD 的角色变成了去评审并确保它是“很棒”的。“很棒”可以有多种含义：

从工程系统的角度来看架构是否良好：代码是否以可扩展、高性能、稳健的方式编写？

从产品角度是否经过深思熟虑：它是否解决了用户的痛点？

设计是否良好：界面是否易用且直观？

由于创建某个代码初始版本的成本非常低，我们看到越来越多的原型被创建。这些原型随后成为一个焦点，由产品、工程和设计团队一起进行评审。

问题在于——生成代码太容易了。过去，编写代码需要花一些时间，所以作为评审者，在任何时候摆到你桌面上需要评审的项目数量是有限的。但现在——任何人都可以写代码。这意味着正在进行的项目数量在增加。我们看到的瓶颈（在这三个职能中）变成了评审——拿到这些原型并确保它们是“好的”。

PRD万岁

从PRD开始构建软件的“前Claude时代”已经过去。但描述产品需求的文档仍然至关重要。

假设有人有一个想法并迅速做出了一个原型。它如何进入生产环境？它需要由EPD的其他成员进行评审。在这个过程中，一份书面文档总是有帮助，而且往往是必不可少的。当其他人进行评审时，他们怎么知道代码中的某一部分是偶然存在的还是有意为之？这取决于意图。因此需要某种方式来传达这种意图。

我认为传统的PRD流程（PRD → 原型图 → 代码）已经死了。但描述产品需求的文本仍然非常有生命力。在将原型交付评审之前，这份相关文档应该成为其必备的配套说明。

最常见的形式会是一份文档，但也有一些有趣的想法，比如共享用于创建这个功能的提示词（prompts），把它作为沟通方式。如果未来的PRD只是结构化、可版本化的提示词，会怎样？

通才比以往任何时候都更有价值

这里所说的通才，是指对产品、工程和设计三方面都有良好理解的人。这类人一直都很有价值、影响力也很大——但在有了编码代理之后更是如此。为什么？

沟通是所有事情中最难的部分。它会拖慢进度。一个能够完成产品、设计和工程所有工作的个人，比一个由三个人组成的团队要走得更快，因为沟通的开销。

之前，当实施是瓶颈时，这位通才仍然需要与他人沟通才能完成工作。现在，他们只需要与代理沟通。这意味着他们仅凭自己就能比以往更具影响力。

编码代理是必需的

由于编码代理使得实施变得便宜，使用它们是必须的。能够使用编码代理的人将能够自己完成更多的工作：

采用编码代理的PM可以通过直接构建原型来验证想法，而无需编写规格说明并等待。

采用编码代理的设计师可以在代码中进行迭代，而不仅仅是在Figma中。

采用编码代理的工程师可以将时间从实施转移到系统思考上。

采用编码代理是必须的，因为这并不难，如果你不这么做，你会被那些做的人取代。

优秀的PM很棒，差的PM很糟糕。

好的产品思维比以往任何时候都更有价值——你可以构建有用的东西。差的产品思维比以往任何时候都更浪费。如果有人有一个糟糕的产品想法，他们可以拿着原型出现——但那个原型将是一个无用或构思不周的功能。这些原型现在需要更多的审查——来自工程、产品和设计。这消耗了时间和资源。要将这些原型投入生产也需要更多的惯性（“它已经存在了！我们直接合并吧！”）。这有可能导致产品变得更糟或臃肿。

系统思考是需要磨练的技能

在执行成本便宜的世界中，系统思考成为了区分者。你应该专注于成为一名擅长系统思考的人，并且对你所在领域有清晰的思维模型：

工程：非常好的思维模型，帮助架构服务、API 和数据库。

产品：非常好的思维模型，帮助了解用户实际需要的东西，而不是他们说想要的。

设计：非常好的思维模型，帮助理解为什么某个东西看起来和使用起来是合适的。

系统思维一直都很重要——那么，是什么改变了呢？实施的成本大大降低了。这意味着实现某些东西比以往任何时候都更容易——但这并不意味着它就一定很棒。成为一个优秀的系统思考者，能够确保你一开始就构建正确的东西。它还可以让你在事后审查他人的工作。这两者都意味着，成为一个优秀的系统思考者的重要性已经增加。

每个人都需要产品感觉。

编码代理仍然需要有人来引导他们，需要有人告诉他们该做什么。如果你告诉他们去构建错误的东西——你是在为别人制造更多需要审查的杂乱。知道该告诉代理构建什么（“产品感觉”）是必备的，否则你会成为组织的拖累。这对于工程、设计和（显然）产品都是适用的。

EPD 的一个重要部分现在是审查原型。如果你有产品感觉，审查设计/工程时会更容易。如果你没有产品感觉，你需要一份非常详细的产品文档与原型一起使用。如果你有产品感觉，你能通过最简洁的规格理解功能的意图，从而加速沟通、审查和交付。

专业化的门槛更高了。

你需要知道如何使用编码代理。你需要产品感觉。所有角色之间的界限正在模糊。

角色之间一直有重叠。设计和产品长期以来一直是紧密相关的——在一些公司，比如苹果和AirBnb，设计师担任产品经理。像 Vercel 这样的公司，‘设计工程师’这一角色越来越受欢迎。

这并不意味着没有专业化的空间。一位非常资深的工程师，如果只关注系统架构，依然是有价值的。同样，一个没有学会编码，但对客户问题和该构建什么有非常清晰的思维模型的 PM 也是有价值的。一个能够理解并模拟用户旅程和交互的设计师也是如此，即便他/她仍然使用 Figma。

但专业化的门槛确实更高了。你不仅要在自己的领域非常出色，还要在审查和沟通方面非常快速和出色。而且在任何公司，可能没有那么多这样的角色。

你要么是构建者，要么是评审者

我们看到在 EPD 中正在出现两种不同类型的角色。

第一种：构建者。这类人具备良好的产品思维，能够使用编码代理，并且拥有基础的设计直觉。在有护栏的情况下（测试套件、组件库），他们可以把小功能从想法带到生产环境，也可以为更大的功能做出可运行的原型。

第二种：评审者。对于大型且复杂的功能，需要进行细致的 EPD 评审。这个门槛很高——你必须在自己的领域里是出色的系统思考者。同时你还必须工作节奏很快——需要评审的内容很多。

如果你现在是一名工程师——你要么应该努力在系统设计方面变得非常出色，并且能够自如地评审架构，目标成为一名评审者……要么尝试提升你的产品/设计能力，成为一名构建者。

如果你在做产品或设计——你要么必须对产品/设计有非常出色的心智模型，并主要承担评审工作；要么就要开始使用编码代理并提升你的编程能力。

有意思的是，角色正在某种程度上开始融合，这一点从整个 EPD 都分布在上面的图表中可以看出来。角色开始相互交融——工程师有了更多时间，可以更多地思考产品和设计；而产品和设计人员也可以编写代码。

每个人都觉得自己的角色最能从编码代理中受益——而他们其实都没错。

Twitter 上有一篇很棒的帖子，讲的是哪类人最能从编码代理中受益：

那种对现有产品有直觉式理解的人——知道哪里还不够好，哪里真正出彩，以及如何把它不断迭代打磨得更加锋利。

这种人最稀有的版本，是站在文化与深度技术交汇点的人。某种真正的“双语者”。他们既知道技术上什么是可能的，也知道哪些文化潮流是真实的、哪些只是昙花一现。正是这种组合，让产品看起来像是必然出现的，而不是被拼装出来的。

这篇帖子很好地概括了这个新世界，并且在一定程度上走红了。它之所以传播开来，其中一个原因是：每个读到它的人都觉得它是在说自己或自己的角色。我看到做产品的人在引用它、设计师在引用、设计工程师、创始人……每个人都觉得它适用于自己和自己的角色。

而且他们可能都说对了！我觉得这个新世界最伟大、最令人兴奋的一点是：背景变得没那么重要了。我真心相信，这种类型的人可能来自产品、设计或工程领域。这并不意味着每个人都能成为这样的人——说起来容易，做起来难。真正的“独角兽”其实非常少。

这是一个令人兴奋的建设与创造的时代 :)