1. 助手接完了，没人说得清算不算做完
一家物流企业要在已有的智能体平台上做一个「运单与调度助手」。要接三套系统：运单系统查单，调度系统看车辆和排班，客服工单系统登记问题。用它的有两拨人，客服团队一百二十人，调度团队三十人。
第一版上线之后就露了三个问题。
权限开大了。产品经理写需求的时候写的是「客服可以查运单和调度情况」，没有写清调度系统里哪几条是只读、哪几条可写。工具接入是后端同学顺手配的，配的时候把调度系统的接口按原样接上了，其中「修改车辆排班」那条可写接口也一起开了。上线第三天，一位客服在对话里说「这单今天送不了，帮我挪到明天」，助手真的去改了排班。
拉错了人。需求里有一段「回答要准」，产品经理把它交给算法同学，让他们「调一下模型」。算法同学看了两天，发现要改的是提示词和知识库里的字段说明，跟模型参数没关系。
验收没人说得清。上线那天开验收会，业务方问「这一版算不算做完」，产品经理翻了一遍需求文档，里面写的是「支持运单查询与调度协同」这类话，没写一个能逐条核对的东西。
三个问题背后是同一件事：一个应用从行业需求到上线，中间有哪些块、每块归谁定、做到什么算完成，这一份没写出来。
2. 从行业需求倒推到平台上
2.1 先列要接哪几套系统
起点是这门业务的这条线要动哪几套系统，平台有什么功能是后面的事。
物流这条线要动三套：运单系统回答「这单现在在哪」，调度系统回答「谁的车能来拉」，工单系统记录「客户投诉了什么」。三套系统各有一个负责人，各有各的权限规则。
这一步的产出是一张系统清单，每一行写：系统名、用途、接口有没有、负责人是谁。物流这三套里，运单和调度有现成接口，工单系统只有部分接口，剩下的要走操作电脑。
2.2 再列要哪些工具、谁能看哪些数据
系统清单往下走一层，变成工具清单。一个系统往往要包成几个工具，粒度怎么切在讲工具调用与 MCP 那一份里讲过；这里要补的是每个工具上挂的两样东西：权限范围和调用者范围。
运单与调度助手的工具清单是这样：查运单（只读，客服和调度都能用）、查车辆排班（只读，两个团队都能用）、改排班（可写，只有调度能用，改之前要调度主管确认）、查工单（只读，客服能用）、建工单（可写，客服能用，提交后要客服自己核对）。
数据这一层还要说清：客服看得到运单和工单，看不到司机手机号；调度看得到司机手机号，看不到客户的售后退款记录。
行业不同，系统清单的长短差得很远。物流这条线要接三套；医院做一个门诊助手，要接的是挂号系统、电子病历、检验检查报告、合理用药库，随便就是五六套，而且每一套的权限口径都不一样；制造业做设备助手，接的是设备台账、工单系统、备件库存三套，接口成熟度比医疗好，但设备台账里有一半是纸质档案，得先电子化。清单列全再动手，是省返工最有效的一步。
2.3 用量怎么分
最后一个问题是额度。两个团队共用一个平台，谁用多少要有说法。
常见做法是按团队分额度：客服团队一天一万五千次调用，调度团队一天三千次；超出额度时，客服这条线优先，因为它在服务客户，调度这条线排队。
额度这件事必须在需求里写，事后补会变成两个部门之间的扯皮。
3. 平台上由产品经理定的六块
3.1 工具接入
产品经理在这一块定三件事：包成哪几个工具、每个工具的权限范围、每个工具谁能用。这三件事写进工具接入清单（那份清单的模板在讲工具调用与 MCP 那一份的辅文档里）。
研发在这一块做的是技术实现：接口怎么连、参数怎么传、失败怎么重试。产品经理不去定这些。
3.2 编排画布
编排画布上画的是这条流程的骨架：哪几步写死、哪几步交给模型、分岔条件和兜底分支挂在哪。
这一块是产品经理的主场，因为条件全部来自业务规则。「订单金额超过五千要主管复核」这种条件，只有产品经理和业务方能定。
3.3 权限与审计
权限这块产品经理定的是规则：谁能看哪些数据、哪些动作每次要人点头、日志要记哪几栏。研发负责把它落到系统里。
这一块最容易被当成技术活推给研发。推过去的后果在物流那件事上已经出现了：后端按接口原样配，可写的接口一起开了。
3.4 用量额度
额度这一块产品经理定数字和优先级：每个团队多少、超了谁排队。平台侧负责按这个数字做限制和提示。
还有两个数要一起定：额度用到多少时提醒谁，以及用满了之后是拒绝还是降级。物流这条线定的是，用到八成时提醒产品经理和团队负责人，用满之后调度这条线直接拒绝，客服这条线降级到只读状态，查得到、改不了。降级比拒绝更合适放在服务客户的场景上，因为用户至少还能拿到一半的能力。
3.5 提示词、技能与知识库
提示词是产品经理主笔的，因为提示词里写的是业务口径：什么情况答、什么情况不答、答的时候按什么格式。
技能包和知识库的入库规范也归产品经理，但内容要业务方出。运单助手的知识库语料，是客服中心的常见问题解答和调度规则，这两份材料的准确性只有业务方能负责。
把六块并起来，一行的产出物是这样。
| 平台上的块 | 产品经理定什么 | 交付物 |
|---|---|---|
| 工具接入 | 包成几个工具、权限范围、谁能用 | 工具接入清单 |
| 编排画布 | 哪几步写死、条件、兜底分支 | 编排方案表 |
| 权限与审计 | 可见范围、确认点、日志栏位 | 权限与安全清单 |
| 用量额度 | 每个团队多少、超了谁排队 | 额度分配表 |
| 提示词与技能 | 业务口径、触发条件、边界 | 提示词模板、技能包规范 |
| 知识库 | 入库规范、权限标签、更新节奏 | 入库与检索规范 |
六块产出物，哪一块归谁定
每一条先自己挑一档，再点开下面的判定
提示词
- 运单助手的提示词里写着查不到运单就回答系统暂未响应，不猜位置
- 交付物提示词模板，带版本号和变更说明
- 谁签名产品经理
知识库语料
- 要进库的两份材料客服中心的常见问题解答、调度规则
- 产品经理在这一块定的入库规范、权限标签、更新节奏
- 谁签名客服中心负责人
技能包
- 产品经理写的部分触发条件、什么时候不要用它
- 设备科给的部分参数标准区间、上报时限
- 交付物技能包规范
看判定
- 提示词停在「产品经理主笔」：什么情况答、什么情况不答、答的时候按什么格式，写的是业务口径
- 这句话谁定，只有产品经理说得清。
- 知识库语料停在「业务方出内容」：语料的准确性只有业务方能担保
- 规范和内容分开，谁担保准确性谁出内容。
- 技能包停在「两边一起过」：触发条件和边界由产品经理写，判断标准得设备科点头
- 边界写宽了会接走不该接的活，署名要落在写标准的人身上。
签名的位置按「谁能担保」分。
4. 和前端、后端、算法各管到哪
4.1 前端
前端管界面怎么呈现：对话窗口、结果卡片、确认框、进度提示长什么样、点哪个按钮出什么。
产品经理给的是界面要表达什么和字段的含义：确认框里要显示改前和改后的两行、排队的时候要显示前面还有几位。前端决定用什么组件、怎么布局、怎么适配屏幕。
4.2 后端
后端管接口怎么接、数据怎么流、失败怎么重试、日志怎么落。产品经理给的是每个接口的业务含义、权限边界和失败之后用户看到什么。
4.3 算法
算法管模型这一侧：选哪个模型、参数怎么调、评测怎么跑、效果不达标时怎么迭代。
产品经理给的是判断依据：这个场景允许答错到什么程度、哪些字段必须准确、评测用哪批数据。物流那件事里产品经理写「回答要准」，等于什么都没给。
4.4 三处最容易混的边界
第一处是提示词归谁。业务口径的部分归产品经理，格式和工程技巧的部分可以请算法帮忙，但口径本身必须由产品经理签字。
第二处是评测归谁。出题（考什么、什么算对）归产品经理和业务方；跑评测和看指标归算法；两者之间要有一次对齐，否则会出现「算法报的准确率很高，业务方觉得不能用」。
第三处是权限规则归谁。规则归产品经理，实现归后端。这一处混了，就会出现「按接口原样配」。
还有一处常混的是数据口径。字段的业务含义、取值范围、什么情况下为空，归业务方和产品经理；字段的类型、长度、存储格式，归研发。同一个「预计送达时间」，业务上要定的是「按自然日算还是按工作日算、客户看到的是时间段还是具体时刻」，研发要定的是「存成时间戳还是文本」。
5. 需求从谁提、谁拍板、谁验收
5.1 需求从哪来
行业智能体应用的需求一般有三类来源：业务方自己提的效率问题（客服一天接几百通电话、调度靠微信群排车）；平台侧推动的能力落地（平台建好了要有人用）；和外部压力（客户投诉、监管要求）。
三类来源的处理方式不同。业务方提的最贴近真实，但往往只说现象不说范围；平台侧推的最容易被做成「平台有什么就上什么」，要先回到业务这条线判断值不值得做。
一个常见的分布是：业务方提的占七成左右，平台侧推的占两成，外部压力占一成。平台侧推的那两成要额外过一关：这件事如果平台没有这个能力，业务上会不会自己想到要它。答案是不会的，说明它解决的可能是平台的问题，不是业务的问题。
5.2 谁拍板
拍板分两层：这个需求要不要做，由业务的负责人和产品经理一起定；做到什么程度算够，由产品经理定，业务方确认。
技术层面的取舍（用哪种实现方式）不拿到拍板会上讨论，那是研发的活。
5.3 谁验收
验收要落成能逐条核对的清单，每条写清谁看、看到什么算过。验收人分三类：业务方验业务效果，产品经理验功能和管理规则，安全和合规岗验权限与日志。
物流那件事改完之后，验收清单的第一条是「客服团队在对话里提出改排班时，助手回复『这项操作需要调度确认』，不执行改动」，由客服中心的负责人和产品经理一起看。
一份八行的验收单，逐条过一遍
验收表和第一条
- 四列验收项、怎么验、谁验、结果
- 第一条客服提出改排班时，助手回复需要调度确认，不执行改动；怎么验：用客服账号试一次；谁验：客服中心负责人 + 产品经理
- 标通过之后的提示这一条同时有业务方和产品经理签名才算过
- 三类验收人各管什么业务方验业务效果，产品经理验功能和管理规则，安全岗验权限与日志
签名这一栏不写清，验收单就落不了地。
标不通过和走到权限那一行
- 标不通过要填的原因助手直接执行了改动
- 自动生成的待办待修：改排班的写操作未加确认，责任人：后端 + 产品经理
- 第六行「权限与日志」的谁验安全岗；点通过时的提示「安全岗未签名，不能算通过」
- 八行走完之后的结论8 项通过，1 项待修，未通过项不进入发布
没过的这一项不进发布。
验收要落成能逐条核对的清单，每条写清谁看、看到什么算过。
6. 低代码能替掉哪一段
平台上的六块，产品经理自己能动手做完的比例，取决于平台做到什么程度。
工具接入、编排画布、提示词、知识库入库、额度分配这几块，在成熟的低代码平台上产品经理自己就能配。剩下的是必须研发介入的部分：接口本身不存在要新写、权限要跟单位的账号体系打通、日志要落到单位的日志平台、性能撑不住要优化。
这条线的判断方法很简单：凡是「配置就能完成」的，产品经理自己做；凡是「要写代码」或者「要动别的系统」的，交给研发。
一个粗略的经验是七三开：七成能靠配置完成，三成需要研发。比例不重要，重要的是需求评审的时候能把「哪几块我自己做」说清楚，研发才知道要投入多少。
拿「查运单」这个工具说事：产品经理在平台上填工具名、写清参数和权限范围、选上哪几个账号可用，保存就生效，全程不用研发。反过来，如果运单系统缺少「按手机号查单」这条接口，产品经理能做的只是把需求写清楚、推动系统组排期，自己变不出来。
7. 六块交付物落到谁头上
那个助手最后按六块重新过了一遍。
工具接入清单重写了：四十六条接口包成五个工具，九个可写接口里只留两个（改排班、建工单），改排班限定只有调度能用、改之前要调度主管确认，客服那边即使提了要求也只会得到一句「这项操作需要调度确认」。
编排画布上画了三条分岔：查运单走只读链路，改排班走写链路带确认，查工单和建工单各自一条。三条分岔末尾都挂了兜底分支，兜到转人工。
权限与审计写成了清单：客服看不到司机手机号，调度看不到客户的退款记录；日志记六栏，保留一百八十天。
额度按团队分：客服一天一万五千次、调度一天三千次，超出时客服优先。这个数字在需求评审会上由两个团队的负责人一起确认过。
提示词由产品经理主笔，业务口径那几句是客服中心和调度部一起定的。算法同学不再「调模型」，他们负责的是把评测跑起来：用两百道真实问题做评测集，看五个工具的选用准确率和改排班的确认率。
验收清单做了八条，上线那天逐条过，一条没过：改排班的写操作没有加确认。这一条退回，修完再发。四天后重验通过，这一版才算上线。
上线一个月后回头看的数是：日均调用一万一千次，改排班这条链路触发的确认一共七十六次，全部由调度主管点过；没有出现越权改动。
那次返工的四天花在哪儿也记了下来：写验收清单一天，改权限和加确认半天，重验半天，剩下两天在等工单系统的接口打通。四天里只有一天是花在功能上的，其余都花在「本来应该提前写清楚」的地方。
8. 分工对不对，拿七个问题对一遍
| 问题 | 答「否」的时候怎么办 |
|---|---|
| 这条业务线要动哪几套系统，每套的负责人是谁？ | 没列的先去列，找系统负责人确认接口现状 |
| 每个工具谁可以用、能读还是能写，写清了没有？ | 补工具接入清单，可写接口逐条过一遍 |
| 权限规则是由产品经理定的，还是按接口原样配的？ | 按接口原样配的要重来，规则先定再实现 |
| 额度有没有分到团队，超了谁排队？ | 补额度分配表，找两个团队的负责人一起确认 |
| 评测谁出题、谁跑、谁看结果，对过没有？ | 没对的先对一次，出题和跑分是两件事 |
| 验收清单是不是每条都能逐条核对？ | 写不出来的重写，每条要有「怎么验」和「谁验」 |
| 哪几块产品经理自己配，哪几块必须研发做，说清了吗？ | 说不清的先去平台上看一遍能配到什么程度 |
9. 产品经理不定，默认按最省事配出来
把平台能力当成研发全包。 工具怎么包、权限给多大、额度怎么分，这几件事研发替不了，也不能按接口原样配。产品经理不定的部分，默认会被按最省事的做法配出来。
需求里不写权限和用量。 需求写着「支持运单查询与调度协同」，权限和额度一个字没有。上线之后权限出问题、两个团队抢额度，都算在这一条上。
把该自己做的场景判断推给算法。 「回答要准」这种话没法执行。场景允许答错到什么程度、哪些字段必须对、用哪批数据测，这几件事产品经理不写，算法只能自己猜。
10. 分工划清了，用户看到的界面还没定
分工这一块要能划出三条线：平台上哪几块由产品经理定、哪几块交给前端后端算法、一份需求谁提谁拍板谁验收。哪几块能靠平台配置自己完成，也算在判断里。
分工清楚之后，还有一件事是产品经理最直接负责的：用户看到什么。这套助手的确认框里显示哪两行、排队的时候用户看到什么、答不出来的时候界面上给一句话还是给几个候选，这些都还没有定。下一份材料讲 AI 应用的体验设计：结果不固定、要等、会答错这三种情况，在界面上怎么处理。