原文：Harrison Chase, How Coding Agents Are Reshaping Engineering, Product and Design, LangChain Blog, 2026 年 3 月。以下为编译，保留原文结构与论点，部分段落做了压缩和意译。
软件公司里的 EPD——工程（Engineering）、产品（Product）、设计（Design）——存在的目的只有一个：造出能用的软件。角色分得再细，最终交付物也只是代码。
认清这一点很重要，因为 Coding Agents 突然让写代码变得极其廉价。那么，EPD 的角色会怎么变？
PRDs 已死
在 Coding Agent 出现之前，PRD（产品需求文档）是软件开发的起点。标准流程是一条清晰的瀑布：
- 有人（通常是 PM）冒出一个想法
- PM 写 PRD
- 设计师根据 PRD 画 Mock
- 工程师把 Mock 变成代码
这不是铁律——创业公司里这些步骤经常混在一起，最好的 Builder 能一个人跨好几个环节。但之所以还有这条「标准流程」，是因为写软件和画 Mock 都需要大量时间。于是产生了专业分工，也产生了跨分工沟通的需求。PRD 就是这个沟通的起点，一切从这里瀑布到设计，再瀑布到工程。
Coding Agents 改变了这一切。它们可以把一个想法直接变成能跑的软件。所以当我（和其他人）说「PRDs 已死」，真正的意思是：这种以写 PRD 为起点的传统软件开发方式已死。
瓶颈从实现转向审查
任何人现在都能写代码，也就意味着任何人都能做东西。但这不代表做出来的东西架构良好，不代表解决了正确的问题，也不代表好用。
工程、产品和设计应该成为这些维度的审查者和仲裁者。生成的代码并不总是「好的」，EPD 的角色变成了审查并确保它是「好的」。「好的」意味着：
- 工程视角：架构是否可扩展、高性能、健壮？
- 产品视角：是否真正解决了用户痛点？
- 设计视角：界面是否易用、直观？
由于生成初版代码的成本极低，原型数量大幅增加。这些原型成为焦点，EPD 围着它们审查。
问题在于——生成代码太容易了。以前写代码需要时间，审查者桌上同时摆的项目有限。现在任何人都能写代码，在做的项目数量在膨胀。我们在三个职能中看到的瓶颈都是同一个：审查——拿着原型，确保它们是「好的」。
PRDs 万岁
以写 PRD 为起点的旧流程死了，但描述产品需求的文档依然必不可少。
假设有人冒出一个想法，快速生成了一个原型。这个原型怎么进生产？它需要 EPD 其他成员审查。审查时，一份书面文档总是有帮助的，甚至是必需的——别人看代码时，怎么知道某段代码是手误还是有意为之？这取决于意图，而意图需要被传达。
所以，传统的 PRD → Mock → Code 流程已死，但描述产品需求的文本活得好好的。这份文档应该在原型交出去审查之前就准备好。
Chase 抛出一个有趣的问题：未来的 PRD 会不会就是结构化的、版本化的 Prompt？
全才比以往更有价值
Chase 说的「全才」，是指对产品、工程和设计三者都有良好感觉的人。这类人一直很有价值——但有了 Coding Agents，他们的价值被放大了。
原因很简单：沟通是一切中最难的部分，它拖慢所有事情。一个能同时做产品、设计和工程的人，会比一个三人团队更快，因为沟通开销更少。
以前，即使是这样的全才，实现仍然是瓶颈，他们还是得跟别人协作才能把东西做出来。现在他们可以直接跟 Agent 协作。这意味着一个人能比以往任何时候都更有影响力。
Coding Agents 是必备技能
Coding Agents 让实现变得廉价，使用它们就成了必修课。能用 Agent 的人可以自己做更多事：
- PM 可以直接构建原型来验证想法，不用写 Spec 然后干等
- 设计师 可以在代码里迭代，不只在 Figma 里画
- 工程师 可以把时间从实现转移到系统思考
用 Coding Agents 不难，但如果你不用，你会被用的人替代。
好 PM 更稀缺，坏 PM 更危险
好的产品思维比以往更有价值——你能做出真正有用的东西。坏的产品思维比以往更有害。
如果一个人有糟糕的产品想法，他现在可以带着一个原型出现——但那个原型是一个无用的、构思拙劣的功能。这些原型需要工程、产品和设计花时间审查，消耗资源。而且把它们推进生产的惯性更大了——「它已经写好了！直接合并吧！」这会让产品变得更差或更臃肿。
系统思考成为核心区分技能
在一个执行廉价的世界里，系统思考成为区分因素。你应该专注于真正擅长系统思考，并对你所在领域建立清晰的心智模型：
- 工程：如何架构服务、API 和数据库
- 产品：用户真正需要什么（而不是他们嘴上说想要什么）
- 设计：为什么某些东西看起来和用起来就是「对」的
系统思考一直很重要——那什么变了？实现成本大幅下降。实现某个东西比以往任何时候都容易，但这不代表它是好的。好的系统思考让你能在动手之前就确保方向正确，也让你在事后审查别人的工作时更有判断力。两者都意味着，系统思考的重要性提高了。
每个人都需要产品感
Coding Agents 仍然需要有人来 Prompt 它们，告诉它们做什么。如果你让它们构建错误的东西，你就是在给别人制造更多需要审查的垃圾。知道该让 Agent 构建什么——也就是「产品感」——是必需的，否则你会成为组织的拖累。这对工程、设计和产品都成立。
EPD 的大部分工作现在是审查原型。有产品感的人审查更快，即使审查的是设计或工程。没有产品感的人，需要一份超详细的产品文档才能理解原型的意图。有产品感的人，用最简的 Spec 就能理解功能意图，加速沟通、审查和交付。
专业化的门槛更高了
你需要会用 Coding Agents，需要有产品感。所有角色都在融合。
角色之间一直有重叠。设计和产品早就紧密相连——在 Apple 和 Airbnb，设计师就是产品经理。「设计工程师」这个角色在 Vercel 等公司越来越流行。
但这不意味着没有专业化的空间。一个只思考系统架构的资深工程师仍然有价值；一个没学过 Vibe Coding 但对用户问题有极清晰心智模型的 PM 也是；一个还在 Figma 里工作但能精准把握用户旅程和交互的设计师同样如此。
只是专业化的门槛高了很多。你不仅要在自己的领域出类拔萃，还要审查速度快、沟通能力强。而且这类角色在任何一家公司里都不会太多。
你要么是 Builder，要么是 Reviewer
Chase 看到 EPD 中出现了两种角色分化。
Builder：从想法到原型。 这类人有良好的产品思维，会用 Coding Agents，有基本的设计直觉。在有 guardrails（测试套件、组件库）的环境下，他们可以把小功能从想法带到生产，也可以为更大的功能做出可用的原型。
Reviewer：从原型到生产。 大型复杂功能需要深入的 EPD 审查。门槛很高——你必须是你所在领域出色的系统思考者，而且要快，因为有大量的东西等着你审。
如果你是工程师——要么瞄准成为出色的系统设计者，专注审查架构，走 Reviewer 路线；要么培养产品和设计能力，走 Builder 路线。
如果你在产品或设计——要么对产品/设计有极好的心智模型，以 Review 为主；要么跳进 Coding Agents，提升编码能力，成为 Builder。
有趣的是，角色正在融合。所有 EPD 成员都在 Builder-Reviewer 这条光谱上的某个位置。工程师有了更多时间，可以更多地思考产品和设计；产品和设计则可以直接写代码。
每个人都觉得自己最受 Coding Agents 青睐——而他们是对的
Chase 引用了 X 上一条半病毒式传播的帖子，关于最受 Coding Agents 青睐的人：
那些对产品有直觉把握的人——知道它哪里是软肋，哪里是亮点，以及如何迭代让它更锐利。
这种人最稀有的版本，站在文化与深度技术的交汇处。真正的「双语者」。他们知道什么在技术上是可能的，也知道哪些文化潮流是真实的、哪些转瞬即逝。这种组合，才是区分「感觉命中注定」的产品与「感觉东拼西凑」的产品的东西。
这条帖子之所以传播，部分原因是每个读到它的人都觉得说的是自己。Chase 看到 PM 在引用它，设计师在引用它，设计工程师在引用它，创始人也在引用它。每个人都觉得它适用于自己的角色。
而他们很可能都是对的。
Chase 真心相信在这个新世界里，背景不那么重要了。这种理想中的人可以来自产品、设计或工程。当然，这不意味着每个人都会成为这种人——说起来容易做起来难。真正的独角兽很少。
这是一个令人兴奋的建设时代。
我的看法
我每天都在用 Coding Agent 写代码——这篇文章所在的博客，从写作流程到配图生成到发布脚本，全部由 Agent 协助完成。所以 Chase 说的那些变化，对我来说不是预测，是日常。
但我想补充一点 Chase 没有展开的东西：Agent 放大的不只是能力，还有品味。
一个有品味的人用 Agent，产出的是精准的原型；一个没品味的人用 Agent，产出的是精致的垃圾。工具越强大，品味的杠杆越大。这跟摄影很像——iPhone 让每个人都能拍照，但好照片和坏照片的差距反而比胶片时代更大了，因为技术门槛消失后，审美成了唯一的变量。
Chase 把未来分成 Builder 和 Reviewer 两条路。我的体感是，最舒服的状态其实是在两者之间快速切换——花二十分钟用 Agent 搭一个原型，然后花两个小时审自己刚写的东西，砍掉一半，重构另一半。最好的 Reviewer 就是五分钟前还在 Build 的那个人，因为他知道意图。
最后一点：Chase 说「Coding Agents 是必备技能」，我同意，但我想加一个限定——会用 Agent 是入场券，会拒绝 Agent 的输出才是真本事。 Agent 生成的代码有一种诱惑力，因为它「已经存在了」，删掉它需要勇气。而软件工程里最被低估的能力，从来都是知道什么不该做。
- FIN -