假如你想开一家餐厅，你会怎么做？正常人不会一上来就租黄金地段、请五位大厨、印五十道菜的菜单。稳妥的做法是：先推一辆小餐车，在写字楼楼下卖最拿手的一道菜。看看有没有人买、口味合不合适、成本赚不赚得回来。餐车验证通过了，再开店；开店验证通过了，再扩张。 AI 项目也是同样的道理。很多团队一上来就想打造“全网最聪明的模型”，结果预算烧完了、业务方失望了、项目搁浅了。MVP（最小可行产品）交付正是那辆小餐车：先圈定最痛的一个场景，用最简单的方案跑通闭环，在真实反馈中快速调整，再逐步加菜。它不追求一步到位，只追求每一步都走稳、走快、走得有依据。 本文会用“开餐车”的视角，带你走一遍 AI 项目 MVP 的完整旅程：怎么定范围、怎么控节奏、怎么过冷启动、怎么对齐预期、怎么验收、怎么兜底。

岗位关联

对 AI 从业者而言，MVP 交付能力是项目从实验室走向生产环境的桥梁。学会小步快跑，你能在资源有限时赢得业务方信任，让 AI 项目真正落地创造价值。

目录
  1. 可视化演示
  2. 范围定义：只卖招牌菜
  3. 迭代节奏：小步快跑的两周循环
  4. 数据冷启动：先家常菜谱，再专业大厨
  5. 预期对齐：后厨与客人的共识
  6. 交付清单：出摊前的检查表
  7. 风险预案：有备无患
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示AI项目的MVP交付的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI项目的MVP交付：AI项目 AI项目MVP范围定义 交付节奏与迭代控制 核心机制可视化 AI项目的MVP交付整体架构与关键组件

范围定义：只卖招牌菜

阿珍想开一家餐厅。她没有急着去租铺面、搞装修、印菜单，而是先推了辆小餐车，在写字楼楼下卖自己最拿手的红烧牛腩饭。她想得很清楚：我的招牌菜是什么？谁会来买？十块钱一份能不能赚钱？这三个问题，比任何装修都重要。AI 项目的 MVP，开张前同样先回答三个问题：为谁、解决什么问题、哪些功能绝对不能少。

很多 AI 团队一启动就忙着搭模型、调参数，忽略了对范围的约束。结果做出来的东西像一本什么菜都印上去的菜单——看着丰富，却没有一道菜经得起推敲。范围定义（Scope）就是 MVP 的第一道工序：从用户旅程里圈出最高频、最痛的那一个场景，然后只保留支撑闭环的最小功能集。

把范围写成一个集合表达式：MVP 的边界 = 核心场景集合 ∩ 最小功能集合。核心场景来自访谈、日志分析或业务方痛点清单，通常只取 1-2 个；最小功能集来自流程梳理，指“缺了它闭环就断”的环节。两者取交集，交集之外的需求全部排进 backlog 等待迭代。

小餐车的菜单上永远只有两三道菜，阿珍很清楚：菜越多，备料越乱，出餐越慢。先把红烧牛腩饭做成街坊口中的“必点”，再考虑加一道例汤。范围定义的成果不是一张密密麻麻的需求表，而是一张写着“这版只做这些”的瘦菜单——它决定了你的餐车能不能在第一天就做出让客人愿意再来的味道。

SMVP=Score∩Fmin⁡\displaystyle S_{\text{MVP}} = S_{\text{core}} \cap F_{\min}
说白了：MVP 不是“什么都做一点”的缩水版，而是“只做一件事但做完整”的聚焦版。交集之外的东西，一律不做。
  1. S_core（核心场景集合）从用户旅程中挑出高频、强痛点的一两个场景，比如“余额查询”和“挂失”，这是你的招牌菜。
    Score={s1,s2}\displaystyle S_{\text{core}} = \{s_1, s_2\}
  2. F_min（最小功能集合）支撑场景走通闭环必不可少的环节，如输入、识别、反馈。
    Fmin⁡={f1,f2,f3}\displaystyle F_{\min} = \{f_1, f_2, f_3\}
  3. ∩（交集）只保留场景需要且功能支持的交叉部分，其余砍掉不做。
    SMVP={si∩fj∣si∈Score, fj∈Fmin⁡}\displaystyle S_{\text{MVP}} = \{s_i \cap f_j \mid s_i \in S_{\text{core}},\ f_j \in F_{\min}\}

