PRD 到底死没死？编程 Agent 正在重写软件团队的流水线

两天在读 Harrison Chase（LangChAIn 联合创始人兼 CEO）那篇《How Coding Agents Are Reshaping Engineering, Product and Design》，又把 signüll 那条关于“product thinker”的帖子一起读了一遍。

它们真正打动我的地方，是把一个更值得团队负责人重视的变化说清楚了：

软件团队最稀缺的资源，正在从实现能力，转向判断能力、评审能力和上下文传递能力。

过去最贵的是把东西做出来。
现在，原型和初版代码越来越便宜，真正开始变贵的，是判断它值不值得做、哪里不能合、出了问题谁来收。

如果换成工程团队更熟悉的说法：

编程 Agent 改写的，是整个 EPD（Engineering、Product、Design）协作链路的瓶颈位置。

下面不按原文顺序直译，而是把 Harrison 的原文和 signüll 那条帖子放在一起，顺着四个问题往下聊：

1. PRD 到底死没死。

2. 为什么团队瓶颈会从实现转向评审。

3. 为什么“产品判断 + 系统思维”会成为更稀缺的能力。

4. 工程、产品、设计团队接下来该怎么调整协作方式。

如果最近一直在看我们这组关于 Agent 的文章，会发现不少线头能接上。前面写 Skills 分层、Claude Code 治理、架构师角色转型、AI 原生工程师工作流，聊的都是同一件事的不同切面。

这篇接着往下走一步：当实现成本被 Agent 打下来之后，软件团队的组织逻辑会怎么变。

太长不看版（8 条）

1.PRD 没死，先死的是“PRD -> 设计稿 -> 工程实现”这条老流水线。

2.编程 Agent 把原型成本压下来了，组织的新瓶颈自然会转向评审吞吐和判断质量。

3.以后最稀缺的人，不只是会写代码的人，而是能判断“该做什么、为什么做、做到什么程度才算对”的人。

4.会用编程 Agent 很快会从加分项，变成很多岗位的默认项。

5.通才会更值钱，但专业岗不会消失，只是门槛会明显提高。

6.好的 PM、好的设计判断、好的架构判断，都会被放大；差判断造成的浪费也会被放大。

7.软件团队会越来越像两类角色协同：建设者（Builder）和评审者（Reviewer）。

8.对团队负责人来说，更急的不是再提速，而是把护栏、评审机制和上下文交接补起来。

先用一张更紧凑的图，把“瓶颈迁移”放回流程里。

PRD 没死，死的是“文档先行、实现滞后”的老流程

Harrison Chase 在原文里用了一个很抓眼球的说法：PRDs are dead。

这句话很容易被误读。最常见的误读有两种：

• • 以后不用写文档了。
• • 编程 Agent 会让产品、设计这些角色边缘化。

如果认真读完原文，会发现他真正否定的，其实是这条老流程：

• 有了想法，产品先写一份长 PRD；
• 设计再根据 PRD 出稿；
• 工程最后把设计稿实现成代码。

这套流程之所以成立，是因为“实现成本很高”。既然开发贵，组织就会尽量把讨论前置，把需求、交互、边界和验收条件先写细，尽量减少返工。

PRD 在那个时代很重要，因为它既是沟通介质，也是流程起点。

现在前提变了。编程 Agent，也就是能直接读代码、改代码、跑测试、生成提交的代码智能体，正在把初版实现的成本压到非常低。很多原来要一两周才能看到雏形的东西，现在一天甚至半天就能做出一个能点、能跑、能演示的版本。

于是流程顺序开始倒过来：

• 先有原型，再补意图说明；
• 先把东西跑起来，再决定它是否值得进入生产。

所以真正退出历史舞台的，是“文档先行、实现滞后”的老式瀑布链路。PRD 这类文档本身并没有消失。

相反，它的职责变得更清楚了。

以前写文档，核心目的是让下游知道“该做什么”。
现在写文档，更重要的目的是让评审者知道“为什么这么做”“哪些是有意设计”“哪些只是原型阶段的暂存方案”“最终验收标准到底是什么”。

这件事在复杂系统里尤其重要。没有意图说明，评审者看到的只是一个“已经能跑”的东西；但“能跑”离“应该合并”，中间还差很远。

