编码智能体如何重塑工程、产品与设计

在软件公司，EPD（工程、产品、设计）的核心任务是创造好软件。虽然角色分立，但最终目标都是产出能解决业务问题、可供用户使用的功能性软件。归根结底，这就是代码。认识到EPD职能的产出就是代码至关重要，因为……编码智能体突然让写代码变得非常容易。那么，这会如何改变EPD的角色？

流程之变

• PRD已死
• 瓶颈从实现转向评审
• PRD万岁

角色之变

• 通才比以往任何时候都更有价值
• 编码智能体成为必需品
• 优秀的产品经理很棒，糟糕的产品经理很可怕
• 每个人都需要产品感
• 专业化的门槛更高了
• 你要么是构建者，要么是评审者
• 每个人都认为自己的角色最能从编码智能体中受益——他们是对的

PRD已死

PRD（产品需求文档）是前Claude时代构建软件的核心。典型的EPD流程是：

• 某人（通常是产品）有一个想法
• 产品撰写PRD
• 设计根据PRD制作原型
• 工程将原型转化为代码

这并非铁律（在初创公司这些步骤常融合，最优秀的构建者能同时完成多项），但这是教科书式的构建方式。

之所以需要这样，是因为构建软件（以及制作原型）需要大量时间和精力。因此产生了专门从事这些工作的学科。随着人们越来越专业化，跨学科沟通的需求随之产生。PRD是这一切的基础，它启动整个流程，然后瀑布式地传递给设计，设计将漂亮的文字转化为漂亮的UI和流畅的UX，工程再将其变为现实。

编码智能体改变了这一切。编码智能体可以接受一个想法并创建功能性软件。当我说“PRD已死”时，真正指的是这种从撰写PRD开始的传统软件构建方式已经过时。

瓶颈从实现转向评审

现在任何人都能写代码，这意味着任何人都能构建东西。但这并不意味着构建出来的东西架构良好、解决了正确的问题或易于使用。工程、产品和设计应该成为这些领域的评审者和仲裁者。问题在于，生成的代码并不总是“优秀”。EPD的角色变成了评审并确保其“优秀”。“优秀”可以指多个方面：

• 从工程系统角度看架构良好：是否以可扩展、高性能、健壮的方式编写？
• 从产品角度看思虑周全：是否解决了用户痛点？
• 设计精良：界面是否易于使用且直观？

由于创建代码初始版本的成本极低，我们看到产生了更多的原型。这些原型随后成为焦点，由产品、工程和设计进行评审。

问题是——生成代码太容易了。以前，创建代码需要一段时间，因此作为评审者，你手头需要评审的项目数量有限。但现在，任何人都能写代码。这意味着正在进行的项目数量在增加。我们观察到瓶颈（在所有三个职能中）都转移到了评审环节——即审查原型并确保它们“良好”。

PRD万岁

前Claude时代从PRD开始的软件构建方式已经一去不复返。但描述产品需求的文档仍然至关重要。

假设某人有一个想法并快速构建了一个原型。这如何进入生产环境？它需要由EPD的其他成员评审。在这个过程中，书面文档总是有帮助的，而且通常是必不可少的。当其他人评审时，他们如何知道某部分代码是偶然存在还是有意为之？这取决于意图。需要某种形式的意图沟通。

我认为传统的PRD流程（PRD → 原型 → 代码）已经过时。但描述产品需求的文本仍然非常重要。在移交评审之前，这份相关文档应该是原型的必备附件。

最标准的形式是文档，但也有一些有趣的想法，比如共享用于创建此功能的提示（Prompt）作为一种沟通方式。未来的PRD会不会只是结构化、版本化的提示？

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

我所说的通才，是指对产品、工程和设计都有良好感觉的人。这些人一直很有价值、很有影响力——但有了编码智能体，他们更是如此。为什么？

沟通是一切中最难的部分。它会拖慢进度。一个能兼顾产品、设计和工程的人，因为沟通开销更小，其推进速度将快于一个三人团队。

以前，当实现是瓶颈时，这位通才仍然需要与他人沟通才能完成工作。现在他们可以直接与智能体沟通。这意味着他们单枪匹马就能产生比以往更大的影响力。

编码智能体成为必需品

随着编码智能体使实现成本降低，使用它们已成为必需。能够采用编码智能体的人将能独立完成更多工作：

• 采用编码智能体的产品经理可以直接构建原型来验证想法，而无需编写规格说明并等待
• 采用编码智能体的设计师可以在代码中迭代，而不仅仅是在Figma中
• 采用编码智能体的工程师可以将时间从实现转向系统思考

