# Small Batch

> 用小批量方式减少浪费、加速反馈。当产品开发周期过长、团队陷入"憋大招"困境、错误发现太晚导致返工量大时，使用此Skill。

- Skill: `ace3000chao/small-batch` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ace3000chao/small-batch`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ace3000chao/small-batch/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/small-batch

---


# Skill: 小批量原则

## Metadata
- **ID**: leanstartup-007
- **类型**: framework
- **来源**: 《精益创业》第九章
- **验证状态**: ✅ 三重验证通过（V1: 9章完整+多案例, V2: 开发效率核心, V3: 反直觉）

## R — Reading（原文引用）
> "用大批量的话，我们一直要到接近流程终点才会发现问题。而用小批量的话，我们几乎能马上发现问题。"
>
> "这个结果在很多研究中已经得到证实：一次封装一个信封看似较慢，却能更快地完成工作。"

## I — Interpretation（方法论骨架）
小批量的反直觉洞察：**慢即是快，少即是多**。

大批量的诱惑：看起来效率高——可以专注做一件事，不用反复切换。

大批量的代价：
- 反馈周期拉长到几周甚至几个月
- 错误在后期才暴露，修正成本成倍增加
- 团队在"错误方向"上投入了大量资源

小批量的本质：
- 把大工作拆成小块，**每完成一小块就获取一次反馈**
- 不是"把事情做完才交付"，而是"持续交付，持续验证"

**小批量的极致 = 持续部署/持续交付**。

## A1 — Past Application（书中案例）
**信封实验**：父亲一次装一个信封赢了比赛，因为孩子们大批量处理（折100个→封信口100个→贴邮票100个），但中途发现问题只能最后返工；父亲发现问题立刻调整，总时间反而更短。

**丰田的精益生产**：丰田面对资源匮乏，无法像美国工厂那样大批量生产。被逼走上小批量道路，最终发现这种方法比大批量更高效——因为能**快速发现问题**，不用在错误的基础上继续投入。

**财捷TurboTax的快速实验**：每周进行70项不同的测试，每次测试周期只有几天。每个测试完成后立即分析结果，周四部署新测试，周一看数据，周二决策。传统软件公司的产品开发周期是季度或年度，财捷是每天。

## A2 — Future Trigger（何时调用）
**当你听到以下问题时，就应该调用这个Skill：**
- "产品开发了好几个月，但还没有给用户看过"
- "开发团队说'等发布再看看市场反应'"
- "我们花了半年做的功能，用户反馈完全不是我们预期的"
- "团队感觉工作很忙，但产品好像没有进展"
- "每次发布都像一场战役，因为积累了大量改动"

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

### 步骤1：识别大批量行为
**信号**：
- 产品开发的某个阶段超过2周没有任何用户接触
- 团队说"功能做完了，等发布日期"
- 一次性发布大量功能，而不是逐个验证
- 错误/问题总是在发布前一周才集中爆发

### 步骤2：拆解大批量为小批量
**原则**：每个批量的完成标志是**获得了关于这个批量的用户反馈**，而不是"代码写完了"。

**方法**：
- 产品功能：拆成"核心功能+次要功能"，**先发布核心，验证后再加**
- 开发任务：把"开发→测试→发布"的大循环，变成每个功能的小循环
- 会议/决策：把大议题拆成小议题，**逐个解决，逐个确认**

### 步骤3：测量批量大小的影响
**问题**：当前从"想法"到"用户反馈"需要多长时间？
- 目标：越短越好，核心功能≤1周
- 如果>2周，问："能否拆成更小的部分发布？"

### 步骤4：建立持续反馈机制
- **持续部署**：代码合并后自动发布到测试环境
- **A/B测试**：每次发布都是一个实验
- **快速回顾**：每1-2周回顾"这批工作和预期相比如何"

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

| 不适用场景 | 原因 |
|-----------|------|
| 硬件/制造业 | 物理产品的小批量成本远高于软件 |
| 合规要求严格的产品 | 医疗/金融产品的发布需要完整审批流程 |
| 极其稳定的业务 | 这类业务的大批量发布反而成本更低 |

**作者盲点提醒**：小批量需要**组织文化支持**——如果团队习惯于"功能完成后才算成绩"的绩效考核，小批量会让团队感觉"什么都没完成"。需要在绩效评估上同步调整，让"快速验证"本身就是成绩。

## 关联Skills
- **MVP构建法** — MVP是产品开发中小批量的极端实践
- **Build-Measure-Learn循环** — 小批量让BML循环转得更快
- **对比测试** — 小批量发布后，用对比测试快速验证效果