开发直接对业务把 Agent 架起来，产品不干了——聊聊那份「消失的规格」

这不是又一篇「AI 会不会取代产品经理」。这是一次真实项目会上的分工冲突，往下挖到根上——为什么在 Agent 系统里，那份维系了二十年的「业务→产品→开发」交接链会突然接不上，企业转型已经跑出来的三个有名字的解法，以及一条「试验期一个人架、成熟期一个团队养」的时间轴。English version: The Spec That Vanished。

那次会上，产品为什么突然成了「辅助」

前阵子一次项目会，业务负责人说了句话，会议室安静了一下：现在做客服 Agent，是开发直接对着业务需求，把架构、落地、一期二期上线全串起来，产品这次是辅助角色。搁传统项目，这话是反过来的——产品主导，开发实现。

散会我去找隔壁做知识 Agent 的同事聊，他给了我一句更扎的：他那套设计，根本没法先写成文档发给产品和开发去讲——讲不清楚。他的做法是直接把系统架起来，然后产品和开发再基于这套架构，去接企业里现有系统的规格、把它们对接进来。

两句话拼一起，指向同一件事：在这个项目里，"设计" 这个动作，从产品手里挪走了，挪给了能把系统架起来的人。

产品当场不满，可以理解。传统项目里他们的活是实打实的：接业务需求、出设计文档、画原型、连前端按钮多大、点一下跳哪都写进 spec，再交给开发照着做。现在这条链子的上半截，被人绕过去了。

但把它读成「开发夺权、产品出局」，就把这件事读浅了。这一年我在企业里做 Agent 落地，见过好几个团队卡在这一模一样的地方，吵的都是「谁主导」——没有一个团队吵对了题。真正发生的事，是他们手里那份东西，那份叫「规格」的交付物，在 Agent 系统里悄悄不存在了。而这件事，海外已经吵了一年、砸了数十亿美金，跑出了名字和解法。

产品那套「把业务钉死成配置」的手艺，在 Agent 上第一次失灵

先把结论摆桌面上：传统 SaaS 产品的核心手艺，是把模糊的业务规则，固化成一屏屏能勾选、能填、能拖拽的确定性配置；Agent 系统里，这套「固化」根本做不到。

拿一个最普通的需求打样——业务说「退款要管起来」。传统 SaaS 里，产品交出来的是一整套能钉死的东西——

• 一个审批流配置器：后台拖拽节点，「退款金额高于 500 走主管审批，高于 5000 再加一道财务」，if-then 分支画成可视化流程图；
• 一套工单表单：工单类型下拉框十二项、每项的必填字段、SLA 倒计时、超时自动升级给谁；
• 一张状态机 + 权限矩阵：退款单五个状态（待提交 / 待审核 / 已通过 / 已驳回 / 已退款），每个状态哪个角色能点哪个按钮，一格一格定死；
• 一个规则引擎后台：让运营自己配「7 天无理由退货」开关、「满 200 减 20」，业务变了运营自助改，不用叫开发。

这套手艺的内核，是一个默认前提：业务里「什么算对、什么算够好」，是可以被产品提前想清楚、固化成配置项的。「退款高于 5000 要财务审」——这是一条能写死的规则，产品把它做成配置界面，系统照着确定性地执行。产品、开发、QA 三方能接上，是因为中间传的那份东西本身就能被钉死：给定输入，界面长什么样、点了调哪个接口、走哪条审批，全是定的。

Agent 把这个前提抽掉了。用户敲一句「这鞋穿着挤，能退不」——你找不到一个下拉框能装下这句话背后要判断的东西：这是退货还是换码、发货没发货（决定能不能物流拦截）、活动价买的换原价尺码要不要补差价、补差价按哪个价。这套判断没法预先做成配置项让运营去勾，因为它的下一步取决于运行时的上下文，每次对话路径都不一样（这正是 L2 真 Agent 和 L1 自动化的分界线）。

海外把这句话说得很狠——「AI 打碎了通用 SaaS」：每家企业的数据、流程、合规、以及「什么算够好」都不一样，到了 agent 时代，每家要的 prompt、tool 清单、eval rubric、集成面全不同。通用 SaaS 赌的是「业务规则能被产品固化成一套通用配置」，这个赌注，在 agent 上塌了。产品那套「把业务翻译成确定性配置」的手艺，没了固化的对象。

产品「讲不清楚」，不是能力问题——是那道「翻译」换了方向

业务→产品→开发这条链，值钱的地方从来不是三个环节本身，是中间那道翻译——把模糊的业务意图，翻译成能实现的东西。产品这个岗位，本质是这道翻译的 owner。

