先承认:敏捷在 AI 项目里不能照搬
我的观点很明确:敏捷的骨架(短迭代、快反馈、拥抱变化)非常适合 AI 项目,但血肉必须换掉。传统 sprint 的承诺是「这两周交付这几个功能」,AI 项目里你承诺不了「这两周把意图识别准确率提 5 个点」——可能三天就调出来了,也可能试了一个月发现这条路走不通。硬套 Scrum 的结果是:算法同学天天被问「你的 story 怎么还没关」,最后要么瞎估点糊弄,要么不敢接探索性任务,团队士气崩盘。
工程任务和实验任务分开管
适配的关键一招是把 backlog 拆成两类任务。工程类任务——接口开发、评测平台搭建、数据管道——和传统软件没区别,正常走 sprint、正常估点、正常验收,这部分大约占一半工作量。实验类任务——调 prompt、换模型、试新的 RAG 策略——不估点,改用「时间盒 + 假设验证」的方式管:每个实验明确写下假设(「换用语义切分能把召回命中率从 75% 提到 80%」)、验证方法(跑哪个评测集)、时间上限(3 天),时间到了不管成败都要出结论。
实验的产出不是「做完/没做完」,而是「假设成立/被推翻/不确定」。一个实验被推翻也是有效产出,因为它排除了一个方向。我在团队里会明确讲:实验失败不背锅,但没有结论的实验才背锅——时间盒到了你得说清学到了什么、下一步往哪走。
迭代目标从「交付功能」改成「交付认知和指标」
sprint 目标也要改写。传统目标是「上线 XX 功能」,AI 项目的 sprint 目标应该是两层:一层是确定的工程交付(上线 bad case 标注工具),一层是指标假设(这轮迭代结束时,客服场景的解决率达到 55% 以上)。指标没达成不算 sprint 失败,但必须能回答「为什么没达成、是方向问题还是执行问题」。
站会的内容也要跟着变。除了常规进度,加两个固定环节:昨天的实验结果是什么(哪怕一句话「试了 CoT prompt,bad case 降了 8%」)、今天需要谁配合什么数据。AI 项目里最大的协作损耗是算法等数据、工程等接口、标注等标准,站会的价值就是每天把这些等待暴露出来。
验收标准换成评测集说话
传统功能验收靠 QA 点一遍用例,AI 功能验收必须靠评测集。我的做法是每个迭代维护一个不断膨胀的评测集:从几十条种子 case 开始,每周把线上暴露的 bad case 补进去,三个月后就有几百上千条。验收就一句话:新版本在评测集上的得分不低于某个阈值,且关键 bad case 全部修复。这样「效果有没有变好」从吵架问题变成了数字问题。
发布节奏建议双轨:工程功能可以两周一发,模型效果改动走灰度——先 5% 流量跑一周,指标不掉再全量。ChatGPT、Cursor 这些产品迭代那么快,背后都是这套评测加灰度的机制在兜着,不是靠人肉测出来的。
角色上,产品经理要多干一件事
AI 项目里产品经理比普通项目累,因为你要补一个传统项目里没有的角色:效果定义者。什么叫「答对了」、什么叫「可用」、bad case 怎么分级——这些定义算法和工程都定不了,得你带着业务方一条条过案例定下来。这件事不干,团队会在「模型到底行不行」上空转无数轮。所以 AI 产品经理的迭代计划里,要给自己留出至少三分之一的时间做评测和 bad case 分析,这不是兼职,是本职。
还有一点容易被忽略:团队里算法、工程、标注的迭代节奏天然不同,标注以天为单位,工程以周为单位,算法实验以小时为单位。PM 要像对表一样把三方节奏对齐——比如每周三固定发一版标注数据、每周五算法出一版实验结论,让互相等待变成可预期的节拍,而不是随机的阻塞。