编码代理如何重塑工程、产品和设计

软件公司的 EPD (Engineering, Product, and Design) 部门旨在创建优质软件。尽管存在不同的角色，但最终目标是开发出能解决业务问题并可供用户使用的功能性软件。归根结底，这只是一堆代码。认识到 EPD 作为一个职能部门所构建的产出仅仅是代码这一点很重要，因为…… 编码代理（coding agents）突然让代码编写变得异常容易。那么，这会如何改变 EPD 的角色呢？

不断变化的过程：

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

对角色的影响：

• 通才（Generalists）比以往任何时候都更有价值
• 编码代理是必需品
• 好的 PM 很棒，差的 PM 很糟糕
• 每个人都需要产品感（product sense）
• 专业化的门槛更高了
• 你不是建造者就是评审者
• 每个人都认为他们的角色最受编码代理的优势——而且他们是对的

PRD 已死

PRD (Product Requirement Documents) 在 Claude 时代之前是构建软件的焦点。EPD 流程大体上是：

• 某人（通常是产品经理）有一个想法
• 产品经理编写 PRD
• 设计部门根据 PRD 创建模型
• 工程部门将模型转化为代码

这并非一成不变的规则（在初创公司，这些步骤会融合在一起，最好的构建者能够同时完成多项工作），但这是教科书式的构建方式。

之所以需要这样做，是因为构建软件（和构建模型）需要大量的时间和精力。因此，为了专注于这些工作而创建了不同的学科。随着人们变得更加专业化，就需要跨学科进行沟通。PRD 是这种沟通的基础，它启动了一切。然后，它会瀑布式（waterfall）地传递给设计部门，设计部门会将优美的文字转化为漂亮的 UI 和流畅的 UX。最后，工程部门会将其变为现实。

编码代理改变了这一切。编码代理可以根据一个想法创建功能性软件。当我和其他人说“PRD 已死”时，我们真正的意思是这种传统的软件构建方式，即从编写 PRD 开始，已经消亡了。

瓶颈从实现转移到评审

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

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

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

问题在于——生成代码太容易了。以前，创建代码需要一段时间——所以作为评审者，你案头需要评审的项目数量有限。然而现在，任何人都可以编写代码。这意味着正在进行的项目数量正在增加。我们已经看到（所有三个职能部门）的瓶颈是评审——获取原型并确保它们是“好的”。

PRD 万岁

Claude 时代之前（以 PRD 开始）的软件构建方式已经消失了。但是，描述产品需求的文档仍然至关重要。

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

我认为传统的 PRD 流程（PRD → 模型 → 代码）已经消亡了。但描述产品需求的文本却非常有生命力。在将其交付评审之前，这份相关文档应作为原型的必要伴侣。

最标准的格式将是文档，但有一些有趣的想法是共享用于创建此功能的提示（prompts），以此来传达。如果未来的 PRD 只是结构化、版本化的提示（prompts）呢？

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

我所说的通才（generalists）是指对产品、工程和设计三个领域都有良好理解的人。这些人一直都很有价值且具有影响力——但有了编码代理，他们更是如此。为什么？

沟通是所有事情中最困难的部分。它会减慢速度。一个能够同时进行产品、设计和工程工作的人会比一个三人团队行动更快，因为沟通开销更小。

以前，当实现是障碍时，这个通才（generalist）仍然需要与其他人沟通才能完成工作。现在他们只需要与代理（agents）沟通。这意味着他们自己就能比以往任何时候都产生更大的影响力。

编码代理是必需品

由于编码代理使得实现成本低廉，使用它们是必需的。能够采用编码代理的人将能够独自完成更多工作：

• 采用编码代理的 PM 可以通过直接构建原型来验证想法，而无需编写规范（spec）和等待
• 采用编码代理的设计师可以在代码中进行迭代，而不仅仅是在 Figma 中
• 采用编码代理的工程师可以将时间从实现转移到系统思考（system thinking）上

采用编码代理是必需的，因为这样做并不难，如果你不这样做，你就会被那些做的人取代。

好的 PM 很棒，差的 PM 很糟糕

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

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

在一个执行成本低廉的世界里，系统思考（system thinking）成为了区别。你应该专注于擅长系统思考（system thinking），并对你的特定领域（domain）有一个清晰的心智模型（mental model）：

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