传统软件里，这道翻译最难、也最有价值：业务说「我要让退货更顺畅」，产品把它拆成十几个界面状态、几十条配置规则、按钮多大跳转去哪。难点在把意图翻译成确定性的界面和配置——这道难点，产品扛。

Agent 系统里，最难的翻译换了个方向。业务说「我要让退货更顺畅」，真正难的不是画界面，是把这个意图翻译成一套安全、可评估、能归责的决策架构：哪些能让 LLM 自己决定、哪些必须走死流程、哪一步错了会赔钱、Critic 在哪兜底、怎么证明它上线前是对的。这道翻译，要的是同时懂业务规则和 LLM 的失效模式——这两样得在同一个脑子里，而它恰好不在产品原来那套「界面配置」的技能里。

这里得说句大实话，也是我自己项目里最真实的处境：传统企业的开发团队，绝大多数没有 ML、LLM、算法的储备，没碰过 eval，也没有「持续学习」「标注」这些概念。 在这样一个团队里，能同时接住「业务边界」和「LLM 会怎么翻车」这两头的，往往只有一个节点——那个专门架 Agent 的人。不是「架构师」这个头衔天然该主导，是在你这个组织里，只有他一个人接得住这道翻译：业务的痛点要快速落地，系统怎么架、团队资源怎么调，都得从他这里过。所谓开发直接对业务，不是他想绕过谁，是链子上别的节点暂时还没长出这套能力。

这也就是那位同事「讲不清楚」的真正原因。不是他表达差。是他要交的那份东西，写到能讲清楚的程度，就已经是系统架构本身了，不是交给下游去实现的规格——中间那层「产品把设计翻译成开发能实现的 spec」，没有东西可翻译了。设计即架构，架构即实现说明。产品站的那一层，被抽掉了地板。

所以不是开发抢了产品的活。是「把业务意图翻译成能实现的东西」这道核心翻译，在 Agent 系统里换了形状，换到了另一个人手里。 这不是我一个人的观察。Andrew Ng 说得更直白：AI 创业公司的瓶颈不在写代码，在产品——决定该造什么，比造出来更难。有人把新的人力配比拍成 1 个产品配 0.5 个工程师，而不是传统的 1:4。硅谷那边把这轮叫「产品经理被一劈两半」：一半贴着工程和客户、直接写「Agent 能执行的规格」，另一半退到平台、API、数据、合规那层；中间那个写十页 PRD、连按钮多大都定的人，成了瓶颈——一句话：「工程快了 5 倍，产品没有」。

「产品没用了」是陷阱：消失的规格散成三件事

到这里最容易跳到一个结论：那产品是不是就没用了？这是个陷阱。会掉进去的团队，半年后都会付学费。

那份消失的「规格」，原来同时扛着三件事。规格没了，这三件事不会跟着消失——它们只是从产品的文档里掉出来，散落一地，等人去捡。看清是哪三件，你就知道产品该往哪搬、以及不捡会烂在哪。

第一件：决策边界——Agent 允许自己决定什么，不许决定什么。 「退货 vs 取消 vs 物流拦截」到底走哪条，取决于这单发货没发货；哪些政策 LLM 能自己判、哪些必须转人工。这件事现在长在 workflow 状态机里，跟着架构走——它需要同时懂业务和 LLM 失效模式，产品不补上这两样就接不住。这件多半跟着架构师走了。

第二件：评估基准——什么才算「做对了」。 这件最容易被所有人漏掉，而它恰恰是产品的新家。举个真实到疼的例子：客户拿活动价买的鞋，来换个大一码，得补差价——补差价按哪个价？ 实付价、当前可购价、吊牌价、会员价，四个数能差出上百块。这不是工程问题，工程只负责把公式跑对；「按哪个价」是一个业务决策，得有人拍板、写成判准。

这不是我的一家之言，海外已经把它做成了一门显学，叫 eval-driven development（评估驱动开发）：任何概率系统上线前，都得先有一份「什么算对」的规格，没有自动化证明它达标就不许发。而其中最关键的一句分工，几乎是给产品的新岗位说明书——「rubric 由产品写，不由工程写；工程搭打分设施，产品定义每个分数什么意思、阈值设多少。」 更狠的是，这份 eval——rubric、标注好的真实会话、阈值——进版本库、有 changelog，是能跨模型升级留存下来的「产品 IP」：prompt 和模型会换，判准不换（接住率 vs 解决率、上线前卡哪几道闸 全卡在这套判准上）。这就是那份消失的 PRD 的转世：它不再长得像需求文档，长得像一套评分标准 + 一批标好答案的真实会话。谁去定这套判准，谁就是 Agent 时代的产品。