采用编码智能体是必需的，因为这样做并不难，如果你不这样做，你将被这样做的人取代。

优秀的产品经理很棒，糟糕的产品经理很可怕

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

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

在执行成本低廉的世界里，系统思维成为差异化因素。你应该专注于真正擅长系统思维，并对你的特定领域有清晰的心智模型：

• 工程：对如何架构服务、API和数据库有非常好的心智模型
• 产品：对用户实际需要什么（而非他们口头想要什么）有非常好的心智模型
• 设计：对为什么某些东西看起来和用起来感觉正确有非常好的心智模型

系统思维一直很重要——那么什么改变了？实现的成本大幅下降。这意味着实现某样东西比以往更容易——但这并不意味着它就优秀。成为一个好的系统思考者能让你确保从一开始就在构建正确的东西，也让你能在事后评审他人的工作。这两点都意味着，成为一个好的系统思考者的重要性增加了。

每个人都需要产品感

编码智能体仍然需要有人提示（Prompt）它们。需要有人告诉它们做什么。如果你让它们构建错误的东西——你就是在制造更多需要他人评审的垃圾。知道告诉智能体构建什么（“产品感”）是必需的，否则你将成为组织的拖累。这在工程、设计和（显然）产品领域都是如此。

EPD现在很大一部分工作是评审原型。如果你有产品感，评审会更容易，即使是评审设计或工程方面。如果你没有产品感，你需要一份超级详细的产品文档伴随原型。如果你有产品感，你只需一份最小规格说明就能理解功能的意图，从而加速沟通、评审和交付。

专业化的门槛更高了

你需要知道如何使用编码智能体。你需要产品感。所有角色都在融合。

角色之间一直存在重叠。设计和产品长期以来一直紧密相连——在苹果和Airbnb等公司，设计师兼任产品经理。“设计工程师”作为一种角色在Vercel等公司越来越流行。

这并不意味着没有专业化的空间。一位只思考系统架构的资深工程师仍然有价值。同样，一位尚未掌握编码但能清晰把握客户问题及构建方向的产品经理也有价值。一位即使仍在Figma中也能理解并模拟用户旅程和交互的设计师也是如此。

但专业化的门槛高多了。你不仅必须在自己的领域出类拔萃，还必须极其擅长快速评审和高效沟通。而且，在任何一家公司，这类角色的数量可能都不多。

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

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

第一种：构建者。这类人具有良好的产品思维，能够使用编码智能体，并具备基本的设计直觉。在有安全护栏（测试套件、组件库）的情况下，他们可以将小功能从想法带到生产环境，并能构建大型功能的原型版本。

第二种：评审者。对于大型复杂功能，需要详细的EPD评审。对此的要求很高——你必须是你所在领域出色的系统思考者。你还必须快速工作——有很多东西需要评审。

如果你现在是一名工程师——你应该要么努力精通系统设计，乐于评审架构，并立志成为评审者……要么尝试提升你的产品/设计技能，成为构建者。

如果你在产品或设计领域——你必须要么对产品/设计有极佳的心智模型并主要从事评审工作，要么投身编码智能体并提升你的编码能力。

有趣的是，角色正在某种程度上融合，正如上图所示所有EPD人员都位于某个位置。角色可以开始融合——工程师有更多时间，可以更多地思考产品和设计。产品和设计人员可以创建代码。

每个人都认为自己的角色最能从编码智能体中受益——他们是对的

推特上有一篇关于最能从编码智能体中受益的人群类型的精彩帖子：

那些对产品现状有直观把握的人，知道哪里柔软，哪里美妙，以及如何迭代使其更加锐利。 这类人中最稀有的版本，坐在文化与深度技术的交叉点。他们是真正的双语者。他们知道什么是技术上可行的，也知道哪些文化潮流是真实的，哪些是短暂的。这种组合将感觉必然的产品与感觉拼凑的产品区分开来。

这篇帖子精彩地概括了这个新世界，并获得了半病毒式传播。它走红的部分原因是，每个读到它的人都认为这是在描述他们自己或他们的角色。我看到产品人、设计师、设计工程师、创始人都在引用它……每个人都认为它适用于他们和他们的角色。

他们可能都是对的！我认为这个新世界伟大而令人兴奋的一点是，背景变得不那么重要了。我真诚地相信，这类人可能来自产品、设计或工程背景。这并不意味着每个人都会成为这种人——这说起来容易做起来难。真正的独角凤毛麟角。

这是一个令人兴奋的构建时代 :)