快速阅读

随着编程智能体（Coding Agents）的兴起，软件公司内部工程（Engineering）、产品（Product）和设计（Design）——即 EPD 的核心角色正在发生剧变。过去的软件构建以产品需求文档（PRD）为起点，经过层层传递直至代码实现；但如今，只要有产品感，任何人都能凭借智能体快速生成功能代码。

这场变革的核心影响包括：

1. 传统的 PRD 已死，取而代之的是伴随着原型的轻量化产品描述或结构化提示词。
2. 软件开发的瓶颈已经从代码实施阶段转移到了代码审查阶段。
3. 能跨越产品、设计和工程的**“通才”变得比以往任何时候都更有价值**。
4. 未来的 EPD 角色将主要分化为两类：能独立从想法到雏形的构建者（Builder），以及具备顶级系统思维能力的审查者（Reviewer）。

简而言之：如果你不拥抱智能体，你将无法在这场生产力革命中保持竞争力。

---

在软件公司中，EPD（工程、产品和设计）的核心使命是创造出优秀的软件。尽管这三个角色通常是分离的，但最终目标都是通过功能性软件来解决用户问题并创造商业价值。从本质上讲，最终的产出就是代码。

我们必须认识到，既然 EPD 团队的最终产出是一行行代码，那么当编程智能体突然让编写代码变得极其容易时，这会如何改变 EPD 的角色定位呢？

变革正在发生

传统 PRD 已死

在“前大模型时代（pre-Claude era）”，产品需求文档（PRD）是构建软件的核心。以前的 EPD 流程很大程度上是这样的：

1. 某人（通常是产品经理）有了一个想法。
2. 产品经理撰写 PRD。
3. 设计师拿到 PRD 并创建交互原型。
4. 工程师将原型转化为实际代码。

之所以需要这种“瀑布流”式的协作，是因为无论是编写代码还是制作原型，都需要极高的专业门槛和大量的时间投入。因此，大家高度分工，而 PRD 就是沟通这些不同专业职能的桥梁。

但编程智能体改变了这一切。 智能体可以直接把一个想法变成功能软件。所以当我们说“PRD 已死”时，我们真正的意思是：这种必须从撰写冗长 PRD 开始的传统软件构建方式已经不复存在了。

瓶颈从“实施”转移到了“审查”

现在任何人都可以写代码并构建东西，但这并不意味着他们造出来的东西架构合理、能解决正确的痛点或者易于使用。因此，工程、产品和设计团队就应该成为这些领域的“审查者（Reviewers）”和最终仲裁者。

智能体生成的代码并不总是“伟大的（Great）”。EPD 的作用就是审查并确保它们变得伟大：

• 工程维度的伟大：架构是否合理、性能是否优越、代码是否健壮？
• 产品维度的伟大：这是否真正解决了用户的痛点？
• 设计维度的伟大：界面是否直观、易于使用？

因为创建一个初代代码版本的成本极低，我们会看到越来越多的“原型（Prototypes）”被快速生产出来。这些原型将成为新的聚焦点，供产品、工程和设计团队审查。

过去的瓶颈在于写代码太慢，所以摆在你桌面上需要审查的项目并不多；现在任何人都可以“写代码”，导致项目数量激增，于是开发流程的瓶颈（在产品、工程和设计所有三个方面）都变成了审查。

PRD 精神长存

尽管以 PRD 为起点的旧时代落幕了，但描述产品需求的文档依然是不可或缺的。

如果有人带着用智能体快速搭建的原型跑来找你，它要怎么部署上线？它需要其他 EPD 成员的审查。审查时，大家怎么知道某段代码是“特意这么写的”还是“AI 瞎编的”？这需要沟通意图。

所以传统的流程死了，但用来描述产品意图的文字仍然活着。这份文档必须作为原型的配套材料，在提交审查前一起提供。未来甚至可能出现这种形式：“未来的 PRD 只是结构化和版本化的 AI 提示词（Prompts）。”

对职业角色的影响

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

这里的“通才”，指的是那些对产品、工程和设计都有良好直觉的人。他们在过去就很有价值，但在编程智能体时代，他们的价值被放大了无数倍。