第三件：归责——出了事，谁在「Agent 为什么这么做」上签字。 传统项目里，产品的 spec 就是归责链的一环。开发直接对业务把系统架起来之后，这条链常常断在半空——上线前谁签「可以上」？线上退错一笔款，谁去回答监管和老板「这条路径为什么走通了」？这件事一旦没有明确的人扛，整个项目就悬着。 这不是技术问题，是决策权问题。

把三件事摆一起，那句「产品没用了」就站不住了。产品不是被开发取代了。是产品原来站的那一层——把意图翻译成界面配置——在 Agent 系统里变薄了；而新长出来的那一层——定义评估基准、守住归责——产品还没搬进去。 硅谷那句话糙但对：能干活的人多了，能拍板、能让整件事自洽的人少了。

企业到底该怎么转：三个已经有名字的解法

好消息是：你会议室里这场别扭，海外已经吵了一年、砸了数十亿美金，跑出了三个有名字、能照抄的解法。它们不是理论，是四家最大的 AI 公司真金白银押出来的操作模型。

解法一：承认「开发直接对业务」是个有名字的模式，别当成夺权。 它叫 Forward Deployed Engineer（FDE，前置部署工程师）——Palantir 2008 年就发明了，OpenAI、Anthropic、Databricks 在 2023–2025 为 LLM 时代重造了它。2026 年年中，几家最大的 AI 公司（AWS、Anthropic、OpenAI、微软）在短短几周内密集加注这个模式，专门派工程师驻到客户现场把 agent 架起来——光 AWS 一家就公开宣布投 10 亿美元。这波数十亿美金级的集体下注，押的是同一件事：agentic AI 不会自己上线，得有人贴着客户把它架起来。 FDE 圈里最出名的一句定义，跟你老板那句几乎一字不差：「屋里没有产品经理替你做这件事——你就是屋里那个产品经理。」 所以你老板不是拍脑袋，是踩在一条跑了十七年、又被重造的轨道上。解法不是把主导权抢回来，是给这个架构师配一个业务 SME 当搭子、直接对，把产品从「中间二传手」的位置挪走——挪去哪，看解法二。

解法二：把消失的规格，重新定义成 eval，让产品搬进去当 rubric owner。 上一节说的 eval-driven development，落到组织上就是一次岗位再定义：产品不再写「按钮多大」的 PRD，改去定义「什么算解决了、补差价按哪个价、这单该不该退」，把它写成 rubric、标一批真实会话当 ground truth、设阈值、进版本库。这活比守着旧 PRD 值钱十倍——因为它是唯一能跨模型升级留存的产品资产。一个能读懂业务、又愿意钻进标注和判准里的产品，是 Agent 项目最稀缺的人。产品的转型出路，不在「学会写 prompt」，在成为判准的 owner。

解法三：显式画决策权，上一层治理（DRI + agent registry）。 三个 owner 白纸黑字指到人。这里有个数字最该让老板清醒：将近一半（48%）的企业上了 AI，却压根没重新设计它所处的流程和角色；只有 34% 说 AI 产生了可衡量的财务回报，不到 20% 有成熟的治理框架。大多数失败不是模型不行，是把 agent 塞进没改过的旧组织里。 成熟做法是上一个 agent registry 统一管所有 agent——谁能调、KPI 怎么盯、什么时候退役；企业架构团队把 agent 当「架构组件」来建模，和流程、应用、数据并列（这正好呼应第一件事：决策边界跟着架构走）。别做那 48%。

三个解法拼起来，就是新的分工：架构师 + 业务 SME 直接对（FDE），产品搬去当判准 owner（eval-driven），治理层把三个 owner 钉死（DRI）。 谁主导，是个假问题；这套落位，才是真问题。

这套分工有条时间轴：试验期一个人架，成熟期一个团队养

前面讲的都是横切面——三件事分别归谁。但还有一条纵轴容易被忽略：Agent 项目有试验期和成熟期，这两段的分工根本不是一回事。

这条纵轴也有现成的样板。Palantir 的 FDE 从来不是一个人干到底，它是双速的：前面一拨人（他们叫 Delta）贴着客户现场快速把系统架起来，0→1，怎么快怎么来；后面一拨人（叫 Echo，核心产品团队）再把趟出来的东西 generalize、加固、做成能跨客户复用的稳定平台。他们给这个过程起的外号很传神——「把土路修成高速公路」。

对上号了：试验期是架构师的主场。 一个强 agent 架构师单点快跑，把业务痛点迅速架成能跑的功能——这一段就该他主导，人越多越慢，产品在这段确实帮不上太多。但成熟期是另一拨人的活：稳定运行、数据治理管道、监控告警、跨场景复用——这些不是「打磨架构」，是补一整套试验期没顾上的能力。

