第一时间捕获有价值的信号
本文译自 LangChain 创始人 Harrison Chase 在 X 上发布的长文 “How Coding Agents Are Reshaping Engineering, Product and Design”。
软件公司的 EPD（工程、产品、设计）职能，本质上都是为了创造优秀的软件。虽然角色分工不同，但最终目标都是交付能解决业务问题、用户可用的功能性软件。归根结底，这一切都只是代码。认识到 EPD 作为一个职能的输出就是代码这一点至关重要，因为……编程智能体突然让代码变得极其容易编写。那么，这将如何改变 EPD 的角色呢？
正在变化的流程
- PRD 已死
- 瓶颈从实施转向审查
- PRD 万岁
对角色的影响
- 通才比以往任何时候都更有价值
- 编程智能体是必备工具
- 好的产品经理如虎添翼，差的产品经理雪上加霜
- 每个人都需要产品感
- 专业化的门槛更高了
- 你要么是建设者，要么是审查者
- 每个人都认为自己的角色从编程智能体中获益最多——他们都没错
PRD 已死
PRD（产品需求文档）曾是前 Claude 时代软件开发的核心焦点。EPD 流程大致是这样的：
- 某人（通常是产品）有了一个想法
- 产品撰写 PRD
- 设计根据 PRD 创建原型
- 工程将原型转化为代码
这并非铁律（在初创公司中这些步骤会融合在一起，最优秀的建设者能够同时完成多项工作），但这是教科书式的构建方式。
之所以需要这样，是因为构建软件（以及创建原型）需要大量的时间和精力。因此，学科被划分出来专门从事这些工作。随着人们变得更加专业化，就产生了跨学科沟通的需求。PRD 就是这一切的基础，它启动了整个流程。然后瀑布式地流向设计，设计将漂亮的文字转化为漂亮的 UI 和流畅的 UX。工程再将这一切变为现实。
编程智能体改变了这一切。编程智能体可以接收一个想法并创建功能性软件。当我（以及其他人）说”PRD 已死”时，我们真正的意思是这种传统的软件开发方式——从撰写 PRD 开始——已经消亡了。
瓶颈从实施转向审查
现在任何人都能编写代码，这意味着任何人都能构建东西。但这并不意味着构建出来的东西架构良好、解决了正确的问题，或者易于使用。工程、产品和设计应该成为这些领域的审查者和仲裁者。问题在于生成的代码并不总是”优秀”的。EPD 的角色变成了审查并确保它是”优秀”的。“优秀”可以意味着几件事：
- 从工程系统的角度来看架构良好：代码是否以可扩展、高性能、健壮的方式编写？
- 从产品的角度来看经过深思熟虑：这是否解决了用户的痛点？
- 设计良好：界面是否易于使用和直观？
由于创建代码初始版本的成本如此之低，我们看到创建了更多的原型。这些原型随后成为焦点，由产品、工程和设计进行审查。
问题在于——生成代码太容易了。以前，创建代码需要一段时间——所以作为审查者，在任何给定时间只有那么多项目出现在你的办公桌上等待审查。但现在——任何人都能编写代码。这意味着正在进行的项目数量在增加。我们看到（所有三个职能的）瓶颈都是审查——接收原型并确保它们是”好的”。
PRD 万岁
前 Claude 时代的软件开发方式（从 PRD 开始）已经一去不复返了。但描述产品需求的文档仍然至关重要。
假设某人有了一个想法并快速构建了一个原型。这如何进入生产环境？它需要由 EPD 的其他成员进行审查。作为这个过程的一部分，一份书面文档总是有帮助的，而且通常是必不可少的。当其他人进行审查时，他们如何知道代码的某些部分是偶然存在的还是有意为之？这取决于意图。需要某种对这种意图的沟通。
我认为传统的 PRD 流程（PRD → 原型 → 代码）已经消亡。但描述产品需求的文本仍然非常活跃。这份配套文档应该是原型在移交审查之前的必备伴侣。
最标准的格式将是文档，但也有一些有趣的想法，比如分享用于创建此功能的提示作为传达意图的方式。如果未来的 PRD 只是结构化、版本化的提示呢？
通才比以往任何时候都更有价值
我所说的通才是指对产品、工程和设计三者都有良好感觉的人。这些人一直都很有价值和影响力——但有了编程智能体，他们更是如此。为什么？
沟通是一切中最困难的部分。它会拖慢事情。一个能够同时完成产品、设计和工程的人会比三人团队移动得更快，因为沟通 overhead。
以前，当实施是瓶颈时，这个通才仍然需要与他人沟通才能完成工作。现在他们可以只与智能体沟通。这意味着他们独自一人就能比以往任何时候都更有影响力。
编程智能体是必备工具
随着编程智能体让实施变得廉价，使用它们成为一种必需。能够采用编程智能体的人将能够自己完成更多工作：
- 采用编程智能体的产品经理可以通过直接构建原型来验证想法，而无需撰写规范并等待
- 采用编程智能体的设计师可以在代码中迭代，而不仅仅是在 Figma 中
- 采用编程智能体的工程师可以将时间从实施转向系统思考
采用编程智能体是一种必需，因为这并不难做到，如果你不这样做，你就会被这样做的人取代。
好的产品经理如虎添翼，差的产品经理雪上加霜
好的产品思考比以往任何时候都更有价值——你可以构建有用的东西。糟糕的产品思考比以往任何时候都更浪费。如果某人有一个糟糕的产品想法，他们可能会带来一个原型——但这个原型将是一个无用的或构思不佳的功能。这些原型现在需要更多的审查——来自工程、产品和设计。这会消耗时间和资源。而且将这些原型投入生产也有更大的惯性（“它已经存在了！让我们合并它吧！”）。这冒着创建更糟糕或臃肿产品的风险。
系统思考是需要磨练的技能
在执行成本低廉的世界中，系统思考成为差异化因素。你应该专注于成为非常优秀的系统思考者，并对你的特定领域有清晰的心智模型：
- 工程：对如何架构服务、API 和数据库有非常好的心智模型
- 产品：对用户实际需要什么有非常好的心智模型，而不是他们说他们想要什么
- 设计：对为什么某些东西看起来和使用起来感觉正确有非常好的心智模型
系统思考一直都很重要——那么有什么改变呢？实施的成本大幅下降。这意味着实现某件事比以往任何时候都更容易——但这并不意味着它是好的。成为一个好的系统思考者可以让你确保从一开始就构建正确的东西。它还让你能够事后审查其他人的工作。两者都意味着成为一个好的系统思考者的重要性已经增长。
每个人都需要产品感
编程智能体仍然需要有人来提示它们。有人告诉它们该做什么。如果你告诉它们构建错误的东西——你正在制造更多的垃圾让其他人审查。知道告诉智能体构建什么（“产品感”）是一种必需，否则你将成为组织的负担。这在工程、设计和（显然）产品中都是正确的。
EPD 的很大一部分现在是审查原型。如果你有产品感，审查会更容易，即使是审查设计/工程。如果你没有产品感，你需要在原型旁边附上一份超级详细的产品文档。如果你有产品感，你可以通过最小的规范理解功能的意图，从而加快沟通、审查和交付。
专业化的门槛更高了
你需要知道如何使用编程智能体。你需要产品感。所有角色都在融合在一起。
角色之间一直存在重叠。设计和产品长期以来一直联系在一起——在 Apple 和 AirBnb 等某些公司，设计师担任产品经理。“设计工程师”作为一个角色在 Vercel 等公司逐渐流行起来。
这并不意味着没有专业化的空间。一个只考虑系统架构的非常资深的工程师仍然很有价值。一个没有学会 vibe coding 但对客户问题和构建什么有超级清晰心智模型的产品经理也是如此。同样，一个能够理解和模拟用户旅程和交互的设计师，即使仍然在 Figma 中，也是如此。
但专业化的门槛要高得多。你不仅必须在你的领域出类拔萃，而且必须在审查方面极其快速，并且是一个出色的沟通者。而且在任何给定的公司中，这些角色可能并不多。
你要么是建设者，要么是审查者
我们看到 EPD 中出现了两种不同类型的角色。
首先：建设者。 这个原型具有良好的产品思考能力，能够使用编程智能体，并具有基线设计直觉。在他们周围有防护栏（测试套件、组件库）的情况下，他们可以将小功能从想法带到生产，并原型化大型功能的可工作版本。
第二：审查者。 对于大型和复杂的功能，需要详细的 EPD 审查。这方面的门槛很高——你必须在你的领域是一个出色的系统思考者。你还必须以快速的节奏工作——有很多东西需要审查。
如果你现在是一名工程师——你应该要么目标是在系统设计方面出类拔萃，并乐于审查架构，目标是成为一名审查者……要么尝试发展你的产品/设计技能并成为一名建设者。
如果你是产品或设计——你要么必须对产品/设计有出色的心智模型并主要进行审查，要么跳进编程智能体并提高你的编码能力。
有趣的是，角色正在某种程度上融合，如上图所示，所有 EPD 都在某个位置。角色可以开始融合在一起——工程师有更多时间，可以更多地思考产品和设计。产品和设计可以创建代码。
每个人都认为自己的角色从编程智能体中获益最多——他们都没错
有一篇关于从编程智能体中获益最多的人的类型的帖子广为流传：
某人对产品有直观的把握，了解它的现状、它的弱点、它的亮点，以及如何将其迭代向更锐利的东西。
这种人最稀有的版本处于文化与深度技术的交汇处。某人真正的双语者。他们知道技术上可能什么，也知道哪些文化潮流是真实的，哪些是短暂的。这种组合是让感觉不可避免的产品与感觉组装的产品区分开来的原因。
那篇帖子是对这个新世界的绝佳概括，它 semi-viral 了。它 viral 的部分原因是阅读它的每个人都认为这是关于他们或他们的角色。我看到产品人引用它，设计师，设计工程师，创始人……每个人都认为这适用于他们和他们的角色。
而且他们可能都是对的！我认为这个新世界的伟大和令人兴奋的事情是背景不那么重要。我真诚地相信这种原型的人可以来自产品、设计或工程。这并不意味着每个人都会是这种人——说起来容易做起来难。真正的独角兽很少。
这是一个令人兴奋的建设时代 :)