ARTICLE · 1270846
AI 项目的 MVP,要验证四层
AI 项目的 MVP,要验证四层这篇接的是《编程变容易了，MVP 反而更难做》。那篇讲的是为什么难：AI 把写代码变便宜了，但验证的成本没降，团队的行为还容易走歪，而项目经理明知有问题也得往前推——因为验证这件事在他的考核表上没有位置。 那篇的结尾留了一个问题：在一个奖励"做出来"、不奖励"想清楚"的环境里，怎么让验证这件事有位置。 这篇只回答这一个问题。不讲道理，只讲动作。 传统软件 MVP 主要验证"用户要不要这个功能"，AI 项目只验这一层，一定会在规模化时爆掉。下面这四层是我自己归纳的，不是现成的行业框架，但它是我这些年看项目时用得最顺的一把尺子。
第一层的经典死法，一位技术博主写过他亲眼见过的例子：某零售集团上需求预测 AI，算法团队花三个月把离线评测准确率做到 95% 以上，全渠道推广，上线一个月业务部门反馈"这玩意还没老统计好用"——预测偏高的 SKU 积压库存，偏低的断货，两头都在骂。模型指标和业务价值之间，隔着一道没人验证过的鸿沟。 第二层的坑更隐蔽，因为它通常在离线阶段看不出来。算法团队拿历史数据切训练集和验证集，指标很漂亮，一上现场就崩，原因往往就三样：样本不代表现场，标签本身有噪声，分布还在动。 训练数据多来自过去跑得最顺的那批业务，也就是最好采、最干净的部分。现场的真实分布里，偏门的、异常的、脏的那部分，恰恰是被历史过滤掉的。标签也是一样——如果标签是人工事后补的，人工补的时候带了多少主观判断，"标准答案"里就有多少误差。至于分布，采购价在变、渠道在变、设备在老化，模型训练时的世界和上线后的世界不是同一个。 所以数据层要验的不是"准确率多少"，是**"这个准确率是在什么样的数据上、用什么标准算出来的，那批数据跟现场差多远"**。我自己的做法很土：不问指标，问三句话——这批训练数据是怎么采的、标签是谁标的、最近一次重训是什么时候。三个问题里有两个答不上来，这个验证就不能算过。 第四层最容易被当成技术问题，其实是个责任问题。闭环要回答的不是"系统能不能回滚"，是"出错之后谁接得住"。判断结果发出去，一线照着做了，后来发现是错的——这时候谁最先知道？谁有权叫停？停下来的损失算谁的？这些问题在立项书上通常是空白，等到真出事，才发现没有人被授权按下那个按钮。 闭环验证其实不费什么成本，问清楚三件事就行：出错的结果会流到谁手上、他有没有办法识别出来、识别之后能不能在两小时内退回人工流程。第三件事尤其要问，因为很多系统技术上"可以回滚"，但流程上没有人为回滚负责，结果就是一次误判之后，一线干脆不用了——这比系统坏掉更难救。 第三层最容易被漏掉，也最致命。采纳这件事需要的不是 GPU 算力，而是对晨会节奏的尊重、对报销单格式的妥协、对"这个按钮放左边还是右边"连续三轮跨部门对齐的耐心。 这句话把 MVP 从技术问题说成了组织问题。而组织问题，恰恰是项目经理最熟的那部分战场——这也是他能真正使上劲的地方。 看清了四层验证，接下来的问题是：这些验证动作具体长什么样？ 不是把正式产品砍一半，而是换一种形态。智能化项目的 MVP 有三种更适合的做法。 形态一：影子模式。系统在后台跑，不接管业务，只把判断结果和人工结果并排比对。这个做法在智能驾驶领域已经相当成熟——AI 在量产车上静默运行，跟人类驾驶员"同台竞技"，却不干预物理世界，用来验证模型的鲁棒性；近两年企业级 AI 上线也在用同一套思路，先影子运行、再灰度放量。这几乎是 AI 项目最划算的 MVP：零风险拿到真实数据下的效果评估，一线也感受不到被打扰。 形态二：人机混合的最小闭环。不追求自动化，先做"AI 出初稿、人做终审"。验证的是这条链路能不能跑通、人愿不愿意用，而不是模型有多强。 这个形态最怕做成一锅粥：AI 出完初稿，谁都能改，改完没人签字，最后出了问题查不到是哪一环节错的。所以它得定死三件事——初稿交给谁审、审几轮、什么情况下退回重做。我的经验是审的人不能超过两个，一个管业务对不对，一个管风险能不能兜；轮次定两轮，两轮还改不明白，说明这件事本身没想清楚，不该继续往下做。 形态三：单点场景的最小闭环。判断一个场景适不适合先做，我常用一个很朴素的三条标准：边界清晰、结果可验证、失败代价可控。这三条不是行业通用框架，是我从踩过的项目里攒出来的，但它解释了一件事：为什么"给全公司做一个智能助手"这种项目几乎必败——三条一条都不满足。 三种形态的共同点，都是把成本压在验证上，而不是压在开发上。 正因为难在这三件事上——验证成本没降、行为容易走歪、组织压力真实存在——所以清单不能只是流程，得能对付它们。下面七条，按这三件事分别对应。 对付验证成本： 1. 立项时先写一句：这个版本要验证的唯一假设是什么？ 2. 再写一句：验证通过的标准是什么？（必须是行为或付费，不能是"用户反馈不错"） 3. 列出为验证这个假设必须有的功能，其余全部移出本版本 对付行为走歪： 4. 明确这次验证的成本上限（时间、人力、钱），并且只花这个数 5. 指定谁去亲自使用并做访谈——见过太多项目，老板不亲自用，最后每组数据都特别好看 对付组织压力： 6. 提前写好：如果验证失败，我们下一步做什么——这一条是给上级看的，它把"失败"从事故变成计划的一部分 7. 在汇报里给"验证结论"留一个固定位置，跟进度并列 还有一个更底层的视角，它不算论证，算参照。 万维钢讲盖尔定律时提到 MVP：如果你有个很新的产品或服务，先别追求功能全面，先弄个有最重要功能的版本开卖，看市场反应；如果用户买账，就继续投入。盖尔定律说，一个能运转的复杂系统，总是从一个能运转的简单系统演化来的；从零开始设计的复杂系统从来不能运转。 这条规律管的不只是 MVP，它管的是所有复杂系统怎么长出来。放在这里是想说明一件事：AI 让造东西变便宜，改不了系统演化的规律，只会让违反它的代价更隐蔽——因为你能更快地造出一个跑不起来的复杂系统。 七条清单抄进立项书，只花十分钟。难的是抄完之后，下次会上有人问"这个方向到底成不成"的时候，你敢不敢把验证结论放上去。 过去做错一件事很贵，贵到团队会本能地谨慎；现在做错一件事很便宜，便宜到没人拦你。 MVP 的价值从来不是帮你省钱，是帮你在还没花掉不可逆的代价之前，拿到一个能推翻自己的证据。而这句话，在写代码变得这么便宜的今天，比过去任何时候都更需要有人站出来说。
先说清楚这篇从哪儿接
智能化项目里，MVP 要验证的不是一层，是四层
所以形态要变：三种更轻的验证
给项目经理的落地清单
另一层参照
结尾
参考资料说明
概念源流：盖尔定律出自约翰·盖尔《通用系统学》，本文经万维钢讲解转引；MVP 定义参见埃里克·莱斯《精益创业》。 经验性材料：零售需求预测案例、影子模式在智能驾驶与企业级 AI 中的用法，来自技术社区与从业者的公开文章，属个人实测或经验观察。 本文自有：四层验证表、三条场景标准、七条落地清单，均为作者个人归纳。
