根本差异:交付物从"功能"变成"能力"
传统软件项目,需求文档写完,交付物的样子就定了——做一个审批流,上线那天它一定长那样。AI 项目不一样,你交付的是一个概率性的能力:意图识别准确率 92%,意味着每 100 个用户里有 8 个注定得不到正确答案。这件事带来两个连锁反应。第一,验收标准本身就是项目的一部分,定不准验收标准,项目永远完不了。第二,上线不是终点,模型会退化、数据分布会漂移,运维期的效果监控和传统项目的"修 bug"完全是两种活。
所以 AI 项目经理的第一课是:别再问"什么时候做完",要问"什么时候能验证这件事做得成"。
用阶段门代替大里程碑
我自己的做法是把项目切成四段,每段设一个"过得了就继续、过不了就停"的门。第一段是问题验证,一到两周,确认这事值得用 AI 做——很多时候用规则或者现有 SaaS 就能解决,那就别立项。第二段是 POC,两到四周,用最快的方式验证技术可行性:拿个开源模型或者调 API,在小样本上跑,核心指标能不能摸到及格线。第三段是效果打磨,这是周期最长、最不可控的一段,迭代实验、扩数据、建评测集。第四段才是工程化上线,这一段反而最接近传统项目管理,可以排期、可以承诺。
每个阶段门都配套一个明确的"不通过怎么办"。POC 没过,项目体面地关掉,这不叫失败,叫花四周时间避免了六个月的浪费。我见过最惨的项目是跳过 POC 直接立项做半年,最后发现天花板就到 70% 准确率,业务要 95%,所有人下不来台。
把不确定性前置,用区间管理预期
AI 项目的不确定性大头在前面:数据有没有、够不够、标注质量行不行。所以排期的第一件事不是估开发时间,是盘数据。我一般会先回答三个问题:现有数据有多少、覆盖多少场景、标注一致性有多高(抽 200 条让两个人各标一遍,一致率低于 85% 就说明标注规范本身有问题)。这三个问题答完,项目的风险等级基本就出来了。
对老板和业务方的预期管理,我用区间承诺而不是日期承诺:"这个指标,四周后有七成把握到 85%,五成把握到 90%。"听着不爽快,但比拍一个日期然后延期强一百倍。很多 PM 不敢这么说,怕被觉得不专业;恰恰相反,能说出概率分布的 PM,在 AI 团队里才是稀缺品。
敏捷还灵,但要改一改
双周迭代照跑,但迭代目标从"交付功能点"改成"验证假设"。每个迭代的评审会,核心问题不是"做完了吗",而是"我们学到了什么、哪个假设被排除了"。看板上的卡片也分两类:确定性任务(搭评测集、做标注工具)按传统方式估点;探索性任务(实验某个方法)只框时间盒,不承诺产出。把时间盒和产出承诺分开,是 AI 项目里保住团队士气最关键的一招——工程师不会因为实验没出结果而显得"没干活"。