最近，LangChain创始人Harrison Chase在社交平台发布了一篇广为流传的长文，深入剖析了AI编码代理对软件开发领域的冲击。他的核心观点犀利而直接：传统的PRD流程正在失效，开发瓶颈从“实现”转向了“评审”，而具备系统思维的通才将变得前所未有的重要。
这并非危言耸听，而是正在许多团队中真实发生的转变。一个好的产品经理借助AI工具可以如虎添翼，而一个糟糕的决策则可能更快地拖累整个EPD（工程、产品、设计）团队。工程师也必须做出选择：是成为能够独立构建的“建造者”，还是转型为深度评审的“把关人”。
以下是Harrison Chase观点的核心内容整理与翻译，希望能为云栈社区的技术与产品同仁们带来一些启发。
软件公司的工程、产品、设计团队，本质上都在做同一件事：将想法转化为可用的软件。角色可以分工，但最终的交付物始终是代码。如今，编程代理大幅降低了编写代码的成本，这将直接重构EPD之间的协作模式。主要将带来三个层面的变化：
对角色的影响
- 通才比以前更有价值
- 使用编程代理从加分项变为基本功
- 优秀PM的价值被放大，糟糕PM的破坏力也被放大
- 每个人都必须具备产品判断力
- 专业化不会消失，但门槛会变得更高
- 你最终会更像“构建者”或“评审者”中的一种
- 每个角色都认为自己的岗位最能从编程代理中受益，而且这种感觉是对的
PRD 已死
在强大的AI编程工具出现之前，PRD（产品需求文档）几乎是软件开发流程的固定起点。典型流程通常是：
- 某人（通常是产品经理）产生一个想法。
- 产品经理将想法写成PRD。
- 设计师根据PRD制作原型或Mockup。
- 工程师将原型转化为可运行的代码。
当然，这不是铁律。在初创公司，这些环节常常是混合的，能力强的人可以一气呵成完成多个步骤。但在过去，这确实是行业中最常见、最标准化的协作模式。
原因很简单：无论是制作高保真原型还是编写生产级代码，在过去都非常耗时耗力，因此催生了明确的角色分工。分工越细，沟通成本就越高，而PRD正是这套复杂协作流程的基石。后续流程基本是线性的：设计师将文字转化为界面与体验，工程师再将其实现。
编程代理的出现打断了这套逻辑。它可以直接将一个相对清晰的想法转化为可运行的软件。所以，当我说“PRD已死”时，并非指文档本身会消失，而是指那种“先写长篇PRD，再走完传统流水线”的软件构建方式，已经过时了。
瓶颈从实现转向评审
现在，几乎任何人都能“做出点东西”。但“能做出来”绝不等于“做得对”。它可能在架构上不合理，可能没有真正解决问题，也可能用户体验糟糕。
此时，工程、产品和设计角色的职责，开始更多地转向评审与把关。因为代理生成的代码，很多时候只是“能跑”，距离“优秀”还有很大差距。这里的“优秀”至少包含三个维度：
- 工程角度：架构是否合理、可扩展，性能与稳定性是否达标。
- 产品角度：是否真正击中了用户痛点，创造了价值。
- 设计角度：界面是否清晰、易用、符合直觉。
由于生成第一版代码或原型的成本极低，原型数量会爆炸式增长。于是，原型本身成为了讨论的中心，产品、工程和设计都围绕它进行评审。
问题正出在这里：代码生成太容易了。过去，制作一版可评审的代码需要投入时间，因此评审者能并行处理的项目数量有限。现在不同了，人人都能快速产出，项目自然变多。于是，工程、产品、设计这三个职能面临的共同新瓶颈，都落在了评审能力上：如何高效地评估一个原型，判断它是否足够好。
PRD 万岁
从PRD开始的旧软件开发流程确实结束了。但“清晰地表述需求”这件事不仅没有消失，反而变得更加重要。
假设某人有一个想法，并迅速用AI拉出了一个原型。接下来如何将其推进到生产环境？它仍然需要经过其他EPD成员的评审。到了这一步，书面说明就成了必需品。评审者如何区分一段代码是精心设计的结果，还是AI随手生成的？靠的就是对原始意图的清晰说明。
因此，我认为传统的PRD流程（PRD -> 原型 -> 代码）已经过时；但用文字将产品需求、约束条件和权衡取舍阐述清楚，这件事永远不会过时。在将原型提交评审前，附上一份说明文档是很好的实践。
最常见的形式当然是文档，但也可能出现其他形式。例如，提交生成此功能时使用过的Prompt序列，本身也可以成为一种沟通方式。谁知道未来的PRD，会不会就是结构化、可版本化的Prompt集合呢？
通才比以前更有价值
这里所说的通才，不是“什么都懂一点皮毛”的人，而是对产品、工程和设计三个领域都有深刻理解和良好感觉的人。这样的人过去就很有价值，现在他们的价值会倍增。
为什么？因为真正拖慢进度的往往不是写代码，而是沟通与对齐。一个既能构思产品、又能评估设计、还能推进工程落地的人，其效率通常会高于三个人分工协作，因为他消除了大量的交接与沟通成本。
在过去，实现是主要瓶颈，这类通才即使判断力超群，许多事情仍需等待他人配合。现在，他们可以直接与编程代理协作，将想法推进得更远，也能更独立地产出可验证的结果。
编程代理是基本功
当实现成本被编程代理大幅压低后，是否会用它就从一个“加分项”变成了基本功。谁能将代理深度融入日常工作流，谁就能独立完成更多事情：
- 会使用代理的PM，可以直接制作原型来验证想法，不必先写长篇规格文档，再排队等待开发资源。
- 会使用代理的设计师，可以直接在代码层面进行迭代，而不仅限于Figma等设计工具。
- 会使用代理的工程师，可以将更多时间从“写实现代码”转移到“思考系统设计”上。
它之所以会成为基本功，还有一个原因：学习使用编程代理并没有想象中那么困难。如果你不去掌握它，迟早会被那些善用工具的人超越，甚至取代。
好的PM会更好，差的PM会更糟
拥有优秀产品判断力的人，其价值会被进一步放大，因为他们现在可以更快地将真正有价值的东西做出来。反过来，产品判断力差的人，其破坏力也会被同步放大。
过去，一个糟糕的产品想法可能仅仅停留在会议讨论中；现在，它能迅速变成一个看起来“有模有样”的原型。但这个原型本质上可能仍是无效的，或者从一开始方向就错了。接下来，工程、产品和设计团队不得不花费额外时间评审它、收拾烂摊子。
更棘手的是，一旦这种原型被做出来，就容易产生一种惯性思维：“既然都做出来了，不如就合并进去吧。”最终的结果，往往是把未经深思熟虑的功能硬塞进产品，导致产品变得更差、更臃肿。
系统思维会变得更重要
在一个“执行成本极低”的世界里，真正能拉开差距的，是系统思维。你需要在各自的领域建立起足够清晰、坚实的心智模型：
- 工程：清楚服务、API和数据库应该如何组织与交互。
- 产品：清楚用户真正需要什么，而不仅仅是他们嘴上说什么。
- 设计：清楚为什么一个界面看起来和谐、用起来顺畅。
系统思维向来重要，变化在于如今“把东西做出来”的成本太低了。实现变容易，绝不意味着结果会变好。系统思维强的人，能在一开始就判断什么值得做、应该怎么做；事后也能更快地评估他人成果的优劣。
因此，这项能力的重要性只会持续攀升。
每个人都需要产品判断力
编程代理再强大，也需要有人告诉它该做什么。如果初始方向就是错的，你产出的只会是更多需要别人来清理和评审的“垃圾”。
因此，“知道该让代理去做什么”——即产品判断力，已经成为了所有人的基本能力。这不只是产品经理的事，工程师和设计师同样需要。
现在EPD团队的大量时间都花在评审原型上。如果你具备产品判断力，即使在评审设计或工程方案时，也更容易抓住一个功能想要解决的核心问题；如果不具备，你就只能依赖一份极其详尽的产品文档。前者意味着更快的沟通、更高效的评审和更迅速的交付。
专业化的门槛会更高
你既需要会使用编程代理，也需要具备产品判断力。角色之间的边界本就日渐模糊，如今这一趋势只会加速。
设计与产品本就经常交叉。在像Apple、Airbnb这样的公司，设计师兼任产品经理的情况并不罕见；在像Vercel这样的公司，design engineer这类角色也日益常见。
这并不意味着专业化会消失。只专注于系统架构的资深工程师，依然极具价值。那些尚未精通“ vibe coding ”但对客户问题与产品方向有清晰洞察的PM，同样有价值。能够想明白完整用户旅程与交互逻辑、即使主要工作仍在Figma中的设计师，也有其不可替代的位置。
但问题是，专业化的门槛被抬高了。你不能再仅仅是自己领域的专家，还必须具备高效的评审能力和清晰的沟通能力。在任何一家公司里，能同时满足这些条件的顶级专家岗位，数量都不会太多。
你要么是构建者，要么是评审者
我们正在目睹EPD团队中逐渐分化出两类更清晰的角色。
第一类是 “构建者” 。这类人拥有良好的产品判断力，能熟练使用编程代理，并具备基本的设计直觉。在测试框架、组件库等基础设施完善的前提下，他们可以将一个小功能从想法一路推至上线，也能为大型功能先搭建出一个可工作的雏形。
第二类是 “评审者” 。面对大型、复杂的功能，仍然需要非常深入的EPD联合评审。要做好这件事，门槛极高：你必须在自己的领域具备极强的系统思维，并且能跟上快节奏，因为等待评审的东西只会越来越多。
如果你是一名工程师，要么将系统设计和架构评审能力锤炼到顶尖，向“评审者”发展；要么补足产品和设计能力，向“构建者”转型。产品经理和设计师亦然：要么依靠极强的专业判断力承担核心评审工作，要么真正投身实践，补全利用编程代理进行开发的能力。
有趣的是，这两类角色的出现，也在进一步模糊EPD之间的边界。工程师手头有了更多时间，自然会更多地参与到产品与设计决策中；而产品经理和设计师，也开始直接涉足代码编写。
每个人都觉得自己最能受益，而且这可能是对的
一条广为流传的推文很好地描述了哪类人最能从编程代理中受益：
“那种对产品有极强直觉的人。他们知道产品当前的状态，哪里是软肋，哪里是亮点，也清楚该如何继续打磨，让它变得更加锋利。
更稀缺的一类人，站在文化与深度技术的交叉点上，像是真正的‘双语者’。他们既知道技术上什么可行，也能分辨哪些文化趋势是真实的，哪些只是昙花一现。正是这种组合，区分了‘浑然天成的产品’和‘生硬拼装的产品’。”
这条推文精准地概括了这个新时代。更有意思的现象是，几乎每个读到它的人都会觉得：“这说的不就是我（这类人）吗？”
我看到产品经理、设计师、设计工程师、创始人们都在转发。每个人都认为它适用于自己的角色，而他们很可能都是对的。这个新发展阶段最引人注目的一点恰恰在于：出身背景变得不那么重要了。这种“双语者”可能来自产品团队，也可能来自设计或工程团队。当然，这绝不意味着人人都能成为这样的人。说起来容易，做起来极其困难。真正的行业“独角兽”，永远是少数。
但对于“创造事物”这件事本身而言，这无疑是一个激动人心的时代。如果你对这类开发者角色的演变和技术驱动的产品变革有更多想法，欢迎交流探讨。
发表于 2 小时前
|
查看: 10|
回复: 0