迭代节奏：小步快跑的两周循环

阿珍的餐车每天收摊后都会做一件事：数一数哪道菜卖完了，哪道菜被剩下了，客人对咸淡有什么抱怨。第二天一早调整菜单和做法。她不去想“三个月后卖什么”，只想“明天怎么比今天好一点”。

AI 项目的迭代节奏也要这样。MVP 上线后不是终点，而是验证的起点。行业公认的节奏是“两周一个迭代”：第一周围绕一个核心假设开发，第二周上线并收集真实反馈，周末复盘决定下一步。两周不长不短——太短做不出像样的改动，太长又等不到反馈。

迭代的价值密度可以用一个分数衡量：交付给用户的可感知价值 ÷ 周期时间。分子是“这个功能有多少人用、解决了多大问题”，分母是“从想法到上线用了多久”。把分母压到两周，倒逼团队砍掉不必要的工作，专注在最小改动上验证最大假设。

阿珍不会一次研发十道菜，她每天只改进一道。两周一轮的节奏就像“天天收摊复盘”，让团队始终盯住最有价值的一步，而不是被漫无边际的需求带偏。小步快跑不是跑得快，而是“每步都踩实”。

Viter=UdeliveredTcycle\displaystyle V_{\text{iter}} = \frac{U_{\text{delivered}}}{T_{\text{cycle}}}
价值密度：每花一天能产生的用户价值。分母越小跑得越快，分子越实越接近真相。
  1. U_delivered（交付价值）本迭代新功能带来的可感知收益，可用使用量、转化率等衡量。
    Udelivered=功能使用量×单次价值\displaystyle U_{\text{delivered}} = \text{功能使用量} \times \text{单次价值}
  2. T_cycle（周期时间）从需求冻结到上线的天数，MVP 阶段建议 14 天。
    Tcycle=14 天\displaystyle T_{\text{cycle}} = 14\ \text{天}
  3. V_iter（价值密度）单位时间产出的价值，是衡量迭代效率的仪表盘。
    Viter=UdeliveredTcycle\displaystyle V_{\text{iter}} = \frac{U_{\text{delivered}}}{T_{\text{cycle}}}

数据冷启动：先家常菜谱，再专业大厨

新餐车开张第一天，阿珍没有客人的口味数据。她不敢乱创新，老老实实按妈妈传下来的家常菜谱做——咸淡适中、配料固定、出品稳定。这套“规则”虽然不惊艳，但保证客人不会踩雷。

AI 项目的数据冷启动也是同一个道理。新项目往往没有足够的标注数据来训练模型。聪明的做法是先上规则引擎：关键词匹配、决策树、专家经验表。规则引擎不需要训练数据，几周就能上线，先把业务跑起来。

规则引擎上线后要做的唯一一件事是积累数据：每一条真实请求、每一次用户反馈，都在为将来的模型备料。当满足两个条件时切换：样本量超过训练阈值，且规则的覆盖率已不够支撑业务目标。这就像阿珍的笔记本上记录了一百位客人的口味偏好后，才开始调整配方。

规则不是被丢弃的旧菜单，而是保留下来作为兜底。就像阿珍即使请了专业大厨，逢年过节还是会亲手做一道家常菜，因为客人吃的是信任。冷启动的成功标志不是“换成了模型”，而是“无论规则还是模型，客人那道菜永远上得稳”。

