先分清楚失败类型,再谈复盘
AI 项目复盘的第一步不是拉会,是给结果定性。我的经验是失败分三类,复盘方式完全不同。第一类是需求错误:根本不该做,或者不该用 AI 做——比如花了三个月做一个 AI 生成周报的功能,上线后发现用户一周就点开两次。这类要复盘的是立项判断:当初的需求验证为什么没拦住?
第二类是路径错误:需求是真的,但技术路线选错了——比如死磕 fine-tuning 半年,后来发现 RAG 加 prompt 两周就能达到同样效果。这类要复盘的是技术选型时的信息够不够、有没有做小成本验证再重投入。
第三类是执行错误:方向和路径都对,但评测集没建好、数据质量差、迭代节奏乱,导致效果爬得太慢。这类才轮到复盘执行细节。很多团队复盘会的毛病是不分类,混在一起开成批斗会,最后结论是「下次加油」,什么都没留下。
复盘用数据说话,但别迷信数据
AI 项目复盘有个独特的优势:数据多。评测集得分曲线、线上 bad case 记录、每周的实验结论,这些都是复盘素材。复盘会之前,我会让团队先把三条曲线画出来:指标爬坡曲线(和当初承诺的爬坡计划对比)、成本曲线、迭代节奏曲线(每周实验数、工程交付数)。图一贴出来,很多争论自动消失——是爬坡太慢还是中间掉过坑,一目了然。
但也要警惕数据的另一面:指标达标的项目未必成功。我做过一个项目,解决率从 40% 提到 85%,数据漂亮,但复盘时发现用户满意度几乎没涨——因为答对的 85% 里有一大半是用户本来就能自己搜到的简单问题,真正难的 15% 还是全错。所以复盘一定要配用户侧的定性材料:访谈、投诉原文、流失用户的原因。数字回答「发生了什么」,案例回答「为什么」。
复盘的产出物:决策原则,不是检讨清单
普通复盘会的产出是「三条不足、两条改进」,写完就没人看了。有价值的复盘产出应该是一组「下次遇到同类情况怎么做」的决策原则。举个例子,我们有一次复盘后沉淀了这么几条:「涉及专业术语的场景,先用 50 条真实 query 测一遍通用模型的裸效果,低于 60% 直接上 RAG,不要先调 prompt」「给老板报效果预期时,在实测值上打八折」「标注外包前,先自己标 100 条摸清分歧点,不然标注规范写不出来」。这些原则进团队 wiki,下次立项时过一遍,这才是复盘的复利。
还有一类容易被忽略的产出:可复用的资产。这个项目建的评测集、标注规范、prompt 模板、灰度发布配置,整理出来,下一个 AI 项目直接复用,起步快一倍。复盘会留半小时专门盘资产,比留半小时表决心有用得多。
怎么开复盘会才不会开成甩锅会
两个硬规则。第一,对事不对人,而且产品经理先自我批评——复盘的氛围是主持人定调的,PM 上来先讲自己判断错了什么,其他人才敢说真话。如果 PM 带着「找出谁的责任」的目的开会,所有人都会进入防御姿态,复盘当场报废。
第二,区分「当时该知道」和「事后才知道」。评估一个决策,要用决策时刻可得的信息来判断,不能用结果倒推。比如三个月前选了某个模型,现在它降价被证明选错了——只要当时的对比测试做得充分,这就是合理的决策,不复盘成「失误」。这条规则不立住,团队以后没人敢拍板,全都等老板指示,组织的决策能力就废了。
时间点:别等项目死了才复盘
AI 项目节奏快,只做一个收尾复盘不够。我的实践是三层:每迭代结束有小复盘(15 分钟,只讲一个实验结论),每月有阶段性复盘(对爬坡计划,调预期),项目里程碑或终止时有大复盘。小复盘保证经验不过夜,大复盘保证经验能沉淀。等项目失败半年后再复盘,细节全忘了,只剩下互相防御的记忆。