AI 产品迭代管理：从 MVP 到规模化

AI product 的迭代，和传统 SaaS 最大的区别，不是节奏更快，而是变量更多。你改一次 UI 是一个变量；你换模型、改 system prompt、补 few-shot、调 temperature，就已经是另外四个变量。很多 AI 团队迭代越多，系统反而越难控，就是因为没有把这些变量分层管理。

所以这页的核心不是“怎么多发版本”，而是怎么在不确定性里迭代，还能知道到底是哪一层变动带来了结果。

---

先说结论：AI 产品不能只做功能版本管理

传统产品常见的版本管理是：

feature release -> bug fix -> next sprint

AI 产品至少要同时管理 3 层版本：

1. product version
2. prompt version
3. model version

如果这三层混在一起发，出了问题几乎没法定位。

---

为什么 AI 迭代更容易失控

这也是为什么 AI PM 不该只盯 sprint burndown，还要盯 quality drift。

---

一套更稳的迭代分层

经验上，越靠近 model layer，越不应该“一次改很多”。

---

MVP 阶段最容易犯的错

错误 1：先冲功能面，后补评估体系

这会导致你每次都只能凭感觉说“好像更好了”。

错误 2：把 prompt 当运营素材，不做 versioning

结果就是团队里每个人都在偷偷改 prompt，但没人知道线上跑的是哪版。

错误 3：上线前只看 demo，不看 edge case

真实用户的输入一定比 demo 脏得多、乱得多，也更难预测。

---

AI 迭代一定要先有 Eval，再谈优化

没有 eval，所有“优化”都只是 subjective preference。

一套够用的 eval 组合通常包括：

不要等到出事故才补 eval。那时你已经在拿真实用户做测试了。

---

迭代节奏怎么定更合理

更稳的 AI iteration cadence 可以是这样：

如果你所有改动都塞进双周 sprint，通常会把风险管理做丢。

---

灰度发布比一次全量重要得多

AI feature 最怕的是“线下好，线上翻”。
所以更实际的 rollout 应该是：

internal testing
  -> 1% traffic
  -> 5% traffic
  -> 20% traffic
  -> full rollout

每一层都看 3 类信号：

• quality 有没有掉
• latency 有没有飙
• user complaint 有没有上升

只看 usage，不看 complaint，是非常典型的 AI PM 误区。

---

A/B Test 在 AI 产品里要更谨慎

AI A/B test 最大的问题是输出不稳定，所以实验设计要更收敛。

一个高均值但长尾翻车严重的版本，不一定值得上线。

---

回滚策略必须提前写

AI 团队常见的一种危险心态是：
“先上线看看，不行再说。”

更稳的做法是上线前就写清楚：

如果没有 rollback playbook，你其实不是在迭代，而是在碰运气。

---

一套够用的 Iteration Review 模板

每次版本发布后，至少复盘这 6 件事：

1. 我们改了哪一层
2. 预期提升的指标是什么
3. 哪些样本明显更好了
4. 哪些 edge case 变差了
5. 有没有 cost / latency side effect
6. 这次 change 是否值得继续放量

这个 review 模板越稳定，团队就越不容易陷入“每次都在重新解释”。

---

Practice

拿你现在在做的一个 AI feature，把最近一次上线拆开看：

1. 改的是 product、prompt 还是 model
2. 有没有对应的 eval
3. 有没有灰度阶段
4. 有没有明确 rollback threshold

只要这 4 个问题里有两个答不上来，这个迭代流程基本还不成熟。

---

上线前写一份 Release Contract

继续注册原型案例。假设团队准备把“先预览结果、后注册”放到 5% 流量，发布说明不能只写“优化 onboarding”。

“满足样本量”必须由团队根据基线和期望效应计算，不能在课程里假装有一个通用数字。

发布当天的 Stop / Continue Gate

STOP：安全、隐私、权限或支付路径出现新问题
HOLD：质量信号不明确，需要更多样本或人工复核
CONTINUE：主指标改善，护栏稳定，失败样本可解释
ROLL BACK：触发预先定义的回滚阈值

每个结论都要附版本号：产品、Prompt、模型、检索数据和功能开关。否则发生退化时，团队无法还原线上组合。

完成标准

• 一次发布只验证一个主要变化
• 基线、主指标与护栏指标在放量前已锁定
• Prompt、模型、数据和产品版本可追溯
• Stop / Hold / Continue / Roll Back 的负责人明确
• 回滚演练证明团队能在承诺时间内恢复

本章交付物

完成一份 AI Release Contract，包含假设、版本矩阵、流量计划、护栏和回滚记录。下一步进入 AI 产品指标体系，把每个发布判断落到可解释的指标合同。