摘要
我最近读到 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<br/>创建原型"]
C --> D["工程：将原型<br/>转化为代码"]
这不是一条铁律（在初创公司中这些步骤会混合在一起，优秀的构建者能同时兼顾多个环节），但它是教科书式的做法。
之所以需要这个流程，是因为构建软件需要大量时间和精力。于是催生了专业化分工，而分工之后就需要跨学科沟通——PRD 正是这种沟通的基础。它启动整个流程，瀑布式地流向设计（将文字变成界面和交互），再流向工程（将设计变为现实）。
编码 Agent 改变了这一切。编码 Agent 可以直接从一个想法生成功能性软件。当作者说"PRD 已死"时，真正的意思是：这种以撰写 PRD 为起点的传统软件构建方式已经终结了。
瓶颈从实现转移到审查
现在任何人都能写代码，意味着任何人都能构建东西。但这不意味着构建出来的东西架构良好、解决了正确的问题、或者易于使用。工程、产品和设计应该成为这些领域的审查者和仲裁者。
"好"意味着三件事：
- 架构良好（工程视角）：可扩展、高性能、健壮
- 产品思考到位（产品视角）：是否解决了用户的真实痛点
- 设计精良（设计视角）：界面是否易用且直观
flowchart TD
A["任何人用 Agent<br/>快速生成原型"] --> B["原型作为审查焦点"]
B --> C["工程审查<br/>架构是否健壮？"]
B --> D["产品审查<br/>是否解决用户痛点？"]
B --> E["设计审查<br/>是否易用直观？"]
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["小功能：想法到生产<br/>大功能：快速构建原型"]
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… |