原文里还有一个细节值得保留：未来这类文档未必一定是传统 PRD。它可能是一份轻量文档，也可能是一套结构化、可版本化的 prompt，甚至是原型旁边一份很短的验收说明。

形式会变。
意图说明这件事，不会消失。

从我们作为架构师的来看，这里有一个更具体的变化值得注意：PRD 的继任者，很可能不是另一种形式的 PRD，而是更接近 ADR（Architecture Decision Record）或轻量 RFC 的东西。

因为在"先有原型再补文档"的新流程里，需要记录的不再是"要做什么"，而是"为什么选了这个方案而不是另一个""已知的 trade-off 是什么""什么条件下应该回滚这个决策"。

这些恰恰是 ADR 的核心字段。换句话说，原型负责回答"能不能做"，ADR 负责回答"该不该这么做"。

这和我们之前反复碰到的现象一致。

无论是拆 Claude Code 的批注循环，还是聊 AI 原生工程师怎么管理多个 Agent，背后都是同一个变化：文档不再只是把需求交给下游的说明书，它越来越像评审入口、协作状态和意图对齐的控制面。

前面写 Skills 那篇时，我们专门讲过一个点：好的 description 更像路由规则，决定什么场景触发、什么场景不触发。放到这里也是一样。原型旁边那份文档，写得越像路由规则和验收规则，评审成本就越低，误解也越少。

实现越便宜，评审越昂贵

很多团队对编程 Agent 的第一反应，是“研发效率提升了”。

这当然没错，但如果只停在这里，理解还停留在个人提效层面。更大的变化发生在组织层。

当原型生产成本急剧下降时，系统里涌入的，并不只是更多代码，而是更多等待判断的候选方案。评审流量会上升，噪音也会上升。

过去团队之所以还能扛住，是因为实现速度天然限制了上游输入。想法再多，真正能走到“可评审”阶段的东西并不多。现在不同了，产品、设计、工程，甚至运营、创始人，都可能直接借助 Agent 搭出一个原型，然后把它扔进评审队列。

输入端被放大以后，评审端如果还是老配置，瓶颈一定会从“没人做”变成“没人看得过来”。

这也许和《当 AI 完成了大部分代码，架构师何去何从》里那条线是一致的。AI 先吞掉的是手写实现，先升值的则是验证、观测、约束和回滚。

写代码的时间省下来了，不代表团队就轻松了，很多时候只是把压力从编码端推到了评审端。

这时候，评审就不只是 code review 了。

更具体一点看，评审至少有三层：

1. 1. 工程评审：架构是否合理，边界是否清晰，可维护性、可扩展性和性能风险是否可接受。
2. 2. 产品评审：这个需求到底值不值得做，解决的是不是用户真实问题，优先级是否成立。
3. 3. 设计评审：交互是否顺滑，信息层级是否清楚，是否破坏已有的一致性。

这三层里面，工程评审的压力上升最快。

因为 Agent 生成的代码在表面可用性上往往还不错，但在模块边界、状态管理、错误处理和接口演进这些架构层面的问题上，常常埋着隐患。

一个架构师或者工程师以前一周可能只需要深度 review 两三个方案，现在可能面对的是十个"能跑的原型"，每一个都需要判断：这个实现路径，是否会在三个月后变成一笔难以偿还的技术债。

原文里有一句话我很认同：Agent 生成的代码未必总是差，真正的问题是它太容易生成了。

数量一旦上来，组织要处理的重点，就不再是“怎么把东西做出来”，而是“怎么把不该进主干的东西拦住”。

这也是为什么一些团队最近会出现一种新内耗：

• • 原型已经做出来了，团队会下意识觉得“都到这一步了，不如先上”。
• • 评审者明知道方向不对，但因为东西已经存在，反对的心理成本会更高。
• • 一旦缺少清晰的验收标准，讨论很容易从“这是不是该做”滑向“既然做了，怎么补一补把它上线”。

实现变便宜之后，最贵的代价，往往不是写错几百行代码，而是把错误方向包装成“低成本试错”。

因为错误方向带来的成本，不再主要体现为开发工时，而是评审吞吐、系统复杂度、产品臃肿，以及后续维护债务。

带过团队的人，对这种感觉大多不会陌生。以前一个坏方向常常死在“做不完”；现在它更容易死在“来不及拦”。差别看起来不大，组织后果却完全不同。