Switch=(Nsamples>Nthr)∧(Rcov<Rtarget)\displaystyle \text{Switch} = \left(N_{\text{samples}} > N_{\text{thr}}\right) \land \left(R_{\text{cov}} < R_{\text{target}}\right)
切换时机不是拍脑袋决定的，而是数据量和规则覆盖率同时给出信号：数据够了，规则不够了，模型该上场了。
  1. N_samples（已积累样本量）线上真实业务数据的总条数，是模型训练的“食材储备”。
    Nsamples=n1+n2+⋯+nk\displaystyle N_{\text{samples}} = n_1 + n_2 + \cdots + n_k
  2. N_thr（样本训练阈值）模型训练所需的最小数据量，通常数千至上万条。
    Nthr=2000∼10000\displaystyle N_{\text{thr}} = 2000 \sim 10000
  3. R_cov（规则覆盖率）规则引擎能正确处理请求的占比，低于目标说明规则开始吃力。
    Rcov=规则命中数总请求数\displaystyle R_{\text{cov}} = \frac{\text{规则命中数}}{\text{总请求数}}
  4. R_target（业务目标覆盖率）业务方期望的覆盖底线，通常要求 85% 以上。
    Rtarget=0.85∼0.95\displaystyle R_{\text{target}} = 0.85 \sim 0.95

预期对齐：后厨与客人的共识

阿珍在餐车开张前，跟常来买饭的几位上班族打招呼：“我们这餐车刚起步，目前只做红烧牛腩饭，味道可能不如大饭店稳定，但有啥意见您尽管提。”客人有了心理预期，哪怕今天的饭稍微咸了一点，也不会大发雷霆，反而会认真给建议。

AI 项目最怕的是业务方抱着“AI 应该无所不能”的期待上线。上线第一天发现只能回答三种问题，立刻觉得项目失败了。预期对齐就是在项目启动之初，用业务方听得懂的语言说清楚三件事：第一版能做什么、不能做什么、评价标准是什么。

预期偏差可以量化：业务方预期指标和实际指标之差占预期值的比例。偏差越小，双方信任越深。经验上，偏差控制在 15% 以内是“可接受节奏”，超过这个数字就要第一时间同步，而不是等到上线才揭晓。

透明是最好的调味料。阿珍把“目前只卖三种菜”的牌子挂在餐车上，客人不会因为选择少而失望，反而会因为“说到做到”而信任。预期对齐不是低三下四地降低标准，而是把真实的进度和质量，变成双方共同经营的一段关系。

Dexpect=∣Emetric−Mmetric∣Emetric\displaystyle D_{\text{expect}} = \frac{\left| E_{\text{metric}} - M_{\text{metric}} \right|}{E_{\text{metric}}}
如果业务方预期准确率 90%，模型实际 82%，偏差约 8.9%。这个数最好在第一个迭代就摆到桌面上，而不是等三个月后揭晓。
  1. E_metric（业务方预期值）业务方对核心指标的心理目标，比如“准确率至少 90%”。
    Emetric=0.90\displaystyle E_{\text{metric}} = 0.90
  2. M_metric（模型实际值）当前版本在验证集上的真实效果，是诚实的“试吃结果”。
    Mmetric=0.82\displaystyle M_{\text{metric}} = 0.82
  3. D_expect（预期偏差）偏差越小沟通越顺，偏差过大就要启动预期管理，调整承诺或提升效果。
    Dexpect=∣0.90−0.82∣0.90≈0.089\displaystyle D_{\text{expect}} = \frac{|0.90 - 0.82|}{0.90} \approx 0.089

交付清单：出摊前的检查表

阿珍每天出摊前都会默念一遍检查清单：牛肉新不新鲜？煤气够不够？零钱备了吗？餐巾纸带了吗？这些事没有一件是“大事”，但任何一件掉链子，都会让排队的客人转身离开。

