编码 Agent 如何重塑工程、产品与设计

摘要

我最近读到 LangChain 联合创始人 Harrison Chase 的一篇长文,他系统剖析了编码 Agent(Coding Agents)如何从根本上改变软件公司中工程、产品和设计(EPD)三大职能的协作方式与角色定位。核心论点清晰而直接:当代码的生成成本趋近于零时,实现不再是瓶颈,审查(Review)才是;传统的 PRD 驱动的瀑布式流程已经死亡,但对产品需求的书面描述反而更加重要。这篇文章对任何在软件团队中工作的人------无论是工程师、PM 还是设计师------都有直接的参考价值。以下是我的整理。

正文

起点:EPD 的产出归根结底就是代码

作者开篇点明一个容易被忽视的事实:软件公司中 EPD(工程、产品、设计)的最终产出就是代码。角色各有不同,但终极目标是构建能解决业务问题、用户能使用的功能性软件。认识到"产出就是代码"这一点至关重要,因为编码 Agent 突然让代码变得非常容易编写------这将如何改变 EPD 的角色?

作者将影响分为两个维度:流程的变化角色的变化

流程变革:从 PRD 瀑布到原型驱动

PRD 已死

产品需求文档(PRD, Product Requirement Document)曾是 "Claude 时代之前" 构建软件的核心枢纽。传统 EPD 流程大致如下:

