编程 Agent 如何重塑工程、产品和设计

软件公司的 EPD（工程 Engineering、产品 Product、设计 Design）存在的意义就是做出好软件。虽然分了不同角色，但最终目标一样：做出能解决业务问题、用户用得上的功能软件。说到底，产出就是代码。这一点必须认清——因为编程 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 上有一条很好的帖子^[1]，讲的是什么样的人从编程 Agent 中受益最大：

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

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

这条帖子精准概括了这个新世界，引发了不小的传播。它之所以传开，部分原因是每个读到的人都觉得说的就是自己或自己的角色。我看到产品人在转发，设计师也在转，设计工程师也在转，创始人也在转……每个人都觉得说的就是自己。

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

这是一个做建设者的好时代 :)

引用链接

[1] 很好的帖子: https://x.com/signulll/status/2030404483897815089

文章来自于“宝玉AI”，作者“Harrison Chase”。