# Build Measure Learn

> 用开发—测量—认知反馈循环驱动产品迭代。当你想知道"做完产品后如何判断对不对"、"要不要坚持当前方向"、"什么时候该转型"时，使用此Skill。

- Skill: `ace3000chao/build-measure-learn` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ace3000chao/build-measure-learn`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ace3000chao/build-measure-learn/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ace3000chao (https://skillmd.com/u/ace3000chao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ace3000chao/build-measure-learn

---


# Skill: Build-Measure-Learn循环

## Metadata
- **ID**: leanstartup-002
- **类型**: framework
- **来源**: 《精益创业》引言+第五章
- **验证状态**: ✅ 三重验证通过（V1: 全书核心, V2: 每日决策, V3: 非常识）

## R — Reading（原文引用）
> "新创企业的基本活动是把点子转化为产品，衡量顾客的反馈，然后认识到是应该改弦更张还是坚守不移。所有成功的新创企业的流程步骤都应该以加速这个反馈循环为宗旨。"

## I — Interpretation（方法论骨架）
BML循环的核心洞察：**创业不是一条直线（计划→执行→评估），而是一个不断加速的循环**。
- **开发(Build)**：不是"做完产品"，而是"把想法转化为可以测试的形式"
- **测量(Measure)**：不是"看数据涨跌"，而是"确认我们获得了关于假设的真实反馈"
- **认知(Learn)**：不是"学到了新东西"，而是"证明或证伪了一个关键假设，决定坚持还是转型"

**质量标准不是"功能多少"，而是"这个循环转得多快"。**

## A1 — Past Application（书中案例）
**IMVU的教训**：作者团队花了6个月开发产品发布后，**没有任何用户**。但他们没有把"发布"当成终点，而是把"发布"当成循环的起点——每天追踪顾客行为、每周迭代，最终找到正确的产品方向。

**Facebook的快速迭代**：不是"想好所有功能再发布"，而是每次只发布一个功能，观察数据，立刻决定是坚持还是调整。

## A2 — Future Trigger（何时调用）
**当你听到以下问题时，就应该调用这个Skill：**
- "产品发布后，下一步该做什么？"
- "我怎么知道我们的方向是对的？"
- "我们要不要做一个新功能/进入新市场/改变定价？"
- "团队在争论该不该坚持当前方案，怎么裁决？"
- "产品迭代了很多版本，但不确定是否真的在进步"

## E — Execution（可执行步骤）

### 步骤1：确认当前循环的位置
问自己：**这个循环现在卡在哪里？**
- 是不知道该开发什么？（想法太多，没有优先级）
- 是开发了但没有测量反馈？（发布了就完事）
- 是测了数据但不知道代表什么？（数据一堆，没有洞察）
- 是知道方向错了但不敢调整？（缺乏转型勇气）

### 步骤2：为每个活动计时
**开发时间**：从想法到"能获取用户反馈的产品"要多久？
- 目标：越短越好，目标≤1周
- 如果超过1个月，问："能否拆解成更小的可测试单元？"

**测量时间**：从发布到"获得有统计意义的数据"要多久？
- 目标：越短越好，目标≤2周
- 如果超过1个月，问："是否有更快的验证方式？"

**认知时间**：从数据到"知道该坚持还是转型"要多久？
- 目标：当天或次日决策
- 如果超过1周，问："数据是否清晰到可以决策？"

### 步骤3：问核心问题
> **"我们把时间投入哪个环节，能最大化加速整个循环？"**

把资源集中在**拖慢整个循环的那个环节**。

### 步骤4：建立"加速"的定义
不要笼统说"加快迭代"，要具体：
- 从想法到用户反馈：原来X天 → 目标Y天
- 从数据到决策：原来X天 → 目标Y天
- 每月迭代次数：原来X次 → 目标Y次

## B — Boundary（何时不适用）

| 不适用场景 | 原因 |
|-----------|------|
| 基础研究/长期技术研发 | 这类工作的反馈周期本身就很长，无法按"周"计算 |
| 高度监管的产品（药品/航空） | 合规要求限制了迭代速度 |
| B2B大型复杂销售 | 一个销售周期可能数月，不适合快速BML循环 |

**作者盲点提醒**：BML循环的"快"是有代价的——它要求团队习惯"不完美"并容忍频繁的方向调整。对于追求完美或权威导向的团队，这个循环会让成员焦虑。

## 关联Skills
- **MVP构建法** — MVP是BML循环中"开发"阶段的最佳实践
- **转型决策树** — "Learn"阶段的产出决定是否需要转型
- **三个"可"衡量指标** — 确保"Measure"阶段的数据是可执行的