会用 Agent，很快会从加分项变成默认项

Harrison Chase 在原文里还有一个判断很直接：Coding agents are a requirement。

这句话听起来很猛，但放到组织现实里并不突兀。

当实现成本已经被大幅打下来时，一个不会使用编程 Agent 的岗位，很容易在吞吐上吃亏。

这个变化不会只发生在工程团队。

原文举的三个例子都很典型：

• • 产品如果会用 Agent，就能先做一个原型验证想法，而不用先写一大份规格文档再排队等待。
• • 设计如果会用 Agent，就能直接在代码里迭代，而不只是停留在 Figma 层。
• • 工程如果会用 Agent，就能把更多时间从“机械实现”转移到“系统判断”。

这不意味着所有人都要变成高级工程师。

更贴近现实的说法是：会不会写复杂代码，仍然有层次差异；但会不会借助 Agent 把想法快速落成一个可讨论、可评审的版本，很快会成为很多岗位的基础能力。

这也是为什么角色边界会继续模糊。

产品会更早进入原型阶段。
设计会更早进入交互实现。
工程会把更多精力投向架构、护栏和评审。

岗位没有消失，只是重心在移动。

这和《从写代码到“管Agent”: 何为AI 原生工程师?》里讲的“角色从写代码的人变成管 Agent 的人”，本质上是一回事。差别不在于头衔变了，而在于工作重心确实在从个人实现，转向任务拆分、上下文管理、结果验收和异常收敛。

真正稀缺的，会是产品判断加系统思维

signüll 那条帖子里有个词，很准：product thinker。

它不是传统意义上的产品经理头衔，更像一种稀缺能力组合：对产品现状有直觉式理解，知道哪里是软肋，哪里是真正有价值的亮点，也知道接下来两年该往哪里推——然后从那个终态往回倒推当下该做什么。

用 signüll 原话说：this person has to cohesively hold in their head where this product should be 2 years from now & work backwards from that。这种"从终态倒推"的思维方式，和我们之前聊架构师时讲的"从约束倒推设计"，逻辑上是一致的。

signüll 在帖子里还有一个很锐利的判断：当实现不再困难时，结果的差异几乎完全取决于三件事——判断做什么、决定先后顺序、以及怎么讲清楚为什么做。

尤其是第三点，他用了一个很重的词：narrative。

the story matters as much as the thing. internally, it organizes the team around a shared model of why. externally, it shapes the interpretive frame users bring to their first experience. you can't retrofit narrative onto a product & expect it to land, it has to be load bearing from the start.

翻译过来就是：故事和产品本身一样重要。对内，它让团队围绕一个共同的"为什么"来组织协作；对外，它塑造了用户第一次使用时的认知框架。叙事不能事后补上去，它必须从一开始就是承重结构。

这个观察在国内技术团队里很容易被忽视。很多团队习惯把"讲故事"归类为市场或运营的事。但 signüll 实际上是在说，叙事能力是产品判断的一部分——如果你连"为什么做"都讲不清楚，评审者、合作者和用户都很难建立信任。

这条帖子之所以传播得这么广，很大程度上是因为它点中了一个现实：

当实现不再稀缺，判断就成了最大的杠杆。

这句话落到不同岗位，会有不同版本。

对工程师来说，系统思维会变得比“快速写出功能”更值钱。更关键的是服务边界怎么划、状态放哪层、接口怎么演进、哪些技术债会在后面快速放大。

对产品来说，价值判断会变得比文档产出更值钱。用户口头说要什么，和系统真正该做什么之间，往往不是一回事。

对设计来说，交互判断会变得比单点视觉输出更值钱。一个看起来能用的界面，和一个真正可理解、可学习、可连续扩展的界面，中间往往隔着不小的距离。

原文还有一个很关键的提醒：编程 Agent 依然需要人来告诉它做什么。

如果方向给错了，Agent 只会更快地产出错误。
如果上下文给少了，Agent 只会更快地产出噪音。
如果约束给松了，Agent 只会更快地制造评审负担。

这也是为什么“产品意识”会从产品岗的专属能力，慢慢变成工程、设计也绕不过去的基础能力。

放到工程现场看，这个判断并不抽象。

