内容
软件公司的 EPD（工程、产品和设计）部门致力于打造优质软件。虽然存在不同的角色分工，但最终目标是开发出功能完备的软件，以解决业务问题并供用户使用。归根结底，这一切都离不开代码。认识到 EPD 部门作为一个职能团队所产出的成果仅仅是代码，这一点至关重要，因为…… 编码代理突然让代码编写变得极为容易。那么，这会如何改变 EPD 的角色呢？
变化的过程
- PRD 已死
- 瓶颈从实施转移到审查
- PRD 万岁
对角色的影响
- 通才比以往任何时候都更有价值
- 编码代理是必需的
- 好的产品经理很棒，坏的产品经理很糟糕
- 每个人都需要产品意识
- 专业化的门槛更高
- 你要么是建设者，要么是审查者
- 每个人都认为自己的角色因编码代理而最受益——他们是对的
PRD 已死
PRD（产品需求文档）曾是构建软件的焦点。在 Claude 前时代，EPD 流程大致如下：
- 某人（通常是产品）有一个想法
- 产品编写 PRD
- 设计根据 PRD 创建模型
- 工程将模型转化为代码
这并不是一个硬性规定（在初创公司中，这些步骤会混合在一起，最好的建设者可以同时完成多个步骤），但这是教科书式的建设方式。
这是必要的，因为构建软件（和模型）需要大量的时间和精力。因此，各个学科应运而生，专门从事这些工作。随着人们越来越专业化，跨学科的沟通需求也随之增加。PRD 是这一过程的基础，它启动了整个流程。然后，设计会将其转化为漂亮的 UI 和流畅的 UX。工程则使其变为现实。
编码代理改变了这一切。编码代理可以从一个想法中创建功能性软件。当我（和其他人）说“PRD 已死”时，我们真正的意思是，从编写 PRD 开始的传统软件构建方式已经死了。
瓶颈从实施转移到审查
现在，任何人都可以编写代码，这意味着任何人都可以构建东西。但这并不意味着构建的东西架构良好，解决了正确的问题，或易于使用。工程、产品和设计应该是对这些领域进行审查和仲裁的人。问题在于，生成的代码并不总是“优秀”的。EPD 的角色变成了审查并确保它是“优秀”的。“优秀”可以意味着很多事情：
- 从工程系统角度来看，架构是否合理：是否以可扩展、高性能和稳健的方式编写？
- 从产品角度来看，是否考虑周全：是否解决了用户的痛点？
- 是否设计良好：界面是否易用且直观？
由于创建代码的初始版本的成本非常低，我们看到创建了很多原型。这些原型然后作为焦点，产品、工程和设计对其进行审查。
问题在于 - 生成代码非常容易。以前，需要一段时间才能创建代码 - 因此，作为审查者，在任何时候都只有那么多项目需要审查。现在，任何人都可以编写代码。这意味着正在进行的项目数量正在增加。我们看到瓶颈（在所有三个功能中）是审查 - 采取原型并确保它们是“优秀”的。
PRD 万岁
构建软件的 Claude 前时代（从 PRD 开始）已经过去。但描述产品需求的文档仍然必不可少。
假设有人有一个想法，并迅速建立了一个原型。它如何进入生产？它需要由 EPD 的其他成员审查。在此过程中，书面文档始终有助于审查。通常，文档是必不可少的。当他人审查时，他们如何知道代码的某些部分是故意还是无意？取决于意图。需要某种形式的沟通来表达这种意图。
我认为传统的 PRD 流程（PRD → 模型 → 代码）已经死了。但描述产品需求的文本仍然非常重要。这种相关的文档应该是在将原型交付审查之前必不可少的配套文档。
最标准的格式将是一份文档，但有一些关于共享用于创建此功能的提示的有趣想法。如果未来的 PRD 只是结构化、版本控制的提示呢？
通才比以往任何时候都更有价值
这里的通才指的是对产品、工程和设计都有深刻理解的人。这些人一直很有价值和影响力 - 但有了编码代理，他们更是如此。为什么？
沟通是所有事情中最难的部分。它会减慢速度。一个可以同时胜任产品、设计和工程工作的人，由于沟通的复杂性，会比三个人组成的团队行动更快。
以前，当实施是瓶颈时，这个通才仍然需要与其他人沟通才能完成工作。现在，他们可以直接与代理人沟通。这意味着他们可以比以往任何时候都更独立地、更有影响力地工作。
编码代理是必需的
有了编码代理，实施变得很便宜，使用它们是必需的。可以采用编码代理的人将能够独立完成更多工作：
- 采用编码代理的产品经理可以直接构建原型，而无需编写规格并等待
- 采用编码代理的设计师可以在代码中迭代，而不仅仅是在 Figma 中
- 采用编码代理的工程师可以将时间从实施转移到系统思考
采用编码代理是必需的，因为这样做并不难，如果你不这样做，你就会被别人取代。
好的产品经理很棒，坏的产品经理很糟糕
好的产品思维比以往任何时候都更有价值 - 你可以构建有用的东西。坏的产品思维比以往任何时候都更浪费。如果你有一个坏的产品想法，你可以带着原型出现 - 但那个原型将是一个无用或构思不良的功能。这些原型现在需要更多的审查 - 来自工程、产品和设计。这会消耗时间和资源。并且将这些原型投入生产的惯性更大（“它已经存在了！让我们直接合并吧！”）。这可能会导致产品变差或臃肿。
系统思维是需要磨练的技能
在一个执行很便宜的世界里，系统思维成为区分因素。你应该专注于系统思维，并对特定领域有清晰的心理模型：
- 工程：对如何构建服务、API 和数据库有很好的心理模型
- 产品：对用户真正需要什么有很好的心理模型，而不是他们想要什么
- 设计：对为什么某件事情看起来和使用起来很直观有很好的心理模型
系统思维一直很重要 - 那么有什么变化？实施的成本大幅降低。这意味着实施某件事情比以往任何时候都更容易 - 但这并不意味着它很优秀。成为一个好的系统思考者可以让你确保一开始就构建正确的事情。它也可以让你在事后审查别人的工作。两者都意味着，作为一个好的系统思考者的重要性增加了。
每个人都需要产品意识
编码代理仍然需要有人来提示他们。有人需要告诉他们该做什么。如果你让他们构建错误的东西 - 你会为他人创造更多的负担来进行审查。知道如何提示代理构建什么（“产品意识”）是一个要求，否则你将成为组织的负担。这在工程、设计和（显然）产品领域都是如此。
EPD 的一个重要部分是现在审查原型。如果有产品意识，审查会更容易，即使是审查设计/工程。如果你没有产品意识，你需要一个详细的规格文档来配套原型。如果你有产品意识，你可以用最小的规格文档来理解功能的意图，从而加快沟通、审查和交付。
专业化的门槛更高
你需要知道如何使用编码代理。你需要有产品意识。所有角色都在融合。
角色之间一直存在重叠。设计和产品一直密切相关 - 在某些公司，如苹果和 Airbnb，设计师担任产品经理。“设计工程师”作为一种角色，在 Vercel 等公司中逐渐流行起来。
这并不意味着没有专业化的空间。一个只关注系统架构的高级工程师仍然很有价值。一个没有掌握编码但对客户问题和需要构建的内容有清晰的心理模型的产品经理也是如此。一个可以理解和模拟用户旅程和交互的设计师，即使仍然在 Figma 中，也是如此。
这并不意味着专业化没有空间。 一名只关注系统架构的高级工程师仍然很有价值。 产品经理（PM）如果没有涉及编码，但对客户的问题和产品需求有清晰的认知，同样宝贵。 设计师如果能理解和模拟用户旅程和交互，即使仍在使用 Figma，也依然有价值。
但是，专业化的门槛更高。 你不仅要在专业领域出类拔萃，还要具备极快的评审速度和出色的沟通能力。 而且，在任何一家公司中，这样的角色可能都寥寥无几。
你要么是建设者，要么是评审者
我们在 EPD 中看到两种不同的角色正在出现。
首先，是建设者。 这种类型的人具有良好的产品思维，能够使用代码代理，并具备基本的 设计直觉。 在一定的约束下（例如测试套件、组件库），他们可以将小功能从想法变为产品，并可以制作较大功能的原型。
其次，是评审者。 对于大型和复杂的特性，需要进行详细的 EPD 评审。 这方面的门槛很高 - 你必须在专业领域内具有出色的系统思维能力。 同时，你还要能够快速工作 - 因为需要评审的内容很多。
如果你是一名工程师 - 你应该努力在系统设计方面出类拔萃，并熟悉评审架构，以成为评审者... 或者尝试提高你的产品/设计技能，成为建设者。
如果你在产品或设计领域 - 你要么需要对产品/设计有出色的认知，并主要负责评审，或者开始使用代码代理，并提高你的编码能力。
https://x.com/hwchase17/article/2031051115169808685/media/2031050345888288768?ref=blog.langchain.com
有趣的是，角色正在某种程度上融合，如上图所示，EPD 中的所有角色都位于图表上的某个位置。 角色可以开始融合 - 工程师有更多时间，可以更多地思考产品和设计。 产品和设计人员可以编写代码。
每个人都认为自己的角色最能从代码代理中受益 - 而且他们是对的
Twitter 上有一篇优秀的帖子，讨论了最能从代码代理中受益的人群：
那些对现有产品有直觉的人，他们知道产品的优缺点，以及如何迭代产品，使其变得更好。
这种人的稀有版本处于文化和深度技术的交叉点。 他们真正具备双语能力。 他们知道什么在技术上是可行的，并且知道哪些文化趋势是真实的，哪些是短暂的。 这种组合使产品感觉是必然的，而不是组装而成的。
这篇帖子很好地概括了这个新世界，并且它几乎走红了。 部分原因在于，每个人读到它时都认为它是在谈论自己或自己的角色。 我看到产品人员引用它，设计师、设计工程师、创始人... 每个人都认为它适用于自己和自己的角色。
而且他们可能都是对的！ 我认为，在这个新世界中，背景变得不那么重要了。 我真的相信，这种类型的人可以来自产品、设计或工程领域。 这并不意味着每个人都会成为这种人 - 说起来容易做起来难。 这样的真正人才寥寥无几。
现在是建设的激动人心的时刻 :)