AI 项目的上线同样需要一张交付检查清单。它不是走形式，而是把“模型不错”翻译成“可以交给业务方”的最后一公里。清单通常分三类：功能验收（每个场景是否达到预期效果）、性能基线（响应时间、并发量是否达标）、文档归档（接口说明、部署手册、回滚指南是否齐全）。

用验收通过率来量化：通过的检查项除以总检查项。团队约定通过率 ≥ 90% 才允许上线，剩下 10% 的不通过项必须给明确的整改人和完成日期。这样一次验收会议就能结束“再测测看”的泥潭。

这张清单就像餐车抽屉里的零钱盒，平时不显眼，关键时刻谁也离不开它。有了它，阿珍每天出摊都能气定神闲；有了它，AI 项目的上线再也不会靠“感觉差不多了”来拍板。

Ppass=NpassNtotal\displaystyle P_{\text{pass}} = \frac{N_{\text{pass}}}{N_{\text{total}}}
交付清单的意义不是增加流程负担，而是让“能不能上线”从主观判断变成客观打分。
  1. N_pass（通过项数）检查项被验证满足要求后记 1 分，是硬指标。
    Npass=∑i=1Ntotal1(ci=1)\displaystyle N_{\text{pass}} = \sum_{i=1}^{N_{\text{total}}} \mathbf{1}(c_i = 1)
  2. N_total（检查项总数）清单上的全部项目数量，覆盖功能、性能与文档。
    Ntotal=功能验收项+性能项+文档项\displaystyle N_{\text{total}} = \text{功能验收项} + \text{性能项} + \text{文档项}
  3. P_pass（验收通过率）通过率越高，上线风险越低，90% 是常见的安全门槛。
    Ppass≥0.90\displaystyle P_{\text{pass}} \ge 0.90

风险预案：有备无患

再熟练的摊主也会遇到意外：突然下暴雨、牛肉供应商断货、燃气灶中途熄火。阿珍的餐车里永远藏着一把备用伞、一份附近肉铺的电话、一罐备用气罐。她不会因为意外而停业，因为预案早在开张前就想好了。

AI 项目的风险预案要覆盖三类高发风险：数据风险（标注断供、线上分布漂移）、模型风险（效果不达标、产生错误输出）、系统风险（接口故障、并发超限）。每种风险都要有一句话预案：“如果 X 发生，我们就做 Y”。

风险优先级用影响度与发生概率的乘积排序。影响度打 1-10 分，概率取 0-1。得分最高的风险先准备预案，而且预案必须演练过，不能只写在文档里。就像阿珍的备用气罐，不到关键时刻绝不拿出来，但拿出来就得能用。

预案改变的是心态：阿珍知道即使下雨，她还有备用伞和避雨棚，所以开张时格外从容。AI 项目也一样，把最坏的情况提前想好，团队在关键时候就不会手忙脚乱。风险预案不是悲观，而是让“小步快跑”跑得更踏实的保险带。

Rpriority=Iimpact×Pprob\displaystyle R_{\text{priority}} = I_{\text{impact}} \times P_{\text{prob}}
一个影响度 8 分、概率 0.6 的风险，优先级 4.8，需要提前准备；一个影响度 2 分、概率 0.1 的风险，优先级 0.2，先记在案即可。
  1. I_impact（影响度）风险发生后的业务损失程度，1-10 分。
    Iimpact∈{1,2,…,10}\displaystyle I_{\text{impact}} \in \{1, 2, \dots, 10\}
  2. P_prob（发生概率）风险出现的可能性，0 到 1 之间。
    Pprob∈[0,1]\displaystyle P_{\text{prob}} \in [0, 1]
  3. R_priority（风险优先级）得分越高，预案越要充分，投入产出越划算。
    Rpriority=Iimpact×Pprob\displaystyle R_{\text{priority}} = I_{\text{impact}} \times P_{\text{prob}}

AI 应用场景

智能客服意图识别冷启动

阶段：数据准备与模型选择（冷启动）