前面写“Agent 友好的代码库”时专门提过，测试不是装饰，它是 Agent 能读懂的显式合约；README、代码风格和模块边界之所以重要，也不只是为了代码整洁，而是为了让 Agent 不会在一个含混不清的系统里越跑越偏。没有这些合约，产品判断再模糊一点，系统噪音会成倍放大。

原文说得很直白：没有产品意识的人，会给组织制造更多待评审的垃圾。

这句话虽然重，但放到很多团队的现实里，并不夸张。

因为今天最贵的，已经不是做一个无用功能本身，而是让更多人围着这个无用功能开会、评审、修改、妥协，最后还可能把它带进生产环境。

这个，可能会变成一个灾难，慢慢累积可能会比屎山代码更加恐怖的事情。

好的 PM 会更值钱，差判断也会更贵

原文里有一句判断值得单独拎出来：Good PMs are great, bad PMs are terrible。

这句话不只适用于 PM，也适用于所有承担方向判断的人。

为什么会这样？

因为在实现昂贵的时代，一个坏想法往往会死在排期、资源或者开发成本上。它有机会变差，但扩散得没那么快。

在 Agent 时代，一个坏想法完全可能以“原型已经做出来了”的形式活下来。它看起来很具体，甚至还有点说服力，于是会继续占用组织的注意力。

这时候，差判断造成的浪费会成倍放大：

• • 工程要看它的实现质量。
• • 产品要重新讨论它的价值。
• • 设计要补它的交互和一致性。
• • 管理层还可能被“已经做出来了”的既成事实推着走。

原文对这种惯性有个很形象的描述：东西都已经存在了，团队会更容易说出“那就先 merge 吧”。

很多团队真正需要警惕的，往往就在这里。
问题不在“AI 做得太快”，而在“错误方向太容易显得像一个差不多能上线的版本”。

前面拆 Boris Tane 那套 Research -> Plan -> 批注 -> Implement 工作流时，其实就在处理这个问题。先让 Agent 读清系统，再把方案写成可以批注的文档，再进入实现，本质上就是把“已经做出来了”的惯性往前打断。先审方向，再审代码，成本会低很多。

通才会更强，但专业岗也会更贵

原文里还有一个很容易被片面理解的点：通才会更有价值。

这个判断大体成立，但还要补一个前提。

通才之所以在 Agent 时代更强，核心原因不是“一个人什么都懂一点”突然变成了万能答案，而是沟通成本在很多场景里，真的会压过实现成本。

一个同时懂产品、工程、设计基本语言的人，能更快把模糊想法变成可评审原型，也能更快把评审意见转成下一轮迭代。

原来他被卡住，是因为实现能力不够。
现在实现环节有 Agent 补位，他的综合判断力就会被放大。

但这不意味着专业岗不重要了。

恰恰相反，专业岗会变得更少，也更贵。

因为当大量普通实现被自动化之后，留下来的高价值专业工作，会更集中在这些位置：

• • 复杂系统的架构判断。
• • 关键链路的质量把关。
• • 高风险场景下的安全、合规和边界设计。
• • 复杂产品的优先级裁剪与长期路线规划。
• • 关键交互模式的一致性设计与抽象沉淀。

原文也提到，专业化并没有消失，只是门槛被抬高了。以后还能稳稳站在专业岗上的人，不能只会做自己那一小段，还得能高密度评审、快速沟通、给出明确判断。

所以接下来团队里最值钱的人，往往会落在两端：

• • 一类是能跨产品、设计、工程快速推进的通才。
• • 一类是在复杂问题上给出高质量判断的资深专家。

中间那层只负责把明确需求翻译成实现的人，会先感受到挤压。

对高级工程师或架构师来说，这意味着工作重心会进一步从"亲手写关键代码"转向"定义约束、把关质量、设计可演进的系统骨架"。

以前你的不可替代性可能来自写出别人写不了的复杂模块；以后你的不可替代性更可能来自：你能判断一个 Agent 生成的微服务拆分方案是否会在半年后造成级联故障，你能在十个看起来都行的原型里指出哪个的接口设计最容易随需求演进而扩展。

所以与其把接下来的变化理解成“岗位消失”，不如把它看成“岗位厚薄变化”。薄的一层，会是纯翻译型实现；厚的一层，会是能把需求、架构、验证和协作串起来的人。

软件团队会越来越像两类角色协同

