AI 项目的变更为什么更狠
传统软件改需求,代价基本是线性的人力:改个字段,前后端各改一天。AI 项目的变更代价经常是阶跃式的。举三个真实感受过的例子。第一,指标口径变更:"回答正确"的定义从"事实正确"改成"事实正确且语气友好",之前按旧标准标注的训练数据和评测集全部作废,重新标注按一条几毛到几块钱算,几千条就是几万块和两三周周期。第二,场景扩展:原来只做售前咨询,现在要加售后,听起来是"多一个意图",实际售后场景的数据分布、风险等级、合规要求全不一样,约等于新开半个项目。第三,技术路线绑定:做到一半业务方说"能不能顺便支持语音输入",这牵扯的是另一条技术栈,不是加一个字段。
所以 AI 项目的变更管理,核心不是流程,是让提出变更的人理解"这个变更的真实价格"。
变更分级:能接的痛快接,不能接的摆价格
我把变更分三级。一级是低成本变更:提示词调整、知识库内容更新、前端交互改动,这类不动模型和数据,24 小时内响应,不用走任何流程,AI 项目要快就快在这些地方。二级是中成本变更:新增意图、调整拒识阈值、换评测指标,动评测集和部分数据,需要和算法一起估 1-2 天的影响分析,明确告诉业务方"代价是 X 天 + 延期 Y"。三级是高成本变更:换场景、换技术路线、推翻指标定义,这类变更等同于重新立项,必须回到阶段门重新评估可行性,不能塞进现有排期。
分级的价值在于:它不是挡变更的墙,是定价器。业务方看到"这个变更 = 三周延期 + 两万标注费",一半以上的变更会自己撤回——很多变更本来就是拍脑袋,一报价就冷静了。
控制源头:让变更发生在便宜的时候
最好的变更管理是让变更不发生,或者发生在 POC 阶段——那时候改任何东西都便宜。两个做法最有效。第一,验收标准前置并且签字画押:项目启动时把评测集样例、指标定义、通过线写成文档让业务方确认,最好附上 30-50 条"什么样的回答算对、什么样的算错"的示例,业务方对着具体 case 确认,比对着抽象指标点头靠谱得多。第二,POC 阶段故意"勾引"变更:demo 做得糙一点没关系,重点是让业务方早摸、早提意见。POC 阶段收到的每条变更都是赚到了,上线前一周收到的每条变更都是灾难。
流程要轻,评估要重
别给 AI 项目套传统的 CCB 变更委员会,一周开一次会审批,迭代节奏直接废掉。我的做法是:一级变更 PM 自己批,记进变更日志就行;二级变更拉算法负责人当场评估,当天给报价;三级变更升级到项目干系人,48 小时内给"接 / 不接 / 怎么接"的答复。但每一级,影响评估都要做足四件事:对数据的影响、对评测集的影响、对排期的影响、对上线风险的影响。评估重、决策快,这是 AI 项目变更管理的正确姿势——和传统项目正好反过来,传统项目常常流程很重、评估反而走过场。