PRD已死？编程智能体正在重塑EPD协作方式

编程智能体与EPD协作示意图

Harrison Chase（LangChain创始人）在2026年3月发表了一篇长文，标题叫”PRD已死”。但读完你会发现，他真正想说的不是文档消亡，而是整个软件构建流程正在被编程智能体（coding agents）翻转。

EPD——Engineering、Product、Design这三个职能——的存在意义始终是一个：交付好软件。软件的本质是代码。而现在，代码变得极其便宜。这一个变量，把所有事情都搅动了。

传统流程为什么是那样的

在Claude这类编程智能体出现之前，EPD有一套标准流程：产品写PRD，设计把文字变成视觉稿，工程把视觉稿变成可运行的代码。这套流程不是某人发明的，它是自然生长出来的——因为写代码和画稿子都需要大量时间，专业化是合理的分工，跨专业分工就需要沟通协议，PRD就是那个协议。

现在的问题是：这条链条上最耗时的环节（写代码）突然变得很廉价。

任何人都可以写代码了。但”可以写”不等于”写得好”。代码生成的成本降到接近零，随之而来的是：同时进行的项目数量激增，每个工程师、产品、设计师桌上等待评审的原型越堆越多。

追问一下，Chase指出了三个评审维度：

以前每个季度可能只有几个项目上桌，现在随时都有原型涌进来。评审，成了新瓶颈。

“PRD已死”这个说法是对的，但只对了一半。死掉的是那条流水线：先写PRD，再做设计稿，再写代码。这个顺序没有意义了，因为原型可以几乎零成本生成。

但描述产品需求的文字依然不可或缺。原因很简单：当一个原型交出去评审时，评审者需要知道哪些设计是刻意为之，哪些是智能体随手加进去的。没有意图说明，评审就无法判断”这是否达到了目标”。

Chase提出了一个有意思的设想：也许未来的”PRD”就是那些用来生成原型的结构化Prompt——版本化的提示词，比文档更贴近实现，也更能传达构建者的意图。

跨职能沟通历来是最耗时的事。一个能同时理解产品、工程和设计的人，不需要等待传达，不需要翻译意图，可以直接和智能体对话完成闭环。

以前这类通才虽然价值高，但终究受制于时间——自己写代码的时间是有限的，还是得依赖团队。现在他们可以把大量实现工作交给智能体，专注在判断上。这让他们能产生的影响力比以往高出不止一个量级。

这听起来矛盾，但逻辑很清楚。如果你选择走专才路线——比如专注系统架构的高级工程师，或者专注用户洞察的资深PM——你的杠杆就是评审。而评审的速度要求很高，因为涌来的原型多了，你得快，还得准。

光是”技术过硬”不够了。你要同时具备：领域内顶尖的系统思维、快速评估他人工作的能力、清晰的沟通和反馈能力。这比以前的专才要求更高，而且这类角色在一个团队里也不需要那么多人。

Chase提出了一个两类角色的框架，但他说得比较克制，没有断言哪条路更好：

构建者（Builder）：懂产品思维，会用编程智能体，有基础设计感。在测试套件、组件库这类护栏约束下，能把小功能从想法推到上线。

评审者（Reviewer）：领域系统思维极强，能快速判断一个大型复杂功能在架构、产品和设计维度是否”足够好”。

对工程师来说，两条路都在眼前：往深做成顶尖系统思维的评审者，或者往宽做个能写代码的构建者。对产品和设计，也是类似的选择题。

有意思的是，Chase认为这两类角色的边界其实在模糊：工程师有了余力，可以多想产品和设计；产品和设计把代码加进了工具箱。职能分工在重新定义，但还没到消失的那一步。

Chase提到一篇关于”最适合用编程智能体的人”的推文走红，内容大意是：最能用好这波浪潮的，是那个对产品有直觉、同时懂技术可能性的人。

这条推文的有趣之处在于，产品经理、设计师、工程师、创始人都觉得说的是自己。Chase的观点是：他们可能都对。这类人可以从任何背景成长出来，这恰恰是”背景变得不那么重要”这个时代最令人兴奋的地方。

当实现成本趋近于零，判断力就变成了稀缺资源。PRD这张纸死了，但对”要构建什么、为什么构建、是否构建正确”的追问，比任何时候都更有价值。