Harrison Chase 在文末做了一个很有启发的归纳：Builder 和 Reviewer。

这两个词，拿回去对照很多团队的现状，通常都会有点意思。

所谓 Builder，不是传统意义上的“码得快的人”，而是能在护栏之内，把一个功能从想法推进到可用版本的人。他需要有基本的产品意识、基本的设计直觉，也会熟练使用 Agent，把测试、组件库、规范和脚手架当成自己的放大器。

所谓 Reviewer，也不是单纯负责挑错的人，而是能从系统层面做判断的人。他要能快速看懂一个原型背后的真实成本，知道哪些地方只是表面可用，哪些地方会在生产环境里出问题。

对很多团队来说，架构师和高级工程师天然就是 Reviewer 的核心人选。但这个角色对他们的要求也在变：不能只盯代码质量，还要能快速理解业务意图；不能只说"这里有问题"，还要能给出可执行的改进路径。评审速度和沟通密度，会成为区分"经验丰富的工程师"和"真正有效的 Reviewer"的关键差异。

这两类角色以后大概率都会存在，而且关系会越来越紧：

• • Builder 负责提高试错速度。
• • Reviewer 负责控制试错质量。

少了 Builder，组织会慢。
少了 Reviewer，组织会乱。

很多团队现在的问题，不在于没有 Agent，也不在于没人会用 Agent，而在于默认所有人都在往 Builder 方向走，却没有认真建设 Reviewer 机制。

结果就是：

• • 原型越来越多。
• • 主干越来越脏。
• • 评审越来越疲惫。
• • 最后大家开始怀疑，是不是 Agent 天生就会拉低工程质量。

更准确的说法是：

Agent 只是把组织原本就存在的质量控制短板放大了。

《Claude Code 最佳实践：架构、治理与工程实践》里写过一句话：真正先失控的，往往不是模型能力，而是上下文。放到团队层面也一样，先失控的通常不是“它写得不对”，而是“没人说得清它为什么这么写、改动边界在哪里、出了问题怎么退”。这类失控一旦进入多人协作，很快就会从工具问题变成组织问题。

前面那篇也花了不少篇幅讲控制面分层：常驻约束放哪，工作流放哪，硬性校验放哪，隔离层放哪。放到这里看，Builder 和 Reviewer 的分工，其实也可以理解成组织层面的控制面分层。

每个岗位都会觉得自己更受益，而且他们都没错

Harrison Chase 在原文最后提到，关于“哪类人最受益于编程 Agent”这件事，产品、设计、设计工程师、创始人都能从同一段话里看到自己，而且他们大概率都没看错。

这件事背后的意思很重要。

编程 Agent 带来的，不是某一个岗位对另一个岗位的单向替代，而是多个岗位同时获得更大的行动半径：

• • 工程师有了更多时间思考产品和设计。
• • 产品和设计更容易把想法变成代码。
• • 创始人和业务负责人也能更早参与原型验证。

所以这轮变化最有意思的地方，也许恰恰不是“谁会赢”，而是很多原本分散在不同岗位上的能力，正在重新组合。

signüll 帖子里还有一句描述很精准：这种人最稀有的版本，站在文化与深度技术的交叉口上，是真正的"双语者"——既知道技术上什么是可能的，又能分辨哪些文化潮流是真实的、哪些只是昙花一现。正是这种组合，决定了一个产品让人感觉"理应如此"还是"拼凑而成"。

出身背景会变得没那么重要。
能不能快速理解问题、组织上下文、做出判断、推动收敛，会变得更重要。

这也是为什么很多人读完那条帖子都会觉得“它说的就是我”。
从某种意义上讲，他们确实都说对了一部分。

团队更需要补的，是护栏、评审和上下文

如果上面的判断成立，那接下来最该调整的，就不是一句空泛的“大家都去学 AI 编程”。更有效的，还是组织上的几件具体动作。

1. 让原型提交物有最基本的结构

以后进入评审的东西，最好不要只有一个能跑的 demo。

至少得把这几件事交代清楚：

• • 这次要解决的用户问题是什么。
• • 哪些行为是刻意设计，哪些只是临时实现。
• • 最低验收标准是什么。

这个载体可以是轻量 PRD，可以是结构化 prompt，可以是 issue 模板，也可以是 ADR 风格的短文档。

形式不是重点，重点是意图能不能被别人快速看懂。

