软件公司的 EPD（工程、产品、设计）存在的意义就是做出好软件。虽然分了不同角色，但最终目标一样：做出能解决业务问题、用户用得上的功能软件。说到底，产出就是代码。这一点必须认清——因为编程 Agent 突然让写代码变得异常简单。那么，EPD 的角色定位会怎么变？
流程的变化：
PRD 已死
瓶颈从实现转向评审
PRD 万岁
对角色的影响：
通才比以往更有价值
使用编程 Agent 是必选项
好的 PM 更好，差的 PM 更差
每个人都需要产品意识
专业化的门槛更高了
你要么是建设者，要么是评审者
每个人都觉得自己的角色从编程 Agent 中受益最大——而且都没说错
PRD 已死
PRD（产品需求文档）曾是 Claude 时代之前软件开发的核心枢纽。EPD 的流程大致是这样的：
有人（通常是产品经理）冒出一个想法
产品经理写一份 PRD
设计师拿着 PRD 做出设计稿
工程师把设计稿变成代码
这并不是铁律（在初创公司，这些步骤往往混在一起，最强的人能同时做好几件事），但这就是教科书式的标准做法。
之所以需要这套流程，是因为写软件（和做设计稿）要花大量时间和精力。于是就有了专门的分工。分工越细，跨部门沟通的需求就越大。PRD 就是一切的起点，把整个流程串了起来。接力棒传到设计，把文字变成漂亮的 UI 和流畅的交互体验。最后工程师把这些变成现实。
编程 Agent 颠覆了这一切。编程 Agent 能把一个想法直接变成可运行的软件。当我（以及很多人）说"PRD 已死"时，真正的意思是：这种从写 PRD 开始的传统软件开发方式，终结了。
瓶颈从实现转向评审
现在谁都能写代码，意味着谁都能把东西做出来。但这不代表做出来的东西架构合理、解决了正确的问题、或者好用。工程、产品和设计应该成为这些方面的评审者和把关人。问题在于，Agent 生成的代码并不总是"足够好"。EPD 要做的事变成了评审，确保代码"足够好"。这里的"足够好"有几层含义：
从工程系统角度看架构是否合理：代码是否可扩展、高性能、足够健壮？
从产品角度看思考是否到位：这真的解决了用户的痛点吗？
从设计角度看是否好用：界面是否易用、直观？
初版代码的生成成本极低，大量原型涌现出来。这些原型成了大家讨论评审的中心，产品、工程和设计都围着它们转。
问题是——生成代码实在太容易了。过去写代码需要很长时间，作为评审者，手上需要看的项目不会太多。但现在谁都能写代码，在做的项目数量急剧增加。所有三个职能的瓶颈都转移到了评审——拿到原型后确保它们够好。
PRD 万岁
Claude 之前的软件开发方式（从 PRD 开始）已经成为过去。但描述产品需求的文档依然不可或缺。
假设有人想到一个点子，快速做出了原型。接下来怎么上线？需要 EPD 其他成员来评审。在这个过程中，一份文字说明总是有帮助的，而且往往必不可少。其他人评审时，怎么知道代码里某个地方是有意为之还是偶然写成的？得看意图。总得有办法把意图传达清楚。
我认为传统的 PRD 流程（PRD → 设计稿 → 代码）已经死了。但描述产品需求的文字本身活得好好的。在交付评审之前，这份文档应该是原型的必备搭档。
最标准的形式是一份文档，但也有一些有意思的想法——比如把生成功能所用的 prompt 分享出来作为沟通方式。如果未来的 PRD 就是结构化的、带版本管理的 prompt 呢？
通才比以往更有价值
这里说的通才，是指在产品、工程和设计三方面都有不错感觉的人。这些人一直都很有价值、很有影响力——但有了编程 Agent，他们更加如鱼得水。为什么？
沟通是所有事情中最难的部分，它拖慢一切。一个人如果能同时搞定产品、设计和工程，就比三个人的团队快，因为省掉了沟通开销。
过去实现本身是瓶颈，通才也得和别人沟通才能把事情做完。现在他们只需要和 Agent 沟通就行。这意味着一个人单打独斗的影响力比以往任何时候都大。
使用编程 Agent 是必选项
编程 Agent 让实现成本极低，使用它们就是必选项。能用好编程 Agent 的人可以独自完成更多事情：
产品经理可以直接做原型验证想法，不用写需求文档然后干等
设计师可以直接在代码里迭代，而不只是在 Figma 里画图
工程师可以把时间从实现转向系统思考
用编程 Agent 是必选项，因为上手并不难，而且你不用的话，就会被用的人替代。
好的 PM 更好，差的 PM 更差
好的产品思维比以往更有价值——你能做出真正有用的东西。差的产品思维比以往更浪费。如果某人有一个糟糕的产品想法，他可以带着一个原型出现——但这个原型展示的是一个无用的、或者没想清楚的功能。这些原型现在需要更多人来评审——工程、产品、设计都得看。这会吞噬大量时间和资源。而且上线的惯性更大了（"东西都做出来了！直接合并吧！"）。产品很可能因此变得更差或更臃肿。
系统思维是需要磨练的核心技能
在一个执行成本极低的世界里，系统思维成了真正的差异化能力。你应该专注于磨练系统思维，建立起自己所在领域的清晰心智模型：
工程：对如何设计服务架构、API 和数据库有清晰的心智模型
产品：对用户真正需要什么（而非他们嘴上说想要什么）有清晰的心智模型
设计：对为什么某个东西用起来看着感觉就是对的有清晰的心智模型
系统思维一直都很重要——那变化在哪？实现成本大幅下降了。做出东西比以往更容易——但不代表做出来的就好。好的系统思维让你在动手之前就能确保方向正确，也让你评审别人的工作时更有判断力。两方面都说明，系统思维的重要性提升了。
每个人都需要产品意识
编程 Agent 仍然需要有人来给它下指令，告诉它该做什么。如果你让它做了错误的东西——你就是在给别人制造更多待评审的垃圾。知道该让 Agent 做什么（也就是"产品意识"），是一项基本要求，否则你会拖累整个组织。这对工程、设计和（显然）产品都适用。
EPD 现在有很大一部分工作是评审原型。有产品意识，评审起来更容易，哪怕评审的是设计或工程方面的内容。没有产品意识，就需要一份超级详细的产品文档来配合原型。有产品意识，只需要一份简要说明就能理解功能的意图，加速沟通、评审和交付。
专业化的门槛更高了
你需要会用编程 Agent。你需要有产品意识。所有角色都在融合。
角色之间一直有重叠。设计和产品向来紧密相连——在 Apple 和 Airbnb 这样的公司，设计师本身就兼任产品经理。"设计工程师"（Design Engineer，兼具设计和工程能力的角色）在 Vercel 等公司也越来越流行。
但专业化仍然有它的空间。一个专注系统架构的资深工程师仍然很有价值。一个没学凭感觉编程（Vibe Coding）但对客户问题和该做什么有超清晰心智模型的 PM 也是如此。一个能理解和设计用户旅程与交互的设计师也一样，哪怕还是在 Figma 里工作。
只是专业化的门槛高多了。你不仅要在自己的领域出类拔萃，还要评审速度极快、沟通能力极强。而且这类角色在任何公司里都不会太多。
你要么是建设者，要么是评审者
我们看到 EPD 中正在形成两类角色。
第一类：建设者。这类人有不错的产品思维，能用编程 Agent，具备基本的设计直觉。有了护栏（测试套件、组件库），他们可以把小功能从想法做到上线，把大功能做出可用的原型。
第二类：评审者。对于大型复杂的功能，需要 EPD 层面的深度评审。门槛很高——你必须是自己领域的顶尖系统思维者。而且你得快——要评审的东西太多了。
如果你现在是工程师——要么把系统设计练到极致，能从容评审架构，朝评审者方向发展；要么提升产品和设计能力，成为建设者。
如果你做产品或设计——要么建立起顶级的产品/设计心智模型，主要做评审；要么投入编程 Agent，提升自己的编程功底。
有意思的是，角色正在坍缩，从上面的图可以看到所有 EPD 的人都分布在这张图的某个位置。角色开始融合——工程师有了更多时间，可以更多地思考产品和设计；产品和设计也能写代码了。
每个人都觉得自己的角色从编程 Agent 中受益最大——而且都没说错
Twitter 上有一条很好的帖子，讲的是什么样的人从编程 Agent 中受益最大：
一个对现有产品有直觉般理解的人——知道哪里是短板、哪里是亮点、以及如何迭代让产品变得更锋利。
这种人最稀有的版本，站在文化与深度技术的交叉点上。真正的"双语者"。他们既知道技术上什么是可能的，又能分辨哪些文化潮流是真实的而非昙花一现。正是这种组合，决定了一个产品让人感觉"理应如此"还是"拼凑而成"。
这条帖子精准概括了这个新世界，引发了不小的传播。它之所以传开，部分原因是每个读到的人都觉得说的就是自己或自己的角色。我看到产品人在转发，设计师也在转，设计工程师也在转，创始人也在转……每个人都觉得说的就是自己。
而他们很可能都没说错！我觉得这个新世界令人兴奋的地方在于，出身背景不那么重要了。我真心相信这种人可以来自产品、设计或工程中的任何一个方向。但这不意味着每个人都能成为这样的人——说起来容易做起来难。真正的全才少之又少。
这是一个做建设者的好时代 :)