解决的问题：银行客服部想上线意图识别，但历史对话记录大多未标注，模型无法直接训练。传统方式是把工单外包标注，等 3 个月数据达标才动工，业务方根本等不起。

具体案例：某银行先用 200 条常见问题做成关键词规则引擎，当天就能回答“余额查询”“挂失”等高频问题。线上运行两个月积累 5000 条真实对话，人工清洗后微调一个意图分类模型，准确率从规则期的 78% 提升到 91%，同时保留规则作为兜底。

智能推荐系统的冷启动上线

阶段：模型迭代与效果评估

解决的问题：新品上线没有用户行为数据，协同过滤算法完全失效。传统做法是等一周攒数据，用户早就流失了。

具体案例：电商平台先按品类热度做规则推荐（“大家都在看”），同时给新品打标。一周后积累行为数据，切换到向量召回模型，新客点击率提升 23%。规则推荐长期保留为离线兜底方案。

工厂质检 AI 的分批落地

阶段：交付与持续优化

解决的问题：视觉质检模型在真实产线上误检率偏高，生产方迟迟不敢切换。传统方式是无限期延长测试，项目陷入停滞。

具体案例：项目组先圈定一条产线、一类瑕疵（划痕）上线 MVP，把“检出 + 人工复核”作为闭环流程。两周迭代一次，每次增加 3-5 类瑕疵的样本，同步优化模型阈值。4 个迭代后误检率下降 60%，才逐步推广到全部产线。

Python 演示

python34 行
"""模拟 AI 项目 MVP 交付：先规则后模型 + 两周迭代追踪""" class MVPProject:    def __init__(self, name):        self.name = name        self.iteration = 0        self.data_count = 0        self.rule_accuracy = 0.78          # 规则引擎基线准确率        self.model_accuracy = 0.62         # 模型冷启动初始准确率        self.switch_threshold = 2000       # 数据切换阈值        self.total_samples = 8000          # 预期积累总量     def run_iteration(self, new_samples):        self.iteration += 1        self.data_count += new_samples        if self.data_count < self.switch_threshold:            mode = "规则引擎"            acc = self.rule_accuracy        else:            ratio = min((self.data_count - self.switch_threshold) / self.total_samples, 1.0)            acc = min(self.model_accuracy + ratio * 0.25, 0.92)            mode = "机器学习模型"        return mode, acc if __name__ == "__main__":    project = MVPProject("智能客服意图识别")    print("项目启动：智能客服意图识别（MVP）")    print("初始策略：数据不足 2000 条，先用规则引擎兜底")    print("=" * 40)    for week in range(1, 7):        mode, acc = project.run_iteration(400)        print(f"第 {week:2d} 轮迭代（第{week * 2:2d}周）| 累计样本 {project.data_count:4d} | {mode} | 准确率 {acc:.2f}")    print("=" * 40)    print("结论：样本越滚越多，模型逐步接管，规则保留兜底。")
目的：模拟一个 AI 客服项目从规则引擎冷启动到模型接管的两周迭代过程。
  1. self.switch_threshold = 2000设定冷启动切换门槛：样本量不足之前不硬上模型，就像餐车没记满客人口味前不换配方。
  2. if self.data_count < self.switch_threshold:当前阶段判断：低于门槛走规则，高于门槛走模型，这是“先规则后模型”的核心开关。
  3. ratio = min(...)超过门槛后，数据越接近目标，模型发挥越稳定，用比例控制爬升速度。
  4. acc = min(self.model_accuracy + ratio * 0.25, 0.92)模型准确率随数据量爬升，但设了 0.92 的天花板，防止自嗨式预估。
  5. project.run_iteration(400)每轮迭代新增 400 条标注样本，模拟“两周一个迭代”的积累节奏。

常见误区

误区我理解的 MVP 就是把完整产品砍到只剩一个壳子，用户根本不想用，开发也觉得没面子。

