1. 这份PRD不是文档是跨角色协同的“翻译器”和“共识锚点”我带过17个AI产品从0到1落地最常被拉进会议室救火的场景不是模型跑不起来而是老板拍着桌子问“这功能到底能带来多少GMV”研发盯着需求文档皱眉说“这个‘智能推荐’要怎么实现”而算法同学默默把PRD翻到第3页指着一句“用户画像要足够精准”叹气“请问精准的定义是什么误差率低于多少算达标”——这根本不是需求写得不够细而是我们默认用同一套语言在跟三类人说话老板听的是商业结果研发听的是技术路径AI工程师听的是数据与指标。所谓“老板/研发/AI都爱的PRD”本质不是讨好所有人而是用三套语言在同一份文档里讲同一件事并让每类角色都能在自己的专业语境里找到唯一解。它不叫产品需求文档我更愿意叫它跨职能对齐协议Cross-Functional Alignment Protocol。核心关键词就三个可量化、可拆解、可验证。没有“提升用户体验”这种虚词只有“首页点击率提升≥8%AB测试置信度95%”没有“支持多模态输入”而是“支持用户上传图片语音≤30秒文字三种输入方式语音识别ASR准确率≥92%CER”没有“模型要聪明”而是“在电商搜索场景下Query意图识别F1-score ≥0.87测试集覆盖长尾Query占比≥15%”。这份文档的价值从来不在写得多漂亮而在上线前就把所有人的预期钉死在同一个坐标系里。如果你现在手里的PRD还停留在“用户登录后看到欢迎页”这种描述层级那它大概率会在开发中途被推翻三次——不是因为需求错了而是因为没人知道“欢迎页”到底要解决什么问题、用什么数据证明它解决了。接下来我会拆解如何用一套结构化框架把模糊的AI能力想象变成老板敢签字、研发敢排期、算法敢承诺的硬性契约。2. 为什么传统PRD在AI项目里会失效——三类角色的认知鸿沟与致命断点2.1 老板视角他要的是“确定性ROI”不是“技术可能性”老板打开PRD第一眼找的永远是三个数字投入成本、上线周期、预期收益。但他不会直接问你“模型训练要多久”他会问“上这个智能客服客服人力成本能降多少客户满意度NPS能提几个点如果三个月没见效我们止损的阈值在哪”——传统PRD常犯的致命错误是把技术方案当成果写。比如写“采用BERT微调方案”老板看到只会困惑这玩意儿和省钱有什么关系正确的写法必须建立技术动作→业务指标→财务影响的强因果链。举个真实案例某金融APP要做智能投顾助手原始PRD写“接入大模型生成投资建议”。我重写后第一段是“目标将人工投顾响应时效从平均4.2小时压缩至实时3秒覆盖80%标准化咨询如‘如何赎回基金’‘手续费是多少’预计减少60%基础咨询人力年节省成本约280万元按当前12名初级投顾年薪均值计算”。这里每个数字都有出处4.2小时来自客服系统后台日志统计80%覆盖率基于过去半年咨询工单分类分析280万是HR提供的标准人力成本模型。老板看到这个立刻能判断“值不值得投”。他不需要懂BERT他需要知道钱花在哪、回本周期多长、风险边界在哪。所以PRD开篇必须设商业目标声明区Business Objective Statement用表格强制填写指标维度当前基线目标值达成路径一句话数据验证方式责任方客服响应时效4.2小时3秒用RAG架构替代人工检索埋点监控P95响应时长后端算法标准化咨询覆盖率0%80%构建1200条FAQ知识图谱工单分类抽样审计产品运营人力成本节省—280万元/年减少6名初级投顾编制HR系统人力预算表财务HR这张表就是老板签字的底线。没填满别提交。2.2 研发视角他要的是“可执行接口”不是“功能描述”研发工程师最怕的PRD是通篇用产品经理的“人话”描述技术行为。比如写“用户上传图片后系统自动识别商品并推荐相似款”这等于没说。他需要知道输入格式是什么输出字段有哪些超时时间多少失败怎么兜底AI项目尤其如此因为模型服务不是传统API它有概率性、延迟波动、资源消耗等特殊属性。我见过太多PRD在这里翻车产品写“支持图片识别”研发按常规HTTP接口设计结果模型推理耗时2.3秒超了设定的800ms SLA整个页面卡顿。根源在于没定义AI服务的非功能性需求Non-Functional Requirements, NFR。必须在PRD中单独设立AI服务契约章节AI Service Contract用代码注释般的精确语言约定【服务名称】商品图像识别APIv1.2 【请求方式】POST /api/v1/recognize-image 【输入约束】 - 图片格式JPEG/PNG尺寸≤1024x1024像素大小≤2MB - 单次请求仅支持1张图片不支持批量 - 请求头必须携带X-Request-ID用于全链路追踪 【输出规范】 - 成功响应HTTP 200 { item_id: string, // 识别出的商品ID主键 confidence_score: 0.92, // 置信度0~1保留2位小数 similar_items: [ // 推荐相似商品列表最多5个 {id: SKU-123, score: 0.87}, {id: SKU-456, score: 0.79} ], processing_time_ms: 420 // 实际处理耗时毫秒 } - 失败响应HTTP 4xx/5xx {error_code: IMAGE_INVALID, message: 图片分辨率超出限制} 【SLA要求】 - P95响应时长 ≤ 800ms含网络传输 - 可用性 ≥ 99.5%月度统计 - 错误率 ≤ 0.3%HTTP 4xx/5xx占比 【降级策略】 - 当模型服务不可用时返回HTTP 503前端展示“识别中请稍候”并启用本地缓存的Top10热门商品作为兜底推荐这段内容不是给老板看的是给研发写代码、给运维配监控、给测试写用例的依据。少一个字段开发就要来问你十次少一个SLA上线后性能抖动你就背锅。我坚持要求所有AI相关接口必须由产品、研发、算法三方在PRD评审会上逐行确认——这不是流程形式主义而是把“我以为你知道”变成“我们共同确认”。2.3 AI工程师视角他要的是“可评估指标”不是“效果形容词”算法同学最反感的PRD是充斥着“更智能”“更精准”“用户体验更好”这类玄学词汇。他们需要的是可测量、可复现、可归因的评估基准Evaluation Benchmark。比如写“搜索结果更相关”这无法验收。正确写法是定义评估数据集、评估指标、基线模型、达标阈值四要素。以电商搜索为例我在PRD中这样写【搜索相关性评估协议】评估数据集使用2023年Q4真实用户搜索日志抽样10,000条Query覆盖品牌词/品类词/长尾词比例3:5:2每条Query人工标注3个相关商品Golden Standard。评估指标主指标Normalized Discounted Cumulative Gain 5 (NDCG5)次指标Precision3前3个结果中相关商品占比基线模型当前线上ES关键词匹配模型NDCG5 0.42达标阈值新AI模型NDCG5 ≥ 0.65提升≥54.8%p-value 0.01验证方式A/B测试期间随机分流5%流量至新模型连续7天采集NDCG5数据由数据科学团队出具统计报告注意这里的关键细节数据来源明确2023年Q4日志避免算法用合成数据糊弄抽样规则透明品牌/品类/长尾比例防止只测简单Case指标选择有行业依据NDCG5是搜索领域黄金标准不是拍脑袋阈值计算有逻辑54.8%提升对应业务侧要求的转化率提升目标验证方式闭环A/B测试统计报告杜绝“我觉得效果好”。我曾遇到一个项目算法声称模型效果提升显著但PRD里没定义评估协议。上线后运营反馈点击率下降算法却说“我的指标涨了”。最后发现他用的是Accuracy准确率而搜索场景真正重要的是NDCG——因为用户只看前3个结果后面全错也没关系。这就是没定义评估协议的代价。PRD里关于AI效果的部分必须像法律条文一样精确容不得半点模糊。3. “三合一”PRD结构设计用一张表串联商业、工程、算法三重视角3.1 核心框架需求卡片Requirement Card——最小原子化单元传统PRD按模块写用户管理、订单管理AI项目必须按原子需求组织。我把每个需求拆成一张独立卡片强制包含商业、工程、算法三重视角确保任何一方都能快速定位自己关心的信息。卡片模板如下以“智能客服自动解答退货政策”为例【需求卡片 #RD-023】智能客服自动解答退货政策▶ 商业视角Why What业务目标将退货政策类咨询的人工介入率从65%降至≤20%缩短用户等待时长至15秒当前平均128秒价值测算预计每月减少人工客服工时240小时折合成本节约≈1.8万元用户退货流程完成率提升12%基于历史数据回归分析成功信号上线后30天内退货政策类咨询的“首次响应即解决率”≥85%客服系统埋点统计▶ 工程视角How to Build功能范围支持用户输入文本如“退货要多久”“能退现金吗”或语音ASR转文本后处理输出结构化答案含步骤清单1. 2. 3.、时效说明“7个工作日内到账”、例外条款“定制商品不支持无理由退货”技术约束答案生成必须基于预置知识库JSON格式含23条退货政策条款禁止联网搜索响应超时800msP95超时则返回预设兜底话术交付物REST API/api/v1/return-policy输入Query输出结构化JSON前端SDK支持Web/App/H5三端调用含加载状态提示▶ 算法视角How to Measure数据要求训练数据2023年退货咨询对话日志5,000条脱敏后标注意图退货时效/退款方式/例外情形测试集人工构建300条覆盖边缘Case的Query如“我买的是二手手机能退吗”模型指标意图识别准确率 ≥ 94%测试集答案相关性NDCG3 ≥ 0.82人工评分5分制≥4分视为相关上线验证A/B测试新旧策略各50%流量对比“首次响应即解决率”与“用户追问率”监控告警当意图识别准确率连续2小时90%触发算法团队预警这张卡片的价值在于老板看第一栏就知道值不值得投研发看第二栏就知道怎么开发算法看第三栏就知道怎么训练和验收。它把模糊的“智能客服”拆解成可分工、可排期、可验收的具体任务。我要求团队所有需求必须先生成卡片再汇总成PRD——没有卡片的需求一律不进入排期。3.2 动态优先级矩阵用“影响-可行性”四象限驱动决策AI项目最大的陷阱是试图一次性解决所有问题。PRD里必须内置动态优先级机制告诉所有人“为什么先做这个而不是那个”。我用一张二维矩阵图不放图用文字描述替代模糊的“高优/中优”标签高可行性已有数据/模型/接口低可行性需新建数据管道/训练模型高业务影响直接影响营收/成本立即启动P0• 退货政策自动解答已有23条政策文本可RAG快速上线• 订单状态实时查询对接现有订单中心API分阶段启动P1• 智能推荐需构建用户行为图谱分两期先做热度推荐再做协同过滤低业务影响优化体验/锦上添花暂缓P2• 客服对话情感分析当前无业务场景调用冻结P3• 语音客服方言识别覆盖用户5%ROI为负关键点在于每个象限的判定必须附带证据。比如“高可行性”不能只写“技术成熟”要写“RAG框架已在XX项目验证QPS≥2000延迟300ms”。老板看到P0需求旁标注“已验证框架”就会放心签字研发看到P1需求注明“分两期”就知道第一期只需调用现有热度接口不用等算法训练。这个矩阵不是静态的PRD里要注明“每双周根据数据表现和业务变化更新优先级”并留出更新记录栏。我见过太多项目死在“所有需求都是P0”的幻觉里——用这张表把主观判断变成客观证据链。3.3 风险对冲清单把“可能出问题的地方”提前写进PRDAI项目的不确定性远高于传统软件PRD里必须有风险对冲章节Risk Hedging Section不是罗列风险而是写清楚“如果发生我们怎么应对”。这是让老板敢决策、研发敢投入的关键。我按风险类型分三类▶ 数据风险AI的粮食危机风险退货政策知识库更新滞后导致回答过时如促销期临时政策未同步对冲方案建立知识库双签机制法务审核客服主管确认更新后2小时内自动触发模型重训设置“政策时效性”元数据字段答案中强制显示“本政策更新于2024-03-15”当检测到用户提问含“最近”“刚”等时间敏感词且知识库无对应更新时自动转人工并标记“政策时效性待确认”▶ 模型风险黑箱的不可控性风险意图识别模型在长尾Query上准确率骤降如用户问“我昨天买的耳机今天能退吗”对冲方案部署Query复杂度检测模块当句子长度30字或含多个否定词时自动降级至规则引擎基于关键词匹配设置“置信度熔断阀”当模型输出confidence_score 0.75强制返回“请描述更具体的问题例如您想了解退货时效、退款方式还是例外情况”每日自动抽取低置信度Query推送至算法团队进行bad case分析▶ 工程风险服务的脆弱性风险GPU服务器突发故障导致AI服务不可用超过5分钟对冲方案预留2台CPU服务器运行轻量级规则引擎覆盖80%高频Query故障时自动切流前端增加“智能模式开关”用户可手动切换至传统FAQ列表不依赖AI监控告警升级当AI服务错误率1%持续1分钟立即通知值班研发产品负责人这些方案不是应急预案而是PRD的组成部分。老板看到“政策时效性双签机制”就知道风控有抓手研发看到“CPU服务器预留”就知道不用临时加班扩容算法看到“每日bad case推送”就知道迭代有数据支撑。风险不是用来回避的是用结构化方案把它变成可控变量。4. 实操一份完整AI PRD的诞生过程从0到1手把手4.1 第一步用“三句话挑战法”校准需求本质很多AI需求一开始就是伪命题。我要求团队在写PRD前必须通过“三句话挑战”用一句大白话告诉老板这事能帮他省多少钱或赚多少钱例不是“做智能推荐”而是“把首页商品曝光点击率从3.2%提到4.1%预计月增GMV 180万元”用一句技术语言告诉研发这事需要调用几个接口、改几行代码、加什么监控例不是“提升推荐效果”而是“替换/recommend接口输入增加user_embedding向量输出增加score字段新增GPU节点监控GPU显存占用率”用一句评估语言告诉算法这事用什么数据、什么指标、多少天能验证是否成功例不是“模型更好”而是“用2024年1月用户行为日志训练AUC提升0.03A/B测试7天后看CTR变化”通不过任意一句需求就退回重想。我曾否掉一个“AI生成营销文案”的需求因为产品说“让文案更吸引人”——老板问“吸引人多少转化率提升”研发问“生成文案要对接哪个内容库”算法问“用什么指标评估‘吸引人’”。直到产品拿出历史数据同类活动文案点击率均值1.8%目标提升至2.5%评估用A/B测试点击率用户停留时长才允许进入PRD编写。这一步看似慢实则省去后期80%的返工。4.2 第二步搭建PRD骨架——六个必含章节与禁忌AI PRD不是传统文档的加长版它有独特骨架。我坚持六个核心章节缺一不可且每个章节都有明确禁忌▶ 第一章商业目标与成功定义严禁出现“提升体验”“增强粘性”等虚词必须包含量化目标如“将新用户7日留存率从28%提升至35%”、达成路径“通过个性化新手引导降低学习门槛”、验证方式“埋点统计新用户第7天DAU”、失败阈值“若30天内留存率32%启动预案”禁忌写“打造行业领先的产品”老板不知道领先在哪写“让用户爱上我们的产品”研发不知道怎么实现“爱上”。▶ 第二章用户旅程与AI触点地图严禁画泛泛的“用户旅程图”必须标注每个AI介入点的触发条件如“用户在注册页停留60秒且未点击下一步”、AI动作“弹出智能引导检测到您可能需要帮助点击获取3步注册教程”、退出机制“用户点击‘跳过’或关闭弹窗永久屏蔽该引导”禁忌只画“用户从A到B再到C”不标AI在哪介入、怎么介入、用户怎么拒绝。▶ 第三章需求卡片集严禁按功能模块归类所有需求必须是独立卡片如前所述按优先级排序每张卡含商业/工程/算法三栏禁忌写“智能客服模块”必须拆成“退货政策解答”“物流查询”“优惠券使用”等原子卡片。▶ 第四章AI服务契约严禁用自然语言描述接口必须用前述代码注释式格式定义输入/输出/SLA/降级策略禁忌写“提供图片识别能力”必须写清尺寸/格式/超时/错误码。▶ 第五章评估与验证协议严禁只写“上线后看效果”必须明确评估数据集来源与规模、核心指标及计算公式、基线模型与阈值、A/B测试分流比例与周期、报告出具方禁忌写“通过用户调研验证”必须写清调研样本量、问卷问题、统计方法。▶ 第六章风险对冲与演进路线严禁写“后续考虑”“未来扩展”必须写清当前版本的风险应对方案以及下一版本的明确交付物如“V2.0交付支持语音输入需新增ASR服务契约”禁忌写“未来支持多语言”必须写“V2.0交付支持英语/日语需采购XX语音API预算12万元”。这个骨架保证PRD从诞生起就具备可执行性。我曾用这套结构在一个医疗AI项目中让老板在评审会上当场签字——因为他看到第一章就清楚知道“上线后每月减少300小时医生文书工作折合人力成本12万元”看到第四章就确认“接口能扛住日活50万用户的并发”看到第五章就相信“7天A/B测试就能验证效果”。文档的价值就是把不确定性变成确定性。4.3 第三步PRD评审会实战技巧——让三方达成共识的“三把尺子”PRD写完只是开始评审会才是真正的战场。我主持过上百场评审总结出让老板、研发、AI工程师同时点头的“三把尺子”▶ 尺子一老板的“钱尺子”——只问三个问题“这事投多少钱什么时候能回本”要求PRD中成本明细ROI测算表“如果失败最大损失是什么谁来负责”要求PRD中风险对冲方案责任人“这事不做竞争对手做了我们会丢什么”要求PRD中竞品分析简表列明对手已上线功能及效果只要这三个问题在PRD里有明确答案老板基本会签字。他不需要懂技术只需要知道钱花得值、风险可控、不落后。▶ 尺子二研发的“代码尺子”——只认三样东西“接口文档在哪字段都定义好了吗”指向第四章AI服务契约“SLA达标需要多少服务器GPU型号和数量”要求PRD附基础设施需求表如“需2台A10 GPU服务器内存≥64GB”“失败时怎么降级前端怎么配合”指向第六章风险对冲中的工程方案研发不关心AI多酷只关心能不能写出稳定、可维护的代码。PRD里这些信息越全他们越愿意接。▶ 尺子三算法的“数据尺子”——只盯三个数据“训练数据在哪质量怎么样”要求PRD附数据来源说明样本示例如“2023年客服对话日志已脱敏含5000条标注数据”“评估指标怎么算基线是多少”指向第五章评估协议必须给出计算公式和基线数值“bad case怎么收集多久迭代一次”要求PRD写明bad case自动采集机制迭代周期如“每日凌晨自动抓取置信度0.7的Query算法团队T1分析”算法最怕闭门造车。PRD里把数据、指标、迭代机制写死他们才有信心承诺效果。评审会不是宣讲会是三方用这三把尺子共同丈量PRD的时刻。我习惯把PRD打印出来每章贴一张便利贴评审时直接翻到对应章节回答问题。当老板问“ROI怎么算”我就翻到第一章的ROI测算表当研发问“GPU要几台”我就翻到第四章的基础设施需求表。用文档本身说话比任何口头解释都管用。5. 常见问题与避坑指南那些血泪换来的实战经验5.1 问题一老板总说“再想想”其实是没看到确定性现象PRD写了20页老板还是犹豫不决反复说“这个方向不错但我们再评估评估”。根因PRD里缺乏老板决策所需的确定性锚点——他看不到钱、看不到风险、看不到竞品压力。解决方案在PRD开篇加一页决策速查表Decision Quick-Reference Sheet用三栏极简呈现决策维度当前状态风险控制竞品对标投入成本总预算85万元含GPU服务器32万人力53万首期只投入35万验证ROI后再追加A公司投入120万B公司投入60万回本周期预计6.2个月基于GMV提升测算若12个月未回本自动终止二期投入A公司宣称4.8个月B公司未公布最大风险模型效果不达预期概率30%已部署规则引擎兜底保障基础功能可用A公司上线首月故障率12%B公司5%这张表不是补充材料是PRD的第一页。老板扫一眼就能抓住核心不用在20页文档里找答案。我试过加了这张表后老板签字速度平均提升70%。记住老板不是不想签是不敢签——你得给他签的底气。5.2 问题二研发抱怨“需求天天变”其实是PRD没锁死边界现象开发到一半产品突然说“加个语音输入吧”研发崩溃“接口都写完了”根因PRD里没定义需求变更熔断机制导致边界模糊。解决方案在PRD末尾强制加入需求冻结协议Requirement Freeze Agreement【需求冻结条款】V1.0 PRD于2024-03-20正式冻结此后所有需求变更视为V2.0范畴冻结期内仅接受两类变更①阻塞性Bug修复如安全漏洞、核心功能不可用②法规强制要求如新出台的数据合规条例其他变更如新增功能、修改UI、调整指标必须提交《需求变更影响评估表》列明对工期、成本、测试范围的影响经产品、研发、算法三方签字确认重新签署PRD修订版这条款不是束缚而是保护。它让研发知道“我按这个干就不会被临时加活”让产品明白“加需求要付出代价”让老板清楚“变更意味着延期和超支”。我曾用这个条款把一个项目的需求变更次数从平均12次压到0次——因为所有人知道改一个字都要三方签字自然就慎重了。5.3 问题三算法说“效果达不到”其实是评估方式没对齐现象算法提交模型测试指标达标但上线后业务指标没提升互相指责。根因PRD里评估协议与业务目标脱节算法优化的指标不是业务关心的指标。解决方案在PRD中建立指标映射表Metric Mapping Table强制关联业务目标对应业务指标技术可测指标映射逻辑验证方式提升用户购买意愿商品详情页转化率CVR推荐列表CTR点击率CTR每提升1%CVR提升0.3%基于历史回归系数A/B测试同期对比CVR变化缩短客服响应时间平均首次响应时长API P95响应时长响应时长3秒时用户放弃率下降42%历史数据埋点监控响应时长与放弃率相关性这张表让算法知道“我优化CTR就是在帮业务提CVR”让老板知道“你们测CTR其实是在测我的GMV”让研发知道“我把P95压到3秒就能让老板满意”。指标不再割裂而是形成一条从技术动作到商业结果的完整证据链。我坚持所有AI项目PRD必须有此表否则不予评审。5.4 问题四PRD写得巨细无遗但没人看——因为没做“角色定制版”现象PRD文档厚重老板只看第一页研发只看接口章节算法只看评估章节其他人懒得翻。根因把一份文档当三份文档用没做信息分层。解决方案PRD交付时同步生成三份角色定制版Role-Tailored Versions老板速览版1页PDF只含商业目标、ROI测算、风险对冲、决策速查表研发执行版接口手册SLA表只含第四章AI服务契约、第六章工程风险方案、基础设施需求表算法实验版评估协议数据说明只含第五章评估协议、第三章需求卡片中的算法栏、数据来源说明这三份文档从同一份PRD源文件自动生成用Markdown模板脚本确保信息一致。老板开会前5分钟看速览版就能决策研发拿到执行版就能开工算法打开实验版就知道怎么训练。信息过载不是文档太厚而是没给对的人看对的内容。我团队现在PRD交付必附这三份定制版阅读率从32%提升到91%。5.5 问题五模板套用千篇一律失去AI项目的独特性现象下载网上PRD模板填空式写作结果老板觉得假大空研发觉得不落地。根因把AI PRD当成传统PRD的变体忽略了AI特有的不确定性、数据依赖、模型迭代三大特性。解决方案在模板中嵌入AI特性强化模块每个模块解决一个核心痛点不确定性缓冲模块在每张需求卡片中强制填写“最差情况应对”如“若模型准确率仅达85%低于目标94%则启用规则引擎人工审核双通道”数据主权模块在PRD开头声明“本项目数据所有权归属甲方模型训练数据需经甲方书面授权训练日志需留存6个月备查”模型迭代模块在第六章明确“V1.0上线后算法团队每月提交模型迭代报告包含bad case分析、指标变化、下月优化计划产品有权否决不符合业务目标的迭代”这些模块不是锦上添花是AI项目的生存必需。没有不确定性缓冲上线就可能崩盘没有数据主权声明法务会否决项目没有模型迭代机制AI就会变成一潭死水。我见过太多项目死在“以为AI模型一次训练就永远有效”的幻觉里——PRD必须把AI的“活”特性写进骨子里。6. 最后分享一个真实教训我们曾因漏掉一行字导致项目延期47天去年做一个银行智能风控项目PRD里写“支持实时交易风险识别”看起来很完整。评审时老板、研发、算法都签了字。上线前压力测试发现TPS每秒事务数卡在1200远低于银行要求的5000。研发排查一周发现瓶颈在模型推理——原来我们没在PRD里定义GPU显存占用上限。算法用的模型显存峰值达16GB而采购的A10服务器只有24GB显存跑两个实例就爆了。临时换卡采购周期30天。优化模型算法说至少2周。最后只能紧急扩容多花了87万元。这个教训刻在我脑子里AI PRD里硬件资源约束不是运维的事是产品的事。从此我在PRD第四章AI服务契约里强制增加一行【资源约束】GPU显存占用 ≤ 12GB单实例CPU内存占用 ≤ 8GB单实例磁盘IO吞吐 ≥ 200MB/s模型加载阶段并且要求算法在提交模型 AI产品PRD：跨角色对齐的量化契约与可验证协议
1. 这份PRD不是文档是跨角色协同的“翻译器”和“共识锚点”我带过17个AI产品从0到1落地最常被拉进会议室救火的场景不是模型跑不起来而是老板拍着桌子问“这功能到底能带来多少GMV”研发盯着需求文档皱眉说“这个‘智能推荐’要怎么实现”而算法同学默默把PRD翻到第3页指着一句“用户画像要足够精准”叹气“请问精准的定义是什么误差率低于多少算达标”——这根本不是需求写得不够细而是我们默认用同一套语言在跟三类人说话老板听的是商业结果研发听的是技术路径AI工程师听的是数据与指标。所谓“老板/研发/AI都爱的PRD”本质不是讨好所有人而是用三套语言在同一份文档里讲同一件事并让每类角色都能在自己的专业语境里找到唯一解。它不叫产品需求文档我更愿意叫它跨职能对齐协议Cross-Functional Alignment Protocol。核心关键词就三个可量化、可拆解、可验证。没有“提升用户体验”这种虚词只有“首页点击率提升≥8%AB测试置信度95%”没有“支持多模态输入”而是“支持用户上传图片语音≤30秒文字三种输入方式语音识别ASR准确率≥92%CER”没有“模型要聪明”而是“在电商搜索场景下Query意图识别F1-score ≥0.87测试集覆盖长尾Query占比≥15%”。这份文档的价值从来不在写得多漂亮而在上线前就把所有人的预期钉死在同一个坐标系里。如果你现在手里的PRD还停留在“用户登录后看到欢迎页”这种描述层级那它大概率会在开发中途被推翻三次——不是因为需求错了而是因为没人知道“欢迎页”到底要解决什么问题、用什么数据证明它解决了。接下来我会拆解如何用一套结构化框架把模糊的AI能力想象变成老板敢签字、研发敢排期、算法敢承诺的硬性契约。2. 为什么传统PRD在AI项目里会失效——三类角色的认知鸿沟与致命断点2.1 老板视角他要的是“确定性ROI”不是“技术可能性”老板打开PRD第一眼找的永远是三个数字投入成本、上线周期、预期收益。但他不会直接问你“模型训练要多久”他会问“上这个智能客服客服人力成本能降多少客户满意度NPS能提几个点如果三个月没见效我们止损的阈值在哪”——传统PRD常犯的致命错误是把技术方案当成果写。比如写“采用BERT微调方案”老板看到只会困惑这玩意儿和省钱有什么关系正确的写法必须建立技术动作→业务指标→财务影响的强因果链。举个真实案例某金融APP要做智能投顾助手原始PRD写“接入大模型生成投资建议”。我重写后第一段是“目标将人工投顾响应时效从平均4.2小时压缩至实时3秒覆盖80%标准化咨询如‘如何赎回基金’‘手续费是多少’预计减少60%基础咨询人力年节省成本约280万元按当前12名初级投顾年薪均值计算”。这里每个数字都有出处4.2小时来自客服系统后台日志统计80%覆盖率基于过去半年咨询工单分类分析280万是HR提供的标准人力成本模型。老板看到这个立刻能判断“值不值得投”。他不需要懂BERT他需要知道钱花在哪、回本周期多长、风险边界在哪。所以PRD开篇必须设商业目标声明区Business Objective Statement用表格强制填写指标维度当前基线目标值达成路径一句话数据验证方式责任方客服响应时效4.2小时3秒用RAG架构替代人工检索埋点监控P95响应时长后端算法标准化咨询覆盖率0%80%构建1200条FAQ知识图谱工单分类抽样审计产品运营人力成本节省—280万元/年减少6名初级投顾编制HR系统人力预算表财务HR这张表就是老板签字的底线。没填满别提交。2.2 研发视角他要的是“可执行接口”不是“功能描述”研发工程师最怕的PRD是通篇用产品经理的“人话”描述技术行为。比如写“用户上传图片后系统自动识别商品并推荐相似款”这等于没说。他需要知道输入格式是什么输出字段有哪些超时时间多少失败怎么兜底AI项目尤其如此因为模型服务不是传统API它有概率性、延迟波动、资源消耗等特殊属性。我见过太多PRD在这里翻车产品写“支持图片识别”研发按常规HTTP接口设计结果模型推理耗时2.3秒超了设定的800ms SLA整个页面卡顿。根源在于没定义AI服务的非功能性需求Non-Functional Requirements, NFR。必须在PRD中单独设立AI服务契约章节AI Service Contract用代码注释般的精确语言约定【服务名称】商品图像识别APIv1.2 【请求方式】POST /api/v1/recognize-image 【输入约束】 - 图片格式JPEG/PNG尺寸≤1024x1024像素大小≤2MB - 单次请求仅支持1张图片不支持批量 - 请求头必须携带X-Request-ID用于全链路追踪 【输出规范】 - 成功响应HTTP 200 { item_id: string, // 识别出的商品ID主键 confidence_score: 0.92, // 置信度0~1保留2位小数 similar_items: [ // 推荐相似商品列表最多5个 {id: SKU-123, score: 0.87}, {id: SKU-456, score: 0.79} ], processing_time_ms: 420 // 实际处理耗时毫秒 } - 失败响应HTTP 4xx/5xx {error_code: IMAGE_INVALID, message: 图片分辨率超出限制} 【SLA要求】 - P95响应时长 ≤ 800ms含网络传输 - 可用性 ≥ 99.5%月度统计 - 错误率 ≤ 0.3%HTTP 4xx/5xx占比 【降级策略】 - 当模型服务不可用时返回HTTP 503前端展示“识别中请稍候”并启用本地缓存的Top10热门商品作为兜底推荐这段内容不是给老板看的是给研发写代码、给运维配监控、给测试写用例的依据。少一个字段开发就要来问你十次少一个SLA上线后性能抖动你就背锅。我坚持要求所有AI相关接口必须由产品、研发、算法三方在PRD评审会上逐行确认——这不是流程形式主义而是把“我以为你知道”变成“我们共同确认”。2.3 AI工程师视角他要的是“可评估指标”不是“效果形容词”算法同学最反感的PRD是充斥着“更智能”“更精准”“用户体验更好”这类玄学词汇。他们需要的是可测量、可复现、可归因的评估基准Evaluation Benchmark。比如写“搜索结果更相关”这无法验收。正确写法是定义评估数据集、评估指标、基线模型、达标阈值四要素。以电商搜索为例我在PRD中这样写【搜索相关性评估协议】评估数据集使用2023年Q4真实用户搜索日志抽样10,000条Query覆盖品牌词/品类词/长尾词比例3:5:2每条Query人工标注3个相关商品Golden Standard。评估指标主指标Normalized Discounted Cumulative Gain 5 (NDCG5)次指标Precision3前3个结果中相关商品占比基线模型当前线上ES关键词匹配模型NDCG5 0.42达标阈值新AI模型NDCG5 ≥ 0.65提升≥54.8%p-value 0.01验证方式A/B测试期间随机分流5%流量至新模型连续7天采集NDCG5数据由数据科学团队出具统计报告注意这里的关键细节数据来源明确2023年Q4日志避免算法用合成数据糊弄抽样规则透明品牌/品类/长尾比例防止只测简单Case指标选择有行业依据NDCG5是搜索领域黄金标准不是拍脑袋阈值计算有逻辑54.8%提升对应业务侧要求的转化率提升目标验证方式闭环A/B测试统计报告杜绝“我觉得效果好”。我曾遇到一个项目算法声称模型效果提升显著但PRD里没定义评估协议。上线后运营反馈点击率下降算法却说“我的指标涨了”。最后发现他用的是Accuracy准确率而搜索场景真正重要的是NDCG——因为用户只看前3个结果后面全错也没关系。这就是没定义评估协议的代价。PRD里关于AI效果的部分必须像法律条文一样精确容不得半点模糊。3. “三合一”PRD结构设计用一张表串联商业、工程、算法三重视角3.1 核心框架需求卡片Requirement Card——最小原子化单元传统PRD按模块写用户管理、订单管理AI项目必须按原子需求组织。我把每个需求拆成一张独立卡片强制包含商业、工程、算法三重视角确保任何一方都能快速定位自己关心的信息。卡片模板如下以“智能客服自动解答退货政策”为例【需求卡片 #RD-023】智能客服自动解答退货政策▶ 商业视角Why What业务目标将退货政策类咨询的人工介入率从65%降至≤20%缩短用户等待时长至15秒当前平均128秒价值测算预计每月减少人工客服工时240小时折合成本节约≈1.8万元用户退货流程完成率提升12%基于历史数据回归分析成功信号上线后30天内退货政策类咨询的“首次响应即解决率”≥85%客服系统埋点统计▶ 工程视角How to Build功能范围支持用户输入文本如“退货要多久”“能退现金吗”或语音ASR转文本后处理输出结构化答案含步骤清单1. 2. 3.、时效说明“7个工作日内到账”、例外条款“定制商品不支持无理由退货”技术约束答案生成必须基于预置知识库JSON格式含23条退货政策条款禁止联网搜索响应超时800msP95超时则返回预设兜底话术交付物REST API/api/v1/return-policy输入Query输出结构化JSON前端SDK支持Web/App/H5三端调用含加载状态提示▶ 算法视角How to Measure数据要求训练数据2023年退货咨询对话日志5,000条脱敏后标注意图退货时效/退款方式/例外情形测试集人工构建300条覆盖边缘Case的Query如“我买的是二手手机能退吗”模型指标意图识别准确率 ≥ 94%测试集答案相关性NDCG3 ≥ 0.82人工评分5分制≥4分视为相关上线验证A/B测试新旧策略各50%流量对比“首次响应即解决率”与“用户追问率”监控告警当意图识别准确率连续2小时90%触发算法团队预警这张卡片的价值在于老板看第一栏就知道值不值得投研发看第二栏就知道怎么开发算法看第三栏就知道怎么训练和验收。它把模糊的“智能客服”拆解成可分工、可排期、可验收的具体任务。我要求团队所有需求必须先生成卡片再汇总成PRD——没有卡片的需求一律不进入排期。3.2 动态优先级矩阵用“影响-可行性”四象限驱动决策AI项目最大的陷阱是试图一次性解决所有问题。PRD里必须内置动态优先级机制告诉所有人“为什么先做这个而不是那个”。我用一张二维矩阵图不放图用文字描述替代模糊的“高优/中优”标签高可行性已有数据/模型/接口低可行性需新建数据管道/训练模型高业务影响直接影响营收/成本立即启动P0• 退货政策自动解答已有23条政策文本可RAG快速上线• 订单状态实时查询对接现有订单中心API分阶段启动P1• 智能推荐需构建用户行为图谱分两期先做热度推荐再做协同过滤低业务影响优化体验/锦上添花暂缓P2• 客服对话情感分析当前无业务场景调用冻结P3• 语音客服方言识别覆盖用户5%ROI为负关键点在于每个象限的判定必须附带证据。比如“高可行性”不能只写“技术成熟”要写“RAG框架已在XX项目验证QPS≥2000延迟300ms”。老板看到P0需求旁标注“已验证框架”就会放心签字研发看到P1需求注明“分两期”就知道第一期只需调用现有热度接口不用等算法训练。这个矩阵不是静态的PRD里要注明“每双周根据数据表现和业务变化更新优先级”并留出更新记录栏。我见过太多项目死在“所有需求都是P0”的幻觉里——用这张表把主观判断变成客观证据链。3.3 风险对冲清单把“可能出问题的地方”提前写进PRDAI项目的不确定性远高于传统软件PRD里必须有风险对冲章节Risk Hedging Section不是罗列风险而是写清楚“如果发生我们怎么应对”。这是让老板敢决策、研发敢投入的关键。我按风险类型分三类▶ 数据风险AI的粮食危机风险退货政策知识库更新滞后导致回答过时如促销期临时政策未同步对冲方案建立知识库双签机制法务审核客服主管确认更新后2小时内自动触发模型重训设置“政策时效性”元数据字段答案中强制显示“本政策更新于2024-03-15”当检测到用户提问含“最近”“刚”等时间敏感词且知识库无对应更新时自动转人工并标记“政策时效性待确认”▶ 模型风险黑箱的不可控性风险意图识别模型在长尾Query上准确率骤降如用户问“我昨天买的耳机今天能退吗”对冲方案部署Query复杂度检测模块当句子长度30字或含多个否定词时自动降级至规则引擎基于关键词匹配设置“置信度熔断阀”当模型输出confidence_score 0.75强制返回“请描述更具体的问题例如您想了解退货时效、退款方式还是例外情况”每日自动抽取低置信度Query推送至算法团队进行bad case分析▶ 工程风险服务的脆弱性风险GPU服务器突发故障导致AI服务不可用超过5分钟对冲方案预留2台CPU服务器运行轻量级规则引擎覆盖80%高频Query故障时自动切流前端增加“智能模式开关”用户可手动切换至传统FAQ列表不依赖AI监控告警升级当AI服务错误率1%持续1分钟立即通知值班研发产品负责人这些方案不是应急预案而是PRD的组成部分。老板看到“政策时效性双签机制”就知道风控有抓手研发看到“CPU服务器预留”就知道不用临时加班扩容算法看到“每日bad case推送”就知道迭代有数据支撑。风险不是用来回避的是用结构化方案把它变成可控变量。4. 实操一份完整AI PRD的诞生过程从0到1手把手4.1 第一步用“三句话挑战法”校准需求本质很多AI需求一开始就是伪命题。我要求团队在写PRD前必须通过“三句话挑战”用一句大白话告诉老板这事能帮他省多少钱或赚多少钱例不是“做智能推荐”而是“把首页商品曝光点击率从3.2%提到4.1%预计月增GMV 180万元”用一句技术语言告诉研发这事需要调用几个接口、改几行代码、加什么监控例不是“提升推荐效果”而是“替换/recommend接口输入增加user_embedding向量输出增加score字段新增GPU节点监控GPU显存占用率”用一句评估语言告诉算法这事用什么数据、什么指标、多少天能验证是否成功例不是“模型更好”而是“用2024年1月用户行为日志训练AUC提升0.03A/B测试7天后看CTR变化”通不过任意一句需求就退回重想。我曾否掉一个“AI生成营销文案”的需求因为产品说“让文案更吸引人”——老板问“吸引人多少转化率提升”研发问“生成文案要对接哪个内容库”算法问“用什么指标评估‘吸引人’”。直到产品拿出历史数据同类活动文案点击率均值1.8%目标提升至2.5%评估用A/B测试点击率用户停留时长才允许进入PRD编写。这一步看似慢实则省去后期80%的返工。4.2 第二步搭建PRD骨架——六个必含章节与禁忌AI PRD不是传统文档的加长版它有独特骨架。我坚持六个核心章节缺一不可且每个章节都有明确禁忌▶ 第一章商业目标与成功定义严禁出现“提升体验”“增强粘性”等虚词必须包含量化目标如“将新用户7日留存率从28%提升至35%”、达成路径“通过个性化新手引导降低学习门槛”、验证方式“埋点统计新用户第7天DAU”、失败阈值“若30天内留存率32%启动预案”禁忌写“打造行业领先的产品”老板不知道领先在哪写“让用户爱上我们的产品”研发不知道怎么实现“爱上”。▶ 第二章用户旅程与AI触点地图严禁画泛泛的“用户旅程图”必须标注每个AI介入点的触发条件如“用户在注册页停留60秒且未点击下一步”、AI动作“弹出智能引导检测到您可能需要帮助点击获取3步注册教程”、退出机制“用户点击‘跳过’或关闭弹窗永久屏蔽该引导”禁忌只画“用户从A到B再到C”不标AI在哪介入、怎么介入、用户怎么拒绝。▶ 第三章需求卡片集严禁按功能模块归类所有需求必须是独立卡片如前所述按优先级排序每张卡含商业/工程/算法三栏禁忌写“智能客服模块”必须拆成“退货政策解答”“物流查询”“优惠券使用”等原子卡片。▶ 第四章AI服务契约严禁用自然语言描述接口必须用前述代码注释式格式定义输入/输出/SLA/降级策略禁忌写“提供图片识别能力”必须写清尺寸/格式/超时/错误码。▶ 第五章评估与验证协议严禁只写“上线后看效果”必须明确评估数据集来源与规模、核心指标及计算公式、基线模型与阈值、A/B测试分流比例与周期、报告出具方禁忌写“通过用户调研验证”必须写清调研样本量、问卷问题、统计方法。▶ 第六章风险对冲与演进路线严禁写“后续考虑”“未来扩展”必须写清当前版本的风险应对方案以及下一版本的明确交付物如“V2.0交付支持语音输入需新增ASR服务契约”禁忌写“未来支持多语言”必须写“V2.0交付支持英语/日语需采购XX语音API预算12万元”。这个骨架保证PRD从诞生起就具备可执行性。我曾用这套结构在一个医疗AI项目中让老板在评审会上当场签字——因为他看到第一章就清楚知道“上线后每月减少300小时医生文书工作折合人力成本12万元”看到第四章就确认“接口能扛住日活50万用户的并发”看到第五章就相信“7天A/B测试就能验证效果”。文档的价值就是把不确定性变成确定性。4.3 第三步PRD评审会实战技巧——让三方达成共识的“三把尺子”PRD写完只是开始评审会才是真正的战场。我主持过上百场评审总结出让老板、研发、AI工程师同时点头的“三把尺子”▶ 尺子一老板的“钱尺子”——只问三个问题“这事投多少钱什么时候能回本”要求PRD中成本明细ROI测算表“如果失败最大损失是什么谁来负责”要求PRD中风险对冲方案责任人“这事不做竞争对手做了我们会丢什么”要求PRD中竞品分析简表列明对手已上线功能及效果只要这三个问题在PRD里有明确答案老板基本会签字。他不需要懂技术只需要知道钱花得值、风险可控、不落后。▶ 尺子二研发的“代码尺子”——只认三样东西“接口文档在哪字段都定义好了吗”指向第四章AI服务契约“SLA达标需要多少服务器GPU型号和数量”要求PRD附基础设施需求表如“需2台A10 GPU服务器内存≥64GB”“失败时怎么降级前端怎么配合”指向第六章风险对冲中的工程方案研发不关心AI多酷只关心能不能写出稳定、可维护的代码。PRD里这些信息越全他们越愿意接。▶ 尺子三算法的“数据尺子”——只盯三个数据“训练数据在哪质量怎么样”要求PRD附数据来源说明样本示例如“2023年客服对话日志已脱敏含5000条标注数据”“评估指标怎么算基线是多少”指向第五章评估协议必须给出计算公式和基线数值“bad case怎么收集多久迭代一次”要求PRD写明bad case自动采集机制迭代周期如“每日凌晨自动抓取置信度0.7的Query算法团队T1分析”算法最怕闭门造车。PRD里把数据、指标、迭代机制写死他们才有信心承诺效果。评审会不是宣讲会是三方用这三把尺子共同丈量PRD的时刻。我习惯把PRD打印出来每章贴一张便利贴评审时直接翻到对应章节回答问题。当老板问“ROI怎么算”我就翻到第一章的ROI测算表当研发问“GPU要几台”我就翻到第四章的基础设施需求表。用文档本身说话比任何口头解释都管用。5. 常见问题与避坑指南那些血泪换来的实战经验5.1 问题一老板总说“再想想”其实是没看到确定性现象PRD写了20页老板还是犹豫不决反复说“这个方向不错但我们再评估评估”。根因PRD里缺乏老板决策所需的确定性锚点——他看不到钱、看不到风险、看不到竞品压力。解决方案在PRD开篇加一页决策速查表Decision Quick-Reference Sheet用三栏极简呈现决策维度当前状态风险控制竞品对标投入成本总预算85万元含GPU服务器32万人力53万首期只投入35万验证ROI后再追加A公司投入120万B公司投入60万回本周期预计6.2个月基于GMV提升测算若12个月未回本自动终止二期投入A公司宣称4.8个月B公司未公布最大风险模型效果不达预期概率30%已部署规则引擎兜底保障基础功能可用A公司上线首月故障率12%B公司5%这张表不是补充材料是PRD的第一页。老板扫一眼就能抓住核心不用在20页文档里找答案。我试过加了这张表后老板签字速度平均提升70%。记住老板不是不想签是不敢签——你得给他签的底气。5.2 问题二研发抱怨“需求天天变”其实是PRD没锁死边界现象开发到一半产品突然说“加个语音输入吧”研发崩溃“接口都写完了”根因PRD里没定义需求变更熔断机制导致边界模糊。解决方案在PRD末尾强制加入需求冻结协议Requirement Freeze Agreement【需求冻结条款】V1.0 PRD于2024-03-20正式冻结此后所有需求变更视为V2.0范畴冻结期内仅接受两类变更①阻塞性Bug修复如安全漏洞、核心功能不可用②法规强制要求如新出台的数据合规条例其他变更如新增功能、修改UI、调整指标必须提交《需求变更影响评估表》列明对工期、成本、测试范围的影响经产品、研发、算法三方签字确认重新签署PRD修订版这条款不是束缚而是保护。它让研发知道“我按这个干就不会被临时加活”让产品明白“加需求要付出代价”让老板清楚“变更意味着延期和超支”。我曾用这个条款把一个项目的需求变更次数从平均12次压到0次——因为所有人知道改一个字都要三方签字自然就慎重了。5.3 问题三算法说“效果达不到”其实是评估方式没对齐现象算法提交模型测试指标达标但上线后业务指标没提升互相指责。根因PRD里评估协议与业务目标脱节算法优化的指标不是业务关心的指标。解决方案在PRD中建立指标映射表Metric Mapping Table强制关联业务目标对应业务指标技术可测指标映射逻辑验证方式提升用户购买意愿商品详情页转化率CVR推荐列表CTR点击率CTR每提升1%CVR提升0.3%基于历史回归系数A/B测试同期对比CVR变化缩短客服响应时间平均首次响应时长API P95响应时长响应时长3秒时用户放弃率下降42%历史数据埋点监控响应时长与放弃率相关性这张表让算法知道“我优化CTR就是在帮业务提CVR”让老板知道“你们测CTR其实是在测我的GMV”让研发知道“我把P95压到3秒就能让老板满意”。指标不再割裂而是形成一条从技术动作到商业结果的完整证据链。我坚持所有AI项目PRD必须有此表否则不予评审。5.4 问题四PRD写得巨细无遗但没人看——因为没做“角色定制版”现象PRD文档厚重老板只看第一页研发只看接口章节算法只看评估章节其他人懒得翻。根因把一份文档当三份文档用没做信息分层。解决方案PRD交付时同步生成三份角色定制版Role-Tailored Versions老板速览版1页PDF只含商业目标、ROI测算、风险对冲、决策速查表研发执行版接口手册SLA表只含第四章AI服务契约、第六章工程风险方案、基础设施需求表算法实验版评估协议数据说明只含第五章评估协议、第三章需求卡片中的算法栏、数据来源说明这三份文档从同一份PRD源文件自动生成用Markdown模板脚本确保信息一致。老板开会前5分钟看速览版就能决策研发拿到执行版就能开工算法打开实验版就知道怎么训练。信息过载不是文档太厚而是没给对的人看对的内容。我团队现在PRD交付必附这三份定制版阅读率从32%提升到91%。5.5 问题五模板套用千篇一律失去AI项目的独特性现象下载网上PRD模板填空式写作结果老板觉得假大空研发觉得不落地。根因把AI PRD当成传统PRD的变体忽略了AI特有的不确定性、数据依赖、模型迭代三大特性。解决方案在模板中嵌入AI特性强化模块每个模块解决一个核心痛点不确定性缓冲模块在每张需求卡片中强制填写“最差情况应对”如“若模型准确率仅达85%低于目标94%则启用规则引擎人工审核双通道”数据主权模块在PRD开头声明“本项目数据所有权归属甲方模型训练数据需经甲方书面授权训练日志需留存6个月备查”模型迭代模块在第六章明确“V1.0上线后算法团队每月提交模型迭代报告包含bad case分析、指标变化、下月优化计划产品有权否决不符合业务目标的迭代”这些模块不是锦上添花是AI项目的生存必需。没有不确定性缓冲上线就可能崩盘没有数据主权声明法务会否决项目没有模型迭代机制AI就会变成一潭死水。我见过太多项目死在“以为AI模型一次训练就永远有效”的幻觉里——PRD必须把AI的“活”特性写进骨子里。6. 最后分享一个真实教训我们曾因漏掉一行字导致项目延期47天去年做一个银行智能风控项目PRD里写“支持实时交易风险识别”看起来很完整。评审时老板、研发、算法都签了字。上线前压力测试发现TPS每秒事务数卡在1200远低于银行要求的5000。研发排查一周发现瓶颈在模型推理——原来我们没在PRD里定义GPU显存占用上限。算法用的模型显存峰值达16GB而采购的A10服务器只有24GB显存跑两个实例就爆了。临时换卡采购周期30天。优化模型算法说至少2周。最后只能紧急扩容多花了87万元。这个教训刻在我脑子里AI PRD里硬件资源约束不是运维的事是产品的事。从此我在PRD第四章AI服务契约里强制增加一行【资源约束】GPU显存占用 ≤ 12GB单实例CPU内存占用 ≤ 8GB单实例磁盘IO吞吐 ≥ 200MB/s模型加载阶段并且要求算法在提交模型