在所有事情中，“沟通”是最难、也是最拖慢进度的部分。一个能独自搞定产品、设计和工程的人，由于零沟通成本，动作会比三个人的团队快得多。过去即便通才想大展拳脚，受限于技术实施的瓶颈，依然要依赖他人；现在，他们只需要跟智能体沟通。这使得通才可以单枪匹马发挥出前所未有的影响力。

采用编程智能体不再是可选项，而是必须项

既然智能体让实现成本变得如此低廉，使用它们就成了刚需。那些拥抱智能体的人能独立做成更多事：

• 拥抱智能体的 PM 能够直接通过构建原型来验证想法，而不需要写长篇规格说明并干等着。
• 拥抱智能体的设计师 可以直接在代码层面迭代，而不仅仅是在 Figma 里。
• 拥抱智能体的工程师 可以把精力从低级代码实现转移到高级系统思维上。

这并不难做到。如果你不这么做，很快就会被掌握这项技能的人取代。

优秀的产品经理更加大放异彩，而糟糕的只会徒增麻烦

好的“产品思维”将变得更加稀缺和宝贵——因为你能指导 AI 建造出有用的东西。反之，糟糕的产品思维会带来空前的浪费：如果一个人带着糟糕的想法来，他可以直接扔出一个原型的功能代码，但这功能可能毫无用处。

这些糟糕的原型将不可避免地消耗工程、产品和设计团队去“审查”。因为代码已经写好了，把它推向生产环境的惯性阻力更小（“反正它都在那了！合并算了！”），这将导致产品变得更加臃肿和糟糕。

系统思维是必修课

在这个“执行变得廉价”的世界里，系统思维（System Thinking）成为了最核心的差异化优势。

你应该专注于磨练系统思维，并在你所在的领域建立清晰的心理模型：

• 工程：如何设计服务、API 和数据库架构的绝佳心理模型。
• 产品：对用户真正需要什么（而不是他们嘴上说想要什么）的深刻洞察。
• 设计：为什么某种交互和视觉看起来对、感觉起来对的直觉与逻辑。

由于把东西做出来的门槛降到了谷底，确保一开始就在“做正确的事”比什么都重要，这也是做好事后代码审查的根本。

每个人都需要“产品感”

编程智能体仍然需要有人来提示它们、告诉它们要做什么。如果你让它去建一个错误的东西，你只是在制造更多的垃圾供他人审查。因此，知道“要告诉智能体构建什么”（即产品感）已然是一项硬性要求。对于工程、设计，尤其是产品人员来说，都是如此。

专业化的门槛变得更高了

所有角色都在走向融合：工程师有更多时间思考产品，设计师可以直接输出代码。但这不意味着不需要专家了。一个只思考宏观架构的高级工程师，或者一个拥有极强用户痛点洞察力却不会写代码的 PM，依然具有很高的价值。

只不过，在这个时代，“专家”的门槛被大幅拉高了。你不仅要在自己的领域极其出色，还要具备难以置信的审查速度和沟通能力。

你要么是构建者（Builder），要么是审查者（Reviewer）

在 EPD 团队中，两种不同类型的角色正在浮现：

1. 构建者（The Builder）：他们有优秀的产品思维，能够熟练使用编程智能体，并具备基础的设计直觉。在适当的护栏（测试套件、组件库）保护下，他们能把小功能的点子直接推向生产环境，并为大功能制作可运行的原型。
2. 审查者（The Reviewer）：对于复杂的大型功能，需要详细的 EPD 审查。这个门槛极高——你必须是你所在领域的顶级系统思考者，并且要能适应极快的工作节奏，因为需要审查的代码如同海啸。

如果你现在是工程师，要么努力精进系统设计，成为一名“审查者”；要么拓展产品与设计技能，成为一名“构建者”。 如果你是产品或设计人员，要么在你的心智模型中登峰造极转入审查，要么就卷起袖子，用编程智能体强化你的代码能力。

这真是一个让人兴奋的构建时代。

🔗 原文链接：How Coding Agents Are Reshaping Engineering, Product and Design