如果借用之前写 Claude Code 工作流时的经验，这一步很像把 plan.md 从个人习惯提升成团队规范。多的不是一个文件，而是一个更稳定的评审落点。

2. 把评审当作主流程来设计

很多团队今天还在精细化管理开发流程，却把评审当作“大家顺手看看”。

这套思路在 Agent 时代会越来越吃力。因为评审已经不是附属动作，它正在变成主流程。

团队至少需要明确：

• • 什么级别的改动必须经过产品评审。
• • 什么级别的改动必须经过架构评审。
• • 哪类原型只能在沙箱或分支环境里流转，不能直接碰主干。
• • 哪些验收项必须自动化，不能靠口头保证。

归根结底，还是要把评审从“顺手做一下”升级成真正的控制面。

这和之前写 Skills 那篇讲的分层逻辑一样。哪些约束该常驻，哪些该按需触发，哪些必须硬性执行，背后都是同一种组织思路：先把边界画清楚，再去追求速度。

3. 给 Builder 足够的护栏

Builder 的高效率建立在护栏之上。

没有测试、没有组件库、没有权限边界、没有回滚机制，Builder 很容易从“高产”变成“高破坏”。

这也是为什么有些团队会觉得“Agent 更适合做原型，不适合进生产”。很多时候，问题不在 Agent 本身，而在于组织没有给它接上足够稳定的护栏。

这和之前聊 OpenClaw、Claude Code 时反复强调的结论也一致：护栏不是多写几句“请小心操作”，而是测试、权限、回滚、沙箱、审计这些硬约束。没有硬约束，再好的提示词也扛不住长链路任务。

如果再往前接，《从误删邮箱到 Skill 投毒：OpenClaw 安全到底该怎么做》里讲的最小权限、隔离执行和审计留痕，放到今天这个话题里也完全成立。工具不同，约束逻辑并没有变。

4. 给 Reviewer 足够的上下文

评审者最怕的，不是代码多，而是上下文少。

如果提交给 Reviewer 的只有一堆 diff、几张截图和一句“帮忙看下”，那再强的评审者也只能做表面判断。高质量评审需要知道业务意图、历史包袱、约束条件、失败代价和上线目标。

没有上下文，评审只能看形式。
有了上下文，评审才能看方向。

《从写代码到管智能体》里有个比喻一直很贴切：Agent 像一群很聪明但也很容易卡住的实习生，真正难的不是把任务派出去，而是在多个任务之间做上下文切换，还能记得每个任务走到哪一步。换到评审场景，这个难点一点没变，只是对象从人变成了原型和 diff。

同样的逻辑也能解释为什么我们之前会专门写《Claude Code 内置 Git Worktree：多 Agent 并行不再互相踩文件》。并行本身不是目的，隔离才是。没有隔离，并行越多，评审噪音越大。

5. 在评价体系里承认“判断力”是一种一等产能

很多公司今天的评价体系，还是更容易看见“做了多少”，不太容易看见“拦下了多少不该做的东西”。

但在 Agent 时代，后者的价值会上升。

一个能挡住错误方向、能快速指出系统风险、能把模糊问题重新定义清楚的人，创造的价值，未必比一个一天生成三万行代码的人少。

如果组织还只奖励“产出量”，最后拿到的就会是越来越多的候选方案，以及越来越少的有效决策。

我读完 Harrison Chase 那篇原文后, 核心理解是：

编程 Agent 没有消灭产品、工程、设计这三种能力，它只是把它们从“分段接力”推向了“围绕原型的并行评审”。

这会带来两个直接结果。

第一，角色边界会继续模糊。产品会更懂实现，工程会更早介入产品判断，设计也会更多进入代码和交互细节。

第二，组织对高质量判断的需求会持续上升。谁能定义问题、约束方案、看穿代价，谁就在新阶段更有价值。

所以 PRD 不会消失，它只会换一种形态回来。它可能不再是一份厚重文档，而是原型旁边那份更短、更结构化、直接服务评审的意图说明。

对团队来说，接下来真正要升级的，也不是先学会哪个新 Agent，而是能不能建立一套新的协作秩序：

让试错更快，同时不让错误方向更容易通过。

这件事做成了，Agent 才是杠杆。
这件事做不成，Agent 就只是噪音放大器。