系统思考（System thinking）一直很重要——那么改变了什么？实现的成本大大降低了。这意味着实现某些东西比以往任何时候都容易——但这并不意味着它很棒。成为一个优秀的系统思考者（system thinker）可以让你确保你从一开始（upfront）就构建正确的东西。它也让你可以在事后评审他人的工作。这两点都意味着成为一个优秀的系统思考者（system thinker）的重要性增加了。

每个人都需要产品感

编码代理（Coding agents）仍然需要有人提示（prompt）它们。有人告诉它们该做什么。如果你告诉它们构建错误的东西——你会给其他人带来更多的负担（slop）去评审。知道要告诉代理构建什么（“产品感”，product sense）是必需的，否则你将成为组织的累赘。这适用于工程、设计以及（显而易见的）产品部门。

EPD 的一个重要部分现在是评审原型。如果你有产品感（product sense），即使是评审设计/工程，评审也会更容易。如果你没有产品感（product sense），你需要在原型旁边附带一份超详细的产品文档。如果你有产品感（product sense），你就能以最少的规范（spec）理解功能的意图，从而加快沟通、评审和交付。

专业化的门槛更高了

你需要知道如何使用编码代理（coding agents）。你需要产品感（product sense）。所有角色都在融合。

角色之间一直存在重叠。设计和产品长期以来都是相互关联的——在某些公司，如苹果和爱彼迎，设计师担任产品经理。“设计工程师”（Design engineer）作为一个角色在 Vercel 等公司越来越受欢迎。

这并不意味着没有专业化的空间。一位只关注系统架构（system architecture）的资深工程师仍然很有价值。一位没有掌握气氛编码（vibe coding）但对客户问题和要构建什么有非常清晰的心智模型（mental model）的 PM 也是如此。同样，一位即使仍在 Figma 中也能理解和模拟用户旅程和交互的设计师也很有价值。

但专业化的门槛要高得多。你不仅必须在你的领域（domain）表现出色，还必须在评审方面非常迅速，并且是一位出色的沟通者。而且在任何一家公司，这种角色可能都不会太多。

你不是建造者就是评审者

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

第一种：建造者（builder）。这种原型（archetype）具有良好的产品思维（product thinking），能够使用编码代理（coding agents），并且具备基本的设计直觉（design intuition）。在他们的防护栏（guardrails）（测试套件，test suite；组件库，component library）的保护下，他们可以将小型功能从想法变为生产，并原型化（prototype）大型功能的可行版本。

第二种：评审者（reviewer）。对于大型复杂功能，需要详细的 EPD 评审。这方面的门槛很高——你必须是你的领域（domain）中出色的系统思考者（systems thinker）。你还必须以快速的节奏工作——有很多东西需要评审。

如果你现在是一名工程师——你应该要么致力于在系统设计（system design）方面变得出色，并习惯评审架构，并致力于成为一名评审者……要么尝试培养你的产品/设计技能，成为一名建造者。

如果你在产品或设计部门——你必须对产品/设计有出色的心智模型（mental model）并主要进行评审，或者投入编码代理（coding agents）并提高你的编码能力（coding chops）。

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

每个人都认为他们的角色最受编码代理的优势——而且他们是对的

Twitter 上有一篇很棒的帖子（great post on Twitter），内容是关于最受编码代理（coding agents）优势的人：

那些对产品现状、其不足之处（soft）、其出彩之处（sings）以及如何迭代使其更锐利（sharper）有直观理解的人。

这种人中最稀有的一种处于文化与深度技术（deep technology）的交汇点。一个真正的双语者（bilingual）。他们知道什么是技术上可能的，也知道哪些文化潮流是真实（real）的，哪些是短暂（ephemeral）的。这种组合正是将那些感觉不可避免（inevitable）的产品与那些感觉拼凑而成（assembled）的产品区分开来的原因。

这篇帖子很好地概括了这个新世界，并且半病毒式传播（semi-viral）。它之所以能病毒式传播（viral）的一部分原因是，所有阅读它的人都认为它指的是他们自己或他们的角色。我看到产品经理、设计师、设计工程师（design engineers）、创始人（founders）……所有人都认为它适用于他们和他们的角色。

而且他们可能都说对了！我认为这个新世界最棒、最令人兴奋的地方在于，背景变得不那么重要了。我真诚地相信这种原型人物（archetype of person）可以来自产品、设计或工程部门。这并不意味着每个人都会成为这样的人——说起来容易做起来难。真正的独角兽（unicorns）少之又少。

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

• 原文链接： x.com/hwchase17/status/2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～