LLM 产品的敏捷迭代：把假设驱动开发用到极致

实践卡 · Lean-Agile for AI 系列（第二阶段开篇）适用角色：AI 产品经理、LLM 应用团队负责人、技术负责人前置：任意支持长上下文的对话式 AI（如 GLM、GPT、Claude）；准备一条 LLM 功能需求或一次实验结果。

方向切换说明

本篇起，系列从「AI for Lean-Agile」（用 AI 赋能敏捷实践）切到「Lean-Agile for AI」（用敏捷/精益方法论管理 AI 产品的开发）。前者是“AI 帮人做敏捷”，后者是“人用敏捷做 AI”——这是「用纪律做 AI 产品」路线的真正主场。

为什么 LLM 产品不能照搬传统迭代

传统软件可以靠一份写清楚的需求文档开工，因为“输入确定、输出可预期”。LLM 产品恰恰相反：

模型是黑盒：你无法在写 PRD 时精确预测某个 prompt 的效果。
效果难预估：同一个功能，换模型、换措辞、换样本，结果天差地别。
用户接受度模糊：“回答好不好”往往主观，靠感觉迭代必翻车。

所以 LLM 产品的正确姿势不是“大需求文档 → 开发 → 上线”，而是假设驱动开发（HDD）+ 小实验：把每个改动当成一个可证伪的假设，用最低成本验证，让证据而非拍板来决策。

这份卡片怎么用

复制下方 Prompt，把 {占位符} 换成你的真实内容。
新功能先跑 Prompt 1（需求→假设），别直接动手写 prompt。
有假设就跑 Prompt 2/3 设计实验与评测。
拿到结果用 Prompt 4 复盘决策，用 Prompt 5 规划长期节奏。

先认清 5 个核心概念

概念	在 LLM 产品里的含义
假设驱动开发（HDD）	把每个产品改动当成可证伪假设，用实验验证而非拍板
Build-Measure-Learn	精益创业循环：构建最小产物 → 度量 → 学习
LLM Eval（评测）	自动 rubric / 人工抽检 / 线上 A-B 多管齐下，先建评测再优化
探针实验	最低成本验证技术可行性（prompt 探针、影子模式、小流量）
提示词即代码	Prompt 版本化、可回滚、纳入代码评审，而非随手改

下面 5 个 Prompt 围绕这个循环展开。

Prompt 1 · 需求转可验证假设

场景：团队说“加个 XX 能力”，但你清楚这不该直接做，而该先验证。

你是一名既懂精益创业又懂 LLM 产品的产品教练。请把下面这条 LLM 产品需求，转化为「可验证假设」格式：

结构要求：
- 假设：我们假设 [某改动] 能为 [用户/场景] 带来 [预期效果]
- 成功指标：可量化，含基线值与目标值
- 最小证据阈值：达到什么算验证成功
- 主要风险与前提

若原需求模糊，先指出缺失信息，再基于合理假设补全（标注「假设」）。
【LLM 产品需求】
{粘贴}

小提示：没有“成功指标 + 基线值”的假设都是伪假设。AI 会逼你把“更好用”翻译成“采纳率从 40% 提到 55%”。

Prompt 2 · 设计最小验证实验

场景：假设有了，想用最低成本知道它成不成立。

针对下面的假设，请设计一个「最低成本验证实验」：
- 实验类型（提示词探针 / 影子模式 / 小流量 A-B / 人工模拟）
- 需要的样本量与周期
- 如何对照（基线 vs 改动）
- 需采集的指标与采集方式
- 明确「不值得做」的弃权条件（成本过高或风险过大）
【假设】
{粘贴 Prompt 1 的输出}

Prompt 3 · 设计 LLM 评测方案

场景：功能写出来前，先想清楚怎么证明它“真的好”。

请为下面的 LLM 功能设计评测（Eval）方案，覆盖三层：
1. 自动评测：给出 3–5 条可程序化判断的 rubric（如格式合规、事实一致性、拒答恰当性）
2. 人工抽检：抽检比例、评分维度、评分者一致性校准方式
3. 线上指标：埋哪些行为指标（采纳率、重试率、负反馈率）
并给出「功能可发布」的综合通过标准。
【LLM 功能描述】
{粘贴}

Prompt 4 · 实验复盘与决策

场景：实验跑完了，数据摆在那，要决定下一步。

下面是一次 LLM 实验的结果数据与当初的假设。请：
- 判断假设是否成立（证据是否达到最小阈值）
- 给出三选一决策：坚持(Persist) / 迭代(Pivot) / 放弃(Kill)，并说明依据
- 若迭代，给出下一轮假设方向；若放弃，说明学到了什么、避免了什么损失
【当初假设】
{粘贴}
【实验结果】
{粘贴指标与观察}

Prompt 5 · 规划迭代节奏（双轨制）

场景：团队既要在 LLM 上快速试错，又要稳定交付，两者常打架。

我们是一个做 LLM 产品的团队，现状如下。请帮我们规划迭代节奏：
- 设计「双轨制」：prompt/模型实验轨（快速试错）与 工程交付轨（稳定发布）如何并行不打架
- 假设 Backlog 的维护方式（如何持续产生与淘汰假设）
- 一个 2 周迭代的样例节奏表（含假设评审、实验、复盘节点）
【现状】
{粘贴团队规模、发布频率、当前痛点}

最佳实践小结

先写假设再动手：每个 prompt/功能改动都先落成“假设 + 成功指标”，这步省下的返工远大于花的时间。
评测先行（eval-driven）：别靠感觉调 prompt，先建 rubric 和线上指标，优化才有靶心。
小流量 / 影子模式降险：新 prompt 别全量，先用探针和影子模式验证再放量。
失败假设也是资产：快速 Kill 一个不成立的方向，比硬扛三个月更划算——学习本身就有价值。
双轨并行：把“prompt/模型实验”和“工程交付”拆成两条轨，避免试错节奏拖垮发布稳定性。
提示词版本化：Prompt 当代码管，版本、回滚、评审一个都不能少。

FDE 工作流 ③ 探针验证的深挖卡。延伸阅读：《AI 产品的价值流映射：从数据到上线》——把假设驱动的纪律用到上线与监控闭环（⑤）。