编程智能体如何重塑工程、产品与设计 [译]

原文：How Coding Agents Are Reshaping Engineering, Product and Design · LangChain Blog

引言：这篇文章最有价值的地方，不是单纯强调「AI 会让写代码更快」，而是进一步指出，当实现变得越来越便宜之后，团队真正的瓶颈会从开发转向评审、判断与系统性思考。

它提供了一个很清晰的观察框架：传统的 流程正在松动，产品、设计、工程这三个角色之间的边界也会被重新定义。未来更有价Agent 智能体值的人，往往不是某一个环节里的执行者，而是既能借助编程智能体快速产出，又能站在更高层面做取舍与审查的人。

如果你最近也在思考 AI Coding 会怎样改变团队协作方式，这篇文章很值得读。

在软件公司，工程、产品与设计（合称 EPD）的核心任务就是打造优秀的软件。虽然角色分工不同，但终极目标是一致的：交付能解决业务问题且好用的功能性软件。说到底，这些产物最后都要落到代码上。

我们要意识到，EPD 团队的所有产出本质上就是代码。而现在，编程智能体（Coding Agents）的出现让写代码变得异常简单。那么，EPD 的角色将发生怎样的转变？

• PRD 模式宣告终结
• 开发不再是瓶颈，评审才是
• 需求文档以新形态重生

• 全能型通才比以往任何时候都更具价值
• 掌握编程智能体是生存底线
• 优秀的产品经理会变得卓越，而平庸的则会变成灾难
• 每个人都需要具备产品感
• 专业化的门槛显著提高
• 你要么是开发者，要么是评审者
• 每个人都认为自己的岗位获益最多，事实也确实如此

在 Claude 时代之前，PRD（产品需求文档）是软件开发的轴心。当时的流程通常是：产品经理产生想法并撰写文档，设计师根据文档画出原型，工程师最后将其转化为代码。

这虽然不是死板的教条，但在当时是主流。之所以需要这种流程，是因为以前构建软件和制作原型的成本极高。为了提高效率，必须进行细分专业化，但也因此产生了跨部门沟通的需求，PRD 便是这种沟通的基石。随后，项目像瀑布一样流向设计，将文字转化为 UI 和 UX，最后由工程团队变为现实。

编程智能体打破了这个循环。AI 可以直接根据想法生成可运行的软件。当我们说 PRD 已死，指的是那种从撰写长篇文档开始的传统开发模式已经过时了。

现在任何人都能写代码，这意味着任何人都能构建产品。但这并不代表写出来的东西架构合理、能解决正确的问题或足够好用。工程师、产品经理和设计师的角色正在演变为评审者和仲裁者。

问题在于，AI 生成的代码未必完美。EPD 的职责转变为通过评审确保产出达到卓越标准。这里的卓越包含多重含义：

• 工程维度： 系统架构是否稳健，是否具备可扩展性和高性能？
• 产品维度： 是否深思熟虑，真正解决了用户的痛点？
• 设计维度： 交互界面是否简单直观？

由于制作初版代码的成本极低，我们会看到大量原型涌现。这些原型成为团队协作的新重心，由各方共同评审。

由于生成代码变得太容易，新的挑战也随之而来。以前写代码很慢，评审者的工作量相对可控。而现在，项目数量呈爆炸式增长，评审反而成了所有职能部门的共同瓶颈。

虽然传统的 PRD 开发模式消失了，但描述产品需求的文字依然不可或缺。

假设有人产生了一个想法，并迅速用 AI 搞出了原型。如何将其推向正式生产？它依然需要经过 EPD 团队的评审。在这个过程中，书面说明不仅有帮助，甚至是必须的。评审者需要知道某段代码是刻意为之，还是 AI 产生的错误，这取决于开发者的初衷。因此，传达这种开发意图是必不可少的。

我认为，传统的先写文档、再画原型、最后写代码的流程已经结束，但描述需求的文字生命力旺盛。在提交评审时，这份文档应该是原型的必要配套。未来，PRD 甚至可能演变为一种结构化、带版本控制的提示词。

这里说的通才，是指对产品、工程和设计都有敏锐感觉的人。这类人一直很稀缺，而在编程智能体的加持下，他们的影响力还会被进一步放大。

