关于作者：Harrison Chase，LangChain 联合创始人兼 CEO，长期专注 AI Agent、上下文工程、LLM 应用架构与 MLOps。
原文链接：x.com/hwchase17/s…
导语：代码智能体大幅降低代码编写成本，彻底重塑软件行业 EPD（工程、产品、设计）工作模式：传统 PRD 先行的瀑布式流程终结，工作瓶颈从开发实现转向审核校验；EPD 角色分化为构建者与审核者，通才价值凸显，产品思维成全员必备，专业人才门槛大幅提升；掌握代码智能体成为职场必需，其核心价值在于让从业者聚焦 “做什么” 和 “做得好不好” 的核心判断，而非基础编码工作。
软件公司的工程、产品与设计团队（EPD）的核心工作是打造优质软件。团队内部分工明确，但最终目标都是开发出能解决业务问题、可供用户使用的功能性软件。归根结底，这一切的成果最终都会落地为代码。我们必须认清一个事实：EPD 团队的工作产出本质上就是代码，而代码智能体的出现，让代码编写变得前所未有的轻松。那么，这一变化会如何重塑 EPD 各角色的定位与工作模式？
行业变革的核心趋势
- 传统产品需求文档已成过去式
- 工作瓶颈从开发落地转向审核校验
- 产品需求文档的核心价值依然存续
- 通才的价值迎来前所未有的提升
- 掌握代码智能体成为必备能力
- 优秀产品经理的价值被放大，能力不足的产品经理则会造成更大内耗
- 产品思维成为全员必备素养
- 专业人才的能力门槛大幅提高
- 职场角色逐渐分化为 “构建者” 与 “审核者”
- 每个岗位都能从代码智能体中获得专属优势，这一认知是完全正确的
传统产品需求文档已成过去式
在 Claude 诞生前的时代，产品需求文档（PRD）是软件开发工作的核心抓手，彼时的 EPD 工作流程基本遵循固定范式：
- 有人（通常是产品人员）产生一个产品想法
- 产品团队撰写产品需求文档
- 设计团队依据文档制作产品原型
- 研发团队将原型开发为实际代码
这并非铁律（创业公司中这些环节往往相互融合，优秀的从业者能同时胜任多个环节的工作），但却是行业内标准化的开发流程。
这种流程的存在有其必然性：过去，开发软件和制作原型需要投入大量的时间与精力，因此行业中逐渐形成了各有专攻的职能分工。而随着专业化程度的提升，跨职能的沟通需求应运而生，产品需求文档则成为了跨部门沟通的基础，是整个开发流程的起点。后续工作会按瀑布式推进：设计团队将文字描述转化为美观的用户界面和流畅的用户体验，研发团队再将设计落地为实际可用的产品。
而代码智能体的出现，彻底颠覆了这一模式。它能直接将一个产品想法转化为可运行的功能性软件。我们所说的 “传统 PRD 已成过去式”，本质上是指这种以撰写 PRD 为起点的传统软件开发模式，已经不再适用。
工作瓶颈从开发落地转向审核校验
如今，任何人都能编写代码，也就意味着任何人都能参与产品搭建，但这并不代表所有搭建出的产品，都具备合理的架构、能真正解决问题，或是拥有良好的易用性。而 EPD 团队的核心职责，就转变为对这些产品的上述维度进行审核与评判。
问题的关键在于，智能体生成的代码并非总能达到 “优质” 标准，因此 EPD 团队的工作重心也变为审核代码、确保最终产出的质量。这里的 “优质” 包含多重维度：
- 从工程架构角度，代码是否具备可扩展性、高性能与高健壮性？
- 从产品设计角度，产品是否真正解决了用户的痛点？
- 从交互设计角度，产品界面是否简洁直观、易于使用？
由于制作初代代码版本的成本大幅降低，市面上出现了大量的产品原型，而这些原型也成为了 EPD 团队共同审核的核心对象。
当下的核心问题是，代码生成的门槛过低。在过去，开发代码需要耗费大量时间，因此审核人员手头的待审核项目数量始终有限；但现在，任何人都能编写代码，导致同时推进的项目数量大幅增加。我们发现，工程、产品、设计三大职能的工作瓶颈，都已转移至 “审核” 环节 —— 即对原型进行校验，确保其达到可用标准。
产品需求文档的核心价值依然存续
以撰写 PRD 为起点的传统软件开发模式已然落幕，但用于描述产品需求的文档，其价值依然不可或缺。
试想这样的场景：有人产生一个想法后，快速搭建出了产品原型，那么这个原型要如何落地投产？答案是必须经过 EPD 团队其他成员的审核。而在这一过程中，书面的需求文档往往能起到关键作用，甚至是必不可少的。当审核人员查看原型时，如何判断某段代码的存在是刻意设计还是偶然生成？这一切都取决于产品的设计初衷，而这份初衷，需要通过文档进行清晰传递。
我认为，PRD→原型→代码的传统流程已经消亡，但用于描述产品需求的文本内容，生命力依旧旺盛。在原型提交审核前，配套的需求说明文档必须成为必备材料。
这类文档的标准形式仍是书面文件，但行业中也出现了一些新颖的思路：比如将生成产品功能时使用的提示词作为沟通载体。未来的产品需求文档，是否会演变为结构化、可版本化的提示词？这值得思考。
通才的价值迎来前所未有的提升
这里所说的通才，指的是同时具备产品、工程、设计三大领域核心认知的从业者。这类人才一直以来都极具价值和影响力，而在代码智能体的时代，他们的价值被进一步放大，原因何在？
沟通是所有工作中最难的环节，它会大幅拖慢工作推进的效率。一个能同时胜任产品、设计、研发工作的通才，其工作效率远高于一个由三人组成的专业团队，核心原因就是省去了跨角色的沟通成本。
在过去，开发落地是工作的主要障碍，即便是通才，也需要与他人沟通协作才能推进工作；但现在，通才只需与代码智能体协作即可完成工作，这意味着单一个体的影响力，能达到前所未有的高度。
掌握代码智能体成为必备能力
代码智能体让开发落地的成本大幅降低，掌握这一工具也因此成为行业必备能力。能熟练运用代码智能体的从业者，能凭借一己之力完成更多工作：
- 产品经理可直接通过搭建原型验证想法，无需撰写需求规格文档后苦苦等待；
- 设计师可在代码层面进行产品迭代，而非仅局限于 Figma 等设计工具；
- 研发工程师可将工作时间从基础开发，转移至系统架构设计等更具深度的思考上。
掌握代码智能体之所以成为必备能力，是因为其学习门槛并不高，而如果不愿掌握这一工具，最终必然会被掌握它的人取代。
优秀产品经理的价值被放大，能力不足的产品经理则会造成更大内耗
优质的产品思维，其价值在当下达到了新高度 —— 凭借它能打造出真正有价值的产品；而糟糕的产品思维，造成的资源浪费也会远超以往。如果一个产品经理提出了糟糕的产品想法，甚至能快速做出对应的原型，但这个原型对应的功能，要么毫无用处，要么设计拙劣。
这类问题原型会需要工程、产品、设计团队投入更多精力审核，大幅占用团队的时间和资源；同时，将其落地投产的惯性也会更大（比如有人会说 “原型都已经做出来了，直接合并上线就好”），最终可能导致产品体验变差、功能臃肿。
系统思维成为核心必备技能
在开发落地成本极低的时代，系统思维成为了区分从业者能力的核心标准。每个人都应专注于打磨自己的系统思维，建立对所在领域清晰的心智模型：
- 研发工程师：对服务、接口、数据库的架构设计，拥有清晰的心智模型；
- 产品经理：能精准洞察用户的真实需求，而非被用户的表面表述所误导；
- 设计师：能理解设计背后的逻辑，知晓为何某类设计能带来良好的视觉感受和使用体验。
系统思维一直以来都至关重要，那么如今发生了什么变化？核心是开发落地的成本大幅降低，这意味着实现一个想法变得前所未有的容易，但 “容易实现” 并不等同于 “实现得好”。
拥有优秀的系统思维，能让从业者在工作初期就确定正确的开发方向，也能在后期更高效地审核他人的工作成果。这两点，让系统思维的重要性被无限放大。
产品思维成为全员必备素养
代码智能体仍需要人来下达指令，告诉它该做什么。如果向它下达了错误的开发指令，最终只会产生更多需要他人审核的低质量产物。因此，知道该让智能体开发什么功能，也就是具备 “产品思维”，成为了全员必备能力，否则就会成为团队的拖油瓶。这一点，对工程、设计团队适用，对产品团队而言更是理所当然。
如今 EPD 团队的核心工作之一是审核原型，而具备产品思维能让审核工作变得更高效，即便是审核设计或工程相关的内容也是如此。如果缺乏产品思维，就需要为原型配套极其详尽的产品文档；而具备产品思维的人，只需简单的规格说明就能理解功能的设计初衷，大幅加快沟通、审核和交付的效率。
专业人才的能力门槛大幅提高
当下的从业者，不仅需要掌握代码智能体的使用方法、具备产品思维，各岗位的工作内容也在相互融合。
其实岗位间的重叠一直存在：设计与产品的关联由来已久，在苹果、爱彼迎等公司，设计师甚至会承担产品经理的工作；而 “设计工程师” 这一岗位，也在维尔塞等公司逐渐兴起。
这并不意味着专业人才失去了发展空间：一位深耕系统架构的资深研发工程师，依然具备极高的价值；即便不擅长通过代码落地产品，但能精准洞察客户问题、明确产品开发方向的产品经理，同样不可或缺；哪怕仍在 Figma 中进行设计，但能精准理解并制作用户旅程和交互原型的设计师，也依旧是团队的核心力量。
但专业人才的能力门槛确实大幅提高了：从业者不仅要在所属领域做到顶尖，还必须拥有极高的审核效率和出色的沟通能力。而在任何一家公司，能达到这一标准的专业人才，数量都寥寥无几。
职场角色逐渐分化为 “构建者” 与 “审核者”
我们发现，EPD 团队的岗位角色正逐渐分化为两大类型：
- 第一类是构建者。这类从业者具备优秀的产品思维，能熟练使用代码智能体，且拥有基础的设计直觉。在测试套件、组件库等工具的辅助下，他们能将小型功能从想法直接落地投产，也能为大型功能搭建出可运行的原型。
- 第二类是审核者。对于大型、复杂的产品功能，需要 EPD 团队进行详尽的审核，而这一岗位的能力门槛极高 —— 从业者必须是所属领域的顶尖系统思维者，同时还要具备高效的工作节奏，因为待审核的内容数量极为庞大。
如果你是一名研发工程师，未来的发展方向有两个：要么深耕系统设计，熟练审核各类架构方案，成为一名审核者；要么培养自己的产品和设计能力，转型为构建者。
如果你从事产品或设计工作，要么打造出对产品 / 设计领域的极致心智模型，专注于审核工作；要么熟练运用代码智能体，提升自己的代码能力，成为构建者。
有趣的是，各岗位的边界正逐渐模糊，EPD 团队的所有从业者，都能在 “构建者 - 审核者” 的维度中找到自己的定位：岗位间的融合成为趋势，研发工程师有了更多时间，能深入思考产品和设计问题；产品和设计人员，也能亲自编写代码、落地想法。
每个岗位都能从代码智能体中获得专属优势，这一认知是完全正确的
Twitter 上曾有一篇优质帖子，探讨了哪类人群能从代码智能体中获得最大优势，核心观点如下：
真正能把握时代机遇的，是那些能直观理解现有产品的人 —— 他们清楚产品的短板在哪、亮点何在，也知道该如何迭代优化，让产品变得更出色。
而这类人群中最稀缺的，是那些兼具文化洞察力和深厚技术功底的人，他们是真正的 “双语者”：既懂技术实现的边界，又能分辨哪些文化趋势是真实的长期趋势，哪些只是短暂的潮流。正是这种复合能力，让他们打造的产品浑然天成、深入人心，而不是简单拼接、毫无灵魂。
这篇帖子精准概括了代码智能体时代的行业现状，也在社交平台上小范围走红。它能走红的原因之一，就是每个读到它的人，都觉得这说的是自己或自己的岗位 —— 产品人、设计师、设计工程师、创始人…… 所有人都认为，这篇帖子描述的特质与自己的工作高度契合。
而他们的想法，大概率都是正确的！我认为，代码智能体时代最令人振奋的一点，就是从业者的专业背景变得不再重要。我坚信，上述这种稀缺的复合型人才，可能来自产品、设计或工程等任何一个领域。
当然，这并不意味着所有人都能成为这样的人才 —— 说起来容易，做起来却难上加难，真正的全能型人才本就寥寥无几。
当下，正是投身产品搭建的黄金时代。