这里藏着 Agent 项目最贵的一个坑，得逆着直觉说一句：eval 和数据治理，不能全 defer 到成熟期再补。 一个「先把功能做出来、稳定性以后慢慢磨」的排期听上去很合理，国际数据却是反的——用了评估工具的组织，能推上生产的 AI 系统多出近 6 倍（Databricks 2026）；而只有 21% 的企业有成熟的 agent 治理，专门设「agent owner」的企业两年间从 11% 涨到 56%（Deloitte）。

翻译成你的处境就一句话：试验期你一个强架构师能顶，成熟期你顶不住——不是架构不行，是没人能「量」这个 Agent 到底有没有在变好。 一个团队要是没有 eval、没有标注、没碰过持续学习那套（这恰恰是绝大多数传统企业开发团队的现状），成熟期的「慢慢打磨」就会变成「慢慢重写」：改了一版不知道好坏，凭体感上线，出了事再回滚。没有那把尺子，打磨就是原地转圈。

所以成熟期真正要做的，不是把架构师的设计磨光滑，是补上团队现在没有的那套能力——eval、标注、数据治理、一个判准 owner，而且其中的种子得在试验期就埋下。这也正好是产品该进场的时点：你把 0→1 架完，产品带着 rubric 和标注进来做 1→N。 试验期属于架构师，成熟期属于产品 + 开发 + 数据——不是谁淘汰谁，是同一条路的两段路面，土路和高速，各由不同的人铺。

你办公室那场不满，是一场数十亿美金级的行业重排

如果你也在经历这种别扭，先松一口气：这不是你们公司哪个人的问题，是一轮行业级的角色重排，全世界的团队此刻都在同一个坑里打转。

HN 上这个吵得很凶。有工程师抱怨「产品不让工程碰 prompt」，底下最高赞一句话戳破：「禁工程师碰 prompt，纯粹是政治」——本质是岗位在守自己的地盘。也有反过来的：产品改了 AI 生成的代码，但「产品根本看不出 AI 写的代码是好是坏」，埋下 bug 自己不知道。还有一句留给产品的公道话：「好产品做的是看不见的活；差产品，是人就看不见」——产品的价值从来不在写 spec 那道手工活上，在判断和对齐上，那部分 AI 拿不走。

数字未必要照单全收，但方向一致：「谁写规格、谁拍板、谁签字」这套二十年没动过的分工，正在被集体重画。 GitHub 工程团队那句话说得最干脆——「规格成为唯一事实来源，它决定造什么」。过去 PRD 是给人看的对齐文档；现在给 Agent 的规格，是一份可执行、可打分的接口。写规格这件事本身，变了物种。

你会议室里那场不满，是这场重画在你桌上的一个切片。吵「谁主导」，是拿旧地图找新路——地图上那条「业务→产品→开发」的路还在，但路面已经塌了一截。

结语：产品的不满是真的，但题吵错了

回到那次会。产品觉得被绕过去了，这感受不假——他手里那份能钉死需求的规格，确实没了用武之地。但会上真正该解决的，从来不是「把主导权还给谁」，是那份消失的规格散落的三件事——决策边界、评估基准、归责——在你项目里落位了没有。

• 决策边界，多半已经跟着架构师走了（这就是 FDE）。认了，别抢。
• 评估基准，那块空地最大、也最值钱。产品肯搬进去当 rubric owner，比守着「按钮多大」值钱十倍。
• 归责，最容易断在半空，也最致命。指一个 DRI，白纸黑字。别做那 48% 只上 AI 不改组织的公司。

给你一个当场能用的检测动作：下次评审会，别问「这是产品的活还是开发的活」，问三句——

1. 决策边界谁定的？ 这个 Agent 允许自己决定退款，边界写在哪、谁评审过？答不上来 = 决策边界没 owner，等着 LLM 自由发挥出事。
2. 判准谁拍的？ 「补差价按哪个价」「什么算解决了」，这套 ground truth 谁签的字、进没进版本库？答「按模型判断」= 评估基准没 owner，你上线全凭体感。
3. 上线谁签的？ 出了事，谁去回答「Agent 为什么走这条路径」？答不上来 = 归责没 owner，项目悬着。

三句里但凡有一句卡壳，那个位置就是你项目接下来会烂掉的地方——跟谁主导没关系。

Agent 时代的分工不是谁淘汰谁。是那份维系了二十年的「规格」散架了，它扛的三件事，掉在地上等人捡。谁弯腰捡，谁就还在场上。

如果这篇帮你把「谁主导」的死结解开了，欢迎转给团队里正为这事别扭的同事——尤其是那位觉得自己被绕过去了的产品。分工重排不是零和，是三个 owner 该各归各位。

想要这篇里那张「三个 owner 落位检测表」（一页 A4，下次评审会直接对着打勾），回复关键词「分工重排」，我发你。回复渠道见页脚。