编程 Agent 如何重塑工程、产品和设计
软件团队常说 EPD，也就是 Engineering、Product、Design。三个角色过去像接力赛，产品写 PRD，设计出稿，工程实现；而这篇文章最值得记下的判断是，编程 Agent 让“把东西做出来”这一步迅速贬值，团队瓶颈开始从实现转向评审。
这不是“人人都会写代码”那种浅层结论，而是协作逻辑在变。
原型成本被压低以后，讨论不再只能从文档开始，很多想法会先被直接做成可运行的东西，再拿回来讨论。于是 PRD 并没有消失，只是不再天然是流程起点，它更像围绕原型补充背景、约束和取舍的评审材料。
原型一多，团队马上会遇到新的成本结构。能跑，不等于方向对；能上线，不等于架构合理；能演示，也不等于体验过关。以前大家担心做不出来，现在更常见的问题是做出来太快，来不及判断哪些应该继续、哪些应该及时停掉。
如果说过去最稀缺的是实现产能，现在更稀缺的就是高质量的否决能力。团队需要有人及时说清楚：这只是个能运行的草稿，不是值得扩大的方案。
这也是为什么 Agent 对工程、产品、设计的影响不是均匀的。
工程需要更快识别技术债和系统边界，产品需要更快判断需求是否成立，设计需要更早介入交互质量。三方抢的其实是同一件事：有限的评审注意力。实现被压缩后，评审自然成了新瓶颈。
原文里“PRD 已死”这句话很容易被误读成“以后不需要需求表达”。
我更倾向于把它理解成，PRD 不再负责把意图从上游逐层传递到下游，而是和原型一起承担评审职责。先做一个能跑的版本，再补充目标用户、边界条件、成功标准和为什么不做别的方案，这会比先写一份很长但没人验证的文档更有效。
文档仍然重要，只是重要的方式变了。它不再是让团队开工的唯一入口，而是帮助团队校准共识、沉淀约束、降低返工的配套材料。
很多人会顺手得出一个夸张结论：既然 Agent 让每个人都能做点实现，那是不是以后只剩通才？我不这么看。更可能发生的是，跨角色协作能力变成基础门槛，而专业深度反而更贵。
真正占优的人，不是“每样都懂一点”，而是在一个方向上足够深入，同时能和另外两个方向高质量对话的人。
工程师不仅要写得出，还得判断系统如何演进；产品不仅要提需求，还得借助原型验证问题定义；设计也不再只是交付稿件，而要更早参与实现反馈。角色名不会消失，但单向派单式的分工会越来越吃亏。
从组织视角看，团队里可能会更明显地分成两类能力重心：一类擅长快速构建，把模糊想法尽快变成讨论对象；另一类擅长高质量评审，负责筛选方向、控制风险、提高成品率。
大多数人会落在中间，但都得补上原来不属于自己的那部分判断能力。
这类变化最容易被误读成“有 Agent 以后，好想法会跑得更快”。这只说对了一半。更准确的说法是，好想法和坏想法都会被加速放大，差别只在团队有没有足够的判断力去筛掉后者。
所以原文里“好的 PM 会更好，差的 PM 会更差”并不只是针对产品经理。它适用于所有 EPD 角色。
错的方向现在也能很快长出一个像样的原型，甚至更危险，因为一旦东西可见、可点、可演示，团队就更容易被沉没成本拖着继续往前走。Agent 不会替你做判断，只会把已有判断放大。
如果把这篇文章压成几个可执行的提醒，我会保留三条。
第一，不要只把编程 Agent 当成“更快写代码”的工具。它真正改变的是原型和试错的成本，而这会进一步改写需求表达、协作方式和决策节奏。
第二，评审能力会比生成能力更稀缺。会调 Agent、会生成草稿的人会越来越多，但能识别坏方案、看懂系统代价、判断是否值得继续做的人，不会同步变多。
第三，不管你现在在哪个角色，都该补另外两侧最关键的约束。工程要补产品和体验判断，产品和设计也要补实现成本与系统边界感知。目的不是角色混同，而是减少低质量往返。
“编程 Agent 会替代谁”当然容易引发讨论，但我觉得那不是最重要的问题。
更重要的是，当实现不再昂贵，团队里什么能力会重新变得稀缺？
我的答案和原文基本一致：需求表达还在，但更多是服务评审；实现门槛在下降，评审和取舍开始变贵；角色边界会变松，可真正有深度的专业判断不会被替代。如果今天还把 Agent 只看成工程提效工具，判断就太窄了。它真正重塑的，是谁来定义问题、谁来判断质量、谁来推动 EPD 协作。