flowchart LR A["产品:提出想法"] --> B["产品:撰写 PRD"] B --> C["设计:基于 PRD
创建原型"] C --> D["工程:将原型
转化为代码"]

这不是一条铁律(在初创公司中这些步骤会混合在一起,优秀的构建者能同时兼顾多个环节),但它是教科书式的做法。

之所以需要这个流程,是因为构建软件需要大量时间和精力。于是催生了专业化分工,而分工之后就需要跨学科沟通------PRD 正是这种沟通的基础。它启动整个流程,瀑布式地流向设计(将文字变成界面和交互),再流向工程(将设计变为现实)。

编码 Agent 改变了这一切。编码 Agent 可以直接从一个想法生成功能性软件。当作者说"PRD 已死"时,真正的意思是:这种以撰写 PRD 为起点的传统软件构建方式已经终结了。

瓶颈从实现转移到审查

现在任何人都能写代码,意味着任何人都能构建东西。但这不意味着构建出来的东西架构良好、解决了正确的问题、或者易于使用。工程、产品和设计应该成为这些领域的审查者和仲裁者

"好"意味着三件事:

  • 架构良好(工程视角):可扩展、高性能、健壮
  • 产品思考到位(产品视角):是否解决了用户的真实痛点
  • 设计精良(设计视角):界面是否易用且直观
flowchart TD A["任何人用 Agent
快速生成原型"] --> B["原型作为审查焦点"] B --> C["工程审查
架构是否健壮?"] B --> D["产品审查
是否解决用户痛点?"] B --> E["设计审查
是否易用直观?"] C --> F["迭代至生产就绪"] D --> F E --> F

由于生成初始代码的成本极低,大量原型被创造出来,这些原型成为审查的焦点。但问题也随之而来------以前代码需要时间编写,审查者在任一时间点只需处理有限数量的项目。现在任何人都能写代码,在进行中的项目数量激增。作者观察到,三个职能中的瓶颈都已转移到审查环节------即确保原型真正"好"。

PRD 万岁

传统的 PRD 驱动流程(PRD → 原型 → 代码)虽然已死,但描述产品需求的文档仍然必不可少

假设有人有了一个想法并快速构建了原型,它如何进入生产?需要 EPD 其他成员审查。在审查过程中,书面文档始终有帮助且常常是必要的------当审查者审阅代码时,他们怎么知道某段代码是有意为之还是意外产物?这取决于意图的表达,而意图需要某种形式的沟通。

作者认为,与原型配套的需求描述文档应该是提交审查前的必备伴侣。最标准的格式仍然是文档,但也有一些有趣的新想法------比如分享用于创建功能的提示词(Prompts)作为需求沟通方式。

未来的 PRD 会不会就是结构化的、版本化的提示词?

角色变革:谁将在新世界中胜出

通才比以往任何时候都更有价值

作者所说的通才(Generalist)是指对产品、工程和设计三个领域都有良好感觉的人。这类人一直很有价值------但有了编码 Agent 之后更加如此。

原因在于沟通是一切中最难的部分 ,它会拖慢一切。一个能兼顾产品、设计和工程的人,会比一个三人团队更快------因为没有沟通开销。以前,当实现是瓶颈时,通才仍需与他人沟通来推进工作。现在他们只需与 Agent 沟通,这意味着单人的影响力可以比以往大得多

编码 Agent 是必选项

  • 工程师采用编码 Agent 后,可以将时间从实现转向系统思考(System Thinking)
  • 设计师采用编码 Agent 后,可以直接在代码中迭代,而非仅在 Figma 中
  • PM 采用编码 Agent 后,可以通过直接构建原型来验证想法,无需写规格说明然后等待

采用编码 Agent 是必选项------因为使用门槛并不高,如果你不用,你会被用的人替代。

好 PM 更好,差 PM 更差

好的产品思维(Product Thinking)比以往更有价值------你能构建出真正有用的东西。但差的产品思维也比以往更具破坏力

如果一个人有了糟糕的产品想法,他现在可以带着一个原型出现------但这个原型是一个无用或构思拙劣的功能。这些原型需要工程、产品和设计花时间审查,消耗资源。更糟糕的是,已经存在的原型会产生惯性("它都做出来了!合并进去吧!"),有可能让产品变得更差或更臃肿。

系统思维是需要磨炼的核心技能

在执行成本趋近于零的世界里,系统思维(System Thinking)成为真正的差异化能力。你应该专注于成为一个优秀的系统思考者,在你的领域中建立清晰的心智模型:

  • 工程:对如何架构服务、API 和数据库有非常好的心智模型
  • 产品:对用户真正需要什么(而非他们嘴上说的)有非常好的心智模型
  • 设计:对为什么某样东西看起来和用起来感觉对了有非常好的心智模型

系统思维一直很重要------变化在于,实现成本的大幅下降使得构建变得前所未有的容易,但这不意味着构建出来的东西是好的。优秀的系统思维让你在前期就确保构建正确的东西,也让你在事后能有效审查他人的工作。

每个人都需要产品感

编码 Agent 仍然需要有人提示它们做什么。如果你让它们构建错误的东西,你就是在制造更多需要他人审查的"废品"。知道让 Agent 构建什么(即"产品感" Product Sense)是一项基本要求,否则你会成为组织的拖累。这对工程、设计和产品角色同样适用。

EPD 的很大一部分工作现在是审查原型。如果你有产品感,审查会容易得多------你能以最少的规格说明理解功能意图,加速沟通、审查和交付。如果没有产品感,你就需要一份超详细的产品文档才能审查。

专业化的门槛更高了

你需要会使用编码 Agent,需要有产品感------各个角色正在融合。

角色之间一直有重叠。设计和产品长期关联密切------在 Apple 和 Airbnb 等公司,设计师兼任产品经理。"设计工程师"(Design Engineer)这个角色在 Vercel 等公司越来越流行。

但这并不意味着没有专业化的空间。一位只思考系统架构的资深工程师仍然有价值;一位没有学 Vibe Coding 但对客户问题和该构建什么有极清晰心智模型的 PM 也是如此;一位理解用户旅程和交互的设计师同样如此。

关键是:专业化的门槛大幅提高了。 你不仅要在自己的领域出类拔萃,还要在审查速度和沟通效率上做到极致。而且在任何一家公司里,这类角色可能并不需要太多。

你要么是构建者,要么是审查者

作者观察到 EPD 中正在涌现两种角色原型:

flowchart TD A["EPD 新角色分化"] A --> B["构建者 Builder"] A --> C["审查者 Reviewer"] B --> B1["良好的产品思维"] B --> B2["熟练使用编码 Agent"] B --> B3["基本设计直觉"] B --> B4["小功能:想法到生产
大功能:快速构建原型"] C --> C1["卓越的系统思维"] C --> C2["在特定领域深耕"] C --> C3["快速审查大量工作"]
  • 构建者:拥有良好的产品思维,能熟练使用编码 Agent,具备基本的设计直觉。在护栏(测试套件、组件库)的保护下,他们可以将小功能从想法推到生产,并为大功能构建功能性原型
  • 审查者:对大型复杂功能进行深度 EPD 审查。门槛很高------你必须是所在领域出色的系统思考者,同时还要有快速审查大量工作的节奏

如果你是工程师------你要么致力于精通系统设计成为审查者,要么提升产品和设计技能成为构建者。如果你在产品或设计岗位------你要么在自己的领域建立卓越的心智模型做审查者,要么投身编码 Agent 提升编码能力做构建者。

有趣的是,角色在某种程度上正在坍缩:工程师有了更多时间可以思考产品和设计,产品和设计则可以编写代码。

每个人都觉得自己的角色最受益------他们都对了

作者引用了一条热门推文,描述了最受编码 Agent 赋能的人的画像:对产品有直觉性的理解,知道哪里需要打磨、哪里已经出彩,以及如何迭代让产品更锐利。这类人中最稀有的版本同时兼具文化敏感度和深度技术理解------知道什么在技术上可行,也知道哪些文化潮流是真实的而非短暂的。

这条推文半病毒式传播,部分原因正是每个读到它的人都觉得说的是自己或自己的角色------产品人、设计师、设计工程师、创始人都在转发。

作者认为,他们可能都是对的。这个新世界里最令人兴奋的一点是:背景不再那么重要。这种理想人选可能来自产品、设计或工程中的任何一个。当然,这不意味着每个人都会成为这样的人------说起来总比做起来容易,真正的"独角兽"少之又少。

这是一个令人兴奋的构建时代 :)

关键术语对照

英文术语 中文翻译 说明
EPD 工程、产品与设计 Engineering, Product, and Design 三大职能的合称
PRD 产品需求文档 Product Requirement Document,传统软件开发的起点文档
Coding Agents 编码 Agent 能自主编写代码的 AI 智能体
System Thinking 系统思维 对领域内复杂系统的整体架构和运作方式的理解能力
Product Sense 产品感 对用户需求和产品方向的直觉判断力
Generalist 通才 兼具产品、工程、设计多领域能力的人
Builder 构建者 利用编码 Agent 从想法到原型/生产的全栈角色
Reviewer 审查者 对代码、产品和设计进行深度审查的专家角色
Vibe Coding 氛围编码 以自然语言驱动 AI 编写代码的新编程方式
Design Engineer 设计工程师 兼具设计和前端工程能力的复合角色
Prototype 原型 用编码 Agent 快速生成的功能性软件初版

参考资料

来源 摘要 链接
@signulll 描绘了最受编码 Agent 赋能的人的画像:兼具产品直觉和深度技术理解,知道什么在技术上可行、哪些文化潮流是真实的。 x.com/signulll/st...
相关推荐
掘金酱2 小时前
小册上新|玩🦐吗?ai 编程全栈指南了解一下?
前端·人工智能·ai编程
landuochong2002 小时前
SpecKit学习
人工智能·架构·claudecode
xu_ws2 小时前
Spring-ai项目-deepseek-6-哄哄模拟器
java·人工智能·spring
喵叔哟2 小时前
0.【.NET10 实战--孢子记账--产品智能化】--目录
人工智能·微服务·.net
萌兰三太子2 小时前
企业级 AI 智能体平台安全沙箱在 E2B 中的实现
人工智能·安全
sensen_kiss2 小时前
INT305 Coursework2 用卷积神经网络训练CIFAR-10数据集以进行图像识别
人工智能·神经网络·机器学习·cnn
一起来学吧3 小时前
【OpenClaw系列教程】第二篇:OpenClaw 是什么? 开源AI智能体平台
人工智能·ai·openclaw
qq_454245033 小时前
规则AI与大模型的认知互补:从游戏智能体到通用智能的边界探索
人工智能·游戏