正解MVP 不是功能残缺的壳子，而是精心设计的最小人体验证闭环。就像小餐车虽然只卖一碗面，但这碗面必须好吃、出餐快、价格公道——核心体验完整，外围体验从简。MVP 的“最小”指的是范围最小，不是质量最差。

为何常见：很多人把“最小”理解成“最烂”，以为只要功能少就是 MVP，忽略了“可用的闭环”才是关键。

误区业务方说“你们连训练数据都没有，怎么做 AI？”我听完觉得项目要完蛋了。

正解数据冷启动阶段完全可以先用规则引擎顶上，像小餐馆先用家常菜谱做菜，同时通过线上使用积累数据。当数据量超过阈值再切换到模型。关键不是“有没有数据”，而是“有没有清晰的切换路线图”。

为何常见：媒体报道里 AI 都是大模型加海量数据，让人误以为数据是前提条件，其实工程上冷启动有一整套成熟打法。

误区既然要小步快跑，那业务方每周提新需求我们都接，迭代不就越来越值钱吗？

正解迭代有边界，每个迭代都要有明确目标和验收标准。无节制加需求叫“镀金”，会让 MVP 永远无法收尾。小步快跑的精髓是“每步都有交付”，不是“每步都在变卦”。

为何常见：把迭代误当成需求收集箱，混淆了“验证假设”与“堆功能”这两件完全不同的事。

误区模型准确率到了 95%，我觉得项目成功了，上线后可以不用再管了。

正解准确率是离线指标，上线后还有延迟、覆盖面、用户真实反馈、badcase 等一堆问题。就像菜再好吃，出餐慢、份量少、服务差，客人照样不回头。MVP 的验收清单里，可用性、延迟、覆盖率与离线指标同样关键。

为何常见：算法同学天然关注离线指标，容易忽视系统层面的“最后一公里”。

误区MVP 上线后用户量很少，大家觉得这个项目彻底失败了，团队士气很低落。

正解MVP 的核心目的就是验证假设，验证结果是“此路不通”同样是有效产出。它帮你避免了更大的失败。小餐车卖不动，要判断是“这个地段不适合”还是“这个菜不对味”——这本身就是下一步决策的依据。

为何常见：组织文化不允许失败，导致团队用假指标掩盖真实情况，反而错过了及早止损的最佳时机。

面试题

Q1. MVP 最核心的目标是什么？

单选题 · easy

  • A.以最小成本验证核心价值← 正确答案
  • B.一次性做齐所有业务功能
  • C.追求模型效果极致天花板
  • D.尽快部署上线抢占市场份额

答案：A。MVP 的目标是以最小成本验证核心价值，就像小餐车先验证招牌菜有没有人买。B 一次性做完违背“最小”原则，C 追求极致效果超出 MVP 范围，D 只关注上线速度而忽略验证目的，三者都与 MVP 的本质相悖。

Q2. 数据冷启动阶段优先应该怎么做？

单选题 · mid

  • A.先积累数据再启动项目
  • B.直接训练大规模大模型
  • C.先上规则引擎做冷启动← 正确答案
  • D.暂停项目等待数据足够

答案：C。数据冷启动期的正确姿势是先用规则引擎垫底，就像新摊子先按家常菜谱做菜，边营业边攒口碑和偏好记录。A 和 D 把启动无限推迟，B 没有足够数据硬上大模型就像让大厨在没有食材的厨房里做菜，都不现实。

Q3. 两周迭代节奏的核心价值是什么？

单选题 · mid

  • A.以更快的速度发布完整功能
  • B.快速验证假设并获得反馈← 正确答案
  • C.借机减少团队的开发工作量
  • D.一次规划未来半年的完整路线

答案：B。两周迭代的本质是“快速验证假设 + 获取反馈”，对应餐车每晚收摊复盘、第二天调整菜单。A 是追求完整功能的产品思路，C 是变相减负，D 的大周期规划与小步快跑矛盾，这三者都没有抓住“验证”这个核心。

Q4. MVP 的范围定义应优先选择什么？

