原文：How Coding Agents Are Reshaping Engineering, Product and Design 作者：Harrison Chase（LangChain CEO） 译者按：这篇文章值得细读。它不是在讲"AI 会不会取代程序员"这个老问题，而是在讨论一件更微妙、更切身的事：当写代码变得几乎免费，软件团队里的每一个角色——工程师、产品经理、设计师——究竟在哪里创造价值？
一切的起点：瓶颈换了位置
软件团队的传统工作流，是一条流水线：
产品经理写 PRD → 设计师出稿 → 工程师实现
这套流程之所以存在，本质上是因为"实现"这件事太贵了。写代码需要专业技能、需要时间、需要沟通——于是团队自然分化成不同的职能，PRD 和设计稿成为职能之间传递意图的媒介。
但 Coding Agent 出现之后，这个前提不再成立了。
从一个想法到一个可运行的原型，成本已经趋近于零。
这不是说工程师要消失，而是说：整个团队过去几十年围绕"实现成本高"这一事实所建立起来的协作结构，正在被迫重新设计。
新的瓶颈是什么？是审查（Review）。
当生成代码变得廉价，"评估这段代码好不好"反而成了稀缺资源。好不好，要从三个维度来判断：
- 工程视角：架构是否合理？能否撑起规模化？边界条件处理了没？
- 产品视角：这个实现真的解决了用户的问题吗？
- 设计视角：界面用起来是否顺手、符合直觉？
原型多了，但能看懂原型、能判断好坏的人，并没有等比例变多。这个张力，是接下来所有变化的根源。
PRD 死了，但文字没有死
"PRD 已死"——这句话乍听很刺激，但 Harrison Chase 的意思并不是说产品不需要思考了。
他的意思是：为了"让工程师看懂需求"而存在的那种 PRD，已经没有意义了。过去写 PRD，很大程度上是在做翻译工作——把产品的意图翻译成工程师能执行的语言。但现在 Coding Agent 能直接读懂人话，这个翻译层就消失了。
然而，另一种文字记录比以往更重要了：用来辅助审查的上下文。
当一个 Coding Agent 生成了某个功能，Review 的人需要理解：
- 这个功能是要解决什么问题的？
- 这个实现是主动选择，还是 Agent 的随机输出？
- 边界条件是故意这么处理，还是遗漏了？
Chase 提出了一个有趣的设想：未来的 PRD，本质上就是一个结构化的、可版本管理的 Prompt——直接把生成这个功能时用的 Prompt 共享出来，就是最好的需求文档。
这个设想听上去激进，但逻辑很自洽：与其写一份描述"应该做什么"的文档，不如直接保存"我是怎么告诉 Agent 去做的"。
每个角色都在发生什么
全栈型人才，价值翻倍
过去，同时懂产品、设计、工程的人很稀缺，但即便存在，他们的价值也受限于团队协作的摩擦——一个人想法再多，还是需要通过沟通把想法传递给别人来执行。
现在这个摩擦消失了。一个全栈型人才可以直接和 Agent 沟通，绕过所有跨职能协作的开销，一个人完成过去需要小团队才能完成的事。
速度不是线性提升，是指数级的。
不会用 Coding Agent？那就危险了
这不是趋势，是门槛。
- 产品经理：用 Agent 快速验证产品假设，不再等工程资源
- 设计师：直接在代码层面迭代交互细节，不再隔着工程师传话
- 工程师：把精力从"写样板代码"解放出来，专注于系统设计和架构决策
Chase 的判断很直接：不能适应这种工作方式的人，面临被替换的风险。
产品判断力的两极分化
在旧世界，一个粗糙的想法，光靠执行成本就会在 PRD 阶段被过滤掉——没有工程资源去做，这个想法自然死掉了。
在新世界，一个粗糙的想法，会快速生成一个原型，然后需要有人去 Review、去否定、去解释为什么不行。
坏的产品判断，现在会直接消耗团队的审查资源。
所以，好的产品直觉比以前更值钱；坏的产品直觉，也比以前更贵。
系统思维成为核心竞争力
当"生成代码"变得廉价，"设计系统"就成了真正的差异化能力。
这里的"系统思维"不只是工程架构，而是每个职能内部的深层理解：
- 工程师理解服务的边界、扩展性、失效模式
- 产品经理真正理解用户——不是用户说他们想要什么，而是他们实际在做什么、在卡在哪里
- 设计师知道为什么某个交互"感觉对"，能说清楚背后的认知逻辑
这种深度的领域理解，是 Agent 短期内无法替代的。
"懂产品"成为所有人的基础能力
无论你是什么角色，你都需要能够告诉 Agent 该构建什么。
这个能力——判断什么值得做、什么不值得做、什么方向是对的——就是产品感（Product Sense）。
Chase 的观点是：缺乏这种判断力的人，无论在哪个职能，都会成为团队的拖累——因为他们生成的原型质量低，反而制造了更多需要被 Review 和否定的噪音。
专才的门槛更高了
"我是专业工程师"不再是护城河。专才需要同时满足：
- 在自己领域真正出色
- 能高速 Review，快速判断好坏
- 能清晰沟通，让 Agent 和团队都理解你的意图
"设计工程师"（Design Engineer）这个角色正在兴起，正是这种趋势的体现——纯粹的单一职能，生存空间在收窄。
两种新的人才原型
Chase 预测，团队里会逐渐出现两种核心角色：
构建者（Builder）
- 有扎实的产品直觉
- 熟练使用 Coding Agent
- 有基础的设计审美
- 能在测试套件、组件库等工程护栏的支撑下，独立把功能从想法推到生产环境
这类人的价值，在于执行速度——他们是团队的推进引擎。
审查者（Reviewer）
- 在自己领域有深厚的系统思维
- 能以极高的速度审查 Builder 的输出
- 确保整体架构的完整性和产品方向的正确性
这类人的价值，在于判断质量——他们是团队的质量门禁。
两者缺一不可。Builder 产出越快，越需要高质量的 Reviewer。
一个反直觉的结论
文章结尾，Chase 引用了一条 Twitter 上广泛传播的帖子，大意是：最能从 Coding Agent 中获益的人，是那种"对产品有直觉性的把握——知道哪里软、哪里硬、如何迭代让它更锋利"的人。
有趣的是：所有人看到这段描述，都觉得说的是自己——产品经理觉得是自己，设计师觉得是自己，工程师觉得是自己，创始人也觉得是自己。
Chase 的回答是：他们可能都没错。
背景和职能头衔，重要性在下降。真正重要的，是那种融合了文化理解和技术洞察的混合直觉——能看懂系统、能感知用户、能做判断的能力。
这种能力，不专属于任何一个职能。
译者总结
这篇文章的核心洞见，可以浓缩成三句话：
- 瓶颈从执行转移到了审查——会做不再稀缺，会判断才稀缺
- 职能边界在模糊——不是消失，而是每个人都需要具备跨职能的基础理解
- 系统思维 + 产品感 + Agent 熟练度，是新时代的复合竞争力
软件团队的组织形态，正在经历一次结构性的重写。这次重写，不是由某一个技术突破触发的，而是由"执行成本趋近于零"这个经济学事实，慢慢渗透进每一个角色的工作方式里。
现在是参与这个变化最好的时候——前提是，你愿意重新审视自己的角色在哪里创造价值。
