EPD 的本质：产出就是代码

软件公司里的 EPD（工程、产品、设计）三个角色，最终目标只有一个：做出能解决业务问题、用户用得上的功能软件。说到底，产出就是代码。认清这一点很重要，因为编程 Agent 突然让写代码变得异常简单，整个角色定位正在被重塑。

PRD 已死，PRD 万岁

PRD（产品需求文档）曾经是软件开发的核心枢纽。传统流程是这样的：

  • 产品经理冒出一个想法
  • 产品经理写一份 PRD
  • 设计师拿着 PRD 做出设计稿
  • 工程师把设计稿变成代码

之所以需要这套流程，是因为写软件和做设计稿要花大量时间精力，于是有了专门分工，分工越细，跨部门沟通的需求就越大。PRD 是一切的起点，把流程串起来。

编程 Agent 颠覆了这一切。它能把一个想法直接变成可运行的软件。"PRD 已死"的真正含义是：从写 PRD 开始的传统软件开发方式，终结了。

但描述产品需求的文档本身并没有死。假设有人快速做出了原型，接下来怎么上线？需要团队成员来评审。评审时，怎么知道代码里某个地方是有意为之还是偶然写成的？得看意图，总得有办法把意图传达清楚。传统的 PRD 流程死了，但描述需求的文字活得好好的——它应该是原型的必备搭档。

一个有意思的想法是：如果未来的 PRD 就是结构化的、带版本管理的 prompt 呢？把生成功能所用的 prompt 分享出来，本身就是一种高效的沟通方式。

瓶颈从实现转向评审

现在谁都能写代码，意味着谁都能把东西做出来。但这不代表做出来的东西架构合理、解决了正确的问题、或者好用。瓶颈转移到了评审环节：

  • 工程视角：代码是否可扩展、高性能、足够健壮？
  • 产品视角：这真的解决了用户的痛点吗？
  • 设计视角：界面是否易用、直观？

初版代码的生成成本极低，大量原型涌现出来，成了大家讨论评审的中心。过去写代码需要很长时间，手上需要评审的项目不会太多。但现在谁都能写代码，在做的项目数量急剧增加，所有职能的瓶颈都转移到了评审——拿到原型后确保它们够好。

通才比以往更有价值

这里说的通才，是指在产品、工程和设计三方面都有不错感觉的人。这类人一直很有价值，但有了编程 Agent，他们更加如鱼得水。

原因很直接：沟通是所有事情中最难的部分，它拖慢一切。一个人如果能同时搞定产品、设计和工程，就比三个人的团队快，因为省掉了沟通开销。过去实现本身是瓶颈，通才也得和别人沟通才能把事情做完。现在他们只需要和 Agent 沟通就行。一个人单打独斗的影响力比以往任何时候都大。

这对一人公司来说是个巨大的利好。

使用编程 Agent 是必选项

编程 Agent 让实现成本极低，不同角色的人都能用它独自完成更多事情：

  • 产品经理可以直接做原型验证想法，不用写需求文档然后干等
  • 设计师可以直接在代码里迭代，而不只是在 Figma 里画图
  • 工程师可以把时间从实现转向系统思考

上手并不难，而且你不用的话，就会被用的人替代。

好的产品思维更好，差的产品思维更差

好的产品思维比以往更有价值——你能做出真正有用的东西。差的产品思维比以往更浪费。如果某人有一个糟糕的产品想法，他可以带着一个原型出现——但这个原型展示的是一个无用的、或者没想清楚的功能。这些原型需要更多人来评审，吞噬大量时间和资源。而且上线的惯性更大了——"东西都做出来了！直接合并吧！"——产品很可能因此变得更差或更臃肿。

系统思维是需要磨练的核心技能

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

  • 工程：对如何设计服务架构、API 和数据库有清晰认知
  • 产品：对用户真正需要什么（而非他们嘴上说想要什么）有清晰认知
  • 设计：对为什么某个东西用起来看着感觉就是对的有清晰认知

做出东西比以往更容易，但不代表做出来的就好。好的系统思维让你在动手之前就能确保方向正确，也让你评审别人的工作时更有判断力。

每个人都需要产品意识

编程 Agent 仍然需要有人来给它下指令。如果你让它做了错误的东西，你就是在给别人制造更多待评审的垃圾。知道该让 Agent 做什么——也就是"产品意识"——是一项基本要求，否则你会拖累整个组织。

有产品意识，评审起来更容易。只需要一份简要说明就能理解功能的意图，加速沟通、评审和交付。没有产品意识，就需要一份超级详细的产品文档来配合原型。

专业化的门槛更高了

所有角色都在融合。你需要会用编程 Agent，需要有产品意识。设计和产品向来紧密相连——在 Apple 和 Airbnb 这样的公司，设计师本身就兼任产品经理。"设计工程师"（兼具设计和工程能力的角色）在 Vercel 等公司也越来越流行。

但专业化仍然有它的空间。一个专注系统架构的资深工程师仍然很有价值，一个没学凭感觉编程（Vibe Coding）但对客户问题和该做什么有超清晰心智模型的 PM 也是如此。只是专业化的门槛高多了——你不仅要在自己的领域出类拔萃，还要评审速度极快、沟通能力极强。

建设者与评审者：两条路

EPD 中正在形成两类角色：

建设者：有不错的产品思维，能用编程 Agent，具备基本的设计直觉。有了护栏（测试套件、组件库），他们可以把小功能从想法做到上线，把大功能做出可用的原型。

评审者：对于大型复杂的功能，需要深度评审。门槛很高——你必须是自己领域的顶尖系统思维者。而且你得快——要评审的东西太多了。

如果你现在是工程师——要么把系统设计练到极致，朝评审者方向发展；要么提升产品和设计能力，成为建设者。如果你做产品或设计——要么建立起顶级的心智模型主要做评审；要么投入编程 Agent，提升编码功底。角色正在坍缩和融合，工程师有了更多时间思考产品和设计，产品和设计也能写代码了。

每个人都觉得自己受益最大——而且都没说错

有一个观察很精准：从编程 Agent 中受益最大的人，是对现有产品有直觉般理解的人——知道哪里是短板、哪里是亮点、以及如何迭代让产品变得更锋利。这种人最稀有的版本，站在文化与深度技术的交叉点上，既知道技术上什么是可能的，又能分辨哪些趋势是真实的而非昙花一现。正是这种组合，决定了一个产品让人感觉"理应如此"还是"拼凑而成"。

这个新世界令人兴奋的地方在于，出身背景不那么重要了。这样的人可以来自产品、设计或工程中的任何一个方向。但说起来容易做起来难，真正的全才少之又少。

对独立开发者和一人公司而言，行动建议很明确：用好编程 Agent 降低执行成本，同时花更多时间打磨产品意识和系统思维。能做出东西的人越来越多，能判断该做什么、做得好不好的人，才是真正稀缺的。