单选题 · easy

  • A.技术实现最为复杂的功能
  • B.用户在访谈中提出的全部想法
  • C.用户频率最高的核心痛点← 正确答案
  • D.最容易开发的技术验证功能

答案：C。MVP 范围优先圈定频率最高的核心场景，就像餐车先卖回头客最多的招牌菜。A 是炫技导向，B 是全盘接收需求导致范围失控，D 是成本导向而非价值导向，三者都偏离了“验证核心价值”的初衷。

Q5. 规则覆盖率低于目标且数据量达标时，应该怎么做？

单选题 · hard

  • A.立即删除规则引擎的兜底逻辑
  • B.等待样本达标后再切换模型← 正确答案
  • C.不断扩张规则以覆盖更多场景
  • D.直接停用规则只保留模型结果

答案：B。当数据量达标且规则覆盖不足时，说明模型该上场了。就像阿珍的笔记本记满 100 位客人的口味后才调整配方。A 和 D 贸然删除或停用规则，等于把备用伞扔了，风险极高；C 在数据足够时还继续堆规则，就像有了大厨还坚持全部自己做，效率低下。

Q6. 交付清单最核心的作用是什么？

单选题 · mid

  • A.能提升业务方对交付的信任度← 正确答案
  • B.帮助项目隐藏潜在的风险项
  • C.减少开发过程中的沟通成本
  • D.替代用户在真实环境中的测试

答案：A。交付清单让“能不能上线”从主观判断变成客观打分，从而提升信任度，就像出摊前的食材和零钱检查让客人放心点餐。B 隐藏风险与清单的透明精神相反，C 只是附带效果，D 不可能替代真实用户测试。

Q7. 业务方预期对齐应包括哪些内容？

多选题 · mid

  • A.明确本期交付的能力边界← 正确答案
  • B.约定核心指标与验收口径← 正确答案
  • C.承诺所有需求全部实现
  • D.确定每次迭代的复盘节点← 正确答案

答案：ABD。预期对齐要明确边界、约定验收口径、确定复盘节奏，对应餐车开张前说清“只卖三样菜、价格怎样、随时听反馈”。C 承诺所有需求等于放弃范围控制，是范围蔓延的根源，不属于预期对齐。

Q8. “小步快跑”的核心含义是什么？

单选题 · easy

  • A.大周期规划加小步频繁交付
  • B.把开发任务拆解到多个小团队
  • C.缩短迭代周期并保持持续验证← 正确答案
  • D.减少迭代过程中的质量把关环节

答案：C。小步快跑指缩短迭代周期并持续验证，就像餐车每天收摊复盘、第二天调整菜单。A 的大周期规划本身就不“小步”，B 是组织调整而非交付策略，D 牺牲质量底线换速度是饮鸩止渴。

Q9. AI 项目的风险预案应包含哪些内容？

多选题 · hard

  • A.模型效果不达标时的降级链路← 正确答案
  • B.数据断供时的人工兜底流程← 正确答案
  • C.长期依赖单一大模型供应商
  • D.线上故障时快速回滚的机制← 正确答案

答案：ABD。风险预案要覆盖模型降级、数据断供的人工兜底和系统回滚机制，就像餐车备好备用伞、备用气罐和紧急肉铺电话。C 的“依赖单一供应商”本身就是风险源而不是预案，应该避免而不是列入预案。

Q10. MVP 交付成功的标志包括哪些？

多选题 · mid

  • A.核心业务场景价值得到验证← 正确答案
  • B.数据积累达到预期的切换阈值← 正确答案
  • C.业务方对交付结果充分认可← 正确答案
  • D.代码评审在行业中获得最高分

答案：ABC。MVP 交付成功的标志是核心场景价值被验证、数据积累达标、业务方认可，这三者对应“招牌菜有人买、口味记录够多、客人说好吃”。D 追求代码量行业最高是工程虚荣指标，与 MVP 验证商业价值的目标无关。