AI 产品迭代管理：从 MVP 到规模化
AI 产品迭代管理：从 MVP 到规模化
AI product 的迭代，和传统 SaaS 最大的区别，不是节奏更快，而是变量更多。你改一次 UI 是一个变量；你换模型、改 system prompt、补 few-shot、调 temperature，就已经是另外四个变量。很多 AI 团队迭代越多，系统反而越难控，就是因为没有把这些变量分层管理。
所以这页的核心不是“怎么多发版本”，而是怎么在不确定性里迭代，还能知道到底是哪一层变动带来了结果。
先说结论：AI 产品不能只做功能版本管理
传统产品常见的版本管理是：
feature release -> bug fix -> next sprint
AI 产品至少要同时管理 3 层版本：
- product version
- prompt version
- model version
如果这三层混在一起发，出了问题几乎没法定位。
为什么 AI 迭代更容易失控
| 传统产品 | AI 产品 |
|---|---|
| 逻辑大多可预测 | 输出天然带随机性 |
| 回归测试覆盖率更清晰 | 很多问题只能用 eval + 人审发现 |
| 回滚通常是代码层 | 还要考虑模型、prompt、数据版本 |
| 用户预期更稳定 | 用户会直接感知到回答风格变化 |
这也是为什么 AI PM 不该只盯 sprint burndown，还要盯 quality drift。
一套更稳的迭代分层
| 层级 | 包含什么 | 更适合什么发布方式 |
|---|---|---|
| Product layer | UI、flow、permission、feature flag | 常规 sprint 发布 |
| Prompt layer | system prompt、few-shot、output spec | 小流量灰度 |
| Model layer | model swap、routing、parameter change | 必须配 eval + rollback |
经验上，越靠近 model layer，越不应该“一次改很多”。
MVP 阶段最容易犯的错
错误 1：先冲功能面，后补评估体系
这会导致你每次都只能凭感觉说“好像更好了”。
错误 2：把 prompt 当运营素材，不做 versioning
结果就是团队里每个人都在偷偷改 prompt，但没人知道线上跑的是哪版。
错误 3：上线前只看 demo，不看 edge case
真实用户的输入一定比 demo 脏得多、乱得多，也更难预测。
AI 迭代一定要先有 Eval，再谈优化
没有 eval，所有“优化”都只是 subjective preference。
一套够用的 eval 组合通常包括：
| Eval 类型 | 用来发现什么 |
|---|---|
| offline test set | 基础能力有没有变好 |
| human review | 答案是否真的可用 |
| online metrics | 用户是否买账 |
| safety check | 有没有新风险 |
不要等到出事故才补 eval。那时你已经在拿真实用户做测试了。
迭代节奏怎么定更合理
更稳的 AI iteration cadence 可以是这样：
| 迭代类型 | 周期 | 例子 |
|---|---|---|
| hotfix | 当天 | prompt bug、安全问题、明显跑偏 |
| minor tuning | 1-2 周 | prompt 优化、UI 小调、阈值调整 |
| capability release | 2-4 周 | 新 workflow、新工具调用、新模型路由 |
| architecture shift | 1-3 月 | RAG 改造、agent 化、infra 重构 |
如果你所有改动都塞进双周 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 最大的问题是输出不稳定，所以实验设计要更收敛。
| 问题 | 更稳的做法 |
|---|---|
| 同输入不同输出 | 拉长样本周期，不迷信单次结果 |
| 指标太主观 | 混合自动指标和人工标注 |
| treatment 改太多 | 一次只验证一个核心假设 |
| 只看均值 | 额外看坏样本和高风险 case |
一个高均值但长尾翻车严重的版本，不一定值得上线。
回滚策略必须提前写
AI 团队常见的一种危险心态是：
“先上线看看，不行再说。”
更稳的做法是上线前就写清楚：
| 问题 | 需要预先定义什么 |
|---|---|
| 回滚触发条件 | 满意度下降、投诉上升、特定错误率超阈值 |
| 回滚对象 | product、prompt、model 哪一层 |
| 回滚速度 | 谁执行，多久能切回 |
| 数据保留 | 需要保留哪些实验日志和坏案例 |
如果没有 rollback playbook，你其实不是在迭代，而是在碰运气。
一套够用的 Iteration Review 模板
每次版本发布后，至少复盘这 6 件事：
- 我们改了哪一层
- 预期提升的指标是什么
- 哪些样本明显更好了
- 哪些 edge case 变差了
- 有没有 cost / latency side effect
- 这次 change 是否值得继续放量
这个 review 模板越稳定，团队就越不容易陷入“每次都在重新解释”。
Practice
拿你现在在做的一个 AI feature，把最近一次上线拆开看：
- 改的是 product、prompt 还是 model
- 有没有对应的 eval
- 有没有灰度阶段
- 有没有明确 rollback threshold
只要这 4 个问题里有两个答不上来，这个迭代流程基本还不成熟。