转载说明：本文译自 LangChain 博客文章《How Coding Agents Are Reshaping Engineering, Product and Design》。作者：Harrison Chase。原发布方：LangChain。原文发布日期：2026-03-10。原文地址：https://blog.langchain.com/how-coding-agents-are-reshaping-engineering-product-and-design/。Coding Agent 如何重塑工程、产品与设计 作者：Harrison Chase 在软件公司里，EPD（Engineering、Product、Design）的职责，是做出好的软件。岗位分工虽然存在，但最终目标都是交付能够解决业务问题、并且真的会被用户使用的功能软件。归根结底，这一切产出的都是代码。之所以必须先承认这一点，是因为 Coding Agent 突然让“写代码”这件事变得非常容易。那么，这会怎样改变 EPD 的角色？ 变化正在这样发生：PRD 已死瓶颈从实现转向 reviewPRD 万岁 对角色的影响：通才型人才会比以往更有价值会使用 Coding Agent 已经是硬性要求好 PM 会变得更强，差 PM 会变得更糟人人都需要 product sense专业分工存在的门槛会更高你要么是 Builder，要么是 Reviewer每个人都觉得自己的角色最能受益于 Coding Agent，而且他们都没错PRD 已死 在 pre-Claude 时代，PRD（Product Requirement Document，产品需求文档）是软件构建流程的中心。当时的 EPD 流程大致是：某个人，通常是产品，先有一个想法产品写 PRD设计拿着 PRD 做出 mock工程把 mock 变成代码 传统的“想法到代码”流程图 这并不是一条绝对铁律。在创业公司里，这几个步骤经常会混在一起，最强的 builder 往往也能同时完成其中多个环节。但它一直是教科书式的软件构建流程。 之所以必须这样做，是因为过去无论是把软件做出来，还是把设计稿做出来，都需要投入相当多的时间和精力。于是，不同学科开始围绕这些高成本环节形成分工。随着分工越来越细，不同角色之间就必须沟通。PRD 于是成了整个流程的起点，后续再瀑布式地流向设计，设计把文字变成漂亮的 UI 和顺滑的 UX，工程再把它真正落地。 Coding Agent 改变了这一切。Coding Agent 可以直接把一个想法变成功能可用的软件。当我，和其他人，说“PRD 已死”时，我们真正想表达的是：这种从写 PRD 开始的软件构建方式，已经死了。瓶颈从实现转向 review 现在，任何人都能写代码，这也意味着任何人都能做东西。但这并不意味着他们做出来的东西就架构合理、问题定义正确、或者足够好用。工程、产品和设计应该分别成为这些维度的评审者与裁决者。问题在于，生成出来的代码并不总是“足够好”。于是，EPD 的职责开始转向 review，确保它真的“足够好”。这里的 “great” 至少包括：从工程系统的角度看，架构是否可扩展、性能是否足够、实现是否鲁棒从产品角度看，它是否真正解决了用户痛点从设计角度看，界面和交互是否直观、易学、好用 由于做出第一版代码的成本已经非常低，我们会看到越来越多原型被快速生产出来。这些原型随后会成为讨论与评审的中心，由产品、工程和设计围绕它们展开 review。 实现成本下降后，review 成为新的瓶颈 问题就在于，生成代码变得太容易了。以前，做出代码本身需要很长时间，所以作为 reviewer，在任何时刻摆到你桌上的项目数量总是有限的。现在则不同了，任何人都能写代码，这意味着同时在推进的项目数会不断增加。我们已经看到，三个职能共同的瓶颈都变成了 review：把这些原型接过来，再确认它们是否真的“够好”。PRD 万岁 那个从 PRD 起步的 pre-Claude 软件构建时代已经过去了。但描述产品需求的文档依然是必要的。 假设某个人有了一个点子，并很快做出了一个原型。那它要怎么进入生产环境？它仍然需要被 EPD 的其他成员 review。在这个过程中，一份书面文档永远会有帮助，而且通常是必要的。别人 review 的时候，怎么知道代码里某一部分究竟是偶然出现，还是有意为之？这取决于最初的意图。而意图必须通过某种方式传达出来。 我认为，传统的 PRD 流程，也就是 PRD -> mock -> code，已经死了。但描述产品需求的文字并没有死。相反，它应该成为原型在交给别人 review 之前的必备配套文档。 最常见的形式当然仍然是一份文档，但也有一些很有意思的想法，比如把生成这个功能时使用的 prompt…