沟通是软件开发中最大的损耗。一个能同时处理产品、设计和工程的人，其推进速度会远远超过一个三人的小团队，因为他几乎消除了沟通成本。过去，开发者受困于繁琐的实现细节，现在他们可以直接与 AI 智能体交流。这意味着个人能产生的影响力，达到了前所未有的高度。

当 AI 让开发成本大幅下降时，学会使用它们就成了一项生存技能。能拥抱 AI 的人将具备极强的独立作战能力：

• 产品经理： 可以直接通过原型验证想法，无需写完文档后再苦苦等待。
• 设计师： 可以在代码中直接迭代效果，而不仅是在 Figma 里画图。
• 工程师： 可以将精力从重复的编码转向更深层的系统思考。

如果不去掌握这些工具，很快就会被学会使用它们的人取代。

优秀的产品思维现在更值钱，因为你能更迅速地做出有用的东西。而糟糕的产品思维则会造成巨大的浪费。

如果一个产品想法很烂，虽然能很快做出原型，但这只是在制造垃圾。这些低质量原型会占用更多的评审资源，榨干团队精力。而且，由于东西已经做出来了，团队往往会有直接上线的冲动，这会给产品带来臃肿和变质的风险。

在一个执行力变得廉价的世界里，系统性思维成了拉开差距的关键。你应当专注于提升这种能力，并对自己的领域建立清晰的认知模型：

• 工程： 懂如何架构服务、API 和数据库。
• 产品： 洞察用户的真实需求，而非盲从他们的口头要求。
• 设计： 理解为什么某种设计在体验上是正确且舒适的。

实现一个功能很容易，但要实现得对、实现得好，全靠系统性思维。它能确保你从一开始就在构建正确的东西，也能让你在事后精准地评审他人的工作。

AI 智能体仍需要人类去引导。如果你指挥它们造出了错误的东西，你就是在给评审人员制造负担。无论你身处哪个岗位，知道该让 AI 构建什么，也就是具备产品感，已经成为基本要求。

现在的 EPD 工作有很大一部分是评审原型。具备产品感的人，即使在文档简略的情况下，也能快速理解功能意图，从而加速整体的交付进程。

你需要会用 AI，需要有产品感，所有角色的界限正在模糊。

这种角色重叠一直存在。在 Apple 或 Airbnb，设计师往往兼任产品经理。而像设计工程师这样的职位，在 Vercel 等公司正备受推崇。

这并不代表专家不再重要。一位深耕系统架构的高级工程师，或是一位对客户痛点有精准洞察的产品经理，依然极具价值。但现在的门槛变了：你不仅要在专业领域顶尖，还必须具备极快的评审速度和卓越的沟通能力。

在 EPD 领域，两类角色正在显现：

1. 开发者（Builder）： 这类人具备良好的产品思维，能熟练操作 AI 智能体，并有基础的设计直觉。在既有的技术框架下，他们能独立完成从想法到上线的闭环。
2. 评审者（Reviewer）： 面对复杂功能，需要深度的专家把关。这要求你必须是该领域顶尖的系统思考者，并能保持极高的评审效率。

如果你是工程师，要么往架构和评审方向深造，要么提升产品和设计能力，成为全能开发者。如果你是产品或设计师，要么建立起顶尖的认知模型进行评审，要么全身心投入 AI 学习，提升自己的代码实战能力。

最近社交媒体上有一段话很火，描述了最能从 AI 中获益的人：

他们对现有产品有直觉般的把握，知道哪里不够完美，并知道如何将其迭代得更加犀利。这类人处于文化与技术的交汇处，是真正的双语者。他们既懂技术的边界，又懂哪些趋势是真实存在的。这种组合，区分了那些“感觉必然会成功”的产品与那些“拼凑出来”的产品。

每个人都觉得这段话在说自己，这正是最令人兴奋的地方。在这个新世界里，职业背景不再是决定性的障碍。这种复合型人才可能来自任何领域。虽然真正的独角兽依然罕见，但对于所有构建者来说，这都是一个充满机遇的时代。

这篇文章最值得记住的一点，也许不是「AI 会让开发更快」，而是当实现变得越来越便宜之后，真正稀缺的能力会转向判断、评审、协作与系统性思考。

对工程师来说，这意味着要么成为能驾驭智能体的 Builder，要么成为能把关复杂系统的 Reviewer。对产品和设计来说也是一样。角色不会消失，但角色的重心正在改变。